Alarm Status Table change height at runtime

We’re trying to toggle between single line (no header, no footer, marquee mode–all handled by bindings) and full table at runtime with the code below. However, it produces no errors and… has no effect.

if event.propertyName == 'expand':
	from java.awt import Dimension
	alarmTable = event.source.parent.getComponent('Alarm Status Table')
	if event.newValue == True:
		dim = Dimension(573,200)
	else:
		dim = Dimension(573,20)
	alarmTable.setSize(dim)

Is there a way to do this other than creating two alarm status tables and swapping visibility, or is that the way to go?

Try using system.gui.transform(). Ignition’s look & feel is responsible for actually calling setSize() after setting the L&F so it’ll actually work.

2 Likes

system.gui.transform(alarmTable,newHeight=20)
system.gui.transform(alarmTable,newHeight=200)

Should do what you are looking for.

1 Like

Ha! Phil beat me by like 30 seconds :stuck_out_tongue:

1 Like

Thanks @pturmel & @MMaynard. I knew I was missing something obvious; no need to dig into Java here.

Here’s the script I ended up with on the alarm status table with custom property expand. Using the notes area it was necessary to change it and footer panel in the script (rather than bindings) and use invokeLater for the height change. Otherwise when contracted the footer would still be showing (and the only thing showing given the single row height when retracted).

# Toggle alarm table size.
if event.propertyName == 'expand':
	expand = event.newValue
	# Show notes area on north when expanded. Else hide it.
	event.source.notesAreaLocation = 5 if expand else -1
	# Show footer when expanded.
	event.source.showFooterPanel = True if expand else False
	# Expand/contract.
	def setHeight():
		newHeight = 300 if expand else 20
		system.gui.transform(event.source, newHeight=newHeight, duration=300, acceleration=system.gui.ACCL_FAST_TO_SLOW)
	system.util.invokeLater(setHeight)

Alarm status table refreshes its data with these property changes, so there’s a delay between expand/retract and redisplaying data, but it’s not too bad if the refresh rate is low enough. Interestingly, each refresh bumps CPU usage up noticeably (~10%) for a moment in Designer, though there is no noticeable CPU bump for this running in client running on same computer.

2 Likes