Public Variable not holding it's value

[Robert_L_Ross]

I've got a weird situation that I'm tring to handle.

I have a 'cover sheet' .dot that we want to use to gather information,
display it properly (some values as bar codes, etc.) then close. We do NOT
want our users to be able to save the document (it contains vital data) and
we want control over the printing. We initially tried using buttons to print
(so as to not allow the file to be sent to a .pdf, etc.) but the problem with
the document was we used buttons. After reading around the newsgroups here,
I figured that actually making a toolbar for the .dot was the best solution.

I'm trying to make this document be as unobtrusive as possible, so I want to
gather the status of the toolbars at document open, store them so when the
user closes the document, the toolbars they originally had open will reappear.

After reading around, here's what I came up with. In the Document, I have a
Public declare area:

'Set Public Variables for Default Toolbars
Public toolbarSTANDARD, ... toolbarWORD_COUNT, toolbarWORDART As String

(It's really long...can I use the underscore to make this easier to read?)

I then set all of those values to False every time the document is opened
(in case they try to open multiple instances):

Public Sub Document_New()

'Set Public Variables for Default Toolbars to False (Clear Previous Values)
toolbarSTANDARD = False
toolbarFORMATTING = False
....etc.

I then get the current status and assign it to my public variables:

'Set Opening Toolbar Status for all Default Toolbars
If CommandBars("STANDARD").Visible = True Then
toolbarSTANDARD = True
End If
If CommandBars("FORMATTING").Visible = True Then
toolbarFORMATTING = True
End If
....etc.

I display a quick test message to verify the values were captured:

msg = MsgBox("STANDARD = " & toolbarSTANDARD & Chr(13) & Chr(10) & _
"FORMATTING = " & toolbarFORMATTING & Chr(13) & Chr(10) & _
...etc.
"WORDART = " & toolbarWORDART, vbOKOnly, "Toolbar Status")

I then close the toolbars:

'Close Default Toolbars
With CommandBars("Standard")
.Visible = False
End With
With CommandBars("Formatting")
.Visible = False
End With
...etc.

I then run my code that gathers the data and populates the fields on my forms:


Application.Run ("NewSheet")

End Sub

Everything works great - Until I try to close the form.

I have a message to state my 'public' stored values:

Public Sub Document_Close()

msg = MsgBox("STANDARD = " & toolbarSTANDARD & Chr(13) & Chr(10) & _
"FORMATTING = " & toolbarFORMATTING & Chr(13) & Chr(10) & _
...etc.
"WORDART = " & toolbarWORDART, vbOKOnly, "Toolbar Status")

At this point, all fields show as empty.

If I can retain my values, the code would go on to restore the toolbars.

Can someone tell me where I'm going wrong? I'm guessing I'm somehow
clearing the public variables somewhere, but I can't figure out where I'm
doing it.

Thanks in advance guys!

 

[Jezebel]

Not easy to diagnose from the description you give. Doing any work in VBA
resets the project, which clears all variables. So if you're switching back
and forth between Word and VBA trying to test all this, that might itself be
the problem. Try saving the variables somewhere such as writing them as
document variables or to the registry.

Bear in mind that there's really nothing you can do to control saving and
printing, that isn't easily defeated; so it's worth asking whether there's
any point in what you're trying to do here.


Note that this form of declaration

Public toolbarSTANDARD, ... toolbarWORD_COUNT, toolbarWORDART As String

declares all your variables, apart from the last, as variants.

And this construction

If CommandBars("STANDARD").Visible = True Then
toolbarSTANDARD = True
End If

simplifies to

toolbarSTANDARD = CommandBars("STANDARD").Visible

 

[Robert_L_Ross]

Jezebel,

THX for replying. Let me address this in order:
1. I'm not switching back and forth. I change the code, save the .dot,
close it, then re-open it (so I don't have to worry about the resets).

2. I can't write anything to the registry - this is for my work, and our
TSS group doesn't allow anyone to fiddle with registry entries. I'm
wondering if I'm declaring them at the wrong place. When I hit Alt+F11, I
can see two spots I can put code (Microsoft Word Objects/ThisDocument and
Modules/NewMacros). I have the Public statement in the Microsoft Word
Objects/ThisDocument section, thinking this would make the variables apply
over the entire document. Is this maybe incorrect?

3. I don't really think I agree 100% with your statement about
printing/saving...if I can get this code to work, I elminate the Standard
toolbar and maybe even the Menu Bar (I already found code to intercept the
save and print commands in case I can't hide the Menu Bar)...I don't see any
other ways an 'average' user could kick off the print/save commands.

 

[Robert_L_Ross]

I answered my own question...when I moved the declare from the Microsoft Word
Objects/ThisDocument to the Modules/NewMacros, it worked!

 

[Jezebel]

3. I don't really think I agree 100% with your statement about
printing/saving...if I can get this code to work, I elminate the Standard
toolbar and maybe even the Menu Bar (I already found code to intercept the
save and print commands in case I can't hide the Menu Bar)...I don't see
any
other ways an 'average' user could kick off the print/save commands.

Amongst other methods --

Method 1: Go to Tools > Macro > Macros. Select 'Word Commands' from the
'Macros in' list. Select FilePrint/FileSave from the list.

Method 2: Right-click any toolbar. Select customise. Reset the menus and
toolbars, or retrieve the missing commands and put them anywhere.

Method 3: Disable macros so your code doesn't run in the first place.

Method 4: Switch to VBA and enter the commands in the immediate window.


To hope that your users remain ignorant of all these methods is just wishful
thinking. Users *hate it* when their apps behave differently, and are on the
whole seem prepared to do surprisingly sophisticated things about it.

 

[Robert_L_Ross]

Method 1: Remove the commands from the Menu Bar that you can use-
'Hide File Command
CommandBars("Menu Bar").Controls(1).Visible = False
...etc.

Method 2: Prevent customizing remaining toolbars-
CommandBars("Menu Bar").Protection = msoBarNoCustomize
CommandBars("Imaging").Protection = msoBarNoCustomize

Method 3: Disable Macros-
Haven't figured this one out.

Method 4: Remap Alt+11 and other shortcuts.

As for "Users *hate it* when their apps behave differently", that's too bad.
This document will have a person's SSN and other vital identity information
on it. I have to do everything in my power to make sure they can't save the
document or print it to a printer I don't authorize. We don't have USB ports
activated, we don't have CD burners, we don't have external e-mail - unless
they write down every piece of information, smuggle a camera phone in with
them or have a photographic memory, we've made it pretty hard. I'd rather
have them be frustrated for the 1 or 2 minutes they have my document open
than have to fire staff for leaving identity information on printers or on
their hard drives.

 

[Jezebel]

I sympathise with your objectives, but if security matters so much, Word is
the wrong product to be using. As I think you're already seeing, to disable
the functions you want to prevent users getting to, you have to switch off
large parts of Word's functionality, to the point that the whole app will be
effectively unusable.

Hiding the toolbars and using msoBarNoCustomize doesn't help: that doesn't
prevent the user creating a new toolbar and putting on it whatever commands
they want. Similarly hijacking the shortcuts (and you'd have to find the
user's own custom shortcuts also) is defeated simply by resetting them.

Users can also print the document by taking a screen shot, pasting that into
something else, and printing it. They can also save the document by using
ctrl-alt-delete and killing Word abruptly. Then restart Word: the document
will be recovered, with all the toolbars etc back to normal.

Do some research: a lot of organisations have faced (and solved) this
problem; and the solutions don't involve screwing around with Word's
functionality.