I've made a patch that shows a bit more info in the call tip showed by CC.
Here is the patch: http://smrt.is-a-geek.org/codeblocks/patches/cc_call_tip.patch
New features:
1. Show the return type of the function
2. Show the parents (class, namespaces)
3. Show the constness of the function
Missing features/bugs:
1. There is no info in the token if the function is static or not, so this info is missing
2. It doesn't work for constructors (it shows the info for the enclosing function :( )
Any help on these two will be appreciated :)
interesting, something to try out :-)
Another interesting thing : show the doxygen documentation (but then this needs to be parsed too : could start with a simple heuristic for functions : either the comment after the declaration, or the comment just in front of the declaration [when starting on a dedicated line])
void foo() //!< do foo stuff
/*!
Some information on bar
@param[in] in1 : first argument
\param[out] in2 : second argument
@return returns true on success, false otherwise
*/
bool bar(int in1, float& in2);
It could be any comment, not only doxygen's comments.
But I don't think it could be done without changing the parser.
In this patch I don't do any parsing. I just read the info stored in the tokens tree.
p.s. Also I don't use doxygen comments or any other doc system :)
Quote from: oBFusCATed on January 03, 2011, 07:31:52 PM
I've made a patch that shows a bit more info in the call tip showed by CC.
Here is the patch: http://smrt.is-a-geek.org/codeblocks/patches/cc_call_tip.patch
New features:
1. Show the return type of the function
2. Show the parents (class, namespaces)
3. Show the constness of the function
Missing features/bugs:
1. There is no info in the token if the function is static or not, so this info is missing
2. It doesn't work for constructors (it shows the info for the enclosing function :( )
Any help on these two will be appreciated :)
nice job!!!
I will look into your patch to see if I can help.
I've found a bug in the patch and I've fixed it.
The fix:
old: result = token.m_ActualType + wxT(" ") + result + token.m_Name + token.m_Args;
new: result = token.m_Type + wxT(" ") + result + token.m_Name + token.m_Args;
And the bug was:
1. if the return type is Class& the & was missing
2. if the return type is Class const & - only const was displayed
Please download the patch again...
applying your patch to trunk and build the whole C::B.
Than I do the following steps:
1, open the project
F:\cb\codeblocks_trunk\src\plugins\codecompletion\parser\parsertest.cbp
2, edit the file "test.h"
to below:
aaa & f();
aaa const & g();
3, run the project, here is the log:
...
--------------L-i-s-t--L-o-g--------------
000055. function aaa & f() [9,0]
000056. function aaa const & g() [11,0]
it seems the log is correctly.
Note that the List log comes from: parsertest.cpp
void ParserTest::PrintList()
{
TokenList& tokens = m_tokensTree->m_Tokens;
for (TokenList::iterator it = tokens.begin(); it != tokens.end(); it++)
{
wxString log;
log << (*it)->GetTokenKindString() << _T(" ") << (*it)->DisplayName() << _T("\t[") << (*it)->m_Line;
log << _T(",") << (*it)->m_ImplLine << _T("]");
ParserTrace(log);
}
}
then, DisplayName() will internally call the function:
wxString Token::DisplayName() const
{
wxString result;
if (m_TokenKind == tkClass)
return result << _T("class ") << m_Name << m_BaseArgs << _T(" {...}");
else if (m_TokenKind == tkNamespace)
return result << _T("namespace ") << m_Name << _T(" {...}");
else if (m_TokenKind == tkEnum)
return result << _T("enum ") << m_Name << _T(" {...}");
else if (m_TokenKind == tkTypedef)
{
result << _T("typedef");
if (!m_Type.IsEmpty())
result << _T(" ") << m_Type;
if (result.Find('*', true) != wxNOT_FOUND)
{
result.RemoveLast();
return result << m_Name << _T(")") << GetFormattedArgs();
}
if (!m_TemplateArgument.IsEmpty())
result << m_TemplateArgument;
return result << _T(" ") << m_Name;
}
else if (m_TokenKind == tkPreprocessor)
{
result << _T("#define ") << m_Name << GetFormattedArgs();
if (!m_Type.IsEmpty())
return result << _T(" ") << m_Type;
}
// else
if (!m_Type.IsEmpty())
result << m_Type << m_TemplateArgument << _T(" ");
if (m_TokenKind == tkEnumerator)
return result << GetNamespace() << m_Name << _T("=") << GetFormattedArgs();
return result << GetNamespace() << m_Name << GetStrippedArgs();
}
Then, I check the m_Type here, it is correct too.
not sure why your problem happens....
Because I was using m_ActualType, now I am using m_Type and it seems to work.
Quote from: oBFusCATed on January 04, 2011, 08:28:51 AM
m_ActualType, [...] m_Type
Nah - reminds me that m_ActualType is a bad name for that purpose. It leads to confusion like in your case (and happened to me, too).
when it shows the parent of a local variable, say test which is a local var of the function foo(),
not it shows : int foo::test
Wouldn't it be better to show : int foo()::test, so a clear distinction is visible between method parents or classes/namespaces ?
What do you think ?
Hm, thanks for the report...
I'll try to limit this patch only to functions/methods. For variables it will be a bit annoying.
I'm on gentoo linux r6900 debuggers branch and I can't get the call tip to show up for non functions.
Can you test it on linux and if you can reproduce it can you give me simplest possible example :) ?
I did it on linux, also on the debuggers branch.
I will try to create a small example tomorrow, to post here.
just make a new console app through the wizard : and make this the contents of the main.cpp
#include <iostream>
int main()
{
int foo = 0;
foo = foo + 20;
std::cout << foo << std::endl;
return 0;
}
tooltip over foo --> int main::foo
PS : I noticed the tooltip not always shows up.
I've remembered to check this problem and it seems this is not caused by my patch,
because the problem happens in CodeCompletion::OnValueTooltip and I've not changed it.
Is there any developer willing to commit this patch? :P
Quote from: oBFusCATed on January 27, 2011, 08:26:39 PM
Is there any developer willing to commit this patch? :P
Not yet, it has several bugs.
For example: I get strange things when I hover e.g. over wxMessageBox. There were some other strange things but I forgot. :roll: :(
Edit: It wasn't wxMessageBox (although this look weired, too), but another wx class. The point was that it had obviously
#defines in the parameter list which broken the call tip completely.
Are these bugs caused by the patch or they can be reproduced in trunk?
If the patch is the problem, please report them, so I can try to fix them :lol:
Quote from: oBFusCATed on January 27, 2011, 08:49:58 PM
Are these bugs caused by the patch or they can be reproduced in trunk?
You don't really want me to compile "plain" trunk, don't you?! ;-)
All I can say is that they become visible with our patch but they may have it's root in a bug in CC.
I'll tell next time it happens again. However, when I use C::B these days I don't have much time to remember what I've seen and what caused it exactly. So usually just continue to work. But I'll try to make it better next time. :oops:
The other option is to apply it and people will tell us if it is badly broken... :twisted:
I'm using this patch for something like an year and I had no problems with it...