Prev: Creating a master document from code
Next: NoSpaceBetweenParagraphsOfSameStyle
From: Mo on 30 Sep 2009 08:27
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" wrote:

> 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
From: Manfred F on 1 Oct 2009 04:59
Hi,

"Mo" wrote:
>
> > 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.

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
From: "Tony Jollans" My forename at my surname dot on 1 Oct 2009 05:57
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.

--
Enjoy,
Tony

www.WordArticles.com

"Manfred F" <ManfredF(a)discussions.microsoft.com> wrote in message
news:CCAC55DC-326E-49C2-A8A1-C0D64073122E(a)microsoft.com...
> Hi,
>
> "Mo" wrote:
>>
>> > 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.
>
> 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

From: Mo on 1 Oct 2009 13:10
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
on that :-)?
/P

"Tony Jollans" wrote:

> 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.
>
> --
> Enjoy,
> Tony
>
> www.WordArticles.com
>
> "Manfred F" <ManfredF(a)discussions.microsoft.com> wrote in message
> news:CCAC55DC-326E-49C2-A8A1-C0D64073122E(a)microsoft.com...
> > Hi,
> >
> > "Mo" wrote:
> >>
> >> > 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.
> >
> > 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
>
>
First  |  Prev  | 
Pages: 1 2 3
Prev: Creating a master document from code
Next: NoSpaceBetweenParagraphsOfSameStyle