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_wx2812_gcc471-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc471-TDM.7z
And the exception handler dll (for better crash reports) : http://prdownload.berlios.de/codeblocks/exchndl_gcc471-TDM.7z
The 16 June 2013 build is out.
- Windows :
http://prdownload.berlios.de/codeblocks/CB_20130616_rev9158_win32.7z
- Linux :
none
Resolved Fixed:
- fix proper use and initialization of common controls on Windows
Regressions/Confirmed/Annoying/Common bugs:
As there are no linux related changes in svn (except 64 bit project-files, not used by automake bukd-system), I decided not to upload new packages.
Actual packages on my server are (still) svn r9156 :
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc17, fc18 and fc19) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .
The CC Test issue remains the same; it does not compile and continues to complain about http://forums.next.codeblocks.org/index.php/topic,18011.msg123242.html#msg123242 (http://forums.next.codeblocks.org/index.php/topic,18011.msg123242.html#msg123242).
Is there anything I could do about it? Oh I forgot to mention; the error is reported within Code::Blocks. I haven't tried to compile it with make.
P.S.: Unrelated to bug, related to development: How outdated SDK documentation is in BerliOS? I want to understand how Code::Blocks currently works. Something is causing my IDE to randomly crash under Debian and it's really annoying...too outrageous when you are in the middle of coding!
ToApolytoXaos: Try to disable CC for a while and tell us if the crashes are still there...
Quote from: ToApolytoXaos on June 16, 2013, 11:30:18 PM
P.S.: Unrelated to bug, related to development: How outdated SDK documentation is in BerliOS? I want to understand how Code::Blocks currently works.
Here is my suggestion if you would like to learn C::B source code:
1, try to build and debug C::B.
2, try to read the source code.
3, ask any questions here.
The most important thing is: C::B core can generate many events (like cbEvent or scintilla event), then the any C::B plugins can receive those event and do any thing they can in the event handler. ;)
Quote from: oBFusCATed on June 17, 2013, 02:05:02 AM
ToApolytoXaos: Try to disable CC for a while and tell us if the crashes are still there...
The problem is much more generic than I thought so...it affects other plugins as well. I have successfully compiled
CodeBlocks-unix.cbp, but upon compiling
ContribPlugins-unix.workspace as a whole, it would fail. After doing so, I have decided to compile each plugin separately. So far, It has stopped on
wxSmith (Unix) and now on
wxSmith - Contrib Items (Unix).
I will continue with every plugin and would let you know for sure.
UPDATE: I'm afraid it's almost the entire
ContribPlugins-unix.workspace with certain plugins as minor exceptions. Can someone provide feedback if he or she deals the same issue?
looks like you'll have to recompile Code::Blocks ToApolytoXaos
Deleting the .gch files should work as well... (src\.objs\include)
At least that's what you'll have to do once the sdk changes. (or your compiler)
@White-Tiger: that would not help; my repository is freshly checked out.
I have the same problem . C::B with contrib plugins compile fine with make
but gives compile error when building plugins from C::B itself.(linux mint 15)
in prep.h
const bool linux = (id == platform_linux);
"linux" is probably defined as a preprocessor token and hence the error.
I also vaguely remember some talk about this but can't remember where it was
now. I am not linux savvy enough to pinpoint the problem but this should be
sorted out.
Add -ansi to all projects that fail.
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
What green highlight? Screenshots please!
Here you go:
http://pasteboard.co/qFM5yrH.png (http://pasteboard.co/qFM5yrH.png)
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ? ;)
Since svn9128 if that helps.
I found some possible improvements:
Quote1- FILES WITHOUT TARGETS
'CodeBlocks r9156'
- 'sdk\nullptr.cpp'
- 'wxsmith\debuggersettingspanel.wxs'
'CC Test' : 'src\plugins\codecompletion\'
- 'cctest\test.h'
'wxSmith' : 'src\plugins\contrib\wxSmith\'
- 'wxwidgets\defitems\wxsmediactrl.cpp'
- 'wxwidgets\defitems\wxsmediactrl.h'
'Tools Plus Plugin' : 'src\plugins\contrib\ToolsPlus\'
- 'update.bat'
2- TO AVOID WARNING XGETTEXT :
FILES CONTAINING _("") TO REPLACE _T("") OR wxT("")
'CodeBlocks r9156'
- 'src\scriptingsettingsdlg.cpp' : L128
'wxWidgets - Contrib Items' : 'src\plugins\contrib\wxContribItems\'
- 'wxSpeedButton\wxSpeedButton.h' L73, L89, L90, L107
'wxSmith' : 'src\plugins\contrib\wxSmith\'
- 'wxwidgets\defitems\wxsimagelist.cpp' L206
- 'wxwidgets\properties\wxsimagelisteditordlg.cpp' L1213
'wxSmith - Contrib Items' : 'src\plugins\contrib\wxSmithContribItems\'
- 'wxled\wxsLcdWindow.cpp' L33
- 'wxled\wxsLedNumber.cpp' L34
- 'wxled\wxsLedPanel.cpp' L48
- 'wxspeedbutton\wxsSpeedButton.cpp'L80:
- 'wxtreelist\wxsTreeListCtrl.cpp' L142, L150, L318, L410, L476
'wxSmithAui - wxAUI' :'src\plugins\contrib\wxSmithAui\'
- 'wxAuiManager\wxsAuiManager.cpp' L108, L116
'FileManager Plugin' : 'src\plugins\contrib\FileManager\'
- 'directorymonitor.cpp' L518
'ThreadSearch' : 'src\plugins\contrib\ThreadSearch\'
- 'ThreadSearch.cpp' L656, L660
- 'ThreadSearchLoggerBase.cpp' L52
3- FILES CONTAINING wxT("blabla") TO REPLACE _("blabla")
'src/plugins/compilergcc/compileroptionsdlg.cpp'
L2851, L2875
'src/plugins/contrib/BrowseTracker/ConfigPanel.cpp' (from wxFormBuilder)
L27, 39, 42, 50, 52, 61, 63, 72, 84, 86, 92
'src/plugins/contrib/SpellChecker/ThesaurusDialog.cpp'
L44, 53, 65
'src/plugins/contrib/codesnippets/Search/SearchInPanel.cpp'
L35, 37, 39
'src/plugins/contrib/codesnippets/Search/ThreadSearch.cpp'
L411, 448, 449, 459, 460, 604
'src/plugins/contrib/codesnippets/Search/ThreadSearchConfPanel.cpp'
L44..63, 69, 75, 81, 87, 124, 125, 303,
'src/plugins/contrib/codesnippets/Search/ThreadSearchConfPanel.h'
L47, 52
'src/plugins/contrib/codesnippets/Search/ThreadSearchLoggerList.cpp'
L150, 167, 249, 142, 158
'src/plugins/contrib/codesnippets/Search/ThreadSearchView.cpp'
L73, 76, 77, 80, 295, 296, 837, 838
'src/plugins/contrib/codesnippets/codesnippets.cpp'
L1816
'src/plugins/contrib/codesnippets/codesnippetsapp.cpp'
L431..434, 548..550, 576, 582
'src/plugins/contrib/codesnippets/codesnippetstreectrl.cpp'
L855, 1775...1777, 1868..1870
'src/plugins/contrib/codesnippets/CodeSnippetsWindow.cpp'
L970, 1480..1482, 1515..1540
'src/plugins/contrib/codesnippets/editor/DragScrollCfg_H.cpp'
L26....128
'src/plugins/contrib/codesnippets/SettingsDlg.cpp'
L58
'src/plugins/contrib/codesnippets/SettingsDlgForm.cpp'
L32....121
'src/plugins/contrib/codesnippets/SnippetPropertyform.cpp'
L54....86
'src/plugins/contrib/codesnippets/SnippetPropertyform.h'
L73
'src/plugins/contrib/dragscroll/dragscrollcfg.cpp'
L15....127
'src/plugins/contrib/keybinder/cbkeybinder.cpp'
L351, 518, 563, 624..628, 736
'src/plugins/contrib/keybinder/keybinder.cpp'
L1941....1987, 2002.....2072, 2768..2778
'src/plugins/contrib/keybinder/keybinder.h'
L1342, 1351
copy the attached file.
Please post patches at the project page in berlios.de.
http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29
Quote from: ToApolytoXaos on June 18, 2013, 12:33:45 PM
Since svn9128 if that helps.
Does it mean that 9128 is bad and 9127 is good?
Or is 9128 the first revision where you recognized the issue ? If yes which was the last good one (if you still know) ?
Or is 9128 the last good revision you know and a later one is bad ?
For the build issue (prep.h etc.), I also see it when using the C::B workspace-file on linux.
I will look into it.
Quote from: LETARTARE on June 18, 2013, 05:41:30 PM
I found some possible improvements:
I saw that the attached file is not a patch. Can you try to provide a patch, please? Its very simple! just checkout the sources, then change the lines as needed and then issue the following command in the root folder of your svn-controlled working copy of C::B:
svn diff > translation_issues.patch(Assuming that you have the svn command line tools installed, if not, please do so before and point to the svn executable.)
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
@MortenMacFly
thank you.
yes indeed I know, but for extensions, I thought he had the agreement of the author.
The files without target, what to do ?
Quote from: LETARTARE on June 18, 2013, 08:22:29 PM
The files without target, what to do ?
What exactly do you mean by that?
If the file is not existent in SVN, do:
svn add the_filebefore the
svn diff command.
Quote from: oBFusCATed on June 18, 2013, 01:17:08 AM
Add -ansi to all projects that fail.
I am not on my computer right now, but attached is an easy commit for someone.
Quote from: MortenMacFly on June 18, 2013, 08:12:21 PM
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
I have occasionally observed this under Linux. It is most likely something to do with smart tab jump, but I have not yet had time to see if I can figure out what.
Quote from: Alpha on June 18, 2013, 08:50:02 PM
Quote from: oBFusCATed on June 18, 2013, 01:17:08 AM
Add -ansi to all projects that fail.
I am not on my computer right now, but attached is an easy commit for someone.
I just committed a similar patch to all linux project-files (wx2.8 and 2.9).
I hope it fixes the build issue not only for me.
Quote from: Alpha on June 18, 2013, 08:50:02 PM
Quote from: MortenMacFly on June 18, 2013, 08:12:21 PM
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
I have occasionally observed this under Linux. It is most likely something to do with smart tab jump, but I have not yet had time to see if I can figure out what.
The green highlight colour occurs immediately if "Brace completion" is on and I type the left parenthesis (round bracket, neither square nor curly bracket). It highlights the right parenthesis and if I type a doublequote, it also highlights the right quote and all characters I type between it and the right parenthesis.
To reproduce:
- "Brace completion" checked in the settings.
- In the editor type printf( followed by ".
- You get printf("|") (the pipe-symbol is the caret's place).
- The right quote and the right parenthesis are green highlighted.
- Type another " .
- Now you get printf(""|) .
- All characters you type now are also green highlighted until you type (e.g.) another quote or a right parenthesis
Quote from: jens on June 18, 2013, 07:39:05 PM
Quote from: ToApolytoXaos on June 18, 2013, 12:33:45 PM
Since svn9128 if that helps.
Does it mean that 9128 is bad and 9127 is good?
Or is 9128 the first revision where you recognized the issue ? If yes which was the last good one (if you still know) ?
Or is 9128 the last good revision you know and a later one is bad ?
Yes, 9128 is the first revision where I have found out this issue by accident. I don't remember such issue before.
Quote from: MortenMacFly on June 18, 2013, 08:12:21 PM
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
What platform, btw? I cannot reproduce on Windows, at least. I've used exactly the code you have shown...?!
On Debian testing with latest updates MortenMacFly.
Quote from: jens on June 18, 2013, 10:11:15 PM
To reproduce:
- "Brace completion" checked in the settings.
- In the editor type printf( followed by ".
- You get printf("|") (the pipe-symbol is the caret's place).
- The right quote and the right parenthesis are green highlighted.
- Type another " .
- Now you get printf(""|) .
- All characters you type now are also green highlighted until you type (e.g.) another quote or a right parenthesis
Actually, to reproduce it, try to use
printf() as you have shown on third point, but instead of typing another double quote, use your right arrow to move your cursor next to right quote, add a comma to add your variable parameter and see the green highlight persisting to continue.
NOTE: You can try the same with
std::cout << ("") and as soon as you use right arrow and enter comma next to double quote, it does exactly the same.
svn r9078 seems to be the first bad revision ("* SDK: major update to core component wxScintilla: Pumped underlying scintilla to v3.3.1").
OK, the svn9161 that I have currently compiled produces the same issue.
When you run the updates, can you please tell me which plugin or part of project should I compile within C::B, so I could save a bit of CPU cycles and unnecessary energy?
Another thing is that when I run C::B within terminal without & at its end, I can see how parser works and works pretty fast, actually faster than loading the IDE from "run" command and use it accordingly. Usually with the latter option, most of the times parser would hang and force me to reparse the entire project which is a bit of annoying.
Is there a reason for such behavior?
Quote from: LETARTARE on June 18, 2013, 05:41:30 PM
I found some possible improvements:
Thanks for the contribution, as some devs said before, we need patch files.
Quote1- FILES WITHOUT TARGETS
'CC Test' : 'src\plugins\codecompletion\'
- 'cctest\test.h'
I think this is by design, E.g. some code snippet cause our Parser hang. To debug this kind of issue, we use a CCTest project, and you just simply copy the code snippet to "test.h", and let the CCTest app to parse it. Now, if "test.h" cause Parser hang issue, then we even can't open CCTest correctly.
@mortenmaclfy
QuoteIf the file is not existent in SVN, do:
svn add the_file
Files without targets are either an oversight or a desire for the author ?
Should we add them (but what target?) Or remove it?
A developer knows better than me.
@ollydbg
thank you for this last explanation, I discovered.
For other changes I'll try to do several patchs.
Hello Everybody.
Since the last 2 nightlys I recognize a change how namespaces are displayed in the symbol browser.
If I have the following source-example:
namespace a {
namespace b {
};
};
using namespace b;
The namespace b will be displayed on toplevel what not happens in this example:
namespace a {
namespace b {
};
};
In both examples the namespace b will displayed as child of namespace a also. It seems that using namespace will be analysed like a lonly namespace if it is placed after the closing } of namespace a. This happens not if it is placed after the closing } of namespace b like here:
namespace a {
namespace b {
};
using namespace b;
}
Is this the wanted behaviour?
I use the official nightlies on Windows XP SP3 and this behaviour occures since 9156.
BestRegards,
Eckard Klotz.
First of all, you don't need semicolon at the end of namespace.
I would suggest to avoid doing something like
namespace a {
namespace b {
}
using namespace b;
}
because, with this way, if you have declared variables or classes that use the same name to both namespaces, the using directive will hide the outer namespace's names, thus causing nightmares detecting what the hell is going on with your code.
Here's what I have tested myself and works just fine.
#include <iostream>
namespace a
{
int i = 0;
namespace b
{
int i = 0;
}
}
int main()
{
std::cout << "a::i = " << a::i << '\n';
a::i++;
std::cout << "a::i = " << a::i << '\n';
std::cout << "a::b::i = " << a::b::i << '\n';
a::b::i++;
std::cout << "a::b::i = " << a::b::i << '\n';
return 0;
}
Please note that I explicitly use using::declaration rather than using-directive for the reasons I have stated above.
Quote from: jens on June 18, 2013, 06:40:06 AM
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ? ;)
Update: Issue remains with svn9161. To reproduce it, type
("") << ("") << (""), go to the most right bracket pair and use your left arrow to move towards the first pair. See how the right double quotes get highlighted all together.
(http://i40.tinypic.com/ekjipl.png)
Hello ToApolytoXaos
Thankyou for your tip.
To be honest I don't uses namespaces for functional reasons but for a better display in the C::B symbol-browser. Unfortunatly all classes wil be displayed on top level even if they are child-classes of other classes. Only nested namespaces where displayed nested in the past. Thus I put around every class a namespace and and put a using-line at the end of the associated header. You are absolutly right, if you say that this is a very confusing behaviour. But is there an other posibility to avoid long lists in the symbol-browser?
I would expect that only parentless classes or classes where the parents are not defined in project-sources would be displayed on toplevel. I would expect child classes under there parents. Alternativly an user specified folder-system (like they have implemented in Dev-C++) would be nice that gives the user the posibility to sort all ellements in the symbol-browser acording to his own wishes. This would be extreemly helpfull in c projects where in C::B all functions of a project are displayed in a long list as well as all variables all preprocessor-definitions all...
Best regards,
Eckard Klotz.
Quote from: ToApolytoXaos on June 20, 2013, 04:39:14 PM
Quote from: jens on June 18, 2013, 06:40:06 AM
Quote from: ToApolytoXaos on June 18, 2013, 01:31:02 AM
I have compiled it with make and works fine. I hope certain issues do not exist with 9158, like the green highlight color when you insert for example double quotes and you continue typing, it remains highlighted until to enter semicolon at the end of your current line, or use the arrows to interrupt it.
Since which revision do you get this ?
Might it be related to newer scintilla sources ?
Probably a new feature ? ;)
Update: Issue remains with svn9161. To reproduce it, type ("") << ("") << (""), go to the most right bracket pair and use your left arrow to move towards the first pair. See how the right double quotes get highlighted all together.
(http://i40.tinypic.com/ekjipl.png)
I was not clear enough, that's what I wanted to say:
Quote from: jens on June 19, 2013, 12:38:33 AM
svn r9078 seems to be is the first bad revision ("* SDK: major update to core component wxScintilla: Pumped underlying scintilla to v3.3.1").
I did a bisecting, so I'm sure it starts with this revision !
Quote from: eckard_klotz on June 20, 2013, 05:30:36 PM
Hello ToApolytoXaos
Thankyou for your tip.
To be honest I don't uses namespaces for functional reasons but for a better display in the C::B symbol-browser. Unfortunatly all classes wil be displayed on top level even if they are child-classes of other classes. Only nested namespaces where displayed nested in the past. Thus I put around every class a namespace and and put a using-line at the end of the associated header. You are absolutly right, if you say that this is a very confusing behaviour. But is there an other posibility to avoid long lists in the symbol-browser?
I would expect that only parentless classes or classes where the parents are not defined in project-sources would be displayed on toplevel. I would expect child classes under there parents. Alternativly an user specified folder-system (like they have implemented in Dev-C++) would be nice that gives the user the posibility to sort all ellements in the symbol-browser acording to his own wishes. This would be extreemly helpfull in c projects where in C::B all functions of a project are displayed in a long list as well as all variables all preprocessor-definitions all...
Best regards,
Eckard Klotz.
Can you please Eckard provide an example with your issue? I would like to test it on my system.
@jens: That makes things much clearer now :) thanks.
Quote from: ToApolytoXaos on June 20, 2013, 04:39:14 PM
(http://i40.tinypic.com/ekjipl.png)
Well sorry to say that, but not for me. Here it works as expected - at least on Windows (see attached image).
I do have some patches concerning Scintilla applied though, but they they should
not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
Quote from: MortenMacFly on June 21, 2013, 06:59:30 AM
Quote from: ToApolytoXaos on June 20, 2013, 04:39:14 PM
(http://i40.tinypic.com/ekjipl.png)
Well sorry to say that, but not for me. Here it works as expected - at least on Windows.
I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.
Quote from: jens on June 21, 2013, 07:02:04 AM
Quote from: MortenMacFly on June 21, 2013, 06:59:30 AM
Quote from: ToApolytoXaos on June 20, 2013, 04:39:14 PM
(http://i40.tinypic.com/ekjipl.png)
Well sorry to say that, but not for me. Here it works as expected - at least on Windows.
I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.
The issue does not occur on windows.
I will look into it, later.
eckard, I have downloaded the source files you have posted here and try to compile them. Obviously I'm doing something wrong ( lol ), but that's not the point.
I have created a new C::B project and imported your code and saw what you said about namespaces and classes. I hope I'm wrong, but seriously something's going on with Symbols' mechanism. It would show a namespace and when I double click it, instead of taking me to the actual namespace, it sends me on the first line of source file.
@devs: Which project should I look for Symbols? Is it part of SDK or as a plugin?
Hello ToApolytoXaos.
QuoteObviously I'm doing something wrong ( lol )
Sory I didn't mention that you have to use some preprocessor defines for the project to compile it. They are described in the readme. But especially for those things I planed to post my C::B project files in the future also. Furthermore you need the current boost-library (1.53) also since I use the spirit parser from it.
QuoteIt would show a namespace and when I double click it, instead of taking me to the actual namespace, it sends me on the first line of source file.
Sory again, I did forget to mention this also. So let confirm me that also. Furthermore you will se that I use the namespace
boost in the file
prs_tpdef.h. But even I don't define this namespace somewhere else (this will bedone in the spirit files wich are not part of my project) it is shown in the symbol browser.
Best regards,
Eckard.
@MortenMacFly: Why "rename symbols" does not always work? It has a very peculiar behavior. "Symbol not found under cursor!" and other times it would let me rename my desired symbols.
It's one of those WTF moments...:D honestly!
I have found a couple of bugs in the toolbar docking system, let's see if you can reproduce this:
BUG 1: reappearing toolbars
---------------------------
- make a fresh install under Windows (removing previous default.conf)
- undock one (or more) toolbars, and close them clicking on their close button
- undock another toolbar, and the ones you closed before reappear again (undocked and apparently in their same position as before being closed)
BUG 2: docking beyond window width
--------------------------------------
- Close all toolbars but code completion, main and compiler
(use the menu so that they won't reappear)
- Undock main and compiler toolbars, leave code completion at the left
- Redock both toolbars. Even if you try to place them under code completion toolbar, they are always added at its right. With my current window width (non fullscreen), I can't even see the rightmost toolbar.
Can't reproduce both problems on Linux.
What happens if you use View -> Toolbars -> Fit toolbars or View -> Toolbars -> Optimize ?
What windows are you using?
I'm now on Windows XP, I'll try it under Vista later.
Fit Toolbars and Optimize Toolbars seem to work reasonably well. There were a couple of times when a toolbar had a small part of it outside the window width, but I can't find a sure way to reproduce it. I wouldn't worry too much about that though.
None of these options seems to have any effect on undocked toolbars.
Quote from: carra on June 27, 2013, 02:14:22 PM
None of these options seems to have any effect on undocked toolbars.
This is good, because the fit/optiomize commands are only for docked toolbars:)
Lol! I meant that after using them the undocked bars bugs kept happening just the same ;)
Unfortunately someone running windows should try to see if he/she can reproduce it and then debug it.
Quote from: jens on June 21, 2013, 10:20:34 AM
Quote from: jens on June 21, 2013, 07:02:04 AM
Quote from: MortenMacFly on June 21, 2013, 06:59:30 AM
Quote from: ToApolytoXaos on June 20, 2013, 04:39:14 PM
(http://i40.tinypic.com/ekjipl.png)
Well sorry to say that, but not for me. Here it works as expected - at least on Windows.
I do have some patches concerning Scintilla applied though, but they they should not affect this functionality.
I can apply them for testing, but I am not sure if this is fine for all...?!
I will test it on windows also (hopefully this weekend), but it might be a gtk-issue, so it would probably be better to wait.
The issue does not occur on windows.
I will look into it, later.
Sorry, but I will disappoint you now. I am on Windows at work with svn-9138 and the issue remains the same.
(http://i39.tinypic.com/eo8wp.png)
Quote from: ToApolytoXaos on June 28, 2013, 07:11:48 AM
Sorry, but I will disappoint you now. I am on Windows at work with svn-9138 and the issue remains the same.
(http://i39.tinypic.com/eo8wp.png)
Ditto . It's pretty annoying...
Quote from: golgepapaz on June 28, 2013, 10:27:55 AM
Ditto . It's pretty annoying...
If that is already annoying for you, I hope you will never come in touch with real problems in your life.
This is getting really interesting...the issue (with bracket-matching highlighting) remains the same on both Debian jessie and windows.
(http://i44.tinypic.com/2mhynuh.png)
The issue should be fixed in trunk (svn r9171).
The cause was an incorrect use of IndicatorClearRange in void cbStyledTextCtrl::HighlightRightBrace().
IndicatorClearRange takes a position as first and a length as second parameter, but a position was given for both.
If position + length is greater than the documents length the indicators will not be cleared.
This behaviour has changed with the revision of scintilla we use since our svn r9078.
Older scintilla has cleared the indicators anyway.
That's why it happened since this commit.
Can you please test and give feedback.
By the way one of the green indicators is okay and used by the so called SmartTabJump-feature.
Thank you jens. It seems the issue kind of got solved. Another issue exists now.
Take a look at the standard coding I use to produce the issue:
() << () << (). As soon as I start moving from far left to right and reach the first << my first pair of parentheses highlight its right one. As you move along, the same repeat itself.
()| << () << () << ()
-------^ /* this is the blinking cursor supposedly */
Quote from: ToApolytoXaos on July 02, 2013, 09:33:43 PM
Thank you jens. It seems the issue kind of got solved. Another issue exists now.
Take a look at the standard coding I use to produce the issue:
() << () << (). As soon as I start moving from far left to right and reach the first << my first pair of parentheses highlight its right one. As you move along, the same repeat itself.
()| << () << () << ()
-------^ /* this is the blinking cursor supposedly */
Is the highlight colour the normal colour used for matching parenthesis or the colour we had before (a little more "greener").
What happens if you hit the tab-key in this situation ?
If it jumps to he right, it's the so called SmartTabJumping (http://forums.next.codeblocks.org/index.php/topic,12406.msg84207.html#msg84207 (http://forums.next.codeblocks.org/index.php/topic,12406.msg84207.html#msg84207)).
I don't know how it should behave exactly.
I think the "feature" itself and its highlight-colour should be configurable.
The combobox on Incremental Search toolbar looks strange, is this normal?
(http://i.imgur.com/EqMZ48E.png) (http://imgur.com/EqMZ48E)
Is there a way to disable compiler checking before loading? CB brings up a list of detected compilers dialog every time before starting. That didn't exist before.
Win7 x64, rev 9158
Something is broken. It should do it just once.
Quote from: oBFusCATed on July 05, 2013, 08:36:10 PM
Something is broken. It should do it just once.
That is the way it used to work; I put dummy paths like C:\ in the ones I did NOT have installed.
Tim S.
It should only show up on first launch, and once more each time the compiler plugin has a major change.
It is possible Code::Blocks is crashing on exit, so it fails to save its configuration file, which would cause it to believe every launch is the first launch.
Shouldn't I be warned about the crash somehow by Windows? Also there is no crash report (whatever its name was) file in cb folder. Can it be related to the changing of advanced compiler settings somehow? One of the latest nightlies asked me to save the new default advanced compiler settings and I believe I said 'no'.
I think it's the compiler plugin mulfunctioning. If I disable the compiler plugin cb starts up just fine. When I enable it again it looks for compilers and does that every time I start cb. What may be the problem and the solution?
Will it work if I manually edit the config file cuz that compiler detection thing is driving me nuts?
Can you post the default.conf file?
Also can you try to start cb from command line and to pass parameters like:
codeblocks.exe -v -d --log-to-file=somefile --debug-log-to-file=somefile
After the crash has happened you can post the files here.
p.s. use paste bin like service.
When I try to run 'codeblocks.exe -v -d --log-to-file=somefile --debug-log-to-file=somefile', I get "Unexpected characters following option 'log-to-file'". I tried many variations in place of 'somefile' and even the files that already exist but no luck. Can you give a simple example with a name for the file pls.
My default.conf is here though, http://pastebin.com/6mBgKUmP (http://pastebin.com/6mBgKUmP)
Quote from: scarphin on July 09, 2013, 01:47:29 AM
When I try to run 'codeblocks.exe -v -d --log-to-file=somefile --debug-log-to-file=somefile', I get "Unexpected characters following option 'log-to-file'". I tried many variations in place of 'somefile' and even the files that already exist but no luck. Can you give a simple example with a name for the file pls.
My default.conf is here though, http://pastebin.com/6mBgKUmP (http://pastebin.com/6mBgKUmP)
Try without the filenames as in
codeblocks.exe -v -d --log-to-file --debug-log-to-file
Then look for files called codeblocks-debug.log and codeblocks.log
Tim S.
Thnx Tim it worked. It seems the problem was me forgetting to update the 'installation directories' for the 2 tdm compilers I created.
Added compiler "TDM GCC Compiler 32-bit"
Added compiler "TDM GCC Compiler 64-bit"
Master path of compiler ID "tdm_gcc_compiler_32-bit" is empty -> triggers auto-detection.
Master path of compiler ID "tdm_gcc_compiler_64-bit" is empty -> triggers auto-detection.
After updating the compiler paths to correct directories, cb no longer tries to detect compilers at startup but it still takes much more time to launch than launching with compiler plugin disabled. So my guess is cb still tries to detect compilers but doesn't show the detected compilers screen. 'cb-log' and 'cb-debug.log' here,
http://pastebin.com/0YnjGTAN (http://pastebin.com/0YnjGTAN)
http://pastebin.com/8jpd8Ncr (http://pastebin.com/8jpd8Ncr)
There is something wrong with the 'bin' field of 'global variables'. When I enter some variable there, it doesn't change when the 'current variable' changed. Also it cannot be saved.
Win7 x64, rev9158
Quote from: scarphin on July 13, 2013, 05:46:05 PM
There is something wrong with the 'bin' field of 'global variables'. When I enter some variable there, it doesn't change when the 'current variable' changed. Also it cannot be saved.
Win7 x64, rev9158
Should be fixed in trunk (svn r9206).
Thanks for reporting this !
Quote from: jens on July 13, 2013, 07:37:35 PM
Quote from: scarphin on July 13, 2013, 05:46:05 PM
There is something wrong with the 'bin' field of 'global variables'. When I enter some variable there, it doesn't change when the 'current variable' changed. Also it cannot be saved.
Win7 x64, rev9158
Should be fixed in trunk (svn r9206).
Thanks for reporting this !
Thanks, Jens, this bug was introduced by me several months ago (when I introduce the "bin" field). :-[
Hello guys, I'm back from long absence. Just catched another crash here:
I tried to use file search in C::B to find broken files on a flash drive (they're filled with 1111111111s). I'm not really sure this is a right way to use IDE :) , but still, I have to report it. So: after using parameters provided on attached screenshot, CB hangs (possibly working, full CPU utilization for a few seconds, then 0%). Then abort/retry/ignore dialog pops out. When I try "abort" or "retry", unknown exception rises and CB terminates. My environment and CB version are visible at the screenshot.
Quote from: xawari on July 20, 2013, 08:59:30 PM
Hello guys, I'm back from long absence. Just catched another crash here:
I tried to use file search in C::B to find broken files on a flash drive (they're filled with 1111111111s). I'm not really sure this is a right way to use IDE :) , but still, I have to report it. So: after using parameters provided on attached screenshot, CB hangs (possibly working, full CPU utilization for a few seconds, then 0%). Then abort/retry/ignore dialog pops out. When I try "abort" or "retry", unknown exception rises and CB terminates. My environment and CB version are visible at the screenshot.
This should be fixed in trunk (svn r9214).
Hi guys,
I'm on a virtualized Debian 7 x64. I try to build CB, sugin my usual script :
#!/bin/bash
cd ~/sourcesCB
svn checkout http://svn.code.sf.net/p/codeblocks/code/trunk .
./bootstrap
./configure --with-contrib-plugins=all
make
sudo make install
bootstrap is present, but configure seems to be missing :
folco@debian:~$ buildCB.sh
U src/sdk/wxscintilla/src/scintilla/src/AutoComplete.cxx
U src/src/find_replace.cpp
Fetching external item into 'src/plugins/contrib/FortranProject'
Checked out external at revision 45.
Checked out revision 9215.
Using 'svn --xml info' to get the revision
Found revision: '9215' '2013-07-21 16:23:04'
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
./bootstrap: 70: aclocal: not found
/home/folco/bin/buildCB.sh: line 8: ./configure: No such file or directory
make: *** No targets specified and no makefile found. Stop.
Did I miss something ? Thanks in advance. :)
Quote from: Folco on July 21, 2013, 08:38:39 PM
Quote
[...]
./bootstrap: 70: aclocal: not found
Looks like you are missing the automake package or it is broken.
What a noob, didn't see that... But... wxwidgets 2.8.12 is needed, Debian provides only 2.8.10 on squeeze ><
Nevertheless, thank you.
Why do you use squeeze (oldstable) ?
You can use wxWidgets from apt.wxwidgets.org, if you don't want to (or you cannot for whatever reason) update your distro.
See http://wiki.wxpython.org/InstallingOnUbuntuOrDebian (http://wiki.wxpython.org/InstallingOnUbuntuOrDebian) for details. Packages for squeeze are available.
I use squeeze because I can virtualize it without any problem : https://www.virtualbox.org/wiki/Guest_OSes
I got some troubles with Wheezy, not supporting shared folder, which is a bit embarrassing...
Thanks for your link, I didn't know this page, I'll give a try tomorrow.
Thanks for your responses !
Thanks Jens, it perfectly works ! :)
This is my first software night-build version to download ever, ::) I hope that I face no more auto-completion bugs.
I have noticed a couple of issues with svn9232 on my Windows XP PC and I would like to ask if anyone else has noticed the same behavior.
When I attempt to open a recently opened project, the entire IDE freezes and I suspect it has something to do with the parser. It runs on the background as soon as you load the project, am I right? Please do by all means correct me if I'm wrong!
Also, another issue is that when the IDE crashes, it does not produce any report file as it used to, at least on Windows XP.
Cheers.
Quote from: ToApolytoXaos on August 02, 2013, 08:40:14 AM
I have noticed a couple of issues with svn9232 on my Windows XP PC and I would like to ask if anyone else has noticed the same behavior.
When I attempt to open a recently opened project, the entire IDE freezes and I suspect it has something to do with the parser. It runs on the background as soon as you load the project, am I right? Please do by all means correct me if I'm wrong!
I encountered the hang problem from time to time, but it is hard to reproduce. Do you have steps to reproduce this bug?
Quote
Also, another issue is that when the IDE crashes, it does not produce any report file as it used to, at least on Windows XP.
It should be "codeblocks.RPT" in the same folder of codeblocks.exe.
Quote from: ollydbg on August 02, 2013, 10:40:25 AM
I encountered the hang problem from time to time, but it is hard to reproduce. Do you have steps to reproduce this bug?
As you have stated yourself, it hangs from time to time, but I have noticed that it usually hangs when I start Code::Blocks for the first time while attempting to load a recent project.
Quote from: ollydbg on August 02, 2013, 10:40:25 AM
It should be "codeblocks.RPT" in the same folder of codeblocks.exe.
I'm afraid there is no such thing; that's why I have mentioned it here. It just shuts down without warning or whatsoever; and the funny thing is that I don't know how to reproduce it so I can check it with GDB :/
"from time to time" is relative :P My CB hangs every time when I start it up and try to close one of my opened projects..
This happens while code completion is parsing stuff.. and that needs a few seconds. When I wait for them, it won't hang.
So with a high speed PC (SSD, fast CPU), it's very unlikely to get CB to hang^^
The only way to fix it seems for me to improve the multi threading stuff.. better locks and more checks for the project existence.. or better... add a reference count to things like projects so that they can be removed from within codeblocks but some plugins may still use them until they remove their reference and it gets deleted^^
I'm not sure if it's about badly placed locks.. that's just what my first look suggested xD It's also possible that a wxWidgets call freezes... as that's what I see. (called from code completion)
@ToApolytoXaos
when you are self compiling CB and using Windows... make sure you are compiling exchndl.dll as well... or get a copy and put it into CB root.
Quote from: White-Tiger on August 02, 2013, 02:04:58 PM
"from time to time" is relative :P My CB hangs every time when I start it up and try to close one of my opened projects..
This happens while code completion is parsing stuff.. and that needs a few seconds. When I wait for them, it won't hang.
So with a high speed PC (SSD, fast CPU), it's very unlikely to get CB to hang^^
Speed for sure is totally irrelevant, because the issue *could* be probably the focus from Projects' Workspace while switching to editor. I can see the highlighting line getting disappeared and then the toolbar menus become white as a crashing indicator.
Quote from: White-Tiger on August 02, 2013, 02:04:58 PM
The only way to fix it seems for me to improve the multi threading stuff.. better locks and more checks for the project existence.. or better... add a reference count to things like projects so that they can be removed from within codeblocks but some plugins may still use them until they remove their reference and it gets deleted^^
That could be a solution, but for now I lack the knowledge about threads and I cannot take place, nor can I answer to something like that.
Quote from: White-Tiger on August 02, 2013, 02:04:58 PM
@ToApolytoXaos
when you are self compiling CB and using Windows... make sure you are compiling exchndl.dll as well... or get a copy and put it into CB root.
I have been doing so for the past 7 years, therefore I think I have it covered ;) Thanks for your suggestions though.
Quote from: White-Tiger on August 02, 2013, 02:04:58 PM
@ToApolytoXaos
when you are self compiling CB and using Windows... make sure you are compiling exchndl.dll as well... or get a copy and put it into CB root.
@White-Tiger: You have raised an interesting point here mate. I remember
exchndl.dll being copied into output from devel folder with execution of
update.bat file, but as it seems such thing is not happening anymore.
The so-called dynamic library can be seen in
src/ directory and after copied it in devel and ran update.bat, it could re-copied it in output. I don't remember doing such thing in the past...Probably I have forgot such procedure if I have done it only once.
Quote from: ToApolytoXaos on June 28, 2013, 07:11:48 AM
Sorry, but I will disappoint you now. I am on Windows at work with svn-9138 and the issue remains the same.
(http://i39.tinypic.com/eo8wp.png)
It seems this issue still exists with array brackets this time. If you create an array, but without a type, right bracket remains highlighted for some reason waiting for a matching left bracket
arr[] and if you try to create another array next to it
barr[], as you move the line it matches the right bracket only.
(http://i40.tinypic.com/1zx65l.png)
(http://i43.tinypic.com/1zwhd.png)
As you can see, this issue happens when you have forgotten to add an array type for some reason.
Is it an issue or a normal behavior when a variable type is missing?
Quote from: ToApolytoXaos on October 28, 2013, 09:21:08 AM
Is it an issue or a normal behavior when a variable type is missing?
It is *supposed* to be a feature; the highlight represents the location your cursor will jump to if you press tab.
By the way, what's this new case with creating new files in a project?
I get a "Mixed Line Endings" popup balloon window; I haven't touched anything in my line endings.
This issue is with svn9423, GNU / Linux Debian testing (32-bit), GCC 4.8.1 fully updated.
P.S.: I have compiled wxMSW-2.8.12 with TDM's GCC 4.8.1 in just 2 hours today (very peculiar I would say...), but I could not finish with C::B compilation and I had to cancel it at 300-minute, 31-second :S
Too many freaking warnings while compiling the project :(
Quote from: ToApolytoXaos on October 29, 2013, 07:40:46 PM
I get a "Mixed Line Endings" popup balloon window; I haven't touched anything in my line endings.
The files you've opened have both windows and linux line endings in them. This is just a warning.
Quote from: ToApolytoXaos on October 29, 2013, 07:40:46 PM
Too many freaking warnings while compiling the project :(
Search the forum for the proper -fno- blabla option to disable them. Probably you can fine them in the topics for mingw 4.8 or tdm 4.8.
Quote from: oBFusCATed on October 29, 2013, 07:50:46 PM
The files you've opened have both windows and linux line endings in them. This is just a warning.
OK, but the files have been created under Debian as I have been doing for ages and never had any similar issue. Oh well...
Quote from: oBFusCATed on October 29, 2013, 07:50:46 PM
Search the forum for the proper -fno- blabla option to disable them. Probably you can fine them in the topics for mingw 4.8 or tdm 4.8.
I have done so with wxMSW compilation procedure and still would get warning messages periodically; with C::B workspace though, where shall I add the specific flag to disable all these warnings?
Project or compiler level...
It might be best to add the flags to the global variable cb_release_type.
I added the "-Wno-unused-local-typedefs" to the Compiler Global "other options".
Tim S.
Quote from: Alpha on October 30, 2013, 01:05:44 AM
It might be best to add the flags to the global variable cb_release_type.
It seems your way is indeed very convenient next to -g. Thank you both @stahta01 and @Alpha; currently compiling it and I hope it will finish sooner than 300 minutes without my interruption LOL!
my CB build currently has "-w" set :P It just took ages otherwise.... (and as I'm not a CB dev, and not gonna fix ya bugs, I don't care about warnings :P)
Quote from: White-Tiger on October 30, 2013, 02:37:21 PM
my CB build currently has "-w" set :P It just took ages otherwise.... (and as I'm not a CB dev, and not gonna fix ya bugs, I don't care about warnings :P)
I think my build has a few more flags than yours ;)
-ansi -Wall -Wextra -Wmissing-include-dirs -Wunreachable-code -Winline -Wundef -Wcast-align -Wredundant-decls -Winit-self -Wshadow -Wnon-virtual-dtor -Wno-long-long -Wno-variadic-macros -Wno-unused-local-typedefs -Werror=return-type
You're on Linux right? Well.. in my Windoze machine it takes 20-40 minutes to compile CB and it's contrib items.
If I had warnings enabled, it would take more then 3 hours because of that warning spam I get... (and the fact that Windoze is slow as hell... especially in terms of console output^^)
As I'm always using the latest GCC, I was probably one of the first ones who have seen all these numerous warnings. It all started with GCC 4.8.. before that, the warnings were few and not really important. (I don't know how much impact they had...)
Anyway.. none the less it would be nice to see you guys not ignoring these warnings and instead fixing them ;) Actually they all have their reasons and it's way easier once you've got rid of them. As then, every warning will be a single one caused by recent changes and is easy to see and fix.
Quote from: White-Tiger on October 30, 2013, 03:40:14 PM
You're on Linux right? Well.. in my Windoze machine it takes 20-40 minutes to compile CB and it's contrib items.
If I had warnings enabled, it would take more then 3 hours because of that warning spam I get... (and the fact that Windoze is slow as hell... especially in terms of console output^^)
As I'm always using the latest GCC, I was probably one of the first ones who have seen all these numerous warnings. It all started with GCC 4.8.. before that, the warnings were few and not really important. (I don't know how much impact they had...)
Anyway.. none the less it would be nice to see you guys not ignoring these warnings and instead fixing them ;) Actually they all have their reasons and it's way easier once you've got rid of them. As then, every warning will be a single one caused by recent changes and is easy to see and fix.
I suggest you do this at the wxWidgets team and see the results.
You do realize the cause of the warning is them or can you NOT read!
Tim S.