Transferring AutoText

[Chuck]

Hi all

Periodically we need to roll out refreshed a normal.dot to our users (to
make sure the built-in toolbars are standardised and there are no macros
other than the auto macros we prescribe). However we need to preserve users'
autotext and autocorrect entries. The idea is to have the log in script copy
the user's old normal.dot into a temporary location, copy over the user's
autotext and autocorrect entries from the old normal.dot to the refreshed
normal.dot and then delete the old normal.dot.

I've written a sub to delete all autotext entries from the refreshed
normal.dot and to import them from the old normal.dot and it works fine.
However, after import the Insert > AutoText menu shows duplicates of all the
out of the box AutoText entries. The Autotext entries aren't actually
duplicated -- only one of each shows in the Organizer if I exit Word and go
back in the Insert > AuoText menu shows only one of each.

What gives? Any ideas on how I can do what I need to do without having to
restart Word to clean out (ghost) duplicates on the Insert > AutoText menu?

Below is the code I've come up with for copying the AutoText entries. Many
thanks for any suggestions...

Sub AutotextCopy1()

Dim docOldNormal As Word.Document
Dim atxEntry As Word.AutoTextEntry

Set docOldNormal = Word.Documents.Open("c:\temp\xnormal.dot")

For Each atxEntry In NormalTemplate.AutoTextEntries
atxEntry.Delete
Next atxEntry

For Each atxEntry In docOldNormal.AttachedTemplate.AutoTextEntries
Application.OrganizerCopy _
Source:=docOldNormal.AttachedTemplate.FullName, _
Destination:=NormalTemplate.FullName, Name:=atxEntry.Name, _
Object:=wdOrganizerObjectAutoText
Next atxEntry

docOldNormal.Close wdDoNotSaveChanges

End Sub

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, < Chuck > écrivait :

Hi all

Periodically we need to roll out refreshed a normal.dot to our users (to
make sure the built-in toolbars are standardised and there are no macros
other than the auto macros we prescribe). However we need to preserve

users'

IMHO, corporate-wide macros/toolbars/autotexts should be in a global
template, locked for editing if needed.
This way you don't have to play around with users' Normal.dot, unless they
screw it up, then it is a support case, not a regular policy thing.
Much less hassle for you and more joy for the users.

But, that's just my opinion!

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Chuck]

Thanks for the suggestion. We have global locked add ins for macros/command
bars; user macros are not allowed in normal.dot; we don't have corporate
autotext entries. However we have to accommodate users by allowing them to
create their own autotext entries and not erase all their work when we
periodically refresh the normal.dot. If we lock the normal.dot then that
just makes it difficult for users to save their autotext entries (I know it's
possible, but it's not feasible or necessary to expect them to remember to
save autotext outside normal.dot or to comply with such a policy).

So we need to save the autotext entries in their existing normal.dot into
the refreshed normal.dot without creating ghost duplicate entries in the
Insert > AutoText menu.

Anyone have any ideas how to tweak the code I posted or another/better way?

Many thanks...

 

[JB]

Thanks for the suggestion. We have global locked add ins for macros/command
bars; user macros are not allowed in normal.dot; we don't have corporate
autotext entries. However we have to accommodate users by allowing them to
create their own autotext entries and not erase all their work when we
periodically refresh the normal.dot. If we lock the normal.dot then that
just makes it difficult for users to save their autotext entries (I know it's
possible, but it's not feasible or necessary to expect them to remember to
save autotext outside normal.dot or to comply with such a policy).

So we need to save the autotext entries in their existing normal.dot into
the refreshed normal.dot without creating ghost duplicate entries in the
Insert > AutoText menu.

Anyone have any ideas how to tweak the code I posted or another/better way?

Many thanks...

:

Well another way (if I understand this properly) is to create a form in
your existing addin, which allows users to edit/create their own global
for Autotext and include in your toolbar a button to execute this form.

The thinking is that users should not really mess with Normal.dot as you
well know, so give them another, more permanent option which will suit all.

