David,
I did a little playing around with this today. The routine I was testing was a Save() method that executes from a toolbar button click. The Save() method calls Valid() and LostFocus() internally, just in case the events were missed outside the method. The Valid() method merely verifies the entry against other fields in the current record and in other records in the table. The LostFocus() method makes some field changes, and calls Refresh() on each field that is changed, in an attempt to reflect the changes to the table cursor and the form. The flashing cursor is sitting at the end of the first editable text box, and a change was made to the field. Here are a few findings:

-- It does indeed make a difference whether you run the FoxPro debugger or the Frames debugger. Also, it makes a difference whether or not you set a breakpoint inside the routine called from the toolbar click.

-- If you're running the Frames debugger, and a breakpoint is NOT set, neither the Valid nor LostFocus methods fire before the Save method starts. If a breakpoint is set, however, both Valid() and LostFocus() fire before the Save() method starts. However, the field changes made in the LostFocus method are not reflected in the form, nor are they saved to the database. (In my tests, I could identify that both Valid and LostFocus were being called inside the Save method, just as they are coded. But even with that second call, the field changes are not reflected.)

-- If you're running the FoxPro debugger, the scenario is almost identical to above, except that the field changes made in the LostFocus method are reflected in the record ONLY IF A BREAKPOINT WAS SET IN THE SAVE() METHOD.

I've posted this question on the support conference for the application framework I'm using. Their lead developer spent all day working with this, and found different results when running 5.0, 5.0a and 5.0a with Service Pack 3 installed! Furthermore, although I haven't asked him about it, the impression I got from him was that the LostFocus method will never get called in the situation noted above, and any attempt to do so from within the routine is hopeless. For me, that makes for about a week's worth of coding in trying to pull all the relevent stuff out of LostFocus() and put it into Valid().

Any ideas where to go next with this?

Ed


>Ed,
>
>Do you have some code in the Form Activate, Deactivate methods? What if you seed DEBUGOUT commands instead of messagebox() to track what's going on? Does it make a difference if you are using the FoxPro or Debug frame for the debugger?
>
>>I appear to be having significant problems with VFP 5.0, Service Pack 3, having to do with the debugger. I can run my code and produce the expected results when I'm stepping through it with the debugger. However, I can run it without the debugger and find that some events (specifically InteractiveChange, Valid and LostFocus) do not appear to run. I say "do not appear" because it looks like the values are not what I expect in a text box as I run the application.
>>
>>What's even more strange is that I can add a MESSAGEBOX command somewhere in the LostFocus() method, which updates a number of other fields on the form before the object loses focus, and everything works fine. If MESSAGEBOX is in the method code, and I hit a button on a toolbar or menu item that saves the info in the form, the message box appears, the form on the screen appears current, and the record is saved. However, if I leave the MESSAGEBOX out and do the same test, the form doesn't reflect the record changes, nor does the saved record.
>>
>>Any ideas?
>>
>>Ed