Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Code Completion works only partially per file
jamieo:
Unfortunately it's not just function names but any symbol is affected. For example, the BSM_* constants that appear a little after GetMessage in WinUser.h are not parsed. (these were the first and only I tried just now). It would be a huge task to count each and every one but it would be nice if somebody could add some stats to the code completion parser to see how many symbols were parsed per file, even if it were just a quick hack to help with this investigation.
Based on your question I checked where the symbols stopped being parsed in the latest Vista PSDK. It's in the exact place for both files ie, FormatMessage and GetMessage are the last symbols that will work. I then compared these files to the original versions I reference above from PSDK2003 and there are (as expected) many new symbols defined, including new functions so I doubt symbol or function count has an influence. I also checked some of the new symbols defined either side of the 'divide' and behavior was as with psdk2003.
I'm surprised none of the developers or more experienced codeblocks hackers are interested in this thread - this IS the Dev-el-op-ment Forum?! Maybe you have to have 10000 posts before your posts are valid...
Jamie
TDragon:
--- Quote from: jamieo on February 23, 2007, 02:07:16 am ---I'm surprised none of the developers or more experienced codeblocks hackers are interested in this thread ...
--- End quote ---
Code::Blocks' code completion is a work in progress. It's generally accepted that the current implementation, while usable, would be better off redeveloped from the ground up. Of the official devs, I'd expect only mandrav and possibly thomas to be truly qualified to troubleshoot and bugfix the current version (the majority of which was written single-handedly by mandrav). Any fixes to the current version, therefore, are subject to mandrav's willingness to nail more boards onto a house that's already scheduled for demolition.
(I don't pretend to speak for the C::B dev team in any way -- this has just been my experience.)
mandrav:
--- Quote from: jamleo ---Based on your question I checked where the symbols stopped being parsed in the latest Vista PSDK. It's in the exact place for both files ie, FormatMessage and GetMessage are the last symbols that will work. I then compared these files to the original versions I reference above from PSDK2003 and there are (as expected) many new symbols defined, including new functions so I doubt symbol or function count has an influence. I also checked some of the new symbols defined either side of the 'divide' and behavior was as with psdk2003.
--- End quote ---
Did you check inside the files for "strange" constructs or defines, around there the parser stops, that could possibly confuse our parser?
If you can't see anything, zip one such file and attach it here or post a link to it so I can have a look.
--- Quote from: jamleo ---I'm surprised none of the developers or more experienced codeblocks hackers are interested in this thread - this IS the Dev-el-op-ment Forum?! Maybe you have to have 10000 posts before your posts are valid...
--- End quote ---
But then again you may ignore this post as I don't have 10000 posts already so it may very well be considered invalid...
jamieo:
--- Quote from: mandrav on February 23, 2007, 09:28:23 am ---Did you check inside the files for "strange" constructs or defines, around there the parser stops, that could possibly confuse our parser?
If you can't see anything, zip one such file and attach it here or post a link to it so I can have a look.
--- End quote ---
Thanks for looking into this, I've spent a while investigating and documenting this so a resolution may be found. Opening the attached project from testproj.zip with your psdk search path changed to the minimal set of headers included *should* result in the described behavoir. The other attachment has the working headers from VS2003 if required.
I've found the part of the include that causes the problem by commenting out various directives and retesting, I didn't think of doing this before as I thought disabling the 'Follow Preprocessor Directives' option should ignore any #ifdef etc. directives but it doesn't seem to have any effect on this issue - does the option only effect reading of additional files included in a header? Additionally, the directives look valid and folding within SciTe seems to confirm that.
The error occurs with incorrect parsing of the '#ifdef UNICODE' block within the '#if defined(_M_CEE)' blocks commented below. What's surprising is that I wouldn't expect the problem block to even be parsed based on the defines in effect. With the 'Follow Preprocessor Directives' option disabled the error still happens. Also, 'Find declaration of..' FormatMessage lists the symbol defined within this directive, should this be the case. It seems Codeblocks parses within inactive directives.
WinBase.h
--- Code: ---#if defined(_M_CEE)
#undef FormatMessage
__inline
DWORD
FormatMessage(
DWORD dwFlags,
LPCVOID lpSource,
DWORD dwMessageId,
DWORD dwLanguageId,
LPTSTR lpBuffer,
DWORD nSize,
va_list *Arguments
)
{
/// COMMENTING THE FOLLOWING DIRECTIVE
/// MAKES THE PROBLEM GO AWAY!
/*
#ifdef UNICODE
return FormatMessageW(
#else
return FormatMessageA(
#endif
*/
dwFlags,
lpSource,
dwMessageId,
dwLanguageId,
lpBuffer,
nSize,
Arguments
);
}
#endif /* _M_CEE */
--- End code ---
WinUser.h
--- Code: ---#if defined(_M_CEE)
#undef GetMessage
__inline
BOOL
GetMessage(
LPMSG lpMsg,
HWND hWnd,
UINT wMsgFilterMin,
UINT wMsgFilterMax
)
{
/// COMMENTING THE FOLLOWING DIRECTIVE
/// MAKES THE PROBLEM GO AWAY!
/*
#ifdef UNICODE
return GetMessageW(
#else
return GetMessageA(
#endif
*/
lpMsg,
hWnd,
wMsgFilterMin,
wMsgFilterMax
);
}
#endif /* _M_CEE */
--- End code ---
Commenting out the blocks above doesn't completely fix code completion, for instance 'MessageBox' is not found so there are other instances of this problem within the same include. However, some similar directives I look into don't seem to cause the same problem. The following block for 'SetEnvironmentVariable' within 'WinBase.h' seems ok so there seems to be some other influence at work here:
WinBase.h
--- Code: ---#if defined(_M_CEE)
#undef SetEnvironmentVariable
__inline
BOOL
SetEnvironmentVariable(
LPCTSTR lpName,
LPCTSTR lpValue
)
{
/// THE FOLLOWING DIRECTIVE DOESN'T
/// SEEM TO CAUSE A PROBLEM...
#ifdef UNICODE
return SetEnvironmentVariableW(
#else
return SetEnvironmentVariableA(
#endif
lpName,
lpValue
);
}
#endif /* _M_CEE */
--- End code ---
--- Quote from: mandrav on February 23, 2007, 09:28:23 am ---But then again you may ignore this post as I don't have 10000 posts already so it may very well be considered invalid...
--- End quote ---
Ha! Then I am lucky your post count is not so high yet! Of course your post is valid - to me anyway - you still have more posts than I do!!! ;)
I'm joking btw, although it does annoy me how many boards have a snobery regarding post count. Especially as I prefer to search for my own answers rather than increasing my post count by blindly asking for help all the time! End Rant! :P
Jamie
[attachment deleted by admin]
jamieo:
Another problem I've encountered with code completion is that some functions complete but do not offer the parameter tooltip.
I've noticed this seems to occur only with functions that are defined as other functions, ie: 'MessageBox' is really 'MessageBoxA' or 'MessageBoxW' depending on the 'UNICODE' define. The tooltip doesn't work for this function but does for 'MessageBoxA' and 'MessageBoxW'. This severly cripples code completion (for win32 at least, not sure about other platforms) - is this behavoir expected or should the tooltips be shown??
PS. Although I'm probably unable to fix these problems myself I have noticed a few other minor bugs - I'm unsure if these have already been reported as the forum referenced to in the 'Reporting Problems' sticky seems to be inaccessible to non-developers.
Jamie
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version