Thanks Doru. I appreciate the update. No hurry since I hit this curiosity just while I was tracing through the innards of Mondrian to understand it better, plus I have found a work around by using a temporary variable, but I'd still like to gain an understanding this.

Perhaps just focussing on these three lines...
btcRenderer1 := ann viewRenderer.             
"self halt."
btcRenderer2 := ann viewRenderer.
...for case1, when the "self halt" is commented out, btcRenderer1 and btcRenderer2 are identical.
...for case2, when the "self halt" is uncommented, btcRenderer2 is nil.  The only action taken was to immediately <Proceed> at the pre-debugger.

Where...
MOAnnouncer>>viewRenderer
    ^ viewRenderer

and the only reference to instance variable viewRenderer is...
MOAnnouncer>>viewRenderer: anObject
    viewRenderer := anObject

which I monitor and it seems this is not called.

So what I am trying to understand is why for case2 the instance variable viewRenderer loses its value to become nil.  I have attached two file-outs that hopefully makes it quicker to try out. Instructions included inline. Note this was with a fresh download of Moose 4.6.

cheers -ben

Tudor Girba wrote: 
Hi Ben,

Your mail requires a bit more attention span than I can afford right now, and I do not quite understand what the issue actually is. But, this does not mean it went unnoticed :).

Cheers,
Doru


On 9 Apr 2012, at 16:09, Ben Coman wrote:

  
My understanding of Announcements is not so good yet, but here is another opportunity.  While I was trying to trace some code execution to troubleshoot a ticket that I logged for Mondrian, I bumped into some behaviour that seems strange, which I would like to understand.   At the end I propose a fix.

For the short example, execute [MOEasel open] then <Generate View> on the following:
----8<----
view shape rectangle size: 20.
view interaction registerForEvent: MOMouseDown forNode: #yourself updateNode:  [ :v | "self halt." view forNode: v do: [ view nodes: (1 to: 2) ] ] updateLayout: true.
view nodes: (1 to: 4).
----8<----

Click on a node and observe that node successfully has two nodes within it.

Now uncomment the "self halt" and <Generate View>, then click on a node.  When the pre-debugger for 'halt' appears, click <Proceed>.  Surprisingly a MNU now occurs in MOAnnouncement>>registerForEvent:forNode:updateNode:updateLayout due to 'ann viewRenderer' now returning nil.  Observe this occurs immediately after the execution of 'updateBlock' which contained the 'self halt'


The extended example modifies MOAnnouncement>>registerForEvent:forNode:updateNode:updateLayout as follows...
  | domainNode btcRenderer1 btcRenderer1test btcRenderer2  btcRenderer2test btcRenderer1test2 |
  self
      on: eventClass do: [:ann |
          "----8<---- begin debug code "
          btcRenderer1 := ann viewRenderer.              btcRenderer1test := (self viewRenderer == ann viewRenderer ).
          "self halt."
          btcRenderer2 := ann viewRenderer.              btcRenderer2test := (self viewRenderer == ann viewRenderer ).              { self viewRenderer. btcRenderer1. btcRenderer2. btcRenderer1test. btcRenderer2test.  } inspect.                   "----8<----  end debug code "                     ann element
              removeAllEdges;
              removeAllNodes.

<Generate View> on the same code as the short example with the 'self halt' commented out, then click on a node.
An inspector pops up showing array { aMOViewRenderer. aMOViewRenderer. aMOViewRenderer. true. true. }

Then uncomment the 'self halt' in the extended example, <Generate View> and click on a node.  <Proceed> at the pre-debugger.
An inspector pops up now showing array { aMOViewRenderer. aMOViewRenderer. nil. true. false. }
'ann viewRenderer ' has lost its value following the 'self halt.'

Proposed fix:
It can be seen from the second inspector that 'self viewRenderer' is identical to 'ann viewRenderer' and retains its value across the 'self halt', and so might be used in its place. 
thanks for you attention, your thoughts would be appreciated.
cheers, -ben

    

--
www.tudorgirba.com

"No matter how many recipes we know, we still value a chef."







_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev