One issue I get on windows xp and on my debian system (gcc 4.5 on windows amd 4.6 on linux) is, that neither the PARSER_START not the PARSER_END event is caught by the appropriate event-handlers.I'm testing this issue on Windows XP and rev 7289.
As third: I always see some boost-defines and most likely some of the other high-priority headers (former up-front) in the symbols-browser, even if I do not include these headers any of my projects.The high-priority headers were predefined by Codecompletion plugin, and they were searched and parsed before parsing any actual files in your projects. This behavior is used to handle some predefined macro definition in those high-priority headers. So, even you did not include those files in your projects, they were still be parsed, thus this issue you complain happens.
Maybe we can put it into "Project > Properties > C/C++ Parser options".As third: I always see some boost-defines and most likely some of the other high-priority headers (former up-front) in the symbols-browser, even if I do not include these headers any of my projects.The high-priority headers were predefined by Codecompletion plugin, and they were searched and parsed before parsing any actual files in your projects. This behavior is used to handle some predefined macro definition in those high-priority headers. So, even you did not include those files in your projects, they were still be parsed, thus this issue you complain happens.
I think you can simply change these high-priority headers in Codecompletions options dialog. :D
Maybe we can put it into "Project > Properties > C/C++ Parser options".But then, people won't do it and effectively loose this feature. I think it' OK to have them in one place and maybe spoil the symbol table with a little useless information. In the end it doesn't consume too much memory.
So that each project can be set to different high-priority headers.
4 user templates loaded
Project's base path: /tmp/test/
Project's common toplevel path: /tmp/test/
Caching GCC dir: /usr/include/c++/4.6
Caching GCC dir: /usr/include/c++/4.6/x86_64-linux-gnu
Caching GCC dir: /usr/include/c++/4.6/backward
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include-fixed
Caching GCC dir: /usr/include/x86_64-linux-gnu
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse with priority: '/usr/include/c++/4.6/cstddef'
Header to parse with priority: '/usr/include/boost/config.hpp'
Header to parse with priority: '/usr/include/boost/filesystem/config.hpp'
Add 3 priority parsing file(s) for project 'test'...
Added 1 file(s) for project 'test' to batch-parser...
Create new parser for project 'test'
@ollydbg:
I know how the event-handling should work, and the appropriate calls to PostParserEvent are made, but the events are never caught.
Here is the debug-log after creating a new console-project with the wizard, before creating I cleaned the log:Code4 user templates loaded
Project's base path: /tmp/test/
Project's common toplevel path: /tmp/test/
Caching GCC dir: /usr/include/c++/4.6
Caching GCC dir: /usr/include/c++/4.6/x86_64-linux-gnu
Caching GCC dir: /usr/include/c++/4.6/backward
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include-fixed
Caching GCC dir: /usr/include/x86_64-linux-gnu
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse with priority: '/usr/include/c++/4.6/cstddef'
Header to parse with priority: '/usr/include/boost/config.hpp'
Header to parse with priority: '/usr/include/boost/filesystem/config.hpp'
Add 3 priority parsing file(s) for project 'test'...
Added 1 file(s) for project 'test' to batch-parser...
Create new parser for project 'test'
BTW: Jens, I cannot reproduce on Windows XP. Could you provide simple steps / a project to reproduce? Do you see in the debug log the message "NativeParser received parser end event" and "CodeCompletion received parser end event"? I see them whatever parsr configuration I use...?!
CodeCompletion received parser end event
oid CodeCompletion::OnParserEnd(wxCommandEvent& event)
{
if (!Manager::IsAppShuttingDown())
Manager::Get()->GetLogManager()->DebugLog(_("CodeCompletion received parser end event."));
ParsingType type = static_cast<ParsingType>(event.GetInt());
if (type == ptCreateParser)
{
if ( !m_SystemHeadersThread.empty()
&& !m_SystemHeadersThread.front()->IsRunning()
&& m_NativeParser.Done() )
{
m_SystemHeadersThread.front()->Run();
}
}
cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (editor)
ParseFunctionsAndFillToolbar(true);
event.Skip();
}
Does it means the "DebugLog" function does not works correctly? or some messages were slip away???I guess if it is called from a non-main-gui thread, a race condition is possible (wxGTK is almost single threaded lib) and skipped messages, too.
mortenmacfly 2011-7-3 19:46:20
* CC: show some more information to the user to hunt CC bugs
- CC: remove long-time obsolete functions to save a CC cache
Jens, are you using Debian Testing?Unstable/experimental (with some libs of testing of course), with libgtk2.0 2.24.5-4, libgtk3.0 3.0.12-1 and libwxgtk 2.8.10-3.1.
Project's base path: /home/loaden/DengYC/Projects/baby/
Project's common toplevel path: /home/loaden/DengYC/Projects/baby/
Caching GCC dir: /usr/include/c++/4.5
Caching GCC dir: /usr/include/c++/4.5/x86_64-linux-gnu
Caching GCC dir: /usr/include/c++/4.5/backward
Caching GCC dir: /usr/local/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include
Caching GCC dir: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/include-fixed
Caching GCC dir: /usr/include/x86_64-linux-gnu
Caching GCC dir: /usr/include
Passing list of files to batch-parser.
Header to parse with priority: '/usr/include/c++/4.5/cstddef'
Add 1 priority parsing file(s) for project 'baby'...
Added 1 file(s) for project 'baby' to batch-parser...
Create new parser for project 'baby'
Starting batch parsing for project 'baby'...
NativeParser received parser end event.
Project 'baby' parsing stage done!
Project 'baby' parsing stage done (94 total parsed files, 4181 tokens in 0 minute(s), 0.279 seconds).
Updating class browser...
Class browser updated.
CodeCompletion received parser end event.
it also works fine with the build from my repo, but still fails if build C::B on my working system.Try to remove the default.conf
I just recompiled C::B with gcc 4.5 instead of 4.6, but the not-catch-the-parser-events-issue remains.
It does not change anything, but I don't know what the default.conf should have to do with event handling.it also works fine with the build from my repo, but still fails if build C::B on my working system.Try to remove the default.conf
I just recompiled C::B with gcc 4.5 instead of 4.6, but the not-catch-the-parser-events-issue remains.
The attached patch seems to fix the event-handler issue and should not break anything other.It's works. But why? It's wxWidgets's bug?
Can you please test it ?
I have the same question hare, the patches seems only convert the event-handler map from static macro definition to dynamically linked style, are there much difference on propagate messages? I guess it is a bug in Linux version of wxWidgets. :DThe attached patch seems to fix the event-handler issue and should not break anything other.It's works. But why? It's wxWidgets's bug?
Can you please test it ?
It's works. But why? It's wxWidgets's bug?
I have the same question hare, the patches seems only convert the event-handler map from static macro definition to dynamically linked style, are there much difference on propagate messages?
Jens' patch indeed solve the problem, but I still believe its a bug in wx, because there is no reason that the event_table way does not work. (although wx guys use/suggest dynamical way, but the static event_table way should always work), and looking at c::b's source, there are many event_table usages. :DIt's works. But why? It's wxWidgets's bug?I have the same question hare, the patches seems only convert the event-handler map from static macro definition to dynamically linked style, are there much difference on propagate messages?
It's not a bug, but a matter of ordering the event handling. In fact, the wx guys really encourage to use this method (see here: http://wxwidgets.blogspot.com/2007/01/in-praise-of-connect.html). I am using it all the time in my personal projects and once you get used to it it's really quite handy. Especially the ability to switch the event propagation temporarily off for certain reasons is nice.
So I think we can safely apply Jens' patch.
Jens' patch indeed solve the problem, but I still believe its a bug in wx, because there is no reason that the event_table way does not work. (although wx guys use/suggest dynamical way, but the static event_table way should always work), and looking at c::b's source, there are many event_table usages. :DI have the same point!
I have the same point!That might be true, but in fact you are doing 2 different things here. But I guess the wx guys can explain better - why not asking in the wx forums?
I think I can't. Because my poor English. I can't explain this clear.I have the same point!That might be true, but in fact you are doing 2 different things here. But I guess the wx guys can explain better - why not asking in the wx forums?
I think I can't. Because my poor English. I can't explain this clear.And I just realised that for some obscure reason the wx shadownet forum seems gone?! Have they moved to a new place and I didn't get it? :shock:
The movement takes several days ago. :D, and the old domain name was expired, at that time, the wx forum has encountered a crash and recovery. (I'm subscribed to the wx-maillist under my thunderbird).I think I can't. Because my poor English. I can't explain this clear.And I just realised that for some obscure reason the wx shadownet forum seems gone?! Have they moved to a new place and I didn't get it? :shock:
EDIT: And what the hell is this:
http://forum.wxwidgets.org/
???
that's the wrong link. The right one is http://forums.wxwidgets.org (http://forums.wxwidgets.org).I think I can't. Because my poor English. I can't explain this clear.And I just realised that for some obscure reason the wx shadownet forum seems gone?! Have they moved to a new place and I didn't get it? :shock:
EDIT: And what the hell is this:
http://forum.wxwidgets.org/
???
that's the wrong link. The right one is http://forums.wxwidgets.org (http://forums.wxwidgets.org).Darn! The missing "s" leads to this strange page...?! WTF?! :?