>>We're in testing now. We have employed toolbars in the converted app but having some minor problems. For example if a user is in a date field and enters an invalid date like '33/33/04' and clicks the toolbar BEFORE exiting the field the print job goes ahead on the old data. How can I generically trap such problems where VFP intervenes prior to the valid() event. My toolbar triggers a "writebuffer" call which does a valid or setfocus on the activecontrol, but valid returns .t. because VFP has already restored the original value. I can't see a way around it because VFP (and FPW2.6) replaces the users value with the original value BEFORE ANY other code is run.
>
>If I remember this trick correctly, your toolbar button should check for _screen.activeform, and _screen.activeform.activecontrol - and if they're not both null, try to control.setfocus(). When the control receives focus, the previous controls (which is this same control - that's why I say this is a trick) tries to lose focus, and its valid() and lostfocus() should fire.
>
>Haven't tried this for a long time, really. My toolbars only launch other forms, and when a new form is launched, it takes the focus - so the last control on the first one loses it, and any validation there gets triggered, so I didn't have this problem at all.


We use the setfocus() technique already, but as I said VFP will replace an invalid date like {33/33/03} with the previous value without any event or code being fired/run at all.