Touch Screen Issues


We have a new client that is using touch screens for the clients and I’m noticing some disturbing problems that the lack of a real keyboard and the fact that the client is configured for the whole screen (No Windows task bar).

  1. When an error, warning or message screen pops up the components are not sized to be touch friendly (Larger).
  2. When an error, warning or message screen pops up, if you miss and touch the client window the client window will come to the front and take focus. There is no easy way to get the system.gui window back to the front. And if any additional errors occur, you will not notice them. I’m presently attempting to test a modification to a forum post where they made a client timer event script that would CLOSE untitled windows, I’ve modified it to give the window focus and bring it to the front. So far it hasn’t worked.
  3. If you update the project, the message bar that you have to touch in order to update the project is too small to touch easily/reliably.
  4. If you update the project and manage to press the bar to indicate you wish to update and then miss the yes/no confirmation box there is no way to bring it back to the front AND you can’t do ANYTHING with the client screen other than finding a keyboard somewhere or power cycling the client PC. I even tried long pressing the screen to see if WINDOWS would pop up something and it didn’t.
  5. There doesn’t seem to be a built in Modal popup window. I’m getting around this using a trick I found in the forum, but it’s a pain to add this semi-transparent component to EVERY main window defined AND make sure that it is in front of all the other components. This relates to touch screens because the selection is so imprecise.
  6. You have a project level setting for scrollbar width, but you don’t apply that to the dropdown button or the spinner buttons. Again I found a scripting work around for that on the forum, but it is a pain to add that script to every dropdown and spinner component used. With spinners its acerbated by the fact that the button is 1/2 the height of the field, but nothing you can do about that. It was also a pain to determine how to get the value of that project level setting.

Even after all the above is said, the customer is still happier with the performance of the touch screen interface than they were with the old system we are replacing.

And, I’m sure I missed a few of the things that have been bothering me about the touch screen interaction.

1 Like

Just asking, are these TV/Computer style touch screens or are they Industrial HMI type touch screen?

For numbers 3 and 4, I’m wondering why you’re not pushing your updates instead of using the notify option. This can be changed in the project properties.

I consider #1 and #2 to be bugs in the project for which the current behaviour almost guarantees a bug report. Use of try: except: in scripts, and try() in expressions give you the tools to programmatically prevent error windows. And any use of system.util.confirm() or system.util.messageBox() is also a bug in my book.

1 Like


No, I am presently using the system.gui.* functions to display Warnings, Errors and Messages. I am not terribly concerned with the exception handling errors.

Why do you consider the use of those provided functions a bug. Maybe you should be asking IA to enhance them so that for little things like providing feedback to the customer/user doesn’t require the developer to create a custom PopUp window for each and every little thing. The same goes for reporting Warnings and Errors to the user. Granted if I wasn’t attempting to for the most part match existing HMI screens, I would likely have attempted to do some kind of error indicator on the field with a bubble type error.

Even if you turn on the limits/bounds checking on input fields, they use the standard system.gui.* type screens. What, are you expecting me to redesign the wheel for simple things like that??


I don’t like to magically redraw screens on users. I prefer to give the user the option of when to apply updates to the screens.

Besides which, I am reporting things that could be better on screens where you do not have available a keyboard or mouse. Just telling the user not to do something is not an acceptable answer.

Usually, I’ve seen IA respond positively to suggestions on how to make the product better. Recently I’ve noticed that they improved the Python class handling in their editor as I had suggested 3 years ago. Even given that I was an odd bird actually using Python classes at all.

Industrial HMI all in one screens. Fairly costly made for damp environments. Lots of water and conveyors.

Did you ever find a better answer to #6? If not, can you provide the script you’re using, or the link to where you got it from?

Thanks in advance!


Nevermind, I found the link, thanks.


I set the spinner width as follows:

Add a propertyChange Event Handler for the spinner with the following code:

if event.propertyName in ('editor', 'componentRunning' ):
	# editor: designer preview mode
	# componentRunning: client
	from javax.swing import UIManager
	width = UIManager.get("ScrollBar.width")

And I define a Custom Method as follows:

def setWidth(self, width):
		self: A reference to the component instance this method is invoked on. This argument
		  is automatic and should not be specified when invoking this method.
		width: The button width
        # First component of the JSpinner should be the 'up' button
	btn1 = self.getComponent(0)
	# the field 'c' is returned by getPreferredSize() of the button
	c = btn1.getClass()
	sizeField = c.getDeclaredField("c")
	# set the new button size. only the width is used, the height is determined by the text editor
	from java.awt import Dimension
	newSize = Dimension(width,width)
	sizeField.set(btn1, newSize)

I do the same thing for EVERY Spinner. I would have put the setWidth function in a global or project helper script but I have experienced lots of difficulties with the reliability for calling said helper scripts. I was disappointed when the case I opened about that problem was closed without a resolution.

Hope this helps somebody!


Can the spinner button width code work with version 8? I get the following error on the line with the getDeclaredField function.

java.lang.NoSuchFieldException: java.lang.NoSuchFieldException: c

I have not used version 8 yet.

Try finding the getPreferredSize method and calling that.

The error is indicating that there is not declared field “c”, which means it something else. I would also be aware of the 3 magic numbers in the above. The component 0, the accessible 1, and the component 2 layout any of those could have changed as well.

You might need to get down to the Java Swing component level in order to accomplish this now.

Good Luck!