Normal dot & Hyperlink Problems

Topic

New Reply

On Q1 only.

You might get this sympton if more than one user were accessing the one Normal.dot:
.If it’s on a user’s network drive, and that user were still on Word on another machine
.If there’s a phantom copy of Woird running on that machine (Check the Task Manager to see if there’s a Word.exe when Word is not visible)

Reply | Quote

Replies

This is a two-part post: One involves the normal.dot becoming read only and the other involving turning off (permanently!) the hyperlink feature in Word which is an annoyance to many users (if they want to insert hyperlink they can use Ctrl+K)
Q 1: Using WinNT vers 4.0, Word 2000 SR-1. We are customizing our firm & normal.dots to prepare for a rollout of Office2000 (Word, Excel & PowerPoint) to a test group.
One of the team working on the rollout has been testing the firm & normal dots. Suddenly her normal.dot has become read only. She has always been able to make changes to her normal and save it – now it is not allowed.
We know that we can do a save as and rename the normal “oldnormal.dot” then get a new one but because we are doing these customizations we would like to understand why this has suddenly occurred – especially if it may affect our rollout of Office 2000.
Q 2: We turned off the option under Tools, AutoCorrect for “internet and network paths with hyperlinks” – both in our firm and normal.dots (in both AutoFormat as You Type and AutoFormat tabs). We exit Word, reopen and the default is checked, that is, turned on again. Then we thought we’d delete the style ‘hyperlink’ but the option to do so was greyed out.
Can anyone help with these problems? We would like to have the appearance of our toolbars and behaviour of Word as close to perfect as possible (or as close as Mr. Gates will allow!)

Reply | Quote

On Q2:

You’ll want to turn the hyperlinking off using a line of VBA code in your AutoExec macro. I don’t have the syntax at my fingertips, but I know this setting won’t “stick” if you click the radio buttons in Tools, Autoformat.

I recommend you get the book “Writing Word Macros” for tips about making these changes. Pay particular attention to changing the initial state of Word by using AutoExec and AutoNew macro modules.

I’ll post the code for you tomorrow from the office.

V.

Reply | Quote

Thank you! I guess VBA is the only way – as it was not sticking by the usual methods. Thanks very much! for the offer to post the code – appreciate it!

Reply | Quote

P,

In your Afterexec module in Normal.dot, use something like this. You should already have some of these options set and note the line referring to Hyperlinks:False —

Set adoc = NormalTemplate.OpenAsDocument
With adoc
‘Tools, AutoCorrect, Autoformat As you Type Options
With Options
.AutoFormatAsYouTypeApplyHeadings = False
.AutoFormatAsYouTypeApplyBorders = True
.AutoFormatAsYouTypeApplyBulletedLists = False
.AutoFormatAsYouTypeApplyNumberedLists = False
.AutoFormatAsYouTypeApplyTables = True
.AutoFormatAsYouTypeReplaceQuotes = True
.AutoFormatAsYouTypeReplaceSymbols = True
.AutoFormatAsYouTypeReplaceOrdinals = True
.AutoFormatAsYouTypeReplacePlainTextEmphasis = True
.AutoFormatAsYouTypeReplaceHyperlinks = False
.AutoFormatAsYouTypeFormatListItemBeginning = False
.AutoFormatAsYouTypeDefineStyles = False
End With

Reply | Quote

Thanks “vswearingen” for responding and for remembering to post the code. I have passed it along to our network admin to see what he can come up with.

Reply | Quote

You might want to give serious consideration to leaving Normal.dot unmodified. Make your firm changes, defaults and standards in a global template. Any File>New document should ignore normal.dot and use a FirmNormal.dot

Several threads (over the years) in the VBA forum have addressed some of the horrors associated with manipulating the normal.dot file. Looks like you are just beginning, so now might be the time to look into it.

Reply | Quote

Kevin!
You’re scaring me! We have firm.dot and global.dot but modify the normal from time to time to reflect changes and push it out to users. For example all of the styles shipped with Word seem to be hard-coded for Arial. We made both our ‘dots’ Times New Roman and have ensured that all styles (headings 1-9) are consistent and are all TNR. We have had no problems for the last 1-2 years with our styles using Word97. Now we’re just going to Word2000 SR1. Can you give me an idea of what sort of trouble we should be looking out for? TIA

