New log manager since rev. 4606

[mandrav]

Hi all.

Revision 4606 brings you the new shiny LogManager to handle all logging needs. Say bye-bye to MessageManager .

The most important reason for this change was that it separates the logging from the GUI. If you want to add a logger to the GUI you explicitly do this by sending the (new) cbEVT_ADD_LOG_WINDOW message.

The functions you are used to already are present in the new system: Log(), DebugLog(), LogWarning(), LogError() and friends.
The major difference is that they accept two arguments: a wxString (the message to log) and a LogManager::level (the logging level).
If you want to format a string (like the old functions accepted), use the F function (keep keystrokes to a minimum ). Something like: Manager::Get()->GetLogManager()->Log(F(_T("%d"), 5));

All code in our repository (including contrib plugins) has been accordingly updated (hopefully without mistakes ). It's been tested for a couple of days and seems to work fine. Of course, if any problems pop up they will be dealt as appropriate.

The resume of the above is: everything is converted and works like it used to.
To learn more about the new system, see sdk_event.h for the new logging events, logmanager.h for the new manager, logger.h for the loggers interface and loggers.h/cpp for the implementation of the standard built-in loggers.

External plugin developers hopefully now know what to expect/fix when they update their working copy of Code::Blocks .
For any questions/suggestions, just come forth and ask.

[Howard]

Windows get the following compile errors:

mingw32-g++.exe: .objs\sdk\messagelog.o: No such file or directory
mingw32-g++.exe: .objs\sdk\messagemanager.o: No such file or directory
mingw32-g++.exe: .objs\sdk\simplelistlog.o: No such file or directory
mingw32-g++.exe: .objs\sdk\simpletextlog.o: No such file or directory
Process terminated with status 1 (3 minutes, 23 seconds)
0 errors, 0 warnings
 

[Jenna]

Windows get the following compile errors:

mingw32-g++.exe: .objs\sdk\messagelog.o: No such file or directory
mingw32-g++.exe: .objs\sdk\messagemanager.o: No such file or directory
mingw32-g++.exe: .objs\sdk\simplelistlog.o: No such file or directory
mingw32-g++.exe: .objs\sdk\simpletextlog.o: No such file or directory
Process terminated with status 1 (3 minutes, 23 seconds)
0 errors, 0 warnings
 

The according .cpp-files are missing from svn-tree.

[killerbot]

nonono; these were still in the windows cbp file, fixed now ;-)

[killerbot]

note on windows there are still other issues, our don is a linux guy ;-)

EDIT : working on fixing them ...
EDIT : while getting there, my linux build builds ok, but after showing the splash screen the story ends ...
EDIT : windows build fine now , but also crash  (in debugger.dll)

[mandrav]

nonono; these were still in the windows cbp file, fixed now

Ah, yes, I knew I forgot something .

[killerbot]

and debugger plug-in crash is also solved

[MortenMacFly]

Noticed a crash with he TODO plugin. If you enable to show the plugin in the message panel C::B will crash on startup.

BTW: I'm still in the progress of further removing any links to messagemanager e.g. inside commented code). Will commit possibly tomorrow. ;-)

With regards, Morten.

[Jan van den Borst]

In the old days warnings showed up blue and errors red in the Build messages and Build log tabs. This is not happening anymore in svn4616. Also the codeblocks config file (default.conf) is incompatible with older versions as the editor disappears in SVN 4616 and is only showed again after deleting the config file.

Jan

[killerbot]

In the old days warnings showed up blue and errors red in the Build messages and Build log tabs.

I can confirm this.
And I also have no longer the codeblocks app log in the messages panel at the bottom; though on linux it is still there.

@Thomas: I think your the guy who can solve this ;-)

In my case no editor disapeared but it have another strange thing, see here : http://forums.codeblocks.org/index.php?topic=7258.msg55406;topicseen#new

[stahta01]

Is there a replacement for simpletextlog.h/class SimpleTextLog?

Some plugins like SVNInside use it.

Tim S

[stahta01]

Noticed a crash with he TODO plugin. If you enable to show the plugin in the message panel C::B will crash on startup.

BTW: I'm still in the progress of further removing any links to messagemanager e.g. inside commented code). Will commit possibly tomorrow. ;-)

With regards, Morten.

I suggest looking at sdk/config-testsuite.cpp

