Smalltalk › Usenets › Dolphin Smalltalk

ActiveX and MVP: Implementation Strategy?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Eric Taylor

ActiveX and MVP: Implementation Strategy?

Hello Forum,

As any of you who have worked with ActiveX controls knows, deploying ActiveX
can be problematic. It is recommended that ActiveX controls be added to
views dynamically in order to ensure proper instantiation, and to allow the
developer an opportunity to trap a misbehaving ActiveX control _before_ opening
the view. This becomes particularly critical when the manufacturer of the
control decides to release an upgrade. In Eiffel, for example, which also
has a COM wizard that works in a manner very similar to Dolphin's, I generate
the classes at design time, but defer instantiation of the ActiveX control
until program execution. I use a reference rectangle on the form to aid
in the proper placement of the control, and then destroy the rectangle once
the control is placed.

This brings me to two questions:

1. What is the Dolphin community doing in this case? Are you assigning the
progId dynamically, upon showing the view?
2. How does one go about integrating an ActiveX control site into MVP? Are
you creating a full-blown MVP component of the ActiveX control itself, and
then incorporating that component into the view in the normal way, so that
it becomes yet another Presenter established in #createComponents?

I suppose I have another question: Does the Dolphin framework provide a means
to manage ActiveX upgrades, which is the trickier part of ActiveX deployment
(usually)?

Thanks.

Cheers,

Eric

Chris Uppal-3

Re: ActiveX and MVP: Implementation Strategy?

Eric,

> 1. What is the Dolphin community doing in this case? Are you assigning
> the progId dynamically, upon showing the view?
> 2. How does one go about integrating an ActiveX control site into MVP?
> Are you creating a full-blown MVP component of the ActiveX control
> itself, and then incorporating that component into the view in the normal
> way, so that
> it becomes yet another Presenter established in #createComponents?

I don't use ActiveX myself. I just wanted to point you at a few examples in
the image.

MaskedEdit and MonthView are both examples of View classes built directly on
top of ActiveX components. They "know" what kind of component they use, and
instantiate it as they are shown. Other than that they are coded to act as
normal MVP components and their use of ActiveX is hidden from other classes. (I
think there may be the odd bug in the way the masked text component links the
ActiveX control's idea of its 'value' with the value of the MVP Model).

The 'Simple Web Browser' and 'Autoplay' sample package, and the underlying
'Internet Explorer' package are example where the more flexible and generic
AXControlSite (or actually AXValueConvertingControlSite) is used "raw", but
preconfigured (rather than hard-coded) to hook up to the IE control at startup.

The ActiveX Control Browser itself uses an AXControlSite, but in a still more
dynamic mode, where it dynamically chooses what control to show in the site.
Presumably you could use similar logic to postpone instantiating the control in
your own code (set it up in #OnViewAvailable, perhaps).

Which of these would be considered 'best practise', I have no idea...

-- chris

Eric Taylor

Re: ActiveX and MVP: Implementation Strategy?

Hello Chris,

I'm always hesitant to take examples as standards. The ActiveX Control Browser
is not an example, however, and its design does revolve around a more dynamic
model. I'll take a look at it more closely.

Thanks very much.

Cheers,

Eric

> Eric,
>
>> 1. What is the Dolphin community doing in this case? Are you
>> assigning
>> the progId dynamically, upon showing the view?
>> 2. How does one go about integrating an ActiveX control site into
>> MVP?
>> Are you creating a full-blown MVP component of the ActiveX control
>> itself, and then incorporating that component into the view in the
>> normal
>> way, so that
>> it becomes yet another Presenter established in #createComponents?
> I don't use ActiveX myself. I just wanted to point you at a few
> examples in the image.
>
> MaskedEdit and MonthView are both examples of View classes built
> directly on top of ActiveX components. They "know" what kind of
> component they use, and instantiate it as they are shown. Other than
> that they are coded to act as normal MVP components and their use of
> ActiveX is hidden from other classes. (I think there may be the odd
> bug in the way the masked text component links the ActiveX control's
> idea of its 'value' with the value of the MVP Model).
>
> The 'Simple Web Browser' and 'Autoplay' sample package, and the
> underlying 'Internet Explorer' package are example where the more
> flexible and generic AXControlSite (or actually
> AXValueConvertingControlSite) is used "raw", but preconfigured (rather
> than hard-coded) to hook up to the IE control at startup.
>
> The ActiveX Control Browser itself uses an AXControlSite, but in a
> still more dynamic mode, where it dynamically chooses what control to
> show in the site. Presumably you could use similar logic to postpone
> instantiating the control in your own code (set it up in
> #OnViewAvailable, perhaps).
>
> Which of these would be considered 'best practise', I have no idea...
>
> -- chris
>