Hi Paul!
In the FF Samples under MDI, there's a module named "Module1.inc". It contains a SUB named SaveFile. And in that SUB is a call to a function named: "SaveFileDialog" (which I eventually located in ComDlg32.inc).
The sample compiles and runs fine, and when I select SaveFileAs from the menu, the SaveFile dialog appears, as expected. OK, cool.
Seeing that work so well, I decided to use the same code in my own FF app.
At first, I just used Project/Add Module. Also, in the routine, I changed HWND_MDIFORM to HWND_FRMINPUT, my main form. It compiled and ran just fine.
Later I removed several general purpose modules from the FF tab bar (via Project/Remove Module), and at the start of my first form, I use the PB syntax of #INCLUDE "filename.inc" to make them available again.
I inserted the #INCLUDE line in the first form, ahead of all executable code (along with 4 or 5 other Includes that have been working fine all along).
BUT NOW, when I try to compile, FF reports that the PB compiler didn't see a declaration for HWND_FRMINPUT (my main form).
So I commented out the #INCLUDE and used Project/Add Module, and it compiled just fine again. Naturally, I can see where it is in the CODEGEN output after the compile is successful, but there is no code output when the compile fails, so I can't see the sequence of things.
I guess I'm asking if this is indeed a problem of where the file gets #INCLUDEd, and my concern would be how to know in the future how to prevent such a problem. What should I know about the way FF orders things?
(I'm concerned about it because I'm about to add in the DDOC print preview capability, and it has LOTS of included code. I want to make sure I put all that stuff in the right place!)
Thanks,
-John
Hi John,
From the sounds of it, this is a typical problem that may happen based on the ordering of #Includes in the code generation. This type of situation is being addressed in FireFly3 to allow the user to better organize the exact ordering of the Includes.
In the meantime, there is a hack that works. You need to create a simple text file (called "User_Includes.inc") and place it in the same directory as your Project. You should use JellyFish or the PB IDE to create the file. You can then place your #Include statements in that file. FireFly will search for that file during code generation.
Here is a better description of the process:
http://www.planetsquires.com/forums/viewtopic.php?t=2075
Thanks Paul - I had forgotten about User_includes.inc. Your link shows that I had asked questions about it; I think I had tried it and I don't think I saw any difference (at that time), so I haven't been using it.
Now my code is more complex but I'm also a bit more familiar with FF, so last night I checked the CODEGEN_ files. I found that my INCLUDES appear just before the FF Globals, of which the first one is:
Global HWND_FRMINPUT as DWORD
Rather than tinkering with the INC file sequence, I think the real problem is that the routines in my INC routines refer to HWND_
I think the better solution is to re-write the routines to pass the handle as a parameter... makes the INC more independent of the app...
Little by little, I'm learning...
-John
Ah, yes, I see what you mean. You're trying to access HWND_* variables in INC files when the HWND_* variables do not yet exist. Passing your window handles via a sub/function parameter would be a better idea and lead to better modular programming.
Hi Paul, yes, the HWND_ references are all now taken care of, and that problem's now been straightened out.
However, the problem comes up again in this situation:
In the User_Includes.inc, I have 4 or 5 INCLUDES, along with this line:
#INCLUDE "ddoc_p32.inc" 'ddoc preview and print routines
Near the bottom of my first form (FRMINPUT), there is a FUNCTION that uses various Equates which are initialized in that ddoc_p32.inc file.
But the compiler complains that the equates are not defined.
The workaround is to copy the needed equates into the form ahead of any sub or function. Then the compile completes and the app runs.
In the CODEGEN file for the form, those equates which I had to copy in seem to have gotten commented out...
And FF seems to be including User_Includes.inc well before the routine that depends on the Equates, so I don't see why the compiler is complaining... unless the CODEGEN modules themselves are being ordered differently...???
Anyway, this demonstrates that FF is not putting my INCLUDEs first.
(I'm running FF 2.75.)
-John
I'm having the same trouble with CommCtrl.inc:
I've got a routine that references %IPM_SETADDRESS. The routine is in an external file that gets included via User_Includes.inc.
refer to: http://www.planetsquires.com/forums/viewtopic.php?t=2188
But I get a PB error message that the equate is not defined (even if I copy it to my main form and insert it ahead of other routines)...
I'm also trying to use the FIRST_IPADDRESS functions/macros in CommCtrl.inc, but they aren't being recognized.
Yet I see in the CODEGEN_ file that FF includes CommCtrl.inc, but its ahead of User_Includes.inc.
Does FF automatically disregard my INCLUDE of CommCtrl.inc because it knows it has its own? If so, then maybe that's where the sequence is being thrown out of whack...?
I haven't messed with CommCtrl.inc up till now, and from the looks of all those allow/disallow equates spread throughout, I have some work to do in order to figure it all out.
So meantime I'm wondering if FF is disallowing the IPaddress section of CommCtrl.inc, which would prevent the compiler from seeing all the equates and macros... but I'm not sure where FF makes the decisions for those settings, or how to influence them...
-John
--------
Added:
--------
Went to FF's Options/Environment/Code Generation/ and unchecked the last setting (turned off dynamic CommCtrl.inc equates).
Now compiles OK without the manually inserted copies at the beginning of the main form.
Hi John,
Looks like that FireFly Option for generating the CommCtrl equates must be broken for the IP Control. Your best bet is to proceed as you have by keeping that option unchecked.
I also assume that now your project with the DDOC includes is compiling correclty. Is that true?
True.
I am tinkering with it and will let you know when I break the next thing. :lol: (I'm going through the same learning curve with ddoc, as I'm learning to apply it in my FF app...)
I think I'm slowly getting better at tracking down my own mistakes, although I still find it helpful to ask for help - forces me to walk through all possibilities. The big difference is that I'm gradually learning where to check first, and what kinds of things to look for. Whew! A lot for this old DOS dog to learn! But I still believe that good documentation is 90% of the answer.
As always, I appreciate your support! (And I look forward to needing less and less as I continue, as I'm sure you do too!)...
-John