Presenter strange "error"

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

Presenter strange "error"

Bruno Brasesco
Hi all,

I have a #PrincipalPresenter in my application.

And any user can open a lot of other presenter from #PrincipalPresenter.

For example: NewDocumentPresenter.
#PrincipalPresenter method:

addNewDocument

    NewDocumentPresenter show parentPresenter: self.

And a user can add a new document. And this worked ok (for a while).

But now I don not know why every action in #NewDocumentPresenter is
delegated to #PrincipalPresenter.
And a Wallback arise.
This happend with 2 PushButtons, but the third PushButton it work ok
(#NewDocumentPresenter perform the command).

The only thing i have in mind is that the View of #NewDocumentPresenter was
aDilaog after aShell, then aDialog, etc, etc.
(and i changed the presenter too).

Any idea ?

Best Regards
Bruno Brasesco


Reply | Threaded
Open this post in threaded view
|

Re: Presenter strange "error"

Bruno Brasesco
> But now I don not know why every action in #NewDocumentPresenter is
> delegated to #PrincipalPresenter.
> And a Wallback arise.
> This happend with 2 PushButtons, but the third PushButton it work ok
> (#NewDocumentPresenter perform the command).

The problem is in #queryCommand: method.

The presenter had a sentence for each command, although the command it was
always enabled.
To avoid write a lot of lines of this "always enabled command" i put in the
end of #queryCommand:.
example:
#queryCommand: aCQ
....etc, etc.

    query enabled: true.

And this (query enabled: true) cause the error.
I do not why ?

But I'm searching.

Best Regards
Bruno Brasesco


Reply | Threaded
Open this post in threaded view
|

Re: Presenter strange "error"

Ian Bartholomew-7
Bruno,

> example:
> #queryCommand: aCQ
> ....etc, etc.
>
>     query enabled: true.
>
> And this (query enabled: true) cause the error.
> I do not why ?
>
> But I'm searching.

Sorry, I can't quite grasp exactly what you are trying to do but a couple of
things spring to mind.

You don't have to explicitly enable a command if there is a method that
matches that command accessible from one of the presenters in the chain. See
Presenter>>queryCommand:

I can't remember the circumstances offhand, but when you enable like this
you sometimes need to set the receiver of the command as well or else the
command is sent to the wrong presenter. As in

query
   isEnabled: true; "nb #enabled is deprecated"
    receiver: self

The problem will then be making sure that the #queryCommand method that does
this uses the right receiver i.e. the self may need to be a different
presenter to the one implementing the #queryCommand method..

My only real advice would be that this area can get quite complicated,
working out what is being sent to where, and is very difficult to debug as
breakpoints tend to multiply explosively. Unless you really know what needs
doing (and I am not saying that I always do either) it's best to just go
with the flow and use the default scheme.

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Presenter strange "error"

Ian Bartholomew-7
In reply to this post by Bruno Brasesco
Bruno,

> example:
> #queryCommand: aCQ
> ....etc, etc.
>
>     query enabled: true.
>
> And this (query enabled: true) cause the error.
> I do not why ?
>
> But I'm searching.

Sorry, I can't quite grasp exactly what you are trying to do but a couple of
things spring to mind.

You don't have to explicitly enable a command if there is a method that
matches that command accessible from one of the presenters in the chain. See
Presenter>>queryCommand:

I can't remember the circumstances offhand, but when you enable like this
you sometimes need to set the receiver of the command as well or else the
command is sent to the wrong presenter. As in

query
   isEnabled: true; "nb #enabled is deprecated"
    receiver: self

The problem will then be making sure that the #queryCommand method that does
this uses the right receiver i.e. the self may need to be a different
presenter to the one implementing the #queryCommand method..

My only real advice would be that this area can get quite complicated,
working out what is being sent to where, and is very difficult to debug as
breakpoints tend to multiply explosively. Unless you really know what needs
doing (and I am not saying that I always do either) it's best to just go
with the flow and use the default scheme.

Ian