Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Determining UNC path at setup
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Fonctions Windows API
Divers
Thread ID:
00319694
Message ID:
00319847
Vues:
18
>I posted this question earlier today. Based on the two responses I received, I obviously did not accurately convey my question.
>
>I'm running a VFP setup to a workstation from an NT server using a UNC path (i.e. \\servername\sharename\setup.exe). This setup launches a VFP post setup executable (as defined in the setup wizard) which accesses dbf files on the server from which it is launched.
>
>The post setup executable currently requires a F:\ drive mapping to a server share to access dbf files (F:\dbfname). Is there any way to determine the server name from which the setup routine is running so that I may access the dbfs using the \\servername\sharename\dbfname format?
>
>I'm looking to eliminate the need for the F:\ drive mapping entirely. The two responses I received earlier directed me to functions that will determine a UNC path based on a drive mapping. I want to run the setup using a UNC path and determine where the setup exe is running from my VFP post setup executable. This would allow me to access the dbfs using UNC format and eliminate the need for any drive mapping.

This is the way I do it -- I think about the best you can do is have your app try to locate the DBC when launched. If it can not find it, I prompt the user with GetFile() to locate the DBC [they must locate the actual name of the DBC, not just any DBC]. The user rarely has to go through this. [if you prefer GETDIR[], use Bela Bodecs bbgetdir() in the Files section because this includes the Network node in the tree]. I then strip the file name from the return value and store that path in the user's local AppUser table where I keep other setup parameters. Every launch after that uses that path to the DBC. If for some reason that path becomes invalid, they get the GetFile() prompt again.
Mark McCasland
Midlothian, TX USA
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform