Template into the user's Word startup folder, macro name conflict

[Francois Piette]

When a template in a startup folder has a macro with the same name as a
macro in normal.dot, which one will be executed ? How can I manage to have
the macros in the template located in the startup folder detect that macro
name conflict exist ? And better, how can a macro in the template remove a
macro in normal.dot ?

 

[Charles Kenyon]

1) You should _not_ have your Add-In mess around with normal.dot. Name your
macros so that the name will be unique. It isn't hard.

2) Generally it has been my experience that a macro in the document will be
run in preference to a macro of the same name in the attached template. A
macro in the attached template will be run in preference to one in any
global template. A macro in normal.dot will be run in preference to one in a
global template other than normal.dot. If you have multiple globals, it
seems to depend on the order in which they are loaded.

 

[Francois Piette]

1) You should _not_ have your Add-In mess around with normal.dot.

Name your macros so that the name will be unique. It isn't hard.

That answer will not help at all. There is an existing situation and I must
work with that situation. I have 500 workstations with that situation and I
don't want to manually change anything (imagine the time needed to sit down
in front of 500 workstations and clean the mess up !).

2) Generally it has been my experience that a macro in the document will be
run in preference to a macro of the same name in the attached template. A
macro in the attached template will be run in preference to one in any
global template. A macro in normal.dot will be run in preference to one in a
global template other than normal.dot. If you have multiple globals, it
seems to depend on the order in which they are loaded.

OK. So it is unreliable.

And what about my other questions:
I could add that I can easily write an external program making use on COM to
driver Word to remove/rename/create those macro, if it is easier. I have a
working system to remotely distribute and run the external program
automatically on the 500 workstations.

Thank you for taking time to answer my [stupid] questions.

 

[Charles Kenyon]

Your questions are not stupid. As I said in my signature, I am somewhat
ignorant myself in this area.

How are you running the macros? If you are using "application.run
macroname:=" statements or triggering them with a toolbar button there
should be little problem. If the former, refer to the project and module
along with the name of the macro in the statement. I do not know the syntax
for this, but know it exists. If you don't have unique names for your
project and module, you have a problem.

If you are triggering them from a menu or toolbar button, actually create
the button (manually) in the Add-In and it will not get confused. It will
pull the macro that it was created with even if there are confusing names.

1) You should _not_ have your Add-In mess around with normal.dot.
Name your macros so that the name will be unique. It isn't hard.

That answer will not help at all. There is an existing situation and I must
work with that situation. I have 500 workstations with that situation and I
don't want to manually change anything (imagine the time needed to sit down
in front of 500 workstations and clean the mess up !).

2) Generally it has been my experience that a macro in the document will be
run in preference to a macro of the same name in the attached template. A
macro in the attached template will be run in preference to one in any
global template. A macro in normal.dot will be run in preference to one

in

a
global template other than normal.dot. If you have multiple globals, it
seems to depend on the order in which they are loaded.

OK. So it is unreliable.

And what about my other questions:
I could add that I can easily write an external program making use on COM to
driver Word to remove/rename/create those macro, if it is easier. I have a
working system to remotely distribute and run the external program
automatically on the 500 workstations.

Thank you for taking time to answer my [stupid] questions.

--
(e-mail address removed)
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be

 

[Francois Piette]

How are you running the macros? If you are using "application.run

macroname:=" statements or triggering them with a toolbar button there
should be little problem. If the former, refer to the project and module
along with the name of the macro in the statement. I do not know the syntax
for this, but know it exists.

Some macros are triggered by a toolbar button and some other by kyboard
shortcut.

If you don't have unique names for your
project and module, you have a problem.

I currently have macros in normal.dot that I would like to move to a startup
template for easy distribution. So I'm looking for a way to either:
- Be sure that the macros from startup template has higher priority
- Automatically delete the macros from normal.dot so that those in the
template are used.

