Building FWH

[rhlawek]

I would like to be able build fivewin locally using harbour 3.2. I happen to be using MSVC at the moment, but I use BCC and mingw as well. I keep running into the following problem:

Compiling 'classes\dbm.prg'...
classes\dbm.prg(38) Error E0030 Syntax error "syntax error at 'ODICT'"
classes\dbm.prg(51) Error E0030 Syntax error "syntax error at 'AFIELDS'"
2 errors
No code generated.

The error each time is for a line as follows:

BYNAME oDict

I see that this is defined in:

#include "Objects.ch"

Which is included in FiveWin.ch, but I can't clear the error even if I explicitly add Objects.ch to dbm.prg. Please note that dbm.prg is just the first prg I get to with this error, there are quite a few others with the same issue.

I've run out of things to look for and haven't figured this one out. Any insight into what is going on here would be most appreciated.

Best regards,

Robb

[Antonio Linares]

Robb,

Thats an old FW 16 bits file that should not be there, we are sorry.

We are going to delete it right now, thanks

[Antonio Linares]

The same applies for dbms.prg

[rhlawek]

I've now renamed both of those files in my local copy.

Next error:

Compiling 'classes\ddeserv.prg'...
classes\ddeserv.prg(11) Error F0029 Can't open #include file 'DdeFV.ch'

I don't see that .ch file anywhere. I've worked around it temporarily by commenting out the include line in ddeserv.prg. I assume this is just a missing file in the 13.06 distribution, but that is just a guess.

Next error:

Compiling 'classes\dialog.prg'...
classes\dialog.prg(521) Error E0030 Syntax error "syntax error at 'STATIC'"
classes\dialog.prg(524) Error E0030 Syntax error "syntax error at 'STATIC'"
classes\dialog.prg(526) Error E0030 Syntax error "syntax error at 'STATIC'"
3 errors

These are due to the following declarations. As it is a syntax error I'm assuming it is another improperly referenced .ch file. But, as I am compiling this with msvc, I am not sure there isn't still going to be an issue even if the syntax error is corrected.
//----------------------------------------------------------------------------//
// Conection with Borland's VBX DLL - at run-time !!!

DLL STATIC FUNCTION VbxInitDialog( hWnd AS WORD, hInstance AS WORD,;
cResName AS STRING ) AS BOOL PASCAL LIB "BIVBX10.DLL"

DLL STATIC FUNCTION VbxInit( hInstance AS WORD, cPrefix AS STRING ) ;
AS BOOL PASCAL LIB "BIVBX10.DLL"

DLL STATIC FUNCTION VbxTerm() AS VOID PASCAL LIB "BIVBX10.DLL"

[Antonio Linares]

Robb,

Please check that you are using the right DLL.ch

Dialog.prg should compile fine with no errors at all.

Best regards

Antonio

[Richard Chidiak]

Robb

Vbx is for 16 bits only, it will not run on 32 bits

Hth

Richard

[rhlawek]

Richard,

I understand and agree.

Since that last email I have commented out a number files and renamed them .orignal, starting with dbm.prg and dbms.prg as Antonio suggested was proper. I still have to review the complete list of those validate myself, but I think I don't use them, at least not directly. Internally by FW, I have no idea yet. I commented out anything with odbc in its name, as well as anything with sql in its name. I do use some of these features, but I get get much of this from harbour itself. I can provide that list.

I have quite a number of edits of files where structures are used, here just adding "CStruct.ch" to compliment the already present "Struct.ch" fixes most issues. There is still a problem with member strings, this coded uses syntax MEMBER variable AS STRING LEN nn, but LEN nn throws and error under harbour. I use structures in another program and I don't recall this being an issue there so I'll be looking for a configuration issue on my end. For now I've just commented out // LEN

I simply commented out all calls to DLL or DLL32. I'm sure I've disabled a great number of things doing so, but as pointed out, it may not be relevant if they are 16 bit extensions. I'm sure the syntax error is an easy fix, but its the figuring out if they are relevant part that matters. I'm guessing DLL files aren't files I use anyway, but possibly all DLL32 could be used.

I can't that I've tested the outcome, but I at least got it to compile, or I got all the .prg code to compile. I have a number of .c files that won't compile, but appear to be critical, at least by name. This group of errors may be c compiler switch related, so I need to review any errors there.

