C::B 13.12 Can't work with big project which have more than 100 files.

[ollydbg]

Here it is, my whole project files.
https://www.dropbox.com/s/f0lhi9e1y9lvh6q/wxFB_Prj.zip

Works fine here (I'm using the latest svn trunk rev9665), except there are some duplicated DecBy() functions in the suggestion list.
See image shot below:

[MortenMacFly]

Works fine here (I'm using the latest svn trunk rev9665), except there are some duplicated DecBy() functions [...]

Works fine here, too. The DecBy duplicates might be even OK, if these have different parameters... sure there is potential for an optimisation here.

[tyysoft]

How about the release 13.12? no response somewhere?

[tyysoft]

find the issue of rev9660!
code completion setting, if choose "Auto-select, if only one math", then the suggest list is "too many result", otherwise, the suggest list work well.

[tyysoft]

And a little suggestion about the code completion

Code

wxSize* szPtr = this.GetSize();

I think the code completion thread is know the "this" is a pointer, and when I typing the ".", it should be better to change the "." to "->", is it?

[oBFusCATed]

The DecBy duplicates might be even OK....

Looking at the screenshot they aren't OK, they are just duplicates.
Ollydbg can you check why they happen, because I've seen it on my own code.

[ollydbg]

The DecBy duplicates might be even OK....

Looking at the screenshot they aren't OK, they are just duplicates.
Ollydbg can you check why they happen, because I've seen it on my own code.

Using the CC debug tool(dialog), I just lookup the keyword "DecBy", and I get four entries, I found that they are all overload functions.
See image shot below:

So, if they have different documents, those document will shown in the right side of the suggestion list. While we move the caret in the suggestion list, the document will change accordingly.

My suggest would be: Merge the same entry in the suggestion list, but we need also merge the document.
Or, we can just leave it as it is.

[ollydbg]

And a little suggestion about the code completion

Code

wxSize* szPtr = this.GetSize();

I think the code completion thread is know the "this" is a pointer, and when I typing the ".", it should be better to change the "." to "->", is it?

We have such discussion already, but some people will complain such automatic change. Also, such change may be wrong (not the "this" case, but a pointer variable). Another case is when you are editing a C source file, then "this" is not a C language keyword.

[oBFusCATed]

ollydbg: So the problem with the duplicates is that the list of parameters is not displayed for every entry?

[ollydbg]

ollydbg: So the problem with the duplicates is that the list of parameters is not displayed for every entry?

You can enable this code completion option: Show token's details even it hasn't documentation.
(see image shot below)


You will see their function prototypes even they don't have doxygen style document, see image shot below:

[oBFusCATed]

Okay, so they are different, but to me they look the same so we have to do one of these (or do both with an option) :
1. merge them together (the doc popup must show info for all versions in this case)
2. display the parameters, so the user know they are different

[MortenMacFly]

2. display the parameters, so the user know they are different

We had removed this because the parameter list might get that large, that the CC windows won't fit on the screen.

If you want to try, in codecompletion.cpp, method CodeCompletion::CodeComplete() replace:
tmp << _T("(): ") << token->m_FullType;
...with:
tmp << token->GetFormattedArgs() << _T(": ") << token->m_FullType;

...the documentation is responsible for the details and should always be shown in the short version.

[oBFusCATed]

Have you tried some string length limiting?
If yes then option 1 should be implemented. There is no point in having multiple copies of the same string in this list.
Probably this merging should be done in the CCManager in the cc_branch and not by the CC plugin.

[MortenMacFly]

The idea was to have a scrollable list of methods on the left and if you scroll through them the docs window always shows the details on the right. This is as minimalistic as it gets and if you take them as a combined information then thats already option 1.

In the past (w/o docs windows) we only had the plain CC window that showed the (formatted) args as well.
Whats missing IMHO is the use case, if the docs are disabled in the CC options. Then the CC windows should return to its old behaviour and show the args as well.

I think this would be most simple and clear.

[MortenMacFly]

Whats missing IMHO is the use case, if the docs are disabled in the CC options. Then the CC windows should return to its old behaviour and show the args as well.

I've comitted this to trunk. Play with it.

There should only be 2 cases:
1.) A short list of methods and always the docs on the right
2.) A long list of methods including args if the docs are disabled.

Every other state is invalid and we need to dig into it.