As mentionned before, my problem is that I have 500 workstations using the
application and have to find a way to automate this "update". I can
automatically distribute the startup template or any separate executable
application at the user workstation. I can easily spent several days
developping something to automate the update process and then avoid going to
500 workstations (you imagine the time needed for 500 workstations !).

--
(e-mail address removed)
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be

Your questions are not stupid. As I said in my signature, I am somewhat
ignorant myself in this area.

How are you running the macros? If you are using "application.run
macroname:=" statements or triggering them with a toolbar button there
should be little problem. If the former, refer to the project and module
along with the name of the macro in the statement. I do not know the syntax
for this, but know it exists. If you don't have unique names for your
project and module, you have a problem.

If you are triggering them from a menu or toolbar button, actually create
the button (manually) in the Add-In and it will not get confused. It will
pull the macro that it was created with even if there are confusing names.

That answer will not help at all. There is an existing situation and I must
work with that situation. I have 500 workstations with that situation

and

I
don't want to manually change anything (imagine the time needed to sit down
in front of 500 workstations and clean the mess up !).

will
be

template.

A

one

in

OK. So it is unreliable.

And what about my other questions:

I could add that I can easily write an external program making use on

COM

to
driver Word to remove/rename/create those macro, if it is easier. I have a
working system to remotely distribute and run the external program
automatically on the 500 workstations.

Thank you for taking time to answer my [stupid] questions.

--
(e-mail address removed)
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be

 

[Charles Kenyon]

You might use a separate installer template that as part of its AutoExec
strips the macros, toolbars, and keyboard shortcuts from Normal.dot and
saves normal.dot. Then put in your Add-In. Again, in my experience, keyboard
shortcuts and toolbars are set to call a particular project and module so
your problem is not merely which macro Word defaults to but which your
shortcuts and toolbars reach. They do not necessarily follow the default
path for Word.

How are you running the macros? If you are using "application.run
macroname:=" statements or triggering them with a toolbar button there
should be little problem. If the former, refer to the project and module
along with the name of the macro in the statement. I do not know the syntax
for this, but know it exists.

Some macros are triggered by a toolbar button and some other by kyboard
shortcut.

If you don't have unique names for your
project and module, you have a problem.

I currently have macros in normal.dot that I would like to move to a startup
template for easy distribution. So I'm looking for a way to either:
- Be sure that the macros from startup template has higher priority
- Automatically delete the macros from normal.dot so that those in the
template are used.

As mentionned before, my problem is that I have 500 workstations using the
application and have to find a way to automate this "update". I can
automatically distribute the startup template or any separate executable
application at the user workstation. I can easily spent several days
developping something to automate the update process and then avoid going to
500 workstations (you imagine the time needed for 500 workstations !).

--
(e-mail address removed)
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be



"Charles Kenyon" <[email protected]> a écrit dans le
message de news:[email protected]...

Your questions are not stupid. As I said in my signature, I am somewhat
ignorant myself in this area.

How are you running the macros? If you are using "application.run
macroname:=" statements or triggering them with a toolbar button there
should be little problem. If the former, refer to the project and module
along with the name of the macro in the statement. I do not know the syntax
for this, but know it exists. If you don't have unique names for your
project and module, you have a problem.

If you are triggering them from a menu or toolbar button, actually create
the button (manually) in the Add-In and it will not get confused. It will
pull the macro that it was created with even if there are confusing names.
and template. one COM

have

a

working system to remotely distribute and run the external program
automatically on the 500 workstations.

Thank you for taking time to answer my [stupid] questions.

--
(e-mail address removed)
Author of ICS (Internet Component Suite, freeware)
Author of MidWare (Multi-tier framework, freeware)
http://www.overbyte.be

 

[Francois Piette]

You might use a separate installer template that as part of its AutoExec

strips the macros, toolbars, and keyboard shortcuts from Normal.dot and
saves normal.dot. Then put in your Add-In.

That's exactly what I want to do and specially what I want to know how to do
with the questions I asked in my first post on this thread.

Her again:
I'm sure that the answer is easy. It suffice to find the right people
knowing how to do or knowing where to look in the docs.