Once they've filled the form in for the Autotext they want you just
create a new template, add Autotext and save in startup with a pointer
in the reg to show they have their own Autotext template.

Subsequent use of the button would show the original Autotext they
entered and give the opportunity to edit/add or delete.

HTH

J

 

[Chuck]

Thanks for the intriguing suggestion JB. It bears exploring, although
working with the registry is beyond my capabilities at present. Also
unfortunately I don't really have the resources to create a form-based
workaround right now (there are other pressing priorities) so I really do
need to work with exporting/importing autotext from normal.dot. Any thoughts
on my original question about avoiding ghost duplicate items in the Insert >
AutoText menu?

Thanks for any help...
Chuck

 

[Julie]

Chuck,

A user-owned global template is the best way to go, but...

If you must proceed as planned, why not delete the native Word autotext from
your new master normal.dot before copying the user's autotext to the new
normal.dot. That will resolve your duplication problem, but may invite
another problem (discussed next).

You may encounter a problem that I encountered once when using a macro for
the initial (one-time only) move of autotext from Normal.dot to user global
template which is: the link to style was lost as a result of the organizer
copy with the result being, for example, that an autotext entry linked to
footer style no longer appeared on the header/footer toolbar. That was Word
97. I believe I also encountered the problem in Word 2K as well, but am not
positive on that. I had to backtrack and only copy autotext entries that
were not native Word autotext entries, which of course, resulted in user
losing any modifications to the native Word Autotext entries.

Hope this helps,
Julie

 

[Chuck]

Hi Julie

My code does delete the autotext entries from normal.dot (see my original
post). The "duplication" I'm getting is "ghost" duplication because the
entries aren't duplicated, just appear to be on the Insert > AutoText menu
bar -- when I close Word and restart the Insert > AutoText menu bar doesn't
show any duplicates. (I'm running my code from a separate template, not an
autoexec macro.)

Re the problem with unliked styles, I saw a reference to that in the
google.groups archives and the workaround suggested there was to copy styles
over first then autotext, but there wasn't any follow up to indicate whether
that worked or not. In any case all our styles are identical in both the
"old" and "new" normal.dots so hopefully that won't be an issue.

Chuck

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, < Chuck > écrivait :

Hi Julie

My code does delete the autotext entries from normal.dot (see my original
post). The "duplication" I'm getting is "ghost" duplication because the
entries aren't duplicated, just appear to be on the Insert > AutoText menu
bar -- when I close Word and restart the Insert > AutoText menu bar doesn't
show any duplicates. (I'm running my code from a separate template, not an
autoexec macro.)

I know you are sick of reading it, but it cannot be overstated, you should
not have to mess around with your user's Normal.dot.
But, since you are determined to do so, for now, [I hope ;-) ] and since it
seems that the problem is just a matter of restarting Word, you can try to
reset the default menu bar to its default setting. That might clear the
unwanted entries from the menu.

Something like:

'_______________________________________
CustomizationContext = NormalTemplate

Application.CommandBars("Menu Bar").Reset
'_______________________________________

Haven't tried it in your situation, but it might do the trick!

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Chuck]

Thanks Jean-Guy. I'm not sick of it at all, I can't get enough! ;-)

I thought of using CustomizationContext but other posters have warned about
corruption problems with it (and I think I may have run into them myself).

Until we can train users to save their autotext into a dedicated add in, I
think we'll just have to save the old-normal.dot to a safe place, let users
know where that is and have them copy their own autotext manually using
Organizer.

Unless there's something else (simple) that comes to anyone's mind?

Chuck

Bonjour,

Dans son message, < Chuck > écrivait :

Hi Julie

My code does delete the autotext entries from normal.dot (see my original
post). The "duplication" I'm getting is "ghost" duplication because the
entries aren't duplicated, just appear to be on the Insert > AutoText menu
bar -- when I close Word and restart the Insert > AutoText menu bar doesn't
show any duplicates. (I'm running my code from a separate template, not an
autoexec macro.)

