[BUG] TargetSighter-wiz ( [cd][er][et] Is there a customer for this cs? ) ( Transfered from Archive ID 23264 : the original bug report )

[tomkoenig at mindspring.com]

--------------Original Message----------------
How do you set the target on a slider or a button or a
...
There is an entry in the menu for setting the target if it can find one.
 Which uses:
(self world rootMorphsAt: aHandMorph targetOffset)
size > 1
		ifTrue: [aCustomMenu add: 'set target' translated
action: #setTarget:].
	target
		ifNotNil: [aCustomMenu add: 'clear target'
translated action: #clearTarget]
		
Now rootMorphsAt: expects a relevant point in world as its argument.
What has been passed to it instead is the dinky target offset. Which
gives a irrelvant location unless the hand position happens to be 0 at 0. 
anyway (on a 1024x786 screen what are your chances.)
So the only way to get the menu item to appear is to place two copies of
your target in the upper right hand corner of your screen and bring up
the red menu on the slider.
 I dont think this is what anyone intended. This bug has been around so
long its aquired viral qualities.The phrase
	 (self world rootMorphsAt: aHandMorph targetOffset)
appears to have been adopted by most of the target setters.
This is probably one of the reasons Button properties is not working.
	
	MenuMorph
	SimpleButtonMorph
	SimpleSliderMorph
	and
	StringButtonMorph
	>>setTarget: all use this phrase
	the latter three use it in
	>>addCustomMenuItems:hand:  to test for a settable target.
	
	as does MovieMorph: (also in >>insertIntoMovie:).
	
The correct argument is probably (hand pos - hand targetOffset) but the
whole shebang wants to be factored into something like hasTarget and
aquireTarget. (Note: I later tried variations of points but did not seem
to be able to improve things.
I finally realized wanted the menu to work similar to embed into and
designed a fix along those lines.)
	
I am trying to program my stuff and besides being unsure of what the
correction actually is I am a little angry that the care takers of
squeak have taken
so little care. Hopefully one of the responsible parties for the
perpetuation of this bug will take responsibility for tracking down
implementing and testing the fix.  Please note that this is a stealth
bug that users can't see because the hasTarget test
will fail hiding the menu item that would cause the bugged aquireTarget
code to noisily fail. I wonder if the tests were added as a "bug fix" in
the first
place.  
	

'From Squeak3.7beta of ''1 April 2004'' [latest
update: #5967] on 17 July 2004 at 11:28:03 pm'!
"Change Set:		SetTargetsBugFix-wiz
Date:			17 July 2004
Author:			Jerome Peace (wiz)

For buttons and sliders #setTarget: is bizarrely bugged. I've written
about this elsewhere so I won't document it here.

I believe this fixes target setting in SimpleSliderMorph. If havesters
agree then I hope they will find someone to propagate the fix to buttons
and
button properties.  And please rip out the bugged setTarget methods from
the image.  

Blind code copying has turned one bug into many. I can't stress this
enough bugged code was COPIED without ever being properly tested. Indeed
it looks as if
tests containing the same bug were put into the menusto hide the bug
from being DETECTED. The result isuseless, unusable unused code being
propogated as if
it were correct. 

Question for Harvesters: What should the Story for targets of sliders
and buttons be? For the fix I have use the modified story for embed
morph. I can also
imagine a story that says:

'to aquire a target for the button you drag the james
bond crosshair handle from the halo of the slider over
the object to be targeted and lift the mouse. If more
than on object is under the cross hair a menu is
given. If only the world paste up is under the cross
hair nothing is changed.'

Alternate to the menu idea the cross hair could pick
the topmost morph as target.

So harvesters what should the story be. Do you know
who would implement it?"!


!Morph methodsFor: 'meta-actions' stamp: 'wiz
7/17/2004 22:17'!
potentialTargets
	"Return the potential targets for the receiver.
	This is derived from
Morph>>potentialEmbeddingTargets."
	owner ifNil:[^#()].
	^owner morphsAt: self referencePosition behind: self unlocked: true
not! !

!Morph methodsFor: 'meta-actions' stamp: 'wiz
7/17/2004 23:27'!
targetWith: evt
	"Some other morph become target of the receiver"
	|  menu newTarget |
	menu _ CustomMenu new.
	self potentialTargets  do: [:m | 
		menu add: (m knownName ifNil:[m class name asString]) action: m].
	newTarget _ menu startUpWithCaption: ( self externalName, '
targets...').
	newTarget ifNil:[^self].
	self target: newTarget.! !


!SimpleSliderMorph methodsFor: 'menu' stamp: 'wiz
7/17/2004 22:34'!
addCustomMenuItems: aCustomMenu hand: aHandMorph

	super addCustomMenuItems: aCustomMenu hand:aHandMorph.
	aCustomMenu addLine.
	aCustomMenu add: 'set action selector' translated action:
#setActionSelector.
	aCustomMenu add: 'change arguments' translated action: #setArguments.
	aCustomMenu add: 'set minimum value' translated action: #setMinVal.
	aCustomMenu add: 'set maximum value' translated action: #setMaxVal.
	aCustomMenu addUpdating: #descendingString action: #toggleDescending.
	aCustomMenu addUpdating: #truncateString action: #toggleTruncate.
	aCustomMenu add: 'set target' translated action: #targetWith: .
	target ifNotNil: [
		aCustomMenu add: 'clear target' translated action: #clearTarget].
! !


!

The Gzipped changeSet is attached. 

Yours in service, -Jerome Peace

P.S. You should  remove the postscript.  Though here it does not change
anything the comment suggests it changes the color of literals to
orange. I removed the
changed code from the change set but forgot to delete the Dialect stream
reinitialzation. Thanx -Jer