I'm afraid I have already received an answer to my question: unfortunately, I have to confirm what I said. the VB6 SendKeys command generates an "Access denied" error under Vista or IE 7.0.
Thank God, it is possible to work around the problem using the following function:
VB Code:
Option Explicit
Private Const KEYEVENTF_KEYUP = &H2
Private Const INPUT_KEYBOARD = 1
Private Type KEYBDINPUT
wVk As Integer
wScan As Integer
dwFlags As Long
time As Long
dwExtraInfo As Long
End Type
Private Type GENERALINPUT
dwType As Long
xi(0 To 23) As Byte
End Type
Private Declare Function SendInput Lib "user32.dll" (ByVal nInputs As Long, pInputs As GENERALINPUT, ByVal cbSize As Long) As Long
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (pDst As Any, pSrc As Any, ByVal ByteLen As Long)
Public Function SendKeysA(ByVal vKey As Integer, Optional booDown As Boolean = False)
Dim GInput(0) As GENERALINPUT
Dim KInput As KEYBDINPUT
KInput.wVk = vKey
If Not booDown Then
KInput.dwFlags = KEYEVENTF_KEYUP
End If
GInput(0).dwType = INPUT_KEYBOARD
CopyMemory GInput(0).xi(0), KInput, Len(KInput)
Call SendInput(1, GInput(0), Len(GInput(0)))
End Function
The function above should be used in the following way:
VB Code:
Private Sub Form_KeyPress(KeyAscii As Integer)
If KeyAscii = vbKeyReturn Then
SendKeysA vbKeyTab, True
KeyAscii = 0
End If
End Sub
So, there is a solution but it is still a hell of a letdown: I have to update all my software by next January, when Vista will be officially released.
Actually its a good thing as the standard SendKeys is flakey and unreliable. This one still relies on the window having focus so for the most reliable method you would want to automate IE (with FindWindow and SendMessage APIs) and perhaps use the DOM of the loaded document instead.
Also the SendInput function:
This function does not reset the keyboard's current state. Any keys that are already pressed when the function is called might interfere with the events that this function generates. To avoid this problem, check the keyboard's state with the GetAsyncKeyState function and correct as necessary.
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
I have found the answer to my question on Planet Souce Code but, since I haven't tested it myself, I don't know what happens exactly when the old SendKeys code is run. Does the app freeze after the messagebox? Does it close down automatically?
If you have Vista Beta, can you please check and let me know?
I have it but I dont have a test system available to load it on right now.
No problem. If you test it when you have time, please let me know the type of error it generates. I need to know whether I have to provide my customers with an updated version of my software before Vista is released.
Thank God, in most cases, I only used SendKeys just to move from one TextBox to another when the user pressed Enter, so it is not a vital function. In spite of this, if the error you get is quite disturbing, I obviously have to amend the software for my customers.
Is it any better under Beta 3 thats just recently come out?
Well, it looks like my prayer was heard by MS, eventually.
A few weeks after I complained to them about the SendKeys issue, I received the following answer from Chris Mayo, the VB Program Manager responsible for Visual Basic 6 on Vista:
re: Vista To Support Legacy VB6 Apps
Pasquale,
I'm the VB Program Manager responsible for Visual Basic 6 on Vista. The SendKeys issues has been corrected and will be released in Vista RC1. The calls to SendKeys that work under Windows XP will work the same way under Vista.
Hope that helps.
Thanks,
Chris Mayo
Visual Basic Program Manager
Sunday, July 30, 2006 7:38 PM by cmayo
Well, it looks like my prayer was heard by MS, eventually.
A few weeks after I complained to them about the SendKeys issue, I received the following answer from Chris Mayo, the VB Program Manager responsible for Visual Basic 6 on Vista:
This time MS have revealed to be really professional.
Bad news boys. I just got my copy of Vista. I think it's the final release... couldn't say for sure. My son is in University and they get all the MS stuff free off the MSDN site. I installed it last night and SendKeys still generates an Error 70 Permission Denied.
Bad news boys. I just got my copy of Vista. I think it's the final release... couldn't say for sure. My son is in University and they get all the MS stuff free off the MSDN site. I installed it last night and SendKeys still generates an Error 70 Permission Denied.
--DB
Can anybody else confirm what Darkbob said? This sounds terrible.
Sendkeys is always the worst solution anyway, so this is a good thing that it doesn't work.
To simulate keyboard input, use SendInput, as you posted above (note that its predecessor, keyb_event, is long deprecated); or use a more specific solution, like SendMessage.
It's also time that .hlp files died; .chm files are their successor:
Originally Posted by [url=http://support.microsoft.com/kb/917607]KB 917607[/url]
However, the Windows Help program has not had a major update for many releases and no longer meets Microsoft standards. Therefore, starting with the Microsoft Windows Vista and the Microsoft Windows Server Code Name "Longhorn" operating system releases, the Windows Help program will not ship as a component of Windows. Also, third-party programs that include .hlp files are prohibited from redistributing the Windows Help program together with their products. Users who want to view 32-bit .hlp files must download the program from the Microsoft Download Center, and then install it on their computers. The download for Windows Help is still in development. It will be available in time for the consumer release of Windows Vista scheduled for early 2007.
Sendkeys is always the worst solution anyway, so this is a good thing that it doesn't work.
To simulate keyboard input, use SendInput, as you posted above (note that its predecessor, keyb_event, is long deprecated); or use a more specific solution, like SendMessage.
It's also time that .hlp files died; .chm files are their successor:
But have you tried using SendKeys under Vista (final release) yourself? Are you sure it doesn't work? I was told the contrary by Chris Mayo, the VB Program Manager responsible for Visual Basic 6 on Vista.
I haven't tried it; from what I read, it would seem it doesn't; and I'm saying good riddance.
You know, in the time since you started this thread, you could have fixed all your uses of SendKeys.
The reason why I didn't was because I was reassured by Chris Mayo that SendKeys would still work. How could I know they would take back what they said?
Well, I dunno why he said that, but it's still an unreliable technique to use at the best of times, so it would be a good idea not to use it, regardless.
The documentation for SendKeys in .NET suggests that it was originally implemented the same way as VB6 (using a journal hook) and was modified in .NET 3.0 to instead use SendInput as an alternative. This would explain why it wouldn't work in .NET 2.0 under Windows Vista. It therefore also implies that the VB6 implementation doesn't either; and that's not going to change now; unless the VB6 runtime is updated in Vista, which I doubt.
According to the docs Ive read on Vista, it supports VBscript so Id thoughtit would support Sendkeys .. Though I guess its different as VBscript uses WScript.Shell. Anyone know?
Funny thing is a script I wrote in Vbscript to auto install some software, using sendkeys, works better than an EXE i wrote for the same program (and gave up on) that uses FindWindow, where it gives all kinds of memory errors on and off ... :-(
I tested Sendkeys under Vista using an app developed in VB5 (the version I still use) and, as I said, it didn't work. Coud it be that SendKeys works if the app was written in VB6?
Last edited by esposito; Feb 2nd, 2007 at 02:34 PM.
I tested Sendkeys under Vista using an app developed in VB5 (the version I still use). Coud it be that SendKeys works if the app was written in VB6?
SendKeys should work for both VB5 and VB6.
Not all controls/functions in VB6 will be shipped with Vista. Take a look at this link, especially at the section dealing with what won't be with Vista.
SendKeys DOES NOT work for VB5. Please see the attached screenshot. It shows what you get when you execute the following code to move from a TextBox to the next one or check the password entered by the user:
VB5 is very similar to VB6 in terms of the code and IDE, but it is a different beast behind the scenes.. support for VB5 ended a long time ago, so the fact that the VB5 runtimes have issues on Vista is hardly surprising.
I don't know if VB6 would have issues with sendkeys on Vista, but as you are still using VB5 then I guess moving to VB6 isn't an option for you (as you can't buy it anymore).
VB5 is very similar to VB6 in terms of the code and IDE, but it is a different beast behind the scenes.. support for VB5 ended a long time ago, so the fact that the VB5 runtimes have issues on Vista is hardly surprising.
I don't know if VB6 would have issues with sendkeys on Vista, but as you are still using VB5 then I guess moving to VB6 isn't an option for you (as you can't buy it anymore).
I have just tried to use SendKeys in a VB6 application and it works just fine.
Chris Mayo has kept his promise. I was unfair to him.
I also have VB6 installed on my machines but I prefer not to use it to grant compatibility with Windows 98. (Updating OLEAUT32.DLL under Win98 is a real headache.)
So, what I have to do now is, roll up my sleeves and amend all the calls to the SendKeys statement in my applications. Moreover, I will have to get rid of my WinHelp files and replace them with a new help system of my own production. (Nothing special but it works.)
Last edited by esposito; Feb 2nd, 2007 at 03:48 PM.
Ah, good stuff.. that's one issue cleared up then.
It's been a while since I used Win98, but if memory serves the OLEAUT32.DLL issue is down to the installer, rather than VB itself - so it should be solveable by either fixing the P&DW package, or by using a different installer (such as InnoSetup).
As for the help files.. it's been a while there too, but I think you can fairly easily convert your WinHelp "project" files to HTML help (.chm) using the HTML Help authoring tool on the VB6 CD.
It's been a while since I used Win98, but if memory serves the OLEAUT32.DLL issue is down to the installer, rather than VB itself - so it should be solveable by either fixing the P&DW package, or by using a different installer (such as InnoSetup).
Sometimes my applications must be run from a shared folder without any installation. The users should only place a shortcut to the exe on their machines and be able to run the application.
VB5 allows you to do so in that its applications work with any version of OLEAUT32.DLL. VB6, on the contrary, obliges you to replace the incriminated library on each workstation, if they are equipped with Win98.
Needless to say, in order to be standalone, all my applications do not make any use of OCXs or anything that needs to be registered in the Registry. If you know how to exploit the Win32 API, you can get a lot of advanced functions without resorting to OCXs.
If you don't believe me, you can download any program of mine from my Web site (www.espositosoftware.it) and you will see that none of them makes use of external libraries. They only need to be installed in a shared folder on the server and that's it.
I understand where you are coming from, but avoiding an installation is dubious at best - it could well lead to errors.
I think you should provide an installation, at least for Win98.
I don't avoid the installation: I just mean that my applications need to be installed on the server only. And from the server they can be removed by using the Uninstall function. The setup tool I use is Inno.
You are avoiding the installation then... the required files aren't being installed to the client (which is where the program actually runs).
If you don't make use of any external libraries, it is improbable that the lack of an installation may lead to errors. The client machine remains untouched simply because no value is saved in the Registry and all the data is saved in the shared folder on the server. I see no point in installing the application on the client machine when the program leaves nothing on it.
I wasn't refering just to external libraries - there are also internal ones (in msvbvm*.dll etc).
While many versions of Windows include these files, not all do. And they aren't necesarily updated to the latest VB Service Pack either.. so there could be errors from things which are fixed in later SP's.
While your code reduces the risks, it still isn't safe.
I wasn't refering just to external libraries - there are also internal ones (in msvbvm*.dll etc).
While many versions of Windows include these files, not all do. And they aren't necesarily updated to the latest VB Service Pack either.. so there could be errors from things which are fixed in later SP's.
While your code reduces the risks, it still isn't safe.
Then I have been lucky so far. My customers have never complained about system errors generated by my software. (Touch wood!)
Just got my official copy of Vista in the mail today. I can confirm that the SendKeys function generates an error 70 when used with VB6 under Vista. Perhaps there are some cases where Sendkeys does work but I can guarantee you that it doesn't always work and it has NEVER worked for me.
Here's my code. It will change an <ENTER> key into a <TAB> key and changes each key typed to Upper case. This does work just fine on every version of Windows from Windows 95 up to XP. It does NOT work on Vista.
Code:
Privage Sub Form_KeyPress(KeyAscii as Integer)
if KeyAscii = 13 then
KeyAscii = 0
SendKeys "{Tab}"
else
KeyAscii = Asc(Ucase$(Chr$(KeyAscii)))
end if
End Sub
Just got my official copy of Vista in the mail today. I can confirm that the SendKeys function generates an error 70 when used with VB6 under Vista. Perhaps there are some cases where Sendkeys does work but I can guarantee you that it doesn't always work and it has NEVER worked for me.
Here's my code. It will change an <ENTER> key into a <TAB> key and changes each key typed to Upper case. This does work just fine on every version of Windows from Windows 95 up to XP. It does NOT work on Vista.
Code:
Privage Sub Form_KeyPress(KeyAscii as Integer)
if KeyAscii = 13 then
KeyAscii = 0
SendKeys "{Tab}"
else
KeyAscii = Asc(Ucase$(Chr$(KeyAscii)))
end if
End Sub
Error 70 - Permission Denied.
Strange. The code you have posted (compiled in VB6 and not in VB5) works just great on my PC equipped with Vista Premium (if I log on with admin privileges).
Are you sure you have the final release of Vista?
By the way, the code only works in runtime mode and not in design, i.e. you need to launch the compiled exe to avoid the Error 70 - Permission Denied.
Since I discovered Delphi and Lazarus, VB has become history to me.
Reply With Quote
Originally Posted by RobDog888
