Post by MayayanaAs Garry asked, what are the problems?
The only showstopper I know of is 64-bit.
I have an Explorer Bar I can't install on
Win64 because it runs in the Explorer process.
And security can be a bit of a headache. Aside
from that I haven't had problems. VB6 is still one
of the most widely compatible off all tools, running
on virtually all current Windows systems with no
added support files necessary.
OK. Here goes :)
I've written a number of programs that access data on other computers on our network.
Whenever one of my VB6 programs, running on a Win 7 machine, reads any file on another Win 7 machine, that file is, for some reason, "locked" for a very long time after the file has already been read.
This interferes with other programs reading or writing those files in a timely manner.
Since the purpose of these programs is to gather data continuously, and then allow that data to be accessed and displayed by other programs on various workstations in the system, this extended "lock time" is a serious problem.
It seems to take several minutes for a file that's been read by one of the Win 7 machines to become accessible again to to other machines on the network.
However, when I run these same VB6 programs on an XP machine, their reading of these same files, off of the same win 7 machine, DOESN'T cause the files to be locked for any period of time that I can see (just as we'd hope for).
So we can't run these programs on any win 7 machines without losing data due to the files being locked out for access by other machines for this excessive amount of time. Thus, I figure the VB6 file reading methods must interact badly with win 7 machines somehow. It's all very frustrating because it all works great when the "reading" machine is a win XP unit, but not when the "reading" machine is running Win 7.
There are some other issues as well, but that's just a start.
I keep thinking that if I used a different language, that was new and fully-supported, I wouldn't run into this.