Any changes to view/presenter closing?

Hi Blair,

I just noticed a change in BugOff's behavior under D5 vs. D4.  Going from
the summary editor (a text presenter) directly to clicking the save button
w/o first changing selection in the list does not flush the changes to the
model.  Moving the focus to another text presenter before clicking on the
toolbar does flush the changes.  The D4 behavior was correct, but, it might
have been two wrongs making a right.

BugOff uses a selection trick (see below) to force changes to be flushed
back to the model.  There is a definite flicker, so my hunch is that the
close/open is occuring.  Has something changed about view/presenter closing?
PaneHolders is involved here - do I maybe need to add some extra steps when
closing a pane?

Put another way, did you have any problems with data not getting flushed
back to models?  If so, can you remember which presenters or what you did to
fix it?

Have a good one,

Bill

------------------

getDocumentData
 "Private - Answer the data for the receiver's document.
 Can be overidden by subclasses"

  | selectionOrNil |

 "Note the file name for MRU list."
 self recordRecentFile.

 "Force the removal of the current pane to flush changes."
 selectionOrNil := items selectionOrNil.
 items selectionOrNil:nil.
 selectionOrNil notNil ifTrue:[
  items selection:selectionOrNil.
 ].

 ^self model list asOrderedCollection

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

Bill

You wrote in message news:aakhp9$b4qp4$[hidden email]...
> ...
> I just noticed a change in BugOff's behavior under D5 vs. D4.  Going from
> the summary editor (a text presenter) directly to clicking the save button
> w/o first changing selection in the list does not flush the changes to the
> model.  Moving the focus to another text presenter before clicking on the
> toolbar does flush the changes.  The D4 behavior was correct, but, it
might
> have been two wrongs making a right.
>...
> Put another way, did you have any problems with data not getting flushed
> back to models?  If so, can you remember which presenters or what you did
to
> fix it?

I've been mulling this over for a while now, but the only things I've been
able to think of that might be relevant was a change in response to an issue
Ian found some time ago (ValuePresenter>>value resets old value if invoked
from #valueChanged event handler). However we found the change too likely to
break existing code, so we backed it out. The only other thing of possible
relevance is the change in the selectionChanged/selectionChanging events -
see the release notes for issue #33.

Sorry I can't be of more help.

Regards

Blair