A97 code causes keyboard loss

[MLH]

Running the following code produces NO error, but renders
my keyboard incapable of typing. I can use the mouse to
open the class module & look at it. But if I try to type in it -
nothing happens. I can open other apps with the mouse
and type in them, but I have to close the open database
and reopen before Access will let me resume typing.

10 Dim i As Integer, Msg As String, RetVal
20 On Error Resume Next
30 DoEvents
40 Kill ("c:\windows\IP data.sys")
50 On Error GoTo Err006
60 RetVal = Shell("c:\windo ws\system32\cmd .exe,0")
70 SendKeys "ipconfig /all > c:\MyDir\IPdata .sys~", True
80 SendKeys "exit~", True
90 AppActivate "Microsoft Access"
95 Exit Sub

[MLH]

Running just the following locks my keyboard hopelessly.
Ideas?

Private Sub Command0_Click( )
Dim i As Variant
i = DoEvents

End Sub

[MLH]

Sorry, problem went away with a reboot.
Dunno what was happening. Wouldn't
have bothered you all if I had known it
was a glitch.

pls excuxe

[Trevor Best]

MLH wrote:

Sorry, problem went away with a reboot.
Dunno what was happening. Wouldn't
have bothered you all if I had known it
was a glitch.

pls excuxe

Nevertheless you shouldn't use SendKeys like that, there's no guarantee
those keystrokes will go to the application you want them to. Shell out
the command you want to or if it's an internal dos command then use
Shell Environ("COMPSE C") & " /C <command>" as that will give you the
command interpreter for whatever system you're on, be it command.com,
4dos.com, ndos.com or cmd.exe, etc.

If you require more than one command then put them in a batch file and
shell to that.

I used to insert error trapping code using Sendkeys in Access 2.0 (later
versions have a module object) and I tried the same thing in VB once,
the copying and pasting of procedure names (done using highlighting)
went into Explorer once instead of my app, made a right mess of my files.

--
[OO=00=OO]

[MLH]

So, replace this line #60
60 RetVal = Shell("c:\windo ws\system32\cmd .exe,0")
using the one listed below?

10 Dim i As Integer, Msg As String, RetVal
20 On Error Resume Next
30 DoEvents
40 Kill ("c:\windows\IP data.sys")
50 On Error GoTo Err006
60 Shell Environ("COMPSE C") & " /C ipconfig /all > c:\MyDir\IPdata .sys"
90 AppActivate "Microsoft Access"
95 Exit Sub
I'll have a go at it.
xxxxxxxxxxxxxxx xxxxxxxxxxxxxxx xxxxxxxxx

Nevertheless you shouldn't use SendKeys like that, there's no guarantee
those keystrokes will go to the application you want them to. Shell out
the command you want to or if it's an internal dos command then use
Shell Environ("COMPSE C") & " /C <command>" as that will give you the
command interpreter for whatever system you're on, be it command.com,
4dos.com, ndos.com or cmd.exe, etc.

If you require more than one command then put them in a batch file and
shell to that.

I used to insert error trapping code using Sendkeys in Access 2.0 (later
versions have a module object) and I tried the same thing in VB once,
the copying and pasting of procedure names (done using highlighting)
went into Explorer once instead of my app, made a right mess of my files.

Bummer - I'm sure that's an experience you'll have a hard time
forgetting.

[MLH]

Running the following gave me runtime error #53,
File Not Found on line #60...
C:\MyDir does exist.
Private Sub Command0_Click( )
10 Dim i As Integer, Msg As String, RetVal
30 DoEvents
60 Shell Environ("COMPSE C") & " /C ipconfig /all >
c:\MyDir\IPdata .sys"
DoEvents

End Sub

[Trevor Best]

MLH wrote:

Running the following gave me runtime error #53,
File Not Found on line #60...
C:\MyDir does exist.
Private Sub Command0_Click( )
10 Dim i As Integer, Msg As String, RetVal
30 DoEvents
60 Shell Environ("COMPSE C") & " /C ipconfig /all >
c:\MyDir\IPdata .sys"
DoEvents

End Sub

COMSPEC, not COMPSEC :-)

--
[OO=00=OO]

[MLH]

I thought that might be it. Before I made the post,
I checked A97 help. Point of Fact: There ain't
none for "Shell Environ". Only after I made the
post did I realize that Shell and Environ were 2
separate commands. How do we get away with the Shell
command not having its argument(s) enclosed in (parentheses)?

BTW, the thing works now. Reading help on Shell though,
I'm still wondering if I may find myself in a race condition
sometime - having commands after the Shell command that
expect the file to be there trying to open it before DOS is
finished doing its job. I have stuck a DoEvents line in there
after the Shell line. And I suppose I could loop between
Dir / sleep / Dir / sleep until the file was there. Hasn't been
a problem yet though.

COMSPEC, not COMPSEC :-)

[David W. Fenton]

MLH <CR**@NorthStat e.net> wrote in
news:aj******** *************** *********@4ax.c om:

I thought that might be it. Before I made the post,
I checked A97 help. Point of Fact: There ain't
none for "Shell Environ". Only after I made the
post did I realize that Shell and Environ were 2
separate commands. How do we get away with the Shell
command not having its argument(s) enclosed in (parentheses)?
Shell() is a function, which returns a value.

But if you aren't using the return value, it can be called as a
command, without the parentheses, just like any other command.

This is garden-variety VBA, not something specific to Shell().

I make a practice of never just using these commands baldly, but
instead use Call:

Call Shell ([whatever])

That forces the use of the parens, and then you no longer see any
apparent inconsistency.
BTW, the thing works now. Reading help on Shell though,
I'm still wondering if I may find myself in a race condition
sometime - having commands after the Shell command that
expect the file to be there trying to open it before DOS is
finished doing its job. I have stuck a DoEvents line in there
after the Shell line. And I suppose I could loop between
Dir / sleep / Dir / sleep until the file was there. Hasn't been
a problem yet though.

I have found that it is just better to have Shell() call a batch
file, since all the commands within the batch file will execute
sequentially.

If you need to do something in VBA *after* the Shell() command
finishes, then you have to use ShellAndWait, or some other form of
looping that pauses execution until the Shell instance closes.

But, looking at the bigger picture, excessive reliance of Shell()
suggest to me that you've designed your app incorrectly. Shell()
should be used exceedingly sparingly, and only for those things that
you cannot use VBA code for (which are very few).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[MLH]

Good advice.