Windows7 and Word2007 vba code problem

[Mo]

Hi,

I have posted a problem here earlier regarding code that works in
WindowsXP/Word2007 but not on Windows7/Word2007, but have received no
replies. That problem still exists. I now have another similar problem:

In a global template I store code and global variables. The global template
is in the startup directory so it gets loaded into word at word startup.
Individual templates then make use of that code and variables. This is
accomplished through an autonew macro in each individual template, that at
run-time attaches a reference to that global template. Here is the code
structure:

In the Global template:

Public G_Variable as string

Public Sub AutoExec()
G_Variable = "Hello"
End Sub

Public Sub AddGlobalReference()
ActiveDocument.AttachedTemplate.VBProject.References.AddFromFile Chr(34) &
"TheGlobalTemplateName.dotm" & Chr(34)
ActiveDocument.AttachedTemplate.Saved = True

End Sub

In the Individual templates:

Sub AutoNew()
Application.Run "AddGlobalReference"
MsgBox G_Variable
End Sub

The problem:
When a new document is created with the individual templates and the AutoNew
macro runs

* In Windows7/Word2007 the msgbox displays "" = Not desired result
* In WindowsXP/Word2007 the msgbox displays "Hello" = Desired result

To me a strange thing in Windows7/Word2007 is, that after the AutoNew macro
has finished its execution, if you in VBE, in the Immidiate Window, view the
variable (debug.print G_Variable) it displays "Hello".

Some notes:

* There are no problems with the reference setting - it is set through the
AddGlobalReference code. (If you need a
* First after the execution of the AutoNew is finished, the variable is
usable from the individual templates.

Environment:

* The latest updates are installed via Microsoft Update.

I would be glad if someone, also from Microsoft, could comment on this
problem,
Peeter

 

[Tony Jollans]

My guess is that this is a timing issue. Does it make a difference if you
put DoEvents before the MsgBox?

 

[Mo]

Thanks,

I have tried that but it makes no difference. The problem still exists: It
works in Windows XP, and has so for years, but under Windows 7 it doesn't.

Microsoft - could you please comment on this?

/P

 

[Manfred F]

Mo,

this could still be a timimg problem.
Please try and run the "AutoExec" in Your global template manually once
(again).
What happens then when You add a new document from Your individual template?

Kind Regards,

Manfred

 

[Mo]

Thanks for showing interest,

No, that didn't help. The timing problem, if that is it, lies more in the
autonew sequence - addglobalreference and the following msgbox.
/P

 

[Manfred F]

Hi Mo,

No, that didn't help. The timing problem, if that is it, lies more in the
autonew sequence - addglobalreference and the following msgbox.

well, if You re-run the Autoexec and then add a new document, and the error
still occurs, then - it is not a timimg problem.
By running the Autoexec again, You are out of the execution context of
startup. When You add a new document, this again happens in an own execution
context.

It is curious. What do You get, when You access the global variable in the
debugger?
Is there really only one instance of this global variable in the system?
Maybe You can replace the global Variable by a global Property Get
procedure. What happens then?

Regards,

Manfred

 

[Mo]

Hi again,

1) What do You get, when You access the global variable in the debugger?
In the debugger I get the same as the msgbox shows - at execution of autonew
= blank, after execution of autonew "Hello"
2) Is there really only one instance of this global variable in the system?
Absolutely sure
3) Maybe You can replace the global Variable by a global Property Get
procedure. What happens then?
The same result as before

Has anyone tried this in Windows7/Word7 and it works?

Thanks,
/P

 

[Tony Jollans]

I have just tried this and it doesn't work for me anywhere and, having taken
a proper look at it, I have no idea how it works for you in XP.

When you set a reference it affects the way individual procedures are
compiled. The AutoNew procedure in the document template is compiled without
the reference, at which time the global variable in the global template is
not, and can not be, resolved. If you have "Option Explicit" set, you will
get a compile error; if not, a local variant will be automatically created
with a default (empty) value.

To make it work, you need to code something like:

Sub AutoNew()
Application.Run "AddGlobalReference"
SecondProc
End Sub

Sub SecondProc()
MsgBox G_Variable
End Sub

SecondProc will be compiled when it is called and, by then, the reference to
the global template will have been set and G_Variable will resolve to the
global variable there.

 

[Manfred F]

Hi Mo,

I didn't get the point that, in Your AutoNew routines, You set the Reference
to THIS global add-in. By the way - why do You do this again and again for
every new document? You should do this only once after loading the local
template or even better - once at compile time (early binding).

Tony is right with his comments. I would be even more cautious and call his
SecondProc in a second execution context using a timer:

Sub AutoNew()
Application.Run "AddGlobalReference"
Application.OnTime When:=Now + TimeSerial(0, 0, 0.3), _
Name:="SecondProc"
End Sub

Public Sub SecondProc()
MsgBox G_Variable
End Sub

Regards,
Manfred

 

[Mo]

Thanks Tony,

it's a very good explanation. I'll use that.

/P

 

[Mo]

Thanks for your reply,

By the way - why do You do this again and again for
every new document? You should do this only once after loading the local
template or even better - once at compile time (early binding).

It's because we dont always have full control over customers different
environments and espacially the paths. If you have the "hard coded" path in
the individual template it probably won´t find it when installed in the user
environment. The instruction could then be to put it in the start-up folder.

/P

 

[Manfred F]

Hi,

It's because we dont always have full control over customers different
environments and espacially the paths. If you have the "hard coded" path in
the individual template it probably won´t find it when installed in the user
environment. The instruction could then be to put it in the start-up folder.

There shouldn't be a need to restore the references to global add-ins: Word
automatically does this for You, if the add-in is located in the startup
folder. So, if You develop on Your pc an add-in (in the startup folder) and a
dependant template (located anywhere) referencing the add-in statically, this
will work also after transfer to another machine (global add-in into startup
folder, dependant template somewhere), regardless of differences in the
startup folder's path.

Regards,
Manfred

 

[Tony Jollans]

I haven't checked this out but, in my experience, Word has a tendency to
drop references to other VBA projects unless they are explicitly used and I
don't think the reference to a public variable is enough to change that
behaviour. So I think, for this situation (the rather convoluted example is
nonsense in isolation, but I assume there real thing is more complex) the
reference may need continually re-establishing, though once per template
load rather than once per new document should be sufficient.

 

[Mo]

thank you T and M for your comments,

I have posted a problem here earlier (2009-09-17) regarding code that works
in
WindowsXP/Word2007 but not on Windows7/Word2007 - you wouldn't mind comment