Hi Dragan
All resolved perfectly...
Message #875045

>>>>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.
>
>Ummm... it looks like it's time to call Sherlock Holmes, i.e. event logging, to see what actually occurs. The setfocus() thingy should work, unless something else is triggered first and the controls start getting refreshed. But I can only spurt wild guesses here, haven't had such a case myself. It just sounds like an issue with the order in which things are being done, but I may be wrong... my hearing not being what it once was :).