>>Hi David,
>>>No, haven't had a chance yet. But it looks good.
>>Yup, I'ld like to add it to my "best practices" and sure could use
>>testing with probably totally different apps/scenarios.
>>
>>>Our big conversion job from 2.6 is almost complete.
>>I already deployed... We should compare notes/techniques sometime.
>>
>>regards,
>>
>>thomas
>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.