No announcement yet.

Monitor Acceleration KeyPress

  • Filter
  • Time
  • Show
Clear All
new posts

    Monitor Acceleration KeyPress

    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.

          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.

    Originally posted by Gary Beene
    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.

    ​​Click image for larger version

Name:	image.png
Views:	79
Size:	265.2 KB
ID:	826450
    <b>George W. Bleck</b>
    <img src=''>


      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.


        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?


          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?
          In some future era, dark matter and dark energy will only be found in Astronomy's Dark Ages.


            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.
            So here we are, this is the end.
            But all that dies, is born again.
            - From The Ashes (In This Moment)


              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".


                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.
                Michael Mattias
                Tal Systems (retired)
                Port Washington WI USA
                [email protected]