Dialog with large and variable number of controls - C++ and WIN32



  • Our newest feature is connecting to analog input devices.  These devices range from having a few input channels to a boatload of input channels (there could be multiple devices too).  My task is to write the UI to select and configure these things.  I'm thinking of a scrollable list with each line having controls to configure the channel


    My first question: is this a good way to design this?  Second: any pointer on how to implement such a beast?

    Unfortunately, Google has not been my friend :( 



  • That seems like you're trying to solve a problem you don't need to have. 

    When I built something similar (using C++, MFC) a few years back, each device had it's own dialog that was designed specifically for it.  Each device was represented by a class, which was derived from an abstract base class which defined a virtual function called, let's say, "Configure()" which displayed the dialog and responded to what was set in the UI.

    It's a few years back now (well, ok, 9 years), so I don't recall all the details, but it worked quite smoothly.

    -cw



  •  Thanks for the reply, but I don't think device specific configuration helps here.  Some of the devices have 80 input channels.  Second, in this part of the application I'm try to list all the available input channels so the user can select which ones to use.  Separating them by device instance I think will make it harder for the user.  The user would have to go through multiple pages or dialogs to see which lines are active.

     Maybe that's the real question.  When presenting a large list of items is it better to paginate them and keep the onscreen list limited or is it better to huge list it?



  • @DogmaBites said:

    Maybe that's the real question.  When presenting a large list of items is it better to paginate them and keep the onscreen list limited or is it better to huge list it?
     

    Having a large number of controls or variable controls is usually a bad idea, but there are good alternatives. 

    Usually, if I have a large number of items that need individual configuration, I'd use a tree (breaking them up some meaningful way), and present the configuration in a property grid.  If you've got the user slaving away at a lot of settings, let them save, load, revert and apply these settings as a batch. 

    If there are standard colums, or some summary representation that can be made from the many channels, use a datagrid and assign appropriate controls to the columns that need user configuration.  If you absolutely can't use a C++ binding of the really good .NET DataGridView, CGridCtrl exists, and might suit your needs. 

     



  • @DogmaBites said:

    I'm thinking of a scrollable list with each line having controls to configure the channel

    My first question: is this a good way to design this?

    arty's suggestion regarding a tree is a good one.

    I would not put the controls themselves into a list or a tree. Instead, whenever the user selects a row in the list/tree, the controls for that device or channel should appear in an area of the window to the right of the list/tree. I doubt the controls for all channels need to be visible simultaneously, since the user can't very well manipulate more than one at a time.

    If it's necessary to show the states of all the channels all the time, you can do so in the list/tree by incorporating the information into each line's text.



  • I checked back here a little late, but some other people made the same suggestions.  Both the control grid idea and the simple list with the details on the side.  I will try the control grid first, as I think having all the details available is a little better than seeing only one at a time.

    Still, thanks to everyone for replying.  I don't do much UI work so I don't know what is available. Most of my work is communicating with various devices.  (So the computer will draw a line on the screen for you?  You don't have to set every pixel?!)


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.