Sign in to follow this  
Followers 0
qwert

What can derail a Send()?

12 posts in this topic

I have a script that uses a Send("^v") to simulate a Paste operation.  The Paste has worked flawlessly to insert clipboard text into several different applications (word processors, graphics packages, etc.).  My basic method is to highlight the text in the receiving program—or otherwise place the cursor at the proper position—and then run my script to place the clipboard text.

But I've found one dialog—a color editor for a graphics package—that doesn't respond to the Send("^v").  It flashes for an instant and changes focus to the first field, but it never accepts the clipboard text (6 characters, in this instance).  Yet I can manually type Ctrl+v and it accepts the clipboard text.

I'll mention that the application, itself, has no problem accepting characters when the dialog isn't active.  And I've pasted into a control on the appl's Print dialog just to confirm that dialogs, themselves, don't block.

Can anyone shed light on some possibilities?  How can this one dialog block the command?  I'm running out of things to try.

Thanks in advance for any ideas.

 

post-29172-0-78252800-1423109091_thumb.p

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

Use ControlSetText and ClipGet instead.

Inversely: GontrolGetText and ClipPut....or just put the value into a variable

To answer your question, too many things...the window you want to send to not being active...the control you want to send to not being focused upon...a modal window of your application being open, which takes the focus and thus the send...the application you send to not being able to accept input as quick as you are sending...it's really a bad function to use when there is ANY other option.

Edited by jdelaney

IEbyXPATH-Grab IE DOM objects by XPATH IEscriptRecord-Makings of an IE script recorder ExcelFromXML-Create Excel docs without excel installed GetAllWindowControls-Output all control data on a given window.

Share this post


Link to post
Share on other sites

the application you send to not being able to accept input as quick as you are sending

 

Of the things you've mentioned, this was the only one I haven't confirmed in my testing.  (But why would a manual Ctrl+v work?)

The problem with Control Set Text is that I have no knowledge of the destination control ... or even that a dialog is active.  My script provides a generic paste function that has to assume that the receiving application window is ready to accept text.

Unless there's some method (equivalent to WinGetHandle("[active]")) that would allow me to grab the control ID of the dialog's active field, I can't think of a way to use Control Set Text.

Like most, I've read about problems with Send().  But this particular script has worked reliably with a variety of applications.  Only this one color editor seems immune to the simple methods ... which is what has me puzzled.

Thanks for your response.

Share this post


Link to post
Share on other sites

As another confirmation of the basic elements of my method, I did succeed in placing text in the color editor's field by using the set text command.  I used the Au3 Window Info tool to read out the control's ID (22698) and then used this statement:

ControlSetText($hWnd, "", 22698, "123456")

But as I mentioned, I don't know of a way of determining these control IDs at runtime ... especially across a range of possible application windows.  Fortunately, most windows do not block the Send().  I hoped I could figure how this one was different.

Share this post


Link to post
Share on other sites

#5 ·  Posted (edited)

The ID is generally static, except for windowsforms...so you would just assign it to a variable...you have to provide the info output or we can only assume.

Check out the help file with all the ways to grab controls.

Edited by jdelaney

IEbyXPATH-Grab IE DOM objects by XPATH IEscriptRecord-Makings of an IE script recorder ExcelFromXML-Create Excel docs without excel installed GetAllWindowControls-Output all control data on a given window.

Share this post


Link to post
Share on other sites

I've traced this problem about as far as I know how.  It's a result of the combination of these two statements:

$task = WinGetHandle("[active]")

:

_WinAPI_SwitchToThisWindow($task)  .......... that I use prior to the Send("^v").

Most windows are simply activated and ready to accept keys ... including most dialogs.  But this particular color editor insists on changing focus to the first control (ComboBox), instead of leaving the selected field (Edit4) alone.  And I can't determine why.

Suggestions of an alternative approach are welcome.

 

Share this post


Link to post
Share on other sites

There are many other ways to grab the window also...click on this link, and there is another link to find windows:

WinGetHandle

Then you can activate it
 

WinActivate

Then focus on your control

ControlFocus
ControlSetText

IEbyXPATH-Grab IE DOM objects by XPATH IEscriptRecord-Makings of an IE script recorder ExcelFromXML-Create Excel docs without excel installed GetAllWindowControls-Output all control data on a given window.

Share this post


Link to post
Share on other sites

Then focus on your control

Therein lies the problem (if I'm interpreting correctly):

It's not my control.  It's whatever control the user may have clicked on in whatever dialog the user may have called up.  And from the help file, all indications are that they cannot be known and coded ahead of time:

A handle is the unique identifier that Windows gives controls. The handle changes each time the control is created. This method of accessing controls is generally only designed for users who are familiar with working with handles.

 

As I said, I've tested Print dialogs and they work fine.  But there are probably dozens of others used on any one PC that probably won't work.

And to top everything, I can't use ControlGetFocus to determine the active control because _WinAPI_SwitchToThisWindow($task) causes the dialog to refocus on the first control (not the one the user had the cursor in).  In this case, it always returns "ComboBox", which is at the top.

It behaves the same when I use WinActivate, instead.  So, for that dialog, I can't figure any way to activate it and leave the user's selection intact.

Share this post


Link to post
Share on other sites

That sounded promising ... but ControlGetFocus($hWindow) always returns a null, for me.  I'll investigate.

 

Meanwhile, I noticed this on the msdn page:

SwitchToThisWindow function

[This function is not intended for general use. It may be altered or unavailable in subsequent versions of Windows.]

Upon further investigation, I found http://blogs.msdn.com/b/oldnewthing/archive/2011/11/07/10234436.aspx

 

A lot is happening (good and bad) behind the scenes on some of these commands.

 

I think I'll switch to only using WinActivate.  Somehow, _WinAPI_SwitchToThisWindow() just seemed more ... well, "sophisticated".

 

 

 

Share this post


Link to post
Share on other sites

what is $task

$task = WinGetHandle("[active]")

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0