In theory. But that's a point to be raised with the app developers -- most of whom can't even be bothered to include basic AppleScript support in the first place.
Grrrr...
Yes -- but it is trivial to activate your app to show the tooltip and then reactivate the previous app. The trick would be in keep your dialog at the front.
I'd use it then close it, but I suppose you could leave it open -- macOS will generally refuse to move things off-screen though, usually leaving a corner visible. You can do the same with KM dialogs -- remembering that they belong to the Engine, not the Editor -- with the same limitation:
But give SwiftDialog a go -- if you want to do re-writes within the dialog it'll probably be all-round easier than a Custom HTML Prompt, and you won't need to close/reopen it like you would a Display Text window.
Which "this" are you talking about? The last macro I provided does not take the focus away from your app, so I'm inferring that you did not test my macro. And you called it slow, while I think it's extremely fast. I just tested how long it takes, and got a result under 0.01 seconds. That's ten times faster than the blink of an eye.
Please explain which "dialog window" you mean. There are several methods for displaying text.
I use the KM Display Progress Bar window to display my macro variables while my macros are running. It works great. For example, I have a very large macro that has a variables called State which is used by the macro to determine which "state" my macro is in. I use the Progress Bar window to update me on the value of the State variable, and sometimes I add additional variables because there's room on the Progress Bar to display several variables. Here's an example:
I use this because it doesn't steal focus, and it's extremely quick. Sometimes I also use the progress bar to display the contents of a variable. The Progress Bar action is so useful for displaying feedback from a macro, that this is all I ever use it for. I never use it for displaying progress.
that's what i was thinking. even if I use the window ID to perform movement operations on the km engine dialogue window, I'm not sure how I could update the text displayed in it.
in other words, to reference the "dialog demo" macros you shared in your last post, rather than "Hello World!" being the text for the window, i wonder if adding a variable reference token (global, or maybe an instance variable would work) for the text to display would allow me to update the text in that particular window instance without needing to close the window and create a new instance.
also, do you know if it's possible and/or how to keep the km engine dialog window always on top like a tooltip?
and even if I can't move the window completely off screen, and need to leave a small corner of it visible, i think that might still be better than minimizing and unminimizing it. for one thing, I think the operation to move a window is generally much faster and cheaper (for CPU/GPU). secondly, i'm not sure if I'd be able to unminimize the window without losing focus on a selection of text, file(s)/folder(s), or media item(s) in the frontmost app.
sorry, i meant to add the quote there. it was referring to viewing the km engine log file to monitor macros being triggered.
and I wasn't saying your macro was slow, but the process of opening and/or switching to the console app would be slower than showing a tooltip with the same info.
i meant the one you get when using the action to display text in a window.
i never really thought of using the progress bar like that, though. it's a pretty good idea.
You can leave both windows on the screen at the same time. Or use a second monitor. There's no switching required. I recall once I modified this solution to actually play a beep sound whenever a macro was triggered, and this technique didn't require any macros at all!
There's more than one action to do that. I can think of four actions to do that.
Unless I'm really misunderstanding something (quite possible), this isn't feasible: Tool tips are coded as part of the app, and can't be changed on the fly by a user or another app. If I want one of our apps to have different tool tips, I have to get Peter (our founder/programmer, not the KM Peter!) to include them in a future build—I can't test anything myself with an already-compiled app.
I probably would have understood if you had literally said "Display Text" but you said "display text." I guess I'm at fault for not understanding what you meant, sorry.
Ditto for me. And literal ToolTips, as in "tips that appear when you leave the mouse over a tool icon/button", aren't really appropriate for the OP's intended use.
But this page seems to suggest, at least to my untrained mind, that tool tip text can be changed on the fly by assigning a new value to the variable. So it shouldn't be beyond the whit of a developer to include AppleScript hooks for setting said variable.
Which isn't going to happen unless said developer wants the functionality for their own use -- it's a lot of work for a feature of limited interest.
KM does already have ways of "drawing" on the screen without stealing focus -- the "Highlight Location" and "Display Text -- Large" actions, for example. And it would be nice to have a version of "Display Text -- Large" that was positionable and auto-sized to the text supplied...
no problem! it's no big deal. i'm sorry too because i wasn't at my computer a few times when i replied to messages here, so i was probably being a little vague or confusing at times anyway.
