before close event and form fields

[roundabout]

Hi everyone,

I don't know much about Word VBA, but here goes.

Someone has asked me to create a Word document with "form fields" but doesn't want the doc closing unless the end user has completed all (or the most important) form fields.

so.....

IF all relevant form fields completed then OK, allow the file to close,
but IF not all completed then the file is NOT to be closed and take you back to the missing form fields.

Does this make sense?

Anyone have any ideas or know if this is possible at all?

Many thanks

Lee

[matthewspatrick]

Lee,

In its wisdom, MS decided the ThisDocument object did not need a BeforeClose event. (There is a Close event, but as I understand it, you cannot use it to cancel the close.

Fortunately, the Application object does have a DocumentBeforeClose event, but there is a catch: you have to use a class module to trap the event. To do this, insert a class module in your doc's VBA project. Name it clsWordEventTrapper.

In that class module, paste this:


Public WithEvents appWord As Word.Application

Private Sub appWord_DocumentBeforeClose(ByVal Doc As Document, Cancel As Boolean)

'insert code here to do the validation

End Sub




In the ThisDocument module, put this code:


Dim X As New clsWordEventTrapper
Private Sub Document_Open()

Set X = Word.Application

End Sub


Patrick

[fumei]

Please be more explicit:
IF all relevant form fields completed then OK, allow the file to close,
but IF not all completed then the file is NOT to be closed and take you back to the missing form fields.Is is explicitly closingthe file that is significant? or is it saving the file?

If this is a formfield functioning document, my first question is: Is the document created from a template?

In any case, while you certainly can use a class module to trap BeforeClose, you can also simply trap Document_Close. For that matter, you can trap FileSave as well. Catching the error is actually easier than doing the proper error trap validation on the formfields.

That is, unless you are only trying to trap empty or missing formfields. Say it is a text formfield, is it important to trap it if it is blank (= ""), but not important to trap if it is gibberish (= "bakhdsl3")?

How many formfields are there?

[roundabout]

You're right. It probably is the 'Save' that is significant.

Lots of the form fields will be for free text (though there will be some for ages etc) relating to accident circumstances so I don't think it will be possible to stop the gibberish.

As for how many fields, Well I haven't designed the form yet but I guess there could be upwards of 50.

Cheers

Lee

[matthewspatrick]

Please be more explicit:Is is explicitly closingthe file that is significant? or is it saving the file?

In any case, while you certainly can use a class module to trap BeforeClose, you can also simply trap Document_Close. For that matter, you can trap FileSave as well. Catching the error is actually easier than doing the proper error trap validation on the formfields.


Gerry, good call on whether we are hitting the right event! BTW, I was under the impression that while we can trap Document_Close, we could not prevent the close from happening (and that to do that, we would have to implement a class module to catch the Application event). Is that incorrect? (On a scale of 1-10, 10 being "Word VBA development superhero", I rate myself a 3 :rotlaugh: )


You're right. It probably is the 'Save' that is significant.

Lots of the form fields will be for free text (though there will be some for ages etc) relating to accident circumstances so I don't think it will be possible to stop the gibberish.

As for how many fields, Well I haven't designed the form yet but I guess there could be upwards of 50.

With that many fields, I might be inclined to use UserForms to poll the user for info, and then dump the UserForm responses into a document. Gives the application a nice, Wizard-like feel, but more importantly vastly improves the control you have over the user's interaction with the survey.

Patrick

[roundabout]

Yeah. I've also started to think that a UserForm may well be a better option

[fumei]

1. With that many discrete pieces of user entry, I would recommend a userForm. Error trapping on a userForm is significantly better than within a document. It makes validation an essentially part of the process and damn well MAKES the user finish it correctly before it is done. Well, that is if you also trap Cancel.....

2. No, you CAN trap and closing a file to prevent it from being close. The following Subs fires BEFORE Document_Close and prevents it, in fact, from firing.

Sub DocClose()
Sub FileCloseOrExit() - this disables the use of Alt-F4, as in:Sub FileCloseOrExit()
Msgbox "Nah...I really don't like that key combination. Forget it."
End Sub


Sub FileClose()

Any of these can be used for content error trapping.

[fumei]

What I am saying is that if you use the above Subs, you can put what ever you want in Document_Close...don't matter. It will not reach it.

[matthewspatrick]

Thanks, Gerry.

General aside: I find MS's overall implementation of VBA for Word to be very half-posteriored, and its help documentation to be...not entirely helpful. (Which is a marked contrast to the Excel VBA help, which while not uniformly excellent, is usually at least very good.)

Patrick

[fumei]

Actually, I do not quite agree. I find Help - once you get past some oddness, to be very helpful. The problem is more the weirdness of the Word Object Model.

[matthewspatrick]

The problem is more the weirdness of the Word Object Model.

You're probably right there :rotlaugh:

Patrick

[fumei]

Mind you it is very true that initially Help is quite wonky. However, as you get to know more, it becomes much easier to extrapolate what they REALLY mean.

And if it wasn't for Intellisense, we would be up sh%t creek. One of the thing thaty drives me nuts is that for certain areas of the object model there IS no intellisense. OLEFormat.Object followed by a dot does not bring up anything from Intellisense....but there ARE properties...like for example OLEFormat.Object.Name.

Shrug...what can I say?