H
Hans
This seems to be a serious bug with potential damage to a lot of Add-Ins. To
reproduce it,
1.. Start Word, click the Office button, then Word Options. Highlight the
contents of the "User name" text box and hit the space bar, then OK.
2.. Open the Visula-Basic editor and type in the following lines of code
Sub Test_Options()
Options.ReplaceSelection = True
End Sub
[See below for a long list of other Options.[.] properties affected!]
3.. Run the above macro.
Word will throw a "Run-time error 4120 Bad parameter". If you run the line
from a password protected project, the error number will be 24 instead of
4120.
The problem is reproducible with Word 2007 both on Windows XP or Vista -
though we have in fact user reports only for XP.
An invalid entry is either entirely empty or consists of one or more blank
spaces only. (There may be more kinds of invalid entries.) Occurrence of
entirely empty "User name" entries could neither be confirmed or negated in
a reliable way. Our reliable user reports all had a single blank space
there, other reports were not clear on the exact contents of the "User name"
field.
The question is: How on earth can you come up with an invalid entry like
this in the first place? Well, at least six of our customers did. In one
case, half of the machines in a school's computer lab were affected. So
chances can't be negligible.
Normally, an Office "User name" is defined when one first uses Word (or some
other office application) on a given Windows user account. A dialog with two
text boxes, "User name" and "Initials", is then presented to the user. The
"User name" text box is pre-filled in with the name of the current Windows
user account and the Initials field is constructed from this name. You can
correct or complete the entries or leave them as they are. Contents of the
"User name" text box are highlighted, when the dialog opens. So, if you just
hit the space bar and then OK, you end up with an invalid Office "User name"
as described above. It is not possible to create a totally empty "User name"
field, though. If you try, the "User name" entry in Options goes back to the
user account name after OK.
I don't think, users are careless enough to enter a blank space in the
"User name" field and confirm that with OK. My hypothesis is, that certain
ways in which some OEMs set up the main User account in Windows and then
complete the Office installation are the underlying root of this problem.
I see some evidence for this conclusion in a) different naming restrictions
for a Windows user account and an Office user name, and b) in different
naming restrictions for the Office user name via Word Options text box and
via Word VBA. There is even a difference between Word VBA and Excel VBA.
Excel VBA does not complain about a "User name" consisting of a blank space
only, and the code line Application.Username = " " (blank space) in Excel
VBA will NOT throw an error but simply change the "User name" to a blank
space.
Of great importance for Word programming and patching: Once there is an
invalid entry like that in the "User name" field, there's no reliable and
user friendly way to correct it via VBA!
With an invalid entry there, Application.Username in Word VBA will throw an
error when attempting to read or write the value.
Similar things will happen if you try to use
Dialogs(wdDialogToolsOptionsUserInfo) for a work-around. The dialog will not
even show on Dialogs(.).Display or .Show and will throw an error on
Dialogs(.).Execute. You can actually read and write the .Name property of
the Dialog and this way work around the problem. But to do this in a user
friendly manner is rather complicated and not very reliable, because no one
knows a) if there are other ways to end up with an invalid entry, and b)
what effects it will have should Microsoft finally come up with a patch. So
I tend to write an error handler that finally asks the user to repair the
Office Username manually instead of trying to show the Word Options area by
code and pre-fill in the "User name" textbox with a valid entry, e.g. the
Windows user account name. Provided the Windows user account name is in fact
valid in the sense of Word VBA. (I actually have the code to do that, but
don't think I'll use it.)
Discussion and suggestions for the best work-around are welcome, of course.
What follows is a long list of Word VBA commands affected by an invalid
username, i.e. throw an error 24 or 4120. I compiled this list from various
contributions to the newsgroup microsoft.public.word.vba.general by Dmitri
Karpov, MikeG, Mary Mc, jalanford, Perry, and my own observations. The
crucial hint about the user name as causation for all the trouble came from
JimmyHoffa.
Here's the list:
Dialogs(wdDialogToolsOptionsUserInfo).Show or .Display will not throw an
error but do nothing at all.
Dialogs(wdDialogToolsOptionsUserInfo).Execute -> error
Application.Username (on read or write attempt) -> error
Trying to read the following Options settings will work, but trying to set
them will produce the run-time error (I don't know if the value part to the
right of the "=" operator really matters - at least for some it doesn't):
With Options
.AllowDragAndDrop = True
.AutoWordSelection = False
.PictureEditor = "Microsoft Office Word"
.Overtype = False
.CtrlClickHyperlinkToOpen = True
.AutorKeyboardSwitching = False
.PictureWrapType = wdWrapMergeInline
.DisplayPasteOptions = True
.PromptUpdateStyle = False
.FormatScanning = False
.ShowFormatError = False
.SmartParaSelection = False
.SmartCursoring = False
.UpdateFieldsAtPrint = True
.UpdateLinksAtPrint = False
.DefaultTray = "Use printer settings"
.PrintBackground = True
.PrintProperties = True
.PrintFieldCodes = True
.PrintComments = True
.PrintHiddenText = True
.PrintDrawingObjects = True
.PrintDraft = False
.PrintReverse = False
.MapPaperSize = True
End With
The following lines work and do not produce an error:
Dialogs(wdDialogToolsOptionsUserInfo).Name
With Options
.INSKeyForPaste = False
.PasteSmartCutPaste = False
.AllowAccentedUppercase = False
.TabIndentKey = False
End With
Regards, Hans
reproduce it,
1.. Start Word, click the Office button, then Word Options. Highlight the
contents of the "User name" text box and hit the space bar, then OK.
2.. Open the Visula-Basic editor and type in the following lines of code
Sub Test_Options()
Options.ReplaceSelection = True
End Sub
[See below for a long list of other Options.[.] properties affected!]
3.. Run the above macro.
Word will throw a "Run-time error 4120 Bad parameter". If you run the line
from a password protected project, the error number will be 24 instead of
4120.
The problem is reproducible with Word 2007 both on Windows XP or Vista -
though we have in fact user reports only for XP.
An invalid entry is either entirely empty or consists of one or more blank
spaces only. (There may be more kinds of invalid entries.) Occurrence of
entirely empty "User name" entries could neither be confirmed or negated in
a reliable way. Our reliable user reports all had a single blank space
there, other reports were not clear on the exact contents of the "User name"
field.
The question is: How on earth can you come up with an invalid entry like
this in the first place? Well, at least six of our customers did. In one
case, half of the machines in a school's computer lab were affected. So
chances can't be negligible.
Normally, an Office "User name" is defined when one first uses Word (or some
other office application) on a given Windows user account. A dialog with two
text boxes, "User name" and "Initials", is then presented to the user. The
"User name" text box is pre-filled in with the name of the current Windows
user account and the Initials field is constructed from this name. You can
correct or complete the entries or leave them as they are. Contents of the
"User name" text box are highlighted, when the dialog opens. So, if you just
hit the space bar and then OK, you end up with an invalid Office "User name"
as described above. It is not possible to create a totally empty "User name"
field, though. If you try, the "User name" entry in Options goes back to the
user account name after OK.
I don't think, users are careless enough to enter a blank space in the
"User name" field and confirm that with OK. My hypothesis is, that certain
ways in which some OEMs set up the main User account in Windows and then
complete the Office installation are the underlying root of this problem.
I see some evidence for this conclusion in a) different naming restrictions
for a Windows user account and an Office user name, and b) in different
naming restrictions for the Office user name via Word Options text box and
via Word VBA. There is even a difference between Word VBA and Excel VBA.
Excel VBA does not complain about a "User name" consisting of a blank space
only, and the code line Application.Username = " " (blank space) in Excel
VBA will NOT throw an error but simply change the "User name" to a blank
space.
Of great importance for Word programming and patching: Once there is an
invalid entry like that in the "User name" field, there's no reliable and
user friendly way to correct it via VBA!
With an invalid entry there, Application.Username in Word VBA will throw an
error when attempting to read or write the value.
Similar things will happen if you try to use
Dialogs(wdDialogToolsOptionsUserInfo) for a work-around. The dialog will not
even show on Dialogs(.).Display or .Show and will throw an error on
Dialogs(.).Execute. You can actually read and write the .Name property of
the Dialog and this way work around the problem. But to do this in a user
friendly manner is rather complicated and not very reliable, because no one
knows a) if there are other ways to end up with an invalid entry, and b)
what effects it will have should Microsoft finally come up with a patch. So
I tend to write an error handler that finally asks the user to repair the
Office Username manually instead of trying to show the Word Options area by
code and pre-fill in the "User name" textbox with a valid entry, e.g. the
Windows user account name. Provided the Windows user account name is in fact
valid in the sense of Word VBA. (I actually have the code to do that, but
don't think I'll use it.)
Discussion and suggestions for the best work-around are welcome, of course.
What follows is a long list of Word VBA commands affected by an invalid
username, i.e. throw an error 24 or 4120. I compiled this list from various
contributions to the newsgroup microsoft.public.word.vba.general by Dmitri
Karpov, MikeG, Mary Mc, jalanford, Perry, and my own observations. The
crucial hint about the user name as causation for all the trouble came from
JimmyHoffa.
Here's the list:
Dialogs(wdDialogToolsOptionsUserInfo).Show or .Display will not throw an
error but do nothing at all.
Dialogs(wdDialogToolsOptionsUserInfo).Execute -> error
Application.Username (on read or write attempt) -> error
Trying to read the following Options settings will work, but trying to set
them will produce the run-time error (I don't know if the value part to the
right of the "=" operator really matters - at least for some it doesn't):
With Options
.AllowDragAndDrop = True
.AutoWordSelection = False
.PictureEditor = "Microsoft Office Word"
.Overtype = False
.CtrlClickHyperlinkToOpen = True
.AutorKeyboardSwitching = False
.PictureWrapType = wdWrapMergeInline
.DisplayPasteOptions = True
.PromptUpdateStyle = False
.FormatScanning = False
.ShowFormatError = False
.SmartParaSelection = False
.SmartCursoring = False
.UpdateFieldsAtPrint = True
.UpdateLinksAtPrint = False
.DefaultTray = "Use printer settings"
.PrintBackground = True
.PrintProperties = True
.PrintFieldCodes = True
.PrintComments = True
.PrintHiddenText = True
.PrintDrawingObjects = True
.PrintDraft = False
.PrintReverse = False
.MapPaperSize = True
End With
The following lines work and do not produce an error:
Dialogs(wdDialogToolsOptionsUserInfo).Name
With Options
.INSKeyForPaste = False
.PasteSmartCutPaste = False
.AllowAccentedUppercase = False
.TabIndentKey = False
End With
Regards, Hans