Reply | Quote

Here’s one scenario. The head honcho has just reorganised all his/her buttons. Someone else has just recorded a complex macr. It’s taken him 2 days to do it. Then a new normal.dot gets rolled out- whack! They’re all gone.

It happened to me.

You can alter styles and buttons from outside of Normal.dot- we have an add-in in the startup directory with an autoexec which adds a custom button if it doesn’t already exist, and which deletes routine tempdde if it does exist. All other user settings are left intact.

Reply | Quote

Yes, it gets complicated, but there are good methods to provide customization and preserve user modifications. Kevin, I will seriously look into leaving Normal.dot alone in my WD2K rollout. Any advice on a publication that will assist me?

For all — here is an illustration of what we are currently doing:

In a nutshell, we use different normal.dots for each country where we have offices to store macro modules, styles, numbering and other toolbars (about 800 macros in all), office specific settings, and one firm-wide WDglobal.dot to store our DMS integration and all our autotext (the firm has 11 offices).

Users may create new toolbars and modify existing. We train them to make new toolbars to replace existing if they want to customize. Then hide the existing ones. When we roll out new templates (user initiated through a batch file on the Start menu) the users must remember to backup their customizations with a macro that records every item type available in the Organizer that has been added by them. After running the Office Update batch file to replace both global templates (normal and custom) as well as the other custom templates used by our macros to create ltrs, faxes, memos, etc. the users are trained to either call the Help Desk or follow the cheat sheat to restore with the organizer any items they created that they want to keep.

The system isn’t too weighty (though the Global template is relatively huge) and download times are fairly brief because the autotext components in WDglobal.dot are used by the macros to fill the rest of the templates.

The Update batch file also restores integrity if things go kablooey for unknown reasons on the user’s desktop and none of the macros will run, which, fortunately doesn’t happen too often, but does happen.

Commercial products, such as Legal MacPac and Softwise Macro Suite, exist to do all this work for you. They are a bit costly and worth every penny. My firm has opted to create and maintain a proprietary macro suite. As its custodian ( !), I rely heavily on WOW to keep me up to date.

With a bit of planning, it all works out very well and we are able to provide a high level of durable user customization. Good luck to you — and if they’ll spring for it, buy a commercial macro suite!

Reply | Quote

We always back up the users normal.dot and that way if they have customizations we copy them over after whatever changes we are rolling out. We’ve done this before with great success.
However, “V”: Am interested in the fact you ask your users to back up the normal dot themselves via a macro. I will post back later – this sounds like a great idea and certainly makes for less work on our part.
TIA!
McGinty

Reply | Quote

P or Mc- what do I call you?

Getting users to restore from a backup might be OK on a smaller site.

We’re moving towards a completely automated solution because of the number of calls to the help desk, and the amount of time that is taking up.

At 3000 users (I think), it’s not a huge organisation, but enough to keep the help desk quite busy.

If your org is small enough that manual restores are a possibilities, then go for it.

Add-ins have provided a good solution for us, but they were not without problems.

We’ve gone for a solution with custom buttons being copied into normal.dot. I suspect there is a way for buttons to be available directly from the add-in, but I don’t know enough to know if that’s possible.

With add-ins, there is no more need to store any macros in normal.dot- that’s really nice. The add-in also provides for cleaning out of the old macros which we had previously provided- that’s also nice. And the help desk don’t have to provide help for those people who’ve lost custom settings.

But, as I said, it’s a solution for our site and our situation only.

I can post code if there’s anything which might help. That way, I can get my own code cleaned up!

Cheers

Reply | Quote

Hi Gary, we are currently 400+ users but will soon be about 2000+ users. Thanks for the offer of posting code. Will post back after Monday-Tuesday re reaction/feedback from users re our update to Office 2000. ‘McGinty’

Reply | Quote

Patrick,

I don’t have the code here. I’ll put it up when I can.

