Julien Galand wrote:
> // BUG (of binding ?) : Use KeyEvent.KeyChar, and not KeyEvent.KeyCode
> !!
> //
> // Note:
> // The same bug appears when retrieving a KeyEvent, such as
> // XAcceleratorConfiguration.getKeyEventsByCommand(".uno:AddDirect").
> // => the returned KeyEvents have KeyChar filled by what should be in
> KeyCode.
I think it didn't work because you already have added something before
you used that call. And the remove/setKeyEvent calls have a bug or at
least a special behavior (see below).
> //
> keyEvent.KeyChar = awt::Key::F11;
> keyEvent.Modifiers = awt::KeyModifier::MOD1; // Ctrl+F11
>
> OUString commandURL = OUString::createFromAscii(".uno:AddDirect"); //
> this command is just as a test
>
> try {
> shortcutMgr->removeKeyEvent(keyEvent);
> }
> catch (NoSuchElementException &) {}
>
> shortcutMgr->setKeyEvent(keyEvent, commandURL);
> shortcutMgr->store();
There is a bug(or an unspecified feature?) in the accelerator
configuration: searching for a configuration by Event ignores KeyChar
and KeyFunc, it only uses KeyCode. This can lead to the strangest
effects. Especially your code will force the Accelerator Configuration
to grab the first binding that has "MOD1" set and no KeyCode assigned,
whatever that means.
I recommend to do the following:
Make sure that you have the default configuration and use
"getKeyEventsByCommand" to see what you get. It should yield the same
result as in Basic.
If setKeyEvent still doesn't work with a correctly assigned KeyCode we
must debug it. This could be accelerated if you could deliver your C++
code as an installable and executable extension.
Best regards,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
