A Desktop App Strategy Question

Greetings Xojo folks -

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.

Thanks, Paul -

Have used ContainerControls very little. Will have to review and see what they might add to the solution.

Cheers
Jim

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.

Thanks, Kristin -

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!

Jim

James Wagner
Oregon Research Electronics