If you have several session of VFP active at one time, make sure that you don't open the same vcx, scx or project in more than one session. If you open one of these files more than once, you may easily end up with blank or corrupted files. This has been documented several times, but not by Microsoft.

>I've been largely sidestepping various issues by perhaps unnecessarily complicating things and cluttering memory by getting into the habit using *separate* sessions of VFP -- one for editing/compiling and another for running/debugging. If something goes wrong in the run/debug session, I can simply kill that process and not nose my place in the edit/debug session. I'm also in the habit of creating multiple shortcuts to VFP -- one set for each software product that I'm working on -- with each with its own CONFIG.FPW as well as separate resource file (basically keeping the build/run environments separated)-- mainly because I'm too lazy to use a simple SET DEFAULT TO command switch between directories for the different software projects (nor have I ever bothered to customize the VFP menus so that I can easily switch between software projects by making selection from the VFP system menu).
>
>I'd been doing similarly lame-brained overly-complicated and memory-hogging procedures back when working in FPD -- I was launching Windows 3.x to use as a task-switcher mostly because DOSSHELL seemed too slow to do a context switch for me (what I should've really done is upgrade the PC from 4MB to 16MB and install DesqView386, considering that I was running the PC with QEMM386 anyway).
>
>>That's why I said it may work. I've experienced times when it does and times when it doesn't.
>>
>>>It's like that when you use the Fix action, it is orphaning the object reference. In that case, Craig's suggestion might not work, or it might.