Hi! I realized that because
*Morphic>>findA: aClass
"Return the first submorph of the receiver that is descended from the
given class. Return nil if there is no such submorph. Clients of this code
should always check for a nil return value so that the code will be robust
if the user takes the morph apart."
^self submorphs
detect: [:p | p isKindOf: aClass]
ifNone: [nil]*
we can simply replace MenuMorph>>doButtonAction by
*MenuMorph>>doButtonAction
"Do the receiver's inherent button action. A MenuMorph that is a
wrapper for a single menu-item -- pass it on the the item. We should enhance
or think what to do with a MenuMorph with multiple items"
self menuItems notEmpty ifTrue:[ self menuItems first doActionButton ]*
I'll look at that a few minutes to give a little fix :).
On Fri, Aug 6, 2010 at 6:28 PM, Stéphane Ducasse
<[email protected]>wrote:
>
> On Aug 6, 2010, at 4:54 AM, Guillermo Polito wrote:
>
> > Hi, removing some findA: message sendings
>
> Yes yes yes!!!
> We only need a few of them.
>
> > i've found:
> >
> > MenuMorph>>doButtonAction
> > "Do the receiver's inherent button action. Makes sense for the kind
> of MenuMorph that is a wrapper for a single menu-item -- pass it on the the
> item"
> >
> > (self findA: MenuItemMorph) ifNotNil: [:aMenuItem | aMenuItem
> doButtonAction]
> >
> >
> > And for me it doesn't make sense :). Even the comment doesn't make
> sense, because it isn't considering the case where a MenuMorph has multiple
> MenuItemMorph s.
> >
> > What should be done in cases like that? If it's my code, i should be
> tempted to delete it or maybe to deprecate it. And I'm really upset because
> it is a very difficult thing to verify not to break too much other things.
> So, what is the "official policy" about this cases? :P I don't like to
> leave it as it is...
>
> Get one or more scenario where the code behavior normally
> and rewrite so that it does not use findA:
> What I suggest is that you start with the easy findA: and publish often so
> that we integrate them in the system
> and slowly we learn and fix the ugly.
>
> Stef
>
>
>
> >
> > Cheers,
> > Guille
> > _______________________________________________
> > Pharo-project mailing list
> > [email protected]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
