Under some circumstances, an ActiveX DLL can pass private objects to its client application, for example a reference to a control that belongs to a form in the DLL. While this approach can be useful, and can work under some circumstances, you should absolutely avoid avoid to do so, because it might be the cause of subtle GPFs in production code.
The reason for such fatal errors is that a reference to a Private object doesn’t keep the DLL alive. In fact, COM can’t determine that the main application has a reference to an object in the DLL if the object is private, and releases the DLL if the application has explicitly or implicitly set to Nothing all the other references to (Public) objects defined in the DLL. When the application eventually uses the object variable (which is now pointing to a deallocated block of memory) the fatal error occurs.
Please note that such errors are really hard to find and debug, because VB typically helds an inactive ActiveX DLL in memory for about 10 minutes. Thus the bug can or cannot occurs, depending on whether the reference to the Private variable is used while the DLL is still in memory. Also note that the same rule applies to other types of in-process ActiveX components, such as a UserControl that directly exposes one of its constituent controls to the main application.While it is a good programming habit not to expose Private objects to the outside world, there is a safe technique for working around this problem: you just must ensure that the DLL is never released. This can be done by having a Public global variable that always points to a (Public) object in the DLL, and explicitly destroying all references to Private object before such global variable is automatically set to Nothing when the main client application terminates.
