Hello everybody, I remarqued that since yesterday the "there are several issues with Code Completion (is being redesigned : work in progress)" dissapeared from the "Regressions/Confirmed/Annoying/Common bugs:" list.
My question is: Is the Code Completion now 100% stable?, if that's the case, I will be very very happy!! (the point is that I didn't have the time to test it myself).
Anyway, congratulations!!!!! :D
After I open ANY from my already existing projects, atfer the parser thread finish (cpu usage falling to nearly zero) the C::B enter an INFINITE LOOP with hourglass cursor.
Edit->Show call tip (Shift+Ctrl+Space) menu is it done?
QuoteAfter I open ANY from my already existing projects, atfer the parser thread finish (cpu usage falling to nearly zero) the C::B enter an INFINITE LOOP with hourglass cursor.Although you give no info at all, I know this is a bug of the linux version. I hadn't had the time to look into it yet, but will do this weekend.
QuoteEdit->Show call tip (Shift+Ctrl+Space) menu is it done?How do you expect this to work when the IDE freezes?
Incorrect combobox drawing within toolbars under Windows 2000 is known problem, but unfortunately with this release it becomes somehow more annoying: screenshot (http://img475.imageshack.us/img475/7628/cbtoolbarscq0.png) (CodeCompletion toolbar is heavily affected). You may add this one to "Regressions/Confirmed/Annoying/Common bugs" list if you feel it feasible.I have that problem as well. Seems to be fine on XP but my 2000 machine it looks exactly the same as the screenshot above even though they are the same build.
I have a machine running 2000 and can build from source- If you have any particular instructions I'll be happy to help. I'll not be available for the next 7 hours, but after that I'm all yours. :wink: :oops:
Wow, COOL! This is feature I waited so long! Thanks!!! :D
- CodeCompletion toolbar added which allows to jump to functions of the current editor and also tracks in which function your cursor is (view->toolbars->codecompletion)
Wow, COOL! This is feature I waited so long! Thanks!!! :D
- CodeCompletion toolbar added which allows to jump to functions of the current editor and also tracks in which function your cursor is (view->toolbars->codecompletion)
There is only one thing I'm missing in C::B. The ability to view two different files in split view.
I tried out the code-completion bar thingy, and it's so fast! Great!
Only thing, what's with the greyed-out bar left of the other one? Do the global functions go there? If so, how do I turn that on?
What would be a superb improvement is the ability to type in the first part of the function's name in that toolbar, like in symbol view, save for that, it's supberb!
I can't open symbols browser anymore. It simply does not open. I've tried fresh-installing cb with no luck.Same thign appeared to happen to me too. But it was docked by default as a tab in the project manager. I had to set it to be a free floating window again, and I docked it back the old way.
Version 1.0 revision 2936 () gcc 3.4.5 Windows/unicode
WinXP SP2
Same thign appeared to happen to me too. But it was docked by default as a tab in the project manager. I had to set it to be a free floating window again, and I docked it back the old way.
I can't open symbols browser anymore. It simply does not open. I've tried fresh-installing cb with no luck.Same thign appeared to happen to me too. But it was docked by default as a tab in the project manager. I had to set it to be a free floating window again, and I docked it back the old way.
Version 1.0 revision 2936 () gcc 3.4.5 Windows/unicode
WinXP SP2
Actually, should it even be in the view-menu when it's not a dockable window, but a tab of manager instead?
The problem is as follows. In wxWidgets 2.6.3, the toolbar's initial client size (when wxDefaultSize) is specified no longer is set to the toolbar's minimum acceptable size. This is slightly different behavior than 2.6.2.
To fix this problem, we added code that sets toolbar initial toolbar sizes to whatever wxToolBar::GetBestSize() returns. Unfortunately, the size that is being returned by the class is too small (vertically). I don't know why.
At any rate, the way to get around this is to do your own wxToolBar::GetBestSize() call, then specify this size on your AddPane call with the BestSize parameter, while at the same time increasing the y parameter by the number of missing pixels.
I hope that wxToolBar::GetBestSize() on win32 can be fixed soon.
Either that, or you can check out the code that is doing the wrong calculation. It's called from wxAUI 0.9.2 on line 1293.
All the best,
Ben
bool CodeCompletion::BuildToolBar(wxToolBar* toolBar)
{
wxSize sz;
Manager::Get()->AddonToolBar(toolBar,_T("codecompletion_toolbar"));
m_Function = XRCCTRL(*toolBar, "chcCodeCompletionFunction", wxChoice);
m_Scope = XRCCTRL(*toolBar, "chcCodeCompletionScope", wxChoice);
m_Scope->Disable();
toolBar->Realize();
// Trying to fix toolbar hSize bug
sz = toolBar->GetBestSize();
sz.x += 30;
toolBar->SetBestFittingSize(sz);
return true;
}
void MainFrame::DoAddPluginToolbar(cbPlugin* plugin)
{
wxSize size = m_SmallToolBar ? wxSize(16, 16) : wxSize(22, 22);
wxToolBar* tb = new wxToolBar(this, -1, wxDefaultPosition, size, wxTB_FLAT | wxTB_NODIVIDER);
tb->SetToolBitmapSize(size);
if (plugin->BuildToolBar(tb))
{
SetToolBar(0);
wxSize sz;
sz = tb->GetBestSize ();
sz.x+=30;
sz.y++;
tb->SetBestFittingSize(sz);
...
}
...
}
svn:2936
After I open ANY from my already existing projects, atfer the parser thread finish (cpu usage falling to nearly zero) the C::B enter an INFINITE LOOP with hourglass cursor.
If I read the board right, the CodeCompletion upgrade wasn't done by the usualy C::B devs, but some cool guy with way too much skills and time ^^.
On other thing, I don't know if its just me, but the fonts in C::B aren't anti-aliased, is there a way to turn this on? I'm running on Kubuntu. I've tried changing the font settings to match those in Kate, but the text is still blocky and I cant tell the difference between a . and , or : and ; which is really frustrating.
If I read the board right, the CodeCompletion upgrade wasn't done by the usualy C::B devs, but some cool guy with way too much skills and time ^^.
Well, you read wrong.
The cool-guy-with-way-too-much-skills-and-time has provided a different standalone implementation (i.e. not a C::B plugin).
Bug: When you first run CB, you get a compiler box. If you select one, you get a [Default] button. If you select several ... wait, how could you set several compilers to the default? That listbox shouldn't be multiselect.fixed
[EDIT]
I found this in the change logs:
* Added handling of #if[[n]def] preprocessor blocks in code-completion's parser. Currently it accepts the #if part and ignores from the #el[se|if] (if it exists) up to the #endif. The special case "#if 0" will be handled later.
Does the fact that it ignores the #el[se|if] currently cause this (http://forums.codeblocks.org/index.php?topic=3872.msg31235#msg31235) (file is here (http://forums.codeblocks.org/index.php?topic=3872.msg31253#msg31253))?
[/EDIT]
[EDIT]
I found this in the change logs:
* Added handling of #if[[n]def] preprocessor blocks in code-completion's parser. Currently it accepts the #if part and ignores from the #el[se|if] (if it exists) up to the #endif. The special case "#if 0" will be handled later.
Does the fact that it ignores the #el[se|if] currently cause this (http://forums.codeblocks.org/index.php?topic=3872.msg31235#msg31235) (file is here (http://forums.codeblocks.org/index.php?topic=3872.msg31253#msg31253))?
[/EDIT]
Yes, and I 've fixed it (not committed yet).
My guess'd be you haven't had the time to commit it yet? It'd be really great if this was fixed
QuoteMy guess'd be you haven't had the time to commit it yet? It'd be really great if this was fixed
This fix is part of another bigger patch which needs a lot of testing before committing... It will come, don't worry ;).