It’s nice to have a first name. You might want to put in in your profile

Geoff

Reply | Quote

I’m interested in the automated restore from normal backup solution also — will be looking for the code.

Thanks, V.

Reply | Quote

Hi V,

This is rough- I had to try to snip it out of the full code, and make it more understandable.

This assumes that the module exists in both the backup template and in Normal.dot. You would have to add more checking if that assumption were not correct.

Dim i As Integer
Dim strSourceNormal As String
Dim strSourceTemplate As String

Application.ScreenUpdating = False

Documents.Open FileName:="J:template97normalbak.dot", addtorecentfiles:=False

strSourceNormal = ""
strSourceTemplate = ""

' Get the string for GetSaveFields in Normal
For i = 1 To NormalTemplate.VBProject.VBComponents.Count
  If LCase$(NormalTemplate.VBProject.VBComponents(i).Name) = "getsavefields" Then
    strSourceNormal = _
      NormalTemplate.VBProject.VBComponents("GetSaveFields"). _
     CodeModule.Lines(1, 1000)
    Exit For
  End If
Next

' Get the string for GetSaveFields in Normal

For i = 1 To ActiveDocument.AttachedTemplate.VBProject.VBComponents.Count
  If LCase$(ActiveDocument.AttachedTemplate.VBProject.VBComponents(i).Name) = _
      "getsavefields" Then
    strSourceTemplate = _
       ActiveDocument.AttachedTemplate.VBProject.VBComponents("GetSaveFields"). _
       CodeModule.Lines(1, 1000)
    Exit For
  End If
Next

' Compare the two strings. If they differ, copy from the backup into NOrmal.dot
If strSourceTemplate  strSourceNormal Then
    
  Application.OrganizerDelete Source:=NormalTemplate.FullName, _
     Name:="GetSaveFields", Object:=wdOrganizerObjectProjectItems
  Application.OrganizerCopy Source:=ActiveDocument.FullName, _
      Destination:=NormalTemplate.FullName, _
      Name:="GetSaveFields", Object:=wdOrganizerObjectProjectItems
  ActiveDocument.Close savechanges:=False
  If Documents.Count = 0 Then
    Documents.Add
  End If
  NormalTemplate.Save
End If

Application.ScreenUpdating = True

Reply | Quote

Thanks. It’s generous of you to share. I’m on vacation until July 9, so won’t be able to work with this until then. I see how it can work and would like to add this functionality for WD2K rollout in September. Can’t wait to try it. Looks clean from home.

Thx. agn. V.

Reply | Quote

Patrick,

I’m putting up code in two pieces to make it a little clearer.

The first piece I’m putting in this post. Its function is to add a new custom button called “Forms”. It’s executed from the “Autonew” in the add-in, so gets executed every time Word is opened.

It first checks all the buttons in the existing normal.dot. If the button already exists, and there’s only one button, nothing happens. If two buttons exist, the second one gets deleted. If a button exists but is hidden, it’s displayed. If no button exists, one is added.

The second function is to manipulate code. I’ll post that later.

Dim blnChanged As Boolean
Dim blnAlreadyUpdated As Boolean

Dim cbc As CommandBarControl
Dim cbb As CommandBarButton
Dim cb As CommandBar
Dim blnFormsButtonFound As Boolean
Dim i As Integer

Application.ScreenUpdating = False
blnAlreadyUpdated = False

blnFormsButtonFound = False

For Each cb In Application.CommandBars
  If cb.Name = "Standard" _
  Or cb.Name = "Formatting" _
  Or cb.Visible Then
    For i = cb.Controls.Count To 1 Step -1
      Set cbc = cb.Controls(i)
      If cbc.Type = msoControlButton Then
  ' Check for a Forms button. If one does not exist, create it.
  ' If more than one exists. delete one.
  ' If one exists pointing to the old location, update it.
        Set cbb = cbc
  
        If LCase$(cbc.OnAction) = "forms.main" Then
  ' We've found a "Forms" button
          If blnFormsButtonFound Then
  ' Delete duplicate forms button
            blnChanged = True
            cbc.Delete
          Else
            Set cbb = cbc
            blnFormsButtonFound = True
            If Not cbc.Visible Then
  ' If we've found the button, but it's not visible, update it
              blnChanged = True
              cbc.Visible = True
            End If
          End If
        End If
        
      End If
    Next
  End If
