In WinForms visual objects that inherit from Control are easy to use as they implement a fairly good amount of behaviour and properties.
Microsoft mistreated visual objects that inherit from Component. Component is quite generic and maybe they should have used VisualComponent or Element (as they did on WPF). The inerited Component has no provision for data binding, no name, no tag, almost no events, in short the inherited Component is pretty much useless.
But there is this ToolStripItem implementation that is inherited by menu and toolbar components in WinForms.
The inheritance in WinForms makes life a lot easier and allows for one very interesting trick that is used in the MvvmFx framework: the ToolStripItemProxy.
This isn’t possible under Wisej, as this kind of inheritance doesn’t exist on Wisej. The interface IToolBarItem might be an interesting feature if this interface was implemented by all “strip” and “bar” components: menu items, toolbar items and also status bar items. This would put Wisej a decade ahead of WinForms.
My suggestion doesn’t break anything at all. Just pick all the common properties of the referred components and abstract them on an interface. Then make all the selected components inherit from that interface.
Let me think and discuss this a bit. In general, the Component class in WinForms is also used for non-visual designer-enabled components, like the menus or the property extenders, or the timer, file systems, data sources. It would have been nice to have a VisualComponent in bewteen Component and Control.
I think that Wisej and WinForms will diverge when it comes to the ToolStrip system. Meaning that we will not implement the ToolStrip classes and duplicate the ContextMenu, ContextStripMenu, etc. We’ll keep one ContextMenu, ToolBar, StatusBar. In fact we are already adding the various additional component to the toolbar (ComboBox, Label, ControlHost, …). So I think that your proposal to make the status bar, toolbar and maybe the menu items compatible is interesting. Something like an IToolItem interface (so it’s not tied to the toolbar). The child collection will have to remain as they are to preserve compatibility, which means that the current classes will have to act as base classes, which also makes sense. Something like this (I’ll pass this around):
ToolBarButton : IToolItem
ToolBarComboBox <- ToolBarButton : IToolItem
..
StatusBarPanel : IToolItem
StatusBarComboBox <- StatusBarPanel : IToolItem
You get where I’m going with this. This way the StatusBarPanel Collection still returns and always returns StatusParPanel instances, which can be a StatusBarComboBox, StatusBarIcon, etc.
/Luca
Please login first to submit.
