This question occurred to me when designing and building a new feature for some commercial software.
"Why is wxComboBox not a wxComboCtrl?"
Background info: I needed our application to check a setting in a configuration file, and if the setting was off, the code in one place would continue to behave its old way, using an older class derived from wxComboBox. If the setting is on, it should use our new class derived from wxOwnerDrawnComboBox, with new improved behavior. (This way, some people could test the new behavior while others testing other functions would not have it interfere.)
Imagine my surprise when I found there is no "single common ancestor" class shared by wxComboBox and wxOwnerDrawnComboBox, that defines the minimum interface for things that all combo boxes ought to be able to do? I ended up making my m_pComboBox member variable a wxControl* and had to hide ugly non-polymorphic code inside a family of helper functions.
After learning a lot more about those classes, I probably actually already know the answer to the above. ("wxComboCtrl contains things that are not needed or not wanted in wxComboBox.")
Instead, I guess the real question is:
"Why is there no 'single common ancestor' abstract class shared by all combo-box classes?"
All the combo box classes (with the strange exception of wxRichTextStyleComboControl) seem to have the ancestors wxControl, wxTextEntry, and wxItemContainer in common. Surely there could be a way to wedge an "all combo-boxy controls" class in between wxComboCtrl and its parents wxTextEntry and wxControl? That would be a huge improvement (in this one tiny area) for the next version of wxWidgets.
Why is wxComboBox not a wxComboCtrl?
Re: Why is wxComboBox not a wxComboCtrl?
BTW: This is a user forum, if you want to talk to the core wx developers, use https://groups.google.com/forum/#!forum/wx-users
So i'm only guessing based on the class hierachy: wxItemContainer is the big difference between the two. wxComboCtrl can theoretically display anything in its popup, it's not limited to a "list of items".
So i'm only guessing based on the class hierachy: wxItemContainer is the big difference between the two. wxComboCtrl can theoretically display anything in its popup, it's not limited to a "list of items".
Use the source, Luke!
Re: Why is wxComboBox not a wxComboCtrl?
Hi,
On top of doublemax' reply:
The popup itself can be anything, say wxGrid.
Thank you.
On top of doublemax' reply:
The popup itself can be anything, say wxGrid.
Thank you.
Re: Why is wxComboBox not a wxComboCtrl?
Thanks! That's useful to know.doublemax wrote:BTW: This is a user forum, if you want to talk to the core wx developers, use https://groups.google.com/forum/#!forum/wx-users
And thanks for the rest of the comments, too. If it's okay to continue the discussion, I think that would be valuable for refining my thoughts before I would presume to take up any of the core developers' time. (Realizing that volunteer time is precious!)
.
Re: Why is wxComboBox not a wxComboCtrl?
As far as the fact of the popup being virtually anything, I understood that, which is why I thought there should be a class just "North" of wxComboCtrl, and not something that drew together all three ancestors including wxItemContainer.
What I was thinking was that even the popup can be abstracted to the generalism of "a selector." In other words, anything we might consider "a combo box" consists of:
You could just use a wxGeneralizedCombo* to hold a combo box if you didn't know what type you'd have until runtime. You'd have access to far more functionality than you would if all you knew was that it was a wxControl*. Of course, you'd still have to dynamic_cast downward if you wanted the specialized functionality of any of the concrete classes.
Thoughts? Commentary?
What I was thinking was that even the popup can be abstracted to the generalism of "a selector." In other words, anything we might consider "a combo box" consists of:
- A display field of some sort, showing a single "active" or "selected" choice of some kind (or nothing),
- A button or actuator to show (or possibly toggle):
- A popup "selector" of some kind that displays some information -- probably a collection such as a tree, grid, of hierarchical menu, but not necessarily limited to such -- and which lets the user make a decision resulting in a possible change in the display field.
You could just use a wxGeneralizedCombo* to hold a combo box if you didn't know what type you'd have until runtime. You'd have access to far more functionality than you would if all you knew was that it was a wxControl*. Of course, you'd still have to dynamic_cast downward if you wanted the specialized functionality of any of the concrete classes.
Thoughts? Commentary?
Re: Why is wxComboBox not a wxComboCtrl?
This maybe good in principle, but it will never happen.
First of all - wxComboBox is a very basic NATIVE control.
Everything else is custom drawn.
Thank you.
First of all - wxComboBox is a very basic NATIVE control.
Everything else is custom drawn.
Thank you.