Next

If Not blnFormsButtonFound Then
  blnChanged = True
' Add a button to the standard bar.
' If order is important, it's possible to add a "before" option
' in the following line
  Set cbb = CommandBars("Standard").Controls.Add(msoControlButton)
  cbb.Caption = "Forms"
  cbb.OnAction = "Forms.Main"
  cbb.TooltipText = "Forms"
  cbb.Style = msoButtonCaption
  cbb.BeginGroup = True
End If

If blnChanged Then
  NormalTemplate.Save
End If

Application.ScreenUpdating = True

Reply | Quote

Geoff,

>>. I suspect there is a way for buttons to be available directly from the add-in, but I don’t know enough to know if that’s possible

Yes, indeed!: write code that creates the toolbar and all it’s buttons in the addin. Code up a nice routine to put them where you want them or stack ’em, dock ’em, float ’em or what have you. Run that code to create the toolbar and save.

As soon as Word loads that addin, the buttons will find there place on the user’s toolbar estate. Though the toolbar is created specifically for that add-in, it is available from any document. That’s one of the nice things about global addins.

Still, the only deviation I’d recommend from Microsoft’s out-of-the box normal.dot is moving it to the LAN (in the user’s private folder via setting the User Template folder location) for easy backup. This technique seems to present no problems when a user logs in twice, too.

Reply | Quote

Sorry to scare you, Patrick. No need to worry if you have smooth sailing.

When I had rough going I posted my woes and Gary Frieder and others suggested I consider the approach I now preach.
And when I finally had my environment set up as suggested, the problems all but vanished. Normal was not getting corrupted.
And I can’t remember the last time I told some user to delete their normal and restart Word.

It just doesn’t happen anymore. I attribute this “success” to leaving the normal.dot alone.

But back in the days before I knew better, I took the same approach as you and many others: the firm font, styles,
toolbars, etc needed to be available to each user and since each user has a Normal.dot that holds all those things,
my Startup addin opened everybody’s normal, checked for the latest items, and updated if needed.

Besides the issue of my code not referencing the “right” normal.dot (there can be several for various reasons), these were some of the problems I found:

1) it was talking longer and longer for users to start Word as the testing and updating was growing
to include more and more items. Word loads one 1500K global firm addin a lot faster than it
can open and modify normal.dot. The global addin even adds addins on startup and when needed so we no longer get complaints about how slow Word starts.

2) The message “Normal.dot has changed. Do you want to save changes?” kept appearing even though the “Prompt to Save Normal” was never checked.

3) The enigmas. Weird footnote numbering problems, graphics “sent to foreground” would always revert to background.
If you keep normal on the C: drive and have multiple users, all sorts of weird things happen when normal is modified:
settings don’t take, settings say one thing but do another, subsequent changes (e.g. setting a font change to default) just don’t work.

4) Normal would always eventually get corrupted and have to be deleted.

To be sure, I still have code that sets options that are stored in Normal.dot. For example,

with options
  .AutoFormatAsYouTypeApplyHeadings = False
  .AutoFormatAsYouTypeApplyBorders = False
  .AutoFormatAsYouTypeApplyBulletedLists = False
  .AutoFormatAsYouTypeApplyNumberedLists = False
  .AutoFormatAsYouTypeApplyTables = False
  etc..
end with

These have never caused me any problems.

But that’s the extend of it. I used to have code that opened normal as a document to make certain changes; and I used the organizer to push styles and toolbars into Normal.

Now, even the New Document button creates a firmnormal not a normal document.

Anyway, enough from professor OnTu Long. Now back to your regular programming.

Reply | Quote

Geoff:
Bingo! “Couldn’t see the forest for the trees” as the saying goes. I had made changes on the test machine & forwarded the normal & firm dots to her! I’ll post back tomorrow to let you know the results.

Reply | Quote