Design Motivation behind "MenuItem>>#registerAcceleratorKeyIn: anAcceleratorTable"

Hello Forum,

Consider the following:

        MenuItem>>#registerAcceleratorKeyIn: anAcceleratorTable

We're curious as to why the accelerator table would be passed in like
this.  We're used to multiply inheriting the accelerator table in an
application class at a level equivalent to that of the
RuntimeSessionManager in Dolphin, so we're a little confused.

What is the design strategy in this approach?

Cheers,

Eric

"Eric Taylor" <[hidden email]> wrote in message
news:001001c68d9f$8eace5d0$6500a8c0@server...
To make Menus and MenuItems polymorphic. Since Menu's can contain sub-menus
or menu-items, it makes for a simple and elegant implementation of the
recursion down through the structure to add all items at any level into the
accelerator table. I suppose it is minor example of the use of the Composite
design pattern.

Regards

Blair

Blair,

>To make Menus and MenuItems polymorphic.

Having worked now with both of these classes quite a bit over the past
week, the polymorphism has become clearer.  I suppose the lesson for us
is to think Composite first, as a starting point, whenever we would
normally do something through multiple inheritance.

BTW, Codejock Software's response this morning to our technical support
request concerning the downcasting anomaly implied that, well, perhaps
we here were the anomaly :).  They can only guess that we actually
compiled the Visual Basic example (which doesn't require an explicit
downcast), not the C# example.  In any case, they just released volume 2
of their suite, which did correct other, real anomalies.  

Cheers,

Eric

like into
> the
> accelerator table. I suppose it is minor example of the use of the
> Composite
> design pattern.
>
> Regards
>
> Blair