Hi!
A page that sums up/explains the different "variations" of this behavior is a good thing for new and old users alike.
A very useful reference.
But, I'm gonna go out on a limb here and probably become very unpopular in the process.
My thoughts:
1. This is not a QAP problem
This is a problem with unavailable or unreliable network resources.
In my VMware lab QAP itself is not even installed locally, but runs from a network drive. There are never any problems as long as the file server is up and running.
2. Complex error handling
Implementing some complex error handling to compensate for the normal delay/timeout of the operating system and an unknown number of variations where this delay can possibly occur? It just seems counter intuitive to me. Some simple and fast error check, and a big "red button" in QAP settings that says "disable network support" is imho the way to go.
....or possibly only the red button! QAP behaves as expected when there is a timeout/delay in the "subsystem" (the OS).
I use a metric ton of applications, tools and utilities, from typical end-user applications to command line tools.
All of them can connect to or use network resources in one shape or another, and ALL of them are affected by a delay when an expected network resource is unavailable.
Try running (s)ftp or ssh and try to connect to an online host that doesn't run a ftp or ssh server, you get a timeout, as expected.
Try running a logon script that tries to connect to non-existent network drives, you get a timeout.
Tools, applications and systems designed to operate under high latency or unstable network conditions is another ball game entirely.
3. Number of users affected
How many of the total number of QAP-users are really affected by this?
Or is this just a question of easily available information as linked to in the original post here?
Unmounting/disconnecting offline network drives makes this whole thing a non-issue.
4. The Exception - The Drives function
The Drives-function is maybe the only exception as it demonstrably goes nuts when network drives that are mapped by the operating system are offline.
That function should probably be fixed, ie the constant triggering.
But removing the delay? Maybe not, this is an error condition after all. Unmounting the drives solves this.
Just my $0.02, and a long rant (sorry about that).
I'll now put on my crash helmet and wait for the storm!
Regards,
joeNOR