Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005567 [Squeak] Morphic major always 12-04-06 03:40 09-08-08 19:34
Reporter wiz View Status public  
Assigned To
Priority normal Resolution fixed  
Status closed   Product Version 3.10
Summary 0005567: hand targetOffset has been misused more times than it has been used correctly.
Description 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}


Additional Information 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.

MouseEvent>>targetPoint
    "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
Attached Files  TargetOffsetFix-wiz.2.cs [^] (5,373 bytes) 12-04-06 09:54
 HandBugs.st [^] (431 bytes) 12-04-06 09:54
 HandBugs-wiz.1.cs [^] (567 bytes) 06-03-07 05:40

- Relationships

SYSTEM WARNING: Creating default object from empty value

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. 

- Notes
(0008537 - 898 - 943 - 943 - 943 - 943 - 943)
wiz
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.

HandBugs.st 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.
 
(0010761 - 398 - 446 - 446 - 580 - 580 - 580)
wiz
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
 
(0010762 - 73 - 73 - 73 - 73 - 73 - 73)
wiz
06-03-07 05:54

fixes in as of sq7105. test names need to be corrected see related issue.
 
(0012599 - 44 - 44 - 44 - 44 - 44 - 44)
KenCausey
09-08-08 19:34

Harvested in update 7081, released with 3.10
 

- Issue History
Date Modified Username Field Change
12-04-06 03:40 wiz New Issue
12-04-06 09:54 wiz File Added: TargetOffsetFix-wiz.2.cs
12-04-06 09:54 wiz File Added: HandBugs.st
12-04-06 10:06 wiz Note Added: 0008537
06-03-07 05:40 wiz File Added: HandBugs-wiz.1.cs
06-03-07 05:47 wiz Relationship added related to 0006429
06-03-07 05:52 wiz Note Added: 0010761
06-03-07 05:54 wiz Note Added: 0010762
06-03-07 05:54 wiz Status new => resolved
06-03-07 05:54 wiz Resolution open => fixed
06-03-07 05:54 wiz Fixed in Version  => 3.10
06-06-07 02:33 wiz Relationship added child of 0006530
01-21-08 05:42 user821 Issue Monitored: user821
09-08-08 19:34 KenCausey Status resolved => closed
09-08-08 19:34 KenCausey Note Added: 0012599


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
80 total queries executed.
52 unique queries executed.
Powered by Mantis Bugtracker