I know you are sick of reading it, but it cannot be overstated, you should
not have to mess around with your user's Normal.dot.
But, since you are determined to do so, for now, [I hope ;-) ] and since it
seems that the problem is just a matter of restarting Word, you can try to
reset the default menu bar to its default setting. That might clear the
unwanted entries from the menu.

Something like:

'_______________________________________
CustomizationContext = NormalTemplate

Application.CommandBars("Menu Bar").Reset
'_______________________________________

Haven't tried it in your situation, but it might do the trick!

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, < Chuck > écrivait :

Thanks Jean-Guy. I'm not sick of it at all, I can't get enough! ;-)

But I still do not understand why it is important to delete and recreate a
new Normal.dot regularly?
You should not even be concerned with Normal.dot. It is used for personal
customization and tom create blank documents.
So what is the harm? I have seen cases where people thought they had to
"update" Normal.dot with new stuff, (which is the wrong way, of course), but
never having to delete Normal.dot on a regular basis to recreate it.
Normally you only do that when there is a problem or when Normal.dot has
become corrupted.

I am intrigued!

I thought of using CustomizationContext but other posters have warned about
corruption problems with it (and I think I may have run into them myself).

Never heard of that before!
But, hey, I do not claim to know everything, so it possible that under some
circumstances that may be true, but I have never heard of that before.

Until we can train users to save their autotext into a dedicated add in, I
think we'll just have to save the old-normal.dot to a safe place, let users
know where that is and have them copy their own autotext manually using
Organizer.

If you still insist on mucking about with Normal.dot...
Then, the first time around, take the Normal.dot, rename it to some Add-in
sounding name and place it in the user Start-up folder. The Autotexts will
be available automatically. Piece of cake!
The second time around, transfer them to the add-in before deleting the
Normal.dot.
You could have a logic test to see if the add-in already exists (Use
UserNames or some other unique ID you can get), if not, first time, if it
does, second time...
Sounds complicated, but it should not be too hard... After all, you are the
one insisting on having fun with your users' Normal.dot (Had to mention it
one more time!)

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Chuck]

There are a variety of good reasons (which we have considered carefully) for
needing to "refresh" normal.dot from time to time. EG: We use automacros in
normal.dot for various reasons. Automacros don't necessarily work with
documents that haven't been created based on the templates they're contained
in. Periodically we need to update the normal.dot with revisions to the
automacros as well as during repair/reconfiguration. Etc.

 

[JB]

There are a variety of good reasons (which we have considered carefully) for
needing to "refresh" normal.dot from time to time. EG: We use automacros in
normal.dot for various reasons. Automacros don't necessarily work with
documents that haven't been created based on the templates they're contained
in. Periodically we need to update the normal.dot with revisions to the
automacros as well as during repair/reconfiguration. Etc.

:

Hi Chuck,
I'm thinking that "Automacros don't necessarily work with
documents that haven't been created based on the templates they're
contained in." is not the best way to think about this problem.

This seems more like a problem which has not been thought through well
enough (I know you said "(which we have considered carefully)") but the
fact is that you are creating a problem to fix a problem, rather than
addressing the underlying issue of how the IT dept should be using
tmplates and macros to help the user use the applications you provide
with as little hassle as possible.

Normally if you get bad behaviour from a document attached to a template
that it shouldn't be attached to then you change to the template the
document works best with, or manipulate the document to conform to the
standards you set when it's opened (creating a backup along the way of
course).

I've a good bit of experience in this feild and I've no doubt Jean-Guy
has also so (one last mention of it) Normal.dot should be removed from
the problem as quickly as possible.

Cheers

J

 

[lishaowen23]

hi Chuck
I think i know what you want.I have some idea: in your code you write:

" For Each atxEntry In NormalTemplate.AutoTextEntries

atxEntry.Delete
Next atxEntry"

that will cause the style which autotextentry linked will lose,and then you
can do nothing with adding entry when you copy entry from other document next
.. How about rename a new style name first,and then add each entry in? codes
like that:

