none
Capture Key strokes in the Word 2010 designer? RRS feed

  • Question

  • Hello

    Im faced with the following problem - I dynamically drop read-only content controls into the MS Word 2010 designer using a C# Word 2010 Add-In.

    One of the requirements is that a content control may not receive the cursor focus.

    In addition to this, when the user is tapping the left key and a content control is encountered the focus needs to move to the left,

    of the beginning of the content conrol.The opposite must happen if the right arrow key is being tapped on the keyboard and a content control is encountered.

    Below is the code which runs on the OnEnter event of the content control.

    What the code below does is move the cursor either to the left or to the right of the content control(depending on which block of code you uncomment).
    The problem is, I cannot find any object which tells me whether the cursor is coming from the left or the right of the designer and
    I need to know this in order to execute the appropriate block of code.

            void CurrDocument_ContentControlOnEnter(Microsoft.Office.Interop.Word.ContentControl ContentControl)
            {
                Microsoft.Office.Interop.Word.Range range = ContentControl.Range;
                
                //Set current range AFTER the content control
                //range.Start = range.End + 1;
                //range.Select();
     
                //Set current range BEFORE the content control
                range.Start = range.Start - 1;
                range.Select();
            }



      
    Any help in how to do this will be appreciated.
    If this cannot be done in Interop is there any way I can intercept the keystrokes just before the OnEnter is executed,
    then I will be able to see whether the user pressed the left or right arrow keys on the keyboard and execute the appropriate block of code.


    • Edited by Denys W Friday, December 23, 2011 9:32 AM
    Friday, December 23, 2011 9:15 AM

Answers

  • Hi Denys

    More exactly, I said there's nothing in the Word API or VSTO that can pick up keystrokes. There's nothing built-in that you can use in a VSTO project to pick up the keystrokes.

    You'd either need to use VBA (which isn't part of VSTO) or you'd need to use the Windows API - both of which are not an integral part of VSTO.

    In Word, keystrokes can only be mapped to VBA macros, not to other code.

    One thing that using the arrow keys will trigger is the WindowSelectionChange event (a lot of other things will trigger it as well). Purely theoretically you could capture this event, deterimine with the Selection is inside a content control range and if it is, move it to the front or end of the content control. Determine which way be comparing the selection's position in the content control with the number of characters in the control. This could, however, interfere with clicking and dragging, so you'd need to test.

    Exactly how "secure" does this need to be? What about the problem of deleting the field? Or of the user being able to go into Design mode (so that he could turn off LockContents)?


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by Denys W Friday, December 23, 2011 12:58 PM
    Friday, December 23, 2011 12:12 PM
    Moderator

All replies

  • Hi Denys

    If the user should not be typing into the content controls, why are you using content controls and not something else?

    The only way you can detect keystrokes in Word is to use VBA or the Windows API. There's nothing in either VSTO or the Word API that will let you pick up keystrokes in your add-in.


    Cindy Meister, VSTO/Word MVP
    Friday, December 23, 2011 11:15 AM
    Moderator
  • Hi Cindy

    I have a requirement to have read-only fields and the only way i found out how to do this in Word is to have text in a content control and then set content control's LockContents property to true.So the user will be allowed to move the field around on the form but will not be able to edit the inner text.

    I'm not sure I understand the last paragraph in your reply.In the first sentence you say that the only way to detect key strokes is using VBA or Windows API but in the second sentence you're saying that this cannot be done?Could you clarify please?

    Friday, December 23, 2011 11:38 AM
  • Hi Denys

    More exactly, I said there's nothing in the Word API or VSTO that can pick up keystrokes. There's nothing built-in that you can use in a VSTO project to pick up the keystrokes.

    You'd either need to use VBA (which isn't part of VSTO) or you'd need to use the Windows API - both of which are not an integral part of VSTO.

    In Word, keystrokes can only be mapped to VBA macros, not to other code.

    One thing that using the arrow keys will trigger is the WindowSelectionChange event (a lot of other things will trigger it as well). Purely theoretically you could capture this event, deterimine with the Selection is inside a content control range and if it is, move it to the front or end of the content control. Determine which way be comparing the selection's position in the content control with the number of characters in the control. This could, however, interfere with clicking and dragging, so you'd need to test.

    Exactly how "secure" does this need to be? What about the problem of deleting the field? Or of the user being able to go into Design mode (so that he could turn off LockContents)?


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by Denys W Friday, December 23, 2011 12:58 PM
    Friday, December 23, 2011 12:12 PM
    Moderator
  • Thank you ,this really helped me.

    I now store the last cursor position which gets set at the WindowSelectionChange event and then compare this value with the Start and End range properties of the content control on the ControlOnEnter event.I will need to look into the performance implications of doing it this way and fine tune it a little, but it does seem to be doing the intended task...

    Exactly how "secure" does this need to be? What about the problem of deleting the field? Or of the user being able to go into Design mode (so that he could turn off LockContents)?

    The requirement is that the inner text of the content control needs to be read-only.The user must be allowed to move the fields around on the designer and place the content controls in any desired position.The user also needs to be able to delete the content control which must remove both the content control and the inner text.

    At the moment if I right click on the content control i get an option on the context menu which lets me "Remove Content Control".This removes the content control BUT leaves the inner text exposing it to the user to make changes.

    I discovered that setting LockContentControl to true removes this option from the context but then i cannot delete the content control at all and in addition to that when i try move the content control to a different location it seems to perform a "copy" operation - creating the content control at the new location AND kepping the content control at the old location as well(i suppose this happens because a Move operation is simply a Delete at old location, Re-create at new location).So that's another thing which I'm planning to look into...I have not considered the issue where LockContents can be altered in design mode but thank you for the tip I will keep this in mind

     

    Friday, December 23, 2011 1:33 PM
  • Hi Denys

    Yes, this is what concerned me as I was looking at the probabilities... I'd also like to piont out that, if the user can put Word into "Design mode" he will be able to unlock the content control, change the text, etc.

    As far as I can see, there's no 100% secure way (by that, I mean protecting the text content) to achieve what you're trying to do and still allow the user to freely edit the document. Although I suppose it would be possible to disable the Design Mode, using Ribbon XML.

    But if this is as "secure" as you need to get, an alternative to content controls would be MacroButton fields. These automatically have the arrow key behavior and drag capability you want. The downside is that it's just as easy for the user to get to the displayed text, if he knows how.


    Cindy Meister, VSTO/Word MVP
    Friday, December 23, 2011 2:14 PM
    Moderator