Beautify Edit->Show call tip

[oBFusCATed]

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

[killerbot]

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])

Code

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);

[oBFusCATed]

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

[ollydbg]

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.

[oBFusCATed]

I've found a bug in the patch and I've fixed it.

The fix:

Code

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...

[ollydbg]

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:

Code

aaa & f();
aaa const & g();

3, run the project, here is the log:

Code

...
--------------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

Code

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:

Code

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....

[oBFusCATed]

Because I was using m_ActualType, now I am using m_Type and it seems to work.

[MortenMacFly]

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).

[killerbot]

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 ?

[oBFusCATed]

Hm, thanks for the report...

I'll try to limit this patch only to functions/methods. For variables it will be a bit annoying.

[oBFusCATed]

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 ?

[killerbot]

I did it on linux, also on the debuggers branch.
I will try to create a small example tomorrow, to post here.

[killerbot]

just make a new console app through the wizard : and make this the contents of the main.cpp

Code

#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.

[oBFusCATed]

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.

[oBFusCATed]

Is there any developer willing to commit this patch? 

[MortenMacFly]

Is there any developer willing to commit this patch?  

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.

[oBFusCATed]

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:

[MortenMacFly]

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:

[oBFusCATed]

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...