AutoHotkey Community

Hi again.

Not to take focus away from my STDIN / STDOUT / STDERR redirection wishlist item (which I consider much more important and which I'll continue researching to try to help), I wonder if you've considered a companion feature to PostMessage/SendMessage that waits for a particular window message to be received (preferably with a timeout feature). Many programs broadcast messages to indicate they have reached various significant points in their execution, so the ability to act on these messages would enhance the ability of AutoHotkey programs to coordinate their activities with such programs (going beyond waiting for particular windows to be created/activated/destroyed, etc.). There are also a number of standard window messages that could be of interest to an AutoIt program, such as for example the message that notifies running programs of a change in the the top-level environment variables (I think that one's called WM_WININICHANGE). And of course it would also open up the ability for custom programs to be written to send specific messages to a companoin AutoHotkey program with which they are cooperating.

Just a thought...

Jacques.

PS: In the mean time, does anybody know of an existing utility that can be used to wait for a particular window message and terminates when the message has been received? That would make this capability available right away.

I'm not trying to be critical, but in the future you might try searching the forum before making support, bug, or feature requests.

359
1894

You can search deeper if you wish, that was just a simple search. Anyway, this feature is tentatively planned (I think) but will probably take some work to do.

Agreed. In my defense, I always search before posting anything to the Support forum, and I search the "Planned Features" page before posting to the Wish List. In this case, there was no mention of anything planned in the realm of window messages.

One comment about something posted in the thread http://www.autohotkey.com/forum/viewtopic.php?t=359 which you mentioned (Thanks):

A system-wide hook would only be required to see messages posted to "other" windows. This request is for an AutoHotkey script to be informed of messages sent to its own window (either explicity or via broadcast), which can be handled within AutoHotkey's own message loop.

Jacques.

This is a good idea and at the very least it will probably be implemented for GUI windows so that the script can respond to messages they receive.

In some sense, this capability already exists with GuiClose, GuiEscape, GuiSize, and other special labels: For example, you could send a Maximize message to a hidden GUI window that the user never sees. The script can then intercept and respond to this message:

Perhaps some kind of generalized message filter could be allowed for a script. For example, if a script has the following function defined, it would receive all messages (or at least those that aren't essential to the program's internal operation) and return 1 to discard them or 0 to let the program process them normally:

The above would rely on the new function-calling feature, which will be available in the next release (hopefully in a day or two). Does this seem interesting/feasible? Can anyone think of a better way?

That way makes a lot of sense chris, like a callback function or something.

I like the idea as well -- full disclosure! Since this may be the first of several future functions with special significance in an AutoIt script (thus potentially creating a number of "reserved" function names), you may want to consider using instead a special class of names not otherwise acceptable for user-defined functions, maybe something like #MessageIn() or @MessageIn(). [I'm not up on what is and isn't acceptabe for variable names in AutoHotkey, but you get my drift].

I take it that receipt of a message would cause the script's MessageIn function to be called asynchronously, presumably in a new thread? Would there be practical limits to how much processing the function would be able to do before returning a result? (i.e. is there a potential for blocking normal background AHK activity, like processing of other messages, etc.) Also, how would such a function be employed to implement a wait for a particular message to be received? (e.g. a script that launches a program and waits for some particular message to be broadcast by that program before performing further action?)

Thanks,

Jacques.

Good points, thanks. It could also be done instead like OnMessage, MessageNumber, NameOfFunctionToExecute

Since the program only has one true thread, internally everything would be synchronous, so there would definitely be the potential for a script to disrupt message flow if it takes to long to return the result. I'm not sure how this can or should be dealt with.

Maybe you could start reserved functions with "A_" (like reserved variables) to avoid confusion and the need to memorize more than one thing.

That's a possibility. Thanks.

That would work nicely if AHK didn't expect a quick return (or any return) from the function, otherwise we're in the same boat as with the A_MessageIn() idea -- i.e. we may need to do lots of processing upon receipt of a particular message (the whole rest of the program in fact, when receipt of the message is a necesary condition for continuning the program's activities), yet we are under pressure to provide a quick return in order to keep AHK happy. Maybe I'm saying that the second parameter to OnMessage should be a label rather than a function name (since calling a function implies that "something" is waiting for a return value). That however would leave the issue of passing the message's parameters to the routine. There is currently (or planned) no way to pass parameters to a "subroutine" as opposed to a "function", right? (like "function returning void"). Alternatively, would there be a way for a function to return a value but continue executing (something like ReturnStay vs. Return)?


The typical answer in API's that offer such features is a statement in the documentation that warns the programmer that the code in the function should return "quickly" (i.e. be "non-blocking") and that the programmer assumes the risk of starting long operations within the code (e.g. that it may be OK to "Run" a program from the function, but maybe not to "RunWait" a program).

Jacques.

That's a good point. In cases where the script needs the value and doesn't care if the program also processes the message normally, the need to return a value can be eliminated (perhaps this should be the default behavior unless changed via an option).

That's interesting. Although it seems a little complicated to implement, I'll give it some more thought when the times comes to work on this feature.

Sounds reasonable.

Thanks.

The ability for a script to receive messages has been added. See OnMessage().

Thanks to everyone who posted ideas above. They really helped motivate me to do it, as well as helping with the design.

Edit: I've added a working example of how to send strings of any length from one script to another (via WM_COPYDATA). See the bottom of the OnMessage() page.

Thanks, Chris. Very cool.

Jacques.