Replies

Jefferson,

Thanks for the URL to a interesting post.

JanB

Jefferson,

Thanks for the URL to a interesting post.

JanB

Hans,

If Porley likes the idea, I’ll do that. And thanks for spreadsheet URL !

JanB

Hans,

If Porley likes the idea, I’ll do that. And thanks for spreadsheet URL !

JanB

Hans, and Porley of course,

I found out something quite interesting. I’m experimenting with Office 2003 (Dutch version) a bit because we are considering upgrading from Office 97. In Word 97 VBA there is only 1 event on application level that you can use: DocumentChange. But in Word 2003 VBA there are a lot more. One of them is WindowSelectionChange and that gave me an idea.
I created a document with 2 sections, marked section 1 as protected and section 2 as unprotected and then protected the document for forms.
In a properly declared class module I put this code:

Public WithEvents wdApp As Word.Application

Private Sub WindowSelectionChange(ByVal Sel As Selection)
If Sel.Information(wdActiveEndSectionNumber) = 1 Then
ActiveDocument.Protect NoReset:=True, Type:=wdAllowOnlyFormFields
Else
ActiveDocument.Unprotect
End If
End Sub

If I click, or move the cursor with the arrow keys in the unprotected Section 2, then the whole document is unprotected. And clicking, or moving the cursor with the arrow keys into Section 1 protects the whole document again, disabling the possibility to enter tekst in that section…
I just found out, so I’m not sure of all the drawbacks and ramifications yet, but it sure has some perspective!

I don’t know of these extra events are already present in Word 2000 VBA, but I heard from a co-worker that there are more than 1 in Word XP. Because I dont have that version here, I cannot tell if this particular event is present and my code is working in Word XP.

JanB

Hans, and Porley of course,

I found out something quite interesting. I’m experimenting with Office 2003 (Dutch version) a bit because we are considering upgrading from Office 97. In Word 97 VBA there is only 1 event on application level that you can use: DocumentChange. But in Word 2003 VBA there are a lot more. One of them is WindowSelectionChange and that gave me an idea.
I created a document with 2 sections, marked section 1 as protected and section 2 as unprotected and then protected the document for forms.
In a properly declared class module I put this code:

Public WithEvents wdApp As Word.Application

Private Sub WindowSelectionChange(ByVal Sel As Selection)
If Sel.Information(wdActiveEndSectionNumber) = 1 Then
ActiveDocument.Protect NoReset:=True, Type:=wdAllowOnlyFormFields
Else
ActiveDocument.Unprotect
End If
End Sub

If I click, or move the cursor with the arrow keys in the unprotected Section 2, then the whole document is unprotected. And clicking, or moving the cursor with the arrow keys into Section 1 protects the whole document again, disabling the possibility to enter tekst in that section…
I just found out, so I’m not sure of all the drawbacks and ramifications yet, but it sure has some perspective!

I don’t know of these extra events are already present in Word 2000 VBA, but I heard from a co-worker that there are more than 1 in Word XP. Because I dont have that version here, I cannot tell if this particular event is present and my code is working in Word XP.

JanB

I think you discovered the single most frustrating thing for Word developers IMHO. It should be a consolation that there are millions of other developers all over the world that suffer with you… NOT!
If you really need the forms functionality – as we do – then there is really no alternativ I know of than to “hijack” all the relevant internal Word functions by writing your own Sub’s performing exactly the same task and storing those Sub’s in a add-in placed in the Word Startup folder. But even then there are quit a few drawbacks!

For your particular problem there may be a work-around. From what you write I understand that you know how to use the checkboxes from the Forms toolbar. You can accomplish almost the same functionality with the checkboxes from the Toolset toolbar (not quite sure about this name, had to translate it from my Dutch version…). The VBA Sub’s handling these checkboxes must reside in the ThisDocument module.
I have no personal experience with these checkboxes. But I have a few documents with a commandbutton to perform a certain task. And that works fine in a unprotected document. The only drawback in my case is that this commandbuttons (and other controls) are always printed – at least I haven’t discovered yet how to prevent that.. But if that is no problem for your situation then this could be something to experiment with.

Good luck
JanB

