none
Automation Access to Word RRS feed

  • Question

  • I have a VBA macro in MS Access that rolls through my database and creates a MS Word document. This worked for years with Office XP. As part of the macro, I create a Text Box in the header of the Word document, format it, then convert it to a Frame so I can specify Outside (through code) for duplex printing.

    Since my upgrade to Office 2010, the "WordApp.ShapeRange(1).ConvertToFrame" command constantly fails with "Error 4652 - Wrong drawing object for this command".

    I have been up and down the help files and cannot find a reference to this error. I have been looking for the error in developer forums, again with no luck finding it. I'm pretty sure it's a missing reference in Access, but I can not nail it down. I also seem to remember reading that Word 2010 does not use Frames any longer, but can't find that article again. I did notice that Text Boxes now have the Inside/Outside option.

    I have tried to record a macro in Word to get the code, but once I create the text box, the "Position" button is greyed out unless I stop recording, which defeats the purpose of recording.

    Does anyone have a solution to this?

    Thursday, December 9, 2010 4:17 PM

Answers

  • Without going in much more deeply myself, I can only offer a pointer, which is to experiment with the values of

    WordApp.Shape(1).Left, .LeftRelative and .RelativeHorizontalPosition

    AFAICS in Word 2010, ConvertToFrame is no longer available in the UI, and even if you put the Command in the QAT, it is greyed out for a selected Textbox, and that corresponds to the fact that the Method is "hidden" in VBA. However, if you create the textbox in Word 2007 and open that document, it will be in compatibility mode and in that case the textbox can be selected, and the old UI option is there, the QAT command works, and the VBA Method also works. Despite the fact that the Shape reports the same .Type value in both cases, they are clearly actually different types of object (presumably because of the new drawing features). I expect there is some other way to determine whether you are dealing with the old type or the new type of shape (without generating a VBA error) but off the top of my head I can't tell you what that is.


    Peter Jamieson
    • Marked as answer by Bessie Zhao Friday, December 17, 2010 9:00 AM
    Thursday, December 9, 2010 11:10 PM
  • Hi Bob (all)

    My reply to this question is in the Access forum:

    http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/698860f8-1180-4ef0-b3e4-c716d090112a

    but here's its content:

    Just happened to be skimming through this forum, today, but I agree with David's suggestion to take such questions to Word Developer:

    http://social.msdn.microsoft.com/Forums/en-US/worddev/threads

    FWIW Word finally implemented the new graphics engine that was introduced in Office 2007, which means the Drawing objects are no longer the same. That's why ConvertToFrame isn't working. And quite a number of things that should be in the object model aren't...

    Is there a reason you're creating these documents from-scratch, rather than using a template that contains standard things as the basis? That would be the simplest way to solve this, as the text box (or frame) could already be in the document with the appropriate formatting.

    The other possibility would be for you to distribute a template with your database that contains BuildingBlocks, such as a text box or frame with this formatting. These can be inserted as required, rather than being built from scratch.

    Another approach that could work would be to define a style that contains the Frame and apply that to the text in question.

    The only other thing that occurs to me would be to make sure this document is a *.doc (Word 2003 file format) or in the "Compatibility Mode" for Office 2007. Possibly, it will then generate the old type of text box and converttoframe will still work.

    Please note that I might not see any follow-up you post in this (Access) forum, so you may need to bring the discussion to Word Developer if you require more information (just copy a link to this thread so that you don't have to retype all the information).


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by Bessie Zhao Friday, December 17, 2010 9:00 AM
    Friday, December 10, 2010 8:34 AM
    Moderator

All replies

  • Without going in much more deeply myself, I can only offer a pointer, which is to experiment with the values of

    WordApp.Shape(1).Left, .LeftRelative and .RelativeHorizontalPosition

    AFAICS in Word 2010, ConvertToFrame is no longer available in the UI, and even if you put the Command in the QAT, it is greyed out for a selected Textbox, and that corresponds to the fact that the Method is "hidden" in VBA. However, if you create the textbox in Word 2007 and open that document, it will be in compatibility mode and in that case the textbox can be selected, and the old UI option is there, the QAT command works, and the VBA Method also works. Despite the fact that the Shape reports the same .Type value in both cases, they are clearly actually different types of object (presumably because of the new drawing features). I expect there is some other way to determine whether you are dealing with the old type or the new type of shape (without generating a VBA error) but off the top of my head I can't tell you what that is.


    Peter Jamieson
    • Marked as answer by Bessie Zhao Friday, December 17, 2010 9:00 AM
    Thursday, December 9, 2010 11:10 PM
  • Hi Bob (all)

    My reply to this question is in the Access forum:

    http://social.msdn.microsoft.com/Forums/en-US/accessdev/thread/698860f8-1180-4ef0-b3e4-c716d090112a

    but here's its content:

    Just happened to be skimming through this forum, today, but I agree with David's suggestion to take such questions to Word Developer:

    http://social.msdn.microsoft.com/Forums/en-US/worddev/threads

    FWIW Word finally implemented the new graphics engine that was introduced in Office 2007, which means the Drawing objects are no longer the same. That's why ConvertToFrame isn't working. And quite a number of things that should be in the object model aren't...

    Is there a reason you're creating these documents from-scratch, rather than using a template that contains standard things as the basis? That would be the simplest way to solve this, as the text box (or frame) could already be in the document with the appropriate formatting.

    The other possibility would be for you to distribute a template with your database that contains BuildingBlocks, such as a text box or frame with this formatting. These can be inserted as required, rather than being built from scratch.

    Another approach that could work would be to define a style that contains the Frame and apply that to the text in question.

    The only other thing that occurs to me would be to make sure this document is a *.doc (Word 2003 file format) or in the "Compatibility Mode" for Office 2007. Possibly, it will then generate the old type of text box and converttoframe will still work.

    Please note that I might not see any follow-up you post in this (Access) forum, so you may need to bring the discussion to Word Developer if you require more information (just copy a link to this thread so that you don't have to retype all the information).


    Cindy Meister, VSTO/Word MVP
    • Marked as answer by Bessie Zhao Friday, December 17, 2010 9:00 AM
    Friday, December 10, 2010 8:34 AM
    Moderator
  • In reply to my response, Bob posted

    "btw: The reason I start the document from scratch is that I actually have multiple databases that I produce this document for and, depending on which database I am documenting, I place different text in the headers and footers (in the text boxes). The code resides in one database so I don't have to worry about changing redundant code. I change it once and it's fixed for all. I pass a variable to let it know which database to retrieve.

    I try to keep my questions simple so I can get simple answers. I've seen so many questions that ramble on about specifics and they are looking for specific answers so they don't have to think too much to fix the problem."

    Sometimes, specifics are necessary in order to work out the optimal approach :-) But it is difficult to know when and how much is required, especially for an application type (Word) with which you're not so familiar...

    If the reports you're generating are basically the same lay-out, then I'd put the "boxes" (whether frames or text boxes or even table cells) into a template's header or footer. Put a bookmark in them so that your code can find them to insert the relevant text for that database. That will save the code needing to create/convert the boxes.


    Cindy Meister, VSTO/Word MVP
    Friday, December 10, 2010 8:38 AM
    Moderator