Possible Small Bug in System Browser

Hello Forum,

I think I have discovered a small bug in the System Browser.

When renaming a variable under the variable tab, if that variable is
referenced in any methods in the class, a dialog box presents asking for
the desired scope of the renaming.  The mouse cursor is hidden, however.
The mouse cursor is visible _outside_ the window owned by Dolphin.  One
can still navigate the dialog box, but only with the keyboard.

All of this occurs when the SB is used within in an Idea Space; I
haven't tested the scenario outside an Idea Space.

Has anyone else encountered this problem?

Cheers,

Eric

Eric,

> Has anyone else encountered this problem?

Seems OK here.  I tried it both inside and outside of an IdeaSpace and could
always see the cursor while the RenameAccessorsDialog was visible.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

I re-tested with a fresh image, both in and out of an IdeaSpace, and I
still have the problem.  The dialog box's caption reads "Rename instance
variable...."  I'm running D6 with Patch 2.  I noticed two other
idiosyncrasies this morning:

1) when accepting or cancelling the dialog, Dolphin responds as if I
were pressing the left mouse button;
2) when cancelling the dialog, the Transcript reports that an unknown
Notification has occurred.

The problem doesn't appear to be sporadic; I can recreate it at will.

I know what the problem is (it's actually very minor), but I'm not at a
level with Smalltalk or Dolphin where I could just go and fix it.  

Cheers,

Eric

Eric,

> I re-tested with a fresh image, both in and out of an IdeaSpace, and I
> still have the problem.  The dialog box's caption reads "Rename instance
> variable...."  I'm running D6 with Patch 2.

Yes, that's the dialog I'm looking at.  I don't know what it will prove but
try evaluating

RenameAccessorsDialog showModal

in a workspace and see if it works there.

> I noticed two other idiosyncrasies this morning:
>
> 1) when accepting or cancelling the dialog, Dolphin responds as if I
> were pressing the left mouse button;

I don't quite follow what you mean?

> 2) when cancelling the dialog, the Transcript reports that an unknown
> Notification has occurred.

Yes, I get that as well.  There's something a bit strange with the way the
exception is signalled - it should, I imagine, report "Refactoring Aborted"
in the Transcript.  It's nothing bad though.

> I know what the problem is (it's actually very minor), but I'm not at a
> level with Smalltalk or Dolphin where I could just go and fix it.

It's a bit difficult when you can't see the error as well :-).

Just so that we know we are doing the same thing (and perhaps somebody else
could try it) ....

Clean 6.02 image
Open a SystemBrowser
Select the $ in folder view
Scroll down the class list and select "Animal"
Click the Variables tab and select "name"
Right click and select "Rename"
Add an "x" to the end of "name"
Press enter

I now see a Dialog that works as I would expect it to. I see the arrow
cursor and can use it to select an option in the list then click on either
the OK or Cancel button.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

> Clean 6.02 image
> Open a SystemBrowser
> Select the $ in folder view
> Scroll down the class list and select "Animal"
> Click the Variables tab and select "name"
> Right click and select "Rename"
> Add an "x" to the end of "name"
> Press enter

The last line is where we differ.  If I press enter, I don't have the
problem either (I had never tried that).  But instead of pressing enter,
after you rename, simply click off (anywhere).  The dialog comes up, but
the mouse cursor is gone.

>...I don't quite follow what you mean?

I think that if you try clicking off, you'll see what I mean about the
left mouse button appearing to stick.

Cheers,

Eric

I
> > still have the problem.  The dialog box's caption reads "Rename
instance
> > variable...."  I'm running D6 with Patch 2.
>
> Yes, that's the dialog I'm looking at.  I don't know what it will
prove unknown
> > Notification has occurred.
>
> Yes, I get that as well.  There's something a bit strange with the way
the
> exception is signalled - it should, I imagine, report "Refactoring
> Aborted"
> in the Transcript.  It's nothing bad though.
>
> > I know what the problem is (it's actually very minor), but I'm not
at a either
> the OK or Cancel button.
>
> --
> Ian
>
> Use the Reply-To address to contact me (limited validity).
> Mail sent to the From address is ignored.

Eric,

> The last line is where we differ.  If I press enter, I don't have the
> problem either (I had never tried that).

And I never tried just clicking away to accept the change.  It's funny how
you get into a fixed way of doing things :-)

