App.Path and AppData Question

I would like to use App.Path and Environ("APPDATA") to define the paths necessary to reach resource files used in my VB6 application program. This procedure has been strongly recommended by all the senior members on this forum and I have dutifully written the code to do so.

I now have an important question regarding this issue. Suppose the paths to these directories contain directory names containing Asian characters such as Chinese, Korean, Japanese, etc. I imagine this could easily happen on computers using different language settings with Asian characters.

Is the program going to be able to handle these strings? Or, will I generate error 76 (Path Not Found) or some other error (such as error 5 - Illegal Function Call) whenever I try to access the files for read/write operations?

You almost certainly don't want to use %APPDATA% for two reasons:

• The user can interfere with any environment variables, intentionally or otherwise.
• At the best of times this one points to the user's roaming data, which should only be used for per-user settings that apply globally within the in-house network. %LOCALAPPDATA% is usually a better choice unless you expect your programs to be installed per-machine on every workstation in the network, and large files are expensive to put in users' roaming profiles.

To answer the question though: I think you'll be ok.

While the actual words used are different in differently localized Windows you'll be retrieiving and using exactly those localized words (path names). Where the alphabet differs you'll be working with the localized "ANSI" subset of the alphabet when it comes to paths and operations on them.

Generally there should be no need to work with the Unicode API calls to accomplish these things. If there was almost nobody outside the Western locales would get much use out of VB anyway.

Well, I fear I am not OK. This just came in:
From Singapore and Taiwan:
"The error message is “Unrecoverable error 5 has occurred. This software must be reinstalled." - That's my error trap message upon invocation when the resource files are first being accessed. App.Path and Environ("APPDATA") are both being defined at that point, but it is impossible for me to trace it to the exact code line.

What concerns me is that either of these paths on Asian machines are likely to include directory names that have Asian (Unicode?) characters. When these are encountered, error 5 occurs.

In the past, when I did not use either App.Path or Environ("APPDATA") to define the paths, the error never occurred. In that case, I simply used the default App directory to store the resource files. The program ran flawlessly.

Dilettante, et al, I am really worried about this one. I hate migrating back to an old but workable solution. Vista does not like read/writes on the App.Path directory. Uninstall will leave behind fingerprints.

its best to recover APPDATA paths through APIs.. which will return always correct...

These APIs should get you started:

Private Declare Function SHGetSpecialFolderLocation Lib "shell32.dll" (ByVal hWnd As Long, ByVal folderid As Long, shidl As ITEMIDLIST) As Long
Private Declare Function SHGetPathFromIDList Lib "shell32.dll" Alias "SHGetPathFromIDListA" (ByVal shidl As Long, ByVal shPath As String) As Long


I'd say give them a search on the forum to find out their use.

Quote:

---

Originally Posted by some1uk03

its best to recover APPDATA paths through APIs.. which will return always correct...

These APIs should get you started:

Private Declare Function SHGetSpecialFolderLocation Lib "shell32.dll" (ByVal hWnd As Long, ByVal folderid As Long, shidl As ITEMIDLIST) As Long

Private Declare Function SHGetPathFromIDList Lib "shell32.dll"
Alias "SHGetPathFromIDListA" (ByVal shidl As Long, ByVal shPath As String) As Long


I'd say give them a search on the forum to find out their use.

---

What about this API?

Code:

---

Private Declare Function GetFullPathName Lib "kernel32" Alias "GetFullPathNameA" (ByVal lpFileName As String, ByVal nBufferLength As Long, ByVal lpBuffer As String, ByVal lpFilePart As String) As Long
Private Sub Form_Load()
    Dim Buffer As String, Ret As Long
    Buffer = Space$(255)
    Ret = GetFullPathName("myfile.ext", 255, Buffer, "")
    Buffer = Left$(Buffer, Ret)
End Sub

---

Do you see VB6 having the same problem using this API with Asian characters packed inside the path name, either for the App.Path or the AppData path? Also, it seems that for this API to work, "myfile.ext" has to be unique to the system. :ehh: If more than one user has installed the software, that is not going to be easy to establish. Identical file names with different paths will exist.

Seems hard to believe that App.Path and Environ("APPDATA") are obsolete. :sick:

when u say app.path and environ("_") you are doing like ssss = app.path & "\file name"
and environ ("_") & "\filename" yeah>?

i know app.path doesnt add the \ and i doubt environ does....

Quote:

---

Originally Posted by wpearsall

when u say app.path and environ("_") you are doing like ssss = app.path & "\file name"
and environ ("_") & "\filename" yeah>?

i know app.path doesnt add the \ and i doubt environ does....

---

