User forums > Nightly builds
The 19 september 2006 build is out.
killerbot:
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26u_gcc_cb_wx2.6.3p2.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10.7z
For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26_gcc_cb_wx2.6.3p2.7z
The 19 September 2006 build is out.
- Windows : http://prdownload.berlios.de/codeblocks/CB_20060919_rev2982_win32.7z
- Linux :
http://prdownload.berlios.de/codeblocks/CB_20060919_rev2982_Ubuntu6.06.deb
http://prdownload.berlios.de/codeblocks/CB_20060919_rev2982_fc4+5.rpm
Resolved Fixed:
* [ Patch #1499 ] : To do list can cope now with doxygen style to do's
* Code snippets:
* Replaced Clear button with a control button
* Added options for searching: case sensitivity and type
* Removed extra padding around the tree control
Regressions/Confirmed/Annoying/Common bugs:
* toolbar-images-not-changing-state (is a wx problem/Win XP problem)
* menu items with icon not correctly aligned (since wx263)
Visitor:
I'm a new user of CodeBlocks (switching from Dev-C++) and for the past couple days I've been using the nighly builds of CodeBlocks (Including this build) to reorganize my code.
I've found a few quirks that may not technically be bugs, but are close enough that end users might consider them as such.
I was going to add some typecasts to a bunch of constants I have, so I was doing a search and replace to change ) to )) and then I was going to add the typecast to the front using S&R as well.
Rather than doing a big 'select' block and change them all at once, I was doing them one at a time by pressing the 'y' key or clicking on the 'yes' button on the message box.
While doing this, I noticed that if I pressed the 'y' key too quickly (to replace the match and go on to the next), I could some times get multiple replacements at a single spot. So instead of having )) I might have )))
Also, while retrying this experiment, I noticed several times that CodeBlocks would delete sections of my code. Not replacing stuff, but just deleting it. (I checked by saving the file and opening it with another editor. The code was gone, so it's not a display problem.)
I did this last experiment about 5 times and could do it consistantly. All I had to do was click my mouse button just an instant before the menu poped up again (while it was still doing the current replace) and a section of text would select and then when the menu popped up, the accidently selected code would disappear.
I know, I know... don't click before the menu pops up. But when you are in a hurry to change 100+ things through out the code, it happens.
These may not be genuine bugs. The program may be operating as intended, but a user having code unexpectedly deleted during a search & replace isn't going to look at it that way. We're going to look at it as a bug.
(Oh, and I'm doing this on an older P3-800 system. So it's just slow enough that the replace isn't happening 'instantly', hence there's enough time for me to click in between. On a faster modern system, the replace probably happens so fast that you developers wouldn't really have a chance to do this, without some really bad luck timing.)
Also, I don't know where to post this, but could you add a tiny feature... In the project pane, could it be possible to right-click on a section (source, header, sub-dir) to add a new file, instead of having to go through the menu options? Since the project tree has the sub-dirs, you could right click on it and just enter the filename and have it automatically created and placed in the right spot. That would be a bit more convenient during early development. You can add existing files that way, so it seems to make sense to be able to create new files that way too.
Of course, I know you are approaching 'feature freeze', so I certainly don't want to be responsible for a delay.
artoj:
There seems to be something weird going on with the menus.
OS: WinXP
Steps to reproduce:
1. Open Code::Blocks and some random file.
2. Right click on the editor and note the menu sizes
3. Click File menu and click it again.
4. Right click on the editor again, the menu size is different.
This has something to do with menu images because if you click on e.g. Tools menu on step 3 the result is as expected.
It's most likely a wxWidgets problem, I'll try to report it to them after I get a test case done.
Pecan:
--- Quote from: artoj on September 19, 2006, 09:52:26 pm ---There seems to be something weird going on with the menus.
OS: WinXP
Steps to reproduce:
1. Open Code::Blocks and some random file.
2. Right click on the editor and note the menu sizes
3. Click File menu and click it again.
4. Right click on the editor again, the menu size is different.
This has something to do with menu images because if you click on e.g. Tools menu on step 3 the result is as expected.
It's most likely a wxWidgets problem, I'll try to report it to them after I get a test case done.
--- End quote ---
I dont seem to have (or understand) the problem (winXP). The editor context menu resizes itself according to it's inserted or removed items.
takeshimiya:
--- Quote from: artoj on September 19, 2006, 09:52:26 pm ---There seems to be something weird going on with the menus.
OS: WinXP
Steps to reproduce:
1. Open Code::Blocks and some random file.
2. Right click on the editor and note the menu sizes
3. Click File menu and click it again.
4. Right click on the editor again, the menu size is different.
This has something to do with menu images because if you click on e.g. Tools menu on step 3 the result is as expected.
It's most likely a wxWidgets problem, I'll try to report it to them after I get a test case done.
--- End quote ---
I can reproduce, it's subtle for sure, and it haves to do with menu images for sure too.
Also, regarding menu items with icon not correctly aligned (since wx263) I want to note that this doesn't happens only in Windows, but on other platforms and other wxWidgets programs also.
The correct solution could come from wxWidgets, but in the meantime, transparent icons should suffice.
Navigation
[0] Message Index
[#] Next page
Go to full version