I can see the problem now, and what you mean about the left mouse button
sticking down.

I'll have look ...

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Eric, Ian,

> I re-tested with a fresh image, both in and out of an IdeaSpace, and I
> still have the problem.

I can't reproduce it either.  On D6.0.2 on Win2K, or D6.0.1 on WinXP (themed
classic look).  Maybe it's something to so with you running at 16-bit ?  (I
think I remember you saying you had switched to that.)


> 1) when accepting or cancelling the dialog, Dolphin responds as if I
> were pressing the left mouse button;

I don't understand what you mean by that.


> 2) when cancelling the dialog, the Transcript reports that an unknown
> Notification has occurred.

That seems to be a benign side effect of the way that the RB triggers a
Notification to say that the refactoring has been aborted.  That is caught and
re-notified ( in(RefactoringSmalltalkSystem>>handleRefactoringException:) which
causes its #messageText (which hasn't been set in this case) to be written to
the Transcript.   I don't know whether that overall behaviour is by design, but
it doesn't seems likely that the message is /intended/ to be quite so
cryptic...

I suspect the above mentioned method should be using:

    Notification signal: ex description.

instead of:

    Notification signal: ex messageText.

Either that or there's something wrong with the way the #messageText of
RaisedSignals is set when #signal is sent to an instance of Signal.

(AFAIK, all this mess with Signals rather than exceptions is hang-over from the
days when Smalltalk didn't have a properly constructed exception system.  I
don't know why there are so many uses left in the Dolphin image -- I wish there
were none, but maybe there's a good reason.   In this case the reason is
probably because the RB code has to be portable to older dialects of
Smalltalk.)

    -- chris

I wrote:

> I can't reproduce it either.

Belay that, with Eric's more detailed explanation, I'm able to reproduce it and
the mouse down behaviour too.

I guess Andy or Blair is going to have some fun tracking this one down ;-)

    -- chris

Chris,

> I guess Andy or Blair is going to have some fun tracking this one down ;-)

After a quick look I decided they would be the best people for the job :-)

When you do this from a ClassBrowserShell there's actually a nice twist to
the problem.  Follow the procedure as far as editing the variable then click
on another class in the class hierarchy tree to exit the variable edit box.
The Dialog works fine now (yay!) - but the renamed variable is added to the
wrong class, the one that is now selected.

FWIW, I can't say that I've ever used this facility - I always rename
variables using the Class menu's refactoring option.  If the "fix" was to
remove the inplace editing I can't say I would be complaining :-)

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Chris, Ian,

You've both confirmed that I'm not _completely_ mad.  Coming from
another environment, I suppose my first inclination is to edit
everything in place.  But it's not imperative.  I'll just use a
different facility in the IDE for renaming.

Cheers,

Eric

down
> ;-)
>
> After a quick look I decided they would be the best people for the job
:-)
>
> When you do this from a ClassBrowserShell there's actually a nice
twist to
> the problem.  Follow the procedure as far as editing the variable then
> click
> on another class in the class hierarchy tree to exit the variable edit
> box.
> The Dialog works fine now (yay!) - but the renamed variable is added
to
> the
> wrong class, the one that is now selected.
>
> FWIW, I can't say that I've ever used this facility - I always rename
> variables using the Class menu's refactoring option.  If the "fix" was
to
> remove the inplace editing I can't say I would be complaining :-)
>
> --
> Ian
>
> Use the Reply-To address to contact me (limited validity).
> Mail sent to the From address is ignored.

On Sun, 11 Jun 2006 16:49:04 -0600, Eric Taylor wrote:

> When renaming a variable under the variable tab, if that variable is
> referenced in any methods in the class, a dialog box presents asking for
> the desired scope of the renaming.  The mouse cursor is hidden, however.
> The mouse cursor is visible _outside_ the window owned by Dolphin.  One
> can still navigate the dialog box, but only with the keyboard.
>

