but I am somewhat stuck.
I understand that C# generally has better support for UI elements because it comes with Eto, C++ is pretty much limited to MFC forms, correct?
Doing the UI in C# and computing backend in C++ is not really an option, we use external libraries a lot, it would force us to build a pretty extensive C++/C# interface.
As for the C++ options, Rhino has some list controls, which seem to be extensions of the MFC CListCtrl:
CRhinoUiLayerListCtrl That seems to be the one in the screenshot above. More or less exactly what I would like to have, but specifically designed for layers and no easy option to modify for a different purpose. Having the sourcecode would help a lot…
CRhinoUiGridListCtrl seems to be a little more “basic”, is that still in use or legacy? The only reference I could find is from the Rhino 4 samples. It also doesn’t do row-highlighting, transparent icons etc as the layer dialog does.
My best approach so far is to inherit from CRhinoUiGridListCtrl and do some custom drawing, but that feels like a re-implementation and would not result in exactly the same look and feel.
Any hints or suggestions?
Is there any documentation on UI development in general that I might have missed?
Not really… there are lots of UI libraries for C++, including wxWidgets for cross platform work.
You can also use Winforms and other .NET UI from C++ by building some connection infrastructure. Normally, this wouldn’t be encouraged in an independent app, but you have a special use case:
you know Rhino and therefore specific .NET assemblies are installed, so you’re not adding gigs of install package to get a dropdown list
and
you want to match the Rhino and other plugin UI
So, perhaps you should consider calling .NET from C++ in this case.
I’m looking at something similar: the big win if you do go to the significant level of trouble is potentially being able to target Mac as well as Windows. You need to compile the C++ separately (I’m looking at a straight text file interface to the calcs and using XCode to build executables on the mac).
OK, that’s true, but that’s not what Rhino uses. I would like to stay consistent if possible. wxWidgets or Qt could be an option though.
Good point, I was focused on calling C++ code from C#, but doing it the other way could be an option.
Supporting mac (and potentially other platforms) is generally an important point, however, in this particular case we are limited to Windows for different reasons anyway.
Following up on this: I still don’t understand how it is done in Rhino itself.
Are the classed derived from CListCtrl actually used in the current UI?
What about the updated layer panel in Rhino 8?
