Many errors while compiling ...

[Hubert Brandel]

Hi,

I have just tested the Phoenix IDE and got a 'duplicate function declaration' error in Win32API.INC ... after OleWrap.inc. So I checked and this are the lines:

 
in Main:
...
#include "Ole32Api.inc"
#include "OleWrap.inc"
#include "Win32Api.inc"
...

in OleWrap.inc:

#IF NOT %DEF(%OLEINC)
[B]  %OLEINC = 1[/B]
#ENDIF
...
FUNCTION SUCCEEDED _
  ( _
  BYVAL nStatus AS LONG _
  ) AS LONG
  FUNCTION = -(nStatus >= 0)
END FUNCTION
...

in Win32API.INC

...
#IF NOT %DEF([B]%OLEINC[/B])
    %OLEINC = 1
#IF %DEF(%USEMACROS)
    MACRO SUCCEEDED (nStatus) = (-(BITS&(nStatus) >= 0))
#ELSE
    FUNCTION SUCCEEDED (BYVAL nStatus AS LONG) AS LONG
        FUNCTION = -(nStatus >= 0)
    END FUNCTION
#ENDIF

I think in PB Win 8.0 the first %OLEINC = 1 in the first include file would be defined for the hole EXE or not ? If so the second function would be never set.

As I testet here, the include files will not get and not set def% Values in/from the calling program.

Is this because of the new 'more than 1 file' compiling ?

[Hubert Brandel]

This little program shows it Clear:

#COMPILE EXE
#DIM ALL

' %OLEINC = 1  <- this should be set in win32api.inc
#INCLUDE "win32api.inc"

FUNCTION PBMAIN () AS LONG
   
   #IF NOT %DEF(%OLEINC)
       ? "Not DEF"
   #ELSE
       ? "DEF",%OLEINC
   #ENDIF
   

END FUNCTION

This is shown in PB Win 9.0 and PB CC 5.0 : Not DEF

[Rodney Hicks]

Did you do a search of WinAPI32.INC to see if %OLEINC exists in it?
I didn't find %OLEINC in any of the .inc files in the WinAPI directory of PB 9.0.
Nor do I have an "Ole32Api.inc" file there. Perhaps this is a Phoenix issue?
What error number is that?

[José Roca]

Instead of

#IF NOT %DEF(%OLEINC)
  %OLEINC = 1
[COLOR="Red"][B]#ENDIF[/B][/COLOR]

' //
' // Generic test for success on any status value (non-negative numbers
' // indicate success).
' //

FUNCTION SUCCEEDED _
  ( _
  BYVAL nStatus AS LONG _
  ) AS LONG

  FUNCTION = -(nStatus >= 0)

END FUNCTION

' //
' // and the inverse
' //

FUNCTION FAILED _
  ( _
  BYVAL nStatus AS LONG _
  ) AS LONG

  FUNCTION = -(nStatus < 0)

END FUNCTION

It should be

#IF NOT %DEF(%OLEINC)
  %OLEINC = 1

' //
' // Generic test for success on any status value (non-negative numbers
' // indicate success).
' //

FUNCTION SUCCEEDED _
  ( _
  BYVAL nStatus AS LONG _
  ) AS LONG

  FUNCTION = -(nStatus >= 0)

END FUNCTION

' //
' // and the inverse
' //

FUNCTION FAILED _
  ( _
  BYVAL nStatus AS LONG _
  ) AS LONG

  FUNCTION = -(nStatus < 0)

END FUNCTION
[B][COLOR="Red"]#ENDIF[/COLOR][/B]

[José Roca]

This little program shows it Clear:

#COMPILE EXE
#DIM ALL

' %OLEINC = 1  <- this should be set in win32api.inc
#INCLUDE "win32api.inc"

FUNCTION PBMAIN () AS LONG
   
   #IF NOT %DEF(%OLEINC)
       ? "Not DEF"
   #ELSE
       ? "DEF",%OLEINC
   #ENDIF
   

END FUNCTION

This is shown in PB Win 9.0 and PB CC 5.0 : Not DEF

It only demonstrates that you are using the Win32Api.inc file provided by PowerBASIC instead of the one provided by Phoenix.

[Hubert Brandel]

Did you do a search of WinAPI32.INC to see if %OLEINC exists in it?
I didn't find %OLEINC in any of the .inc files in the WinAPI directory of PB 9.0.

You are totaly right, I copied the three INCs to the directory of the bas, and thought it would take this first, but it looks like it took the PB 9 file first.

It was only my mistake by this message here.
My own example will work if I put the define in win32api.inc.

Maybe it was to late tonight

[Rodney Hicks]

It was an opportune time for this to occur.

Today I had just finished creating a file(*.txt) that lists all the PB EQUATEs in the WinAPI directory along with the name of the file found in. 27038 lines.

It was an opportunity to use it for something other than what I had it designated for(the VB to PB Project).

[Hubert Brandel]

Hi,

the new reserved words in PB9 caused most errors.

[Michael Mattias]

I copied the three INCs to the directory of the bas, and thought it would take this first, but it looks like it took the PB 9 file first

The compile log file gives the full path of all #INCLUDEd files.

[Cliff Nichols]

Thank you MCM for that....I will have to check which comes first...in folder or in compiler folder....(never occured to me to check that one myself)

[Michael Mattias]

> I will have to check which comes first...in folder or in compiler folder

Thru 8x, the first place it looks during an IDE compile is the specified #INCLUDE path. The "main source code" path comes after.

I think this is backwards from the way it should be. I had sent in a NFS to allow for some kind of 'token' in the IDE include path to mean the 'main source' folder, eg.

  === COMPILER SETTINGS ===
...
Include path  [<SRC>;D:\INCLUDE;D:\INCLUDE\837]

This would allow testing a new version of the 'master' include file in D:\INCLUDE without touching that file in D:\INCLUDE until I know I have it correct, or modifying the compiler setup string ... A) that's an unwieldy screen and B) I forget to change it back.

The <SRC> token could be set up once and left alone.

MCM

[Dale Yarker]

adding dot back slash should force same directory. like:

#INCLUDE ".\Win32API.inc" 'use copy in same folder as .bas being compiled

[Michael Mattias]

dot-slash <> "main source"; dot-slash = "current"

Yes I could use fully-qualified path in the #INCLUDE statement. That's what I have to do now.

[Cliff Nichols]

Actually I do it the same way as Dale does, Unless I am being misled somehow????

[Hubert Brandel]

Hi,

after reading '.\' ... I could remember that in PB DOS
I had '.;' in front of all path settings ... just forgot.

[Michael Mattias]

Cliff, you are not being misled... "current" directory is not necessarily the same as "source" directory.

In IDE, open a file. Use File/COmmand prompt.

Open a second file in a different folder. Use File/Command prompt.

Hmm, "current" seems to change, huh?

MCM

[Cliff Nichols]

I got the idea from relative addressing from webpages, and it seemed to work with PB (since 6 anyways), that if I got it right then ".\" would keep my references local to the folder I was working from. (Kinda like VB.AppPath, but MUCH BETTER, because PB is a compiler, not an interpreter)

Only drawback I have run into (I am sure I will figure it out one day) is how the compiler numbers lines (like, this line of this INC first, and this line of this other INC next)...but that is a debate of a completely different discussion

[Michael Mattias]

Heck, I could live with that <SRC> token being ".\"; or even if there were a setup option..

  --------------------------------------------------------
  [X] Change to directory of primary source when compiling 
.....
  --------------------------------------------------------

... so that ".\" (current) would be the same as <SRC>

MCM