Dynamic Control Creation

I searched and found one post concerning this prior, and the solution was to pre create controls and toggle their visibility via script.

This is fine and well provided that the number of controls is known ahead of time.

I am integrating with another system and parsing its XML configuration files for use in ignition.

The intent is that it will be tabbed pages by section, and N buttons per page all dynamic and no possible way of predicting ahead of time. SO I could conceivably have one tab page with three buttons, or ten tab pages with anywhere from 1 to N buttons per page.

I would assume that I can enumerate this file and declare new buttons, set their properties, add tab pages (set the tab page properties), add the buttons to a page and position them like I would in any other IDE or or language, is this possible with ignition?

Can you tell us a little more about what you’re trying to do?

Is your intention to parse the XML configuration and create these screens once, in the designer?

Or are you thinking you can do this in the clients at runtime? As in… there’s nothing, then you somehow acquire and parse this XML, and now you have screens with something (in just this client? all the clients?), all happening in a running client?

Yes, each machine running a client has an XML configuration file for the other system, and its location is known.

So the file will not be shared between clients, simply present on the client computers, and unique to each.

So rather than design and edit a series of screens in ignition based on the information contained in those filed (which are edited externally to ignition), it would seem more logical to dynamically build screens client side based off the information.

So in the internalFrameOpened event script, I can read the XML file, parse the appropriate section, and dynamically build a selection screen based of the information in it.

Since the other system maintains the file, it could change once a month or 5 times an hour, pre configured ignition screens could never be maintained in a sane way to keep this integration.

I have all of the details worked out and functioning except the screens them selves (locating, reading, parsing the XML, etc) Now it is a decision of GUI to present in order to use the inputs there.

A location wants to provide the user with the ability to select their name in the system.
Some systems will have many users, so it is logical to break down name selections by A-M / N-Z, Shift A / B, or any other conceivable sub division for narrowing down where to find your name. System B achieves this by way of a flattened tree structure much like an MP3 player’s menu where you can navigate up and down nested groups to items that can be selected.

System B allows this to be configured at the users will, nested as complex or simple as they want, and we would like to present the information in a similar format in Ignition.

So the simple solution would be for each group, create a collection of tabs of possible sub groups, and a screen of buttons of possible selection.

Any tab selection repeats the process until a user selects an item.

Let me start off by saying that I totally get what you’re trying to do.

Currently, in Ignition, there is no way to generate components on the fly like this.

That said, I have a plan for a way to do this, and I’m really hoping to get it into Ignition 7.7

It will be a special component inside which you will be able to programmatically instantiate template instances, and at any location. So, you’d be able to stretch one of these across your whole window, and then instantiate templates to your heart’s desire (or, at least, to the XML file’s desire).

What type of time frame would we be looking at for 7.7

Likewise how stable should I anticipate it to be? No offense intended, but having written software for years, I know that the first non developer that touches anything I have written will try the exact thing I would have never considered as their first effort. If the first hands on are another developer… it is almost a grantee, therefore I never base a production system off round one of anything I write either :wink:

I am trying to replace a method already started by one of our other people whereas he was drawing buttons as rectangles, on a project that would need to be in place mid to end September with some buffer in between to actually write and test it, so I would have to be hands on as early into September as possible.

If not, suggestions on reasonable work around until I can get in a more elegant and maintainable way?


The time frame for 7.7 is… next year… some time… when it’s done. :thumb_right:

Sorry, I know that doesn’t really help you out now. There’s not really any work-arounds for what you’re trying to accomplish.

“When its done…” good answer!

Man I wish I could get away with timelines like that, around here it is “Just finish it after it is deployed.” directives . :slight_smile:

Well… In the mean time I must come up with some creative solution, so I will let you guys know what it ends up being and post a screen shot or two.

[quote]“When its done…” good answer![/quote]Yeah…rushing releases never turns out too well…

Depending on how complex these things are that you want to display, and how much they need to respond to user interaction, you might be able to use the Paintable Canvas component as a workaround.

Proposed plan is create a utility script to handle the details where needed and then use it in the paint events on a paintable canvas.

This produces the following output

And is written as below

Anyone see any issue with pursuing it like this until you guys get a better method in place?

Issues I would be concerned with ahead of time would be excessive object handles / memory leaks.
I am reusing everything vs making it on the fly in paint, but it depends on how the garbage is taken out in the system if this will end up an issue.

Those images don’t seem to be coming through…

Hmmm, attached to this one…
They appear fine on my side.

This looks fine to me. I wouldn’t worry about excessive object creation or memory issues. Your objects will be garbage collected just fine, and the paintable canvas doesn’t paint unless something has prompted it to, like a custom property changing or someone invoking repaint on it.

Hi Carl,

I notice that XML is used to copy and paste gui components in the designer. Is there a way, perhaps, to dynamically “paste” xml into a panel or is this sort of functionality only in the designer, and never deployed with the client (as it would not normally be necessary in the client).

Yeah, you got it - that XML is only processed for pasting by the designer.