<div dir="ltr"><div>Hi Marcel, thanks for the explanations.</div><div>The sole purpose of halt was indeed to check at which depth the handler would be activated.</div><div>This gave me a clue about the possibility or not to detect interception by just stepping (how deep at worse would I have to step into).</div><div>Another alternative that I did not try out would have been to step in two debuggers in parallel,</div><div>one with the red or yellow event, the other with blue...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 17 avr. 2021 à 14:51, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_2824106884039191489__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">
Hi Nicolas,<div><br></div><div>I fixed this bug in MorphicTests-mt.77 by disabling "Morph haloForAll".</div><div><br></div><div>Well, I think that event handling in Morphic has a conceptual complexity that is comparable to other (non-Smalltalk) UI frameworks. Events travel through the hierarchy of morphs, starting in the world. Only one morph can be the actual handler. Event filters might intercept this, do something different, and tell the mechanism to further ignore the event.</div><div><br></div><div>In this test03EventHandler, the question was why that event did not reach its destination (here: that block in the test method). Of course, "self halt" does not work when a destination is not reached.</div><div><br></div><div>Why might an event not reach the desired handler (morph):</div><div>a) the target handler omits to reply to #handlesMouseDown: (etc.)</div><div>b) another (maybe sibling) morph is on top of it</div><div>c) the morph is not even in the hand's world</div><div>d) an event filter intervenes and marks the event as "ignored"</div><div><br></div><div>The cases a), b), and c) can easily be checked through the debugger. The world and the entire morph hierarchy is easily accessible. Bounds can be checked against the event's position.</div><div><br></div><div>This leaves case d), which is quite tricky to debug. Well, one can try to figure out, which implementor of #filterEvent:for: is the culprit. There are only 13 in the current Trunk. This path might lead to success. :-)</div><div><br></div><div>But I think we can do better. That's why I made it possible to log event-ignoring coming from arbitrary event filters in the hand (morph) we use in the event tests. The log includes short stacks to figure out the actual event filter. Here is an example for this bug:</div><div><br></div><div><img id="gmail-m_28241068840391914890c953981-5a59-4969-8986-8c0fee736807" src="cid:178e041e488cb971f161" width="399" height="168"><br></div><div><br></div><div>While I did immediately recalled that "blue button fails" means "halo got the event" because I did something to the halo dispatcher in the last weeks, this is typically unclear for the average programmer, who is jumping between domains (and classes/packages) in the entire image. SO! By inspecting the "eventsIgnored" through the debugger, one can easily see both "mouseDown blue" and "PasteUpMorph >> tryInvokeHalo:" as the culprit.</div><div><br></div><div>That's why disabling the halo during this test solves the issue.</div><div><br></div><div>Best,</div><div>Marcel</div><div></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
<p style="color:rgb(170,170,170);margin-top:10px">Am 17.04.2021 13:43:08 schrieb Taeumel, Marcel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt;color:black">
My bad. I will take a look at it. Maybe I also find a way to improve documentation and code. I will keep you posted.<br>
<br>
</div>
<div dir="auto" style="direction:ltr;margin:0px;padding:0px;font-family:sans-serif;font-size:11pt;color:black">
Marcel<span id="gmail-m_2824106884039191489ms-outlook-android-cursor"></span></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_2824106884039191489divRplyFwdMsg" dir="ltr"><span style="font-family:Calibri,sans-serif;color:rgb(0,0,0)"><b>From:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> on behalf of Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>><br>
<b>Sent:</b> Saturday, April 17, 2021 12:12:05 AM<br>
<b>To:</b> The general-purpose Squeak developers list <<a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>><br>
<b>Subject:</b> [squeak-dev] I've reached my limits</span>
<div> </div>
</div>
<div><span style="font-size:10pt"><span style="font-size:11pt">
<div>I often recommend using the debugger in order to acquire a better<br>
understanding of code.<br>
A priori, I think that no bug can resist a thorough analysis/best efforts.<br>
<br>
A posteriori, it seems that I've reached my limits with the debugging<br>
of test03EventHandler.<br>
If you find where the blue button down event is filtered/catched<br>
without prior knowledge of Morphic event handling, by just stepping,<br>
then either you are lucky, or your analytical capabilities are<br>
tremendous (you can probably focus on 77 symbols simultaneously rather<br>
than the average of 7)!<br>
For me, that's not the right angle of attack!<br>
<br>
All I acquired is an increased reluctance to start a deeper learning<br>
of Morphic, more questioning about whether I'm becoming too old, and<br>
the conviction that things are maybe getting too complex (more than<br>
strictly necessary?).<br>
<br>
Look at the full stack (which BTW is not the full stack -- and more<br>
not shown --).<br>
<br>
I let the test03EventHandler fix to people with prior knowledge, not<br>
only because I was distracted by debugger bugs...<br>
<br>
Nicolas<br>
<br>
--- The full stack ---<br>
MorphicEventTests(Object)>>halt<br>
[] in MorphicEventTests>>test03EventHandler<br>
EventHandler>>send:to:withEvent:fromMorph:<br>
EventHandler>>mouseDown:fromMorph:<br>
Morph>>mouseDown:<br>
Morph>>handleMouseDown:<br>
MouseButtonEvent>>sentTo:<br>
Morph>>handleEvent:<br>
MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:<br>
[] in MorphicEventDispatcher>>dispatchMouseDown:with:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
MorphicEventDispatcher>>dispatchMouseDown:with:<br>
MorphicEventDispatcher>>dispatchEvent:with:<br>
Morph>>processEvent:using:<br>
Morph>>processEvent:<br>
[] in MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf:<br>
Array(SequenceableCollection)>>do:<br>
PasteUpMorph(Morph)>>submorphsDo:<br>
MorphicEventDispatcher>>dispatchEvent:toSubmorphsOf:<br>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:<br>
[] in MorphicEventDispatcher>>dispatchMouseDown:with:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
MorphicEventDispatcher>>dispatchMouseDown:with:<br>
MorphicEventDispatcher>>dispatchEvent:with:<br>
PasteUpMorph(Morph)>>processEvent:using:<br>
[] in PasteUpMorph>>processEvent:using:<br>
[] in ActiveWorldVariable class(DynamicVariable class)>>value:during:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
ActiveWorldVariable class(DynamicVariable class)>>value:during:<br>
[] in ActiveWorldVariable class>>value:during:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
ActiveWorldVariable class>>value:during:<br>
PasteUpMorph>>becomeActiveDuring:<br>
PasteUpMorph>>processEvent:using:<br>
PasteUpMorph(Morph)>>processEvent:<br>
HaloMorph(SimpleHaloMorph)>>mouseDown:<br>
HaloMorph>>mouseDown:<br>
HaloMorph(Morph)>>handleMouseDown:<br>
MouseButtonEvent>>sentTo:<br>
HaloMorph(Morph)>>handleEvent:<br>
MorphicEventDispatcher>>dispatchEvent:withHandler:withMorph:<br>
[] in MorphicEventDispatcher>>dispatchMouseDown:with:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
MorphicEventDispatcher>>dispatchMouseDown:with:<br>
MorphicEventDispatcher>>dispatchEvent:with:<br>
HaloMorph(Morph)>>processEvent:using:<br>
MorphicEventDispatcher>>doProcessingForFocusEvent:with:<br>
MorphicEventDispatcher>>dispatchFocusEventFully:with:<br>
MorphicEventDispatcher>>dispatchFocusEventAllOver:with:<br>
HaloMorph(SimpleHaloMorph)>>processFocusEvent:using:<br>
HaloMorph(Morph)>>processFocusEvent:<br>
[] in [] in [] in HandMorphForEventTests(HandMorph)>>sendFocusEvent:to:clear:<br>
[] in ActiveEventVariable class(DynamicVariable class)>>value:during:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
ActiveEventVariable class(DynamicVariable class)>>value:during:<br>
[] in ActiveEventVariable class>>value:during:<br>
FullBlockClosure(BlockClosure)>>ensure:<br>
ActiveEventVariable class>>value:during:<br>
MouseButtonEvent(MorphicEvent)>>becomeActiveDuring:<br>
[] in [] in HandMorphForEventTests(HandMorph)>>sendFocusEvent:to:clear:<br>
[] in ActiveHandVariable class(DynamicVariable class)>>value:during:<br>
-- and more not shown --<br>
<br>
</div>
</span></span></div>
</div></blockquote></div><br>
</blockquote></div>