ISSUE: PAUSE UNTIL Action Fails with No Windows

###ISSUE: PAUSE UNTIL Action Fails with No Windows

####It appears that the Front Window Title is NOT being read properly by the Pause Until Action when there are NO windows.

####Bug or User Error?

Question for @peternlewis: Why does the Pause Until Condition refer to it as window "title", whereas the token uses window "name"? Is there a difference?


  • KM 7.0.3
  • Yosemite (10.10.5)
  • App: Script Editor

Detect when a new document (and therefore a new window) is created in Script Editor, starting when there are NO open documents/windows in SE

• Open Script Editor, and close ALL windows

• Macro will PAUSE UNTIL a new SE document/window is created.

• Macro does NOT pause.
• Seems to think there is a different window title than at start of macro
• But no new windows have been created.

TEST PAUSE UNTIL Action Fails with No Windows.kmmacros (10.0 KB)


1 Like

@ccstone and @peternlewis, do you have any ideas on this?
Can you confirm or refute this behavior?

I think there is some confusion.

When there is no front window, then %WindowName%1% will return the empty string - it has to return something, but it could just as easily have returned “No Window” or anything else.

The condition in question is not “the text %WindowName%1% is empty”.

The condition in question is that "the front window of the front application title is not ‘WHATEVER’ ". Which if there is no window is definitively true for any possible title, including the empty string. If there is no front window then the title is not anything.

I don't care what It returns as long as it returns it consistently.
The issue I see, is that one action returns one thing for no window, and the other action returns something different.
Shouldn't both the window token and The Pause Until Condition see the same window name, whatever it is?

It seems reasonable to me to be able to test for a change in window name, like when you go from no documents to a new document.

They do see the same name. However the test is not just about the window name, it is also about the front window.

In the absence of a front window, the condition “the front window is xxx” is makes no sense for any xxx.

So the condition “the front window of the front application title is not ‘WHATEVER’” is false whenever there is no front window (it could just as well be true for all cases - it’s a meaningless condition, but I chose it to be false for all cases). The title isn’t anything, its not empty, its not anything else either.

If you want what you want to do, you can use a text condition to get different behaviour.

Sorry, I don't understand what you mean by that.
What test/condition should I use to handle either of these cases:

  1. Start with NO documents/windows, pause until new window appears
  2. Start with 1 or more windows, pause until new window appears

So when I set Variable X to %windowName%1%, KM should assign the same value (empty, false, whatever you want) as it does in the Pause Until condition "the front window of front application is (or is not)" value.
Both Actions are referring to the same window title, of which one valid value is null, or empty string.

What is the purpose or value of the results being different?


The below macro works as expected. I have simulated a "Pause Until" with a loop using "Execute Actions Until Conditions Met".

  • Pause for 1 sec
  • Set Loop variable to Front Window Title
  • Compare Loop variable with Front Window Title BEFORE process was started.
  • Exit loop when a new window title is found
  • Works perfectly (except for the extra pause time)

Since this works comparing a starting point of NO windows (therefore the Win Title would be null/empty) to the Win Title while the user is using the menu (title still null), until a new doc/window is created, it should also work with "Pause Until".

Functionally, these two macros are the same. The big difference is the fixed pause between checks for new window using the Execute Until Action vs the process used internally by the Pause action (which is near instantaneous).

Sorry, but I believe you have a bug in the Pause Until action.
Since the token %WindowName%Front% returns an empty string when there is no window, then the Pause Until condition "the title of the front window of front application" should do the same.

####MACRO: TEST 2 LOOP UNTIL New Window”

TEST 2 LOOP UNTIL New Window.kmmacros (10 KB)

1 Like

Test the condition you are actually wanting - that is, test that %WindowName%1% changes.

Currently you are doing two different things - before the loop you are getting that value of %WindowName%1%, and in the Pause Until, you are testing the condition "the front window of the front application title is not '<the old value of %WindowName%1%>'". This condition is not the same as testing that "%WindowName%1% is not '<the old value of %WindowName%1%>'", specifically it differs in the case where the front window does not exist, where the former condition will always be true when the front window does not exist (because when it does not exist the window title is not equal to anything), and in the latter case where the front window does not exist that will result in %WindowName%1% being the empty string which will be different to the previous value (presuming there was a window with a non-empty title beforehand).

Another case where the conditions might behave differently would be in the case of a window that had an empty string as the name as compared to no window existing.

1 Like

Another way of thinking about the difference here, from a programming perspective is the difference between nil and “”. In the case of window not existing, think of the window title as nil. If you use the token %WindowName%1% it must return a string, so the string you get is the empty string “”. But in the condition, the difference between a nil window title (window not existing) and a window with an empty string for the title is discernible. The condition behaves differently in these two different cases where as the text token is incapable of discerning the difference.

1 Like


Just tested it, and it works just as I would expect.
I don't know why it did not occur to me to use this as the Pause Until Condition.
I guess when I saw the choice for "Front Window Condition" in the Condition list, it just seemed like the obvious test.

Learned something new, and this solves my use case, so I'm ready to move on.

But I'd just like to leave this with you, Peter. Regardless of the underlying programming considerations, IMO, most users would expect the Condition of "Title of Front Window of Front App" to return an empty string if the window did not exist:

  • KM variables can have a type only of string/text
  • The %Window%Name% token returns an empty string when there are no windows. Obviously the KM code is converting a nil to empty string here.
  • The Pause Until action provides a separate condition of Front Window exists

So really, it's more about what is most intuitive for the user, what most users would expect, than it is about the technical difference between nil and empty string (which I already fully understood).

Many thanks for giving us so many choices in KM. I really like choices. :+1: