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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Eric Taylor
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


Reply | Threaded
Open this post in threaded view
|

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

Blair McGlashan-4
"Eric Taylor" <[hidden email]> wrote in message
news:001001c68d9f$8eace5d0$6500a8c0@server...

> 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?

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


Reply | Threaded
Open this post in threaded view
|

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

Eric Taylor
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


> -----Original Message-----
> From: Blair McGlashan [mailto:[hidden email]]
> Posted At: Monday, June 12, 2006 2:44 PM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: Design Motivation behind
> "MenuItem>>#registerAcceleratorKeyIn: anAcceleratorTable"
> Subject: Re: Design Motivation behind
> "MenuItem>>#registerAcceleratorKeyIn: anAcceleratorTable"
>
> "Eric Taylor" <[hidden email]> wrote in message
> news:001001c68d9f$8eace5d0$6500a8c0@server...
> > 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?
>
> 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