User forums > Nightly builds
The 31 august 2006 build is out.
severach:
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.
Bug: When importing old projects, they must be detected by compiler number. Now that VS 2005 has been inserted, all compilers below that are now shifted by one. For example, my Borland C++ 5.5 projects are switched to VS 2005.
Configuration things that still need fixing with some excerpts from my C::B 1.0 RC2 .reg file:
The Platform SDK isn't detected and automatically added to the MSVT 2003 bin, include, lib, and resource-include folders. You might also add the %SDK%\Bin\win64 folder to the MSVT 2003 bin folder to cover up the CVTRES and LIB bug as described in the wiki. VS 2005 does get the SDK folders auto added so copy that code.
Borland-C++ 5.5: You are still using brcc32.exe which is completely defective and compiles very few modern .rc files. Please change it to the one in the SDK if available. Copy the command line from MSVT 2003.
"res_compiler"="c:\\Program Files\\Microsoft Platform SDK\\Bin\\RC.Exe"
"Compile Win32 resource file"="$rescomp $res_includes -fo$resource_output $file"
Borland-C++ 5.5: Link to Dynamic Library is a non working command line. This is as close as I can get. The .BCDEF file needs to be created manually and should in the future be created by Code::Blocks.
"Link object files to dynamic library"="$linker -Tpd $link_options $libdirs c0d32 $link_objects, $exe_output,, $libs,$exe_output.BCDEF, $link_resobjects"
DMC: The included RC compiler is no good. Use the same one as MSVT and BC above if available.
DMC: The SDK include & resource (not lib) should be added to the DMC folders.
Neither linker line works at all.
"Link object files to executable"="$compiler -L/subsystem:windows -WA -mn $link_options $link_objects -o $exe_output $libs $link_resobjects"
"Link object files to dynamic library"="$compiler -L/subsystem:windows -WD -mn $link_options $link_objects -o $exe_output $libs $link_resobjects"
OWC: Compiler Options: -3s. Noone is expecting register calling and Windows OWC libraries don't support it.
Linker: link386.exe
Since OpenWatcom and Borland-C produce exports names so far outside of the norm, the BCDEF file needs to be created to keep them in line.
"Link object files to dynamic library"="$linker -nologo -dll -out:$exe_output $libs $link_objects -def:$exe_output.BCDEF"
My command lines aren't perfect but they are a functional improvement over what is mostly non functional.
nix_BB:
The following code based on Takeshi's post has no effect, although I'm not sure if I've put it in the correct place. :P
Hopefully Mandrav will get out of bed soon and help figure this out. :D
--- Code: ---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;
}
--- End code ---
EDIT: Ok I was fiddeling in the wrong place.... The following code yeilds results but does not fix the bug. It merely shows an additional 30 pixels of the toolbar- hence the problem lies in GetBestSize. Anyone know another method of determinnig the minimum size of a toolbar?
--- Code: ---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);
...
}
...
}
--- End code ---
sque:
--- Quote from: nzoltan on August 31, 2006, 11:55:47 pm ---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.
--- End quote ---
I can confirm same bug from a clean svn rebuild. (2937)
Kazade:
I'm having lots of problems with the last 2 builds, I've had to downgrade to the build of the 29th August (and even then C::B crashes when I save as I mentioned before)
With the builds of the 30th and 31st C::B is crashing after about 10 seconds, I cant find a common cause it will just either, lock up with a timer, or in the case of the 31st build, send me into an infinite loop of debug crash handler windows all of which are also frozen.
It might be something to do with the symbols browser being integrated into the tabbed left bar as it only moved to there on the build of the 30th, downgrading to the 29th put it back where it was and I get no more unexplained crashes.
When is C::B going to go into a feature freeze and just focus on bug-fixes? It already has enough features for version 1 IMO far more than any other free IDE. The more features added just add more bugs and reduces stability, don't get me wrong I love C::B and the work you guys do is amazing, but it might be time to focus on bugs rather than features.
Luke.
Kazade:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version