I am currently trying to build use my .prg lib with the FWH provided FiveHC.lib to do some testing that way.

Antonio, if any of this is helpful outside my personal interest I'll continue to share what I find on this thread. If not of general interest I'll get on with my testing and open discrete problems. If this is helpful for improving things overall, I'm more than happy to share, and learn.

Robb

[Antonio Linares]

Robb,

You don't need to modify the FWH sources to compile. If they are not compiling fine is because you are not providing the right path to the header files to use, or a wrong Harbour version, etc.

No need at all to use "CStruct.ch". Please let us know what errors you get when compiling and we will try to find what is going on on your side, thanks

[rhlawek]

I don't want to edit any FWH files, or any harbour files either for that matter. I'm just trying to get a valid build and there are some things in the way.

All the headers in question have appropriate paths to them. I can compile anything and everything I wrote, it is only a few files in fwh causing me issues.

Without #include "CStruct.ch"

Compiling 'classes\twebcam.prg'...
classes\twebcam.prg(200) Warning W0001 Ambiguous reference 'DWORD'
classes\twebcam.prg(201) Warning W0001 Ambiguous reference 'BOOL'
classes\twebcam.prg(202) Warning W0001 Ambiguous reference '_INT'
classes\twebcam.prg(203) Warning W0001 Ambiguous reference 'BOOL'
classes\twebcam.prg(204) Warning W0001 Ambiguous reference 'DWORD'
...

With #include "CStruct.ch" i get an ambiguous references, as folllows for example:

Compiling 'classes\reg32.prg'...
classes\reg32.prg(129) Warning W0001 Ambiguous reference 'DWORD'
classes\reg32.prg(201) Warning W0001 Ambiguous reference 'DWORD'

or

Compiling 'classes\twebcam.prg'...
classes\twebcam.prg(267) Warning W0001 Ambiguous reference 'STRING'

Where that latter line errors occur on lines as follows:

MEMBER oXYScroll AS STRING LEN 8

I looked for where DWORD is defined and found it in wintypes.ch, but then found that wintypes.ch itself includes cstruct.ch, so I removed the reference to cstruct.ch and added wintypes.ch and cleared all errors in this regard, with the exception of one type,

Compiling 'classes\twebcam.prg'...
classes\twebcam.prg(267) Warning W0001 Ambiguous reference 'STRING'

This one appears to me to be a conflict between FWH and harbour.

Fivewin includes this in struct.ch as follows:

#xcommand MEMBER <cName> AS <type> ;
[ LEN <nLen> ] ;
[ INIT <uValue> ] ;
=> ;
ThisStruct():AddMember( <(cName)>, <type>, <nLen> ) ;
[ ; ThisStruct():SetMember( Len( ThisStruct():aMembers ), <uValue> ) ]

harbour defines it in cstruct.ch as:

#xcommand MEMBER <!elem!> AS <!stru!> => ;
hb_Member( #<elem>, hb_CStructureId( #<stru>, .F. ) )

I don't see this as a problem problem in my code when I use the prebuilt fwh libraries you provide, but I don't use anything that uses this member syntax. It seems to me that including "wintypes.ch" is the correct way to resolve the ambiguous references, but that introduces CStruct.ch which in turn seems to bring in the conflict noted above. If there is another more proper header to use for building fwh I'll be happy to switch to that.

I also note that FWH itself redefines DWORD a itself, not sure the ramifications of that, if any.

---------- DLL.CH
#define DWORD 12

[Antonio Linares]

Robb,

DWORD, BOOL, _INT, etc. are defined inside FWH include/dll.ch

It seems to me as you are using a wrong dll.ch. This used to happen with xbase++ users as xbase++ provides a DLL.ch, different from FWH one, and xbase++ may have changed your paths.

TWebcam.prg compiles here fine with no warnings at all. Please check for that wrong dll.ch and set your paths accordingly, thanks

[Antonio Linares]

Also, those names make no conflict with C compilers same names, as FWH names are used from PRG level only, not from C.

We should use FW_DWORD, FW_BOOL, etc. so this way we avoid any possible conflict, but we can not avoid the use of a wrong CH file. Maybe we could do:

#include "dll.ch"

#ifndef DWORD
#error You are using a wrong DLL.CH
#endif

Not sure how to issue an error from the Harbour preprocessor. Going to search for it...

[Antonio Linares]

Yes, that way:

#error whatever...