Hi there,
Is there any way confugure the gui window’s styles.
Such as, in order to system.gui.confirm(). I want to manupilate the background color as black. Is this possible?
Thanks in advance.
No, the underlying modal dialog is supplied by java. Note that those popups are not recommended for general use, as they freeze the Vision UI while they are displayed. (A necessary consequence of freezing the script to get a return value.)
Make your own pop-up windows and you can style those however you like. Just don’t expect to freeze a script.
I see.
I’ve never needed a specific confirmation screen before. would it be the healthiest way to connect the button on my confirmation screen to a boolean tag and relate it to the script?
You should use a Client tag, not a regular tag. Client tags are local to the Vision client, so the “confirmation” wouldn’t be global.
Personally, where a two-step verification is required, I prefer to provide a “Write Mode” button on the same screen as the actual buttons, where the actual buttons don’t work until after write mode has been turned on. The write mode could be canceled on each use, so each action would need two steps. Or it could be time limited. Or some combination.
1 Like
This sparked me to a possible light bulb moment.
@pturmel Would that be equally true for a script with script based pop ups to grab text or numerical values?
Would it be better suited to use a distinguishable client tag for a text box in a pop up and use that value in the script? Vs a variable which is a input pop up using a scripting gui.
The other thing I’ve done in the past in Vision for confirmation popups to make them more generic, is to allow passing in function definitions to the popup for the No and Yes buttons to call when they’re pressed. This way you can supply the functions with commands in it that you want to run, rather than just a simple “set this tag to True”.
If you wanted to go with a simple confirmation popup that does that though, I would simply pass in the tagPath that you want to write to on “Yes” and the value you want to write it to. The No button would simply close the popup.
Additionally, if you want it to be “modal” (no interaction with the rest of the app), then you will need to fake this. I put a rectangle on every screen that covers the entire window, including the navigation dock set to transparent black with a mouse press event handler set to something inconsequential like simply 1 so that it does nothing but does consume the mouse event. I have a client tag storing the state of the modal flag which is set by any popup requiring modal, and reset whenever the window is closed
1 Like
If you are using one of the popups from system.gui.*Box, then yes, they all freeze the gui. I don’t use them, ever. It doesn’t matter whether you store values in client tags or elsewhere, it only matters that you not stop the UI thread. (Swing’s foreground thread, also known as the Event Dispatch Thread.)
1 Like
Thanks for the info. Im definitely going to have to explore this a little more. Right now I think this might be causing intermittent issues at my facility.
Im surprised this hasn’t been pointed out to me before in relevant post.
Im thinking a one click enter button will close pop up and process script. Should be fairly straightforward. I’ll hold the system.gui info I would grab in a client tag or property.
Im definitely gonna have to play with it more
Where can I learn more about this thread and what affects it?
Ask instead what doesn’t affect it. Because pretty nearly everything runs on the GUI thread in Vision. Event scripts, runScript and all other expression bindings, component methods, both events and extensions, plus custom functions.
Things that run in the background:
- Tag bindings, both direct and indirect.
- Query bindings, both legacy and Named Queries.
- Tag History bindings.
- EasyChart DB and Tag History pen data queries.
- Script functions started with
system.util.invokeAsynchronous.
The above bindings call out to the gateway in the background, then deliver the result value/dataset in the foreground thread.
1 Like
@pturmel would system.gui.showTouchscreenKeyboard or system.gui.confirm cause any thread issues? It’s not a system.gui.*Box but I would assume it could cause similar issues with threading.
Yes, those are both modal. Any system function that blocks to give you a response, is, by definition, hanging the event dispatch thread.
1 Like
@PGriffith , Is this where people start trying to delay scripts? I am not trying to. Just trying to see if there is a connection for my own knowledge?
Thanks
Delaying is a distinct (but related) concept.
Multi-threaded programming is tricky, and there’s lots of different ways to solve the various problems.
system.util.invokeLater literally puts the code you specify at the end of the current Swing ‘event queue’ (all mouse moves, keyboard interactions, clicks, types, window moves, etc). This allows you to wait for e.g., a table to be refreshed before trying to scroll down to the bottom, but it is not a panacea for all (or even most!) threading/concurrency problems.
The somewhat related system.util.invokeAsynchronous creates an entire new thread for your script to execute. This frees up the event dispatch thread (which is good for responsiveness) but, if you want your background thread to do anything with your GUI, you must use invokeLater to jump back to the EDT, or you risk deadlocks, because Swing assumes it can be safely run single-threaded.
4 Likes
Fwiw, I don’t really see locking up the gui thread as being all that terrible for things like prompts and touchscreen input when a user action initiates them. They explicitly issued the command to do the thing. They most likely don’t need to see updates in the background while they’re punching in numbers into a keypad or reading a prompt and acking
1 Like
They are fundamentally untestable with java.awt.Robot.
I guess if you use that, then that would be a show stopper for dev, but I don’t know any projects that have the budget for that kind of testing setup! But then again, we do mainly bespoke projects where customers are requesting changes to their unique systems. If you’re more OEM-type projects rolled out to many customers I can see where this makes sense
1 Like
I just needed a rebuttal. 
I don’t use Robot either.
If you can truly stick to popups that are an immediate consequence of a user action, then you have a point.
5 Likes
Well there goes my lightbulb moment. Lol.
Just to continue the trend of contrarianism thread but I have definitely used java.awt.Robot to click through system.gui.confirms before but it all requires invokeLater stuff. However, I have yet to find a better way to set up robot instructions than a list of that are all called via invokeLater with increasing delays so I never even knew of this limitation.
Code:
import java.awt.Robot
from java.awt.event import InputEvent
rob = java.awt.Robot()
rob.delay(1000)
def moveAndClick(x=910,y=580):
rob.mouseMove(x,y)
rob.mousePress(InputEvent.BUTTON1_MASK)
rob.mouseRelease(InputEvent.BUTTON1_MASK)
system.util.invokeLater(moveAndClick,500)
if system.gui.confirm("Please press yes"):
print "Success!"
So I don’t think it’s fair to say it’s completely untestable with Robot.
1 Like