FOX uses the FXMetaClass data type internally for things like deserialization of objects from streams, message routing and run-time type information. Every FOX class derived from FXObject has an associated FXMetaClass instance that is shared by all objects of that class (i.e. it is a static member of that C++ class).

In previous versions of FOX, FXMetaClass was a simple struct, and the shared FXMetaClass instance for each class was "registered" with FOX using a global C++ constructor buried inside the FXIMPLEMENT macro. David Heath recently noted a problem with this approach that arises when you're trying to dynamically load new FOX-based classes from a shared library at runtime (i.e. as part of a "plug-in" architecture). The first time a plugin was loaded, the metaclass information stored inside it was registered properly, but when that plugin was unloaded the metaclasses weren't "unregistered" by FOX. On subsequent re-loads of the plugin, the plugin classes' metaclasses weren't re-registered properly (since they were never unregistered).

This problem has been corrected, and the metaclasses for FOX classes should now be registered and unregistered properly, even when the code is loaded dynamically from a shared library.