merging documents into templates - automation problem

[sylvian_stone]

Hi,


I'm currently working with a back-office system that does a lot of its
reporting via Word VBA Macros. However, I need to extend the
functionality.


What I did was create a new template, add a user form, and use code to
drag in mini-templates containing text and mergefields to specified
bookmarks, depending on which options the user selects on the form.


This is pretty basic stuff, but my main problem lies in the fact that
if I open the main document as a template, there is no problem.
However, if the main document is opened as a document, I get the
following error:


"Class does not support automation or does not support expected
interface."


Looking through the docs, it suggested that this is an MDAC problem.
Having installed a new MDAC, it has made no difference.


Am I missing something basic here:


The main code that drags the template (or word document - I've tried
both) into the main template / document is:


Sub check_path()
path = "E:\1stdir32\Letter\Financial Plan - LBFP\"


End Sub


Private Sub hide_form_Click()
report_options.Hide
End Sub


Private Sub render_Click()


check_path


Dim myRange As Range


Set myRange =
ActiveDocument.Bookmarks("inve­stment_risk_paragraph").Range


myRange.InsertBreak wdSectionBreakNextPage


myRange.InsertFile path & "attitude_to_investment_risk.d­oc"


End Sub


Thanks for any advice.
SS.

 

[Cindy Meister]

Hi Sylvian

You use some unusual terminology, so I'm not quite sure what you're actually
doing. (By "unusual" I mean things like saying "drag" when what you're
actually doing is inserting a file). Makes it difficult to guess what the
problem might be.

1. What do you mean by "open the main document as a template" vs. opening it
as a document? Please be very precise.

2. Where is the code you show us stored? And what relationship does it have
to the file you're processing with the code?

3. Do you get any indication what code is causing the error message?

4. Where and how is the path variable declared?

5. I take it the code you show us is in the code module for a form? How
about the code that displays the form?

FWIW, a UserForm is a special kind of class. I'm guessing you might be
"mishandling" that, in the code you haven't shown us...

-- Cindy

 

[sylvian stone]

Hi,

OK. I'll try and word this as best I can.

With regard to your points:

1. If I open the main document as a template (i.e. a .dot file), I have
no problem. However, if this is launched as a .doc file based on the
template, I get the automation error.

2. All the code is stored in the template file within a module. It has
no relationship to the files that are being processed. They are just
other templates stored in another directory.

3. No error code - just the automation error message.

4. The path variable is stored in the sub in the 'General' section of
the module.

5. Yes, the code is in a code module for a form. The code that displays
the form is actually located in the word document - in the VBA IDE it
is shown under Microsoft Word Objects\ThisDocument

The form is launched by a button on the document. The code to launch
the form from the document is:

Private Sub UserForm_Initialize()
Load report_options
report_options.Show
End Sub


Private Sub insert_Click()
UserForm_Initialize
End Sub


Where 'insert' is the name of the button, and 'report_options' is the
name of the userform.


Now, I would have liked to simply launch the form at startup, but I am
working around a specific system that already uses Word VBA code to
spit out reports. The code for this is locked, and I suspect there is
already startup code in there. This existing code does certain merging
functions from the back office system, and while it is OK, I need to do
some additional coding to produce the type of reports that we actually
require. Therefore, I would'nt be surprised if there is some conflict
between the 'locked' code and the additional code I am writing to lay
along side it.

Anyway, if you see anything obvious above, I would love to know....


Thanks for your help.
SS.

 

[Cindy Meister]

Hi Sylvian

<<the code is in a code module for a form. The code that displays
the form is actually located in the word document - in the VBA IDE it
is shown under Microsoft Word Objects\ThisDocument>>

OK, I think we're narrowing down where the problems could lie...

<<The form is launched by a button on the document. The code to launch
the form from the document is:

Private Sub UserForm_Initialize()
Load report_options
report_options.Show
End Sub

Private Sub insert_Click()
UserForm_Initialize
End Sub

Where 'insert' is the name of the button, and 'report_options' is the
name of the userform.>>

I take it the button is an ActiveX control (Controls Toolbox)?

UserForm_Initialize is an EVENT for the UserForm, called by VBA when the
UserForm is loaded. You can't (or shouldn't) start the Userform like this.
Try moving the code you have in UserForm_Initialize to the insert_Click
procedure (removing the call to UserForm_Initialize) and see if that settles
things down at all.

<<Now, I would have liked to simply launch the form at startup, but I am
working around a specific system that already uses Word VBA code to
spit out reports. The code for this is locked, and I suspect there is
already startup code in there. This existing code does certain merging
functions from the back office system, and while it is OK, I need to do
some additional coding to produce the type of reports that we actually
require. Therefore, I would'nt be surprised if there is some conflict
between the 'locked' code and the additional code I am writing to lay
along side it.>>

Hard to say, but I'd start with my suggestions Theoretically, you could
try a Document_New procedure (you should see this in the ThisDocument module
of the template) that will execute when a new document is created. Whether
this will conflict with the other app I can't say, but chances are, it would.
But you could try and see what happens...

-- Cindy

 

[sylvian stone]

I found out that the problem was a corrupted template, not the code
itself....

typical....