SendKeys is affected by clicking on Close button

What's the best way to prevent SendKeys from being affected by clicking on
Close button?

I hide the Form just before the SendKeys, but to code timing, other Forms
appear to get displayed before the SendKeys are finished.

The code is of the following structure:

Me.Hide
ctrl.Execute    ' Displays the dialog to which the SendKeys are
to be applied
SendKeys "^{TAB}": Sleep 50: DoEvents
SendKeys "%v": Sleep 50: DoEvents
SendKeys "{TAB}": Sleep 50: DoEvents
SendKeys strStuff: Sleep 50: DoEvents
SendKeys "~": Sleep 50: DoEvents
Set ctrl = Nothing

However, a bit later in the code stream, other Forms get displayed, and
idepending on the timing of the clicks on the respective Close buttons, the
SendKeys gets messed up.

Is there a way to avoid this problem?
Can I detect when the SendKeys have actually completed execution?



--
http://www.standards.com/; See Howard Kaikow's web site.

"Howard Kaikow" <kaikow@standards.com> wrote in message
news:%23LAxTn4RFHA.3928@TK2MSFTNGP09.phx.gbl...
> What's the best way to prevent SendKeys from being affected by clicking on
> Close button?

Don't use SendKeys? Seriously.  I'm not joking. SendKeys is notorious for
being....shall we say....unpredictable (not to mention very
problematic)....and that's being kind regarding SendKeys.

>
> I hide the Form just before the SendKeys, but to code timing, other Forms
> appear to get displayed before the SendKeys are finished.
>
> The code is of the following structure:
>
>             Me.Hide
>             ctrl.Execute    ' Displays the dialog to which the SendKeys
are
> to be applied
>             SendKeys "^{TAB}": Sleep 50: DoEvents
>             SendKeys "%v": Sleep 50: DoEvents
>             SendKeys "{TAB}": Sleep 50: DoEvents
>             SendKeys strStuff: Sleep 50: DoEvents
>             SendKeys "~": Sleep 50: DoEvents
>             Set ctrl = Nothing
>
> However, a bit later in the code stream, other Forms get displayed, and
> idepending on the timing of the clicks on the respective Close buttons,
the
> SendKeys gets messed up.
>
> Is there a way to avoid this problem?
> Can I detect when the SendKeys have actually completed execution?

What exactly are you trying to accomplish by means of all those SendKeys?
It looks as if you're changing focus, copying something, tabbing to some
other control, do whatever, and I have no idea what "~" means to SendKeys.
I can't believer there's not SOMETHING better than SendKeys to do whatever
it is that you're wanting. But you need to tell us what that is.

--
Mike
Microsoft MVP Visual Basic

"Howard Kaikow" <kaikow@standards.com> wrote in message
news:%23LAxTn4RFHA.3928@TK2MSFTNGP09.phx.gbl...
> What's the best way to prevent SendKeys from being affected by clicking on
> Close button?
>
> I hide the Form just before the SendKeys, but to code timing, other Forms
> appear to get displayed before the SendKeys are finished.
>
> The code is of the following structure:
>
>             Me.Hide
>             ctrl.Execute    ' Displays the dialog to which the SendKeys
are
> to be applied
>             SendKeys "^{TAB}": Sleep 50: DoEvents
>             SendKeys "%v": Sleep 50: DoEvents
>             SendKeys "{TAB}": Sleep 50: DoEvents
>             SendKeys strStuff: Sleep 50: DoEvents
>             SendKeys "~": Sleep 50: DoEvents
>             Set ctrl = Nothing
>
> However, a bit later in the code stream, other Forms get displayed, and
> idepending on the timing of the clicks on the respective Close buttons,
the
> SendKeys gets messed up.
>
> Is there a way to avoid this problem?
> Can I detect when the SendKeys have actually completed execution?
>
>
>
> --
> http://www.standards.com/; See Howard Kaikow's web site.
>
>

Try this:
http://www.programmershelp.co.uk/vbactivewindow.php

My goal is to not use SendKeys.

I am trying to programmatically set the Password in the VBA Project
Properties window. Right now, the only method that works is to use SendKeys.

