Recent

Author Topic: Resolving IDE keymapping conflicts programmatically  (Read 2957 times)

Paulo França Lacerda

  • New Member
  • *
  • Posts: 44
    • BlaisePoint Informática
Resolving IDE keymapping conflicts programmatically
« on: August 26, 2016, 09:10:07 am »
I'm working on a design-time package that (among other things) handles F12 (pure F12, no shift keys).
Yes, I know F12 is already taken for toogling between Form/Unit, but I really need this same key.

I'm currently using RegisterIDECommand() and my code works, as long as I remove the previous handler manually on the IDE settings.
I don't want the old handler removed. Being in the same notification list to get called is enough.

QUESTIONS:
  • Isn't there any kind of event chain?
  • How to have my handler called without having to kill the others?
Thanks in advance.
« Last Edit: August 26, 2016, 03:08:26 pm by patulinu »
Lazarus 1.6.0.4 on FreePascal 3.0
Windows 7 32-bit

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4458
  • I like bugs.
Re: Resolving IDE keymapping conflicts programmatically
« Reply #1 on: August 26, 2016, 03:28:21 pm »
I'm currently using RegisterIDECommand() and my code works, as long as I remove the previous handler manually on the IDE settings.
I don't want the old handler removed. Just be in the same notification list and be called is enough.
Do you mean the same shortcut key should trigger many actions? That is not possible currently. I guess it could be supported but it may lead to unpredictable actions.
Remember that an IDECommand and its shortcut key are 2 different things. A command can be triggered by other means, too.

Quote
Isn't there any kind of event chain?
There are event chains in many places in the IDE.

Quote
How to have my handler called without having to kill the others?
You mean how to add a shortcut for your handler (IDECommand) without removing the other identical shortcuts?
Now only one command is triggered by a shortcut. The best you can do is to remove existing ones.
It was not possible using IDEIntf, thus in r52874 I added a new function RemoveShortCut. Please test.
You can use it like:
Code: Pascal  [Select][+][-]
  1. var
  2.   sk: TIDEShortCut;
  3.   i: Integer;
  4. ...
  5.   sk := IDEShortCut(VK_F12,[]);
  6.   i := IDECommandList.RemoveShortCut(sk); // Returned the count of removed shortcuts.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

Paulo França Lacerda

  • New Member
  • *
  • Posts: 44
    • BlaisePoint Informática
Re: Resolving IDE keymapping conflicts programmatically
« Reply #2 on: August 26, 2016, 03:52:52 pm »
Quote from: JuhaManninen
Do you mean the same shortcut key should trigger many actions? That is not possible currently.
Just one action on my code's site (on every keystroke), then I would give the control back to the current hadler. This is the idea.

Quote from: JuhaManninen
Code: Pascal  [Select][+][-]
  1. var
  2.   sk: TIDEShortCut;
  3.   i: Integer;
  4. ...
  5.   sk := IDEShortCut(VK_F12,[]);
  6.   i := IDECommandList.RemoveShortCut(sk); // Returned the count of removed shortcuts.
Well, thank you for the code, but I don't want to remove the current handler, just co-exist with it.

I think I'll have to get my design-time package to hack the SourceNotebook control in order to hijack the event, but saving the current handler and calling it back when my handler is done processing every keystroke.

I'll post the results here soon.
Thank you, for now.
Lazarus 1.6.0.4 on FreePascal 3.0
Windows 7 32-bit

Paulo França Lacerda

  • New Member
  • *
  • Posts: 44
    • BlaisePoint Informática
Re: Resolving IDE keymapping conflicts programmatically
« Reply #3 on: August 26, 2016, 08:53:27 pm »
Ok, I got it!

I have created a design-time package to illustrate how to capture the OnKeyDown event of any open SynEdit tab, in a chain (provided by the TIDESynEditor component), without hacks. Once my event handler is fired, it processes the key as need, then the next handler is fired automatically (by the chain holder: TIDESynEditor), all peacefully. :)

The package keeps track of every editor tab (as desired). Once a editor is created by the IDE, a handler for the target event is registered and a custom object is instantiated (for storing important editor-related data), so that the OnKeyDown handler can use it (eg: filename, editor control, etc). When the editor tab closes, a cleanup is done (the event handler is unregistered and the custom object is freed).

I've used [F12] as example (this key was my goal), but it can capture any key, including shift states (CTRL, SHIFT, ALT, etc).
Also interesting to notice is the number of events one can register (see the sources for the TCustomSynEdit component).

Sample Design-time Package sources:
http://www.filedropper.com/lazkeycapture

Just for the records:
I'm running Lazarus 1.6 on Windows 7 32-bit.
« Last Edit: August 27, 2016, 01:32:30 pm by patulinu »
Lazarus 1.6.0.4 on FreePascal 3.0
Windows 7 32-bit

 

TinyPortal © 2005-2018