Sub CreateAutoTextEntries(ByVal strStyleName As String, ByRef strChoise()
As String)
' strChoise() is all entries linked in a style
For i = 0 To UBound(strChoise) - 1
Selection.Range.Collapse wdCollapseStart

' Selection.Font.Italic = True
Selection.TypeText strChoise(i)

Selection.SetRange Selection.Start - Len(strChoise(i)), Selection.End

Application.Selection.CreateAutoTextEntry(Name:=strChoise(i),
StyleName:=strStyleName)

Selection.Range.Delete unit:=wdCharacter, Count:=Len(strChoise(i)) - 1
Selection.Range.Collapse wdCollapseEnd
Selection.Font.Italic = False
Next i

End Sub

wish be helpful

 

[Chuck]

Hi J

I'm afraid I don't understand your reply. The fact that automacros don't
necessarily work with documents that weren't created based on the templates
they're contained in is a fact (as far as I know, and according to MS) and
not something I have any control over. In any case the solution we've
implemented (providing users with their own autotext.dot add in templates)
seems to solve the problem without using normal.dot for anything other than
certain automacros that *must* load for every user. As for the third
paragraph in your post we're not getting "bad behaviour" that needs fixing,
etc -- this thread was originally about transferring autotext entries after
all.

At this point I have to say I think you and Jean Guy are making assumptions,
and passing judgements, about how we're doing things without having all the
facts. For various reasons -- including confidentiality, lack of time and
irrelevance -- I haven't gone into extensive detail about what we do and how
we do it. While I appreciate helpful suggestions, I don't think it's helpful
for you to suggest that we haven't thought something through well enough
(without being informed about our decision making process) or to make global
statements about how we're creating problems to solve problems and not
properly addressing basic IT functions such as providing services to users
with as little hassle as possible. On the contrary, we're actually doing
quite well in that regard.

Thank you for your feedback anyway.

Chuck

 

[Chuck]

Hi

Thanks for the suggestion. I've tried running the code you provided but
haven't had any luck. Could you give me an idea of how you'd call it? I
notice that the macro requires parameters -- how would you supply them at run
time?

Chuck

 

[lishaowen23]

Hi,Chuck
What i mean is like that:
In the subroutine"CreateEntrIes",the first para is the Style name in which
all the Autotextentries you will add belong to. i.e,on the "solucation style"
,there are a lot of autotextentries,like "Mr.""Mrs",et al. The secand para is
the AutoTextentries's name,just like "Mr""Mrs".we can put all this in a
string array.i.e strArray(0)="Mr".strArray(1)="Mrs"....But before you add
them, you must get their value in selection.range way,otherwise they will
show only their name of Autotextentry,but has not value.so you must type them
first,and then select them in range.
You can trigger this sub in any event,i.e,a button command click.After you
run this sub,you will get all the autotextentries you want.Just open the word
,and click tools>autotextentries commandbars,you will see them all lie in
there.

 

[Chuck]

Hi Lisa

I'm afraid I'm still confused by your code. It's not clear how the
parameters it requires would be supplied; also it relies on selections so I'm
not clear on how it would grab the existing autotext entries from a template
(eg normal.dot). Also there appears to be an error in one of the lines:

Application.Selection.CreateAutoTextEntry(Name:=strChoise(i),
StyleName:=strStyleName)

should be

Application.Selection.CreateAutoTextEntry Name:=strChoise(i),
StyleName:=strStyleName

(no brackets after "CreateAutoTextEntry")

Have you actually run this code? If so how do you supply the parameters and
how do you "select" the autotext entries in the source template?

Thanks ...

Chuck

 

[lishaowen23]

hi,chuck
I'm sorry about the mistake of more brackets after
"CreateAutoTextEntry".what i do is nothing to do with "normal.dot",but add
all the entries you want before you open a new document. For example,if you
wish to use new entries such like a group of entries"A1","A2","A3" which
belong to a Style named "A-group",when you open a new document,you can first
run the sub to add all entries above.and then you will find the entries you
want is in your autotextentry now.