Tim S

[mandrav]

In the old days warnings showed up blue and errors red in the Build messages and Build log tabs. This is not happening anymore in svn4616.

Strange, that's working fine here (linux).

Also the codeblocks config file (default.conf) is incompatible with older versions as the editor disappears in SVN 4616 and is only showed again after deleting the config file.

Jan

This can happen from time to time (when we do such a major change), but you don't have to delete your config file! Just "View->Layouts->Delete current" should be enough...

Is there a replacement for simpletextlog.h/class SimpleTextLog?

Some plugins like SVNInside use it.

Tim S

In loggers.h, among others you will find TextCtrlLogger.

[thomas]

In the old days warnings showed up blue and errors red in the Build messages and Build log tabs. This is not happening anymore in svn4616.

Strange, that's working fine here (linux).

Happens here too, though. I assume it is because you don't use the LogManger consequently in the compiler plugin. There is this one function that does some awful tampering with a lot of if()s and stuff to either log something or not, and to write out some HTML to a file.
Don't worry, though. That's easily fixed, and it's not a severe thing, either. I planned a small update to FileLogger anyway, can add a FileLogger that ouputs HTML too then, which should fix the problem. Just don't have time to do anything today, so will be tomorrow.

[MortenMacFly]

Noticed a crash with he TODO plugin. If you enable to show the plugin in the message panel C::B will crash on startup.

Very strange: Here at work it just works. No crash at all...?!

[thomas]

I'm afraid that I probably won't be able to fix this. I'm unable to follow the modifications to the original code and the reasoning behind them. Not only are there a lot of them, but since half of the code was moved to another file, I can't use diff or blame to see which lines were modified either, so that makes it tedious.

Some of the differences I found are:
SetupGUILogging() is now called before the plugins are loaded. Logger controls are no longer maintained by the application, but are created by hand, either by sending messages or even worse by calling CreateControl manually (see TODO plugin). The behaviour of that function has been changed too (don't know if that is a problem, but it's different).

Trying to find out where the debug log has gone, I went stepping in the debugger. CreateControl() on the Logger in slot 3 (debug log) returns a null pointer, which causes the application to (correctly) ignore it. I don't know why this happens, but apparently somewhere during startup, the TextContolLog is replaced with a NullLog?

[mandrav]

I'm afraid that I probably won't be able to fix this. I'm unable to follow the modifications to the original code and the reasoning behind them. Not only are there a lot of them, but since half of the code was moved to another file, I can't use diff or blame to see which lines were modified either, so that makes it tedious.

Code has not been changed.
And the move to a different file was done to avoid recompilation of the entire repository each time we want to add a comma or a space.

Some of the differences I found are:
SetupGUILogging() is now called before the plugins are loaded. Logger controls are no longer maintained by the application, but are created by hand, either by sending messages or even worse by calling CreateControl manually (see TODO plugin). The behaviour of that function has been changed too (don't know if that is a problem, but it's different).

SetupGUILogging moved there because in the place it was in the original code, no startup log was retained (logs were empty).
I don't understand "controls are not maintained by application". They are. But SDK messages were added so plugins can add/remove loggers at run time (in contrary to only being able to do this at init time).
Also, first step was to make everything compile properly. Old code will slowly be replaced by newer more compact code in time. So the single hack you noticed in todo list is not worth the mention.

Trying to find out where the debug log has gone, I went stepping in the debugger. CreateControl() on the Logger in slot 3 (debug log) returns a null pointer, which causes the application to (correctly) ignore it. I don't know why this happens, but apparently somewhere during startup, the TextContolLog is replaced with a NullLog?

I found out why, although I don't understand it.
Seems like Manager::Get()->GetLogManager() and LogManager::Get() return two different instances...
Specifically, in Mgr<MgrT>::Get(), a new instance is created the first time the two above calls are made (totalling 2 instances).

[thomas]

Code has not been changed.
And the move to a different file was done to avoid recompilation of the entire repository each time we want to add a comma or a space.

