Getting morph events when there is no keyboard focus

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting morph events when there is no keyboard focus

timrowledge
I'm trying to get an idea of how to handle keyboard events when there is no keyboard focus; this is for dealing with  general application commands like 'start', 'stop', 'explode', etc.

I *think* it looks like I might need a listener object added to the handmorph but I don't see how to check if the focus is nil as part of that path. An alternative appears to be something to do with the owner of the hand… maybe?
I've spent too long wandering a twisty maze of messages and as a result, got eaten by a Grue. Explanations of how this all works would be appreciated, whether actual or pointers to already written doc. For example, why do all the implementors of #handleFocusEvent: except Morph use both #processEvent: and handleEvent: when it looks like #processEvent also sends #handleEvent: ? I hope there are intelligible explanations out there...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ETO: Emulate Toaster Oven



Reply | Threaded
Open this post in threaded view
|

Re: Getting morph events when there is no keyboard focus

Bob Arning-2
'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 23 July 2013 at 7:17:36 pm'!
Morph subclass: #TimsAppMorph
    instanceVariableNames: ''
    classVariableNames: ''
    poolDictionaries: ''
    category: 'Morphic-Kernel'!
!TimsAppMorph commentStamp: 'raa 7/23/2013 19:08' prior: 0!
TimsAppMorph new openInWorld!


!TimsAppMorph methodsFor: 'as yet unclassified' stamp: 'raa 7/23/2013 19:16'!
handleListenEvent: anEvent
   
    anEvent hand keyboardFocus ifNotNil: [^self].
    anEvent isKeyboard ifFalse: [^self].
   
    "insert your code here to handle key up/down/stroke as you wish"
   
    Transcript show: 'I could handle: ', anEvent  asString; cr
    ! !

!TimsAppMorph methodsFor: 'as yet unclassified' stamp: 'raa 7/23/2013 19:08'!
initialize

    super initialize.
    self extent: 60@60.
    self color: Color paleBlue.
    ActiveHand addKeyboardListener: self.! !


On 7/23/13 6:41 PM, tim Rowledge wrote:
I'm trying to get an idea of how to handle keyboard events when there is no keyboard focus; this is for dealing with  general application commands like 'start', 'stop', 'explode', etc.

I *think* it looks like I might need a listener object added to the handmorph but I don't see how to check if the focus is nil as part of that path. An alternative appears to be something to do with the owner of the hand… maybe?
I've spent too long wandering a twisty maze of messages and as a result, got eaten by a Grue. Explanations of how this all works would be appreciated, whether actual or pointers to already written doc. For example, why do all the implementors of #handleFocusEvent: except Morph use both #processEvent: and handleEvent: when it looks like #processEvent also sends #handleEvent: ? I hope there are intelligible explanations out there...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: ETO: Emulate Toaster Oven







Reply | Threaded
Open this post in threaded view
|

Re: Getting morph events when there is no keyboard focus

timrowledge
Thanks Bob,
would I be right in thinking that this mechanism is purely a broadcaster, rather than a "did anyone handle this? if not, I will" approach?

ie if my app is watching for <CR> it can handle it but anyone else watching for <CR> will also get to handle it? Any way to stop that? Well, aside from making sure any other listeners are exterminated...



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
29A, the hexadecimal of the Beast.



Reply | Threaded
Open this post in threaded view
|

Re: Getting morph events when there is no keyboard focus

Bob Arning-2
right. all listeners can do whatever they want.

On 7/23/13 7:28 PM, tim Rowledge wrote:
Thanks Bob,
would I be right in thinking that this mechanism is purely a broadcaster, rather than a "did anyone handle this? if not, I will" approach?

ie if my app is watching for <CR> it can handle it but anyone else watching for <CR> will also get to handle it? Any way to stop that? Well, aside from making sure any other listeners are exterminated...



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
29A, the hexadecimal of the Beast.