SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak
Viewing Issue Advanced Details
5567 Morphic major always 12-04-06 03:40 09-08-08 19:34
closed 3.10  
none 3.10  
0005567: hand targetOffset has been misused more times than it has been used correctly.
When I was fixing targetsetting for sliders (and later buttons and menu items.)
I came accross several instances where event hand targetOffset was being used as in input to world rootMorphsAt: aPoint.
The input was meant to be a absolute position in world. targetOffset as the name implies is not a postion but a difference between two positions. Namely the target morphs and the current hand (event) position.

I marveled at the fact the incorrect code had been copied and resued incorrectly.

Now in Squeak 3.9 7067 looking at the senders of targetOffset shows that this spread of incorrect code is even more extensive than I first thought. And when I extended the target setting fixes I missed cleaning up quite a few instances of this bug.

See 0000503 for the original slider fixes.

In 7067 of the 12 senders the following get the use wrong.

ButtonProperties setTarget: {menu} wrong

Morph addPaintingItemsTo:hand: {menus}

MovieMorph addCustomMenuItems:hand: {menu}
MovieMorph insertIntoMovie: {menu}

PasteUpMorph paintArea {world state}
SimpleButtonMorph setTarget: {menu}
SimpleSliderMorph setTarget: {menu}
SketchMorph insertIntoMovie: {menu}
StringButtonMorph setTarget: {menu}

And these three get it right.

FlapTab mouseMove: {event handling}
MouseEvent targetPoint {button state}
PasteUpMorph morphToDropFrom: {dropping/grabbing}

MouseEvent targetPoint {button state}
it would seem that this is the actual message that the others were looking for. Except it is sent to the event rather than the hand.
Note that the source ivar refers to the hand so it will do the right thing.

    "Answer the location of the cursor's hotspot, adjusted by the offset
    of the last mouseDown relative to the recipient morph."

    ^ position - source targetOffset

now to see if we can sub event target Point for the misused hand targetOffset.

Ther is no hand targetPoint (I guess it would be self position - targetOffset) hmmm.

Your in service, --Jerome Peace , Fearless Bug Tracker
related to 0006429closed  [Fix ] Test suite could not run tests because they didn't follow naming convention. 
child of 0006530new  A mother for button, slider and menuItem targeting and argumenting related reports. 
 TargetOffsetFix-wiz.2.cs [^] (5,373 bytes) 12-04-06 09:54 [^] (431 bytes) 12-04-06 09:54
 HandBugs-wiz.1.cs [^] (567 bytes) 06-03-07 05:40

12-04-06 10:06   
TargetOffsetFix-wiz.2.cs fixes the immediate bug by defining a HandMorph>targetPoint which will work like MouseEvent>targetPoint.
Then the places where targetOffset has been misused were replaced by the targetPoint message. contains a rudimentary test that just checks to see if HandMorph>targetPoint exists. I could not figure a good way to check the code replacement of the wrong message with the right one.
The better tests are desirable but this test will a least discern between the old state of affairs and the new.

When I fixed up the target setting I replaced the use of #setTarget: with #targetWith: for the menus. I didn't check to see if that was the only call on #setTarget: for those classes. I suspect now that it was and that those #setTarget: routines could actually be removed since they are no longer used in the menu items. I leave that for another time.
06-03-07 05:52   
HandBugs-wiz.1.cs uploaded.
I was playing with sq7105 and noticed the test had not been fixed.
So I refixed it and that is the change set.

Then I noticed that in sq7105 the fixes from mantis 0006429 had not been added yet. Those fixes take care of the problem and HandBugs-wiz.1.cs is NOT needed.

So I am going to mark this issue resolved.

Yours in curiosity and service, --Jerome Peace
06-03-07 05:54   
fixes in as of sq7105. test names need to be corrected see related issue.
09-08-08 19:34   
Harvested in update 7081, released with 3.10