3.09 crashes

[Robert Rioja]

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.

[Paul Squires]

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.

[Robert Rioja]

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

[Rolf Brandt]

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

[Cho Sing Kum]

I also cannot replicate the crash following your steps.
WinXP Pro SP3

[Robert Rioja]

I have attached a zip with a project that crashes.

Robert

[Cho Sing Kum]

The problem is this line in Globals.inc:

#INCLUDE "C:\TimeTrack\forms\SQLitening.Inc"

The location for the include file is hardcoded.

[Rolf Brandt]

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

[Robert Rioja]

I knew that.   I was just testing you.....

Thank you all for the answer.

Robert

[Rolf Brandt]

(:-)

[Robert Rioja]

I think that FF should give you an error message if the file to be included is missing, instead of crashing.

Robert

[John Montenigro]

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

[Peter House]

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".

[Pat Dooley]

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..

[John Montenigro]

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