Added NET8 compatible ONIX Hub updater

[aacuevas]

• Adds a C# .NET 8-based hub updater with GUI
• Requires clroni compiled with net8 support (built for now using https://github.com/aacuevas/liboni/tree/issue-25 built as a nuget package in a local nuget repo)
• Fixes Create a C# GUI programmer for hubs #8

[jonnew]

One thing I noticed. If I have a context opened in some other software (e.g. Bonsai or oni-repl) and attempt to program I get this exception:

Nothing crashes or anything, but perhaps the exception text could be a bit clearer.

[aacuevas]

Fixed. Now it passes the inner oni exception through.
Which when using the current liboni branch with support for NET8 is the all too familiar "Already triggered operation, but that will change to the new we made once liboni is properly merged.

[jonnew]

Another non-breaking but odd behavior:

If a connect to a headstage by pressing the "program" button on the main form, the little modal GUI pops up with an hourglass indicator. The fields then populate with the detected headstage metadata. Great.

The odd behavior is that if the mouse is not moved during this time period, the "program" and "Cancel" buttons will remain greyed out and the hourglass indicator will remain forever, until the mouse is touched.

[aacuevas]

I'll look into that but I'm not sure that is something we have control over or it's a windows forms quirk

[cjsha]

I've got some questions/nit picks after writing some documentation:

---

Is it true that the highlighted fields only show minor version i.e. this corresponds to v0.4.0? Would the a headstage have a major version update and would that information be indicated here?

---

Since device is a specific term in the context of ONIX, I feel that the highlighted part should be labelled "Connected Hub:" or something?

---

Is this software versioned? The other controller & breakout board updaters are built, zipped, and hosted in the onix-docs repo, with their version indicated in the zip file name. I figured I would follow the same pattern for this software for now.

[aacuevas]

Ah, good catches.
We were testing functionality and I forgot about these things. I will add functionality so the text versions are converted from number to proper version numbers
Same as the label name, thanks!

It is not versioned yet, but I will add some version number somewhere, that's a good idea

[cjsha]

I also feel the UI could be improved if it's a single dialog instead of two, for example (here's something I painted from the screenshots above):

The "File:" fields get populated when the image file is selected and the "Device:" fields get populated when Port is selected. I accidentally left out the "Program" button, but basically it would be greyed out unless the "File" and "Device" fields match. There could also be a message box indicating if it's ready to be programed or why the "Program" is greyed out if not.

I don't know if we're taking input on the UI, if it's worth the time to make these changes, or if people will even agree with this feedback, but I figured I'd mention these thoughts jic y'all agree, before this hub updater is published

[aacuevas]

The reason for the second dialog is that we need to know which headstage we're supposed to be targeting before. This is because we are using different power-scanning algorithms for each headstage. It's the same situation as with onix1, in which the power-scan is performed by the Configure*Headstage node. (In fact we are using the same algorithms)

So, in the current form, selecting the file is the way of specifying which headstage to use and only when the second window is opened the programmer tries to do the power scan and connect to the headstage. Data on the first window is from file only, on the second is from connected headstage as well.

If we reorganize the windows, we need to enforce this sequence (first select hs, then connect, then program) in any other way.

[cjsha]

ah, I didn't consider that. Thanks for the response