I think you discovered the single most frustrating thing for Word developers IMHO. It should be a consolation that there are millions of other developers all over the world that suffer with you… NOT!
If you really need the forms functionality – as we do – then there is really no alternativ I know of than to “hijack” all the relevant internal Word functions by writing your own Sub’s performing exactly the same task and storing those Sub’s in a add-in placed in the Word Startup folder. But even then there are quit a few drawbacks!

For your particular problem there may be a work-around. From what you write I understand that you know how to use the checkboxes from the Forms toolbar. You can accomplish almost the same functionality with the checkboxes from the Toolset toolbar (not quite sure about this name, had to translate it from my Dutch version…). The VBA Sub’s handling these checkboxes must reside in the ThisDocument module.
I have no personal experience with these checkboxes. But I have a few documents with a commandbutton to perform a certain task. And that works fine in a unprotected document. The only drawback in my case is that this commandbuttons (and other controls) are always printed – at least I haven’t discovered yet how to prevent that.. But if that is no problem for your situation then this could be something to experiment with.

Good luck
JanB

Hi Boyley,

Maybe you can use something along these lines:
1. Place the templates in separate subdirs for each department (Dept1; Dept2; etc.)
2. Write Sub DeptTemplates
3a. Place a button on the Toolbar that calls DeptTemplates (if you want to preserve the standard FileNew command)
or
3b. Rename Sub DeptTemplates to FileNew (if you want to “hijack” the standard FileNew command)

Public Sub DeptTemplates
Dim strOld As String
Dim strDept As String
strDept = InputBox(“Department name?”)
strOld = Options.DefaultFilePath(wdWorkgroupTemplatesPath)
Options.DefaultFilePath(wdWorkgroupTemplatesPath) = “” & strDept
Dialogs(wdDialogFileNew).Show
Options.DefaultFilePath(wdWorkgroupTemplatesPath) = strOld
End Sub

Ofcourse you can use a dialog panel with a drop-down list for the departments. Otherwise you have to put some code in this Sub to check wether the user input is in fact an existing department. If not you can put the Inputbox on the screen again, or revert to a default path.
The lines with strOld in them can be omitted, but I think it’s good practice to put things back to the state/value it had before my code changed it.

Hope this helps
JanB

Hi Boyley,

Maybe you can use something along these lines:
1. Place the templates in separate subdirs for each department (Dept1; Dept2; etc.)
2. Write Sub DeptTemplates
3a. Place a button on the Toolbar that calls DeptTemplates (if you want to preserve the standard FileNew command)
or
3b. Rename Sub DeptTemplates to FileNew (if you want to “hijack” the standard FileNew command)

Public Sub DeptTemplates
Dim strOld As String
Dim strDept As String
strDept = InputBox(“Department name?”)
strOld = Options.DefaultFilePath(wdWorkgroupTemplatesPath)
Options.DefaultFilePath(wdWorkgroupTemplatesPath) = “” & strDept
Dialogs(wdDialogFileNew).Show
Options.DefaultFilePath(wdWorkgroupTemplatesPath) = strOld
End Sub

Ofcourse you can use a dialog panel with a drop-down list for the departments. Otherwise you have to put some code in this Sub to check wether the user input is in fact an existing department. If not you can put the Inputbox on the screen again, or revert to a default path.
The lines with strOld in them can be omitted, but I think it’s good practice to put things back to the state/value it had before my code changed it.

Hope this helps
JanB

And, according to Woody, Office 2003 Professional has a full implementation of XML and that alone should be worth the upgrade.

JanB

And, according to Woody, Office 2003 Professional has a full implementation of XML and that alone should be worth the upgrade.

JanB

I typed that on the fly and did not check if there are any items in the pick list for the FileNew dialog.
Sorry that this is no solution for your particular issue. But look at the bright side: you learned something.
And I did too…!

JanB

I typed that on the fly and did not check if there are any items in the pick list for the FileNew dialog.
Sorry that this is no solution for your particular issue. But look at the bright side: you learned something.
And I did too…!

JanB

It is possible to set a specific tab as the default when opening a dialog:

Dialogs(wdDialogFileNew).DefaultTab = xxx

As soon as you type the “=” you get a pop-up list with all the possibilities. Unfortunately this list contains all tabs, not just the ones for the dialog you want (wdDialogFileNew in this case).

Hope this helps.

JanB