(possibly originated from: [bug][fix] #setInvokingView: fails if a subMenu is used)

[Oca Emilio]

Hi lex, harvesters,

I almost discarded this message, I didn't get it. 
Until I saw my address in the To: field. 

My original mail was sent on 28/03/2003. Then I was involved on a commercial
squeak project and faced (not for the first time) the issues stated on that
mail (reproduced below).
At the bottom I asked for any comments, which never came.
> Do I miss something? Is this the intended behavior?
You are the first person after more than a year to have comment on this,
which I much appreciate.

On the MenuMorph>>setInvokingView: issue, I think it's a bug, whit a little
help and mentoring I could get some tests and a fix.

On the perform:orSendTo: issue...
> I am sympathetic to the analysis but if there is not a specific problem
> this solves then why make the code *longer*?  My head is spinning after
Well the specific problem it solves are:
a) I think it is written the wrong way (in Object).
b) Not to write any more overwritings of a seemed suboptimal and confusing
method.
c) To remove all of this overwritings.

b) and c) actually make others code shorter.

But, may be many others use de default behavior. I think that this is the
hard part and that is why I asked for comments. I am not going to offer a
fix before considering and getting some feedback on this.

> confusing.  If you are still thinking about this, then why not submit a
> changeset that changes the default and also overrides this default in
> any cases that need it (perhaps none, really!) ?
Well, I am still thinking. But, I didn't know if it was already fixed by
now. I was not sure if there was interest because my mail passed unnoticed.
Moreover, I need feedback, I really don't want to break perform:orSendTo:
clients.

Besides, I need some technical help. I am not a Celeste user, and here,
where Internet is available for me, we have a very problematic firewall and
mail server to beat. I don't want to flood the list with test and spoiled
fixes.

If anybody could help me, I 'd gladly make try.

Lex, I am not in squeak-harvest at lists.squeakfoundation.org, so I do not know
if they would receive my mail, please if they don't, would you forward this
reply?

Regards

	Emilio

> -----Mensaje original-----
> De: lex at cc.gatech.edu [mailto:lex at cc.gatech.edu]
> Enviado el: Miércoles, 02 de Junio de 2004 23:47
> Para: squeak-harvest at lists.squeakfoundation.org; eoca at afip.gov.ar
> Asunto: 
> 
> 
> 
> I am sympathetic to the analysis but if there is not a  specific problem
> this solves then why make the code *longer*?  My head is spinning after
> reading this message for 5-10 minutes so I am giving up for now.
> 
> Incidentally, it is indeed by design that you the code uses
> perform:orSendTo:, though I agree the default seems to be suboptimal and
> confusing.  If you are still thinking about this, then why not submit a
> changeset that changes the default and also overrides this default in
> any cases that need it (perhaps none, really!) ?
> 



> -----Mensaje original-----
> De: Oca Emilio 
> Enviado el: Viernes, 28 de Marzo de 2003 09:27
> Para: 'The general-purpose Squeak developers list'
> Asunto: [bug][fix] #setInvokingView: fails if a subMenu is used
> 
> 
> Hi Squeakers,
> 
> As an example, if you try to use a submenu in a 
> PlugableListMoph menu the original version of 
> MenuMorph>>setInvokingView: fails because it assumes every 
> item always has arguments.
> This change set fixes this problem, but...
> I used MenuMorph>>add:subMenu: which has several use examples.
> MenuMorph>>add:subMenu:target:selector:argumentList: seems to 
> use 'arguments' an in this case I think my fix doesn't works 
> as it should. There are no examples of how this method is 
> used, may be it is of no use at all.
> May be somebody could add a test case to help harvesters with 
> this fix.
> 
> But (again) look at this method comment:
> 	"Re-work every menu item of the form
> 		<target> perform: <selector>
> 	to the form
> 		<target> perform: <selector> orSendTo: <invokingView>.
> 	This supports MVC's vectoring of non-model messages to 
> the editPane."
> 
> Is it correct to re-work this or is preferable to get it 
> right when it is built?
> 
> But more on this, look at the comment of the most common 
> implementation of this method:
> perform: selector orSendTo: otherTarget
> 	"This should be the default in Object"
> 
> 	(self respondsTo: selector)
> 		ifTrue: [^ self perform: selector]
> 		ifFalse: [^ otherTarget perform: selector]
> 
> Because Object has:
> perform: selector orSendTo: otherTarget
> 	"If I wish to intercept and handle selector myself, 
> 	do it; else send it to otherTarget"
> 	^ otherTarget perform: selector
> 
> And Model has:
> perform: selector orSendTo: otherTarget
> 	"Selector was just chosen from a menu by a user.  If 
> can respond, then perform it on myself.  If not, send it to 
> otherTarget, presumably the editPane from which the menu was 
> invoked." 
> 
> 	"default is that the editor does all"
> 	^ otherTarget perform: selector.
> 
> A consequence of this is that, if you use 
> PlugableSomethingMorph, you have to rewrite 
> #perform:orSendTo: to get messages sent to self instead of 
> plugableSomethingMorph.
> 
> Do I miss something? Is this the intended behavior?
> 
> 	Emilio
> 
> 
> 
> 'From Squeak3.4 of 1 March 2003 [latest update: #5170] on 27 
> March 2003 at 11:33:56 pm'!
> 
> !MenuMorph methodsFor: 'menu' stamp: 'efo 3/27/2003 23:32'!
> setInvokingView: invokingView
> 	"Re-work every menu item of the form
> 		<target> perform: <selector>
> 	to the form
> 		<target> perform: <selector> orSendTo: <invokingView>.
> 	This supports MVC's vectoring of non-model messages to 
> the editPane."
> 	self items do:
> 		[:item |
> 		item hasSubMenu 
> 			ifTrue: [ item subMenu setInvokingView: 
> invokingView]
> 			ifFalse: [ item arguments isEmpty 
> ifTrue:  "only the simple messages"
> 						[item 
> arguments: (Array with: item selector with: invokingView).
> 						item selector: 
> #perform:orSendTo:]]]! !
>