Cluster, Array, List or a mix of all? Some UI thoughts

[drjdpowell]

If I was going for the look OPs wants. I would first consider a cluster-of-clusters as the display. 

The inner cluster would be a horizontally-autosized cluster that is one row, containing all controls I might need. I would have ValueDBLand ValueString, for example, and hide the one not used.

There would be 50-100 of these row clusters in an outer cluster that is autosized vertically, and would hide rows not used (50-100 is the most rows that can show on the screen at once).  Actual data would be in an array, and there would a separate scrollbar.

With a cluster-of-clusters, one can full customise each row (hiding/disabling controls, changing captions, etc.).

[santo_13]

Your UI requirements sound partially like what is available in this addon, see if the demo videos and the UI inspires you (you can even try the trial version)

https://www.ni.com/en-us/shop/software/products/semiconductor-device-control-add-on-for-instrumentst...

[VinnyAstro]

---

@Hooovahh wrote:

---

Several times I've done something like this.  The data behind the scenes is an array of a type def'ed cluster.  Each row in the MCLB is an element of the cluster.  

---

Did you mean an element of the array? Or really an element of cluster?

I'm not sure to understand the point of having an array of already detailed cluster and translate it into a MCLB?

Otherwise, an array of (type-defed) clusters OR a mix between MCLB + Array of values, seems the easiest right not to me for Implementation, maintenance, stability toward changes and adaptation in case of different devices.

I like the idea with the tree control. But my colleague and I agreed that in case of new parameters added to the list (that would potentially require new sections) and/or new devices with complete different set of parameters, it would be eaiser to loads a file with the paramteres names and IDs and to read the EEPROM and associate the values.

[VinnyAstro]

---

@santo_13 wrote:

Your UI requirements sound partially like what is available in this addon, see if the demo videos and the UI inspires you (you can even try the trial version)

https://www.ni.com/en-us/shop/software/products/semiconductor-device-control-add-on-for-instrumentst...

---

Looks like a nice add-on. But our devices have in-house software which I'm not sure would adapt to these very generic interfacing.

[wiebe@CARYA]

---

@VinnyAstro wrote:

---

@Hooovahh wrote:

---

Several times I've done something like this.  The data behind the scenes is an array of a type def'ed cluster.  Each row in the MCLB is an element of the cluster.  

---

Did you mean an element of the array? Or really an element of cluster?

I'm not sure to understand the point of having an array of already detailed cluster and translate it into a MCLB?

Otherwise, an array of (type-defed) clusters OR a mix between MCLB + Array of values, seems the easiest right not to me for Implementation, maintenance, stability toward changes and adaptation in case of different devices.

I like the idea with the tree control. But my colleague and I agreed that in case of new parameters added to the list (that would potentially require new sections) and/or new devices with complete different set of parameters, it would be eaiser to loads a file with the paramteres names and IDs and to read the EEPROM and associate the values.

---

Note that a tree control is multi column. It's basically a multicolumn listbox, where the 1st column is hierarchical.

So, you can have a tree for your value hierarchy, and show current values in the 2nd column (if you're careful with efficiency).

Not that his solves your problems, but it does give you more flexibility...

You can of course combine most of the suggested ideas, like using a tree with dialogs to set values, or overlaying controls over the tree when clicked.

[Hooovahh]

---

@VinnyAstro wrote:

---

@Hooovahh wrote:

---

Several times I've done something like this.  The data behind the scenes is an array of a type def'ed cluster.  Each row in the MCLB is an element of the cluster.  

---

Did you mean an element of the array? Or really an element of cluster?

---

Yeah element of the array, sorry.

---

@VinnyAstro wrote:

---

I'm not sure to understand the point of having an array of already detailed cluster and translate it into a MCLB?

---

Just for a simple, and consistent UI/UX experience.  It isn't required obviously.  Some of my typed clusters are quite complicated, and contain all kinds of data that the user isn't interested in.  Showing them that would confuse the user.  Some times there are variants, or classes, or clusters of a cluster.  Handling that in a custom dialog that can show or allow the user to change parts of it looks nicer.

[VinnyAstro]

---

@Hooovahh wrote: Just for a simple, and consistent UI/UX experience.  It isn't required obviously.  Some of my typed clusters are quite complicated, and contain all kinds of data that the user isn't interested in.  Showing them that would confuse the user.  Some times there are variants, or classes, or clusters of a cluster.  Handling that in a custom dialog that can show or allow the user to change parts of it looks nicer.

---

Ah yes, that's a very good point, I also have a lot of info that I don't necessarily want to display to the user and was thinking of having separate arrays. Which would work I guess, but isn't optimum.

Also I've realized two things while playing around:

-It is possible to disable one element of the MCLB, but not at runtime (?)

-Even if the MCLB is has its "Editable Cells" property set to false, it is still possible to allow the user to edit it via a Double Click event and the "EditPos" property. Not sure that it serves any purpose, except maybe having a more direct way of communicating to the user that a cell is not editable by filtering by Rows. (The "Edit Cell?" event does the same by discarding the event, but only after the user edited the cell)

[BertMcMahan]

I had a similar need and wound up developing my own Datagrid QControl:

https://forums.ni.com/t5/QControl-Enthusiasts/The-DSM-Datagrid-yet-another-Datagrid-QControl/td-p/42...

It's OOP, but you shouldn't need to do TOO much new stuff with objects to get it working. The main benefit to this one over the others I've seen is that you can redefine the grid at runtime, not just at edit time, so you can disable/enable individual cells or rows all you'd like.

I'll admit I don't post much code for others to reuse so it's not nearly as polished as I'd like it to be, but I've used it in many applications and it does work well. It does NOT work as a tree control- though that'd be nice, I haven't needed it yet so I haven't made it yet.

If my toolbox doesn't suit you then there's at least one (maybe two?) other QControls out there that implement Datagrids, as well as the previously mentioned .NET datagrid. I haven't used those much as my need was specifically for something that could be created and modified at edit-time, not at compile-time like most (all?) of the other Datagrids.