EA steals my Ctrl + key keypresses

[Geert Bellekens]

Hi,

I'm writing an add-in that inlcludes a control with a RichtTextBox in it to edit text.
To enable simple editing of the text I included code to use Ctrl-B for bold, Ctrl-I for italic and Ctrl-U for underline.
When I run this control in my own window then that works fine, but when I run it as the Add-In window in EA then it doesn't work.
For some reason EA seams to steal my Ctrl+key keypress, the only thing I get it the Ctrl keypress, not the Ctrl+B
Anyone know how to fix this? Here's my code:

Code: [Select]

/// <summary>
        /// fired when a key is pressed on one of the textboxes.
        /// Handles:
        /// - Ctrl-B -> Bold
        /// - Ctrl-U -> Underline
        /// - Ctrl-I -> Italic
        /// </summary>
        /// <param name="sender">the textbox firing the event</param>
        /// <param name="e">the arguments</param>
        private void textBox_KeyDown(object sender, KeyEventArgs  e)
        {
            //debug
            ACVModellingTools.Util.Logger.log("textBox_KeyDown info: Control = " + e.Control.ToString() + " keyCode =" + e.KeyCode.ToString() );

            RichTextBox textBox = sender as RichTextBox;
            // Bold = Ctrl-B
            if (e.Control && e.KeyCode == Keys.B)
            {
                this.toggleBold(textBox);
                e.SuppressKeyPress = true;
            }
            //Italic = Ctrl-I
            else if (e.Control && e.KeyCode == Keys.I)
            {
                this.toggleItalic(textBox);
                e.SuppressKeyPress = true;
            }
            //Underline = Ctrl-U
            else if (e.Control && e.KeyCode == Keys.U)
            {
                this.toggleUnderline(textBox);
                e.SuppressKeyPress = true;
            }
        }
Geert

[abruckner]

not sure about this, would have to try it myself, but am in a debug-session.
but: do you have your form's property 'KeyPreview' set to true?

[Frank Horn]

There's usually no form in an AddIn project whose KeyPreview property can be set to true, but this seems to point into the right direction.

The windows message queue of the RichTextBox control's parent control (or the parent control's parent control a.s.o) seems to handle the desired key events without passing them on to its child controls.

The only solution I can think of is an ugly one: Use Win API to recurse through the parent window handles up to the one beneath the desktop, which must then be the EA main window. You can then subclass it's message queue to get hold of the key events.

[Geert Bellekens]

I reported this as a bug and received following answer

Hello Geert,

We can confirm that EA currently provides default handling for a number
of different key combinations.  Unfortunately our developers indicate
this behavior is not likely to change in the immediate future.

We have logged a feature request on your behalf for better access to
keypress events from add-in window controls, but cannot say at this time
if/when such changes may be implemented.

Thank you for your feedback.  Sorry we could not be of more assistance.

Best regards,

Geert

[abruckner]

in a project we used a keyhook to intercept the keys before EA is able to.

problematic: antivirus-apps often recognize the addin as a trojan/virus.