Source Tracking System bug discovered when using the Refactoring Browser 
Author Message
 Source Tracking System bug discovered when using the Refactoring Browser

I am using David Goriseks Source Tracking System 2.01 and Dolphin 4.01
Professional and it seems to be a bug in ClassBrowserShell>>onViewOpened
which belongs to the STS. When opening the Refactoring Browser, I get the
following error:

ListView does not understand #referee

17:47:21,  den 6 april 2001: 'ListView does not understand #referee'
ListView(Object)>>doesNotUnderstand:
RefactoringBrowserShell(ClassBrowserShell)>>onViewOpened
RefactoringBrowserShell>>onViewOpened
RefactoringBrowserShell(Shell)>>view:
RefactoringBrowserShell class>>create:
RefactoringBrowserShell class(Presenter class)>>create
RefactoringBrowserShell class(Presenter class)>>show
RefactoringBrowserShell class(SmalltalkToolShell class)>>show
[] in RefactoringBrowserShell class>>initialize
[] in SmalltalkSystemIcon>>openIn:
BlockClosure>>ifCurtailed:

and so on.

The bug is in the code after the comment "added by David Gorisek for Source
Tracking System".

By changing the line:

(self view viewNamed: 'methods' ifNone: []) referee contextMenu

to:

(self view viewNamed: 'methods' ifNone: []) contextMenu

the problem seems to be solved. But perhaps there are some side effects that
I am unaware of, perhaps for those not using the RB?

Regards,

Mikael Svane



Wed, 24 Sep 2003 00:00:23 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser

Quote:
>But perhaps there are some side effects that
>I am unaware of, perhaps for those not using the RB?

Answering my own questions...

If the RB isn't installed, the code:

(self view viewNamed: 'methods' ifNone: [])

answers a ReferenceView and #referee is of course needed, but with the RB
installed it instead answers a ListView. Obviously this isn't a bug in the
STS. I guess that the easiest solution would be if the RB had the following
loose method:

ListView>>referee
    ^ self

Regards,

Mikael



Wed, 24 Sep 2003 03:01:01 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser
Mikael,

Quote:
> If the RB isn't installed, the code:

> (self view viewNamed: 'methods' ifNone: [])

> answers a ReferenceView and #referee is of course needed, but with the RB
> installed it instead answers a ListView. Obviously this isn't a bug in the
> STS. I guess that the easiest solution would be if the RB had the
following
> loose method:

> ListView>>referee
>     ^ self

I'm a big fan of dispatching things through loose methods added to existing
classes, but, #referee is not a message I'd choose to add in this way.  It's
not pretty, but, a test on type in the troublesome code might be more
appropriate, or, one could define a different selector for the purpose.

With that said, perhaps OA would be willing to define View>>referee to
answer self, in effect, allowing one to always assume a reference is
present.  I've hit this kind of problem (alternating "normal" and reference
views) myself, and it would be nice to have a clean way to smooth it over.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.



Wed, 24 Sep 2003 03:38:19 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser
what version of the dolphin are you using? most of the testing was done on
version 3.


Quote:
> >But perhaps there are some side effects that
> >I am unaware of, perhaps for those not using the RB?

> Answering my own questions...

> If the RB isn't installed, the code:

> (self view viewNamed: 'methods' ifNone: [])

> answers a ReferenceView and #referee is of course needed, but with the RB
> installed it instead answers a ListView. Obviously this isn't a bug in the
> STS. I guess that the easiest solution would be if the RB had the
following
> loose method:

> ListView>>referee
>     ^ self

> Regards,

> Mikael




Wed, 24 Sep 2003 04:07:13 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser
I'm using 4.01 PL1 and STS 2.01.

/Mikael



Wed, 24 Sep 2003 16:06:21 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser

Quote:
>I'm using 4.01 PL1 and STS 2.01.

Sorry, that should be STS 2.02.

/Mikael



Wed, 24 Sep 2003 16:54:52 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser
Ok, I'll add the type checking in the next release. However this is not a
bug, it's simply that RB and CHB do not behave the same. And since the

STS from 4.0 beta1 to beta3 one could hardly call it a bug.

Best regards,

David


Quote:
> Mikael,

> > If the RB isn't installed, the code:

> > (self view viewNamed: 'methods' ifNone: [])

> > answers a ReferenceView and #referee is of course needed, but with the
RB
> > installed it instead answers a ListView. Obviously this isn't a bug in
the
> > STS. I guess that the easiest solution would be if the RB had the
> following
> > loose method:

> > ListView>>referee
> >     ^ self

> I'm a big fan of dispatching things through loose methods added to
existing
> classes, but, #referee is not a message I'd choose to add in this way.
It's
> not pretty, but, a test on type in the troublesome code might be more
> appropriate, or, one could define a different selector for the purpose.

> With that said, perhaps OA would be willing to define View>>referee to
> answer self, in effect, allowing one to always assume a reference is
> present.  I've hit this kind of problem (alternating "normal" and
reference
> views) myself, and it would be nice to have a clean way to smooth it over.

> Have a good one,

> Bill

> --
> Wilhelm K. Schwab, Ph.D.




Wed, 24 Sep 2003 16:46:58 GMT  
 Source Tracking System bug discovered when using the Refactoring Browser

Quote:
>Ok, I'll add the type checking in the next release. However this is not a
>bug, it's simply that RB and CHB do not behave the same. And since the

>STS from 4.0 beta1 to beta3 one could hardly call it a bug.

When I started this thread, I thought that the bug was in the STS. After
having examined the problem, I found that it was caused by the RB answering
a ListView instead of a ReferenceView and therefore I suggested that the
change would be added to the RB, since it doesn't behave like the normal
CHB.

However I understand why Bill doesn't like my suggestion, but I don't think
that the STS should be changed. It can't be David's responsibility to
predict where other packages might change the behaviour of the different
browsers and add type checking everywhere where it might be needed, in my
opinion.

Perhaps Bill's suggestion (#referee added to View by OA) is the best one,
especially if others have encountered this problem before?

Best regards,

Mikael



Wed, 24 Sep 2003 18:58:24 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Refactoring Browser. VSE Refactoring Browser

2. Refactoring browser bug

3. Source Tracking System 3.0 released

4. Source Tracking System 2.1 released

5. ANN: Source Tracking System 2.01 for Dolphin Smalltalk 4.0 available

6. ANN: Source Tracking System 2.0 for Dolphin Smalltalk 4.0 available

7. BUG TRACKING SYSTEM

8. SC-Track Roundup 0.5.8 - an issue tracking system

9. SC-Track Roundup 0.6.0b2 - an issue tracking system

10. SC-Track Roundup 0.5.7 - an issue tracking system

11. SC-Track Roundup 0.5.6 - an issue tracking system

12. SC-Track Roundup 0.5.5 - an issue tracking system

 

 
Powered by phpBB® Forum Software