I am working on a workaround that should work tonight if you need to keep your graphical widget when removing the logger.
That shouldn't be needed. When you unload a plugin, there is no reason to keep a GUI widget around.
When the plugin is loaded again, you can create a new object. Yiannis added a message which allows you to do just that.
Personally, I don't like it, because I think that this whole loading/unloading on the fly makes everything needlessly complicated and error-prone, and there is in my opinion nothing wrong if plugins (and their loggers) are only loaded at application startup. However, the functionality is there, and the message to add logs during runtime is there too and it works, so well... there's no real reason
not to use it.
Besides, a workaround to keep the graphical widget would only work accidentially because
PluginManager to time does not work properly. When
PluginManager "loads" a plugin, the plugin really has been loaded ages ago, and when it "unloads" a plugin, nothing is unloaded at all. Loading and unloading is about setting up a few functors properly, and unsetting them. It's quite complicated alltogether, for example the plugin object is created via a static global variable which you could call kind of a "factory template" (which is initialised at DLL load time). This is to make sure that there is a function that "knows" the proper type of the object to be created so it can be created/destroyed correctly (the application only knows the base class). The downside of this is, of course, that we have no real control about when something is created/destroyed, but a better implementation is a lot more complicated.
Anyway, if the load/unload functionality is ever implemented correctly, your "keep the GUI" workaround would mean to keep (and reference) an object that is inside a library which is no longer mapped to memory. I am quite sure this would crash and burn.
The problem of the above crash lies in improper API use (albeit in good intention), which could have been avoided by reading the comments in
logmanager.h:
SetLog() transfers ownership of the Logger object to the LogManager.
Why does it have to be like this? Simple: You can replace one
Logger with another
Logger at any time. In this case, output will be redirected to the new
Logger, and the old one will be deleted by the
LogManager.
For example, if you wanted to write an add-on which redirects the debug log to a file, you would only need a single line of code which adds a
FileLogger into the debug log's slot. The application (and the plugins) using the debug log would never know that anything has changed.
