.inc files and duplicate equates

[Conrad Hoffman]

My application was humming away with no problems so I decided to add a data-to-Excel feature. As soon as I added Excel.inc, I got a duplicated equate message. The offending item was in (obviously) the Excel.inc file, and ocidl.inc, called from atl.inc (the Roca visual activex wrapper). Risking the wrath of MCM for not posting code, can anyone give me a primer on how to deal with overlaps in a potentially large number of .inc files. Oh heck, just for MCM-

#INCLUDE ONCE "Excel.inc"
#INCLUDE ONCE "ATL.INC"               ' from Jose Roca's web site
#INCLUDE ONCE "NSTSQUIGGLECTRL.INC"   ' generated with the PBrowser included with ver. 9
#INCLUDE ONCE "WIN32API.INC"          ' windows api functions from PowerBASIC

I will note that I'm not sure if win32api is being picked up from my pb directory, or my "other inc" directory.

Thanks!

[Peter Lameijn]

If the equates are the same (in value and type) there should be no warning or error. PB doesn't mind multiple declarations, as long as they are the same.
In case of a duplicate error, the value or the variable type is probably different in one of the declares...

[Conrad Hoffman]

Ah, the first ones to come up were GUID$ functions, which should always be different. Do I have to modify the .inc files? Seems like a road to future confusion.

[José Roca]

What you have to do is to generate a new include file for Excel, but adding a prefix. Otherwise, you are going to get many conflicts, e.g. the interface Arc will conflict with the API function Arc.

[Richard Angell]

Modify existing .incs ,,, bad form ... easily do a proper one with the PB COM Browser in the new versions of PBWin and PBCC.

The duplicate naming problem is the reason the new PB COM Browser lets you enter a prefix when you create newer include files. This needs to be done with Excel, as I have already seen.. In the Tools\Options menu you can enter your own prefix, or use the default "I". Also choose to use "Always use n Interface Prefix" or "Only when the interface is an illegal name". Also be sure to check "Prefix GUIDs/ProgIDs witth Library names. Then load and generate a new include file.

Yes,it will probably mean some update of any existing code where you create declare and assign objects. However it does eliminate problems, especially in applications where formerly you may have been accessing an interface with the same name in multiple programs. An example of this is the many programs that have a "Document" interface, as well as an "Application" interface and so on. Formerly the equate names for the ProgIDs and GUIDs used generic naming and that was a source of naming conflict now solved in setting the options correctly.
[IMG]file:///C:/WINDOWS/TEMP/moz-screenshot-7.jpg[/IMG]

[Conrad Hoffman]

Well, I was hoping for some clever trick to somehow resolve everything automatically, but I guess I have to open the hood and get out the wrenches

I must say, Jose, that your ole container files are working just super- THANKS!

CH

edit- Richard, just saw your post, so maybe I can automate more than I thought.

[Michael Mattias]

I'm not sure if win32api is being picked up from my pb directory, or my "other inc" directory.

In/thru 8x, the full paths of all #INCLUDEd files are in the compile log file.

Or, in IDE editor, right-click on the #INCLUDE line to load the #INCLUDEd file, then look at the path name on the caption bar.

[Conrad Hoffman]

I knew that log must be good for something! I have several paths set under options, and the compiler looks in the order they're listed, but I noticed that I have a win32 file in several locations, so I need to check that.

[Cliff Nichols]

Personally I over-ride the settings a bit (to some its confusing, to others its a blessing) it depends on your style of thinking

Depending on the version of the compiler (amongst other things), I create a folder structure for my "Project" (or whatever I am working on at the moment, and use relative addressing (like a webpage would)....Or more to the point something like

1. Create a folder for my "Project"
2. Create a folder called "Includes" within my "Project Folder
3. Create a folder for each *.inc I need within the "Includes" folder (or just let all *.Inc file reside in the includes folder itself
4. Create a *.bas file and in it include the line "#INCLUDE "./IncludeFiles.INC" 'Define all the header files for variables and functions"
5. In that file, I list each *.Inc file that is to be used with the "Project"
6. Copy a copy of each *.Inc in the appropriate place (this way you do not corrupt or change the original in any way)

That way if you count each "./" it starts from the parent *.bas your project started from, and drill down to the folder structure you set forth, and if later needing to change or modify then you are only changing the copy for THAT "Project" and that project only, and not affecting other projects that happen to use the same *.inc files (trust me...I could NOTTTTTTtttt tell you how many times I have either used Dll's from another project, or made some "So-called" modification to meet one need to later regret it in another need.

Its much easier to look at a folder structure and determine "It worked before...why not now???" Than it is to wonder what version did you compile under??? When did you last make a change??? Did you make that change to ALLLLLLllllll your projects (from the day you first created it), Did you test for the same problems??? (I could go on)

Which is also why I stopped using prior built DLL's to handle problems (eventually they get worse, especially if the DLL name is still the same, but could be different depending on the project it was used in)

case in point...Win32Api.INC....lets say one project I wrote years ago (under PB6) I had to go back and revisit
A newer project would require me to place "ByVal" before any and all pointers (at least the compiler catches this one for me, but if it did not...now I am in research mode of "WHAT BROKE?????")

I know...my format of thinking is being reformed all the time...but relative addressing for me makes the most sense...(keep the files for the purpose, WITH THE PURPOSE and let the original stay with the purpose of who wrote it before me )

[Conrad Hoffman]

Cliff, that makes an extreme amount of sense because it reminds me of circuit board layout programs where if you modify a part, the change goes back through every board ever designed. The only good solution is to keep everything necessary for a project in one well organized place. I'm famous for making resource files, then eventually losing all the individual pieces that created them

[Michael Mattias]

SOURCE:
Generic include files ==> Master "INCLUDE" folder, first on #INCLUDE path
Win32 header files ==> WinApi folder of target compiler; second on #INCLUDE path
Files specific to this program' (including resource files) ==> this program's folder

DLLS:
Working (i.e., library code) in D:\utilties\dlls, which is on my PATH
Under development ==> in folder of using program, which might be a one-off test program.

"Where did my include files come from?" ==> compile log

(If needed, rarely) "where are my DLLs loading from?" ==>Show Loaded modules and path from which loaded June 12 2003
Show Loaded Modules Source and Executable package for PB and VB

[Cliff Nichols]

SOURCE:
Generic include files ==> Master "INCLUDE" folder, first on #INCLUDE path
Win32 header files ==> WinApi folder of target compiler; second on #INCLUDE path
Files specific to this program' (including resource files) ==> this program's folder

DLLS:
Working (i.e., library code) in D:\utilties\dlls, which is on my PATH
Under development ==> in folder of using program, which might be a one-off test program.

"Where did my include files come from?" ==> compile log

Well thats another route to go..depending on your programming "Style" and how you best remember things.

I will be the first to admit that my folder-file type of idea does have its detriments (as any project would) over the years, but can be recovered.

When first introduced to PB (and YES ...I am a VB refugee "Hello, I am Cliff, and I have a VB-ahollic )
I started noticing that PB could do things MUCHbetter and faster than I could, and yet I could understand "Most of it"

Over time...I merged more and more to PB and finally left VB (part because the .NET, and part because PB "Got RIGHT what VB got wrong)

Unfortunately I later learned that what at the time I thought building DLL's to keep common concepts together did not work, because when the "What IF???" came into play and I made a change..I forgot to test and check all code that also used that DLL

Now days...I look at it as..."Concept --->Keep Concept ---> If I use code from prior, keep in this concept only"

That way if someone else changes something I did not write, then I am only looking at "Why does this one concept not work?" rather than (why are all my others now failing????) "