User forums > Using Code::Blocks
Code completion does not solve STDMETHOD macro for COM interfaces
ollydbg:
--- Quote from: GPBeta on September 22, 2014, 07:02:29 am ---...
Thanks for the help Huki, but CC is still not going to parse it unless removing the __stdcall from macro definition:
--- Code: ---#define STDMETHOD(m) virtual HRESULT __stdcall m
#define STDMETHOD_(t,m) virtual t __stdcall m
--- End code ---
Maybe I should try about the patch ollydbg referred and compile it myself?
--- End quote ---
To totally fix your issue, we have two steps:
1, fix macro expanding issue, to workaround it, you need Use __stdcall in the macro definition.
Or, just apply this patch:
--- Code: --- src/plugins/codecompletion/parser/tokenizer.cpp | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/plugins/codecompletion/parser/tokenizer.cpp b/src/plugins/codecompletion/parser/tokenizer.cpp
index 8a13abd..4273d73 100644
--- a/src/plugins/codecompletion/parser/tokenizer.cpp
+++ b/src/plugins/codecompletion/parser/tokenizer.cpp
@@ -1931,8 +1931,10 @@ bool Tokenizer::GetMacroExpandedText(const Token* tk, wxString& expandedText)
// sanity check if we have such macro definition that #define AAA(x,y) x+y+AAA
// if a macro name exists in its definition, it will cause a infinite expansion loop
- if (tk->m_FullType.Find(tk->m_Name) != wxNOT_FOUND)
- return false;
+ // Note: disable this sanity check to work around the issue here:
+ // http://forums.codeblocks.org/index.php/topic,19661.msg134291.html#msg134291
+ //if (tk->m_FullType.Find(tk->m_Name) != wxNOT_FOUND)
+ // return false;
// if it's a variable like macro definition simply return the replacement text
if (tk->m_Args.IsEmpty())
--- End code ---
2, apply Huki's patch I mentioned, and rebuild C::B(especially CodeCompletion plugin)
GPBeta:
I found that The 16 September 2014 build (9916) has applied Huki's patch,
I tried it and modified the header with __stdcall, it did fix the problem, but the nightly builds(9916 & 9884) recently released both have an issue: eating up a core's CPU time,
then C::B become extremely slow under Windows 8.1 x64 with default C::B settings, I have to remove all the plugins(except some core plugins and of course the code completion) to make C::B run gracefully.
Anyway, thank you very much for the help :P
ollydbg:
--- Quote from: GPBeta on September 22, 2014, 09:31:13 am ---I found that The 16 September 2014 build (9916) has applied Huki's patch,
I tried it and modified the header with __stdcall, it did fix the problem,
--- End quote ---
Grad to hear, I was mentioned an testing patch which is not in trunk, but it looks like we don't need such patch to solve your issue;)
--- Quote ---but the nightly builds(9916 & 9884) recently released both have an issue: eating up a core's CPU time,
then C::B become extremely slow under Windows 8.1 x64 with default C::B settings, I have to remove all the plugins(except some core plugins and of course the code completion) to make C::B run gracefully.
Anyway, thank you very much for the help :P
--- End quote ---
This is really a big problem, If you can supply a test case, I'm going to hunt this issue. (mostly, I think it is CodeCompletion which cause the issue)
GPBeta:
I think this issue could be confirmed, I also test it under windows 2003 x64 in a virtual machine, same behavior as my win8.1 x64 PC.
I also try about removing codecompletion.dll from the plugins folder and restart C::B, but that does not help anything...So I think we should spend some time to find which plugins produce this issue.
[attachment deleted by admin]
Jenna:
--- Quote from: GPBeta on September 22, 2014, 04:50:54 pm ---I think this issue could be confirmed, I also test it under windows 2003 x64 in a virtual machine, same behavior as my win8.1 x64 PC.
I also try about removing codecompletion.dll from the plugins folder and restart C::B, but that does not help anything...So I think we should spend some time to find which plugins produce this issue.
--- End quote ---
Does it happen without any plugins ?
I ask because we have changes in (wx-)scintilla that use timers and this is at least a change, that might be related to time consuming behaviour.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version