Using Controls on two dialog windows

[terrypin]

With a dialog window open in my application, my macro successfully uses the commands Get Control followed by Get Control Text to set several text variables. The macro then opens a different dialog window and again uses the same procedure to set a couple of additional text variables. But those are not successful. A TBD shows them blank.

 

I'll explore further, but meanwhile does anyone have any suggestions please? Is there perhaps some basic reason why data cannot be captured from multiple windows using controls?

 

--

Terry, East Grinstead, UK

[Cory]

It sounds like you're doing it right. Just read what I wrote the other day about controls and know that the handles will change. So if you were to open a window and then open another without doing the Get Control again it would have the wrong address. And make sure there aren't any windows of the same name. Also check for hidden windows.

[terrypin]

Thanks Cory. Somehow I got it working reliably. Quite a complex macro gathering 8 text variables from two dialogs. I made separate macros, one for each dialog, and ran them as submacros in the parent macro. Finally writing a small text file.

 

So I was quite pleased with myself... until I ran it again today. Both submacros now fail, delivering plainly wrong data.

 

I now need to decide whether to persist with a Controls-based approach (faster, elegant) or revert to a mouse/pixel-based approach (slower, inelegant - but usually reliable if care taken over GUI changes, OS updates, etc).

 

What's the general experience? Are controls really inherently so unpredictable that they're best avoided? Is one of the two capture method more consistently reliable than the other? And if the mouse to pixel position setting is used from the drop-down list, does that have any benefit over simply using Mouse Move and Mouse Click commands?

 

Any feedback would be appreciated please.

 

Terry, East Grinstead, UK

[Samrae]

In my experience some programs have consistent Window Controls. Others, however, create a new Window Control every time the program runs. I happen to have macros that interact with a program somewhere in the middle. Most of the time the Window Control is consistent but sometimes it changes.

 

To get around this, when my macro interacting with this program has a problem with the Window Control I add the new Window Control to my macro. It looks like this:

Get Control: (CLIENT.EXE) Using z-order -> %Description% // Description box  6-13-12
If Control "%Description%" Does Not Exist
  Get Control: (CLIENT.EXE) Using z-order -> %Description% // Description box
End If
If Control "%Description%" Does Not Exist
  Get Control: (CLIENT.EXE) Using z-order -> %Description% // Description box  7-8-11
End If

Fortunately, there seems to be a limited number of Window Controls for this element. So a check for three different Window Controls works.

 

I do not know whether any specific one of the different ways of identifying a Window Control is more or less reliable. I usually try the default (z-order) value first. If that does not work I will try the next (contents) and if that doesn't work then the last choice (coordinates).

 

The Capture Control command requires that you know the X/Y position of an element but the Window Control for that element works correctly until the program is restarted.

[terrypin]

Thanks Samrae, that's an interesting idea, I'll try it. I do have my macro working again, although I'm now not really confident it will continue to do so.

[acantor]

Hi Terry, You and I are facing the same dilemma: we have become skillful at making inferences about the state of a program, or extracting data, by manipulating a program's User Interface. We acknowledge that using controls is a more elegant approach, but our pixel- and pointer-detecting macros sometimes get the job done quicker and more reliably.

 

In my scripting universe, I try to take advantage of controls whenever I can. But sometimes I find that using controls is not worth the effort.

 

Both approaches have value. Often I try both approaches, and then decide which to use based on the larger goals: reliability vs. speed vs. portability vs. maintain-ability, etc.