If you look at the archives (Dec 7, 2005, "isPassword and focus") I had a
similar "no mouse" experience with a dialog box asking for a password. I
wonder if it's somehow related.

s.

"Eric Taylor" <[hidden email]> wrote in message
news:001201c68da9$3d72a1f0$6500a8c0@server...
Yes, Steve Waring reported it a while back. Or at least it sounds like the
known bug "2118: Prompt to rename accessors when renaming an inst var using
in-place edit leaves focus in the ListView's edit box". Patch below, to be
released in 6.03.

Regards

Blair

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

!ClassBrowserAbstract methodsFor!

createSchematicWiring
 "Create the trigger wiring for the receiver"

 super createSchematicWiring.
 self
  when: #timerTick:
  send: #onTimerTick:
  to: self.
 classesPresenter
  when: #modeChanged
   send: #onClassModeChanged
   to: self;
  when: #selectionChanged
   send: #onClassSelected
   to: self;
  when: #selectionChanging:
   send: #onClassSelectionChanging:
   to: self.
 categoriesPresenter
  when: #selectionChanged
   send: #onCategorySelected
   to: self;
  when: #selectionChanging:
   send: #onFilterSelectionChanging:
   to: self;
  when: #drag:
   send: #onDragCategory:
   to: self;
  when: #dragCut:
   send: #onDragMethodsCut:
   to: self;
  when: #dragOver:
   send: #onDragOverCategory:
   to: self;
  when: #drop:
   send: #onDropOverCategory:
   to: self;
  when: #labelOf:editedTo:accept:
   send: #onCategory:renameTo:accept:
   to: self.
 modePresenter
  when: #valueChanged
   send: #onModeSelectionChanged
   to: self;
  when: #dragOver:
   send: #onDragOverMode:
   to: self;
  when: #drop:
   send: #onDropOverMode:
   to: self.
 methodBrowserPresenter
  when: #methodSelected
   send: #onMethodSelected
   to: self;
  when: #dragOver:
   send: #onDragOverMethod:
   to: self;
  when: #drop:
   send: #onDropOverMethods:
   to: self.
 methodBrowserPresenter selectableItems
  when: #leftButtonDoubleClicked:
  send: #onMethodListDoubleClicked:
  to: self.
 self
  when: #closeRequested:
  send: #onCloseRequested:
  to: self.
 (self model)
  when: #methodCategorized:
   send: #onMethodCategorized:
   to: self;
  when: #methodAdded:
   send: #onMethodAdded:
   to: self;
  when: #methodRemoved:
   send: #onMethodRemoved:
   to: self;
  when: #classUpdated:
   send: #onClassUpdated:
   to: self;
  when: #classCategorized:
   send: #onClassCategorized:
   to: self;
  when: #protocolUpdated:
   send: #onProtocolUpdated:
   to: self;
  when: #protocolRemoved:
   send: #onProtocolRemoved:
   to: self.
 (self packageManager)
  when: #methodRepackaged:from:to:
   send: #onMethodRepackaged:from:to:
   to: self;
  when: #classRepackaged:from:to:
   send: #onClassRepackaged:from:to:
   to: self.
 protocolsPresenter
  when: #selectionChanged
   send: #onProtocolSelected
   to: self;
  when: #selectionChanging:
   send: #onFilterSelectionChanging:
   to: self;
  when: #actionPerformed
   send: #browseMethodProtocol
   to: self;
  when: #drag:
   send: #onDragProtocol:
   to: self;
  when: #dragOver:
   send: #onDragOverProtocol:
   to: self model;
  when: #drop:
   send: #onDropOverProtocol:
   to: self model;
  when: #labelOf:editedTo:accept:
   send: #onRenameMethodProtocol:to:accept:
   to: self.
 variablesPresenter
  when: #drag:
   send: #onDragVariableRefs:
   to: self;
  when: #dragCut:
   send: #onDragMethodsCut:
   to: self;
  when: #selectionChanged
   send: #onVariableSelected
   to: self;
  when: #selectionChanging:
   send: #onFilterSelectionChanging:
   to: self;
  when: #labelOf:editedTo:accept:
   send: #onRenameInstVar:to:accept:
   to: self;
  when: #labelOf:changedTo:
   send: #onRenameInstVar:to:
   to: self!

