Moving to 8 will be good for your customers. I think I press the limitis a bit. The app has MDI forms. Changes to one form can affect any other "open" MDI form. I use a lot of ActiveX with generalized methods (for example, the nodeclick in a Treeview subclass is used by other controls to fire form events - and so on.

In many cases I may have a form, a PRG (procedure file for "that" form) and a DBF with the same name.

I usually get lucky and end up on the otherside of the module with everything working. I don't like being lucky - gives me a false sense of security.

Perhaps it's my coding standards. Maybe forms and PRGs and DBFs should have different names. Forms should be prefixed with with 'frm' and so on.

But move to eight - don't let my little blunders affect your efforts:)

>Terry,
>
>We are just about to convert over to 8 from 6. Are there other issues that are known? We are currently testing, but that never runs through every line of code and it would be great if we could search for specific problems.
>
>
>>What is the status (if any) of a VFP8 SP2. I am spending a lot of time inventing clever work arounds to prevent leaks in some of the more straight forward action methods.
>>
>>Example:

>>If VARTYPE(SoAndSo)=="O"
>>   SoAndSo.Value="New Value"
>>Endif

>>I just had an incident where VFP error manager told me SoAndSo "is not an object" at SoAndSo.Value="New Value" , even though VFP vetted the test (in the line before) as true!
>>
>>I will admit this much:
>>SoAndSo is a form name, as well as a PRG name and a DBF name!
>>
>>Should I go back to 6?