Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Odd behavior of .EXE File
Message
From
06/06/2001 01:18:02
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
05/06/2001 21:01:00
Thomas Ianuzzi
Information Security Consultants, Inc.
Florida, United States
General information
Forum:
Visual FoxPro
Category:
Troubleshooting
Miscellaneous
Thread ID:
00515429
Message ID:
00515578
Views:
14
>Thank you Erik - it is a path problem. Your suggestion saved me a lot of trial and error.
>
>I suppose it is necessary to run the .exe in the directory it was compiled in since the SET PATH TO command seems to work only at design time.

I've run into this couple of times, and not only in the executable - just copy a form from one app to another using SaveAs from the menu.

The point is in he DE which stores the paths to the tables as relative paths, well, at least that's what you see if you open the forms as a table, and look at the properties memo. But in the objcode (the compiled version of the methods and properties) there's a full path to the directory where the tables originally were. It took me quite a while to understand why am I seeing wrong customer's data :).

It didn't give me any trouble on user's machines, because they used different drive mappings, and Fox used the tables it found along the path - as long as it couldn't find the same directories.

So just try to run your executable in a different directory, but hide the development directory somehow (rename it?) and see what happens. In my case I couldn't rename, but instead added some code to the DE of the forms to enforce the local paths to DBCs or filenames (for free tables) for each cursor. I did it in a common method in the oApp object to which I passed the DE as a parameter.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Reply
Map
View

Click here to load this message in the networking platform