Visual ActiveX Components

Hi,

one of the key features of Dolphin 4.0 is:

"Full support for hosting ActiveX controls within the MVP application
framework, and for creating ActiveX automation clients and servers. "

I interpret this statement, that it is possible to integrate *visible* AX
components into a view.
Am I right ?

After all, I couldn't figure out how to do this. Is it possible with the
ViewComposer ?

For example: I have created the wrapper classes for MSFlexGrid with the
ActiveX component wizard.
And now ? How to proceed, to embed it into a view ?

Can anybody point me in the right direction ?

Thanks

Ingo

Ingo

"Ingo Blank" <[hidden email]> wrote in message
news:3b0ae1fe$0$3083$[hidden email]...
Start by loading up the control into the AXControlBrowser, as this allows
one to explore the properties and methods, and to see the events that will
be generated. One can prod the control and watch it in action. The event
names can be dragged out of the event list if one later wants to wire up to
them.

Options for using an OCX in Dolphin 4
----------------------------------------
1) No new classes: Within an instance of AXControlSite, which is in turn
embedded into another view. The view can be accessed directly by name from
some parent presenter and then manipulated by requesting its
#controlDispatch, which will answer an instance of its default interface
(which will be a generated interface if one has previously generated it, or
just IDispatch if not). Any events that the control fires will be triggered
directly off the AXControlSite view, since there is no associated presenter.
2) Create a new View class, but no Presenter: Subclass AXControlSite,
override #defaultProgId to answer the progId of the specific control, and
add behaviour specific to that control. Again the view must be accessed
directly from a parent presenter, but this time we can treat the specialised
AXControlSite as a "component", and normally one shouldn't need to to go
delving into it get at the #controlDispatch interface.
3) Create a new Presenter class, but no specific View class: Subclass
Presenter (or maybe ValuePresenter, or even one of the other presenter
classes if appropriate). In this case the Presenter is the "component".
4) Create an entire new MVP triad. For example a RowColumnPresenter
appropriate for presenting two-dimensional data Models, and into which could
be plugged a variety of "table" or "grid" like views. An abstract interface
(protocol) for the model will also be needed, including the events it fires.
Concrete Model implementations will then be needed, and potentially these
might be generic as well.

Rules of Thumb
----------------
(1) is appropriate for once-off uses and for exploration. If I were Kent
Beck I would probably start with it anyway until the need to refactor became
overpowering, but as I am not I would probably do the next most simple
thing, and go for option (3).
(2) is most useful where one is trying to create a View which is compatible
with an existing presenter; for example we have a wrapper for the MaskedEdit
control which we will be shipping in the next release, this implements the
<textView> protocol which TextPresenter expects of the views to which it
connects. Integrating a new control with an existing type of presenter is
not likely to be something one needs to do often.
(3) is likely to be the most appropriate trade off between effort and
re-usability in the case of most controls. Most controls are quite
specialised, and to designing a new generic pairing (as in the last option)
will involve a great deal of thought and effort and probably a few
iterations through to get a satisfactory result. In pursuing this approach
one avoids the temptation to get over-generic too soon, and so one just
designs and implements a specific Presenter which exposes those parts of the
OCXs functionality that one needs.
(4) is the most work, and the most abstract of the approaches. To be done
effectively it probably requires prior experience at using a number of
similar controls so that one can draw out the generic features in order to
design the split of responsibilities between the View and Presenter most
appropriately, and to design the protocols that will be used to communicate
within the triad. One also needs to design the protocol to be called by the
clients of the presenter, and the event protocol it will publish to those
clients.

Although the MSFlexGrid is an obvious example of where a View class could be
implemented to plug into a new generic Presenter and Model, I would not
recommend starting there. Start with something more specific, personally I
would go for (3) most of the time, and write a specialised Presenter with
which I associated a default view containing an appropriate configured
AXControlSite instance hosting the OCX. This specialised Presenter can take
care of transferring data into and out of your model by first populating the
control from the model, and subsequently intercept events in either
direction and updating either OCX or model.

There are some existing examples in the image. The AXControlBrowser is an
example of a tool that embeds OCXs, in this case dynamically. The
SimpleWebBrowser makes use of a (very simple) new generic Presenter,
URLPresenter (from the 'Internet Explorer' package), but has no dedicated
view class or model. This is possible because it uses an
AXValueConvertingControlSite which is much the same as ValueView, in this
case the value being the URL, treated simply as a String. There need to be
more examples, and we will be adding those with new releases, the MaskedEdit
package I mentioned being one example.

Regards

Blair

Wow !
A lot to read and a lot to think about.
But now I see light at the end of the tunnel.
I made already some little experiments of type 1.) and it's amazingly easy
because Dolphin is so fantastic interactive.

Thanks Blair