Anonymous | Login | 04-16-2021 15:15 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0003333 | [Squeak] Morphic | minor | always | 03-21-06 02:28 | 07-14-06 15:45 | ||||
Reporter | MarcusDenker | View Status | public | ||||||
Assigned To | |||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.9 | ||||||
Summary | 0003333: SimpleButtonMorph bug | ||||||||
Description |
Cesare Marilungo wrote: if I create a button with this code: b _ SimpleButtonMorph new label: 'click me'; position: Display center; addMouseUpActionWith: 'self delete'. b openInWorld. If I click on it the border that appears on mouseDown is not centered with the button. I understand it is something in Morphic>>drawRolloverBorderOn but I don't know enough yet to help fixing it. c. Also, If I leftclick on the button but then I step out of it without releasing the mouse button (as if I've changed my mind and don't want to trigger it anymore) the button color becomes darker than before. |
||||||||
Additional Information | |||||||||
Attached Files | |||||||||
|
![]() |
|||||||||||
SYSTEM WARNING: Creating default object from empty value
|
![]() |
|
(0004546 - 916 - 976 - 976 - 1099 - 1099 - 1099) wiz 03-22-06 03:13 |
analysis: There are two complaints here. I will deal with the second one (the color change) in a new mantis report 0003339 . The first problem is proving harder to track down. The interesting observation is the larger the button is grown the more centered the rollover shadow appears. The Morph method for drawing the shadow looks fairly correct. There are probably two or more roundoff bugs causing the problems. One may be in getting the boundry for the shadow form. This is compounded by the fact that that form is magnified to fit within a larger border. The other roundoff problem is probably in the antialiasing that warp cellsize 2 is doing at the borders of the form. The end result is that the right and bottom are being skimped on color. Practically, it might be good to just change the border color on enter and leave w/o using a roll over shadow at all. Yours in service, -- Jerome Peace |
(0004547 - 529 - 619 - 619 - 619 - 619 - 619) wiz 03-22-06 03:53 edited on: 03-22-06 03:58 |
more: The roll over halo is being added by the way addMouseUpActionWith: is being implemented. This seems to do a lot that is doesn't strictly need to do. So maybe it could use some simplification and refactoring. This portion of the bug I would relegate to a low priority and a later time. It is not a SimpleButtonMorph bug per se. It is a good find of another roundoff problem. And the other [proper action is probably to rethink the Morph>>addMouseUpActionWith: code. Yours in service, -- Jerome Peace. |
(0004557 - 1299 - 1473 - 1473 - 1473 - 1473 - 1473) wiz 03-24-06 07:06 edited on: 03-24-06 07:34 |
still more: Another way to get the roll over halo bug. From obects basic get a 'press me' button. (it inherits from SimpleButtonMorph) From the red halo menu extras... select addMouseUpAction. Fill in the blank (I used #flash) Now we get the same roll over behavior being described. history: This does not happen in 3.9a from 3.0 ie 6665. There you get the normal mouse up action with the roll over centered on the button and bigger boarder all around. I check the intermediate images. The error was introduced somewhere 6684-6690. There was a change of behavior in 6686. There was no roll over on entering the button only when it was pressed. This pressed roll over halo was centered and of the right width. So the other halo may just have been made transparent at this point. By 6690 we were seeing a smaller misplaced halo. And also the 6684 actions did what you would expect. showed the roll over on mouse enter. intensified on press. and dissappeared on leave. The 6690 and following behavior had no enter roll over halo, just the misplaced on on mouse press. I didn't have the intermediate images to find out exactly where. The misplaced halo shows the rounded corners clearly. Which means I am probably off base on the round off error theory. |
(0004558 - 1149 - 1352 - 1352 - 1352 - 1352 - 1352) wiz 03-24-06 09:35 |
Alright, found the bug. First some commentary on the other changes: hmmm: in 6684 SimpleButtonMorph was modified to do the button color changing on mouse enter and leave. Morphic-md.38 jrp 7/3/2005 18:06 SimpleButtonMorph handlesMouseOverDragging: a typical time stamp. this overrides the eventhandler behavior on mouse enter and leave. so no more roll over halo. The mouse down event did not change and it call super mouseDown: evt which will invoke the eventhandler action( i.e. the rollover halo.) And NOW ----- TaDa the fix: In 6690 the obscure culprit is the change to shadow form. 'JW 7/12/2005 20:12 Morph shadowForm' 'ar 9/1/2000 14:23 Morph shadowForm' the change substituted self fullbounds for bounds when setting the size of the canvas. The offsets were still calculated from bounds. fullbounds as far as the roll over halo is concerned is the wrong thing to use. And reverting back to the previous method cured the symptom. As usual I don't know what prompted the original change. Recommendation: revert back to: 'ar 9/1/2000 14:23 Morph shadowForm' Yours in service -Jerome Peace |
(0004559 - 282 - 300 - 300 - 300 - 300 - 300) wiz 03-24-06 09:49 |
Reminder sent to: MarcusDenker This change was introduced in Morphic-md.44 I don't know who JW is (there is a jwelton in the reminder list). I'll leave it to you to contact JW to find out what the change was trying to fix. The revision will fix the rollover problem which affects all addMouseUpAction morphs. |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
69 total queries executed. 42 unique queries executed. |