Here's a macro, with a Focused Window Trigger (The focused window title changes), that gets triggered immediately whenever I activate the macro group. To me this does not seem like the expected behaviour. But is this a feature or a bug?
My desired behaviour would be for the macro first being triggered upon first window changing after the macro group is activated. Like how the behaviour is when using Application Trigger (Any Application Activates) for a macro in a similarly set macro group.
That's really strange—I wouldn't think it should, but it definitely triggers on group activation. I displayed the front window title in the macro, and it represented what I was seeing as the (unchanged) frontmost window. @peternlewis will probably have to chime in here...
Thank you for checking it out, and for confirming that it is not only for me that something strange is going on here. Curious to hear what Peter will make of these observations
Just a note. This change that was delivered in 11.0.3 forces me to split macro group that is dedicated to one browser web page into two parts. The one is always active, and another is being activated when the browser title contains some string.
Is there a macro trigger that runs a specific macro when its group was activated?
I would like to instantly run this one: Page handlers. Search.kmmacros (4.0 KB)
when its macro group is being activated. This would allow me to completely switch from using "Available when a focused window title contains" condition to the "URL-Dependent Macro Enable/Disable" approach described here.
I do not believe there is (hopefully I will be proven wrong though), but I have also been thinking that a trigger like this would make allot of sense and oftentimes be very useful
It's been 1.5 years and this has not moved. I don't need this function, but I had an idea about it. (I found this thread while looking for posts about triggering by focused window changes.)
I'm thinking that you could have a macro in the group that is triggered every second. As long as the group is inactive, that macro does nothing.
Less than one second after the group is activated, the macro will trigger. The macro calls whatever macro you want to run for this group activation and then deactivates itself.
Whatever process deactivates the group again should also then, after deactivating the group, activate this macro to set the trap for the next time.
Thanks. I notice that my idea and @kevinb's are slightly different in how they use the initial trigger to call something else and in how they turn the alarm off, but the priniciple is the same. I think both will work (I haven't tested either) and may depend on how you want to use this trigger.
I don't write "This should be resolved for the next version" unless I have actually written the code. So the answer is yes if there has been a release since the date the text was posted.
That said, it's always possible whatever I did did not actually fix the issue, or fixed an issue that was different to an issue that is occurring now.