Code has been changed. I found an if(!control) and was sure that I had not put it there. Doing a manual compare with a revision a week old indeed showed that it wasn't there. Now, I don't know if it really matters, but it changes the behaviour of the function from "always create" to "create only if not exist". The reason why I had no such check in the original code was that it should remove one constraint (pay attention to not create duplicate objects) from people who contribute Loggers, and move that constraint into the application. Very likely it works the same now, but the behaviour is different.
I am aware why you moved the code from a header to a source file, and that is perfectly ok... but... since you did this together with some other changes, one cannot see what those changes were, other than by comparing line by line manually. svn diff doesn't show anything useful in that case.

I don't understand "controls are not maintained by application". They are. But SDK messages were added so plugins can add/remove loggers at run time (in contrary to only being able to do this at init time).

What I was saying was that now a dozen different components decide when they want to add a log, instead of this being decided by the application. There is no harm if this is only done by the application in my opinion.
The worst thing to happen is that a user won't have a log after manually loading a plugin until he starts the application for the next time (it will still work in every other respect). That "missing" log is a very minor issue (actually none at all) but it removes a huge deal of complexity and possible errors from the whole system, and makes it a lot easier to follow (for me, at least). But... never mind that.

Seems like Manager::Get()->GetLogManager() and LogManager::Get() return two different instances...
Specifically, in Mgr<MgrT>::Get(), a new instance is created the first time the two above calls are made

Oh, it's worse... it looks like that's the case with all managers, only so far nobody ever noticed
I don't know why it happens either, it should not be possible, but it is apparently the case.

[thomas]

This is an interesting problem.

We have
type* f() { return g(); };
and we have
f()  != g().

This is beyond my understanding of C++ (or mathematics, or anything). I don't see g() return anything but the exact same thing every time.

[mandrav]

This is an interesting problem.

We have
type* f() { return g(); };
and we have
f()  != g().

This is beyond my understanding of C++ (or mathematics, or anything). I don't see g() return anything but the exact same thing every time.

I know why, because it happened to me before (in a different project).
You see, you instantiate the template's "instance" variable in the template header. But this means that different compilation units will create different static vars (because templates are instantiated in the calling unit).

The solution is to remove the static vars instantiation from manager.h and move them in each manager's compilation unit (as template specializations):

Code: "from manager.h"

// remove those:

template<class MgrT>MgrT* Mgr<MgrT>::instance = 0;
template<class MgrT>bool  Mgr<MgrT>::isShutdown = false;

Code: "for example, top of logmanager.cpp"

template<> LogManager* Mgr<LogManager>::instance = 0;
template<>bool Mgr<LogManager>::isShutdown = false;

Doing this will make everything work as expected. You can try it, if you want .

[MortenMacFly]

Doing this will make everything work as expected. You can try it, if you want .

I can't believe it... Yiannis, you solved a major issue in a software I'm maintaining here at work. I had a singleton class as member variable inside another singleton class. The object got never initialised properly and I did an ugly hack to get it to work. But I was facing *exactly* that issue. You are the hero.
(Although it's really weired that nobody out there noticed this with all those millions of singleton template example code...)

[thomas]

Hmm... can we simply move the instance into a .cpp file (one)? If I understand the problem right, that should work.

[mandrav]

Hmm... can we simply move the instance into a .cpp file (one)? If I understand the problem right, that should work.

It probably would work, yes. But what would be the point? You 'd still have to #include all the managers there. So better to put each one in its own compilation unit (the appropriate manager's .cpp). It's just two lines of code.

I have already created the patch and sent it over to Morten for testing on windows. If all goes well, I 'll commit it.

[mandrav]

I have already created the patch and sent it over to Morten for testing on windows. If all goes well, I 'll commit it.

Tests were successful and changes committed .

[dje]

Hi all !

Feature request 3879 :
I need my log window to be removed from the logger without being destroyed.

In InfoPane class, we have:

Code

int InfoPane::AddLogger(Logger* logger, wxWindow* p, const wxString& title, wxBitmap* icon)
int InfoPane::AddNonLogger(wxWindow* p, const wxString& title, wxBitmap* icon)
bool InfoPane::DeleteLogger(Logger* l)
bool InfoPane::DeleteNonLogger(wxWindow* p)
bool InfoPane::RemoveNonLogger(wxWindow* p)

User benefit from the following events for adding/removing logs:

Code

EVT_ADD_LOG_WINDOW
EVT_REMOVE_LOG_WINDOW

