App.Path problem

[SBerthold]

i have two folders on the same level, with two different VB projects, all on the same partition.

One folder is called - E:\6.5.0\1SourceCode
The other is called - E:\7.0.0\1SourceCode
Using App.Path from each program while in the IDE, I get for the first one the correct path name as posted above.
But for the second one I get:

E:\707184~1.0\1SOURC~2

And this is not recognised by FSO or DIR().

Anyone know why? And how to correct?

I am afraid that if this is some VB flaw, then correcting it on my system may work, but what is to prevent this from happening on other systems?

Using WinNT SP6, VB6 SP5

 

[vb5prgrmr]

SammyB,

I find it hard to believe (oops talking about ms). Is this perhaps the same project name just two different versions in different directories? I have never had a problem with app.path on 95/NT4/Win2KPro/Win2K Server/Win2K Advanced Server, but then again there is a first time for everything (knocking on wood loudly). Only thing I can suggest is to open up each project and F8 each one time and type in the immediate window ?app.Path and see what you get at the first line of code for each program and see if that is what it is supposed to be. If it is then you may corrupt your variable in some way or you may have a memory leak somewhere in your program. Which makes me wonder if you have any recursion going on or are using ado as a data access method. Presently don't know what else to tell you.

Good Luck

 

[SBerthold]

These are two seperate projects in two seperate directories.

The incorrect value the App.Path returned was returned in the immediate window when the program was NOT running and when it WAS running, as well as when set to variables or a message box.

I have also never seen this before.

Maybe there is something with the system?

Thanks for your help!

 

[MiggyD]

I've never seen that happen in VB6 either. However...

I have seen that sort of return when I used a prog. created in vb4(16) and later compiled it with vb4(32bit).

You may want to look at the raw source code and compare the VBP headers and such. That's my only suggestion.

 

[CajunCenturion]

An interesting problem. I would wonder if something is amiss in the FAT, perhaps some confustion in the long and short filenames.

You might want to try to do the following:

Create a new directory. Then copy all of the information into the new directory. Delete the original directory. Then rename the new directory to the proper name.

If it is a FAT problem, this might clear it up. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein