Application Directory (Proj Directory)
in [Visual Basic]
|
Prev: Custom Browser
Next: Combobox Showing Right Justified
From: MikeD on 21 Mar 2010 13:14 "Nobody" <nobody(a)nobody.com> wrote in message news:O$aOom8xKHA.5036(a)TK2MSFTNGP02.phx.gbl... > "MikeD" <nobody(a)nowhere.edu> wrote in message > news:u2Pt2a8xKHA.4240(a)TK2MSFTNGP06.phx.gbl... >> "MikeD" <nobody(a)nowhere.edu> wrote in message >> news:uvp1qw7xKHA.5364(a)TK2MSFTNGP05.phx.gbl... >>> If you start VB by right clicking a .vbp file or any other file type >>> associated with VB (.frm, .bas, etc.), >> >> Oops. Just to clarify, I actually meant double-clicking the .vbp file >> from Explorer opened in that directory. I don't think launching VB via >> association by other means (for example, from the Run dialog) will set >> the current directory to that of the .vbp file (not sure about that >> though). Just another reason to always provide the full path to a file >> you're opening. > > In case of Declare to a DLL that resides in the same path as the VBP file, > one has to change the current directory to App.Path if running in the IDE, > or use full paths in the Declare. This is not needed in the EXE as Windows > looks for the DLL in the EXE folder first. When you run in the IDE, the > EXE folder is VB6 folder as far as the OS is concerned. See LoadLibrary() > in MSDN for the search order used to find a DLL. > Not entirely correct. Refer back to my post about what the current directory is, and how you can "set" the current directory when VB starts. Again, if you launch VB by double-clicking the VBP file from an Explorer window, the current directory of the IDE will be the folder where the vbp file is located. Assuming the non-ActiveX DLL is in that same folder, no path necessary in the Declare statement. You should never use path names (fully qualified or relative) in Declare statements because then that's the ONLY place your app (or Windows, whichever way you prefer to think) will look for the DLL. -- Mike
From: Nobody on 21 Mar 2010 21:59 "MikeD" <nobody(a)nowhere.edu> wrote in message news:eO9d8nRyKHA.5036(a)TK2MSFTNGP02.phx.gbl... > > > "Nobody" <nobody(a)nobody.com> wrote in message > news:O$aOom8xKHA.5036(a)TK2MSFTNGP02.phx.gbl... >> "MikeD" <nobody(a)nowhere.edu> wrote in message >> news:u2Pt2a8xKHA.4240(a)TK2MSFTNGP06.phx.gbl... >>> "MikeD" <nobody(a)nowhere.edu> wrote in message >>> news:uvp1qw7xKHA.5364(a)TK2MSFTNGP05.phx.gbl... >>>> If you start VB by right clicking a .vbp file or any other file type >>>> associated with VB (.frm, .bas, etc.), >>> >>> Oops. Just to clarify, I actually meant double-clicking the .vbp file >>> from Explorer opened in that directory. I don't think launching VB via >>> association by other means (for example, from the Run dialog) will set >>> the current directory to that of the .vbp file (not sure about that >>> though). Just another reason to always provide the full path to a file >>> you're opening. >> >> In case of Declare to a DLL that resides in the same path as the VBP >> file, one has to change the current directory to App.Path if running in >> the IDE, or use full paths in the Declare. This is not needed in the EXE >> as Windows looks for the DLL in the EXE folder first. When you run in the >> IDE, the EXE folder is VB6 folder as far as the OS is concerned. See >> LoadLibrary() in MSDN for the search order used to find a DLL. >> > > Not entirely correct. Refer back to my post about what the current > directory is, and how you can "set" the current directory when VB starts. > Again, if you launch VB by double-clicking the VBP file from an Explorer > window, the current directory of the IDE will be the folder where the vbp > file is located. Assuming the non-ActiveX DLL is in that same folder, no > path necessary in the Declare statement. > > You should never use path names (fully qualified or relative) in Declare > statements because then that's the ONLY place your app (or Windows, > whichever way you prefer to think) will look for the DLL. You are correct, however, there are situations when the current path in the IDE is not the same as the VBP file, like when opening another project by going to the File menu. In this case, the current directory is unchanged, and declares to a DLL in the same folder as the EXE won't work. In this case, the developer could put the DLL in the search path, or use the following code if the DLL is in the same folder as the VBP file: If IsInIDE() Then ChDrive App.Path ChDir App.Path End If In case of running a compiled EXE, Windows always checks the EXE folder first, so it's not a problem in this case.
From: Karl E. Peterson on 23 Mar 2010 20:32
MikeD wrote: > VB's kinda "weird" (IMO) with this. It depends on HOW you start VB as to > what the current directory is. But that's a good weird. If programmer's can't be reliable, how could we ever imagine users could! They can start an application in many ways, just as we can start the IDE in multiple ways. Don't assume anything. If your app is curdir dependent, make sure you know what the curdir is. It's really that simple. -- ..NET: It's About Trust! http://vfred.mvps.org |