Hi Doru,

Internally, VFP maintains some sort of application session/context information. Each line of code that is executed is executed in the context of a particular application or not application at all. When VFP accesses a file, it first searches for a file with the same name in the current application. If it finds one, this is used, otherwise VFP searches the hard disk. Usually, before it accesses the application, it checks the internal caches which are not application specific. When resolving the class hierarchy in a VCX, these caches are not always used, but sometimes are.

What happens if you have classes with the same name in various applications is that an object does not always use the class from this application, rather one from another application if that class has been loaded before. This is especially hard to nail down in a real application, because you only get the error if you do certain actions in a specifc order. Since the other class operates in a different application, code that tries to load classes suddenly fail. Even worse, if those classes differ somehow, the debugger might only display trash in the trace window.

The so far most reliable solution I found is to base all classes in one application only on classes that are also stored in the application, give each class in each application a unique name and do not add dynamically objects from one application to an object from a different application. Or to keep all VCXes externally. You can use a tool like Cryptor to make it harder to decompile them in this case.

Christof