The Dolphin Framework: Why Bound to Windows So Quickly?

Hello Forum,

We spent most of today getting familiar with all of the classes that
implement menus in order to abstract Codejock's XtremeCommandBars
ActiveX control.  So, as we would do with any framework, we set out to
leverage the work already done in the framework.  We identified the
following classes:

Menu
   MenuBar
MenuItem
   CommandMenuItem
   DividerMenuItem

We settled on the following scheme:

Menu
   MenuBar
      XtremeMenuBar
MenuItem
   CommandMenuItem
      XtremeCommandMenuItem
      XtremeDividerMenuItem

None of the Xtreme classes above would have anything to do with the
_view_ of a menu.  That would be the responsibility of the ActiveX
control encapsulated in the XtremeCommandBarsPresenter.  The idea was to
end up with something like:

xtremeMenuBarPresenter := self add: XtremeCommandBarsPresenter new name:
'xtremeCommandBars'.
xtremeMenuBarPresenter createMenuBar; drawMenuBar.

where #createMenuBar encapsulates the grunt work of building the model
of the main menu, and the model would then be utilized by #drawMenuBar
to load the Xtreme control.

But it seems that the framework is bound to the underlying operating
system immediately.  There doesn't seem to be an intervening layer of
abstraction of between MenuBar, MenuItem, etc., and the OS.  We began to
realize that there would be no easy way to simply build on these
classes.

It seems that MenuBar should have absolutely nothing to do with either
the display of a menu or Microsoft Windows.  As we've seen in various
Microsoft products' interfaces, a menu is not a menu is not a menu.
What about the following scheme:

Menu
   MenuBar
      MSWindowsMenuBar

so that one could leverage MenuBar like this:

Menu
   MenuBar
      MSWindowsMenuBar
         MSMoneyMenuBar
      MSOfficeMenuBar
         XtremeMenuBar
            XtremeOwnerDrawMenuBar

The various menu implementations are not simply instance variations, but
rather completely distinct behaviors (floating, docking, customization,
etc.)  The problem is that MenuBar has anyone who comes along afterwards
all tangled up in Windows details that pertain to one particular kind of
menu system.

This is critical to our design.  Directly accessing the ActiveX
control's dispatch violates encapsulation and would make for messy work
should Codejock change any of the implementation details.  We have no
problem developing a high-level interface at the Presenter level onto
the control.  But it would seem that that interface is already developed
in the Dolphin framework, so why reinvent the wheel, so we thought.
Also, mapping the ActiveX control's command dispatch events onto
Dolphin's messaging protocols won't be trivial (at least that's our
assessment), so any help from existing classes would be welcomed.

Cheers,

Eric

Eric,

> Menu
>    MenuBar
>       XtremeMenuBar
> MenuItem
>    CommandMenuItem
>       XtremeCommandMenuItem
>       XtremeDividerMenuItem

I suspect that you'd be better off creating a parallel hierarchy rather than
trying to shoehorn your stuff into a hierarchy which has been designed without
an explicit abstraction layer.  (I've done the shoehorn thing before and
regretted it).  Remember that in Smalltalk, subclassing is not the same as
subtyping.  Inheritance is primarily about inheriting implementation, and in
this case you don't want to inherit the implementation.

That does mean that you'll be duplicating code from the existing
implementation, but (without having tried it, nor even looked at it in any
great detail) I suspect that'd be the lesser of two evils.

It would be better, of course, for your purposes, if there had been an
abstraction layer there already, but there isn't.  So...

BTW, for OA, I suspect that the time might be ripe to consider introducing such
a layer (I think it would have been premature much before now).  Not only has
Eric hit this, but I've been looking into Rebars and the new-style menu bar
implementation (as in Internet Explorer).  It turns out that the new "menu
bars" are actually toolbars (inside a Rebar control) configured to look like
menus.  See (URL will probably wrap):
http://msdn.microsoft.com/library/en-us/shellcc/platform/commctls/faq/ietoolbar.asp

I'd guess that such menus will become de-riguer sooner or later (unless there
is something even weirder in the next version of Windows).

    -- chris

Hello Chris,

>I suspect that you'd be better off creating a parallel hierarchy rather
>than trying to shoehorn your stuff into a hierarchy which has been
designed >without explicit abstraction layer.

I left the office late last night, revolved this dilemma a bit in my
mind, revisited the issue this morning, and now, after having read your
reply, would have to agree with your suggested "parallel hierarchy"
approach.

The resource I often consult as the definitive textbook on O-O design is
Bertrand Meyer's book "Object-Oriented Software Construction."  This
morning, I re-read the chapter covering inheritance, just to freshen up
the knowledge a bit as I confront a new language.  Your reply agrees
with my conclusion, that we are dealing primarily with implementation
inheritance in this case.  I should have seen it right away when I had
to issue a significant number of "^self shouldNotImplement" in the heirs
to the various menu classes.

This is most interesting to me.  Of the half a dozen or so different
types of inheritance that Eiffel supports, it actually has specific
semantics for dealing with the complexities of implementation
inheritance--undefine, redefine, and rename.  "^self shouldNotImplement"
is simply the equivalent of "undefine."  Theoretically, I should feel
right at home with this level of shoehorning, as you say.

But again, your caution against making superficial comparisons applies
here as well.  Shoehorning in Eiffel is rather straightforward, even in
the most complex of cases, because the dependency (coupling) mechanism
between classes and objects is clear (and by "clear" I do mean "limited"
compared to Smalltalk).  But there's obviously a sophisticated network
of interactions going on underneath Menu and MenuBar, etc., that aren't
so obvious to the neophyte.  We realized that when we started exploring
MenuItem and wound up deep in the heart of message-send protocols.  And
here I thought "&Undo" was just a bloody string :-).

Cheers,

Eric
rather
> than
> trying to shoehorn your stuff into a hierarchy which has been designed
> without
> an explicit abstraction layer.  (I've done the shoehorn thing before
and
> regretted it).  Remember that in Smalltalk, subclassing is not the
same as
> subtyping.  Inheritance is primarily about inheriting implementation,
and
> in
> this case you don't want to inherit the implementation.
>
> That does mean that you'll be duplicating code from the existing
> implementation, but (without having tried it, nor even looked at it in
any
> great detail) I suspect that'd be the lesser of two evils.
>
> It would be better, of course, for your purposes, if there had been an
> abstraction layer there already, but there isn't.  So...
>
> BTW, for OA, I suspect that the time might be ripe to consider
introducing
> such
> a layer (I think it would have been premature much before now).  Not
only
> has
> Eric hit this, but I've been looking into Rebars and the new-style
menu
> bar
> implementation (as in Internet Explorer).  It turns out that the new
"menu
> bars" are actually toolbars (inside a Rebar control) configured to
look
> like
> menus.  See (URL will probably wrap):
> http://msdn.microsoft.com/library/en-
> us/shellcc/platform/commctls/faq/ietoolbar.asp
>
> I'd guess that such menus will become de-riguer sooner or later
(unless
> there
> is something even weirder in the next version of Windows).
>
>     -- chris
>