Presenter>>onCloseRequested

Hi,

I'm trying to understand the sequence of things that happen when you
open and close a window.

Using the LibraryShell example from the MVP NightSchool, I inserted
several breackpoints (for example in Presenter>>onCloseRequested and
LibraryShell>>onCloseRequested) and clicked on the close button of the
title bar.

None of those methods were called, only the onCloseRequested method in
View and ShellView, bit not those in the presenters (Presenter and its
subclass LibraryShell).

When are those methods (LibraryShell>>onCloseRequested and
Presenter>>onCloseRequested) called?

Thanks

Fernando,
"Fernando" <[hidden email]> wrote in message
news:[hidden email]...
I don't know about the LibraryShell example, but I think you'll need to hook
it up in your presenter's #createSchematicWiring method, like this:

self
    when: #closeRequested:
    send: #onCloseRequested:
    to: self

I also use the version that takes an argument (#onCloseRequested:), because
it allows you to cancel the close if you want.  The argument is some sort of
value holder, and you just set its value to false to cancel (theArg value:
false).

HTH,

Don

Fernando,

> When are those methods (LibraryShell>>onCloseRequested and
> Presenter>>onCloseRequested) called?

Have a look at ShellView>>onCloseRequested.  This traps the closeRequested
event for Shell/ShellView, interrupting it's normal progression, and
replaces it with an #closeRequested: event (note the colon) which is
triggered directly off the Presenter (a Shell).

The idea is that a Shell can then prevent its own closure by setting the
value of the argument passed  (a ValueHolder) to false.  Because
#closeRequested: is a new event you have to register for it during the
Shell's initialization (usually).  So you need to do two things ....

YourShell>>createSchematicWiring
[]
self when: #closeRequested: send: #onCloseRequested: to: self

and

YourShell>>onCloseRequested: aValueHolder
    aValueHolder value: true "to allow the close"
    "_or_"
    aValueHolder value: false "to deny the close"

There's lots of examples in the default image.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

On Thu, 17 Mar 2005 20:06:15 -0000, "Ian Bartholomew"
<[hidden email]> wrote:

>Fernando,
>
>> When are those methods (LibraryShell>>onCloseRequested and
>> Presenter>>onCloseRequested) called?
>
>Have a look at ShellView>>onCloseRequested.  This traps the closeRequested
>event for Shell/ShellView, interrupting it's normal progression, and
>replaces it with an #closeRequested: event (note the colon) which is
>triggered directly off the Presenter (a Shell).
[snip]

Got it, thanks (again)! :-)

On Thu, 17 Mar 2005 20:06:15 -0000, "Ian Bartholomew"
<[hidden email]> wrote:


>The idea is that a Shell can then prevent its own closure by setting the
>value of the argument passed  (a ValueHolder) to false.  Because

OK, I was expecting this to happen on all windows, but on second
thought, that wouldn't make much sense.

I just did this and set 'self halt' in several methods to follow step
by step what happens. I added breakpoints to the following methods of
the presenter:

#onCloseRequested:
#onViewClosed
#onViewDestroyed

Everything works fine until I reach onViewClosed, then the whole
environment crashes. If I remove the 'self when: #closeRequested:
send: #onCloseRequested: to: self' line from createSchematicWiring,
everything works fine (no crashes when stepping into onViewClosed).

Weird... =:-O

Fernando,

> Everything works fine until I reach onViewClosed, then the whole
> environment crashes. If I remove the 'self when: #closeRequested:
> send: #onCloseRequested: to: self' line from createSchematicWiring,
> everything works fine (no crashes when stepping into onViewClosed).

Yes, I can reproduce that.  It seems to be some sort of race condition
caused when the debugger window partially obscures the shell.  If you
reduce/move the first debug window, so that it doesn't obscure the shell, or
get the same effect by reducing the size of the shell, then the error
doesn't seem to occur as often (for me anyway).

It's not a "major" image crash though - Ctrl-Break gets out of it without
any apparent side effects.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Fernando wrote,

> Everything works fine until I reach onViewClosed, then the whole
> environment crashes. If I remove the 'self when: #closeRequested:
> send: #onCloseRequested: to: self' line from createSchematicWiring,
> everything works fine (no crashes when stepping into onViewClosed).
>
> Weird... =:-O

Not really.  Changing the windowing system can easily lead to problems
like this; imagine what can happen if opening a walkback causes a
walkback.  You can get information by using Trace (a stream interface to
OutputDebugString()) and DebugView to see the output.

Have a good one,

Bill


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

On Fri, 18 Mar 2005 14:32:43 -0500, Bill Schwab
<[hidden email]> wrote:


>
>Not really.  Changing the windowing system can easily lead to problems
>like this;

But I wasn't changing the windowing system at all...
 
>imagine what can happen if opening a walkback causes a
>walkback.  You can get information by using Trace (a stream interface to
>OutputDebugString()) and DebugView to see the output.

Thanks, I'll see what I can find out about those too clases.

Fernando,

>>Not really.  Changing the windowing system can easily lead to problems
>>like this;
> But I wasn't changing the windowing system at all...

You didn't so much change it as add to what happens during it's
operation.  Net result: you changed it :)

Have a good one,

Bill

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

Fernando,

>>imagine what can happen if opening a walkback causes a
>>walkback.  You can get information by using Trace (a stream interface to
>>OutputDebugString()) and DebugView to see the output.
>
>
> Thanks, I'll see what I can find out about those too clases.

Trace is a global pointing to an instance of a stream subclass; the
Browse-it command will take you to the class.  Follow that to the owning
package comment, and you will see where to download DebugView, which is
a separate tool (a must-have).

Have a good one,

Bill

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

On Fri, 18 Mar 2005 18:32:31 -0500, Bill Schwab
<[hidden email]> wrote:

>Fernando,
>
>>>Not really.  Changing the windowing system can easily lead to problems
>>>like this;
>> But I wasn't changing the windowing system at all...
>
>You didn't so much change it as add to what happens during it's
>operation.  Net result: you changed it :)

But I only modified a presenter that isn't used by the environment. It
should cause this sort of thing...

Fernando,

> But I only modified a presenter that isn't used by the environment. It
> should cause this sort of thing...

One thing you must always appreciate is that you are working on a live
environment, the code that is running your application is the same code that
the debugger and all the other windows are using.  By inserting a breakpoint
you are interrupting the normal flow of operations and it can, on occasion,
create some unusual results.  The situation you found, the debugger opening
with a blank view and (I imagine) capturing all input, does occasionally
occur when debugging view code.  In 95% of the these cases you can get out
of it by hitting Ctrl-Break, and generating a user interrupt, to regain
control.

The sort of thing that happens (and this is just an off the top of my head
situation, I've no idea if it is a cause of any of the problems seen) is
when you click on the close button the view being closed must obviously be
in focus.  If something a bit later in the chain assumes that the view still
has focus then it can get confused if, in the meantime, the debugger has
opened and now has the focus.

I imagine this sort of thing could be fixed, running a lot of the view code
inside #critical blocks for instance, but IMHO it would reduce the
flexibility of the whole "working in a live image" thing.

One thing in this area that I would caution you about is when working with
ListViews, and in particular modifying the #getText, #getContents etc
blocks.  If you make a mistake in the blocks code then testing can generate
a continual loop of breakpoints, as each entry in the list is displayed, and
this can be a bit difficult to control.  Motto for the wallboard: _Always_
save the image before testing ListView blocks.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.