Remove-Refactoring shouldn't ask for confirmation (and allow multi selection)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Remove-Refactoring shouldn't ask for confirmation (and allow multi selection)

Carsten Haerle
Remove-Refactoring shouldn't ask for confirmation otherwise it is not a time
saver (I could also first browse references and then chosse Delete). In
addition a multi selections in the browsers would be helpful (especially
here). Maybe talk to the Tool+ guys, because the did that already as an
enhancement.

Regards

Carsten Härle

!RefactoringSmalltalkSystem methodsFor!

safeRemoveMethod: aSelector from: aClass inEnvironment: aBrowserEnvironment
 "Implement the 'Remove Method' method refactoring."

"DELETE FROM HERE"
 (MessageBox
  confirm: ('Remove %1>>%2 (if it has no references or is equivalent to the
superclass implementation)?'
    formatWith: aClass name
    with: aSelector)
  caption: 'Safe Remove Method...') ifFalse: [^false].
"DELETE UNTIL HERE"
 self handleRefactoringException:
   [| model refactoring |
   model := RBNamespace onEnvironment: aBrowserEnvironment.
   refactoring := RemoveMethodRefactoring
      model: model
      removeMethods: (Array with: aSelector)
      from: aClass.
   model name: refactoring displayString.
   refactoring execute].
 ^true! !
!RefactoringSmalltalkSystem categoriesFor:
#safeRemoveMethod:from:inEnvironment:!public!refactoring! !


Reply | Threaded
Open this post in threaded view
|

Re: Remove-Refactoring shouldn't ask for confirmation (and allow multi selection)

Bill Dargel
Carsten Haerle wrote:
>
> Remove-Refactoring shouldn't ask for confirmation ...

I'll second that!

It's not known as a "safe" remove for nothing. The extra confirmation
ends up just being an annoyance, which I also removed some time ago.

Another thought though, is that the confirmation is nice the first time
or two one uses it -- as part of the newbie learning experience. But,
then it would be a good candidate for a "check here to not see this
confirmation again" option that is used as a technique by a number of
applications.

Might not that sort of thing be a good candidate for a general Dolphin
framework enhancement? I'm sure that if one looked around, there would
probably be quite a few uses for such a thing.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA


Reply | Threaded
Open this post in threaded view
|

Re: Remove-Refactoring shouldn't ask for confirmation (and allow multi selection)

Blair McGlashan
"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
> Carsten Haerle wrote:
> >
> > Remove-Refactoring shouldn't ask for confirmation ...
>
> I'll second that!
>
> It's not known as a "safe" remove for nothing. The extra confirmation
> ends up just being an annoyance, which I also removed some time ago.

Yes I agree, but ...

>
> Another thought though, is that the confirmation is nice the first time
> or two one uses it -- as part of the newbie learning experience.

... which is why the prompt remains (to guard against an inexperienced user
doing something they may not know how to undo) ...

>... But,
> then it would be a good candidate for a "check here to not see this
> confirmation again" option that is used as a technique by a number of
> applications.

Absolutely.

>
> Might not that sort of thing be a good candidate for a general Dolphin
> framework enhancement? I'm sure that if one looked around, there would
> probably be quite a few uses for such a thing.

We have often "nearly" put that in. There is a general need for a more
flexible message box than that provided by the system. What has put us off
doing this so far has always been the amount of work involved in
implementing a message box that dynamically resizes to fit the text in the
same way the system box does, and which allows for a configurable number of
buttons with configurable captions, etc. Of course it can be done, but it
has never quite hit the top of the list. I think it is about time it was
formally recorded in our change tracking database though (#1455).

Regards

Blair