Class Variable Browser Fix

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

Fwd: [Seaside] Class Variable Browser Fix

Ted Wrinch
Just had another browser walk-back. Not really sure how it happened - I was in the middle of stuff with the debugger. I'd also been getting some strange screen refresh issues beforehand - bringing an occluded workspace to the foreground left refresh damage behind, until I maximised it. But, anyway, though the debugger thinks that leftMorphs is an Array if you click on it in the lower left pane it is actually an OrderedCollection, for which remove:ifAbsent: is fine. Perhaps some kind of multi-thread malarky going on?

noticeMouseOver: aMorph event: anEvent
"Remember that the mouse is currently over some morph"

leftMorphs remove: aMorph ifAbsent: [ enteredMorphs nextPut: aMorph ].
overMorphs nextPut: aMorph.


Had to send a screen shot as I'm not sure how to copy the stack. Hadn't yet loaded the new OB.


in 

T.

Ted Wrinch




Begin forwarded message:

From: Ted Wrinch <[hidden email]>
Date: 15 July 2011 15:22:32 GMT+01:00
To: Seaside - general discussion <[hidden email]>
Subject: Re: [Seaside] Class Variable Browser Fix

Sounds reasonable. Ok, I'll look forward to picking it up. Any chance of error highlighting as one browses being added?

T.

Ted Wrinch




On 14 Jul 2011, at 14:28, Lukas Renggli wrote:

Load the OB package I fixed, because I had to change a few other
things to get everything working correctly. Your suggested patch alone
did not solve all problems.

Lukas

On Thursday, 14 July 2011, Ted Wrinch <[hidden email]> wrote:
I guessed it was Omnibrowser, but I will try and post to the appropriate list. Actually, I've just checked Pharo and I can reproduce neither issue there so maybe Seaside isn't the worst list for this.  BTW: I'm guessing OB provides all those nice code checking and refactoring tools; in which case I thinks it's a great addition to the Smalltalk environment. One thing I would suggest adding is colour coding for errors in methods that are selected in the browser. It currently only checks code that is being added or modified. It would be particularly helpful feature to partially overcome Smalltalk's weakness in allowing code to exist which references non-existent, renamed or removed methods.

Ok, I've gone back to a clean Seaside image and changed the offending line back to:

(requestor selectedClass notNil and: [ (binding := requestor selectedClass bindingOf: target selector) notNil and:[binding value notNil]])

For this case if I go to the ButtonDecodeTable class variable in InputEventSensor and right click I get a walk-back. If I change the line further to:

(requestor selectedClass notNil and: [ (binding := requestor selectedClass bindingOf: target selector) notNil and:[binding value notNil and:[binding value class canUnderstand: #asNode]]])

I don't. But testing is hard and I maybe missing something here.

T.

Ted Wrinch




On 14 Jul 2011, at 09:12, Lukas Renggli wrote:

If you go to a class variable usage in the browser, say DefaultDirectory in FileDirectory>>default, and select and right click it, Seaside brings up a walk-back.

I cannot reproduce that.

Also note, that this is not Seaside related, but OmniBrowser (I thus
reply to the Pharo list).

My fix for this re-writes the existing method a little by using '&' instead of the older 'and:', which I find clearer. What I've done is check that the value can respond to #asNode:

globalReference
      | binding |
      target hasSelector
              ifFalse: [ ^ nil ].
      (requestor selectedClass notNil & (binding := requestor selectedClass bindingOf: target selector) notNil & binding value notNil & (binding value class selectors includes: #asNode))
              ifTrue: [ ^ binding value asNode ].
      (binding := Smalltalk classNamed: target selector) notNil
              ifTrue: [ ^ binding value asNode ].
      ^ nil

This certainly introduces other bugs. The use of the non-eager #and:
is intentional, because if "requestor selectedClass" is nil,
"requestor selectedClass bindingOf:" is not supposed to be evaluated.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


--
Lukas Renggli
www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
12