Monitor Acceleration KeyPress

[Gary Beene]

For each button on a toolbar I have created an accelerator key. The user can take an action by pressing the toolbar button or by pressing the accelerator keys. I want to control which action is taken depending on whether accelerator keys were pressed or whether the user pressed the toolbar button.

Instead of putting code under each Case to test for the message source. I'd rather put the test code in one place, to take action if an accelerator key was pressed and then, regardless of whether an accelerator key was pressed, I want the app to also take the response that would come from pressing the toolbar button.

This seems to provide that result (uses acceleration key detection code mentioned in an earlier thread) and requires only 1 line of code under %WM_Command, not a line of code for each Case.

   %WM_Command
      If Hi(Word,Cb.WParam) = 1 Then TakeMonitorAction   'if message came from Accel key, then take action. then take action on the button press
      Select Case Cb.Ctl
         Case %IDT_A   : TaskA
         Case %IDT_B   : TaskB
         Case %IDT_C   : TaskC
      End Select
​​

This action is to support a change to an existing app, where the app have the better part of 1000 toolbar buttons and the approach above cuts down on how many lines of code I have to add to the existing app.

[George Bleck]

1000 toolbar buttons

Does each control a Nuke or something??? Sheesh Gary that a LOT of buttons.

Either that or you are a raver into EDM.

[Gary Beene]

Howdy, George!

Yes, it really is a lot. The buttons are spread out over about 100 dialogs, with each dialog having a toolbar that has about 10 buttons.

The app used to be small - 1 dialog and 1 toolbar. It's grown quite a bit since then.

[Stuart McLachlan]

ISTM that having different actions between clicking and using the accelerator key for the same control is a strange design decision which is contrary to the whole WIndows paradigm and is likely to confuse users

What is the purpose of doing this?

[Rodney Hicks]

So, by using the accelerator key a user can activate or start a dialog, I'm assuming here. Does it also perform the task the toolbar button is meant to do or does it just give it focus or just the dialog get the focus(brought to top)? Are there any toolbar buttons duplicated on other dialogs? Do you have a robust tooltip plan in place?

[Steven Pringels 3]

If the actions don't require any parameters to be fed into the sub that is being called, why not create a hash table consisting of the keyvalue of the accelarator key as the key and the value being the codeptr of the sub being called? Then just look it up? You would have to create the hash table at the %WM_CREATE message or in the DIALOG NEW function/sub. Then store the pointer of the hash table using DIALOG SET USER ...

You could use the DwDwHash functions provided by Stanley Durham from his HLib3 library to accomplish all that or use a PowerObject (iCollection I believe) to achieve something similar but you would have to store the ObjPtr then and mess around with AddRef() etc. I prefer the hash functions.

[Gary Beene]

Howdy, John!

What is the purpose of doing this?

Before action is taken when a toolbar button is pressed, I want to have the app optionally speak any pressed accelerator keys. Having the code placed as I show above makes that easy to do. I can do it by placing code under the Case, but having the code in a single location is a simpler approach. Handling as we are describing is transparent to the user. In the case of my low vision users, it is very common that they press keys and get a response other than what they expected. Answering the question "What did I just press?" helps them recover from a typing mistake.


Howdy, Steven!

In many cases, no Sub is called. There may simply be a few lines of code under the Case.


Howdy, Rodney!

Yep, I have a function that returns a tooltip based on the toolbar handle and button ID. Most dialogs have common toolbar buttons, such as "Exit".

[Michael Mattias]

The app used to be small - 1 dialog and 1 toolbar. It's grown quite a bit since then.

Apps do that.

Designers should know that.