Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

codeblocks configuration not saved

<< < (2/2)

dje:
I have the same problem in my ThreadSearch plugin; the logger is deleted in the call to

--- Code: ---CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
 evt.pWindow = m_pListLog->GetWindow();
--- End code ---

The debugger code makes a
--- Code: ---m_pLog = 0;
--- End code ---
just after.
I am working on a workaround that should work tonight if you need to keep your graphical widget when removing the logger.

Dje

killerbot:

--- Quote from: jens on December 01, 2007, 09:22:01 pm ---With this patch the segfault when closing codeblocks goes away:


--- Code: ------ codeblocks-1.0svn.orig/src/plugins/todo/todolist.cpp        2007-11-28 06:16:23.000000000 +0100
+++ codeblocks-1.0svn.work/src/plugins/todo/todolist.cpp        2007-12-01 21:17:28.000000000 +0100
@@ -142,7 +142,7 @@
         CodeBlocksDockEvent evt(cbEVT_REMOVE_DOCK_WINDOW);
         evt.pWindow = m_pListLog->GetWindow();
         Manager::Get()->ProcessEvent(evt);
-        delete m_pListLog;
+//        delete m_pListLog;
     }
     else
     {

--- End code ---

--- End quote ---

Yes, I can confirm this. That ugly crash is gone now. Confirmed on 2 windows CB equipped machines.

nothing:

--- Quote from: killerbot on December 02, 2007, 02:53:02 pm ---

--- Quote from: jens on December 01, 2007, 09:22:01 pm ---
With this patch the segfault when closing codeblocks goes away:

--- End quote ---

Yes, I can confirm this. That ugly crash is gone now. Confirmed on 2 windows CB equipped machines.

--- End quote ---

me too, it work! thanks a lot, im falling in love for CB

thomas:

--- Quote ---I am working on a workaround that should work tonight if you need to keep your graphical widget when removing the logger.
--- End quote ---
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:

--- Quote ---SetLog() transfers ownership of the Logger object to the LogManager.
--- End quote ---
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.

dje:
There won't be any workaround.
In fact, all the changes are made on the fly and don't depend on loading/unloading of the plugin.
All is detailed in the other thread

Dje

Navigation

[0] Message Index

[*] Previous page