Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Windows ME & Visual Basic 3.0
- Thread starter FireAngel
- Start date
Guest_imported
New member
- Jan 1, 1970
- 0
Upgrade your edition of vb. vb3 was made to design apps on windows 3.1 so it's not surprising that it's not compatible with this much higher version of windows. Microsoft is now offering a free download of vb five control creater edition on their site. It's worth checking out if you can't afford vb six.
petermeachem
Programmer
I have customers running vb3 programmes on most versions of win98 and nt. No problems at all. Why should there be any? Peter Meachem
peter@accuflight.com
peter@accuflight.com
Hi guys
some days ago I was asking the exact same thing( I'm lesina).
I was working with VB3 and VB4 (16 bits) and i was not having very sucess.
Now, i know differently.
There are no compatibility problems but since i was working with a pre-historic VB version i had some licence problems that had nothing to do with incompatibilities with the O.S. i was using.
With those problems, i could do nothing and the errors i got were a true cascate.The problem was that i couldn't find out what was the main error that caused the others.
Then, i found out (with other programmers help)that the problem was all about licences.
After getting the .lic files i needed, i had no more things to worry about..except doing the rest of the work...
So, here is the answer you all need. It has nothing to do with the OS.
Marta Oliveira [mio@cpcis.pt]
Porto - Portugal
some days ago I was asking the exact same thing( I'm lesina).
I was working with VB3 and VB4 (16 bits) and i was not having very sucess.
Now, i know differently.
There are no compatibility problems but since i was working with a pre-historic VB version i had some licence problems that had nothing to do with incompatibilities with the O.S. i was using.
With those problems, i could do nothing and the errors i got were a true cascate.The problem was that i couldn't find out what was the main error that caused the others.
Then, i found out (with other programmers help)that the problem was all about licences.
After getting the .lic files i needed, i had no more things to worry about..except doing the rest of the work...
So, here is the answer you all need. It has nothing to do with the OS.
Marta Oliveira [mio@cpcis.pt]
Porto - Portugal
petermeachem
Programmer
This forum seems to consist largely of people asking whether vb3 works on this and that ms os. I cannot think of any reason for vb3 not to work. Dos programmes perhaps, but not vb3. Actually, I think there are fewer problems running vb3 than vb6. Peter Meachem
peter@accuflight.com
peter@accuflight.com
TO petermeachem:
I believe the real set back of VB3 in anything higher than win 3.11 is the nonsupport for long filenames. Otherwise, I, too, do believe there should be no problems running VB3. "The world shrinks more and more with every new user online."
I believe the real set back of VB3 in anything higher than win 3.11 is the nonsupport for long filenames. Otherwise, I, too, do believe there should be no problems running VB3. "The world shrinks more and more with every new user online."
petermeachem
Programmer
Thats true. Plus little things like creating a desktop shortcut in setup. Aside from that...
I once did a test to see how fast different programmes could access a database. I don't know how valid the results were, but vb3 with access 2 was fastest, followed by vb5 and access 97, with access 97 by itself bringing up the rear. The times were quite substantially different too, not just a few percent. Peter Meachem
peter@accuflight.com
I once did a test to see how fast different programmes could access a database. I don't know how valid the results were, but vb3 with access 2 was fastest, followed by vb5 and access 97, with access 97 by itself bringing up the rear. The times were quite substantially different too, not just a few percent. Peter Meachem
peter@accuflight.com
I personally have tested VB 3 in Win 3.1, Win '95, Win 98, and Windows 2000 professional, which is essiantialy NT 5.0. VB 3 works flawlessly with ALL these operating systems. As for long file names, no VB 3 program should have long file names in it anyways. Those operating systems that do support long filenames, also maintain a working DOS (8.3) equivelant name.
For excample, don't write a VB program that might access "C:\Program Files". VB 3 could not do this even if it were runnning on Win 95/98/NT systems! Instead, specify it's 8.3 equivelant. While it would normally be "C:\progra~1" for this example, this may not be the case on a computer that the program migh end up on. I therefore suggest writing a routine that would determine the OS of the host machine and take the appropriate steps to determine the "8.3" name of the target directory or file.
A "crude", but effective example on how one might do this is to issue a dos SHELL command from within the VB program that calls "ver >osver". This would put the OS version in a file called "osver" and the program could then read that file to determin what OS it is using.
Once the OS is determined, and it is discovered to be a OS that uses long file names, you could then use another SHELL call to do a "DIR >dirlist" to output the directory list to a file and then write a routine to read in the data listing while "stripping" the needed information from the file.
For example, in Windows 95/98/ME systems, the normal "DIR >dirlist" would be sufficient. below is a sample output line one might get in the file when obtaining a DIR listing of "C:\"
-----------------------------------------------------------
PROGRA~1 <DIR> 11-05-00 Program Files
-----------------------------------------------------------
The first 15 characters could be stripped as the name to use, while the right section of the line would be the long filename equivelant
In Windows 2000, similiar results could be obtained by using the "DIR /X >dirlist" syntax.
For excample, don't write a VB program that might access "C:\Program Files". VB 3 could not do this even if it were runnning on Win 95/98/NT systems! Instead, specify it's 8.3 equivelant. While it would normally be "C:\progra~1" for this example, this may not be the case on a computer that the program migh end up on. I therefore suggest writing a routine that would determine the OS of the host machine and take the appropriate steps to determine the "8.3" name of the target directory or file.
A "crude", but effective example on how one might do this is to issue a dos SHELL command from within the VB program that calls "ver >osver". This would put the OS version in a file called "osver" and the program could then read that file to determin what OS it is using.
Once the OS is determined, and it is discovered to be a OS that uses long file names, you could then use another SHELL call to do a "DIR >dirlist" to output the directory list to a file and then write a routine to read in the data listing while "stripping" the needed information from the file.
For example, in Windows 95/98/ME systems, the normal "DIR >dirlist" would be sufficient. below is a sample output line one might get in the file when obtaining a DIR listing of "C:\"
-----------------------------------------------------------
PROGRA~1 <DIR> 11-05-00 Program Files
-----------------------------------------------------------
The first 15 characters could be stripped as the name to use, while the right section of the line would be the long filename equivelant
In Windows 2000, similiar results could be obtained by using the "DIR /X >dirlist" syntax.
I have never had any problems based on any version through VBDOS on ANY OS, but like accoding to his post dealing with the fact that you can just run "DIR >DIRFILE" or "DIR /X>DIRFILE" and that's solved, but a really neat routine I found in a for dummies book would make it easier. Try this:
"DIR *.* /A /S (/X)>DIRLIST.TX_"
now to get the correct file name do this:
"FIND "FILENAME.EXT"<DIRLIST.TX_"
I usually get a line with the filename (first 12 chars) or "Directory of "and then the directory listing. This should also save SOME cpu time.
PS: If you were looking for a file, you wouldn't need the whole long file name listing, just the first 12. The user should also know that your program does not use long file names anyways (always worked for me).
"DIR *.* /A /S (/X)>DIRLIST.TX_"
now to get the correct file name do this:
"FIND "FILENAME.EXT"<DIRLIST.TX_"
I usually get a line with the filename (first 12 chars) or "Directory of "and then the directory listing. This should also save SOME cpu time.
PS: If you were looking for a file, you wouldn't need the whole long file name listing, just the first 12. The user should also know that your program does not use long file names anyways (always worked for me).
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
