No, there really isn't. I went so far as to trash the converted FPW2.6 form and started from scratch with a very simple form with only the valid code in it....same result.

I'm simply out of time on this one and *sigh* am going to have to open FPW2.6 to make the change, create another spr file and keep running in backward compatible mode...this is what my associate did quite a while ago, but I'm hoping to someday start turning it into VFP. Not today.

My thanks to all for your ideas. I'll entertain more ideas, but only if this thread is keeping you up nights worrying! ;-)


>Hmmm... Ok, then is there any code in any of the textbox's other methods? Could the cursor's return to the textbox be creating a loop?
>
>Alan
>
>>This.value should always be populated. At least for the sake of debugging, the program populates the memory variable before the form is instantiated. I can see the value of the variable within the textbox and the valid routine has been correctly evaluating the equation - if the statement evaluates to a valid number, then everything works fine. It's only when the evaluation creates an invalid value that there's a problem.
>>As for the on error routine, there is one, but I haven't seen it trip at all. I can put the debugger on, step through the code, and see the next time the valid code fires.....
>> Strangely, I have found that when I'm stuck in the field, I can sometimes press a bunch of keys (I haven't figured out rhyme or reason for which ones) and pop the valid routine up in the debugger again. Once, I actually saw it changed the value to a key that was typed and it let me out. More often, it just evaluates to the same value and returns me to the same state.
>>
>>One other thing: I changed the form to modeless and threw in a read events below the form call. Same results as far as the field is concerned....
>>
>>MAJOR frustration over a supposedly 1 hour "simple" fix!!!!
>>
>>
>>Thanks for the ideas - keep 'em coming
>>
>>
>>>Steve, what is the value of 'This.Value' when it's not populated? And is there an 'On Error' routine running? Also, if the value of the field is an empty date, I wonder if the fact that Date() - {} = 0 is causing a problem.
>>>
>>>Alan
>>>
>>>>I thought of that, too. Strictdate is set to 0 during the valid procedure. I can step through the procedure; it stops responding immediately after exit. The trace screen shows the prg line that calls the screen (do form xxxx), which I think is appropriate.
>>>>I can hit the cancel button in the trace window....otherwise, I can't use any keyboard strokes in the trace window either. I don't think there would be any strange on keys....
>>>>
>>>>
>>>>>Any set date commands in your app? if you put 'set step on' in the gotfocus of the text box or at the beginning of the valid event and verify the value of the textbox before you check it's integrity in your valid event, what is the format of the date entered? Is set strict date on?
>>>>>
>>>>>Tracy
>>>>>
>>>>>>I have a form which was just converted from FPW/2.6 to VFP 6. The modal form works fine, I've moved all code into the appropriate methods. However, one field freezes (or appears to freeze) if there is a condition that causes the valid to fail. the controlsource is a date memory variable. On this form, if the date is within the valid parameters upon exit, then the focus moves to the next control as expected. the form only dies when the following code is tripped.
>>>>>>
>>>>>>Here's the valid code:
>>>>>>

>>>>>>if date() - this.value > 365
>>>>>>     return .f.
>>>>>>endif
>>>>>>

>>>>>>
>>>>>>This works fine if I populate the variable, then run the form from the command line, so I assume there is some wierd setting this old app might be tripping.
>>>>>>
>>>>>>any ideas would be greatly appreciated!