GUI hacks are the processes that you have to create because you can't get at the option or method of doing something to/in a program. For example, a really ugly GUI Hack would be
- open Windows Explorer
- hit Alt-d and put in the directory you want to go to
- then hitting 'Tab' three times to get to the file list
- use the 'key' command to start spelling the name of the file you want so that it is selected
- type Ctl-c
- hit Alt-d to move to the address bar and put in the new directory
- hit 'Tab' three times to get to the file list
- hit Ctl-v
Of course no one would do this; that's what 'ren' or 'cop' is for but sometimes you just have to interact with program GUI dialogs. And God help me, I HATE GUI HACKS! There are just so many more things that can go wrong so many 'edge-cases' you have to account for...God help me but I hate them. Well, if you gotta you gotta so here's some ideas that might help.
Timing is everything in GUI hacking. If the dialog is slow to open, or if the field you need inside the dialog is slow to be drawn, or if...blah blah blah. The first thing I do to make sure my GUI hacks are going to work is put in 'wait's everywhere so that the macro 'paces' itself. Here's an example of that. Sometimes when I send emails via Outlook, I don't want a 'message receipt' nor do I want to keep a copy of the sent message, so I have a macro that changes the message property for me and then sends it. Here's what the dialog looks like.
As you can see, there are two check boxes I want to deselect; they can either be 'clicked' by the mouse (I find this less reliable for various reasons) or the values of the check boxes can be inverted by using keystrokes (Alt-r and Alt-n). First things first; I have to get the dialog to show up. I do that by using the "Accessible object actions" item in the "Windows, controls" button on the QM toolbar and drag the aiming reticle on top of the "Options..." button on the message I'm currently writing. This method works well enough but ask yourself what would happen if the toolbar that had that "Options..." button wasn't visible at the time; the macro would fail immediately (and so would my willowy grasp on sanity). I'd prefer a keyboard shortcut but I don't have one for it, so I make due. But now, I have to guess how long to wait for the dialog to show up before I start hitting my keystrokes....or do I?....Nope. Here's what I do.
This is a version of the 'wait' command. The '0' tells QM to wait indefinitely for the window with the name "Message Options" to become 'active' ('WA'=wait till active). I pulled the window name directly from the QM Editor itself. When you have the editor open the status bar continually gives you information on both the cursor position and the window that it is currently hovering over. The window name is in the first row and comes just after the mouse position relative to the window. So now, when I start the macro, it 'clicks' the "Options..." button and waits for the dialog to become active; it then sends the keystrokes for the above check boxes and hits 'enter'. It then waits for the message itself to become active so that it can send the 'Send Message' command via an Alt-s keystroke.
0 WA "Message Options"
Now you may ask about the second line from the bottom and say, "Gordon Bennett, not ALL your emails can be tittled 'Message'!"...ok, so maybe you wouldn't say that but someone did....probably.....might have....well, ok they could have said it give me that at least.... Well, this kind of gets into the 'win' function which I should cover another time in depth but let's suffice it to say that, it is case sensitive and can be anywhere within the window name. Here's what my window's tittle bar actually looks like with a standard message.
Acc option_a=acc("Options..." "DROPLIST" win(".*Message" "OpusApp" "" 0x200) "MsoCommandBar" "" 0x1001)
0 WA "Message Options"
0 WA "Message"
So have at it and I'll see you next time cause the hook always brings you back.