windowssaleslogix

Tab key does not work in windows control added (.Net extension) in saleslogix windows


I have added a .Net windows form inside a saleslogix windows plugin, every thing is working fine but on pressing the "Tab" key inside this control, instead of going on the next textbox the control goes to next plugin.

I have searched it a lot and can not find a work around for this, when I added a browser control in another saleslogix windows plugin, the page inside this textbox has multiple text boxes in it. To my surprise on pressing the tab key it worked perfectly and control goes to the next text box.

Any help is much appreciated.


Solution

  • That's an entirely normal mishap when you use Winforms (and many other UI class libraries) in a host application. Navigation keys, like Tab and the cursor keys as well as shortcut keystroke keys, need to be recognized regardless which control has the focus. One way to do so would be to implement the KeyDown event handler on every single control. That's excessively painful of course.

    So it doesn't work that way, the keystroke is recognized when it is received by the message loop, before it is dispatched to the control with the focus. Overriding the ProcessCmdKey() method is the general way to do this. The base method takes care of navigation and recognizing menu and button mnemonics.

    Problem is, it isn't the .NET message loop that is receiving and dispatching messages. It is the host application that has the loop. And it doesn't know beans about ProcessCmdKey(). So it doesn't get called and navigation doesn't work.

    It tends to work in a WebBrowser because it is an ActiveX control. Which is designed to interact with its host. In particular it negotiates to decide which one gets to process the key. The IOleInPlaceActiveObject::TranslateAccelerator() method does this. Not the kind of plumbing available in .NET and host apps are rarely written to provide an alternative.

    You could consider the "excessively painful" solution but pretty unlikely you like the sound of it. There's only one other decent way to fix this, you must call ShowDialog() to display your form. Now it is the .NET loop that dispatches and the Tab and cursor keys work fine. That tends to be unwelcome advice, dialogs can be pretty awkward. If you are lucky and know what you're doing and the host can deal with it (usually not) then using a thread can take the sting out of the modality. Asking the vendor for advice, particularly the threading aspect, would be wise.