I was able to enumerate the windows and I found a handle to what I thought
corresponded to each item in the Project Properties dialog, both for th
eGeneral and Protection tabs.

A few minutes ago, I discovered the following.

Turns out that the handles returned in the code are the handles for the
labels on the textboxes.

For example, the handle for &Password is the handle for the "Password" label
itself, not for the adjacent box provided for the password.

So that may explain why using WM_COPYDATA with SendMessage returns an
invalid
password error.

Using WM_SETTEXT with SendMessage causes the "Password" label itself to be
changed to whatever text I send.

Need to find out how to get the handle of the actual input boxes.


--
http://www.standards.com/; See Howard Kaikow's web site.
"MikeD" <nobody@nowhere.edu> wrote in message
news:uwxAUQ5RFHA.356@TK2MSFTNGP14.phx.gbl...
>
> "Howard Kaikow" <kaikow@standards.com> wrote in message
> news:%23LAxTn4RFHA.3928@TK2MSFTNGP09.phx.gbl... 
on 
>
> Don't use SendKeys? Seriously.  I'm not joking. SendKeys is notorious for
> being....shall we say....unpredictable (not to mention very
> problematic)....and that's being kind regarding SendKeys.
> 
Forms 
> are 
> the 
>
> What exactly are you trying to accomplish by means of all those SendKeys?
> It looks as if you're changing focus, copying something, tabbing to some
> other control, do whatever, and I have no idea what "~" means to SendKeys.
> I can't believer there's not SOMETHING better than SendKeys to do whatever
> it is that you're wanting. But you need to tell us what that is.
>
> --
> Mike
> Microsoft MVP Visual Basic
>
>
>
>
>

Thanx.

As I just tried to explain in another response in this thread, I'm trying to
get the handles of the actual controls in the VBA Project Properties dialog
for the Protection tab.

I have not found a way to get those handles.

Once I cause the Protection tab to be known, EnumChildWindows appeared to
ennumate all windows, but I just found out a few minutes ago that it is not
ennumerating the password and confirm password boxes and likely not the
locked check box.

--
http://www.standards.com/; See Howard Kaikow's web site.
"Trammel" <Me@Server.com> wrote in message
news:cigae.21620$Pc.12529@fe1.news.blueyonder.co.uk...
> "Howard Kaikow" <kaikow@standards.com> wrote in message
> news:%23LAxTn4RFHA.3928@TK2MSFTNGP09.phx.gbl... 
on 
Forms 
> are 
> the 
>
> Try this:
> http://www.programmershelp.co.uk/vbactivewindow.php
>
>

On Fri, 22 Apr 2005 23:23:26 -0400, "Howard Kaikow"
<kaikow@standards.com> wrote:

<snip>

>For example, the handle for &Password is the handle for the "Password" labe
l
>itself, not for the adjacent box provided for the password.
>
>So that may explain why using WM_COPYDATA with SendMessage returns an
>invalid
>password error.

Check out what WM_COPYDATA is meant to do
- it is a fairly complex beast

>Using WM_SETTEXT with SendMessage causes the "Password" label itself to be
>changed to whatever text I send.

That figures
- but you should be able to locate the Handle of the Edit box
- if it really is an edit box

>Need to find out how to get the handle of the actual input boxes.

Write a little WindowFromPoint snooper

--
http://www.standards.com/; See Howard Kaikow's web site.
"J French" <erewhon@nowhere.uk> wrote in message
news:426a2e94.5869236@news.btclick.com...
> On Fri, 22 Apr 2005 23:23:26 -0400, "Howard Kaikow"
> <kaikow@standards.com> wrote:
>
> <snip>
> 
label 
>
> Check out what WM_COPYDATA is meant to do
> - it is a fairly complex beast
> 
be 
>
> That figures
> - but you should be able to locate the Handle of the Edit box
> - if it really is an edit box
> 
>
> Write a little WindowFromPoint snooper

> That figures
> - but you should be able to locate the Handle of the Edit box
> - if it really is an edit box

I already enumerated the windows, no handle is returne for the box.
 
