Is there a way to Create a Custom HTML Form without Making it "Active"?

Is there a way to create a Custom HTML Form without making it "Active"? I would like the form that I create to remain in the background. That's because I want the user to see it, but not interact with it. I know how to switch the focus back to the last app, but that's not sufficient.

1 Like

What are you trying to do?

I'm trying to create a "permanent display window" for variables, that displays/updates the value of a bunch of variables every second. My prototype is working, but the most annoying problem is the constant changing of focus between whatever window the user is using and the Custom HTML window.

Think of it as a debugger window for variables, much like the KM Debugger window for macros.

Doesn't the KM Debugger already let you watch variables like this?


I have absolutely no idea how you made the KM Debugger display those variables. I've never seen anything like that. How did you do it? Ok, I've started browsing some of your VIP subroutines. Those macros are very advanced. So far I haven't found the code that puts variables into the Debugger window. I don't even know what I'm looking for.

I didn't do anything! I just stuck a "Debugger Breakpoint this Macro" action in a macro, and ran the macro. When it hit the breakpoint, it displayed this window.

I don't know much else about using the KM debugger, but you should probably take a look at it and see if it can do what you want.

Okay. I use the debugger all the time. I've never seen variables show up in it. I have used breakpoints, but maybe not the type you use. I'll experiment. You've set my sail in the right direction. Thanks.

P.S. I saw an error in your VIP macros. You credited David Niven as James Bond in the 1967 movie Casino Royale. I saw that movie once, and at the end of it I was convinced that it was Peters Sellers, not David Niven, who played James Bond in that movie. But my memory may be faulty. So I checked wikipedia. It claims that both Sellers and Niven played Bond in that movie. I guess I have to re-watch the movie. I think it was a story of mistaken identities.

Cool. If you decide you still want to go the Custom HTML Prompt way, I have some thoughts about the problems you mentioned.

Well, to be fair, I just pulled that data off the Internet. I don't remember where I got it, but "it's not my fault!" :rofl:

After another 10 minutes reading the plot line, you appear to be right.

Nope. The debugger does not display any variables when I invoke it. It never has, and I use it every day. What am I supposed to do to make it show any variables like you have done?

In any case, even if it did work, it looks like it wouldn't meet my needs, because my macro is running asynchronously, showing the values of (selected global) variables as they change. And the debugger window would show the values of variables only when the macro has stopped. So I don't think I would like this solution anyway. I was also hoping to install "data breakpoints" that would do something helpful, like make a sound when a variable reaches a certain value, or something like that. I can achieve this.

My original question is as-yet unsolved: How do I create an HTML form without making it active. Maybe there is no way. I infer that you don't have a way.

Clicking this button toggles showing variables:


In any case, back to your original question about your Custom HTML Prompt. What are you doing to refresh your variables? I can't think of any reason focus would need to change, in order to refresh them.

1 Like


I had no idea that was even a button! I read KM docs for fun, and I never knew about that button.

1 Like

My Custom HTML Form is not smart enough (neither am I) to "refresh" the variables. It draws a new Custom Form every second. Whenever a Custom HTML form is created, it grabs the focus, right? I want it to remain in the background even when it's created. Is there some way to do that?

You're probably thinking "why recreate the form? Just create a JXA loop and update the data that way." Well, that might work with global variables, but in future versions I also want to pass local variables to it. And as far as I can tell, you can't do that even with JXA. But maybe I'm wrong. Have you mastered inter-instance communication between Custom HMTL actions and other KM macros?

Hello @Sleepy ,

If you mean somewhat like "data breakpoints" for debugging purposes than let me me tell you that there is a way using a system using third party PlugIns called "Check Point System Utilities" made by @tiffle .
I use it several times when needed and it is a great System.

I am really sure that if I am right here - and you are interested in this System - He will invite you into our Private Group so that you can make use of it.

Greetings from Germany


Thanks Tobias (@Nr.5-need_input) for the recommendation.

It's obviously up to @Sleepy to decide what's right but for anyone interested in the Checkpoint System they can read all about it here:

Hello Taj (@tiffle),

you're welcome ...

Thanks for mentioning that... but it wasn't my intention to say him what he has to do....
I just needed to tell him about your great Debugging Tool that he can use If I understand it correctly what he wants to accomplish when it comes to debugging.

And thank you for your Tips Post about your Check Point Utilities - I must have missed its existence somehow.

Greetings from Germany to the beautiful France


1 Like

Are you saying you create a new Custom HTML Prompt every second?

Yes. This is why I need a way to stop the changing of the active window. Yes, I know it's inefficient to create a new Custom HTML Prompt window every second. But I don't know how to write in JXE so I have to use tricks to get the same end result.

I will consider that, but for now I get my pleasure out of the act of solving problems on my own.

It's an honour to be considered for that. But not now, because solving problems on my own is the greatest pleasure.

How do you currently propagate your prompt with variables and their values? In other words, how does the Custom HTML Prompt know what variables to display, and how do they end up in HTML elements so you can see them?

You've made my day by asking me a question.

In my prototype macro, the user has to register which global variables to monitor, like this: (de-registering is also possible in this macro, and I could also make deregistering automatic when a variable is set to the empty string, or deleted.)

When the user does this, the names of the variables are stored as keys in a dictionary, making it possible for the asynchronous Custom macro to "remember" which variables to draw. In fact, the values of those variables are stored in the value portion of the same dictionary, which means the Custom macro has the ability (not yet implemented in my macro) to determine if the "current value differs from the last value". If there are no differences, the Custom macro doesn't even have to refresh its window! That's efficiency.

I generate the HTML code to display the variables in a table in the Custom form. One of my actions, therefore, looks like this: (it's assembling rows of the table in a loop)

The end result is pretty "plain" at the moment, but surprisingly, it actually works. I think I can work out some of the kinks. But the biggest kink is that I can't figure out how to generate a Custom HTML form without the form becoming the active window on the screen. Maybe there is no way, which means my utility will end up with a lot of "screen flickering".

That's how global variables are managed. now let's talk about the possibility of local variables. Since local variables are outside the scope of an asynchronous Custom HTML macro, my macro cannot access them directly. I've considered a workaround of allowing the calling macro to pass the value of the local variable along with its name. That would probably be implemented by a subroutine that passes both the name and value of a local variable in such a way that the local variable's name and value can be store in a dictionary. As you know, all dictionaries are global variables, so that could be a workaround. But the problem here is that the calling macro has to call the subroutine frequently, which kind of defeats the purpose.

This whole utility is just an experiment. Perhaps it will turn out to be useless for most people. But for today, it's exercising my brain.