Application Directory (Proj Directory)
in [Visual Basic]
|
Prev: Custom Browser
Next: Combobox Showing Right Justified
From: Webbiz on 19 Mar 2010 14:12 NOBODY posted a link to an FTP example that I'm currently looking at. This is it: http://support.microsoft.com/kb/175179/EN-US/ The file to download and extract files from is VBFTP.exe. I extracted these files into a folder called VBFTP. I then opened the project from within that directory and attempted to run the program. It comes up with an error '53' that 'open.bmp' cannot be found. When I look in the directory, it is right there. The code is below. It stops at... Set imgI = ImageList1.ListImages.Add(, "open", LoadPicture("open.bmp")) I'm puzzled. If you do not provide a complete path, isn't the app.path assumed if that is where you loaded and ran the app from? When I change this code to include the App.Path, it finds the file. LoadPicture(App.Path & "\open.bmp")) And of course fails on the next line because it cannot find the 'closed.bmp' file, etc. etc. Could someone tell me what is happening here? Why does it not look for the file in the same directory that the app is being debugged/ran in? ============ Da Code============ Private Sub Form_Load() bActiveSession = False hOpen = 0 hConnection = 0 chkPassive.Value = 1 optBin.Value = 1 dwType = FTP_TRANSFER_TYPE_BINARY Dim imgI As ListImage Set imgI = ImageList1.ListImages.Add(, "open", LoadPicture("open.bmp")) Set imgI = ImageList1.ListImages.Add(, "closed", LoadPicture("closed.bmp")) Set imgI = ImageList1.ListImages.Add(, "leaf", LoadPicture("leaf.bmp")) Set imgI = ImageList1.ListImages.Add(, "root", LoadPicture("root.bmp")) TreeView1.ImageList = ImageList1 TreeView1.Style = tvwTreelinesPictureText EnableUI (False) End Sub =============================== Thanks. Webbiz
From: Nobody on 19 Mar 2010 14:43 "Webbiz" <nospam(a)noway.com> wrote in message news:m8f7q5psuruts5778m8peklrvj4agjt88v(a)4ax.com... > Could someone tell me what is happening here? Why does it not look for > the file in the same directory that the app is being debugged/ran in? When you don't specify a full path, the current directory is used, which may or may not be App.Path. To see what the current directory is, use the following: Debug.Print "Current directory is " & CurDir() To set the current directory, use: ChDrive App.Path ChDir App.Path
From: MikeD on 19 Mar 2010 19:30 "Webbiz" <nospam(a)noway.com> wrote in message news:m8f7q5psuruts5778m8peklrvj4agjt88v(a)4ax.com... > NOBODY posted a link to an FTP example that I'm currently looking at. > > This is it: > > http://support.microsoft.com/kb/175179/EN-US/ > > The file to download and extract files from is VBFTP.exe. > > I extracted these files into a folder called VBFTP. > > I then opened the project from within that directory and attempted to > run the program. > > It comes up with an error '53' that 'open.bmp' cannot be found. > > When I look in the directory, it is right there. > > The code is below. It stops at... > > Set imgI = ImageList1.ListImages.Add(, "open", > LoadPicture("open.bmp")) > > I'm puzzled. If you do not provide a complete path, isn't the app.path > assumed if that is where you loaded and ran the app from? > > When I change this code to include the App.Path, it finds the file. > > LoadPicture(App.Path & "\open.bmp")) VB's kinda "weird" (IMO) with this. It depends on HOW you start VB as to what the current directory is. If you start VB from its shortcut, the current directory will be where VB is installed UNLESS you change the shortcut's Start In property, in which case it will be whatever you specify. If you start VB by right clicking a .vbp file or any other file type associated with VB (.frm, .bas, etc.), then the current directory will be the directory of that file. This is why I always (well, almost always) open a project by double-clicking the .vbp file, as this is most closely the same behavior as running your program as an EXE (unless modified by some means such as running the EXE via a shortcut and changing the Start In property). In any case, the BEST thing to do is always provide a fully qualified path to any file you are opening in your app because then the current directory, whatever it may be, is irrelevant. NEVER make assumptions as to what the current directory is. And I'd hope this would go without saying, but NEVER hard-code paths. Leave your code just as you've changed it to use App.Path (assuming the .bmp file is located in the same directory as either the .vbp file or the EXE file after compilation and installation on target machines). And one more thing, you should always check if the path already has a trailing backslash. In most cases, API functions and VB's own methods/properties will NOT have a trailing backslash. But this is somewhat inconsistent. For example, if your app is located in a root folder of a drive, then App.Path WILL have a trailing backslash. If you just always append a backslash, eventually you're going to end up with double backslashes and this can be hard to debug because it's probably only occurring on a single computer running your EXE and the error is going to be either an invalid path or file not found and both you and your user are going to say, "well, it IS a valid path and the file IS there, so what the hell is going on?" <g> Including the path (and filename if appropriate) as part of the error message is advisable because then you can see that it's a result of double backslashes. Basically, all you need to do is check if the rightmost character of the path is a backslash. Because this If statement/block can be tedious to write all the time, what I did what write a function called FormatPath. This function has an optional 2nd parameter to return the path with or without a trailing backslash, the default being to include the trailing backslash. I'll leave writing that function up to you as an exercise. <g> So, taking your code above, what I'd do is this: LoadPicture FormatPath(App.Path) & "open.bmp" (given the syntax you used, you shouldn't be enclosing LoadPicture's argument in parentheses, although it's not really hurting anything in this particular case. You're just causing VB to evaluate the expression before passing it to LoadPicture and therefore making your program do more than is necessary. In some cases, however, this evaluation CAN lead to, shall we say, erroneous behavior. So the lesson to be learned is, know the right syntax to use when calling procedures/methods. See VB's Help if you need clarification on this.) -- Mike
From: MikeD on 19 Mar 2010 20:45 "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. -- Mike
From: Nobody on 19 Mar 2010 21:06
"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. |