Author Topic: The 16 January 2010 build (6088) is out.  (Read 181582 times)

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 16 January 2010 build (6088) is out.
« Reply #120 on: February 12, 2010, 12:52:32 am »
Thanks for reporting this, I can not reproduce the crash (on linux), but will try it on w2k (yes I also have it), but not today ( I have to go to bed).

The other problems are reproducible.
The cause seems to be that Ctrl+L deletes the actual line, this is the one with the fold, but does not unfold the block before.
I think it should either unfold the folded block, or delete it completely, and of course the caret should be visible in all cases.

You also report this issue at scintillas bug-tracker: http://sourceforge.net/tracker/?atid=102439&group_id=2439 .

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #121 on: February 12, 2010, 07:29:20 am »
Can you make an `Available macros` button in the forms where macros can be used? It will be very useful for users, especially for newcomers.  :P I mean `default code`, `search paths`, `toolchain` config pages and etc.
« Last Edit: February 12, 2010, 07:31:14 am by critic »

Offline yesno

  • Multiple posting newcomer
  • *
  • Posts: 19
Re: The 16 January 2010 build (6088) is out.
« Reply #122 on: February 12, 2010, 11:40:26 am »
(Maybe OT because it's for rev. 6155 rather than 6088)

If I compile the whole project all is fine like before, no errors but a bunch of warnings, most like
"comparison of unsigned with signed integer".
But if I try to start the application, I get this message from the OS:
"Die Anwendung konnte nicht richtig initialisiert werden (0xc0000005)"
(The application could not be initialized correctly (0xc0000005)),
no matter with or without the plugins.

The downloaded version 6088 (from here) runs fine and my version 5945 (self-compiled) too.

My OS is WinXP SP2, the compiler is MinGW 3.4.5 and the wxWidgets version is 2.8.10 (self-compiled).

Please give me a hint what I should do / where I should search.

Thanks in advance and with kind regards

yesno

PS C::B is the best IDE I've ever seen
« Last Edit: February 12, 2010, 11:43:11 am by yesno »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 16 January 2010 build (6088) is out.
« Reply #123 on: February 12, 2010, 12:05:33 pm »
You should either use a clean svn checkout, or clean the C::B project and the contrib-plugins workspace and manual delete th edevl and output directorires.
Make sure that the pch-files are deleted ( src/include/*.gch ).

Or try the clean-script posted by MortenMacFly here: http://forums.codeblocks.org/index.php/topic,11773.msg79887.html#msg79887

We updated the scintilla-version and had some other api-changes, that might lead to problems if older libs remain.

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #124 on: February 12, 2010, 12:08:35 pm »
Once again to Ctrl+Tab topic: in the IDE can be made browsing (forward and backward) as in internet browser (firefox, for example). This is much better then switching between last two tabs. Because of the code changes made by user browsing can be done with switching tabs only (without line positioning, though editing of the code before this line can be monitored by IDE and if it happens then reset positioning in that tab).

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: The 16 January 2010 build (6088) is out.
« Reply #125 on: February 12, 2010, 11:13:58 pm »
(Maybe OT because it's for rev. 6155 rather than 6088)

If I compile the whole project all is fine like before, no errors but a bunch of warnings, most like
"comparison of unsigned with signed integer".
But if I try to start the application, I get this message from the OS:
"Die Anwendung konnte nicht richtig initialisiert werden (0xc0000005)"
(The application could not be initialized correctly (0xc0000005)),
no matter with or without the plugins.

The downloaded version 6088 (from here) runs fine and my version 5945 (self-compiled) too.

My OS is WinXP SP2, the compiler is MinGW 3.4.5 and the wxWidgets version is 2.8.10 (self-compiled).

Please give me a hint what I should do / where I should search.

Thanks in advance and with kind regards

yesno

PS C::B is the best IDE I've ever seen

I also receive the 0xc0000005 (on Windows7) when starting CodeBlocks when compiled with mingw 3.4.5. Updating mingw to a 4+ version solved the problem.

Be sure to recompile wxWidgets before re-compiling CodeBlocks with a new mingw version.


 
« Last Edit: February 12, 2010, 11:18:28 pm by Pecan »

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #126 on: February 15, 2010, 07:45:18 am »
Can you make automatic addition of closing brace (`}`) only after pressing Enter, because in the following situation I need to delete it:

Before modification of code:

Code
if(something)
    doSomething();

After modification of code:

Code
if(something)
{// I printer opening brace and now I need to delete closing brace - because I want to use doSomething(); function in braces
   
}    doSomething();

Though I need the next:

Code
if(something)
{// I pressed enter after `if(something)` and printed opening brace only (editor doesn't know about doSomething(); function - is it must be in braces or no - I will specify it later)
    doSomething();

The closing brace I will print when needed (i.e. I will show the editor where it is required to place).

If I press Enter after `{` the closing brace can appear:

Code
if(something)
{
    // I pressed enter after opening brace (i.e. I don't want doSomething(); function to be in braces)
}
doSomething();

And else - if I printed opening brace on the same line with doSomething() function and then pressed enter the following will be correct:

Code
if(something)
{
    doSomething();
}

About classes: closing brace of classes and structs must be followed with `;`. Not it isn't.

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: The 16 January 2010 build (6088) is out.
« Reply #127 on: February 15, 2010, 08:09:17 am »
@critic


I can make a patch for this.But I am working for some cc bugs.Not sure when I can finish it. :D
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #128 on: February 15, 2010, 08:15:22 am »
@blueshake

Ok. Thanks for response. I'm a beta tester and only point on some defects in my opinion.

Else one defect in autocompletion of braces:
When I printing closing `"` (i.e. opening `"` already exists) I get `"""` instead of `""`.

Thanks for your work.

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #129 on: February 15, 2010, 01:21:29 pm »
I almost always use Custom Makefile option enabled (for Qt projects) and when I rebuild project the following take place:
Code

-------------- Clean: Debug in ExceptionViewer ---------------

mingw32-make.exe -f Makefile.Release clean
mingw32-make.exe -f Makefile.Debug clean
mingw32-make.exe -f Makefile.Debug
mingw32-make.exe[1]: Entering directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
del obj\Debug\moc\moc_exception_viewer.cpp
mingw32-make.exe[1]: Entering directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
del obj\Debug\moc\moc_exception_viewer.cpp
del obj\Debug\uic\ui_except_dlg.h
del obj\Debug\except_dlg.o obj\Debug\exception_viewer.o obj\Debug\main.o obj\Debug\moc_exception_viewer.o
del obj\Debug\uic\ui_except_dlg.h
mingw32-make.exe[1]: Leaving directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
del obj\Debug\except_dlg.o obj\Debug\exception_viewer.o obj\Debug\main.o obj\Debug\moc_exception_viewer.o
mingw32-make.exe[1]: Entering directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
d:\bin\dev\libs\qt\4.5.0\bin\uic.exe ..\..\..\..\our_libs\arm_kit\src\arm_kit\except_dlg.ui -o obj\Debug\uic\ui_except_dlg.h
g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\except_dlg.o ..\..\..\..\our_libs\arm_kit\src\arm_kit\except_dlg.cpp
mingw32-make.exe[1]: Leaving directory `D:/dev/projects/vvts3/arm/ExceptionViewer'
g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\exception_viewer.o exception_viewer.cpp
g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\main.o main.cpp
D:/bin/dev/libs/qt/4.5.0/bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -D__GNUC__ -DWIN32 exception_viewer.h -o obj\Debug\moc\moc_exception_viewer.cpp
g++ -c -Wall -g -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_THREAD_SUPPORT -I"d:\bin\dev\libs\qt\4.5.0\include" -I"..\..\..\..\our_libs\arm_kit\src" -I"d:\bin\dev\libs\Qt\4.5.0\include" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtCore" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtGui" -I"d:\bin\dev\libs\Qt\4.5.0\include\QtXml" -I"d:\bin\dev\libs\qt\4.5.0\include\ActiveQt" -I"obj\Debug\moc" -I"obj\Debug\uic" -I"d:\bin\dev\libs\qt\4.5.0\mkspecs\default" -o obj\Debug\moc_exception_viewer.o obj\Debug\moc\moc_exception_viewer.cpp
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -mthreads -Wl -o bin\Debug\ExceptionViewer.exe obj/Debug/except_dlg.o obj/Debug/exception_viewer.o obj/Debug/main.o obj/Debug/moc_exception_viewer.o  -L"d:\bin\dev\libs\qt\4.5.0\lib" -LD:\bin\dev\libs\Qt\4.5.0\lib -lQtCore4 -lQtGui4 -lQtXml4
mingw32-make.exe[1]: Leaving directory `D:/dev/projects/vvts3/arm/ExceptionViewer'


:\dev\projects\vvts3\arm\ExceptionViewer\obj\Debug\moc\moc_exception_viewer.cpp


:\dev\projects\vvts3\arm\ExceptionViewer\obj\Debug\uic\ui_except_dlg.h


:\dev\projects\vvts3\arm\ExceptionViewer\obj\Debug\except_dlg.o
exception_viewer.cpp: In member function `void arm::ExceptionViewer::onReadyRead()':
exception_viewer.cpp:39: warning: unused variable 'quitter'
Cleaned "ExceptionViewer - Debug"

-------------- Build: Debug in ExceptionViewer ---------------

Target is up to date.
Nothing to be done.


Build log appears in the `clean` section. Is it a bug? And else, C::B is freezed when rebuilding from begining of `clean` section till begining of `build` section, that is all time of rebuild process. When it became normal (not freezed) all log text appears and in build section - `nothing to be done`.
 

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #130 on: February 17, 2010, 06:28:01 am »
I want to requiest a new feature - adding files right to the virtual folders in the project's tree. Is it possible?

I use my libraries at sources level (without precompiled binaries .so or .dll, or .a) and that's why I need to add sources directly to project. When I add files to project from outside of project's directory all project's files names became large that is not friendly. But when I split these files in virtual folders - all OK - one virtual folder for each library.
Now, to add files to virtual folder I need to add them to project's root, then move them one by one to virtual folder created before. It will be better to allow multiple selection of files in project's tree for such operations and allow addition of files to concrete virtual folder as to the project's root node

Offline loopcoder

  • Single posting newcomer
  • *
  • Posts: 5
Bug: end-of-line comments confuse the symbol parser
« Reply #131 on: February 18, 2010, 04:54:39 pm »
As many "cross-platform-coders" I work on Linux and Windows at the same time.
The class browser (symbol pane) and the code completion do not work for me at all - and luckily I found the reason (just minutes before wiping C::B off my hard drive... ;) )

The parser cannot handle stream comments ("//"), if the EOL mode does not match the current OS (e.g. just CR in Windows). That is quite often the case, if you do the main development under a pleasant OS and want to make it work in a Windows environment...

Small sample: (save it to a unix file (just CR) )

class Foo {
public:
   int this_is_parsed;  // knock-out comment
   int oh_thats_bad;
}


That bug may also apply for other EOL modes (Mac..)


regards


 

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #132 on: February 19, 2010, 07:37:23 am »
I use UTF-8 charset and LF end of line - it works fine. Earlier I used cp1251 with CRLF - it worked fine too. CF is MAC end of line. If you work under windows and linux (not MAC), why do you choose CF?

EDIT:
May be it's charset and `end of line` incompatibility? Which charset do you use?
« Last Edit: February 19, 2010, 07:40:06 am by critic »

Offline loopcoder

  • Single posting newcomer
  • *
  • Posts: 5
Re: The 16 January 2010 build (6088) is out.
« Reply #133 on: February 19, 2010, 12:33:44 pm »
Yes, sorry, I have mixed up CR (\r)  and LF (\n).

The point is: the syntax parser does not work, if you have single line comments ("//...") in a mac file (CR) using C::B in Windows (maybe as well in other non-Mac systems).

If you share your files, such situations may occure.
I consider this as a bug, since you expect the parser / the class browser / the code completion to work in any environment and setting -- you will always blame the software, not your settings ;)
The syntax parser should accept both '\n' and '\r' as EOL. No big deal.    

Offline critic

  • Multiple posting newcomer
  • *
  • Posts: 93
Re: The 16 January 2010 build (6088) is out.
« Reply #134 on: February 24, 2010, 05:55:17 am »
@loopcoder
:)