>>>>
>>>>I wondered why you still use _CUROBJ, READ, etc. in VFP environment. The only reason of this might be that you converted some bulky application from 2.x. Anyway, you can switch to VFP ways. I don't know what is particular problem, but normally VFP looks for active control by using Form.ActiveControl property.
>>>
>>>We are converting a rather large app from 2.6 to VFP. The app is well over 100,000 lines of code and there are only 2 of us working on it so, we have new code running along side old code. We still have to keep releasing the software to our customers, so I can't just take 6 months to completely convert it. So I have to keep up the old code too. I really need to get this working ASAP.
>>
>>Unfortunately, I cannot help much about Fox2x. It's my assumption that keeping old and new programming styles together you will just lengthen time needed to get application on track.
>
>
>Believe me, I would love to take all the necessary time to convert the app, but unfortunately I can't. Anybody else got any ideas?

Joe,

At least in FoxPro 2.6 _CUROBJ indeed works in funny ways. (Don't use VFP yet).

For example, if you are in the valid of a field and change _CUROBJ (for example you might say _CUROBJ = OBJNUM(m.lcAddr)), the value of _CUROBJ does not change immediately! It only changes after you return from the valid. You can confirm this with the Debug window.

I don't remember other cases where _CUROBJ acts funny.

Alex