Which C compiler and which Harbour should be used for FW?

[Antonio Linares]

Microsoft vscode is also a very good option to work with MSVC as you can use Antonino Perricone's Harbour debugger for vscode

[Eroni]

Based on Antonio's tutorial at:
http://forums.fivetechsupport.com/viewt ... 15#p161128
I was able to create the project and make the configuration to compile the .PRGs sources. I also managed with search here on the forum to run the fivewin / harbour syntax color.
However, I'm having a problem when compiling from MSVC, using the same command line:

Code: Select all

D:\Tools\Harbour32MSVC2017\bin\harbour .\Source\open.PRG /m /n /w2 /es2 /gc0 /iD:\Tools\FWH1709\include /iD:\Tools\Harbour32MSVC2017\Include /iD:\Tools\LIB\Hb32_VC_Fwh1709\Include /iD:\Softway\CratusERP_MSVC\Include  /o.\source\open.c
Harbour 3.2.0dev (r1703231115)
Copyright (c) 1999-2016, http://harbour-project.org/
Compiling '.\Source\open.PRG'...
Lines 8324, Functions/Procedures 3
Generating C source output to '.\source\open.c'... Done.

That is Ok.
But when this same command is executed by MSVS, an error occurs:

Code: Select all

1>D:\Softway\CratusERP_MSVC\Source\TOOLS.PRG(2338) Error E0030  Syntax error "syntax error at ','"

Error here:

Code: Select all

oBrw:aCols[ 2 ]:bStrImage       := {|, oBrw| oBrw:aRow[ 2 ] }

The commands are exactly the same, as configured in MSVS:

Code: Select all

D:\Tools\Harbour32MSVC2017\bin\harbour "%(FullPath)"  /m /n w2 /es2 /gc0 /iD:\Tools\FWH1709\include /iD:\Tools\Harbour32MSVC2017\Include /iD:\Tools\LIB\Hb32_VC_Fwh1709\Include /iD:\Softway\CratusERP_MSVC\Include  /o%(RelativeDir)\%(Filename).c

Any Ideas?

[Antonio Linares]

Change this:

oBrw:aCols[ 2 ]:bStrImage := {|, oBrw| oBrw:aRow[ 2 ] }

into this:

oBrw:aCols[ 2 ]:bStrImage := {|x, oBrw| oBrw:aRow[ 2 ] }

[Eroni]

Thanks Antonio.
But is generated this error:

Warning W0004 Codeblock parameter 'X' declared but not used in function '_BROWSEICONES'

I think because I use the / w2 parameter, which is a very severe build. So I changed it to:

oBrw:aCols[ 1 ]:bStrImage := {|x, oBrw| x := 0, oBrw:aRow[ 1 ] }

That it is ok, no warnings.

Thank you.

[Antonio Linares]

very good

[TimStone]

Warnings may be useful in refining code, but they still allow a build of an ezecutable. I still see warnings on my builds but usually it has to do with superceeded commands, or that FWH has functions found in separate libraries.

[Eroni]

I managed to successfully generate my project using Visual Studio 2019. 499 source files. I had no problem with W10.manifest. As part of the project I have a .LIB with 96 files, I managed to generate it successfully too. Some small details I will still review and test all the features. Overall I am quite satisfied with the changes and the VS environment.
My next step is to generate a DLL to store the icons and bitmaps used in the project.
I noticed that the size of both the .LIB and the EXE increased by approximately 30%.
Would this be normal or because it is being debugged? After all, what would be the difference between debug and release mode in this case?
Thank you all.

[Antonio Linares]

The release mode should not have debug info inside and thus the resulting size should be smaller

[Eroni]

Hello everyone.

Dll created successfully.

Most of the project features already tested and approved, communication with webservice working perfectly.

I disabled my own implementation of errorsys, as I added more functionality like sending automatic error email, etc. However, when I link my function to the project, I get the error:

FiveH32.lib (ERRSYSW.obj): error LNK2005: _HB_FUN_ERRORSYS already defined in MAIN.obj

Any idea of someone who's been there?

My code:

Code: Select all

FUNCION Main ()
...
....
RETURN (NIL)

PROCEDURE ErrorSys ()
     ErrorBlock ({| e | SW_ErrorDialog (e)}) // My error function have other name
RETURN
 

[Antonio Linares]

Code: Select all

function Main ()
   ErrorBlock ({| e | SW_ErrorDialog (e)})
   ...
   ....
return nil

Use uppercase for preprocessed keywords only (my advise)

[Eroni]

Thanks Antonio, now works fine.

Use uppercase for preprocessed keywords only (my advise)

Interesting point for a good technical discussion. My former editor does this almost automatically, it has become a habit. But I see no problem with making a general change, if there are benefits.
Thankful,

[TimStone]

I customized ErrorSys and link it in with no problem. I've added additional data to the report.

[Antonio Linares]

Eroni

I see no problem with making a general change, if there are benefits

How to know what becomes preprocessed and what no ?

Because what is going to be preprocessed uses uppercase

It is a simple rule to better understand the code