I'd like:
- bool InfoPane::RemoveLogger(wxWindow* p) to be implemented
- the EVT_DELETE_LOG_WINDOW to be implemented
- the EVT_REMOVE_LOG_WINDOW event call InfoPane::RemoveLogger instead of InfoPane::DeleteLogger
- the EVT_DELETE_LOG_WINDOW event call InfoPane::DeleteLogger

I can do it if accepted.

Dje

[thomas]

If you want a function to hide a log tab, then this could be implemented in InfoPane, if you can give a good reason.
InfoPane does have a Show() member already to allow you to bring a tab into the foreground, if something crucial really has to be shown and put in the foreground (for example a critical error, or search results after a lengthy search). A Hide() member was deliberately omitted because it is generally not your decision what logs are shown, but the user's (selectable from the popup menu).

If you want to do word by word what you said ("my log window to be removed from the logger") then it gets complicated.
LogManager takes Loggers (with GUI or without), and owns them.
InfoPane asks (on behalf of LogManager) all Loggers to provide a GUI control (which they can do, or not). If a Logger does provide a control, InfoPane takes ownership and adds it to the notebook.
Giving up ownership on either of the two may be problematic, and I don't see a real urgent need for it.

You probably want this functionality for the ThreadSearch plugin, right? If so, then using a Logger is not the best solution anyway. You are not logging anything, so you shouldn't be using a Logger.

InfoPane has a function to add non-loggers to its tab list, too. This function takes anything derived from wxWindow, it does not require a Logger, nor does it own a Logger or install one into LogManager, nor does it delete one. That function was added to give the possibility to add something into the log area which actually does not belong there (as it is no log), but still belongs there somehow (as people are used to find it there).

[dje]

if you can give a good reason

