Windows get the following compile errors:The according .cpp-files are missing from svn-tree.
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
nonono; these were still in the windows cbp file, fixed nowAh, yes, I knew I forgot something :).
In the old days warnings showed up blue and errors red in the Build messages and Build log tabs.
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.
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
Is there a replacement for simpletextlog.h/class SimpleTextLog?
Some plugins like SVNInside use it.
Tim S
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.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).
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...?!
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?
Code has not been changed.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.
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.
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.
Seems like Manager::Get()->GetLogManager() and LogManager::Get() return two different instances...Oh, it's worse... it looks like that's the case with all managers, only so far nobody ever noticed :(
Specifically, in Mgr<MgrT>::Get(), a new instance is created the first time the two above calls are made
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.
// remove those:
template<class MgrT>MgrT* Mgr<MgrT>::instance = 0;
template<class MgrT>bool Mgr<MgrT>::isShutdown = false;
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 :).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.
Hmm... can we simply move the instance into a .cpp file (one)? If I understand the problem right, that should work.
I have already created the patch and sent it over to Morten for testing on windows. If all goes well, I 'll commit it.
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)
EVT_ADD_LOG_WINDOW
EVT_REMOVE_LOG_WINDOW
if you can give a good reasonWell, we'll have to discuss what makes a reason to be good :D but:
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 ?
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.
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.
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.
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();
}
CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pThreadSearchView);
Manager::Get()->ProcessEvent(evt);
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?!
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)
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.
CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW,mylogger);
Manager::Get()->ProcessEvent(evt);
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;
}
if (event.window)
infoPane->RemoveNonLogger(event.window);
else
infoPane->DeleteLogger(event.logger);