Vista Sendkeys Wrapper
Vista Sendkeys Wrapper
(OP)
Dear All,
In beta versions of Vista VB6 apps failed with an error 70 when the code encountered a Sendkeys Statement. This was fixed in the final release of Vista for VB6 exe files; however the VB6 IDE still falls over.
For those that must have Sendkeys working in the IDE too the following wrapper appears to work; it just appears too simple after the API solutions I have seen...
Private Sub Command1_Click()
Text1.SetFocus
Sendkey "Hello"
End Sub
Private Sub Command2_Click()
Text1.SetFocus
Sendkey "%{F4}"
End Sub
Private Sub Command3_Click()
'fails with error 70 in IDE under Vista
Text1.SetFocus
SendKeys "Goodbye"
End Sub
Sub Sendkey(text$, Optional wait As Boolean = False)
'wrapper for Sendkeys which does not crash in the IDE under Windows Vista
Set WshShell = CreateObject("WScript.Shell")
WshShell.SendKeys text, wait
Set WshShell = Nothing
End Sub
Any comments?
I am not prompting a discussion on hate for SendKeys.
regards Hugh
In beta versions of Vista VB6 apps failed with an error 70 when the code encountered a Sendkeys Statement. This was fixed in the final release of Vista for VB6 exe files; however the VB6 IDE still falls over.
For those that must have Sendkeys working in the IDE too the following wrapper appears to work; it just appears too simple after the API solutions I have seen...
Private Sub Command1_Click()
Text1.SetFocus
Sendkey "Hello"
End Sub
Private Sub Command2_Click()
Text1.SetFocus
Sendkey "%{F4}"
End Sub
Private Sub Command3_Click()
'fails with error 70 in IDE under Vista
Text1.SetFocus
SendKeys "Goodbye"
End Sub
Sub Sendkey(text$, Optional wait As Boolean = False)
'wrapper for Sendkeys which does not crash in the IDE under Windows Vista
Set WshShell = CreateObject("WScript.Shell")
WshShell.SendKeys text, wait
Set WshShell = Nothing
End Sub
Any comments?
I am not prompting a discussion on hate for SendKeys.
regards Hugh
Talk To Other Members
RE: Vista Sendkeys Wrapper
I do not know about using SendKeys in Vista.
I just wouldn't understand the need to use it to imitate a keypress being sent to an object in the same application in which it was called, except maybe for causing a VB Menu item to show.
RE: Vista Sendkeys Wrapper
RE: Vista Sendkeys Wrapper
I wasn't refering to your examples. Just my opinion on using it at all, or rather avoiding it where possible, and also the fact that I am unaware of a problem using WScript.Shell.SendKeys under Vista.
You said it appears to work, but also appears too simple, and that the problem only occures (now) only in the VB IDE under Vista. The VB IDE isn't probably going to have a correction, so using an external, UTD method helps.
So, as long as seems to be working (in the IDE), and not pertaining to actual compiled code, then consider your post as an "info post", or even put it in as a FAQ in a\the IDE section for those who may be experiencing the same.
RE: Vista Sendkeys Wrapper
Public Sub Sendkeys(Text$, Optional wait As Boolean = False)
Static init As Boolean, IsIDEUnderVista As Boolean, WshShell As Object
'wrapper for Sendkeys which does not cause an Error 70 in the IDE under Windows Vista
If init Then
If IsIDEUnderVista Then
WshShell.Sendkeys Text$, wait
Else
VBA.Sendkeys Text$, wait
End If
Else
If OsVersion() >= 6 Then
IsIDEUnderVista = IsDevEnv()
If IsIDEUnderVista Then Set WshShell = CreateObject("WScript.Shell")
End If
init = True
End If
End Sub
Note OsVersion() and IsDevEnv() functions have to be supplied.
SBerthold,
I'll leave it here for a few days to see if there is any adverse comment and then may post it in the FAQs as you suggest.
RE: Vista Sendkeys Wrapper
If (Not IsDevEnv()) Then
VBA.SendKeys....
Else
WshShell.Sendkeys ....
End If
Private Function IsDevEnv() As Boolean
On Error Resume Next
Debug.Print 1/0
IsDevEnv=(err.number<>0)
End Function
RE: Vista Sendkeys Wrapper
RE: Vista Sendkeys Wrapper
>why not just use
Just thought it would be faster after the initial call; but I guess the advantage is minimal. Sendkeys can be susceptible to timing problems though so maybe it is best to keep execution as simple/ fast as possible after the initial call.
>or maybe just
The exes are ok so I'm applying an 'if it ain't broke don't fix it' policy to them just now. Doing that would also add the overhead/ dependency of the WScript.Shell object to the exe which is currently avoided. I'm also slightly uneasy that the WScript.Shell object never gets set to Nothing; any problems associated with that are also avoided in the exe.