disable keys while sendkeys?

Is it possible to disable all, or most keys out for a short time(1 sec)?

I am using a sendkeys statement, and wonder if disabling key strokes, will disable the sendkeys too.



I overcame the pesky focus problem with a simple do event.
I want to disable key input, during this procedure:

do
dim appid as integer
appid = shell("app.exe", 1)
appactivate appid
sendkeys "{tab}yup!{enter}{F4}"
exit do
loop

Is much smaller and actually more effective than the Dan Appleman reference for putfocus/setfocus in "Guide to the Win32 API". Thanks Balena!

:confused:


PS For the benefit of other beginers, to activate an already running application and sendkeys to it, just omit the shell above.
For example:
do
appactivate appid
sendkeys "blah"
exit do
loop

focus returns to app that sent the keys.

You want to disable the keyboard in your app alone? Or system-wide?

System wide, so that anything the user may be typing, will not steal the focus of sendkeys.

I found a few call's that do this in other forum's, since I have posted. The problem now is that the focus is left on the app, and needs to be returned to the users carret.

I tried Dan's Getfocus Putfocus, but can't get it to work.
Any idea how to grab the current focus, (into variable) and then after sendkeys, putfocus back?

TTn I have a similar reason to disable the keyboard, but I want to disable it only in VB, so that I can still use hooking. Any thoughts? How do you disable it entirely?

Quote:

---

Private Declare Function SetForegroundWindow Lib "user32" (ByVal hwnd As Long) As Long
Private Declare Function GetForegroundWindow Lib "user32" () As Long
Private Declare Function BlockInput Lib "user32" (ByVal fBlock As Long) As Long
Private Declare Function LockWindowUpdate Lib "user32" (ByVal hwndLock As Long) As Long
Private Declare Function GetDesktopWindow Lib "user32" () As Long
dim ProcessId as long

Private Sub button1_click()
DoEvents
LockWindowUpdate GetDesktopWindow
BlockInput True
txtForeground.Text = Str$(GetForegroundWindow())


ProcessId = Shell("App.exe", 1)

Do
AppActivate AppId
SendKeys "{Tab}{Tab}%(s)"
Exit Do
Loop


DoEvents
SetForegroundWindow (txtForeground.Text)
BlockInput False
LockWindowUpdate False
End sub

---

This doesn't work fully if the form is not visible.

What happens if you have an error, you have to re-boot because
your keyborad and mouse are locked. SendKeys is very
unreliable. Your better off using FindWindow, FindWindowEx, and
SendMessage APIs.

I disagree,
Error protection, is standard procedure.
Sendkeys Is fairly reliable, although fussy, but when used correctly is ok. If there is an error the sendkeys fails, and I dont get a lockup. Maybe due to the DoEvents which flushes sendkeys.



Microsoft Press encourages sendkeys.
"You now have all you need to run an external program, and interact with it"(Balena MS)


SendMessage APIs are limited, compared to sendkeys.
They actually both have some advantages, and disadantages.

Bad points for sendmessage:
Some external applications, use their own sendmesseges syntax.
More complicated, as referenced by Balena.
More mainstream, so slightly more likely to be hacked.
I think some character combos, that are easy with sendkeys, take extra work to be input, with sendmessage.

Bad points for sendkeys:
Some external applications, don't allow tab focus on the control you want,(for sendkeys) and or dont have a keyboard friendly, user interface, for control of the menu, and controls.

Good sendmessage:
You'll have to learn it eventually, so why not start now.
Robust and predictable. Granted!

Good sendkeys:
In the here and now, this is simplistic alternative to sendmessage.
If you have VB.net, you can alter the external application file, so that focus can occur on any contol you want!!! This negates a bad point.


Please add more!

You dont have any error handling in the button1_click()
procedure. So if there is an error shelling out the app you can not
activate it and the error will either crash your app or exit the
procedure leaving the keyboard and mouse blocked.

Like you stated:

Quote:

---

This doesn't work fully if the form is not visible.

---

SendMessage API can send messages to non-active windows.

Agreeded SendKeys is easier for small apps, but when you need
reliable communications API is the way to go.

Also, I think if the app was used with a different language the
SendKeys will not work because your hard coding the characters.

SendMessage sends the windows constant for a character.
Universal use.

Just a few constructive criticisms.

:)

An error is unlikely, but possible.
It is not much harder with a non-visable form, I actually use an option in one of my projects, that allows the user to see, the other form or not. The modified sendkeys works just fine.

Quote:

---

Also, I think if the app was used with a different language the
SendKeys will not work because your hard coding the characters.
SendMessage sends the windows constant for a character.
Universal use.

---

I read the exact opposite from MS!
Some app's use their own messages(language), and so sendmessage is much harder, if not impossible.
On the other hand sendkeys is limited by focus of the control, ie "tab stop" etc, although I pose a workaround(vb.net).
Sendkeys works on any windows compatible app(languages).

The BlockInput API only works on Windows 2000 and above or
Windows 98 and above. While SendMessage API works on
Windows NT 3.1 or later or Windows 95 or later. So if your
running Windows NT 4.0 and trying to block input while sending
keys it wont work.

This will require you leave the input open and if the user types a
key or click the mouse to take the focus away, it will also fail.

BlockInput is for 98 and above.
This is an good point, sendmessage does not need to be altered for earlier obsolete versions.

This is more about how Win16, and Win32 differ regurading the. input messege queue. The should be an easy alteration, like setfocus, and setcapture api, if the code is affected at all.
Clearly there is a freeze problem, with Win16.

:wave:

Keep in mind that SendKeys's is just a VB wrapper for WM_KEYDOWN/KEYUP (WM_CHAR).

So whether you call SendKeys or SendMessage, you're invoking the same low-level calls in the end.