This is an example of how you can use very simple worker threads in VB6 without an ActiveX EXE or a third party threading library. There are severe limitations on what you can accomplish this way, but enough to still make the technique useful:
I am trying to have my program check is a mapped network drive is actually connected, and change the curDrive variable based on the result. It works okay, but if the drive is still mapped and the drive is not available, there is a long delay while the program tries to connect (4-6 seconds). I tried two methods and both ways have this delay.
This Demo program shows one way to deal with this by having a UserControl call GetFileAttributes() on a worker thread and use a Timer control to poll for eventual completion. The same technique can be used for other long running API calls. For example doing drive mapping within your program by calling WNetUseConnection().
The key is to avoid anything that requires COM, thread-local storage, and other VB environmental factors to be initialized. This radically limits the statements you can use, rules out VB exception handling, method calls, and so on.
One way to accomplish the task at hand might be to use VB's GetAttr() function. However that is only helpful if we could use error handling since what we want here is to detect success or failure and not the attributes themselves.
So this takes us to directly calling the GetFileAttributes() API. A solution, however calls to entrypoints defined using VB Declare statements requires the use of infrastructure that is not available to simple worker threads.
We can avoid this by defining the API call in the type library GetFileAttributes.tlb we reference in our program. The ODL source is also provided here and can be recompiled if necessary using the MIDL compiler from a Windows SDK.
Third party threading libraries would let us do more by creating new COM Apartments we can run code in. However for simple tasks like this we can get along without them, since sadly they are seldom made available in "thin and lightweight" DLLs. Those that I can think of all tend to wrap a ton of things into one giant DLL. Not that these other things aren't useful, but usually you just don't need them.
This technique avoids any additional runtime dependencies at all.
To test from within the VB6 IDE, which should always be run with full administrative privileges (i.e. elevated), you will need to set up drive mapping in that context. While this didn't matter in the old pre-Vista days things have changed and drive mappings exist separately for each user context (elevated and standard).
So I am including another Project (MapTemp) which you should compile first. Run MapTemp.exe elevated (right-click "Run as administrator"). Here you can provide a file share and credentials and it will temporarily map the share to an available drive letter which it will report to you.
![Name: sshot1.png
Views: 116
Size: 10.3 KB]()
Note that it does this on the UI thread, and in some cases it will take long enough that MapTemp becomes "unresponsive." Just wait it out, but this does show exactly the sort of thing that has been addressed within the drive query Demo!
Now you can test the Demo.vbp drive query Project from within the elevated IDE. After testing, either click the Unmap button or just close MapTemp and it will eliminate the temporary mapping.
![Name: sshot2.png
Views: 75
Size: 7.8 KB]()
A more "realistic" test is to compile the Demo, do a persistant drive mapping via Explorer, etc. and then reboot. When the system comes back up go ahead and run Demo without elevation, and enter the drive letter you mapped. This way you'll see more delay and the Demo's UI should remain responsive (drag it around on the screen, etc.).
Quote:
I am trying to have my program check is a mapped network drive is actually connected, and change the curDrive variable based on the result. It works okay, but if the drive is still mapped and the drive is not available, there is a long delay while the program tries to connect (4-6 seconds). I tried two methods and both ways have this delay.
This Demo program shows one way to deal with this by having a UserControl call GetFileAttributes() on a worker thread and use a Timer control to poll for eventual completion. The same technique can be used for other long running API calls. For example doing drive mapping within your program by calling WNetUseConnection().
The key is to avoid anything that requires COM, thread-local storage, and other VB environmental factors to be initialized. This radically limits the statements you can use, rules out VB exception handling, method calls, and so on.
One way to accomplish the task at hand might be to use VB's GetAttr() function. However that is only helpful if we could use error handling since what we want here is to detect success or failure and not the attributes themselves.
So this takes us to directly calling the GetFileAttributes() API. A solution, however calls to entrypoints defined using VB Declare statements requires the use of infrastructure that is not available to simple worker threads.
We can avoid this by defining the API call in the type library GetFileAttributes.tlb we reference in our program. The ODL source is also provided here and can be recompiled if necessary using the MIDL compiler from a Windows SDK.
Code:
[
uuid(D03ED253-E130-4f20-A145-A5AE627A0875),
helpstring("Kernel32 Query Subset Type Library")
]
library Kernel32Subset
{
[
helpstring("Some queries."),
dllname("Kernel32")
]
module Queries
{
[
helpstring("Retrieve file system attributes for a specified file or directory."),
entry("GetFileAttributesW")
]
long int _stdcall GetFileAttributes([in] long int lpFileName);
};
};Third party threading libraries would let us do more by creating new COM Apartments we can run code in. However for simple tasks like this we can get along without them, since sadly they are seldom made available in "thin and lightweight" DLLs. Those that I can think of all tend to wrap a ton of things into one giant DLL. Not that these other things aren't useful, but usually you just don't need them.
This technique avoids any additional runtime dependencies at all.
To test from within the VB6 IDE, which should always be run with full administrative privileges (i.e. elevated), you will need to set up drive mapping in that context. While this didn't matter in the old pre-Vista days things have changed and drive mappings exist separately for each user context (elevated and standard).
So I am including another Project (MapTemp) which you should compile first. Run MapTemp.exe elevated (right-click "Run as administrator"). Here you can provide a file share and credentials and it will temporarily map the share to an available drive letter which it will report to you.
Note that it does this on the UI thread, and in some cases it will take long enough that MapTemp becomes "unresponsive." Just wait it out, but this does show exactly the sort of thing that has been addressed within the drive query Demo!
Now you can test the Demo.vbp drive query Project from within the elevated IDE. After testing, either click the Unmap button or just close MapTemp and it will eliminate the temporary mapping.
A more "realistic" test is to compile the Demo, do a persistant drive mapping via Explorer, etc. and then reboot. When the system comes back up go ahead and run Demo without elevation, and enter the drive letter you mapped. This way you'll see more delay and the Demo's UI should remain responsive (drag it around on the screen, etc.).