1. Create a folder C:\MyFolder
2. Run FF and start a new project in this folder.
3. Add forms, controls, etc.
4. Compile and run it.
5. Exit FF
6. Create a subfolder C:\MyFolder\NewFolder
7. Move your project from C:\MyFolder to C:\MyFolder\NewFolder
8. Run FF and open the existing project in C:\MyFolder\NewFolder
9. Compile it and crash.
Didn't seem to crash when I tried your test (Windows 7). I'll try tomorrow on WinXP as well.
Would you happen to have a relative path in your code somewhere that expected the original folder structure? Hard to say at this time what the problem could be.
The crash happens only if I move all files. But if I copy them and leave the originals in the first folder, everything works well. I have no relative paths anywhere in my project. But it seems that FF knows where the project used to reside and crashes if it has been moved. I tried it with several different projects with the same results. I use XP Pro SP3.
Robert
I can not reproduce that. I also use XP Pro SP3. When I move the folder with the project to another location I can open compile without problems. I tried it with three different projects.
Rolf
I also cannot replicate the crash following your steps.
WinXP Pro SP3
I have attached a zip with a project that crashes.
Robert
The problem is this line in Globals.inc:
#INCLUDE "C:\TimeTrack\forms\SQLitening.Inc"
The location for the include file is hardcoded.
Yep - that's exactly it.
Put the SQLitening.inc file into the modules folder, add it to the project, and remove the #INCELUDE line. Then you should have no problems.
Edit:
added changed project
I knew that. I was just testing you.....
Thank you all for the answer.
Robert
(:-)
I think that FF should give you an error message if the file to be included is missing, instead of crashing.
Robert
Quote from: Rolf Brandt on July 27, 2010, 12:44:51 PM
Put the SQLitening.inc file into the modules folder, add it to the project, and remove the #INCELUDE line. Then you should have no problems.
What about an .INC that is used by many projects? I have always thought that the advantage of an .INC is that you have one copy in a central location (for example: x:\WIN32API\) , and just "#INCLUDE" it where needed.
If you have a copy in each project's "modules" folder, then when/if you have to update the .INC, then you have to be sure that you update every copy... (ie, FIND them all first! and worry if one has been customized...)
I would be concerned about maintenance if copies of a general-purpose .INC had to reside all over the place...
-John
John, If you use only one copy of an .inc file and make a change you could break all your other projects. Unfortunately, there is no clean way to get around this issue. Either way presents a problem for us to solve. If it was easy - it wouldn't be called "work".
Using relative paths works well for me:
#include "..\modules\filename.inc"
I also rarely add a module to the FF workspace. An exception would be the events module for an ActiveX control, since you would be doing some editing.
Once a module is "carved in stone" it can then be simply included without being added as a module.
Just a theory..
Well one consolation to me is that I'm not the only one facing these issues. I thought it was just because I'm an occasional programmer that I'm unclear on how to best configure things...
Because I'm not doing this all day, every day, the effort to keep things up to date and synchronized is more than "work" for me, it's a significant and major project... I can't keep it all in my head, I've found no reasonable methods, and the tools seem inadequate.
Does everyone just accept this as "normal"? Does anyone else think that there should be a better way? Or am I just missing some advantages that this seeming jumble provides?
(Maybe this should be a different thread...?)
-John
Hi John,
Yours is the method intended-by-design in PB. I think that may be the only method to "include" a file in PB.
FF also follows the same method. This is why you can set the paths of PB's includes as well as Jose's includes.
I would say that any additional include files, like SQLitening.inc for example should also be placed in one of the path depending on which set of includes preferred.
FF also allow for modules where include files can be added. I think Rolf suggested that method probably because Robert was already doing that with his Global.inc, wherein the offending hard-coded path include line was also found.
I will go with the PB intended-by-design method, which is the method you stated.
I think that many of you are missing the point of this thread. No matter where you have your files, if an INCLUDed file is missing FF crashes rather than telling you that it cannot find the file.
Robert
I've seen people use "IF NOT DEF" tests at the top of an .INC file in order to avoid errors due to defining duplicate equates.
Could that help you avoid compiler errors when an .INC is missing???
-John
There are a few situations where FF blows up when it fails to correctly the position of a compiler error. I'll have to build in some additional checks to at least show the compiler message even if the position can not be determined.
Perhaps we could also get an improved analysis of the information in the rc file.
When a file is not found, followed by a crash of the rc.exe.
For beginners, it's difficult to find these errors.
Quote from: Rudolf Furstauer on August 10, 2010, 10:37:57 AM
Perhaps we could also get an improved analysis of the information in the rc file.
When a file is not found, followed by a crash of the rc.exe.
For beginners, it's difficult to find these errors.
That is more difficult - I remember trying to deal with the rc compiler many times and it seems to be very erradic at best. I will look again while dealing with this whole error detection issue.