#Shell (x$, 3) Fixed
5 messages in this thread
Well, you have certainly isolated an interesting gremlin.
However, programming around the gremlin gets us back to the original
problem of not being able to get multiple shells to DOS to work.
Take your example and add the following line to Command1_Click:
MsgBox "Done"
This has the effect of moving the cursor off the button, and thus
preventing the UAE. In the Enhanced mode, it also has the effect of pausing
VB/Windows long enough for one shell in a loop to finish before the next
one starts, which is the effect we are looking for.
But now trying the following in Command1_Click:
For i = 1 to 5
s% = Shell("c:\command.com /c dir c:\*.*", 1)
MsgBox Str$(i) + " done."
Next
When it gets to the "Next" in the first loop, you get an "Illegal function
call". Somebody tell me we're not talking major bugs here!
There is 1 Reply.
Hi Nelson,
I tried the code you sent. The For loop with the MsgBox statement in it
caused a UAE rather than an illegal function call. Not that that's a big
improvement.<g> However, adding an x% = DoEvents() after the Shell made the
UAE go away.
But your code did get me one step further in the search. Here are may
latest and probably finally findings since I've gone as far as my knowledge
can take me.
Whether a UAE occurs depends on the location of the cursor from the time
the Shell command begins until it has finished and the program has
*completely* returned to VB. If the cursor is over a form, a picture box, a
label, list box, directory box or a file box, NO UAE occurs. These controls
don't even have to be on the same form! On the other hand, a UAE *will*
occur if the mouse cursor is over a frame, text box, any kind of combo box,
a drive box, scrollbars, an option button or check box. The only common
feature I can find is this. With the SDK SPY program, when you are
selecting a window to monitor, as you move from window to window, Spy shows
you information about the window you are pointing at. The last line of this
display shows the window's 'style bits'. For all controls that cause UAE's,
the third from the left digit in the style bits is always ZERO. For the
controls that don't cause UAE's, the third digit is never zero.
Unfortunately, I don't know how to decode these style bits.
Well that's it. I don't know what else to do to track this problem down.
KeithF
This is really strange. Obviously I didn't get a UAE when I ran the code I
sent you, or I wouldn't have sent it to you.
Everyone who was involved with analyzing the problem seems to have given
up, so now it's up to MS. Unfortunately, I reported this to MS months ago,
and nothing has come of it yet.
Meanwhile, I continue to get tech calls from customers wondering why *I*
write such buggy software. <sigh>
There are 2 Replies.
Hi Nelson,
Sorry, what I should have said was that the For loop that gave you an
illegal function call gave me a UAE. The For loop that worked for you, also
worked for me.
Anyway, I've found a really ugly work around that works on my machine. I
hope it works on yours also.
Sub Command1_Click ()
For i% = 1 To 10
s% = Shell("command.com /c dir c:\*.*", 1)
x% = DoEvents()
Command1.Visible = 0
x% = DoEvents()
Command1.Visible = -1
Next i%
End Sub
An alternative that also works, but which is equally ugly is to use the API
SetCursorPos function to move the cursor off the Command1 button onto the
form and then back again.
Sorry, but that's the best I can come up with.
KeithF
Hi Nelson,
As you've probably read in other messages, I'm trying to pull as much info
together as possible to send to MS. Do you have the MS diagnostic program
MSD? If so, could you send me an MSD printout of your computer? Also, a Dr.
Watson log if that is possible. Thanks for your help.
KeithF