Mysterious W.B. due to missing presenter method

In my app I have a shell that contains several containers that include
reference views that are all attached to an appropriate default model on
start up. One of the referenced subpresenters is a composite containing a
tool pane with four buttons with their associated selectors and a pane
containing a tree. The methods that correspond to the selectors contained in
the toolpane buttons are implemented in the subpresenter. No problem so far.

The Shell allows the user to read in a new model from disk which changes the
sub presenters model(s) to the new model. (I know, I know - model changing
on the fly is not recommended, but it seemed the easiest way to it at the
time and I haven't come up with a better method so far). After a new model
is loaded there a strange problem occurs.
When I "flyover" a button before changing the model, the help string
displays as it should. After the new model is loaded and I "flyover" a
button, a walkback is generated at about the same time that the flyover help
string for the button under the arrow should appear. Somebody sends
#commandPolicyWithSource: to the presenter and this method is missing, hence
the W.B.

It seems that with the initial default model loaded,
Presenter>>commandPolicy in invoked and everything works but after I change
to the new model, Presenter>>commandPolicyWithSource: is invoked.

I added:

commandPolicyWithSource: commandSource
 "Answers a <CommandPolicy> object set up for routing commands originating
 from the receiver. This should be overridden by subclasses that wish to use
a different
 routing policy."
 "DGW/CSI - Missing method. This was invoked from a tool bar in a sub pane."
 ^self topShell commandPolicyWithSource: self commandSource

to Presenter, and it all works as expected, the flyover help displays and
there are no walkbacks.

I tried to do some tracing, but putting a halt in the commandPolicy or
commandPolicyWithSource: "breaks" the event chain as one would expect so I
can't really trace this effectively.


I have no idea why this should have happende, any Ideas?
Dave
---------

--
Dave Wachtel
President, CSI Technologies, Inc.
Activities Director/Membership Chairman
Mohawk Hudson Region, Sports Car Club of America
[hidden email]
http://www.acmenet.net/~dwachtel
http://www.mohud-scca.org

David

You wrote in message news:[hidden email]...
> In my app I have a shell that contains several containers that include
> reference views that are all attached to an appropriate default model on
> start up. One of the referenced subpresenters is a composite containing a
> tool pane with four buttons with their associated selectors and a pane
> containing a tree. The methods that correspond to the selectors contained
in
> the toolpane buttons are implemented in the subpresenter. No problem so
far.
>
> The Shell allows the user to read in a new model from disk which changes
the
> sub presenters model(s) to the new model. (I know, I know - model changing
> on the fly is not recommended, but it seemed the easiest way to it at the
> time and I haven't come up with a better method so far). After a new model
> is loaded there a strange problem occurs.
> When I "flyover" a button before changing the model, the help string
> displays as it should. After the new model is loaded and I "flyover" a
> button, a walkback is generated at about the same time that the flyover
help
> string for the button under the arrow should appear. Somebody sends
> #commandPolicyWithSource: to the presenter and this method is missing,
hence
> the W.B.
>
> It seems that with the initial default model loaded,
> Presenter>>commandPolicy in invoked and everything works but after I
change
> to the new model, Presenter>>commandPolicyWithSource: is invoked.
> ...

The most logical explanation that I can come up with is that the view is
somehow being reparented so that its ultimate parent is for some reason not
a "shell". #commandPolicyWithSource: should only be sent to a
<topPresenter>, e.g. a Shell, ShellView or DesktopView.

I would suggest checking the parent chains of both view and presenter
hierarchies to see whether something is broken.

> I tried to do some tracing, but putting a halt in the commandPolicy or
> commandPolicyWithSource: "breaks" the event chain as one would expect so I
> can't really trace this effectively.

I usually do this by inserting a "conditional" breakpoint, e.g. so that it
only fires the first time through:

    ...
    SomeGlobal isNil ifTrue: [SomeGlobal := 1. self halt].
    ...

The condition could also look for some specific 'self'. Sometimes it also
helps to copy a method down into the subclass one is investigating.

Regards

Blair

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:9vuvt1$hk36u$[hidden email]... not
> a "shell". #commandPolicyWithSource: should only be sent to a
> <topPresenter>, e.g. a Shell, ShellView or DesktopView.

This looks like what is happening.

> I would suggest checking the parent chains of both view and presenter
> hierarchies to see whether something is broken.
>
> > I tried to do some tracing, but putting a halt in the commandPolicy or
> > commandPolicyWithSource: "breaks" the event chain as one would expect so
I
> > can't really trace this effectively.
>
> I usually do this by inserting a "conditional" breakpoint, e.g. so that it
> only fires the first time through:

Sheesh, I never thought of that!

I followed your suggestions but ended up putting transcript messages in
various places.

Everything looks ok except for this:
    (when the shell is first opened)
    ...
    ShellView>>presenter: CSIEventHierarchyPresenter
    ShellView>>presenter: CSIEventHierarchyShell
    ...
---------------
    ...
    CSIEventHierarchyShell>>mmFileOpenEvent
    (after the file is opened)
    ShellView>>presenter: CSIEventHierarchyShell
    ShellView>>presenter: CSIEventHierarchyPresenter
    ....
Are the above in reverse order, if so any idea why?

Thanks
Dave
------------
Dave Wachtel
President, CSI Technologies, Inc.
Activities Director/Membership Chairman
Mohawk Hudson Region, Sports Car Club of America
[hidden email]
http://www.acmenet.net/~dwachtel
http://www.mohud-scca.org

Dave,

> The Shell allows the user to read in a new model from disk which changes
the
> sub presenters model(s) to the new model. (I know, I know - model changing
> on the fly is not recommended, but it seemed the easiest way to it at the
> time and I haven't come up with a better method so far).
>  After a new model is loaded there a strange problem occurs.

<ShamelessPlug>Try my Pane Holders package</ShamelessPlug>.  Some parts of
it are more ambitious (read dangerous<g>) than others.  PaneHolder itself is
very well tested and I've gotten favorable reports from a couple of other
users.   Instead of loading a different model into one of your
sub-presenters, you would put a pane holder in its place, and then use it to
create a completely new sub-triad each time you "change the model".  You can
set the initial content of the pane holder from the shell's #onViewOpened.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill,

"Bill Schwab" <[hidden email]> wrote in message
news:a05841$fus$[hidden email]...
> Dave,
>
> > The Shell allows the user to read in a new model from disk which changes
> the
> > sub presenters model(s) to the new model. (I know, I know - model
changing
> > on the fly is not recommended, but it seemed the easiest way to it at
the
> > time and I haven't come up with a better method so far).
> >  After a new model is loaded there a strange problem occurs.
>
> <ShamelessPlug>Try my Pane Holders package</ShamelessPlug>.  Some parts of
> it are more ambitious (read dangerous<g>) than others.  PaneHolder itself
is
> very well tested and I've gotten favorable reports from a couple of other
> users.   Instead of loading a different model into one of your
> sub-presenters, you would put a pane holder in its place, and then use it
to
> create a completely new sub-triad each time you "change the model".  You
can I'm considering it.

The thing is that another window displays a list that loads the selected
model and displays details in an associated tab pane. It already has a fair
amount of associated overhead when changing models. The software also has to
be efficient on modest machines so I'm a little worried about the potential
overhead of swapping an entire triad. Is there flicker involved when the
triad is updated? Flicker is a problem in my current implementation. I
wasn't aware that the entire window would be refreshed every time I changed
the model until I was pretty far along in the current implementation. I will
need to change the app so it doesn't do it. The existing Delphi program the
new app is meant to replace doesn't flicker and so the new one shouldn't
also. Unfortunately I didn't notice the flicker when I was doing some tests
at the beginning using my new 1.7 GHz Dell.

I would like to avoid making any big changes in design at this point. If you
have any ideas about updating reference panes in containers without getting
flicker, I'd sure like to know about them. I probably could use aspect
buffers, but I want editing to be "live" in the underlying model, although I
am giving this a rethink as well.

 From my tracing, as indicated in the last post, it looks like there is
either a "binding" of a presenter that is occurring twice when it should
only occur once, or else the binding order is reversed for some reason. I
don't do any of this explicitly, and I checked my views and so on and they
all look OK.  Moving the method keeps the thing from crashing, but I don't
know what the effects might be down the line.

Thanks

Dave
--------
Dave Wachtel
President, CSI Technologies, Inc.
Activities Director/Membership Chairman
Mohawk Hudson Region, Sports Car Club of America
[hidden email]
http://www.acmenet.net/~dwachtel
http://www.mohud-scca.org

David,

Re: Reducing flicker.

> The thing is that another window displays a list that loads the selected
> model and displays details in an associated tab pane. It already has a
fair
> amount of associated overhead when changing models. The software also has
to
> be efficient on modest machines so I'm a little worried about the
potential
> overhead of swapping an entire triad. Is there flicker involved when the
> triad is updated? Flicker is a problem in my current implementation. I
> wasn't aware that the entire window would be refreshed every time I
changed
> the model until I was pretty far along in the current implementation. I
will
> need to change the app so it doesn't do it. The existing Delphi program
the
> new app is meant to replace doesn't flicker and so the new one shouldn't
> also. Unfortunately I didn't notice the flicker when I was doing some
tests
> at the beginning using my new 1.7 GHz Dell.
>
> I would like to avoid making any big changes in design at this point. If
you
> have any ideas about updating reference panes in containers without
getting
> flicker, I'd sure like to know about them. I probably could use aspect
> buffers, but I want editing to be "live" in the underlying model, although
I
> am giving this a rethink as well.
>
> From my tracing, as indicated in the last post, it looks like there is
> either a "binding" of a presenter that is occurring twice when it should
> only occur once, or else the binding order is reversed for some reason. I
> don't do any of this explicitly, and I checked my views and so on and they
> all look OK.  Moving the method keeps the thing from crashing, but I don't
> know what the effects might be down the line.

You might like to try the technique used by the PublishedAspectInspector as
it adds and removes triads. Here's an excerpt from the Dolphin5 version:

PublishedAspectInspector>>onAspectSelected
    "Private - An aspect has been selected within the aspect list.
    Create an appropriate aspect presenter"

    "Remove any existing presenters. Note that the act of removing an
aspectPresenter
    may cause modified data to be flushed back to the aspect. This in turn
may cause
    the aspect to be reselected in the aspectTreePresenter (depending on the
nature
    of the aspect being flushed. To avoid receiving a recursive change
notification we
    protect the removal code within a #noEventsDo: block"

    displayPresenter view disableRedraw.
    aspectTreePresenter noEventsDo:
        [aspectPresenter notNil
            ifTrue:
                [displayPresenter remove: aspectPresenter.
                aspectPresenter := nil].
        workspacePresenter notNil
            ifTrue:
                [displayPresenter remove: workspacePresenter.
                workspacePresenter := nil]].
            displayPresenter view enableRedraw.
    etc.

Note two techniques are used here:

1) Use of #disableRedraw and #enableRedraw for the parent view.
2) Use of #noEventsDo: to prevent spurious event triggers off an object from
causing changes during the triad switch.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---