I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
Rudi Angela
__________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
On Wednesday 30 April 2003 11:05 am, Rudi Angela wrote:
I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
Look at DoubleClickExample for instance. You have to ask the Hand to #waitForClicksOrDrag:event:
I would consider the handleXXX methods to be private. In fact, I tried to move them out of Brick (and failed - but I may try it again soon). These methods do more than just let you add a hilight to your morph when the mouse goes down on it. They also do the event forwarding to models/delegates. So I think you should not override them as I consider them to be part of the system level event dispatching mechanism.
Example from morph:
handleMouseDown: anEvent "System level event handling." anEvent wasHandled ifTrue:[^self]. "not interested" anEvent hand removePendingBalloonFor: self. anEvent hand removePendingHaloFor: self. anEvent wasHandled: true. anEvent controlKeyPressed ifTrue:[^self invokeMetaMenu: anEvent]. "Make me modal during mouse transitions" anEvent hand newMouseFocus: self event: anEvent. anEvent blueButtonChanged ifTrue:[^self blueButtonDown: anEvent]. (self allowsGestureStart: anEvent) ifTrue: [^ self gestureStart: anEvent]. self mouseDown: anEvent. anEvent hand removeHaloFromClick: anEvent on: self. (self handlesMouseStillDown: anEvent) ifTrue:[ self startStepping: #handleMouseStillDown: at: Time millisecondClockValue + self mouseStillDownThreshold arguments: {anEvent copy resetHandlerFields} stepTime: 1].
Notice that if you just override this method without calling super, balloons will stay open, menus will stop working, and mouseStillDown tracking won't work. Instead you want to implement mouseDown: to add your behavior.
On Wednesday, April 30, 2003, at 12:05 PM, Rudi Angela wrote:
I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
Rudi Angela
Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
Try:
myMorph on: #startDrag send: #onDrag to: myMorph. myMorph on: #doubleClick send: #onDoubleClick to: myMorph.
Note that #handlesMouseDown: should be never ever overridden unless you know EXACTLY what you are doing. You're starting to infere with some deep down notions of Morphic and likely to break more than you (think you) fix.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Rudi Angela Sent: Wednesday, April 30, 2003 8:05 PM To: squeak-dev@lists.squeakfoundation.org Subject: [Q] doubleclickable and dragable morph: how?
I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
Rudi Angela
Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
Yeah, I'd vote that these be moved into a category called 'private-events-processing' or something like it to make the point. Comments in the methods with big warnings would be good too.
Those seem to be the first methods new users (including this one) go after to hook an event.
On Wednesday, April 30, 2003, at 08:17 PM, Andreas Raab wrote:
Try:
myMorph on: #startDrag send: #onDrag to: myMorph. myMorph on: #doubleClick send: #onDoubleClick to: myMorph.
Note that #handlesMouseDown: should be never ever overridden unless you know EXACTLY what you are doing. You're starting to infere with some deep down notions of Morphic and likely to break more than you (think you) fix.
Cheers,
- Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Rudi Angela Sent: Wednesday, April 30, 2003 8:05 PM To: squeak-dev@lists.squeakfoundation.org Subject: [Q] doubleclickable and dragable morph: how?
I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
Rudi Angela
Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
I just want to say that #handlesMouseDown: is used in many places inside the image and also in many tutorials (right now I recall the John Maloney tutorial 'An Introduction To Morphic: The Squeak User Interface Framework'). And that's probably the reason why many newbies (me included) have started using those methods.
By the way, why are those methods dangerous? Because they interfer with the #on:send:to: morphic event handling? Always calling super at the begining of #mouseDown:, #mouseUp, #mouseEnter, ..., would help?
Thanks
Regards Hernán
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de tblanchard@mac.com Enviado el: Jueves, 01 de Mayo de 2003 01:05 a.m. Para: The general-purpose Squeak developers list Asunto: Re: [Q] doubleclickable and dragable morph: how?
Yeah, I'd vote that these be moved into a category called 'private-events-processing' or something like it to make the point. Comments in the methods with big warnings would be good too.
Those seem to be the first methods new users (including this one) go after to hook an event.
On Wednesday, April 30, 2003, at 08:17 PM, Andreas Raab wrote:
Try:
myMorph on: #startDrag send: #onDrag to: myMorph. myMorph on: #doubleClick send: #onDoubleClick to: myMorph.
Note that #handlesMouseDown: should be never ever overridden unless you know EXACTLY what you are doing. You're starting to infere with
some deep
down notions of Morphic and likely to break more than you (think
you) fix.
Cheers,
- Andreas
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Rudi Angela Sent: Wednesday, April 30, 2003 8:05 PM To: squeak-dev@lists.squeakfoundation.org Subject: [Q] doubleclickable and dragable morph: how?
I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
Rudi Angela
Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
Hi Andreas,
I can only second what Hernan already said, use of #handlesMouseDown is described in at least some of the tutorials.
Now, if I use your scheme how do I later catch these events? Do I still add #MouseDown ?
Andreas Raab wrote:
Try:
myMorph on: #startDrag send: #onDrag to: myMorph. myMorph on: #doubleClick send: #onDoubleClick to: myMorph.
Note that #handlesMouseDown: should be never ever overridden unless you know EXACTLY what you are doing. You're starting to infere with some deep down notions of Morphic and likely to break more than you (think you) fix.
Cheers,
- Andreas
Kind regards,
Ingo
Hi,
I can only second what Hernan already said, use of #handlesMouseDown is described in at least some of the tutorials.
Err ... sorry, I meant #handleMouseDown: not handle[s]MouseDown: (what a fine difference that is ;-)
Now, if I use your scheme how do I later catch these events?
What do you mean by "catching" these events? When you use #on:send:to: you provide a selector which is called in response to the event.
Do I still add #MouseDown ?
I don't understand what you mean by this.
Cheers, - Andreas
While we are on the subject - there's something not quite kosher about either the double click handling or ColorPickerMorph's event handling. I'm trying to make a morph that, when double clicked, lets me pick a new color for it.
subclass Morph (call it Swatch).
add these methods:
mouseDown: anEvent anEvent hand waitForClicksOrDrag: self event: anEvent.
handlesMouseDown: e ^true
doubleClick: anEvent self changeColor
Try double clicking on it - the color picker often never appears, or when it does it opens and closes immediately. I think its pulling a mouse event it shouldn't get but I'm not having any luck tracking it down.
On Thursday, May 1, 2003, at 01:41 PM, Ingo Hohmann wrote:
Hi Andreas,
I can only second what Hernan already said, use of #handlesMouseDown is described in at least some of the tutorials.
Now, if I use your scheme how do I later catch these events? Do I still add #MouseDown ?
Andreas Raab wrote:
Try: myMorph on: #startDrag send: #onDrag to: myMorph. myMorph on: #doubleClick send: #onDoubleClick to: myMorph. Note that #handlesMouseDown: should be never ever overridden unless you know EXACTLY what you are doing. You're starting to infere with some deep down notions of Morphic and likely to break more than you (think you) fix. Cheers,
- Andreas
Kind regards,
Ingo
On Thursday 01 May 2003 07:18 pm, tblanchard@mac.com wrote:
While we are on the subject - there's something not quite kosher about either the double click handling or ColorPickerMorph's event handling. I'm trying to make a morph that, when double clicked, lets me pick a new color for it.
subclass Morph (call it Swatch).
add these methods:
mouseDown: anEvent anEvent hand waitForClicksOrDrag: self event: anEvent.
handlesMouseDown: e ^true
doubleClick: anEvent self changeColor
Try double clicking on it - the color picker often never appears, or when it does it opens and closes immediately. I think its pulling a mouse event it shouldn't get but I'm not having any luck tracking it down.
Try
doubleClick: anEvent self color: self color darker
and you'll see that the behavior you're describing is more a result of the Color Picker.
True - but its not quite so simple. There's a more complicated interaction between the ColorPickerMorph and the double click tracking. For instance, if I put changeColor in click: rather than doubleClick:, then it works OK - except that I want it to happen on a double click because I'm using click for something else.
On Thursday, May 1, 2003, at 10:26 PM, Ned Konz wrote:
On Thursday 01 May 2003 07:18 pm, tblanchard@mac.com wrote:
While we are on the subject - there's something not quite kosher about either the double click handling or ColorPickerMorph's event handling. I'm trying to make a morph that, when double clicked, lets me pick a new color for it.
subclass Morph (call it Swatch).
add these methods:
mouseDown: anEvent anEvent hand waitForClicksOrDrag: self event: anEvent.
handlesMouseDown: e ^true
doubleClick: anEvent self changeColor
Try double clicking on it - the color picker often never appears, or when it does it opens and closes immediately. I think its pulling a mouse event it shouldn't get but I'm not having any luck tracking it down.
Try
doubleClick: anEvent self color: self color darker
and you'll see that the behavior you're describing is more a result of the Color Picker.
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
On Thursday 01 May 2003 07:18 pm, tblanchard@mac.com wrote:
Try double clicking on it - the color picker often never appears, or when it does it opens and closes immediately. I think its pulling a mouse event it shouldn't get but I'm not having any luck tracking it down.
The problem is this:
Your #doubleClick is called on the second mouseDown transition. You then open the ColorPicker morph, which sets mouse focus to itself. Then the mouse goes up, dismissing the ColorPicker.
On Thursday 01 May 2003 07:18 pm, tblanchard@mac.com wrote:
Try double clicking on it - the color picker often never appears, or when it does it opens and closes immediately. I think its pulling a mouse event it shouldn't get but I'm not having any luck tracking it down.
Upon some reflection, this ugly hack should work. Anyone got any better ideas?
doubleClick: anEvent "mouse is still down when this is called."
[ anEvent hand lastEvent redButtonPressed ] whileTrue: [ World doOneCycleNow ]. "wait till button released" self changeColor
Ned,
You ROCK!
Only I put the wait code in the MouseClickState handleEvent:from: method (because I'd guess its a universal problem).
.... localEvt isMouseDown ifTrue:["double click" aHand resetClickState. [ aHand lastEvent redButtonPressed ] whileTrue: [ World doOneCycleNow ]. "Ned's wonderhack - wait until button is up" self doubleClick. ^false]].
On Thursday, May 1, 2003, at 11:32 PM, Ned Konz wrote:
[ anEvent hand lastEvent redButtonPressed ] whileTrue: [ World doOneCycleNow ]. "wait till button released"
On Thursday 01 May 2003 10:56 pm, tblanchard@mac.com wrote:
Ned,
You ROCK!
Only I put the wait code in the MouseClickState handleEvent:from: method (because I'd guess its a universal problem).
I don't think I'd do that.
Actually, if you were going to change the meaning globally, you could just respond to the second mouse-up instead of the second mouse down to make a double click.
I just don't know how people expect to experience double-clicking. It's the difference between (use fixed font):
up -- --------- ------ \ / \ / down ---- --------
event ^click ^doubleClick
and:
up -- --------- ------ \ / \ / down ---- --------
event ^click ^doubleClick
Well, I believe the second one is correct - its not a 'click' until the mouse is up.
This was drummed into us Mac users' heads in hypercard (new buttons provided mouseUp handlers for actions by default) and it was baked into the system buttons on the Mac.
So I feel fairly certain about this (and look at the trouble it causes when trying to pop open a modal widget with that pending mouseUp lurking out there ready to be delivered to the wrong thing.
Looking at the code again, I think I should add one more state #secondClickDown and then process doubleClick on the mouseUp event delivery. But the hack definitely produces nicer behavior now with no noticeable problems. IOW, doing "self ChangeColor" works the same whether its implemented in #click: or #doubleClick:
So I'm confident about this one.
On Friday, May 2, 2003, at 10:01 AM, Ned Konz wrote:
On Thursday 01 May 2003 10:56 pm, tblanchard@mac.com wrote:
Ned,
You ROCK!
Only I put the wait code in the MouseClickState handleEvent:from: method (because I'd guess its a universal problem).
I don't think I'd do that.
Actually, if you were going to change the meaning globally, you could just respond to the second mouse-up instead of the second mouse down to make a double click.
I just don't know how people expect to experience double-clicking. It's the difference between (use fixed font):
up -- --------- ------ \ / \ / down ---- --------
event ^click ^doubleClick
and:
up -- --------- ------ \ / \ / down ---- --------
event ^click ^doubleClick
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
Ned Konz ned@bike-nomad.com wrote:
doubleClick: anEvent "mouse is still down when this is called."
[ anEvent hand lastEvent redButtonPressed ] whileTrue: [ World doOneCycleNow ]. "wait till button released" self changeColor
I wish people would find better solutions than calling doOneCycle. It doesn't seem like a nice thing to do when Morphic is already in the middle of one cycle. However, if it has to be done, it would be better to call doOneCycle instead of doOneCycleNow.
I'm sending a changeset in the next email message that tweaks the comments to say both of these things.
-Lex
On Tuesday 06 May 2003 06:52 am, Lex Spoon wrote:
Ned Konz ned@bike-nomad.com wrote:
doubleClick: anEvent "mouse is still down when this is called."
[ anEvent hand lastEvent redButtonPressed ] whileTrue: [ World doOneCycleNow ]. "wait till button released" self changeColor
I wish people would find better solutions than calling doOneCycle. It doesn't seem like a nice thing to do when Morphic is already in the middle of one cycle. However, if it has to be done, it would be better to call doOneCycle instead of doOneCycleNow.
You're right. This particular problem can be fixed by just changing the state logic in the double click handling.
More generally, we see these kinds of hacks where people want modal dialogs. There's usually a way around modal dialogs, though it's usually more roundabout.
Can you suggest a more general way to let people who are writing cross-UI (MVC and Morphic) apps get the data they need without major restructurings?
Typical of these is: * push a "save" button * executes "save" code, but * now we need to get a filename * and if there's something wrong we want to tell the user
On Wednesday 30 April 2003 11:05 am, Rudi Angela wrote:
I have a Morph subclass, which is dragable by default. Now I would also like to make it doubleclickable. But if I start adding the methods #handlesMouseDown, etc, then apparently I loose the dragability. Am I doing something wrong? Or does Morphic not support this combination of behaviors?
OK, after thinking about this, hearing the (very correct) warnings from Andreas and Lex, fixing the doubleClick logic in MouseClickState, etc., here's my recommendation for a double-clickable Morph that is also draggable. Much simpler and safer than overriding mouseDown: etc.
MyMorph>>initialize super initialize. self on: #doubleClick send: #changeColor to: self. self on: #startDrag send: #grabMe to: self
MyMorph>>grabMe ActiveHand grabMorph: self
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Hernan Tylim -
Ingo Hohmann -
Lex Spoon -
Ned Konz -
Olmeca＠netscape.net -
tblanchard＠mac.com