Error 466 revisited

[Ken Elvehjem]

Hi,

Well, today' headache is over an Error 466.

From the log:
Error 466 in C:\MISSWEBMAP\SomeIncludeFile.INC(1887:010): Duplicate name definition
Line 1887: FUNCTION SomeFuncName(BYVAL Alpha AS BYTE, BYVAL Red AS BYTE, BYVAL Green AS BYTE, BYVAL Blue AS BYTE) AS LONG

Fortunately, I understand all the words, and I understand what the excellent PB9 Help file has to say about this problem. I also searched the Windows forum here, and I think I understand what they have to say -- But I can't tell if those posts apply to this problem.

Unfortunately, I've checked the .BAS file, and all the include files, and I cannot locate *any* other occurence of the function name.

But, when I follow the troubleshooting tip, and place my #INCLUDE *before* the Win32API.inc, then I get other errors. In any event, SomeFuncName is not referenced anywhere in the WN32API.inc.

I'm recovering from a motherboard crash, and so there may be some items that are not correctly installed yet, but then I'd expect a "bad or missing" type of error.

Help, anyone?

Sincerely,

Ken

[Michael Mattias]

Try changing "alpha," "red", "blue" and "green" to something else. That's all that's left if you've eliminated "somefuncname." Do it one at a time if you want to know which one.

That assumes, of course, you really have been silly enough to name some function "somefuncname," beacause if you made that up for posting purposes, you have just eliminated the ability of anyone to figure out your problem. (Me, I'd bet on "alpha" being the culprit)

I had one of these a few weeks ago, on the token "sID" (as in "string variable type 'ID'). Unfortunately that conflicted with TYPE SID in WIN32API.INC, and even more unfortunately my NFS for duplicate symbols ("enhance error message to show "Symbol 'symbolname' previously defined in file filename at line lineno'") has not (yet?) been implemented.

[Gösta H. Lovgren-2]

%Red, %Green and %Blue are (Integer?) constants in the WinApi file so as M points out, that's probably where the problem is.

=================================
"He would make a lovely corpse."
Charles Dickens (1812-1870)
=================================

[Ken Elvehjem]

silly...

Michael,

You are absolutely right. I changed the function name, not to confound or irritate anyone, especially you, but because the function in question is part of Patrice Terrier's excellent GDI+ Helper package. I did not feel led to post someone else's work, proprietary or not until I had either received permission to do so, or seen a precedent for it on the forum.

However, since the gdiplus.dll is a M$ file, I decided to see if it was already on my computer... it was, and in about 4 other commercial software packages, the Nero multimedia package among them.

Some are version 5.1.3097.0, and some are version 5.1.3102.1360. None of them are in the Windows, Windows\system or Windows\system32 folders.

So, do I need to use one of those, download a more recent one, or copy one of those into my program folder, or another location?

I did try changing those 4 variable names in the function from the included file... no help.

And I certainly vote in favor of having the error message tell me where the duplicated name is... can't believe it doesn't already do that.

Sincerely,

Ken

[Michael Mattias]

And I certainly vote in favor of having the error message tell me where the duplicated name is... can't believe it doesn't already do that.

There is no voting; PowerBASIC Inc is not a democracy. (I think the techinical term most applicable is "benevolent autocracy') .

However, you can send this idea as a "New Feature Suggestion" to [email protected].

If enough people ask, it just may happen.

[Bob Zale]

Take the code which generates the error and move it to the very beginning of the program.

Compile again, and the other usage will cause an error.

[Ken Elvehjem]

Well, the error *does* change...

Bob,

Moved the include to the first line of the program:

#INCLUDE "GDIPLUS.INC"

Which yields:

Error 460 in C:\MISSWEBMAP\GDIPLUS.INC(2267:021): Undefined equate
Line 2267: IF hFind& <> %INVALID_HANDLE_VALUE THEN

which seems reasonable considering that the equate is defined (I think) in the Win32API.inc which is referenced *after* the gdiplus.inc.

But it definitely does not yield the *other occurrence* of the duplicate name.

If I place the #INCLUDE "GDIPLUS.INC" after the WIN32API.inc reference, then I get the error 466.

As I mentioned before this code and associated files were fished off the hard drive from the machine that died; and they compiled there under PB8. I suppose I could have PB8 on this machine, but I didn't see it as useful.

I have never had much success "transplanting" a hard drive from one computer to another w/ different specs and getting the OS to run (I'm sure this is by design;>) but I guess that's my next step. Backwards. May have to reinstall XP.

Michael, I did send in that NFS.

Thanks,

Ken

[Bob Zale]

Then use the Windows find files function.

[Michael Mattias]

because the function in question is part of Patrice Terrier's excellent GDI+ Helper package.

Does the #INCLUDE for for that package include (no pun intended) "include control?"

I found a long time ago that whenever I am going to create an #INCLUDE file, it's best to make it self-controlling, that is,
A) It uses an equate to control if it has been included itself
and
B) (the "Big One") if it needs any other #INCLUDEd files, it conditionally #INCLUDEs them.

eg

' FILE : Myinclude.inc

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

    ' if we need anything from WINAPU...
    #IF NOT %DEF (%WINAPI) 
           #INCLUDE "WIN32API.INC" 
    #ENDIF

    TYPE MYType 
    DECLARE .... 
    %MYEQUATE  
    FUNCTION ... 




#ENDIF  ' if not already included

While I think the "#INCLUDE ONCE" feature (which is new) can probably help with, this can never work smmothly unless ALL #INCLUDEd files are handled just like this...that is, you never leave yourself dependent on the ORDER of #INCLUDEing... which is what you are doing when you DON'T explicitly (conditionally) #INCLUDE everything your #INCLUDE file might need.


MCM

[Ken Elvehjem]

Will try

Michael,

This looks like a fail-safe way to keep included files from being included recursively.

I can throw this 'net' around all of my includes and you can bet I'll do it that way in the future.

Thanks again!

Ken

[Cliff Nichols]

While I think the "#INCLUDE ONCE" feature (which is new) can probably help with, this can never work smmothly unless ALL #INCLUDEd files are handled just like this...that is, you never leave yourself dependent on the ORDER of #INCLUDEing... which is what you are doing when you DON'T explicitly (conditionally) #INCLUDE everything your #INCLUDE file might need.

From the docs

To be effective, the ONCE option must appear on every #INCLUDE of a particular file.

aka...if you do not know you are using say #INCLUDE Win32API.INC and do not place an INCLUDE ONCE...then you are breaking the rules.

(Although not tested what happens, just a fair warning if odd things happen)