New log manager since rev. 4606

[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