There are many Window Conditions, for example in a Pause Until action. One I need doesn’t seem to be available anywhere: when front window changes (i.e., when a different window than the currently front window becomes the front window). The simplest use of this would be to create a new window and wait until it appears. (I think this was available in QuicKeys, because I know I’ve used it in quite a few macros over the years.)
You can’t save the title and wait for it to change (Is Not), because the title might be the same (for example, the homepage you have set in Safari, with the “New Windows Open With” set to “homepage”).
In any case, window ordering — including “front” — is completely scrwed up in OS X. For example, after visiting the KM forums and noting the title and ID of the front window in an AppleScript, then creating some new windows, the title and ID are the same as what was recorded, even though the new windows are blank (if that is how you have set the Safari Preferences). More details and examples upon request — waging war with Safari window order has taken its toll over the years.
I thought so too, but realized that in some situations the new window might have the same title as an existing one. It isn’t always the case that new windows are named something like “Untitled 4”. In particular, new Safari, Firefox, or Chrome windows will often have the same name as an existing one according to the preference setting regarding what a new page opens to. In particular, if the settings are to open to a particular page, then all new windows will have the same title.
Did you notice that my Pause Until also had a check for number of windows?
So if you open a new window, regardless of its name, the window count will increase.
No, I didn’t look closely because the beginning of your post said you were comparing window names and I realized that wouldn’t work. Window count would (normally) work – can’t believe I didn’t think of that. Thanks!
Conditions generally cannot detect “change” per se. So there is no condition for Window Changed, or Application Changed, or Clipboard Changed, or whatever. It might well be useful if there was some way, but that is not how conditions work since conditions are used in various places other than Pause Until (like If) and what would it mean to say “If Window Changed” - changed from when? Maybe for the looping actions it might be possible to add some sort of change condition.
@JMichaelTX is the best solution for this, just detect the WINDOWCOUNT() increasing.
But generally if you want to detect a change you need to use a trigger to do it. So you have a macro that detects the change and sets a variable. And your macro clears the variable, enables the macro, pauses until the variable becomes set, disables the macro and continues. This is a little cumbersome, but is a general way of handling “changes” as opposed to “state”.
Don’t need the generality of “changed from what” — just that a window (new or existing) that was not front in the front application became front (“front window changed”). Similarly, “active application changed”. There must be something in Apple’s API because QuicKeys had at least the window change, if not the application change. Or maybe not: as you once pointed out to me in an email message, QuicKeys did a lot of nasty things to implement its features. (Bet you are tired of hearing about QuicKeys by now :-))
Could you give an example of a macro that follows this approach?
“Monitoring” almost always means a loop that tests conditions, performs actions if the conditions are met, and pausing. Sometimes when the conditions are met you also want to exit the loop. I’m not sure what the business with the variables were about.
I have a macro that performs an action whenever it notices a particular image on the screen, pausing each time around the loop. It also checks whether any of certain applications are running and exits if none of them are. I find it unsettling to be aware of this looping macro running off to the side, but of course its computational cost is essentially 0.
Yes, there is a window change event (well, more or less), and you can have a trigger on the window changed.
My point is you cannot have a Condition on a change event as there is no previous time for the condition to refer to. For example "if Front Window Changed" does not make any sense - changed from when? It cannot have changed, no time has passed.
So I may make some sort of way to do this, but it can't be a Condition per se, it would need to be a different mechanism that only worked with loops.
You can use this same technique to detect any event that you can trigger on. For example, you can detect an application switch, or a key or mouse button press, clipboard change, folder change, etc.
There’s another case I think: user clicks a window that comes to the front. That’s not covered by the COUNT() step but normally would be covered by the name check. Browser, though, could have multiple windows with the same name, and if a window is brought to the front that has the same name as the previous front window, the tests won’t work.
Then why, come to think of it, are we worrying about window counts and names? Adding or deleting a window changes focus. Why isn’t the answer to my initial post “use a focused window trigger, The focussed window changes”? Is any of the rest of the discussion and macro programming really necessary? What have we unearthed here that adds anything?
