Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
Before you use a nightly make sure you understand how it works (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx289.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc421.7z
The 06 January 2009 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20090106_rev5382_win32.7z
- Linux :
none
Resolved Fixed:
- changed saving and restoring of colours for IncSearch nad HighlightOccurrences to make better use of sdk
- fixed wrong indexing of arrays in watches window, if gdb shows multiple occurrences as one, with the addition "<repeated xx times>"
- really fixed a parsing error with stream operator (<<) (see r5007)
- Applied patch by danselmi to fix automatic indentation after opening brace when the next non-white character is a closing brace
- remember logger pane size when toggling with F2 (modified patch of elie)
- If "Auto show/hide message pane" has changed in environment settings dialog, it will be used immediately (without restart of C::B)
- After compiling with message "Nothing to be done." message pane will be closed if "Auto show/hide message pane" is activated.
- Make sure that no deleted layouts remain in conf-file, if their amount decreased
- HexEdit:
* Code refactoring to prepare better architecture for parametrized views
* Added possibility to chage view modes: Bin/Hex, 1,2,4,8 Bytes, Big-Endian/Little-Endian (in editor only, not yet in value preview)
* Some svn properties update - ThreadSearch plugin : implemented the possibility to run many searches without deleting previous results
- changed directory-layout if codeblocks gets build with automake, to make it more compliant with the "Filesystem Hierarchy Standard"
- changed debian package-layout, to have arch-independent and arch-dependent files in different packages
- added wxsmith development headers and a wxsmith conf-file for pkgconfig
- added update-script for ChangeLog on linux-systems (needs to be called manually at the moment)
- added missing contrib-plugin names in debian control file
- added some missing headers to wxSmith's pkg-config list
- HexEdit: Added ability to change the way columns count is calculated
- Fixed: Build error under certain configurations (More to follow)
- HexEdit: Fixed calculation of address
- fixed bug in compiler autodetection for MinGW / gcc
- ThreadSearch: implemented the possibility to remove search results from list or tree control
- make sure that masterpath and extrapath of a toolchain executable come before default systempath in executables environment, to avoid conflicts with different versions with the same name
- Fixed: Build warning under GCC-4.3.x
- some better warning options for GCC
- fix for drag and drop-bug : default behaviour is now not to start DDE/IPC when running C::B from inside C::B, to avoid problems when debugging C::B itself
- upgraded to new wxscintilla version
- new feature : changebar
- renamed menu-entry for empty undo- and changebar-buffer to "Clear changes history", function names are changed accordingly
- Fixed: Menu option "Clear history" looses icon in File > Recent files & Recent projects
- Fixed: Few menu items enable/disabling
Regressions/Confirmed/Annoying/Common bugs:
- toolbar-images-not-changing-state (is a wx problem/Win XP problem)
Ubuntu 7.04 to 8.10 Amd64 tar.gz archive (containing '.deb' installers builds with wx288) can be found here (http://www.esnips.com/web/CodeBlocks) or here (http://www.archive-host.com/compteur.php?url=http://s3.archive-host.com/membres/up/1024301307/CodeBlocks/CB_20090105_802_rev5382_Ubuntu704-810_wx288_amd64tar.gz) (direct link).
I just uploaded the nightlies for debian to my server (http://apt.jenslody.de).
There's a bug with dragging highlighted text.
The text cannot be dropped anywhere unless the mouse is moved far away from the initial selection first.
Quote from: madscientist on January 07, 2009, 01:10:02 AM
There's a bug with dragging highlighted text.
The text cannot be dropped anywhere unless the mouse is moved far away from the initial selection first.
I can't reproduce this problem in my system.
To OP:
Thanks for sharing!
The Drag toolbar crash problem seems
fixed. so, I upgrade the wxmsw28u_gcc_cb_wx288 to wxmsw28u_gcc_cb_wx289, it works fine. still exists, so I should use wx288 instead.
Thank you! I will continue testing.
I think there is a bug when debugging. (I'm using windows XP and Mingw from TDragon.
My program was linked to the debug library of opencv. which are located in:
F:\test1\lib\***
the source file is located in
F:\opencv\src\cxcore\***
It seems that I can't set break points in the source file. GDB complaints that :
> break "F:/opencv/src/cxcore/cxarray.cpp:104"
No source file named F:/opencv/src/cxcore/cxarray.cpp.
Breakpoint 3 ("F:/opencv/src/cxcore/cxarray.cpp:104) pending.
>>>>>>cb_gdb:
But my source file is exactly named "F:/opencv/src/cxcore/cxarray.cpp", my program will call some function in the cxarray.cpp.
Also, another problem is I can't "step into" the source code. ( This functionality is available in the last svn release).
The problem seems happens in this SVN version. The last version works well as I can remember.
I search the forum and found some related discussion.
I download the zip from the thread:
http://forums.next.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390
And still it can't set break point in the DLL source file.
Some one can explain it?
Thanks.
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
Quote from: rhf on January 07, 2009, 04:55:17 PM
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
HI, Thanks for your hint. Actually, I already use the TDM's 4.3.2 TDM-2 2008-12-09 as you mentioned.
Maybe, it is related to the "setting break point in a header file" issue, maybe not, I'm not sure. :(
The problem seems comes from "How does the compiler and GDB handle with the path of source file".
I test the zip file from :
http://forums.next.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390
There are two build targets. One is a exe file. The other is a DLL file.
The exe file will load the DLL file when it runs. Both of these targets were build with Debug enabled. So, I think that in the "TestDLL.dll", there are some part to reference it's source file path.
I put the project in "C:\DebugTest"
main.cpp was located in "C:\DebugTest\TestApp"
dllmain.cpp was located in "C:\DebugTest\TestDLL"
But I can't set break point in the "dllmain.cpp".
GDB reported:
>>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.
It is very confused that sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB. (I'm not sure how does the linker handle the path related issue).
So, I'm totally lost in this problem :(, can someone give a clarification? Thanks.
Quote from: ollydbg on January 07, 2009, 05:38:32 PM
sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB.
Interesting. I have had the same problem debugging using relative paths. I now generally use absolute paths in my Search directories, and debugging seems to work much better. This sure looks like a bug, but I haven't been able to create a simple test case to demonstrate it
Quote from: ollydbg on January 07, 2009, 05:38:32 PM
GDB reported:
>>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.
The gdb-message is normal for shared libraries that are not yet loaded.
The breakpoint is pending means that it's address can not (yet) be resolved.
It will be reevaluated after the lib is loaded.
It has nothing to do with the step-into issue.
If the dll and the exe are compiled with C::B make sure you have not (accidently) unchecked "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings (rightmost tab) -> Advanced options... -> Others -> Use full path for source files (GDB workaround):".
Thanks jens.
I have this option enable by default.
see the attachment image.
I also enable the full compiler output, when compiling, the output are here:
-------------- Build: TestDLL in cb_debug_test ---------------
[ 50.0%] mingw32-g++.exe -Wall -g -ID:\SourceCode\Libraries\wxWidgets2.8\src\msw -c C:\DebugTest\TestDLL\dllmain.cpp -o .objs\TestDLL\dllmain.o
[100.0%] mingw32-g++.exe -shared -Wl,--out-implib=bin\libTestDLL.a -Wl,--dll .objs\TestDLL\dllmain.o -o bin\TestDLL.dll
Creating library file: bin\libTestDLL.a
Output size is 22.46 KB
-------------- Build: TestApp in cb_debug_test ---------------
[ 50.0%] mingw32-g++.exe -Wall -g -I. -ID:\SourceCode\Libraries\wxWidgets2.8\src\msw -c C:\DebugTest\TestApp\main.cpp -o .objs\TestApp\main.o
C:\DebugTest\TestApp\main.cpp: In function 'void LoadDllPlugin()':
C:\DebugTest\TestApp\main.cpp:103: warning: unused variable 'status'
[100.0%] mingw32-g++.exe -o bin\TestApp.exe .objs\TestApp\main.o -mwindows
Output size is 32.17 KB
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 1 warnings
When debugging the exe file, I still can't set break point in anywhere in the "dllmain.cpp".
If you have enough time, you could help to test the zip file in that thread. Thanks.
http://forums.next.codeblocks.org/index.php?action=dlattach;topic=4896.0;attach=1707
correct! setting break points in the code below works!
// a sample exported function
void __declspec(dllexport) MyFunction(const LPCSTR sometext)
{
/** SET BREAK POINT HERE VVVVVVVVVVV **/
MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION);
/** SET BREAK POINT HERE ^^^^^^^^^^^^ **/
}
The breakpoints can't be set in the function of DllMain.
[attachment deleted by admin]
Quote from: ollydbg on January 07, 2009, 06:36:58 PM
The breakpoints can't be set in the function of DllMain.
I can set breakpoints in any of the three functions dllmain.cpp and in MyFunction without problems.
And gdb stops there of course.
g++ is 4.2.1-dw2:
C:\Dokumente und Einstellungen\jens>g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --prog
ram-suffix=-dw2 --with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw --with-local-prefix=/mingw --enable-thread
s --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry --disable-sjlj-exceptions --enable-li
bstdcxx-debug --enable-cxx-flags=-fno-function-sections -fno-data-sections --enable-version-specific-runtime-libs --disable-boot
strap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)gdb is 6.7.50 on my XP partition:
GNU gdb 6.7.50.20071127
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
Iwill test it with gdb 6.8 on w2k too, this evening.
Quote from: jens on January 07, 2009, 07:36:46 PM
I can set breakpoints in any of the three functions dllmain.cpp and in MyFunction without problems.
And gdb stops there of course.
For me it still does not work. But I am using the GCC 3.4.5 compiler suite ang GDB 6.6 (otherwise I cannot debug into wx code). It seems an issue with the compiler/debugger version obviously... Oh dear... Should I really finally upgrade my dev frameworks?!
It is very interesting, when I renamed the project folder name from "C:\DebugTest" to "C:\DebugTest1".
Then I open the cbp file and debug without rebuild the project. Then the gdb complaint that: (I'm using the TDM-mingw version)
Command-line: D:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet -args bin/TestApp.exe
Working dir : C:\DebugTest1\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined in loaded symbols.
>>>>>>cb_gdb:
> show directories
Source directories searched: $cdir;$cwd
>>>>>>cb_gdb:
> directory C:/DebugTest1/
>>>>>>cb_gdb:
> break "C:/DebugTest1/TestApp/main.cpp:26"
No source file named C:/DebugTest1/TestApp/main.cpp in loaded symbols.
Breakpoint 1 ("C:/DebugTest1/TestApp/main.cpp:26) pending.
>>>>>>cb_gdb:
You can see when gdb started, it use the command line:
Command-line: D:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname -quiet -args bin/TestApp.exe
which has a parameter "-fullname", so I can't set break points in anywhere of the source file. Because the debug information in both exe and DLL file were reference to " C:\DebugTest\***".
As a workaround, I should rebuild the Target.
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp (working copy)
@@ -36,7 +36,10 @@
wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
m_VerStr = compiler->GetVersionString();
wxString pch_prepend;
- bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+// bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+ // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+ // compiler->GetVersionString() return is empty string
+ bool IsGcc4 = true;
// for PCH to work, the very first include dir *must* be the object output dir
// *only* if PCH is generated in the object output dir
Quote from: Loaden on January 08, 2009, 02:33:35 PM
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp (working copy)
@@ -36,7 +36,10 @@
wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
m_VerStr = compiler->GetVersionString();
wxString pch_prepend;
- bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+// bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+ // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+ // compiler->GetVersionString() return is empty string
+ bool IsGcc4 = true;
// for PCH to work, the very first include dir *must* be the object output dir
// *only* if PCH is generated in the object output dir
Do you think every MinGW user uses TDragon version ?
Dje
@Loaden:
please post the output of TDragons MinGW-gcc if called with "--version" on commandline.
EDIT:
No need to post it.
I found the problem and will commit a fix after some testing (most likely this evening).
Hi,
I have a debian etch, i have updated to 5382 revision this morning using jens repositories and i have a little problem: the mouse wheel does not work on editor window, its works however in all other windows so i think it could be related with new scintilla version. Has anybody experienced the same problem?
Thanks in advance.
P.S.: I am from spain so sorry about my english.
Quote from: Loaden on January 08, 2009, 02:33:35 PM
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp (working copy)
@@ -36,7 +36,10 @@
wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
m_VerStr = compiler->GetVersionString();
wxString pch_prepend;
- bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+// bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+ // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+ // compiler->GetVersionString() return is empty string
+ bool IsGcc4 = true;
// for PCH to work, the very first include dir *must* be the object output dir
// *only* if PCH is generated in the object output dir
This patch is not necessary. Run the following script at Script Console -
ShowInfo(GetCompilerFactory().GetCompilerVersionString(_T("gcc")))It should show you GCC version no. See following screenshot (showing result in my pc).
(http://img175.imageshack.us/img175/2937/gccverrz9.th.png) (http://img175.imageshack.us/my.php?image=gccverrz9.png)
I can't get the version use script.
and my config:
set PATH=%CD%\bin;%PATH%
set CPATH=%CD%\include;%CD%\lib\mingw\mingw32\4.3.2\include;%CD%\lib\mingw\mingw32\4.3.2\include\c++
set LIBRARY_PATH=%CD%\lib;%CD%\lib\mingw\mingw32\4.3.2
[attachment deleted by admin]
Quote from: Loaden on January 08, 2009, 06:18:19 PM
I can't get the version use script.
and my config:
set PATH=%CD%\bin;%PATH%
set CPATH=%CD%\include;%CD%\lib\mingw\mingw32\4.3.2\include;%CD%\lib\mingw\mingw32\4.3.2\include\c++
set LIBRARY_PATH=%CD%\lib;%CD%\lib\mingw\mingw32\4.3.2
If possible, you can try svn r5390 and see if the issue is fixed for you.
Quote from: dje on January 08, 2009, 02:37:27 PM
Do you think every MinGW user uses TDragon version ?
Dje
oh. this modify want report this question only.
Quote from: jens on January 08, 2009, 09:44:12 PM
If possible, you can try svn r5390 and see if the issue is fixed for you.
thans! I confirm this question exist also.
I can't give MinGW TDM-2's version with r5390.
Quote from: Loaden on January 09, 2009, 01:18:38 AM
Quote from: jens on January 08, 2009, 09:44:12 PM
If possible, you can try svn r5390 and see if the issue is fixed for you.
thans! I confirm this question exist also.
I can't give MinGW TDM-2's version with r5390.
please post the output of the gcc (C- not C++-executable) you have configured in toolchain executables tab, if called with "--version" on commandline.
Please call it with absolute path as configured in the settings:
<Compiler's installation directory>\bin\<C compiler> --versionMake sure you have not accidently added "bin" to the "Compiler's installation directory" in the settings !!
@jens
I test again. I'm using using svn5382, TDM GCC 4.3.2 GDB 6.8.3.
I set break points in each "case" of DllMain, but it can't work.
Only the break points in "MyFunction" works.
Quote from: ollydbg on January 09, 2009, 08:58:38 AM
@jens
I test again. I'm using using svn5382, TDM GCC 4.3.2 GDB 6.8.3.
I set break points in each "case" of DllMain, but it can't work.
Only the break points in "MyFunction" works.
Works here, too, but first after adding the declaration to "dllmain.h" and adding dummy code inside the case statements. The dummy code is not necessary to set breakpoint, but the pointer (the yellow triangle) is always on the return statement and you can not see which case statement is used.
Thanks, it works, setting breaking points in dummy code also works.
so, in the header file:
#ifdef __cplusplus
extern "C"
{
#endif
void MyFunction(const LPCSTR sometext);
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);
#ifdef __cplusplus
}
#endif
#endif
After add the dummy code in each case of DllMain.
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
static int a = 0;
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
// attach to process
// return FALSE to fail DLL load
a++;
break;
case DLL_PROCESS_DETACH:
// detach from process
a++;
break;
case DLL_THREAD_ATTACH:
// attach to thread
a++;
break;
case DLL_THREAD_DETACH:
// detach from thread
a++;
break;
}
return TRUE; // succesful
}
I can set break points in the line of "a++", and it works. Thanks.
Two small problems concerning translations :
within src/plugins/contrib/wxSmith/wxwidgets/defitems/wxsstatusbar.cpp
Lines 146 and 184 should probably use _("Variable width") instead of _T("Variable width")
within src/src/environmentsettingsdlg.cpp
Line 106, should use : SetLabel(_("Dynamic Data Exchange (needs application restart to take effect)"))
gd_on
Quote from: jens on January 09, 2009, 07:24:24 AM
please post the output of the gcc (C- not C++-executable) you have configured in toolchain executables tab, if called with "--version" on commandline.
Please call it with absolute path as configured in the settings: <Compiler's installation directory>\bin\<C compiler> --version
Make sure you have not accidently added "bin" to the "Compiler's installation directory" in the settings !!
Please get my Code::Blocks IDE from here: http://www.qpsoft.com/downloads/qpcb.exe
and test it.
[attachment deleted by admin]
@Loaden
In my system (windows XP, Official nightly build svn5382, TDM GCC 4.3.2 GDB 6.8.3. )
It returned the right number "4.3.2", just like Biplab's screenshot.
Your screen shot show that your use "gcc.exe" instead of "mingw32-gcc.exe", but by default, these values was "mingw32-gcc.exe".
I'm not sure what's the difference between "mingw32-***.exe" and "***.exe"? Thanks.
Hi, jens! I think i found the question. the 'Compiler's installation directory' can't support '$(CODEBLOCKS)', when i set this value to 'D:\ycdeng\qpcb\codeblocks\src\devel\bin', it's OK!
I hope you can fix it: not support $(CODEBLOCKS).
thanks!!
[attachment deleted by admin]
Quote from: Loaden on January 09, 2009, 02:55:25 PM
Hi, jens! I think i found the question. the 'Compiler's installation directory' can't support '$(CODEBLOCKS)', when i set this value to 'D:\ycdeng\qpcb\codeblocks\src\devel\bin', it's OK!
I hope you can fix it: not support $(CODEBLOCKS).
thanks!!
That's what I wanted to write just in the same moment.
Where and how do you set $(CODEBLOCKS) ?
Quote from: jens on January 09, 2009, 02:57:15 PM
Quote from: Loaden on January 09, 2009, 02:55:25 PM
Hi, jens! I think i found the question. the 'Compiler's installation directory' can't support '$(CODEBLOCKS)', when i set this value to 'D:\ycdeng\qpcb\codeblocks\src\devel\bin', it's OK!
I hope you can fix it: not support $(CODEBLOCKS).
thanks!!
That's what I wanted to write just in the same moment.
Where and how do you set $(CODEBLOCKS) ?
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=2979;image)
because the mingw install path is CB install path.
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=2983;image)
I saw the compiler path in toolchain executables, but I didn't know (until now) that the variable is set automatically to C::B's executable directory when it starts.
Shame on me. :oops:
But I think that can be fixed, too.
Later this afternoon, or in the evening.
Quote from: jens on January 09, 2009, 03:15:40 PM
But I think that can be fixed, too.
Later this afternoon, or in the evening.
Thanks you very much!
It seems that you forgot to update the maximum lexer constant in editorcolourset.cpp, making it impossible to use the proper lexer for the D programming language.
Patch for this and lexer_d.xml attached.
EDIT: Sorry, I missed that smart indent depends on the selected lexer. Patch updated
[attachment deleted by admin]
Hi, someone finds a bug in the Toolbar position.
See this thread
http://forums.next.codeblocks.org/index.php/topic,9890.msg69000.html#msg69000
I have verified that this bug exists in SVN5382.
Thanks.
Hi,
I have found that when dragging selected text beyond the actual extent of the editor area, there is not any auto-scroll, so one must drop the dragged selected text only on the visible area of the editor.
I remember, in some previous version of C::B, that auto-scroll worked as expected. Maybe it is because of the new scintilla version?
Regards
Hi,
I've got a problem compiling C::B as an rpm-package for current development version of Mandriva Linux 2009.1 distribution. I guess the problem is that when building rpm packages this distribution forces the use of GCC option -Werror=format-security and it produces several error messages like this:
wiz.cpp: In member function 'void Wiz::CopyFiles(cbProject*, const wxString&, const wxString&)':
wiz.cpp:757: error: format not a string literal and no format arguments
make[4]: *** [wiz.lo] Error 1
make[4]: Leaving directory `/home/olelukoie/rpmbuild/BUILD/codeblocks/src/plugins/scriptedwizard'
Is it possible to fix and make C::B compilable with this option? (As I said there are several other messages of the same error type).
Quote from: JMP on January 10, 2009, 08:26:11 PM
Hi,
I have found that when dragging selected text beyond the actual extent of the editor area, there is not any auto-scroll, so one must drop the dragged selected text only on the visible area of the editor.
I remember, in some previous version of C::B, that auto-scroll worked as expected. Maybe it is because of the new scintilla version?
Regards
Verified. I can
only drag the text to anywhere in the current view. auto-scroll can't work when dragging. But I don't think it's due to the new scintilla version. I can reproduce the bug in SVN5322.
Hi,
I also found that code completion toolbar (function location section) does not recognise functions defined in stored opened files(tabs). Only files opened during the current sesion are properly parsed and their functions located.
To reproduce this error, open first a project with multiple files, then open some files in the editor. Check that the code completion toolbar is locating all the functions in the files properly. Then "save everything" and exit C::B. Reopen C::B and select the last project. All opened files of the previous sesion are in the editor, but the code completion toolbar does not show any function.
Open some file of the project that was not already open. Code completion toolbar can locate the functions of this file, but not of the others.
By closing all tabs and opening again the files, code completion toolbar shows the functions properly.
Best regards
JMP
Quote from: Loaden on January 09, 2009, 03:18:14 PM
Quote from: jens on January 09, 2009, 03:15:40 PM
But I think that can be fixed, too.
Later this afternoon, or in the evening.
Thanks you very much!
Should now also work with environment and global (C::B) variables.
svn r5399
if you use slashs in the project name, like 'my/project/name' code blocks will create the folder name/my/project/name and creates the project there
and if you project's name ends with a slash it is stranger, it creates a '.cbp' foder and a '.cbp' project file
is this a bug?
Well,
project name is used for file names.
At least on windows, there is a list of forbidden chars in filenames such as:\/:*?"<>|
So if you think it is a bug, let's write to M$ :)
Dje
What about new components in wxSmith? Would be grate to have all of then inside. With full paletter it might become a real development toolkit. Also would be grate to have a menue, status bar and toolbar on the devlopment window.
Quote from: dje on January 15, 2009, 09:46:31 AM
Well,
project name is used for file names.
At least on windows, there is a list of forbidden chars in filenames such as:\/:*?"<>|
So if you think it is a bug, let's write to M$ :)
Dje
it happens on linux to
I think one solution could be just replace the slash, or whatever forbidden char, by some other char, like dash
Crash Report
-------------------
Error occured on Friday, January 16, 2009 at 11:24:16.
D:\CB_Pack\codeblocks\codeblocks.exe caused an Access Violation at location 619f37e7 in module D:\CB_Pack\codeblocks\codeblocks.dll Writing to location 7c9106ab.
Registers:
eax=7c9106ab ebx=079eff00 ecx=00000000 edx=7c910732 esi=0000001f edi=060186f8
eip=619f37e7 esp=079efdd0 ebp=079efdd0 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010212
Call stack:
619F37E7 D:\CB_Pack\codeblocks\codeblocks.dll:619F37E7 _Z11DumpLiteralR11SQObjectPtr
617FF8EC D:\CB_Pack\codeblocks\codeblocks.dll:617FF8EC _ZN12cbThreadPool11GetNextTaskEv
618010B4 D:\CB_Pack\codeblocks\codeblocks.dll:618010B4 _ZN12cbThreadPool14cbWorkerThread5EntryEv
100A2FFD D:\CB_Pack\codeblocks\wxbase28u_gcc_cb.dll:100A2FFD _Z22wxMutexGuiLeaveOrEnterv
100A3476 D:\CB_Pack\codeblocks\wxbase28u_gcc_cb.dll:100A3476 _ZN8wxThreadD1Ev
77C3A3B0 C:\WINDOWS\system32\msvcrt.dll:77C3A3B0 _endthreadex
7C80B50B C:\WINDOWS\system32\kernel32.dll:7C80B50B GetModuleFileNameA
Quote from: jens on January 14, 2009, 11:21:27 AM
Should now also work with environment and global (C::B) variables.
svn r5399
It's OK!, thanks!
Patch needed for Windows NON-PCH building of C::B main project.
Tim S
Index: src/sdk/macrosmanager.cpp
===================================================================
--- src/sdk/macrosmanager.cpp (revision 5406)
+++ src/sdk/macrosmanager.cpp (working copy)
@@ -12,6 +12,7 @@
#ifndef CB_PRECOMP
#include <wx/menu.h>
+ #include "cbworkspace.h"
#include "projectmanager.h"
#include "editormanager.h"
#include "logmanager.h"
Index: src/plugins/compilergcc/compilerMINGW.cpp
===================================================================
--- src/plugins/compilergcc/compilerMINGW.cpp (revision 5406)
+++ src/plugins/compilergcc/compilerMINGW.cpp (working copy)
@@ -18,6 +18,7 @@
#include <wx/filename.h>
#include <wx/filefn.h>
#include "manager.h"
+#include "macrosmanager.h"
#include "logmanager.h"
#include "compilerMINGWgenerator.h"
done
There are two bugs I found. (windows)
First bug:
Using gdb with "setting->debugger setting->Evaluate expression under cursor" enabled.
Then If I select a piece of code by drag mouse, then GDB complainted that "what is XXXXXXXXXXX....." and crashed. (which can be seem from the debugger log output window). I think the reason is that these select statements are too complex for GDB to evaluate. :(
Second bug:
thread search window.
See the screen shot below, The "keyword" control will be truncated if I reduce the length of this window. It is not convenient for a user with small screen resolution.
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=3036)
[attachment deleted by admin]
Hi Ollydbg
Concerning ThreadSearch limitation, I already saw it but I didn't find any good solution to solve it.
If that's annoying for you, you can hide the controls panel and use the the ThreadSearch toolbar that is very small.
The check box to uncheck in settings dialog is "Show search widgets in ThreadSearch Messages panel".
Dje
Thank you for the hint.
That's a workaround.
- Mac OS X:
http://prdownload.berlios.de/codeblocks/CB_20090106_rev5382_mac289.zip
Just the baseline, so no fixes to project templates wrt linking or anything...
The Universal Binary is built for Tiger, but should work on Leopard as well.
svn build rev 5416 (2009-01-22T08:26:41.171594Z) gcc 4.3.2 Windows/unicode
Can't edit this config, when i double click it, it's show nothing:
[attachment deleted by admin]
Please let's CodeCompletion support sort:
Index: plugins/codecompletion/codecompletion.cpp
===================================================================
--- plugins/codecompletion/codecompletion.cpp (revision 5422)
+++ plugins/codecompletion/codecompletion.cpp (working copy)
@@ -935,6 +935,8 @@
return -5;
}
+ arr.Sort();
+
// select tokens
MultiSelectDlg dlg(Manager::Get()->GetAppWindow(), arr, true);
if (dlg.ShowModal() == wxID_OK)
Quote from: Loaden on January 29, 2009, 03:24:38 PM
Please let's CodeCompletion support sort:
Don't you worry... we are already testing a patch that will enable way more than "just" sorting... ;-)
a bug
code:
template <typename X>
int Bugtest(X _x)
{
return sizeof(_x); //set breakpoint here
}
int main()
{
int t_ix = 1;
cout << Bugtest(t_ix) << endl;
char t_cx = '0';
cout << Bugtest(t_cx) << endl;
return 0;
}
on first break, open zhe disassembly window, can find the asm code like:
00417758 push ebp
00417759 mov ebp,esp
0041775B mov eax,0x4
00417760 leave
00417761 ret
current eip is 41775b
continue,
on second break, the current eip is 417750, but the disassembly window show the asm code is same as the first,
can't find the current asm code.
my english is pool, sorry
It seems that there's something wrong in the editor. I have reported in the thread. Some files can't be opened.
http://forums.next.codeblocks.org/index.php/topic,9986.0.html
Thank you very much.
Quote from: hying on February 01, 2009, 03:47:21 AM
a bug
code:
template <typename X>
int Bugtest(X _x)
{
return sizeof(_x); //set breakpoint here
}
int main()
{
int t_ix = 1;
cout << Bugtest(t_ix) << endl;
char t_cx = '0';
cout << Bugtest(t_cx) << endl;
return 0;
}
on first break, open zhe disassembly window, can find the asm code like:
00417758 push ebp
00417759 mov ebp,esp
0041775B mov eax,0x4
00417760 leave
00417761 ret
current eip is 41775b
continue,
on second break, the current eip is 417750, but the disassembly window show the asm code is same as the first,
can't find the current asm code.
my english is pool, sorry
I tested it, but there's no problem.
In first break, the disassembly code is like below:
00417758 push ebp
00417759 mov ebp,esp
0041775B mov eax,0x4
00417760 leave
00417761 ret
In second break, the disassembly code is like below:
00417744 push ebp
00417745 mov ebp,esp
00417747 sub esp,0x4
0041774A mov eax,DWORD PTR [ebp+0x8]
0041774D mov BYTE PTR [ebp-0x4],al
00417750 mov eax,0x1
00417755 leave
00417756 ret
So, it works fine in my computer. I'm using TDM-mingw.
Bug report:
windows XP.
Each time I double click on an entry in the "Symbols tree", It will always go the "variables node". See the screen cast here:
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
I think it shouldn't be changed.
Thanks.
planning on creating a new nightly tomorrow.
@developers : any commits you want in, now is the time ;-)
Quote from: ollydbg on February 01, 2009, 04:06:10 PM
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
Can't view... all I see is an empty page with the word "CodeBlocks"...?!
Mind posting a simple step-by-step instruction how to reproduce?
Quote from: MortenMacFly on February 01, 2009, 08:12:28 PM
Quote from: ollydbg on February 01, 2009, 04:06:10 PM
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
Can't view... all I see is an empty page with the word "CodeBlocks"...?!
Mind posting a simple step-by-step instruction how to reproduce?
I can view this flash video in both IE and Firefox under windows XP.
If you can't view that video, you can see two pictures.
When I double click on an "function entry" in "symbols panel" (First image).
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=3097)
the structure tree will automatically go to "variables" (Second image). Furthermore, If this window receive a "WM_PAINT" message to repaint itself, it will change to "variables".
(http://forums.next.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=3099)
Sorry for my poor English expression. :D
[attachment deleted by admin]
Quote from: MortenMacFly on February 01, 2009, 08:12:28 PM
Quote from: ollydbg on February 01, 2009, 04:06:10 PM
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
Can't view... all I see is an empty page with the word "CodeBlocks"...?!
Mind posting a simple step-by-step instruction how to reproduce?
In firefox, when you click the provided link, it automatically redirects to :
http://sites.google.com/site/studycodeblocks/Home/bug1.swf?attredirects=0
In your browser address bar, remove the "?attredirects=0" suffix and then you can view the swf file.
Alternatively, visit the following link for the same :
http://2670631209710576974-a-1802744773732722657-s-sites.googlegroups.com/site/studycodeblocks/Home/bug1.swf?attredirects=0&auth=ANoY7cqP_pyou6_Xmc1Gyuq4ZTCqKTf4PsqREQSb1HKEtnpIJyIT5zz7-AuwT94W09z9MbRcd1TFkkmoHzlwiAH1UYDocw0cHZhoPml_qUhCVdeuxzDCmmT29cY-QxUCZSkdiOi3CXNFiHd0DL6iDpOUglI5yrlP_2i96scBzQw7KmtaIMoizlwKGWm4qe6sOvcPoqlH63XwT5abwOIQ0nKsAh5Xic_f0g%3D%3D
PLEASE DO NOT TRY TO CLICK THE ABOVE LINK. JUST COPY IT AND PASTE IT IN YOUR ADDRESS BAR.I don't know why clicking does not work ! May be browsers trim the url !!
to ollydbg
in a VM xp, i install C::B 8.02, build that code, find the disassembly bug.
i install 5382 patch, rebuild that code, debug it, find the bug exist,
i download [tdm-mingw-1.812.0-f1.exe] (23.8 MB), and install in C:\Program Files\CodeBlocks\MinGW, the bug still exist.
i don't know what is difference your C::B.
Debugger name and version: GNU gdb 6.8
[attachment deleted by admin]
Quote from: hying on February 02, 2009, 04:07:05 AM
to ollydbg
in a VM xp, i install C::B 8.02, build that code, find the disassembly bug.
i install 5382 patch, rebuild that code, debug it, find the bug exist,
i download [tdm-mingw-1.812.0-f1.exe] (23.8 MB), and install in C:\Program Files\CodeBlocks\MinGW, the bug still exist.
i don't know what is difference your C::B.
Debugger name and version: GNU gdb 6.8
what does VM xp mean?
It works Ok in my system. see the two images below:
I use the same environment as you stated.
[attachment deleted by admin]
xp install in VMware Workstation.
Quote from: Saswat2603 on February 02, 2009, 03:59:57 AM
http://2670631209710576974-a-1802744773732722657-s-sites.googlegroups.com/site/studycodeblocks/Home/bug1.swf?attredirects=0&auth=ANoY7cqP_pyou6_Xmc1Gyuq4ZTCqKTf4PsqREQSb1HKEtnpIJyIT5zz7-AuwT94W09z9MbRcd1TFkkmoHzlwiAH1UYDocw0cHZhoPml_qUhCVdeuxzDCmmT29cY-QxUCZSkdiOi3CXNFiHd0DL6iDpOUglI5yrlP_2i96scBzQw7KmtaIMoizlwKGWm4qe6sOvcPoqlH63XwT5abwOIQ0nKsAh5Xic_f0g%3D%3D
I will for sure not click / open a cryptic link like that.
Please: Write a step-by-step instruction if you want help.
@ MortenMacFlyQuote from: MortenMacFly on February 02, 2009, 09:32:14 AM
Quote from: Saswat2603 on February 02, 2009, 03:59:57 AM
http://2670631209710576974-a-1802744773732722657-s-sites.googlegroups.com/site/studycodeblocks/Home/bug1.swf?attredirects=0&auth=ANoY7cqP_pyou6_Xmc1Gyuq4ZTCqKTf4PsqREQSb1HKEtnpIJyIT5zz7-AuwT94W09z9MbRcd1TFkkmoHzlwiAH1UYDocw0cHZhoPml_qUhCVdeuxzDCmmT29cY-QxUCZSkdiOi3CXNFiHd0DL6iDpOUglI5yrlP_2i96scBzQw7KmtaIMoizlwKGWm4qe6sOvcPoqlH63XwT5abwOIQ0nKsAh5Xic_f0g%3D%3D
I will for sure not click / open a cryptic link like that.
Please: Write a step-by-step instruction if you want help.
It's nothing CRYPTIC !!! It's the same link as ollydbg mentioned about the SWF file ::
Quote from: ollydbg on February 01, 2009, 04:06:10 PM
Bug report:
windows XP.
Each time I double click on an entry in the "Symbols tree", It will always go the "variables node". See the screen cast here:
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
I think it shouldn't be changed.
Thanks.
The cryptic URL is the actual location of the file ( i guess ! ).
Because, when you goto http://sites.google.com/site/studycodeblocks/Home/bug1.swf, you actually get redirected to http://sites.google.com/site/studycodeblocks/Home/bug1.swf?attredirects=0 and you see the blank code-blocks page.
When you remove the suffix "?attredirects=0" in the addressbar and <enter>, you visit the cryptic URL and the SWF file then starts playing !!
If you hate the cryptic URL, try removing the "?attredirects=0" after visiting the page and you can see the file.
Hi,
I'm not sure it is the good place to ask for a new feature, but I try here.
Is possible to have a vertical spited view (as it is implemented) but with two different files. With the rise of wide screen (24" and 30"), it is easy to have at least now two files to edit at the same time, and it would be helpful.
This feature exist in the Eclipse EDI.
regards.
EDIT: Sorry, I've just seen that this question have been posted in the Development forum.
Quote from: reptils on February 02, 2009, 03:30:49 PM
Hi,
I'm not sure it is the good place to ask for a new feature, but I try here.
Is possible to have a vertical spited view (as it is implemented) but with two different files. With the rise of wide screen (24" and 30"), it is easy to have at least now two files to edit at the same time, and it would be helpful.
This feature exist in the Eclipse EDI.
regards.
This feature will come (soon ?), we are still testing a patch that make it available.
But as any greater changes it has to be tested thoroughly and some minor issues have to be fixed, to make it work reliable.
Thank you for your quick reply :)
As I said in the "EDIT" part of my reply, I have seen in the "Development" forum, the topic associated to this feature. It is understandable it need to be tested.
I think this feature will be very very helpful, particularly for people who works with a large wide screen.
Quote from: killerbot on February 01, 2009, 07:41:04 PM
planning on creating a new nightly tomorrow.
@developers : any commits you want in, now is the time ;-)
Just added an important update. Hope this comes out in the next nightly.
I've added the following 2 options to make default encoding option clearer to user.
(http://img407.imageshack.us/img407/772/newencoptjz6.png)
Previous behaviour was broken as it used to fallback to System encoding on Windows and to UTF-8 on Linux/Mac. This behaviour was not consistent with the option.
I hope with this commit things will be much clear to choose. :)
it will be in. just finished the build :-)
to ollydbg:
i look the debug log like below:
----------------------------------
.....
>>>>>>cb_gdb:
> bt 30
#0 Bugtest<int> (_x=1) at E:\program\bugtest\main.cpp:7
#1 0x004013ce in main () at E:\program\bugtest\main.cpp:13
>>>>>>cb_gdb:
> info frame
Stack level 0, frame at 0x22ff4c:
eip = 0x41775b in int Bugtest<int>(int) (E:\program\bugtest\main.cpp:7); saved eip 0x4013ce
called by frame at 0x22ff70
source language c++.
Arglist at 0x22ff44, args: _x=1
Locals at 0x22ff44, Previous frame's sp is 0x22ff4c
Saved registers:
ebp at 0x22ff44, eip at 0x22ff48
>>>>>>cb_gdb:
> x/32xb 0x0
Cannot access memory at address 0x0
0x0: >>>>>>cb_gdb:
> info threads
* 1 thread 2100.0xa98 Bugtest<int> (_x=1) at E:\program\bugtest\main.cpp:7
>>>>>>cb_gdb:
> disassemble
Dump of assembler code for function _Z7BugtestIiEiT_:
0x00417758 <int Bugtest<int>(int)+0>: push ebp
0x00417759 <int Bugtest<int>(int)+1>: mov ebp,esp
0x0041775b <int Bugtest<int>(int)+3>: mov eax,0x4
0x00417760 <int Bugtest<int>(int)+8>: leave
0x00417761 <int Bugtest<int>(int)+9>: ret
End of assembler dump.
>>>>>>cb_gdb:
> cont
Breakpoint 2, Bugtest<char> (_x=48 '0') at E:\program\bugtest\main.cpp:7
P:/bugtest/main.cpp:7:90:beg:0x417750
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
_x = 48 '0'
>>>>>>cb_gdb:
> info registers
eax 0x30 48
ecx 0x0 0
edx 0x0 0
ebx 0x7ffda000 2147328000
esp 0x22ff40 0x22ff40
ebp 0x22ff44 0x22ff44
esi 0x16 22
edi 0x20 32
eip 0x417750 0x417750 <int Bugtest<char>(char)+12>
eflags 0x202 [ IF ]
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0
>>>>>>cb_gdb:
> bt 30
#0 Bugtest<char> (_x=48 '0') at E:\program\bugtest\main.cpp:7
#1 0x00401401 in main () at E:\program\bugtest\main.cpp:15
>>>>>>cb_gdb:
> info frame
Stack level 0, frame at 0x22ff4c:
eip = 0x417750 in int Bugtest<char>(char) (E:\program\bugtest\main.cpp:7); saved eip 0x401401
called by frame at 0x22ff70
source language c++.
Arglist at 0x22ff44, args: _x=48 '0'
Locals at 0x22ff44, Previous frame's sp is 0x22ff4c
Saved registers:
ebp at 0x22ff44, eip at 0x22ff48
>>>>>>cb_gdb:
> x/32xb 0x0
Cannot access memory at address 0x0
0x0: >>>>>>cb_gdb:
> info threads
* 1 thread 2100.0xa98 Bugtest<char> (_x=48 '0') at E:\program\bugtest\main.cpp:7
>>>>>>cb_gdb:
----------------------------------------------------------------
at second breakpoint, no run zhe disassemble cmd,
if i send the cmd to GDB, can see the log:
> disassemble
Dump of assembler code for function _Z7BugtestIcEiT_:
0x00417744 <int Bugtest<char>(char)+0>: push ebp
0x00417745 <int Bugtest<char>(char)+1>: mov ebp,esp
0x00417747 <int Bugtest<char>(char)+3>: sub esp,0x4
0x0041774a <int Bugtest<char>(char)+6>: mov eax,DWORD PTR [ebp+0x8]
0x0041774d <int Bugtest<char>(char)+9>: mov BYTE PTR [ebp-0x4],al
0x00417750 <int Bugtest<char>(char)+12>: mov eax,0x1
0x00417755 <int Bugtest<char>(char)+17>: leave
0x00417756 <int Bugtest<char>(char)+18>: ret
End of assembler dump.
>>>>>>cb_gdb:
--------------------------------------------------
i don't know why the disassemble cmd not autorun
@hying
I can confirm this bug (dissassemble command seems to be not send to debug).
It only happens, if I reach the breakpoint the first time and then step over it with "continue" ("STRG+F7" or "F8"), that means if the actual and the former breakpoint are at the same line in source-code. If I step over the breakpoint ("F7") and leave the source-code line, the next hit sends the dissassemble command.
Can you please file a bug-report at berlios, so it can't be lost ?
thank jens
my english is very pool, and i am a beginner, i don't know how to send the bug-report to berlios, sorry.
Quote from: hying on February 03, 2009, 08:22:16 AM
thank jens
my english is very pool, and i am a beginner, i don't know how to send the bug-report to berlios, sorry.
I submit this bug report. see here:
https://developer.berlios.de/bugs/?func=detailbug&bug_id=15209&group_id=5358
I also filed a bug (https://developer.berlios.de/bugs/?func=detailbug&bug_id=15210&group_id=5358) reporting the incorrect change of "symbols" panel we discussed before in this post (http://forums.next.codeblocks.org/index.php/topic,9873.msg69760.html#msg69760)