Me too, I'd like to play around and maybe do something useful (or
funny :) with it. It could at least be put on the CCR if not into
lazarus distribution itself.
That may be a good start. I'll submit it to the CCR as soon as I finish 1.0
Please note I combined two posts below:
How about a middle ground: create a new TKeyboardEvents unit using
code from one of the components that already has it. Yes you will have
the initial code duplication in creating the unit in the first place,
but this would allow adding keyboard events to other controls simply
by inheriting from the base class. In fact, this may be something that
the LCL could use and incorporate itself in the future, if you get it
working property.
I'm not sure about this one - as it would mean anything that needs
keyboardevents cannot be descended from anything else (e.g. a
customControl or it's descendents like tpicture).
However it might be possible to create a small component
TKeyboardListener or something that DOES have these events, can take
focus but isn't actually VISIBLE(is this last bit possible ? Perhaps if
you hardcode it's width and height properties to be locked to 0) . Then
anybody who needs to capture keyEvents globally would be able to drop
one on a form and use it, and components like TDoubleBuffer could just
instantiate one (or hook into one through a property - perhaps better).
This would actually I think be an incredibly useful GENERAL add-on to
the LCL as it would create a platform independent way of doing what
windows coders do with callbacks and hooks. Somebody with deeper LCL
knowledge want to comment on this ?
I haven't looked into the sources deeply, but can't you override some
OnKeyXxx-methods to get the key events?
I don't think there ARE any to overwrite- perhaps in the parent class
for TCustomControl, but they aren't republished. If you use override
though - you may as well rewrite them as you'll need to do the same work
anyway - it doesn't solve the clutter-and-duplicate problem.
If not, maybe hooking into the surrounding forms events would suffice.
This was my first idea, but unfortunately, it doesn't work at all. The
reason is that forms only get keyboard focus onActivate and even then
they only keep it if there is no focusable components - else it's
hardpassed to the component with focus preference. Running
Form.SetFocus throws an exception (Form cannot take focus) - [why is it
there if it cannot be called ?]
If there is a way to make a form take keyboard focus to itself so it's
keyEvents work even if there are focusable components on it then I
haven't found it yet.
Ciao
A.J.
--
"Any sufficiently advanced technology is indistinguishable from magic" -
Clarke's law
"Any technology that is distinguishable from magic is insufficiently
advanced" -Gehm's corollary
"Any technologist that is distinguishable from a magician is
insufficiently advanced" - My corollary
The worlds worst webcomic: http://silentcoder.co.za/scartoonz
The worlds best cybercafe manager: http://outkafe.outkastsolutions.co.za
begin:vcard
fn:AJ Venter
n:Venter;AJ
org:Global Pact Trading Pty. Ltd.;OutKast Solutions
email;internet:[EMAIL PROTECTED]
title:Director of Product Development
tel;work:+27 21 554 5059
tel;fax:+27 11 252 9197
tel;cell:+27 83 455 9978
url:http://www.outkastsolutions.co.za
version:2.1
end:vcard
