[RESOLVED] Can't capture the ESC key

[ragkag]

I have a For loop that shells to another program and waits for it to complete. I then write a line to a listbox that is defined on a form called frmMain. frmMain is displayed non-modally prior to the For loop. I also have a listbox on the form and one command button with its Cancel property set to True. In the command button's code, there is one line of code that exists the program. My problem is when the For loop is running pressing the ESC key does nothing. It doesn't even get to the command button's code. But If I click the command button itself, it does execute the command button's code. I thought Doevents would enable the ESC key to be captured but that is not the case. Hope this makes sense.

Below is the simplified code.


frmMain.show

for Ndx=1 to 100
Result=get_shell_text "program" 'This waits for completion
frmMain.listbox.additem "blah blah blah"
doevents
next ndx

end

[baka]

the "waits" for another program could freeze it up. no matter if u have a doevents after it.
during that time it will not respond. u need to set the waiting differently, like asynchronously.

[ragkag]

the "waits" for another program could freeze it up. no matter if u have a doevents after it.
during that time it will not respond. u need to set the waiting differently, like asynchronously.

If that is the case, why does clicking the command button work where as pressing the ESC key (which has the property "Cancel" set) to True not work?

[SwampeastMike]

If that is the case, why does clicking the command button work where as pressing the ESC key (which has the property "Cancel" set) to True not work?

Because your keypresses are not being directed to your program to go somewhere else including computer "never-never land" where they seem to evaporate. Shelling to an outside program from VB is one of the surest ways to encounter this and other problems like non-responding progress bars, messages, etc. as your screen fades and goes non-responsive.

Are you using the SHELL command? If so, you can gain at least limited control using the ShellExecuteEx API. It's one of the easiest to use and I am no fan of many API functions. Actual communication between VB and a shelled, running program are impossible.

[ragkag]

Because your keypresses are not being directed to your program to go somewhere else including computer "never-never land" where they seem to evaporate. Shelling to an outside program from VB is one of the surest ways to encounter this and other problems like non-responding progress bars, messages, etc. as your screen fades and goes non-responsive.

Are you using the SHELL command? If so, you can gain at least limited control using the ShellExecuteEx API. It's one of the easiest to use and I am no fan of many API functions. Actual communication between VB and a shelled, running program are impossible.

I am using another technique. It's not a big deal as long as clicking the command button works... I was just wondering why.
Thanks for the info.

[VanGoghGaming]

The workflow should be changed to eliminate the need to wait for completion. Instead the "shelled" program should signal back when it's done processing. This way the "main" program will always be responsive.

[AAraya]

Maybe...

Since get_shell_text waits for the external program to finish, the VB6 code pauses at that line until the shell operation completes.
During this wait, no messages (like keyboard inputs) are processed because DoEvents hasn’t been reached yet—it’s called after the shell command returns.

DoEvents processes messages only when it’s called—after get_shell_text returns. Any ESC presses during the wait aren’t processed because the message queue isn’t serviced until then, and if focus was on another window, those key presses may not even reach frmMain’s queue.

The Solution
To make the ESC key work, frmMain must be the active window capable of receiving keyboard inputs, especially after each shell operation.
The simplest fix is to explicitly return focus to frmMain after get_shell_text completes but before DoEvents processes messages.
You can use the AppActivate statement to activate frmMain based on its caption.

Modify your code like this:

frmMain.Show
For Ndx = 1 To 100
    Result = get_shell_text("program") ' This waits for completion
    AppActivate frmMain.Caption
    frmMain.ListBox.AddItem "blah blah blah"
    DoEvents
Next Ndx
End

[baka]

no, what u do is to call shell/shellexecute etc asynchronously.
so, u open a process and wait until the process ends.
or u use a multithread-method, that is basically the same, as u use the 2nd thread to wait for completion.
surely theres other ways, using memory API or just API to check if the window closes etc.
so theres many ways. but the most important thing is that u can not allow the main program to "wait".
use timers, callbacks or subclassing. do not use for/next/loop

[anycoder]

A quick sample with ShellExecuteExW

If ShellExecuteExW(Sei) Then
  Do While WaitForSingleObject(Sei.hProcess, 30) = WAIT_TIMEOUT
     DoEvents
     If fCancel Then Exit Do
  Loop
  CloseHandle Sei.hProcess
End If