I get
Oops! That page doesn’t exist or is private.
when I click the View Topic in my email message
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.
Have you tried my macro, modified for your needs?
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”.
1 Like
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 :-))
Feature explanation? Where did the embedded quote by @JMichaelTX in the previous post (8) come from?
If you change it to count changed, you could detect a window closing too.
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.
You can detect EITHER a NEW window, or CLOSING of a window by the formula you use. I used >, so it will only be TRUE if a window is added:
WINDOWCOUNT() > WinCountBefore
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.
and then used like this:
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.
Oh. That’s nearly perfect. No need for another feature.
And I see your point about what/when/immediately.
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.
Hey Mitchell,
Peter's macro with the Focussed Window Changes trigger should cover that.
-Chris
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?
Because triggering a macro is quite different from using a Pause Until action in a macro.
Because now you have two macros and more confusion.
If you are just waiting for a window to appear or disappear, then Pause Until WINDOWCOUNT changes is two actions within a single macro and very clear.
Once you have two macros interoperating, the complexity increases dramatically.
right. Duh. Good distinction to keep in mind :-).