>Usually when that happens there is still something holding open the file. Is it possible there's another instance of FoxPro running somewhere that has this file loaded or open in the edior? Check in Task Manager.
>
>I've run into locking issues like this myself, but usually it clears up based on a lock from some other location.
>
>I've also had an interesting issue recently where FoxPro somehow managed to create multiple instances of the same class in the same VCX file. Saving would sometimes work, sometimes not as saves would write to various random versions in the file.
>
>The whole VCX/SCX system was a cruel joke by the FoxPro team on us :-) So many possibilities for corruption not to mention all the bloody hassles related to managing source control. But for visual components unfortunately there's no other choice.

Too late now, but the whole thing could have been held in .prg files and built into a table or some other in-memory structure every time, then the changes written back into a freshly generated .prg when done. Fox2Bin style.

But back then that would have been slow, so the compiled code is held as a binary inside that .xcx table, COM references as well, even the decision to use foxels vs pixels is held in its own memo. Just looking at all those Reservedx fields reveals a kludge... which in the end worked with so much more speed and power than anything else that was offered.

And then there's the time lost on useless features, like general fields or formsets... which could have been used to develop this. Eh, even when you have foresight, you don't have the time to apply it to everything.