This is a bit of an open-ended question. I would have liked to ask something more concrete, but this is what I have.
Oregon Research Electronics, which is basically me, manufactures a small number of scientific instruments (http://www.orelecctronics.net). The instruments all use a terminal-based menu system to configure them for use. We are working on a major product upgrade and envision that to use a very similar menu system with menu variants depending on the product version. The device identifies itself, by model and serial number, in the first lines of the menu.
I’ve taken several stabs at creating a GUI to replace the terminal. They have worked but I’m less than thrilled with the results. Even worse, it would have to be rewritten when the new products come along.
To somewhat solve the obsolescence issue, I’ve been thinking of “version files”, maybe xml, that could be added after the GUI was written. This could solve the problem of parsing the different variants. And, I think that there will be a maximum of perhaps 6 or so window formats needed to deal with each of menu items.
But, I am lost, at this point, on how to organize and display the topic windows in a way that is driven by the xml file for that product variant. Presently, I’ve been using tab panels and page panels to organize things into a sort of hierarchical arrangement. I’m not convinced, right now, that that is the most flexible or appropriate way to do it.
So… I’m looking for suggestions about how to organize and display various menu topics that is flexible toward future versions.
Many thanks
Jim Wagner
Oregon Research Electronics
You might consider using ContainerControls to group things into re-usable components that you can then mix or match on Windows or within TabPanels or PagePanels.
Alternatively you can generate the UI dynamically at run-time using Control Sets or ContainerControls.
Cool products! As a bit of a ‘data-geek’ myself, I’m fascinated by data logging and analog to digital conversion was a big part of my grad project back in electronics college.
My honest opinion is that the software for configuration should be self-contained within the device and accessible via a web browser (like a wifi router). That way, you don’t have to worry about platform or OS version compatibility… as long as they can hit it with a browser, it’ll work.
Embedding a Raspberry Pi would be my first choice and depending on the micro-controller muscle required, you might even be able to base your new product completely around it. It would reduce the I/O complexity by using ethernet or wifi (or even BlueTooth) instead of a serial bus. Whether you use Xojo to create the web app or something even more basic, this is a classic Internet Of Things (IOT) example.
Imagine being able to walk up to that tree with your iPhone… connect to the device wirelessly from the ground, and download the latest data. Or, have it connected to the internet and check the data remotely!
You could even embed a RESTful API to serve out raw data to clients who really want to do their own thing with it.
More specifically to your question, I would be tempted to write a different app for each device rather than create a one-size-fits-all app that morphs itself to the needs of the device… but I suppose that would depend upon how much is different between the devices.
Paul’s idea of using containers might work… it’s not far off from simply creating different windows for each device and then dynamically choosing the correct one when the user asks for one.
The one thing about a single parent window with a ContainerControl vs different windows is that it makes more sense to embed the menu item chooser in the single parent window. You are probably right, however, that the difference is pretty small. I really had not given the idea of separate windows much thought. Appreciate the nudge!
ContainerControls are way powerful. They can be deeply nested to build up very complex and reusable controls, or controls within controls within controls. Don’t think of them as simple monolithic “window” for each device you are supporting, like a single tab. I mean you can do that too, but that’s just not fully realizing their power.
For example, I have a custom search control that is a ContainerControl that pairs a EditField with custom border, (X) clear button, dropdown menu, and other features. Then that “search” Container Control is embedded in another “list header” style ContainerControl has handles displaying a Title, another popup menu, its own (X) close button, and other functions. Then that “Header” ContainerControl is embedded in a custom “content” ContainerControl that includes another custom Canvas to display content, and another “footer” ContainerContainer. The footer control of course has multiple CC’s as well. Then this “content” container control can be embedded directly into a standard window, TabView, or another CC if needed. Whew! But you can see how the CC alone can be a heavyweight for organizing things…