Well, we'll have to discuss what makes a reason to be good  but:
Previous MessageManager worked like that.
No access to InfoPane is provided (and I think it's a better design choice).
I'd like to transfer ownership of my control from Messages notebook to the Layout on the fly. From a user point of view, I find very BORING the "Change will take place at next application start". And I find more pleasant being able to use Messages notebook or Layout management for the plugin without restarting the application.

That is why I need a removal without deletion.

You probably want this functionality for the ThreadSearch plugin, right? If so, then using a Logger is not the best solution anyway. You are not logging anything, so you shouldn't be using a Logger.

Yes, I need it for this plugin to keep the same behaviour. If it is not the right place for it, is it the place for the "Search results" tab ?
That's the same feature except there is a preview window and a non blocking search.

InfoPane has a function to add non-loggers to its tab list, too. This function takes anything derived from wxWindow, it does not require a Logger, nor does it own a Logger or install one into LogManager, nor does it delete one. That function was added to give the possibility to add something into the log area which actually does not belong there (as it is no log), but still belongs there somehow (as people are useNonLogger,d to find it there).

I saw it and I agree but no events exist to access it. And I would need a RemoveNonLogger, not a DeleteNonLogger call.
I tried to reparent my ThreadSearchView to avoid the parent window to destroy my wxWindow but as the wxWindow is referenced in a structure and an explicit Destroy is called, there is no workaround.

Nevertheless, I find that, in the present implementation, EVT_REMOVE_LOG_WINDOW is confusing.
That is reenforced by InfoPane implementation with its Remove and Delete methods.

Dje

[thomas]

No access to InfoPane is provided (and I think it's a better design choice).

There is no real access to InfoPane, at least not one that is to be used without good reason. The idea behind the new LogManager and the InfoPane is that LogManager runs regardless of any GUI capabilities (in fact, without any capabilitites at all, not even console I/O or file access). InfoPane is a GUI class that builds a bridge to a GUI, in this case the notebook window that we see on the bottom. If InfoPane isn't there, LogManager still works the same (as for example when doing a batch build). Thus, no special branches are needed for this, everything works the same.
I think this is a better design, but surely opinions can differ on that.

For you, LogManager, Logger, and anything related to them actually does not matter. You don't really log anything. Thus, whatever happens with Loggers really isn't so important, since you would really want to add a non-Logger.

And I find more pleasant being able to use Messages notebook or Layout management for the plugin without restarting the application.  That is why I need a removal without deletion.

That is no good reason. You should be using a non-Logger (even if you derive your panel from a Logger-subclass, you can still add it as non-Logger).

I saw it and I agree but no events exist to access it.

Yiannis probably just forgot to add those, since there are very few valid uses for them anyway. But... it's not like it isn't supported

And I would need a RemoveNonLogger, not a DeleteNonLogger call.

This exists.

[dje]

I totally agree on the fact I should use a non-logger but it is impossible for now as there no access  to the infopane (direct or events).
That's why I chose the logger way that makes me add useless code to comply with available interfaces.
Whatever (non)logger it is, it is systematically destroyed and that is my real problem.

I totally agree this evolution makes software design cleaner but something is broken or missing because i can not do any more what was possible.

Before, there was a mix between LogManager and MessagesManager.
First step is reached, the log part is OK.
Second step is partially reached because developer looses a lot of possibilities.

As there is a wxWindow* Logger::CreateControl method which is triggered for window creation, it could be nice to have a OnRemoveControl which could veto or tell if wxWindow must be removed or destroyed. It could be an alternative solution to a new event type.

As you wrote, lots of what I need is available but some bridges are missing to link them.
So, what, who, when ?

Dje

[dje]

Hi all !

In sdk_events.cpp

Code

CodeBlocksLogEvent::CodeBlocksLogEvent(wxEventType commandType, wxWindow* window, const wxString& title, wxBitmap *icon)
	: wxEvent(wxID_ANY, commandType),
	logger(0), logIndex(logIndex), icon(icon), title(title), window(window)
{
	logger = Manager::Get()->GetLogManager()->Slot(logIndex).GetLogger();
}

logIndex auto affectation gives out of range value (98443884 according to GDB).

my code:

Code

CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pThreadSearchView);
Manager::Get()->ProcessEvent(evt);

Crash

BerliOS bug : 12700

Thanks for non deletion of non logger window in cbEVT_REMOVE_LOG_WINDOW event management in 2nd December build !

Dje

[thomas]

logIndex(logIndex) (lines 66 and 73 of sdk_events.cpp)
Surprised the compiler doesn't complain about that. It complains about so many sophistries, but it doesn't see such an obvious thing.

I can't properly fix it since I don't know how all that event stuff is supposed to work, no idea what the 3-4 different constructors are for and what they should do internally.
But... this is the probable cause of your crash, anyway (as logIndex is intitialised to itself, and then Slot(logIndex) is used as frame pointer).

[dje]

Well, I think it does nothing in fact (keeping a random value).
I also think it is due to my previous request : not destroy a non logger when removing the pane

In facts, this constructor looks like a duplication of the previous one, replacing Logger* parameter by wxWindow* one.
But it seems that the same code don't work with a NULL logger.

I think that first version is used to add/remove logger pane, second to add/remove nonlogger pane.

Dje

[MortenMacFly]

But... this is the probable cause of your crash, anyway (as logIndex is intitialised to itself, and then Slot(logIndex) is used as frame pointer).

Yes - that really looks bad. Is Yiannis aware of that already?!

[dje]

Yes, I can confirm with yesterday's debug session (array access with bad index).
I wrote the problem on this post and created the bug on BerliOS but did not contact Yannis.

Dje

[thomas]

The array out of bounds thing is only the symptom, though. Indeed, Slot() doesn't do bounds-checking... but that is deliberate, and it's good that way (bounds checking could not help the issue, anyway).

An event that does not contain a Logger should generally not touch anything related to LogManager at all (only InfoPane).

Maybe, to make things more clear, it would help to have separate events for adding non-Loggers to the InfoPane, too.

[mandrav]

See, that's what happens when you copy-paste code and then don't update parts of it .
Sorry for this, I will fix it when I return to base later.

[dje]

Hi all !

From what I understood about (non)loggers management and InfoPane, I submitted a patch fixing CodeBlocksLogEvent initialisation :

Code

Index: sdk_events.cpp
===================================================================
--- sdk_events.cpp	(revision 4704)
+++ sdk_events.cpp	(working copy)
@@ -70,9 +70,8 @@
 
 CodeBlocksLogEvent::CodeBlocksLogEvent(wxEventType commandType, wxWindow* window, const wxString& title, wxBitmap *icon)
 	: wxEvent(wxID_ANY, commandType),
-	logger(0), logIndex(logIndex), icon(icon), title(title), window(window)
+	logger(0), logIndex(-1), icon(icon), title(title), window(window)
 {
-	logger = Manager::Get()->GetLogManager()->Slot(logIndex).GetLogger();
 }
 
 CodeBlocksLogEvent::CodeBlocksLogEvent(const CodeBlocksLogEvent& rhs)

It works on Windows (deeply functionnally tested).
I test it on Linux very soon.

Dje

[dje]

Hi all !

I found another bug (12842 on BerliOS)

Content:

Use ThreadSearch plugin v1.1 and enable it in Messages notebook (default behaviour).
To-do and Script console tabs are just after ThreadSearch tab.

Select the ThreadSearch tab.
Click on View/ThreadSearch. The panel is removed from Messages notebook with this code:

CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pThreadSearchView);
Manager::Get()->ProcessEvent(evt);
m_pThreadSearchView->Reparent(Manager::Get()->GetAppWindow());
m_pThreadSearchView->Show(false);