onRenameInstVar: anAssociation to: aString
 "Private - Action an in-place inst var rename that passed validation."

 "Implementation Note: Selection will be lost by #classUpdated: event,
unless we explicitly maintain it"

 | selections |
 selections := variablesPresenter view selectionsByIndex.
 (self model
  renameInstanceVariable: anAssociation value
  to: aString
  in: anAssociation key
  within: BrowserEnvironment new) ifNotNil: [variablesPresenter view
selectionsByIndex: selections]!

onRenameInstVar: anAssociation to: aString accept: aValueHolder
 "Private - In-place inst var rename has been made by the user, validate
it."

 aValueHolder
  value: (
   [self systemModel
    validateRenameInstVar: anAssociation value
    to: aString
    in: anAssociation key.
   true]
     on: Error
     do:
      [:ex |
      MessageBox errorMsg: ex description
       caption: ('Rename <1d>.<2d> to <3s>...'
         expandMacrosWith: anAssociation value
         with: anAssociation key
         with: aString).
      false])! !
!ClassBrowserAbstract categoriesFor:
#createSchematicWiring!initializing!public! !
!ClassBrowserAbstract categoriesFor: #onRenameInstVar:to:!event
handling!private! !
!ClassBrowserAbstract categoriesFor: #onRenameInstVar:to:accept:!event
handling!private! !

!SmalltalkSystem methodsFor!

validateRenameInstVar: oldString to: newString in: aClass
 (self isValidInstanceVariableName: newString for: aClass)
  ifFalse:
   [self
    error: ('<1d> is not a valid instance variable name in <2d>'
expandMacrosWith: newString with: aClass)]! !
!SmalltalkSystem categoriesFor:
#validateRenameInstVar:to:in:!helpers!private! !

Ian, Eric,

> After a quick look I decided they would be the best people for the job :-)

Going for the burn in the good old c.l.s.d spirit of Random Hacking Around, I
tried adding

    variablesPresenter view beActive.

to the start of ClassBrowserAbstract>>onRenameInstVar:to:accept:.  That seems
to fix the symptoms !

I really don't know what I'm doing here, so I won't try to guess why that
"works".

Still, it may help OA narrow down the problem.

    -- chris

Blair,

Since I made the original post, let me be the first to thank you.  The
patch fixed the problem.

Just an aside...Speaking as a neophyte, seeing patches to the product in
the raw like this is very instructive.  

Thanks very much, again.

Cheers,

Eric
for
> > the desired scope of the renaming.  The mouse cursor is hidden,
however.
> > The mouse cursor is visible _outside_ the window owned by Dolphin.
One the
> known bug "2118: Prompt to rename accessors when renaming an inst var
> using
> in-place edit leaves focus in the ListView's edit box". Patch below,
to be validation." validate

"Eric Taylor" <[hidden email]> wrote in message
news:000c01c68e63$17e3cf30$6500a8c0@server...
> Blair,
>
> Since I made the original post, let me be the first to thank you.  The
> patch fixed the problem.
>
> Just an aside...Speaking as a neophyte, seeing patches to the product in
> the raw like this is very instructive.

Yes, although I suspect that patch does a little more than just fix that
particular problem since it seems the author (probably me) has taken the
opportunity to tidy some other stuff up at the same time :-)

Regards

Blair

Blair,

Just for completeness I'll point out that the patch doesn't fix the related
problem I mentioned.  In the ClassBrowser renaming the instVar and then
ending the edit by clicking on another class in the class hierarchy view
results in the matching instVar (slot wise) in the newly selected class
being renamed.  It does rather fall into the "if you do that then you
deserve all you get" category though. :)


BTW, Is there a fixed/still to be fixed page available for 6.03?

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.