Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Odd behavior of .EXE File
Message
De
06/06/2001 01:18:02
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
À
05/06/2001 21:01:00
Thomas Ianuzzi
Information Security Consultants, Inc.
Floride, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Divers
Thread ID:
00515429
Message ID:
00515578
Vues:
15
>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.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform