Enh. Sugg.: SmalltalkWorkspace in Class Browser, text selection persistence issue.

I would like to suggest a small improvement to the Dolphin
SmalltalkWorkspace in the Class Browser.

Workspaces saved with selected text erroneously think they have changed when
they are restored from an image.

For example: Open a class browser and select some text in a method, as if to
copy it.  Then save the image, and exit Dolphin.  Reopen Dolphin.  The class
browser will reopen with the selection still selected.  Now choose another
method or class in the class browser.  It will ask if you want to retain
changes.  There are not really any changes, but apparently the selection
(which seems to loose its formatting) causes Dolphin to think there were
changes.

I know this seems to be a small issue, but I tend to copy and paste method
and variable names quite a bit.  I also tend to work with a number of class
browsers open.  When I decide to close browsers or look at different code
and I am prompted about changes I have to think about whether I made real
changes to the source code or if I might have made changes accidentally or
if I am closing the wrong browser.  Since the class browsers affected by
this selection issue are from a previous session they are not always fresh
in my mind so I have to think a little more.

This is not critical, but an improved selection persistence behavior would
make things flow more smoothly for me.

Thanks,

Chris

Christopher

"Christopher J. Demers" <[hidden email]> wrote in
message news:98p5uj$2vk4a$[hidden email]...
> I would like to suggest a small improvement to the Dolphin
> SmalltalkWorkspace in the Class Browser.
>
> Workspaces saved with selected text erroneously think they have changed
when
> they are restored from an image.

The occassional over-zealous prompt to save changes after image restart has
been bugging me for quite a while too, I just hadn't identified that it was
only those browsers where there was a selection in the workspace. Once you'd
pointed that out it was easy to find the problem, and the loss of formatting
of the selection was a further clue (thanks). It's to do with the
RichTextEdit>>state method, patch below (and will be in 4.01).

Regards

Blair
----------------------------

!RichTextEdit methodsFor!

state
 "Private - Answer a <MessageSequence> which, when replayed, will restore
the receiver
 to its current state."

 | sequence |
 sequence := super state.
 self hasSelection ifFalse: [
  sequence add: (MessageSend receiver: self selector: #resetCharFormat)].
 ^sequence! !
!RichTextEdit categoriesFor: #state!accessing!private! !

Blair McGlashan <[hidden email]> wrote in message
news:98qak1$34ukb$[hidden email]...
> The occassional over-zealous prompt to save changes after image restart
has
> been bugging me for quite a while too, I just hadn't identified that it
was
> only those browsers where there was a selection in the workspace. Once
you'd
> pointed that out it was easy to find the problem, and the loss of
formatting
> of the selection was a further clue (thanks). It's to do with the
> RichTextEdit>>state method, patch below (and will be in 4.01).

As usual I am impressed by your prompt and effective response.  It works
like a charm. Thank you.

Chris