onKeyPressed: and a bell

I have a presenter where in onKeyPressed: I check for certain keys.  It
seems that for non-virtual keys a bell sounds -I can't see where this is
coming from or how to suppress it.  Here's a snippet of code:

onKeyPressed: aKeyEvent
    aKeyEvent code = VK_PRIOR ifTrue: [^self doSomething].
    aKeyEvent code = $O asInteger ifTrue: [^self doSomethingElse].

In both cases, the correct action (doSomething or doSomethingElse) takes
place.  However, if I press the PageDown key there is no sound, but if I
press the 'o' key the bell rings.  I'd appreciate any ideas on how to fix
this, i.e., suppress the bell.

-- Louis

Louis Sumberg wrote:
Hi Louis,

My first guess would be that the bell is coming from CommandPolicy>>route:
and I would check to see if and what (and then why) a command is failing.

Second guess is that you may need to stop defaultWindowsProcessing of the
keyEvent. For example, if the view is a ListView, "O" will try to select an
item starting with "O". To do this, your presenter needs to answer false in
#onKeyPressed:

This wont work if your #onKeyPressed: method is handling a #keyPressed event
from another presenter. You need to answer false from the view's presenter
#onKeyPressed: method.

Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

Louis,

> In both cases, the correct action (doSomething or doSomethingElse)
> takes place.  However, if I press the PageDown key there is no sound,
> but if I press the 'o' key the bell rings.  I'd appreciate any ideas
> on how to fix this, i.e., suppress the bell.

FWIW, I tried this on my XP machine by creating a Shell subclass and adding
the three methods. I get to the correct method when I press o but I don't
hear any bells at all?

BTW VK_PRIOR appears to be the symbol for the PageUp key and not PageDown -
was that a typo in your message?

--
Ian

Hi Steve,

Thanks for both guesses.  Unfortunately, I'm still not able to suppress the
bell.

> My first guess would be that the bell is coming from CommandPolicy>>route:
> and I would check to see if and what (and then why) a command is failing.

Since the commands do work I don't think the problem is here, but I put in a
Notification anyway which showed it wasn't failing.

> Second guess is that you may need to stop defaultWindowsProcessing <snip>

I thought I had tried this, i.e., returning false from the presenter, but
tried it again to no avail.  As a general test, I changed
onKeyPressed/Typed/Released in TreePresenter to just return false, then
brought up a class browser and pressed some keys in the class hierarchy
treeview.  The behavior was the same, e.g., it goes to Object if I press an
O and it sounds a bell if I press an X.  I think this is what you were
getting at, but the result indicates to me to check further up in the chain,
which gives me the #preTranslateSomething shivers.

Btw, I'm actually subclassing SWBorderImageView, which I've gotten to like
for its #scaleBestFit viewmode (and its imagePadding too).  I added rotation
and zooming, and wanted a pluggable presenter with certain keys hardwired
(e.g., L and R for rotate left and right, I and O for zoom in and out).

I guess it's ok for now, or at least until my wife complains about all the
beeping.  Thanks again.

-- Louis

Hi Ian,

> FWIW, I tried this on my XP machine ...I don't hear any bells at all?

Thanks - I'll add that as one more incentive to upgrade.

> BTW VK_PRIOR appears to be the symbol for the PageUp key and not
PageDown -
> was that a typo in your message?

Yeap, it was a typo in my message.  The code tests correctly for both up and
down.

-- Louis

Hi Louis,

Louis Sumberg wrote:

> I thought I had tried this, i.e., returning false from the presenter,
> but tried it again to no avail.

On WinXP, if I file the following code in:

=====
TreePresenter subclass: #SilentTreePresenter
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
classInstanceVariableNames: ''!
!SilentTreePresenter methodsFor!
onKeyPressed: aKeyEvent
"self trigger: #onKeyPressed: with: aKeyEvent"
^false!
onKeyTyped: aKeyEvent
"self trigger: #onKeyTyped: with: aKeyEvent"
^false! !
=====

Then;

   (model := TreeModel new)
      add: #foo asChildOf: nil;
      add: #bar asChildOf: nil.

   presenter1 := TreePresenter showOn: model.
   presenter2 := SilentTreePresenter showOn: model.

The first gives me selection changes and "beeps", the second doesnt. Do you
get the same in Win98?


> wanted a pluggable presenter with
> certain keys hardwired (e.g., L and R for rotate left and right, I
> and O for zoom in and out).

Have you tried Keyboard Accelerators?

Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

Hi Steve,

>    presenter1 := TreePresenter showOn: model.
>    presenter2 := SilentTreePresenter showOn: model.
>
> The first gives me selection changes and "beeps", the second doesnt. Do
you
> get the same in Win98?

I get the same.  The second also swallows up _everything_ which is not what
I want, so for testing I changed #onKeyTyped: to the following so it would
accept keystrokes f and b for foo and bar.  The result: pressing f or b
chooses the correct node and pressing any other key does nothing.  In either
case, there is no bell sound.

onKeyTyped: aKeyEvent
    ((Array with: $f asInteger with: $b asInteger) includes: aKeyEvent code)
            ifFalse: [^false].
    ^super onKeyTyped: aKeyEvent

It turns out that #onKeyPressed: doesn't need to be overridden at all and so
I deleted it.  My guess is that the bell comes from #onKeyTyped: or
thereabouts, because if you refactor/rename the above method to
#onKeyPressed:, i.e.,

onKeyPressed: aKeyEvent
    ((Array with: $f asInteger with: $b asInteger) includes: aKeyEvent code)
            ifFalse: [^false].
    ^super onKeyPressed: aKeyEvent

this works the same as #onKeyTyped: above except there _is_ a bell sound
when you press something other than f or b.

Anyway, I turned back to implementing #onKeyTyped: in an ImagePresenter
subclass and it didn't work.  I reduced it to the following:

onKeyPressed: aKeyEvent
    ^false

onKeyRelease: aKeyEvent
    ^false

onKeyTyped: aKeyEvent
    self halt

You'd think a keystroke would be swallowed up and a breakpoint hit.  Well,
the good ole bell sounded again, and no breakpoint.  I assume keyTyped is a
synthesized event somewhere.  Why the bell sounds I still don't know.  It's
odd to me that onKeyTyped: isn't called at all - if I add the same
onKeyTyped (with self halt) to ScribbleView, the debugger pops up.  So
somewhere in the ImageView hierarachy, something is afoot!

> > wanted a pluggable presenter with certain keys hardwired ...
>
> Have you tried Keyboard Accelerators?

I tried them a bit.  One problem is they don't work in context menus, which
is where I'd want to put them, this being a pluggable presenter, not a
shell.

Thanks again for your time and effort.

-- Louis

"Louis Sumberg" <[hidden email]> wrote in message
news:b3f8h1$1l7996$[hidden email]...
>
> > > wanted a pluggable presenter with certain keys hardwired ...
> >
> > Have you tried Keyboard Accelerators?
>
> I tried them a bit.  One problem is they don't work in context menus,
which
> is where I'd want to put them, this being a pluggable presenter, not a
> shell.

You can define an #additionalAccelerators method in your presenter for this.
The Windows UI guidelines state that one isn't supposed to put accelerator
key bindings on display in context menus, which is one of the reasons the
Dolphin menu framework ignores them when building the accelerator table for
the view (although they will be displayed). If you followed this UI
guidelines, then your user wouldn't necessarily know that the accelerator
existed, at least not from just browsing the menus. However some
applications do put accelerator keys on the context menus, and I don't
understand why that is particularly frowned upon.

Regards

Blair