Macro Palette | "Available when a focused window…"

Hello,

I am struggling to separate window related palettes using "Available when a focused window…".

My application has i.e. different windows and I want to assign a different palette to each one but some of the windows names contain the same string.

One window title is for example "<Part 1>". Since I use the same macro group for more Parts I worked with "Available when a focused window contains" = "<Part". That worked so far.

The other window is called "<Part 1 FM Ope>". Since it also starts with "<Part" both palettes now are showing for both windows.

Is there a way to target a specific string like in this case i.e. "FM Ope>"? I Tried each of the "Available…" options with different combinations that came to my mind but nothing worked.

Sorry, if this might be general or obvious but I spent at least more than half an hour to search for a solution in the Wiki as well the Forums.

Thanks!

Cheers,

HaPe

P.S. I often use a lot of time to figure out something like this. I hardly was able to find what I was looking for. Might be me and my special tasks or issues. I have the feeling that there is a gap between more or less beginners or regular users and forum members that are speaking developers language and are probably able to develop software from scratch. In many threads I don't even have a clue what some of you pro's are writing about.

If someone here has the time and skills to be able to provide paid support for me from time to time, feel free to send me a PM or drop an eMail to hp13@me.com. Thanks!

It's now 23 days since I asked this question. I see 40 views if this is correct.

Since I am member in different other forums and also moderator in one I have at least some related experiences and know that all forums have their special kind of style. I have to admit that I am not that active here because I always try as hard as possible to figure things out by myself. So my experience in this forum is pretty rare.

Due to this situation I’d like to ask how to interpret a missing answer to a question for quite some time. I don’t want to criticise something or someone, I just want to know the meaning so that I have an idea how to continue with my problem and/or maybe KM in general.

Does the silence mean there is no solution at all?

Was my description not detailed enough or not understandable due to my pretty bad English?

Did I miss basic and obvious informations or answers in the forums/wiki so that the silence should mean I have to search more intensively even though I think I did?

Did I violate some rules in this forum maybe even with my P.S.?

I’d really appreciate some hints at least for my forum related questions which might help enlightening me a bit.

Thanks so much in advance.

Hi Hans,

Sorry for the late reply, nothing wrong with your post.

If I read your post correctly, you want two macro groups:

Group A displays a palette if the focused window title…

  • starts with <Part and
  • does not end with FM Ope>

Group B displays a palette if the focused window title…

  • starts with <Part and
  • ends with FM Ope>

Since a macro group only accepts one Focused Window condition (and you have two for each) we should use the “match” condition, i.e. Regular Expressions.

Group A should work with this expression:

^<Part(?:(?!FM Ope>).)*$

…for window titles like…

<Part 1>
<Part 1
<Part 1 >
<Part2>
<Part>
<Part >
<Part 1 FMOpe>
<Part 1 FM Upe>
<Part x x foo>

…and not for the examples in group B.

Group B should work with this expression:

^<Part.*FM Ope>$

…for window titles like…

<Part 1 FM Ope>
<Part2 FM Ope>
<PartFM Ope>

…and not for the examples in group A.


For any other window titles, for example…

Part 1
Part 1>
<Hello FM Ope>
xyz

…no palette at all will be displayed.


Example (with group A):

59-pty-fs8

Hi Tom,

thanks so much for getting back to my topic and your examples. Highly appreciated!

Probably I did a mistake either in my description or while trying your examples but I couldn't get it to work. The "Regular Expressions" you used is actually like rocket science for me. :wink:
I'll try to insert images here. Sorry that I needed to blur out some things because I am working with an internal software that is not available for public. Please ignore the multiple entries of the same application but I often have the issue that the same application is no longer reacting on my macro group for some unknown reason.

This was the situation before and the palette appeared with each and every window containing "<Part".

I duplicated the palette twice renamed the copies and inserted your expressions. As follows the related screenshots (window title and macro palette):

I am using Better Touch Tool to fire the shortcut with a three finger tip. If I try it with the expressions it just gives me a click noise but doesn't open the palette.

Thanks again!

First, try it without all these additional complications (the part below the expression for the title match), just as shown in my example screenshot. (“Shows a palette until” and then nothing.)

Then, in the target application, create two windows, where one meets the title condition and the other not. Now bring one and then the other window to the foreground: The palette should now appear and disappear, in function of which window is frontmost.

If it doesn’t work, quit and relaunch KM Engine from KM’s File menu, and also relaunch the target application. (I had to do this a couple of times while I tested it with TextEdit. I don’t know why.)

Once you know that it works in its basic form, re-add your additional conditions (“hotkey is pressed”, “macro palette entry is clicked”, etc.)

PS:

I’ve just seen a thing: The blurred text in the window title bar, is this part of the window title?

This is important to know. I was assuming the title examples in your OP were complete titles (for example <Part 1>), and not with anyhting before it.

If you are not sure, determine what the complete title is with the “Available when a focused window title is” condition.

If the blurred part belongs to the title, then remove the begin anchor from the expressions (the ^ at the start). It should still work then, but you might get wrong matches, depending on the content of the blurred text.

Thanks again so much Tom, for your help.

