[Bob Kilmer]

If you set Cancel True in the Exit event handler, focus will return to the
control that generated the Exit event. From the user's point of view, focus
never leaves the control.

By "target field", do you mean where the focus will land next if Cancel is
not set to True? The Enter event will have to fire before you know that,
unless you monitor every mouse click and keypress and sort of "manhandle"
the focus.

I might suggest that you validate on the OK click event and save youself
some trouble, if that works for you. Another suggestion I have seen is to
use labels instead of textboxes. Move a textbox around from label to label
for user editing. You can make a label look like a textbox except it will
not be user editable. It will look to the user as if they are tabing around,
but it may be easier to control. (I have heard this suggested, not
implemented it myself, but it sounds doable.)

Bob Kilmer

"Mike NG" wrote in message
...
If I have a userform which looks something like

______________
TextBox1 |_____________|
TextBox2 |_____________|
TextBox3 |_____________|
TextBox4 |_____________|

OK Cancel

I want to run some field exit validation e.g. validating post code
formats, checking values are in a certain range - i.e. not candidates
for the _Change event

The event must run if the user uses the TAB key or the mouse to go to
another field - a field in error will display a msgbox and focus must be
sent back to the field in error, but not if the Cancel button is
*clicked*


The only way I can see focus being driven back to the field is if Cancel
is set to true within the _Exit event, but I can't work out how to
detect what the target field is going to be as a result of the _Exit
event, whilst still in the _Exit event

_Entry would seem like a logical place to call a common validation
routine, but SetFocus doesn't behave as expected


Any pointers would be greatly appreciated
--
Mike