#Shell (x$, 3) Fixed
17 messages in this thread
Keith,
Thanks for perpetuating this confusion <g>. So, it appears that pointers
might be going astray here. I wonder if it's worth letting a Sub outside
of Command1_Click take care of the Shell, e.g.
Sub DoIt()
s% = Shell("c:\command.com /c dir c:\ >> c:\testshel", 1) End Sub
Sub Command1_Click ()
DoIt End Sub
It may be worth the try. Ah… I love the smell of bug hunting in the
morning.
Costas
There is 1 Reply.
Hi Costas,
Putting the code into a sub was one of the early things that I tried in my
experiments. I tried putting the sub in the same form, a different form and
even in a module on its own. No luck. But it was a good idea and thanks for
mentioning it.
I'm going to have to give up on this problem, I'm totally exasperated. I've
done everything I can think of. My AutoExec and Config files are bare bones
– no TSR or device drivers other than HIMEM.SYS. I've turned off my
computer's Shadow Ram and Caching. Win3 is in virtually 'out of the box'
condition as I only have one Win3 App, namely VB. I've ran my computer at
different clock speeds. The only thing that works is to disable my 80387.
It must be some sort of obscure hardware problem.
The worrysome thing for you developers is that you now know that atleast
two computers in the world will crash if you use multiple Shells to DOS
Apps.
Electrons 1, Humans 0. I hate to admit defeat, but the Critters dun
outsmarted me this time.<g>
KeithF
Keith,
Thanks for trying. If it's any consollation I'm thinking of throwing in
the towel as well. I'll try one last thing: to create a batch file on the
fly with the necessary commands which will eliminate the "FOR … NEXT"
loop.
Costas
There is 1 Reply.
Hi Costas,
Well I found an ugly work around that works on my machine. Please see my
message to Nelson for details.
KeithF
There is 1 Reply.
Thanks, Keith. I'll take a look at it.
Costas
There are 3 Replies.
Hi Costas,
A couple of things, if you have a moment, please.
It seems pretty clear we aren't going to be able to solve this problem
without some help from MS. Unfortunately, they can't reproduce the problem,
so the best we can do to help them is send as much info as possible.
Since you have a machine on which the programs work, it might be useful to
include some info about your machine. Do you have the MS program MSD.EXE
that comes with Dr. Watson? If you do, could you EMail me a copy of the
report that it generates for your machine?
Second, and this is bad news. You mentioned creating a batch program to
avoid making multiple calls to Shell as a solution to the problem. This
unfortunately won't work. A click event that only makes a single call to
Shell will still cause a UAE if I click the button again without first
moving my mouse cursor off the command button.
I imagine you saw my note to Don in which I mentioned that the problem in
fact is not related to the VB Shell command as it also occurs if I use the
WinExec command instead.
Thanks for your help.
KeithF
Hi Costas and Nelson,
Damn, I think I've been on the trail of the Great Red Herring for 3 days.
Stop the presses! Don't go to any trouble to send me info about your
systems. I'm back to square one.
As I've experimented with this problem, I've become more and more conviced
that it had something to do with the location of the mouse cursor during
the Shell command. My latest experiment totally trashed this idea. The
following code creates an 'illegal function call' no matter where I place
my mouse cursor.
Sub Command1_Click ()
x% = Shell("c:\command.com /c dir c:\*.*", 1)
x% = DoEvents()
a = 27 '<= creates illegal function call.
End Sub
Now for the 'zinger'. If I change "a = 27" to "a% = 27", I don't get an
illegal function call even if I leave the mouse cursor on Cammand1. So now
I'm off on another wild goose chase. But this one is going to be very
short, like it has already ended! My guess is that maths that use real
numbers make calls to the math-co or to WIN87EM whereas integer maths do
not. Since the UAE's I've been getting involve WIN87EM.DLL and *only* occur
when I have my math-co enabled in Standard mode, I'm now thinking that the
problem may be some wierd conflict between my math-co and the emulation
library. [more]
[continued]
What I would like to know from MS (Don are you listening?) is why WIN87EM
enters into the equation at all on a computer that *HAS* a math-co???
Maybe if we can get an answer to that question, it will lead us to a
solution of this problem.
CONCLUSION: To anyone reading this message. If you use the Shell command to
access a DOS program, please be advised that isolated and potentially
unsolvable problems might occur. The problems do not seem to be directly
related to the Shell command or the DoEvents command, but rather something
in VB, or possibly, but unlikely in Win3, that just doesn't work on a few
386 computers with math-coprocessors that are running in Standard mode.
Well that's my best shot and I'm afraid it missed the target by a wide
margin.
KeithF
There is 1 Reply.
Keith:
Wow! I've been following this thing, and HOPING that it had a rational
explanation, but your latest results are kind of depressing. I hope you
didn't spend so much time tracking this down that you've decided to
drop the forum again! <g> Anyway, thanks for persevering.
There is 1 Reply.
Hi Keith,
<<…that you've decided to drop the forum again.>>
Not at all. It was a great hunt and I learned a lot, although I agree that
the current situation is depressing. On the bright side, we have eliminated
some of the of possible causes. DoEvents is definitely not the culprit. The
VB code that implements Shell is not the problem because WinExec causes the
same problem. So the hunt has not been a total waste of time.
I'll do a report for Don and maybe MS will be able to deduce the cause of
the problem even if they can't reproduce it.
KeithF
There are 2 Replies.
Keith,
You've been discovering some rather bizarre behaviors. My favorite though
is the a = 27 causing an Illegal Function Call. BTW, this doesn't happen
on my system even if I double click on Command1. I noticed in your example
code you used x% twice, for the Shell and DoEvents. This is probably a
silly question but do you get an Illegal Function Call if you use a
different variable? The reason I'm bringing this up is because Shell seems
to return the handle to the module whereas DoEvents returns the number of
VB forms loaded. So if the compiler is doing something weird behind the
scenes, it's setting up x% as: "HANDLE x%; INT x%" Windows or VB could be
confusing things. But this is probably a silly thought.
As far as WinExec goes, I think Shell calls WinExec anyway. We know it
doesn't call LoadModule since the call would be different. It may be worth
trying LoadModule though.
Costas
There is 1 Reply.
Hi Costas,
Well Ted found the perfect work around to the shell problem. Just disable
the command button while the shell command is executing.
I found another work around that I thought I'd mention so you can add it to
the collection of bizarre VB behaviors.
Command1_Click()
'''On Error Resume Next
For i% = 1 To 5
x% = Shell("c:\command.com /c dir c:\*.*",1)
y% = DoEvents()
'''a! = 1
Next i%
End Sub
The above code causes a UAE. But if you uncomment the a! = 1 statement, you
get an illegal function call at that line. BUT, if you uncomment the On
Error Resume Next, the illegal function call is bypassed *AND* the UAE's
don't occur either! Isn't that a hole in the boat!<g>
So now I guess I can get back to looking at the new AutoCAD QuickBASIC
Interface.
KeithF
There is 1 Reply.
Keith,
Why do I suddenly miss DOS? <g> Of course, when I tried your code it
didn't cause any UAEs or Illegal Function Calls. I have a feeling that
everything points to the math-co. I'll download Ted's code since that does
the trick. Like Ted though, I have no idea either why disabling the command
button works.
Costas
Keith,
First of all, many thanks for taking the time to track down the details to
this inscrutable problem. Second, have you tried using ON ERROR to recover
from the illegal function call error? Somehow I think it would cause a
UAE, simply because it *wouldn't* make any sense to cause a UAE. <g>
I finally got my math-coprocessor, but right now I can't fool around with
anything on my machine (being on a serious deadline means I have to make
sure that I don't mess with ANYTHING for fear that I'll lose a day) to see
if I'd start getting the same problems.
– Ted
There are 2 Replies.
Hi Ted,
Please see my message to Costas concerning On Error. It was discovering
this work around that made we download your test program to see if it would
work with it. I was totally blown over when I discovered that your test
program worked! Sure enough, by commenting out the line Command1.Enabled =
0, I got the good old UAE and by leaving the line in, the UAE went away.
As to WHY the problem occurs, MS is going to have to figure that out. I
sure hope they give my report to someone who is a fan of Sherlock Holmes
because that's the approach he will have to take.<g>
KeithF
Ted,
For the record, I tried your SHELL version and it worked for me in both
Standard and Enhanced modes.
Costas
There is 1 Reply.
Costas,
Thanks. I've got Keith F. testing something else with Shell (a "real"
application), so we'll see how that goes.
– Ted
There is 1 Reply.