I will look closer at that article. I did not see any VBA my first time
through.
We have a fairly large Word application - about 60 templates and thousands
of lines of code - that control the editing, storage, history, format,
dispersion and just about anything you can think of for legal documents.
Every (EVERY) keystroke is evaluated. Every word, paragraph, section,
subsection... is stored in SQL.
The situation for using the old bluescreen was to indicate debugging or
development mode. When one of us programmers or one of the techs need to do
a little end user debugging they use a password protected button to switch
all databases to development mode and allow overrule of most edit checks.
They would make a change to the document and then switch back to live mode
and the user would resume their work. The normal use of the application has
many documents opening and closing, so I need the "development indicator"
tied to Word and not to an open document.
The bluescreen switch did this perfectly.
This development mode is indicated in a registry key and read by an autoexec
template module so if Word is shutdown and restarted it will start in the
last mode.
I didn't say the article had VBA, just that the things it described
could be done in a macro.
This set of procedures, saved in each developer's Normal.dotm template
(or a global template stored in theWord Startup folder) and suitably
modified, should do something close to the old blue screen.
If you already have AutoOpen and/or AutoNew macros (or the equivalent
event handlers, Document_Open and Document_New in the ThisDocument
module), just add the call to ToggleBlueScreen to the existing code.
Each time the developer opens an existing document or creates a new
one, the ToggleBlueScreen procedure will be called. It reads the
registry key (modify this to read the same key used by your autoexec
macro, and interpret whatever values you're assigning to that key),
and then it calls one of the two private procedures to change the page
color.
The code assumes that the text in the documents is formatted with font
color = Automatic. When the background is set to blue (or any color
that's dark enough), the display text automatically switches from
black to white. This doesn't affect the font color stored in the
document or used for printing.
The fiddling with the .Saved property prevents the color change from
causing a spurious save prompt when a document is closed; but if the
document already had changes that needed saving, that won't be
dropped.
The ForceToggle procedure was mainly for me to see the effect easily.
For your setup, just add the just add the call to ToggleBlueScreen to
the existing code that lets the developers switch into and out of
debugging mode.
Sub AutoOpen()
ToggleBlueScreen
End Sub
Sub AutoNew()
ToggleBlueScreen
End Sub
Sub ToggleBlueScreen()
Dim regEntry As String
' modify as needed for your existing registry entry
regEntry = System.PrivateProfileString("", _
"HKEY_CURRENT_USER\Software\Microsoft\Office", _
"DebugMode")
If LCase(regEntry) = "true" Then
SetBlueScreen
Else
SetNormalScreen
End If
End Sub
Private Sub SetBlueScreen()
Dim oDoc As Document
Dim bWasClean As Boolean
For Each oDoc In Documents
With oDoc
bWasClean = .Saved
.Background.Fill.ForeColor.RGB = RGB(0, 0, 255)
.Background.Fill.Visible = msoTrue
.Saved = bWasClean
End With
Next oDoc
End Sub
Private Sub SetNormalScreen()
Dim oDoc As Document
Dim bWasClean As Boolean
For Each oDoc In Documents
With oDoc
bWasClean = .Saved
.Background.Fill.ForeColor.RGB = RGB(255, 255, 255)
.Background.Fill.Visible = msoTrue
.Saved = bWasClean
End With
Next oDoc
End Sub
Sub ForceToggle()
Dim regEntry As String
regEntry = System.PrivateProfileString("", _
"HKEY_CURRENT_USER\Software\Microsoft\Office", _
"DebugMode")
If LCase(regEntry) = "true" Then
System.PrivateProfileString("", _
"HKEY_CURRENT_USER\Software\Microsoft\Office", _
"DebugMode") = "false"
Else
System.PrivateProfileString("", _
"HKEY_CURRENT_USER\Software\Microsoft\Office", _
"DebugMode") = "true"
End If
ToggleBlueScreen
End Sub