>
> Write a little WindowFromPoint snooper

I can only position the pointer into the box using SendKeys.
I guess I can follow that with a Window fromPoint to see what gets returned.

I tried using WindowFromPoint, see code below.

Just before calling this sub, I used SendKeys to fill the password field,
but that does not seem to make it the active cursor position.

Right after using SendKeys to fill the password field, I run:

strPassword = "Boo"
SendString strPassword
strPassword = "my"

I had hoped that the SendString would change the password box, but it did
not.
If it had, I would have received an error that the password in the confirm
box does not match.

When I run in design mode, I can see that SendString is sometimes changing
the caption for the button in the VB 6 Form, not that VBA dialog. Oter
times, I do not see where it changes anything. Of course, the code is too
fat to watch. Cannot step thru the code because then th Debug winow gets the
focus.

Running from a .exe, the code is too fast to see anything.

I do list the relevant items in a list box.

Private Sub SendString(strToSend As String)
Dim buffer() As Byte
Dim k As Long
Dim hWnd As Long
Dim strCaption As String

Dim Pt As POINTAPI

hWnd = GetActiveWindow()
strCaption = Space$(GetWindowTextLength(hWnd) + 1)
GetWindowText hWnd, strCaption, Len(strCaption)
strCaption = Left$(strCaption, Len(strCaption) - 1)

lstOutput.AddItem "GetActiveWindow in SendString: " & strCaption & " = "
& hWnd

GetCursorPos Pt
hWnd = WindowFromPoint(Pt.X, Pt.Y)
strCaption = Space$(GetWindowTextLength(hWnd) + 1)
GetWindowText hWnd, strCaption, Len(strCaption)
strCaption = Left$(strCaption, Len(strCaption) - 1)

lstOutput.AddItem "GetCursorPos in SendString: " & strCaption & " = " &
hWnd

k = Len(strToSend)
ReDim buffer(k)
Call CopyMemory(buffer(0), ByVal strToSend, Len(strToSend))
SendMessage hWnd, WM_SETTEXT, 0, buffer(0)
End Sub

"Randy Birch" <rgb_removethis@mvps.org> wrote in message
news:O$KBdqHSFHA.3928@TK2MSFTNGP09.phx.gbl...
> Run the spyxx tool and inspect the dialog with that. You should get, for
the
> password box of interest, a control ID number. That never changes between
> runs, but the hwnd will.  Armed with the control ID, you can now do your
> thing to get the hwnd of the property dialog, then use the GetDlgItem()
API
> to return the hwnd to the control you specify with the control ID you
> discovered earlier. Now that you have that hwnd, try using SendMessage
with
> WM_SETTEXT as the message, and byval sPassword as lparam. wParam will be
> passed as 0&.  For an example of using GetDlgItem, see
> http://vbnet.mvps.org/code/hooks/ch...orcustomize.htm

Thanx.

I have spyxx, but, alas, on my mail system, the installation of VB .NET
seems to have uninstalled the old Visual Studio version.

I guess I could write a quickee VB .NET program to use .NET's spyxx.
Alternative is to reboot to a system that does not have VS.NET.
I guess I'll flip a coin, with my luck it will likely land on its edge.

I've managed to use keybd_event to get rid of most of the SendKeys, but I
need to add code for keyboard_event to use Alt, Shift and Ctrl keys.

However, it does appear that keybd_event might be susceptiple to the user's
mouse clicks when the code is running, so it may be better to continue
trying to use  WM_SETTEXT, i.e., if I can ever get the handles I need.
keybd_event runs much faster than SendKeys.

The last thing I will try to do, tho I'm not sure it is possible, is to try
to set the fields of the Project Properties dialog without the dialog
needing to be visible. I do not think this is possible, unless the IDs that
I can get with GetDlgItem exist when the dialog is not visible. The handles
do not exist without the dialog being visible, indeed, they do not exist
unless the Protection tab is displayed, and CTRL TAB is needed to get to the
Protection tab.

Getting rid of SendKeys, in this case, eliminates the need for DoEvents  and
Sleep with each SendKey.