Trapping Keyboard Key presses for Hot Keys.. Sanity check

[Curt Krueger 1]

 

Hello!

 

Currently on Delphi 10.3 (latest Rio) Pro. 

 

I'm going through an app that's been in production for a long time and I'm finally adding a lot more keyboard short cuts, and finding it's not that fun, and want to make sure that I'm not missing something, even though I kind of made it hard on myself (hard on myself for hot keys).

 

The application has various modules, in the module it has a form that has tabs, each tab instead of embedding a "frame" into the tab or dropping controls directly on the tab and having a nightmare managing tabs, and having no re-usability, I've created a form that embeds into each tab (instead of a frame).  It works well, because I can reuse the forms in other modules, I get all the benefits a form offers with its rich set of events, and if I fix a UI bug, I fix it everywhere that part of the module is used.    For example, I have a Company module, and I'll use one of the Company forms within the Job Order Module.  If I enhance the company form for what ever reason, the Job Order Module gets that benefit and consistency. 

 

I started this app when either Actions were new or non-existent (Delphi 5), if I remember correctly, so I don't have actions wired up, and even if I did, multiple modules can be opened at once, so I'm not sure how multiple forms (only one active at a time obviously) would interact with multiple sets of Actions (maybe this is what I need?).   In any case, now it's time to add some hot keys for Cancel and Save for example (the customer is currently used to tabbing to it, or clicking), and due to the "layered" forms I have, even though I'm setting focus to the top form and have an active control on that form, it seems I have to click on the form before the hotkey will work (defeats the purpose, having to click), and even then it seems intermittent (I want the hot keys to work 100% of the time).   

 

Here is the kicker;   I'm getting rid of as many modal forms/dialogs as possible.  A customer request is they'll be inputting data, get a call (call answering required, can't finish what they were doing before answering/taking call), and can't switch to another module to handle the call, then come back to where they were inputting data unless they save and then return.  This means they have to remember the customer or job order or whatever that they partially entered.  Also forms have input rules and if they haven't met them, they can't close for that reason, so they would be forced to lose what the did enter.   With no dialogs, they can simply keep that module open, and switch via the in application task bar to a new or another module of the same type.   So ultimately, when they switch form module to module, the active modules, active form should accept the Hotkeys it accepts.  So far, I've keyed off of the OnKeyDown event, and its intermittent as to when the app/form decides to handle the key presses. 

 

I don't expect anyone to solve my particular issue, I guess I'm looking for any gotcha's you've encountered and their work arounds if any, and what you do to setup keyboard shortcuts for your apps.    I'm guessing my methodology with forms embedded in tabs is unique and probably "wrong".

 

Thanks,

Curt

 

 

[Anders Melander 1782]

I'm not sure if I understand your UI architecture fully, but here's what I would do:

• Use actions - always.
  One actionlist per form/frame.
• Replace forms with frames if possible.
  If you're embedding the forms then you should use frames.
  The form events are convenient but they are meant for more or less autonomous forms. Forms can be embedded but they are not designed to be so. Unlike frames.
• Move the activation/deactivation logic from the form to the container.
  Have the container notify the frame when it's activated and deactivated.
• Disable the frame actionlist when the frame is deactivated. Enable it when it's activated.
  Might not be necessary though as the actionlist is smart about not handling actions for controls that aren't visible.

[Curt Krueger 1]

5 hours ago, Anders Melander said:

I'm not sure if I understand your UI architecture fully, but here's what I would do:

• Use actions - always.
  One actionlist per form/frame.
• Replace forms with frames if possible.
  If you're embedding the forms then you should use frames.
  The form events are convenient but they are meant for more or less autonomous forms. Forms can be embedded but they are not designed to be so. Unlike frames.
• Move the activation/deactivation logic from the form to the container.
  Have the container notify the frame when it's activated and deactivated.
• Disable the frame actionlist when the frame is deactivated. Enable it when it's activated.
  Might not be necessary though as the actionlist is smart about not handling actions for controls that aren't visible.

 

Thanks for the input.  Basically confirms what I've been thinking. 

 

Curt