void CodeCompletion::OnEditorActivated(CodeBlocksEvent& event)
{
EditorBase* eb = event.GetEditor();
if (IsAttached() && m_InitDone)
{
m_NativeParsers.OnEditorActivated(eb);
m_FunctionsParsingTimer.Start(1000, wxTIMER_ONE_SHOT); // one second delay should be ok
}
event.Skip();
}
bool Parser::ParseBufferForFunctions(const wxString& buffer)
{
ParserThreadOptions opts;
opts.wantPreprocessor = m_Options.wantPreprocessor;
opts.useBuffer = true;
opts.bufferSkipBlocks = true;
opts.handleFunctions = true;
ParserThread* thread = new ParserThread(this,
buffer,
false,
opts,
m_pTempTokens);
return thread->Parse();
}
void CodeCompletion::EditorEventHook(cbEditor* editor, wxScintillaEvent& event)
{
ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("code_completion")); //EXPENSIVE??
if (!IsAttached() ||
!m_InitDone)// ||
!cfg->ReadBool(_T("/use_code_completion"), true)) //cfg-Read... EXPENSIVE??
{
event.Skip();
return;
}
...
unfortunately, I can't say I used any special tool to find the problem other than C::B itself (lots of find in files and find implementation of). I know that on Linux you can use callgrind (part of valgrind) to produce call statistics, but I'm not familiar enough with that tool or the C::B code to use it effectively (you have to have an idea of what code should be called thousands of times and what shouldn't).
back to the Function Parsing code - delaying till all project files are open is good, but then it appears that the parsing occurs on the main thread, which blocks the UI until it's done, which kind of defeats the purpose of waiting...
and next problem: after the editor loses then regains focus, the function parser appears to reparse the whole file if you click on the class/function browser drop down. should only happen if file is modified right? (unless the data is released when the file loses focus?)
back to the Function Parsing code - delaying till all project files are open is good, but then it appears that the parsing occurs on the main thread, which blocks the UI until it's done, which kind of defeats the purpose of waiting...
and next problem: after the editor loses then regains focus, the function parser appears to reparse the whole file if you click on the class/function browser drop down. should only happen if file is modified right? (unless the data is released when the file loses focus?)
Yiannis: Don't worry about the thread problems! I'm not touching THAT thing (eew :-P ). It was just a suggestion, I have to admit sometimes I get misinterpreted (ah, remember the old times? :) ). I said "we" as "the team" because I don't want to meddle with multithreading. I still have open sores about that ;-)Yes I remember the old times :lol: but it seems that you have learned a little bit of it :) (How do I know? you have just edited you're own text :P)
[back to the Function Parsing code - delaying till all project files are open is good, but then it appears that the parsing occurs on the main thread, which blocks the UI until it's done, which kind of defeats the purpose of waiting...
and next problem: after the editor loses then regains focus, the function parser appears to reparse the whole file if you click on the class/function browser drop down. should only happen if file is modified right? (unless the data is released when the file loses focus?)
These problems needs attention. :)
But I got a better solution than your patch. It's called ProjectManager::IsBusy(). Returns true when the project is loading/closing.