General XMetaL Discussion
XMetaL Community Forum › General XMetaL Discussion › XMAX 5.5 Keyboard shortcuts
-
craig_83 April 13, 2010 at 2:08 pm
XMAX 5.5 Keyboard shortcuts
April 13, 2010 at 2:08 pmParticipants 2Replies 3Last Activity 12 years, 11 months agoIs there anyway, through the XMAX API, to disable inbuilt keyboard shortcuts for the XMAX control. We want to handle the activex shortcuts and ceratin keyboard keys ourselves such as paste, copy and the delete key.
Thanks
Derek Read April 13, 2010 at 8:24 pm
Reply to: XMAX 5.5 Keyboard shortcuts
April 13, 2010 at 8:24 pmIdeally the containing application should intercept these keys before they are passed on to XMAX. That is really how things should be coded.
However, you can create a macro for each key you wish XMAX to not do anything for and assign a script that does nothing with the appropriate key assignment. In the resulting MCR file you would then end up with something that looks like this:
//do nothing
]]>craig_83 April 14, 2010 at 7:29 am
Reply to: XMAX 5.5 Keyboard shortcuts
April 14, 2010 at 7:29 amI made a similar post before. I have the XMAX control embedded in a .NET Winforms control, which in turn is embedded in a WPF window. I have tried to capture the keyboard shortcuts at all levels of the application, but the XMAX event, e.g. a paste, still gets fired before my own .NET event.
I cannot seem to capture the event. The only event available is a PreviewKeyDown, but this does not expose the property to handle the event. I would like the option to handle other keystrokes such as the user clicking the delete key. But, again, the XMAX control fires the event before the .NET event is reached. I would like to handle the input into the XMAX control and keystrokes associated with it when it has focus like I could with a .NET control e.g. a textbox.
Thanks.
Derek Read April 14, 2010 at 9:58 pm
Reply to: XMAX 5.5 Keyboard shortcuts
April 14, 2010 at 9:58 pmI've discussed this with our lead developer and here is what he says:
XMAX implements the standard/required ActiveX interfaces and methods.
The standard interface method IOleInPlaceActiveObject::TranslateAccelerator()is called by the ActiveX control container to let XMAX decode and dispatch its accelerator (e.g. Ctrl+C, Delete, etc)…but it is only called if XMAX is UIActivate.
In the .NET world, their ActiveX control container implementation should call XMAX's IOleInPlaceActiveObject::TranslateAccelerator() method. I think that happens via .NET’s “System.Windows.Forms.IOleInPlaceActiveObject.TranslateAccelerator(MSG& lpmsg)” implementation. If there is some way the customer can override or get in front of that .NET implementation, they should have a chance to do their own decoding and handling as to not pass 'Delete' to XMAX in the cases they want.
Doing things at the application (host) level is really the way to go. If you were to implement a scripting solution in an MCR file you would need to call out to your .NET code to get it to do what it needs to do, which is going to add even more complexity. It also means implementing the same script for each MCR associated with every DTD/XSD or XAC for each different document type used to edit documents in XMAX (as there is no concept of an application-level MCR file for XMAX as there are for XMetaL Author).
-
AuthorPosts
- You must be logged in to reply to this topic.