I didn't (and don't) have the chance to try it out today but will figure out more tomorrow.

I'll let you know.

Cheers, HaPe

Hi Tom,

I’ve just seen a thing: The blurred text in the window title bar, is this part of the window title?

Yes. I didn't expect that the whole title is important but just wanted to focus on the part of the window title that is static in each and every situation. Sorry that I wasn't clear enough here.

I like your idea to simplify the things first. So I decided to also use TextEdit to test the behaviour.

I wasn't able to bring up the palette at all. Even a bunch of restarts didn't help. I tried to follow exactly your examples. As follows two screenshots where I named the TextEdit documents and put in your expressions.

I even tried without the "^" and with "…title is…" but nothing worked.

Did I do something wrong?

Thanks!

Hi Hans,

Try setting the macro groups to "Always activated and shows a palette until", rather than "shows a palette for one action". Also, if you were using a hotkey to dismiss the palettes before, you may have inadvertently deactivated the macro groups as well. I would confirm that the macros in these groups still work even if the palettes aren't displaying against the documents they should; if they don't, then the group is deactivated, and will never show a palette until it's reactivated (which can be done most easily with the "Activate Macro Group" action").

1 Like

Hi gglick,

thanks so much for this hint. And apologies (to Tom) that I missed this detail from the first screenshot.

"Always activated and shows a palette until "

This now works for my TextEdit test macro and shows each of the palettes related to the named window. And this is a status where I can start investigate more and try to implement this with my dedicated application.

Thanks again! Very helpful.

1 Like

Hi HaPe,

happy to hear that it (basically) works now :slight_smile:

For the additional text in the window title, and referring to the last paragraph of my previous post:

If the “relevant” part of the title begins always with <Part or at least < (and if <Part or < never appears in the blurred text), it should work reliably also without the ^ anchor in the regex. If it doesn’t, then just tell me the pattern of the preceding (blurred) text, and we will try to integrate it in the regex.

Thanks again for all of your help. But unfortunately I probably have to give up. It may be possible with way more knowledge about RegEx which I never heard about before. As mentioned in this or even other posts I don’t have any programming or scripting skills. I searched for RegEx in this forums and found out that one can read a bunch of books before being able to work with it. I would be interested if I’d have the time. But it doesn’t make sense for me to invest days, weeks or even more to save me minutes calling up a window related palette. I was just able to use your RegEx examples „title matches“ with my TextEdit tests and this seems not to work for my kind of application and the way the windows are titled referring to the patch I am working on. Even though I tried different variations with and without the „^“.

Just to let you know where I failed with the description of my window titles I’d like to give a few examples.

Part of the window titles is changing with the kind of patch I am working on. All „X“’s in the following examples are referring to variable letters, „n“ to variable numbers.

Example Window 1:

XXX… / nnnn : XXX…

Example Window 2:

XXX… / nnnn : XXX… < Part n>

Example Window 3:

XXX… / nnnn : XXX… < Part n Controller>

Example Window 4:

XXX… / nnnn : XXX… < Part n Normal Element>

Example Window 5:

XXX… / nnnn : XXX… < Part n FM Ope>