Yes, I add the "\" and then use global variables to prefix the resource file names thereafter:

Code:

---

AppPath$ = App.Path & "\"
AppDatPath$ = Environ("APPDATA") & "\" & MF$ & "\"

---

This works on all non-Asian computers, such as mine and hundreds of others that have used the code successfully. My conclusion is that one or both of these global strings are being contaminated on the Asian machines. How on earth is this possible?

i have roofing estimating software and files are saved by lastname-address. I have had to check for charters not allowed in file names eg:

Code:

---

Private Sub txtJobCity_KeyPress(KeyAscii As Integer)
  Dim sInValidEntry As String 'allowing these charcters will cause path not found error 76
    sInValidEntry = ",42,47,60,62,58,92,63,"
    If InStr(sInValidEntry, "," & KeyAscii & ",") Then
    Call MsgBox(" These symbols not allowed:  (<) (>) (:) (/) (\) (?) (*)      ", vbExclamation, "Invalid entry")
    KeyAscii = 0
    End If
   
   
    End Sub

---

then i use this to determine where files will be stored:
api SHGetFolderPath pointed to CSIDL_COMMON_DOCUMENTS' Public folder
My installer requires Admin. I don't know about other illegal charters from non- American machines

Quote:

---

Originally Posted by Code Doc

"The error message is “Unrecoverable error 5 has occurred. This software must be reinstalled." - That's my error trap message upon invocation when the resource files are first being accessed. App.Path and Environ("APPDATA") are both being defined at that point, but it is impossible for me to trace it to the exact code line.

---

Why is that impossible?

If you give your code line numbers (using MZTools you can do it in a couple of seconds), you can simply add ERL to your error handler.

Quote:

---

Originally Posted by si_the_geek

add ERL to your error handler.

---

it may also be an idea to print out the paths too... messagebox like...

"Error 5:
Occured Line: ???
App Path: ????
Data Path: ???
Please try reinstalling this software... if this does not fix the issue please forward this error message to the software developer... it can be copied to the clipboard using Ctrl Shif C."

if you get the app path and data path on the loading of the app [it shouldnt change during the app run] it may speed up your app Even if its only slightly, just store it in global variables... and then you can be sure to get the path from the message, to determine the illegal chars...

However: bear in mind if you dont have the language set installed it will only display as a square...

i previously only ever used app.path for paths, but since i have read a lot about it, i have indeed decided to switch to data paths for future coding... / software updates... - just a matter of moving all of the previous version info the data path from app.path if its there ;)

Quote:

---

Originally Posted by Code Doc

Code:

---

AppPath$ = App.Path & "\"
AppDatPath$ = Environ("APPDATA") & "\" & MF$ & "\"

---

---

also, try this

Code:

---

AppDatPath$ = Environ("APPDATA")
if AppDatPath$ = Empty then
      err.raise -1, "Data path empty"
else
      if right$(AppDatPath$,1) <> "\" then AppDatPath$ = AppDatPath$ & "\"
end if

---

it may be some machines have the data path deleted as a variable, so your tring to open say "\me.txt" which would result to "C:\me.txt" if windows is installed on C: [correct me if im wrong somebody please]

and some datapaths may already contain the \ at the end, so only needed if its not there... [it is a user option to type a new path.. so im guessing some apps may change it also]

also: You can infact ADD environment variables... if all else fails, make a C:\????\Data\ folder to store the info... that was if environ(xyzdata) <> empty use this one...

then in the installer maybe an option to add the environ data, then your message change to
"two options, install selecting to use fixed data path... or message the devel for help copying this error:....."

not too difficault with some installers - ive never tried it though...

Well, Forum, I received this back from my Installer's technical support team:

"The trouble is that VB6 is ANSI-based, and unless you take
special precautions, any programs that you create with VB6 might have
trouble dealing with the multi-byte character sets that are typically found on Asian computers."

At this point, my conclusion is that multi-byte Asian characters are going to cause problems with path names that VB6 is trying to work with. The name of the Asian user is likely multi-byte and embedded in the Environ("APPDATA") path, and that is generating the error 5, Illegal Function Call, the instant that my program tries to use that path to find the AppDataPath location that the Installer established.

It is also possible that App.Path could also contain multi-byte Asian characters because the user is given the option to change the default App path while installing, but the likelihood is far greater that the Environ("APPDATA") path is the culprit. If the user changes the computer's language setting to English, that will not solve anything because the multi-byte Asian characters are still in the path name.

My immediate solution and perhaps the only one is to rewrite the code so that it avoids using any pre-existing paths that contain multi-byte Asian characters.

Does that seem like a reasonable conclusion? :ehh:

You may be right but then it occured to me that you could do the conversion between W and A versions of most/some API calls. So with that in mind I search for GetShortPathNameW with one of my friends (yahoo, google, ask, answers, bing) and found this...

http://caulacbovb.com/forum/viewtopi...hilit=+unicode

Not that I can read whatever language that is in but it looks like the author is converting the W (unicode) to A (ansi) for the path returned from a common dialog API call.

and this looks like the same??? but not sure if doing what you need...

http://www.vbarchiv.net/tipps/tipp_1...n-oeffnen.html



Good Luck

>I simply used the default App directory to store the resource files.
I'm a little late in the discussion however;

You may consider that although App.Path and CurDir$ usually return the same path they can return different ones. There are two default paths available not just one. App.Path will always return the path containing the exe, the path returned by CurDir$ is that specified in the Startin Property of the Windows Shortcut used to start the exe unless it is changed by a ChDir (explicitly or implicitly) in your code when it runs.
So you could;
Change all path refs to resource files from App.Path to CurDir$ in your code.
Select a folder which you know the user has read/write access to
Pop the resource files into that folder
Run the exe from a Shortcut specifying the same folder in its Startin property.

I marked this thread resolved but only with great hesitation. I suspect that the problem is not solved and could still be handled.

Is this VB forum trying to tell me that VB6 programs are not commonly used today or cannot be used easily on Asian computers in conjunction with App.Path and Environ("APPDATA") path definitions? :eek:

Diagnosing at a distance is always a bit painful. There are tools that will go further than just inserting line numbers, and some of them capture more than you'd normaly see from the IDE, along with a screenshot at the point of failure. The good ones aren't free, they can be a pain and bloat your code like crazy. I'm not convinced they'd even be reliable in a situation like this.

