In the ABL Wrapper webinar* the question was asked whether it was possible to remove the need to add code (to call MyToolbarsManager's Initialize method) to the containing form, thus removing the need for the developer to do it.
One potential option is to use the ISupportInitialize interface provided by WinForms. The ISupportInitialize interface provides a standard way to initialize an object before it is displayed, and requires the implementer provide BeginInit and EndInit methods. You might have seen these called from InitializeComponent in code generated by the Visual Designer. When EndInit is called, we can be sure that the object (control, component) has been created and properties set from the designer. So if one property depends on some other property, we can be assured that by the time EndInit fires, the properties have been set.
I had thought to use this approach to call the ABL Initialize() method in the inherited control (which fetches data and populates the toolbars). However, this did not work as planned, with the end result that the toolbars are duplicated in the UI, as seen in this picture. Note that the Initialize method is only called once (aka MY code works just fine )
This approach won't work here, for a couple of reasons, all stemming from the fact that the UltraToolbarsManager also implements ISupportInitialize, and does its own stuff there. These methods are furthermore implemented explicitly (a C# speciality) , which means the methods are named ISupportInitialize.EndInit; the ABL doesn't let us to call these methods as SUPER(). Furthermore, the ABL doesn't currently allow shadowing of control methods, and so we have no way of preventing the duplicate calls; while we do want both sets of code to run, we need to be able to define the order in which that happens.
I just thought I'd at least publish my findings, even though this method doesn't work in this particular case.
-- peter
* http://communities.progress.com/pcom/docs/DOC-102281
