Yes, that is the key. If you don't clear the classlibs, you won't see it. There is alot of variability here, Garret, trust me. We just tried to reduce the code down to where we felt it would fail consistently when viewed by the UTI audience. The code you see is not representative of the way we code, but in order to eliminate our code as the reason, we had to reduce it to the base classes and find common ground.

Thanks for looking at it. I am not sure how to report this to Microsoft. Even though we are MS Partners, I have found it difficult to report problems in the past, so I felt exposing this problem at UTI would at least allow VFP developers to be aware and possibly elicit an MS response. Probably not, but at least I might save other developers from the sickening fate that is going to befall our 15 year old company when we tell our enterprise client and the other vendors involved in this major project that VFP v8 is off and so is all of the other things we promised (which we could have delivered...we have never failed!).

I will find a way around this, but my confidence in VFP 8 is gone. It's back to VFP 6 for us and more and more we are going to try and find ways to move all of our logic away from VFP, not because of this bug, but because of the way I see it being handled. VFP has always rocked, and that is why I cannot understand why it was billed as the most stable release ever. From my perspective, I figured it was VFP7 service pack 2, which meant rock on. My mistake, but the folks in Redmond should think before they make stability statements that could put others out of business. Don't get me wrong, I accept the responsibility for this disaster, however, can we not trust anything anymore?

SET RAMBLING OFF!

Cheers,
Bob