Without seeing some code I suppose we can't do more than guess. One possibility is that somebody has a user name containing characters valid in Unicode that don't map to the ANSI codepage in use there. The "W" API calls along with Unicode paths (\\?\..." or something I believe) might help if you could use enough of them. That probably means not directly using App.Path or Environ$() calls at all though, as well as avoiding the use of VB6 intrinsic I/O statements.

This all seems extremely unlikely to me. Surely we'd have heard howls over many years from Asian users if things are truly this grim. I know you don't want to hear it but I suspect it is something you are doing in your code. The good news is it can probably be fixed in that case.

I am in Asia, do you want me to test anything here in your regard?

Quote:

---

Originally Posted by dee-u

I am in Asia, do you want me to test anything here in your regard?

---

The problem is that the total software package is rather huge--50 Mb. Before I could send it to you electronically, I have to shrink it down to about 5 Mb by knocking out most of the resource files or build small dummy files.

I have also just received word back from the Installer who says he is having no trouble with Dir$() when used in conjunction with File.Path or Environ("APPDATA") to define file paths that contain Asian characters. That means to me that the paths are being interpreted by VB6 correctly. Gasp!

Here is a snippet of code that uses all path names that I thought were causing error 5:

Code:

---

' Define Paths
AppPath$ = App.Path & "\"
AppDatPath$ = Environ("APPDATA") & "\" & MF$ & "\"
ConfigFile$ = AppDatPath$ & MF$ & "Config.MS"

' Define Resource and Backup File Names
ResFile$(1) = AppPath$ & MF$ & "Txt"
ResFile$(2) = AppPath$ & MF$ & "Common"
ResFile$(3) = AppPath$ & MF$ & "Images"
ResFile$(4) = AppPath$ & MF$ & "Stems"
ResFile$(5) = AppPath$ & "Black Oval.Gif"
ResFile$(6) = AppPath$ & "Empty Oval.Gif"
ResFile$(7) = AppPath$ & MF$ & "Tracks"
BacFile$(1) = AppDatPath$ & MF$ & "Txt.bac"
BacFile$(2) = AppDatPath$ & MF$ & "Common.bac"
BacFile$(3) = AppDatPath$ & MF$ & "Images.bac"
BacFile$(4) = AppDatPath$ & MF$ & "Stems.bac"
BacFile$(5) = AppDatPath$ & "BO.bac"
BacFile$(6) = AppDatPath$ & "EO.bac"
BacFile$(7) = AppDatPath$ & MF$ & "Tracks.bac"
 
' Check for Resource File Integrity and Repair if Possible
For I = 1 To NumResFiles
    If Dir$(ResFile$(I), vbHidden) = vbNullString Then
        ' File Missing, so copy backup if available
        If Len(Dir$(BacFile$(I), vbHidden)) Then
            FileCopy BacFile$(I), ResFile$(I)
            SetAttr ResFile$(I), vbHidden
        Else: Msg$ = "Fatal Error. This Software must be reinstalled."
            MsgBox Msg$, 16, "Missing File Detected!"
            Unload Me
        End If
    End If
Next

---

NumResFiles is a constant set to 7. No user has reported this Message Box occurring, but error 5 is still showing up from within another error trap routine that I call within the same Sub if ever encountered. Note that FileCopy and SetAttr would not be executed unless the resource file is not present. So, if Dir$() is working correctly, I doubt seriously that error 5 is generated anywhere here.

Any thoughts?

You can log the the error number line (erl) and the values of AppPath$, AppDatPath$ and ConfigFile$ so you can better diagnose what the problem is, have you tried that already?

Quote:

---

Originally Posted by dee-u

You can log the the error number line (erl) and the values of AppPath$, AppDatPath$ and ConfigFile$ so you can better diagnose what the problem is, have you tried that already?

---

Yes, they all tested correctly. Here's a direct quote from the Installer's tech support:

"I did some quick tests with the Dir$ function on Japanese and Chinese test systems (we didn't have a Korean install handy), and it works OK, even when I feed it paths with double-byte characters.

I also analyzed the Dir$ implementation code (in MSVBVM60.DLL) and it uses the correct character conversion routines. So I don't think the problem lies there."

In short, he cannot find a thing wrong with VB6 using double-byte path names. If Dir$() works, then to me, Open and any other file-related statements should also be working flawlessly as they now do on all of the hundreds of non-Asian computers that are using this program today--Vista, XP, 2000, and and all the way back to '98.

I am stumped.

Have a look at this thread, Merri has posted a path which has a chinese character in it (post #13), have a look if it will give you an idea.

Quote:

---

Originally Posted by dee-u

Have a look at this thread, Merri has posted a path which has a chinese character in it (post #13), have a look if it will give you an idea.

---

Note that in that thread, Merri says, "MkDir is also a function that doesn't support Unicode. It fails since there is no folder "?". A lot of VB's native functions coerce to ANSI, including all the file handling functions. If you want to handle Unicode filenames, you have to use Unicode aware API calls."

That tends to conflict with what the Installer reported because if MKDir$() doesn't support Unicode as Merri claims, how could we possibly expect Dir$() to support unicode?

Special note to Marty: Please change the thread back to "Unresolved." This problem is still up in the air.

Is there a reason you haven't used ERL to determine exactly which line is causing the error?

Quote:

---

Originally Posted by Code Doc

Special note to Marty: Please change the thread back to "Unresolved." This problem is still up in the air.

---

It is no easier for Marty (or me) to do it than it is for you to do it yourself - just go back up to the first post, click on "Edit" then "Go Advanced".

You can then change the title and icon of the thread.

Quote:

---

Originally Posted by si_the_geek

Is there a reason you haven't used ERL to determine exactly which line is causing the error?

---

That's because the users who encountered the error are in Sinagpore and Taiwan and I cannot reproduce it with my computer. And, the code they are using does not have line numbers included.

Thread changed back to "unresolved".

add the ERL numbers, send the user an update, and then ask them to send the error message back - so as you can fix their issues....

this would work? - if they want your software... - if your charging them maybe like a small &#37; refund for hassles etc, and then you can easily fix problems for ALL users...

ALSO... dee u offered help for you above...

Quote:

---

Originally Posted by Code Doc

That's because the users who encountered the error are in Sinagpore and Taiwan and I cannot reproduce it with my computer.

---

Indeed, and that is an extremely good reason to use ERL - in fact, I would say it makes it virtually mandatory.

Quote:

---

And, the code they are using does not have line numbers included.

---

..so add the line numbers and ERL, and give them the new version.

Unicode aware App.Path:

Code:

---

Option Explicit

Private Declare Function GetModuleFileNameW Lib "kernel32" (ByVal hModule As Long, lpFileName As Any, ByVal nSize As Long) As Long

Public Function AppPath() As String
    Dim bytAppPath(1025) As Byte, lngLen As Long
    lngLen = GetModuleFileNameW(0, bytAppPath(0), 1024)
    If lngLen > 0 Then AppPath = Left$(bytAppPath, lngLen)
End Function

---

Merri, where have you been hiding? I needed you all this week and last week.

Check out my other thread on Asian vs. USA Computers. We've been in deep 6 or should I say Unicode 6. :afrog:

Anyway, I found out that VB6 can read the AppPath and the AppDataPath on Asian computers using standard VB6 functions. What blows up is reading files with embedded audio and video images when opened for binary. If you have time, take a look:
http://www.vbforums.com/showthread.php?t=586653