Click on View/ThreadSearch. The panel is added to Messages notebook with this code:


wxBitmap bmp;
wxString prefix = ConfigManager::GetDataFolder() + _T("/images/16x16/");
bmp = cbLoadBitmap(prefix + _T("filefind.png"), wxBITMAP_TYPE_PNG);

// Adds log to C::B Messages notebook
CodeBlocksLogEvent evtShow(cbEVT_ADD_LOG_WINDOW, m_pThreadSearchView, wxString(_T("Thread search")), &bmp);
Manager::Get()->ProcessEvent(evtShow);

CodeBlocksLogEvent evtSwitch(cbEVT_SWITCH_TO_LOG_WINDOW, m_pThreadSearchView);
Manager::Get()->ProcessEvent(evtSwitch);


The ThreadSearch tab appears in last position.


I want to set the ThreadSearch tab with the following code

CodeBlocksLogEvent evtShow(cbEVT_SHOW_LOG_MANAGER);
Manager::Get()->ProcessEvent(evtShow);
CodeBlocksLogEvent evtSwitch(cbEVT_SWITCH_TO_LOG_WINDOW, m_pThreadSearchView);
Manager::Get()->ProcessEvent(evtSwitch);


and at this time, the To-Do tab is activated. Note that it was ThreadSearch tab first position.

Dje

[olipfei]

Hello,

might not be the right forum for my issue, but as it is related to 'logger.h' I try to report it here:

During compilation of 'ThreadSearchViewManagerBase.cpp'  I get syntax error in 'logger.h', concerning DLLIMPORT in class declaration of Logger not being defined. One solution is to include 'settings.h' in above .cpp file before other headers. But wouldn't it be more reasonable to include it directly in 'logger.h', as there could be other files were 'settings.h' is included "accidentally" correctly before 'logger.h', and 'logger.h' should be "compilable" stand-alone (i.e. including 'logger.h' does not require to include 'settings.h' before)?

Regards,
olipfei

[killerbot]

well looking at ThreadSearchViewManagerBase.cpp, I can already see, it shouldn't include sdk.h --> doesn't use anything out of that in the cpp file.

But about the logger : you are correct, it should include the settings.h

I will adjust accordingly.

[dmoore]

I'm confused: Does

Code

CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW,mylogger);
Manager::Get()->ProcessEvent(evt);

automatically delete mylogger?

[dje]

Hi Damien !

You can have a look at ThreadSearch plugin.
I don't remember precisely how it works but memory management is clean both with Messages notebook and wxAuiLayout.
I think it is not deleted, simply removed (you'll have to check).

I can send you a mail tonight if you need more info (I don't have this code at work).

Dje

[dmoore]

well I don't see the debugger plugin release the memory for its loggers:

debuggergdb.cpp:458

Code

    if (Manager::Get()->GetLogManager())
    {
        if (m_HasDebugLog)
        {
            CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pDbgLog);
            Manager::Get()->ProcessEvent(evt);
            m_pDbgLog = 0;
        }
        CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pLog);
        Manager::Get()->ProcessEvent(evt);
        m_pLog = 0;
    }

[mandrav]

Code

    if (event.window)
        infoPane->RemoveNonLogger(event.window);
    else
        infoPane->DeleteLogger(event.logger);

In short:

• if it's a _real_ logger, it is deleted.
• if it's a custom window, it is not deleted but simply removed.

[dmoore]

I was pretty sure that was the case - thanks for clarifying