Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
File locations /executable
Message
De
19/06/1997 16:55:20
 
 
À
19/06/1997 15:33:08
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00036780
Message ID:
00037037
Vues:
36
>>The one thing that stands out in your code is the use of the hard-coded "CD" statement. Why are you doing this?
>
>Good question. The reason that it was in there in the first place is that the example I modeled my startup program after had a similar statement. I commented it out for now.
>
>I'm not sure why my program needs a PATH statement in the first place, except to tell it where to look for the data. If all of the program's components are included in the app build, why should a PATH statement include anything but the locations of the data? Yet if I exclude the PATH, or set it explicitly to where the data is only, the program can't find the libraries from which toinstantiate my objects. The most maddening thing about this is that the program WORKS on another machine if I set the path to include the location of my libraries (on my drive; inaccessible from the other machine), it just gives an invalid path error from the CD statement. But remove the statement, and it says it can't find the libraries. The current version of the relevant code follows (doesn't work)

For some silly reason, FoxPro can't seem to always find all the relevant parts of an application without naming their relative directories in SET PATH. I have code inplace to handle this in my applications.

>lcLastSetPath=SET("PATH")
>*!* CD "c:\atpedb"
>*!* SET PATH TO ;DATA;INCLUDE;FORMS;GRAPHICS;HELP;LIBS;MENUS;PROGS;REPORTS;
>lcLastSetClassLib=SET("CLASSLIB")
>
>SET CLASSLIB TO myclasses ADDITIVE
>SET CLASSLIB TO atpedb additive
>SET CLASSLIB TO appwiz additive
>lcOnShutdown="ShutDown()"
>ON SHUTDOWN &lcOnShutdown
>ON ERROR ErrorHandler(ERROR(),PROGRAM(),LINENO())
>_shell="DO Cleanup IN progs\atpedb"
>
>*!* Instantiate application object.
>RELEASE goApp
>PUBLIC goApp
>goApp=CREATEOBJECT("wzApplication")
>

Is "wzApplication" in myclasses.vcx? I noted that this vcx had 9 characters in its name, making it a long file name. You mentioned that the application was once developed in 3.0 - was this development on a Win3.x machine? And in any case, have you forced recompilation of the entire system once it was moved to 5.0?

When I first tried testing a 3.0 app on a Win3.x machine, it couldn't find a particular class library, because even though it was included in the project, it had a long file name, and it couldn't cope with the search.

Try a complete recompile of your project...
David M. Stowell
Ravenslake Consulting
Chicago, Illinois

e-mail: davidstowell@ravenslakeconsulting.com
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform