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.
Example:
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.