View Full Version : reqkeyboard and how it doesnt work as documented

05-28-2010, 11:02 PM
Documentation states very clearly:
"It should return a Boolean false or true value indicating that the key should or should not be further processed by the system, respectively."

I return false. LW doesn't give a s-h-i-t! The key is not further processed by LW. Ie the key is not sent to the parent window, LWs main window, to trigger keyboard shortcuts, as it should and is documented.

Has anyone gotten this to work or is the documentation just pure b-u-l-l-c-r-a-p and this was never ever implemented and I just wasted over a weeks worth of work!? (I've lost count how many times this has happened now. Why do I keep trying?)

It doesn't even appear to work in LW7.5 when this feature was introduced either.

@version 2.6
@script master

create {
destroy {
flags {
process: event, eventData {

options {
if( reqisopen() ) //non-modal panel
reqbegin("keyboard input");
reqkeyboard: key {
return false; //this should send the key to LWs main window according to docs. IT DOESNT!

06-19-2010, 03:08 AM
How can you tell that it's not being processed? The funny thing about reqkeyboard (afaik) is that it doesn't process if the focus is on a field (i.e. ctlnumber, ctlstring, etc). If the focus is on the panel itself, then how do you determine the key going through? I'm thinking that without focus the key just goes off 'into space.'

Of course, this is a long way of saying that the return value is not much practical use. Have I missed anything?

06-19-2010, 08:58 AM
Hmmm... of course, one could argue about what the term "further processed by the system" means. I take it too mean "further processed by the parent window", as is customary in windows system.

So I'm expecting LW standard hotkeys to be triggered when my panel is in focus but doesn't process the key events itself. Ie no edit field is in focus and any keyboard callback returns false.

This is indeed also how SDK panels work, by default, no extra code is needed. Key events are forwarded to the main window. If you don't want that to happen you can add a keyboard callback to trap the keys. I'm ok with Lscripts default being different, it is a more controlled environment, but it seems we don't even have an option to change the default and forward the key events.

With non-modal panels especially, it's important that we can forward the key events as some of these panels are meant to stay open to extend and integrate with the native interface. Take your own PortableTimeline script for example (if it defined it's own hotkeys then maybe it's a bad example). It will be a nuisance to use and far from integrated, as the user will constantly have to make sure that LWs main window is in focus when trying to use native hotkeys.

Or have I missed something? Does it make a difference whether the keyboard callback returns true or false? I noticed no difference.

06-19-2010, 03:45 PM
Ah, so it works in using the SDK, but not in LScript; I suppose that is the way it should work. I've just now tried returning true, false, and the key value itself, and nothing seems to get piped into the main window. I've resigned myself to this behavior; yes, PortableTimeline (even Janus, actually) would benefit from this, and I have used PortableTimeline with those limitations. It is quite annoying, though I've gotten used to it.

Fogbugz anyone? :)

06-19-2010, 03:53 PM
Hmm... In the docs a generic was used. And I noticed that a reqabort() was placed before the return. I tried doing this on non-modal (MC) script. If I reqabort()'d, and then returned true, then nothing happened, as expected. But if I returned false, LW crashes. Clearly there is something different about these two. However, it doesn't seem to be usable. I'm thinking that the key is definitely not piped in to the main window, and that the key buffer is held; that is why the window must be closed for the focus to go back into Layout, and then there is the attempt to release the key buffer from there.

Unfortunately, for non-modal scripts, at least, that doesn't seem to work very well either way.

06-19-2010, 04:09 PM
From the many bugs (including the above) and requests I've submitted I think my pile would be visible through the fog by now.

Interesting that you saw some differences. And I never got any crashes. But that's good. More convincing arguments to avoid the ever dreaded "by design"-defense.

PS. I regret the formulation of the first posted somewhat. But I was kinda upset.