(all without the space between the "<" and the term "Part" but obviously the "<" is related to some functions of this forum and therefore doesn't display my examples correctly)

I was able to separate example 1 with the condition „… does not contain <„. Example 3, 4 and 5 are pretty easy to target with the condition „name contains…“ and then the unique entry between <>. But if I use the „<Part“ which I did with example 2 previously the other palettes (3, 4, 5) also appear because the term is also part of their window titles.

The easiest way for me would be if KM would provide multiple conditions like „contains but does not contain…“. My obvious too simple thinking was that there wold be an easy way to it like this. But even if it may be possible with RegEx I fear that the effort is way too much. So I’d try to find my way around using just „title contains…“ with the included limits.

Thanks again! As always I learned something new.

To avoid misunderstandings, in future posts please format your literal examples as code blocks, as described on the KM Wiki.

The backtick (grave) character is just under the Escape key on US keyboard layouts and to the left of the Delete key on German layouts.

To avoid syntax highlighting in this case, replace the “applescript” identifier (as shown on the Wiki page) with “text”.

Example:

```text
[literal sample text here]
```

Please confirm that the following are correct real-world examples of window titles:

Example Window 1:

abc / 1234 : abc

Example Window 2:

abc / 1234 : abc <Part 1>

Example Window 3:

abc / 1234 : abc <Part 1 Controller>

Example Window 4:

abc / 1234 : abc <Part 1 Normal Element>

Example Window 5:

abc / 1234 : abc <Part 1 FM Ope>

where every abc could also be abcdefg or ab (variable number of letters).

And the conditions are still the same as at the beginning, right? (Example 2, 3 and 4 should be group A, 5 is group B, and 1 is neither.)


Yes, I thought too this would be possible (like in the If…Then action). But – unless I’m missing the obvious – this doesn’t seem to be the case.

But with the Match condition (regex) we should be able to achieve it too (less elegant though). So no need for despair :wink:


At a first glance the old regexes (without ^) should still work.

I just don't have more time right now. I’ll check the regexes later against the new window titles.

Hi Tom,

thanks again for your hint about the text code blocks and all the other tips. I tried it just to be sure it works for me and hopefully will remember it for the next case. :wink:

And the conditions are still the same as at the beginning, right? (Example 2, 3 and 4 should be group A, 5 is group B, and 1 is neither.)

Basically yes but the ideal case (and my initial goal) was to be able to have an individual specific macro palette for each of the different windows.

But with the Match condition (regex) we should be able to achieve it too (less elegant though). So no need for despair :wink:

Sounds very positive and enthusiastic, thank you. But the given examples are not complete and there are even more windows with different consistent part names. And if I am not able to target these by myself and need to ask for support over and over again I fear it doesn't provide the right balance between effort and effect. Neither for you nor for me. :wink:

At a first glance the old regexes (without ^ ) should still work.

Inspired by this I gave it another try, adapting exact your settings from the first screenshot. It recognises the window and shows the palette. But it only works with the setting "Shows palette until…". My ideal setting is "Always activated and shows palette for one action when:" because I am able to use just one shortcut for all windows which is triggered by my configured action in BetterTouchTool. I don't always need the palette for the work in each window. With my three finger tap I am able to call it up just in case and it disappears after I clicked on one of the entries. This is pretty fast and easy for specific actions that I don't need always but if so, they're there to automate some things. And I was not able to combine my activation mode with the RegEx entry while it all works with "Window title contains…".

Thanks again and have a great weekend! :sunglasses:

Sounds very positive and enthusiastic, thank you. But the given examples are not complete and there are even more windows with different consistent part names. And if I am not able to target these by myself and need to ask for support over and over again I fear it doesn't provide the right balance between effort and effect. Neither for you nor for me. :wink:

You are absolutely right. And a bit of RegEx basic knowledge is very helpful (read: indispensable) if you do scripting in whatever form.

Just learn as much as you need. With pretty basic knowledge you’ll be able to cover many common situations. The learn/profit ratio is extremely good at the beginning.

Here some tools:


And the conditions are still the same as at the beginning, right? […]

Basically yes but the ideal case (and my initial goal) was to be able to have an individual specific macro palette for each of the different windows.

With the examples from above:

abc / 1234 : abc
:\s*\w+$
abc / 1234 : abc <Part 1>
<Part\s*\d+>
abc / 1234 : abc <Part 1 Controller>
<Part\s*\d+\s*Controller>

If the string Controller> alone is already a sufficient criterion, then you can also do it with a simple “window title contains” condition.

abc / 1234 : abc <Part 1 Normal Element>
<Part\s*\d+\s*Normal\s*Element>

If the string Normal Element> alone is already a sufficient criterion, then you can also do it with a simple “window title contains” condition.

abc / 1234 : abc <Part 1 FM Ope>
<Part\s*\d+\s*FM\s*Ope>

If the string FM Ope> alone is already a sufficient criterion, then you can also do it with a simple “window title contains” condition.

Note:
The optional spaces \s* are just there to make it more tolerant to typos, like Part1, Part 1, NormalElement.
Since you don’t seem like a person who throws around typos, you can also replace them by simple spaces. (The less complex a RegEx is, the better the computing time.)

You see, with more concrete distinctions (macro groups) now, the Regular Expressions become simpler. The one from my first post was more complex because I had to match Part followed by anything except FM Ope.


I gave it another try, adapting exact your settings from the first screenshot. It recognises the window and shows the palette. But it only works with the setting "Shows palette until…".

These are two separate things. First part, the window must be identified by its title (what I am trying to help you with), then the second part with the specific palette behavior.

The way we identify the window title should not affect the second part, unless there is some bug involved.

Hi Tom,

thank you so much for your outstanding help. That's awesome. I investigated quite a lot this afternoon.

I have to admit, that RegEx is nothing to learn in an hour or two. At least not for me. :joy:

But just from your great examples and with the help of your links (especially the testing and playground tool) I was able to target almost all important windows of my app and the testing tool even helped me to fix my bugs. I even figured out why my shortcut didn't work. It was able to trigger one of the previous palettes simultaneously that I forgot to deactivate which led to the collected palettes window.

The only one that still doesn't work and I wasn't able to fix with my investigation is the first one.

abc / 1234 : abc
:\s*\w+$

This is probably because I didn't explain enough which title variations are possible. That is the main window of my app and the window title refers to the file name before the …

/

while behind it showing the patch number and name (both fully variable) I am working on within the file.

One real life window title example is the test file I created just for the purpose of this RegEx window targeting which looks like:

KMmacro Test File / 0001: KMacro Test

The only consistent characters is again the …

/

and in addition the

:

Everything else can change, of course within the limit of possible characters (also numbers) for the file and the patch name.

But luckily I can target this window with "…doesn't contain "<"" as mentioned, because this main window doesn't contain any additional name like all others. So there is no need to catch it with RegEx.

I just can repeat myself: thanks so much, this all was very helpful even for other and maybe upcoming scenarios.

Enjoy your weekend.

Well, you waited patiently for 23 days for the first reply to come up… :roll_eyes:

I also wish you a nice weekend.