Author Topic: Release 13.12, RC1-RC2 has arrived  (Read 57708 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: Release 13.12, RC1-RC2 has arrived
« Reply #30 on: December 13, 2013, 10:06:39 am »
No need, I'm looking at it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Release 13.12, RC1-RC2 has arrived
« Reply #31 on: December 14, 2013, 11:01:41 pm »
Unfortunately, it looks like the duplicating enum problem has reappeared at some point.  Each time I refresh the CC listing, all enums, except the last one, are duplicated.
(Sorry, I am quite busy right now, and will be unable to look into it for some time.)

(Code::Blocks rev. 9487)

devian

  • Guest
Re: Release 13.12, RC1-RC2 has arrived
« Reply #32 on: December 16, 2013, 02:23:35 pm »
The default Toolchain executable for making the program is set as "make.exe" (for GNU GCC as default compiler). But in the mingw folder it says "mingw32-make.exe". Caused a lot of confusion. Reinstalled the whole thing some 4 times before I actually compared their names. I'm not sure if this comes under the forbidden section but if it is, please forgive me.

Online stahta01

  • Lives here!
  • ****
  • Posts: 6675
    • My Best Post
Re: Release 13.12, RC1-RC2 has arrived
« Reply #33 on: December 16, 2013, 03:21:45 pm »
The default Toolchain executable for making the program is set as "make.exe" (for GNU GCC as default compiler). But in the mingw folder it says "mingw32-make.exe". Caused a lot of confusion. Reinstalled the whole thing some 4 times before I actually compared their names. I'm not sure if this comes under the forbidden section but if it is, please forgive me.

I think its a valid complaint.

I see two solutions by the CB Team copy mingw32-make.exe to make.exe.
Or change the MinGW GCC make program to mingw32-make.exe. (I prefer this one)

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: Release 13.12, RC1-RC2 has arrived
« Reply #34 on: December 16, 2013, 05:16:45 pm »
This appears to be the culprit.
Code: Text
  1.         // look first if MinGW was installed with Code::Blocks (new in beta6)
  2.         m_MasterPath = ConfigManager::GetExecutableFolder();
  3.         if (!wxFileExists(m_MasterPath + sep + _T("bin") + sep + m_Programs.C))
  4.             // if that didn't do it, look under C::B\MinGW, too (new in 08.02)
  5.             m_MasterPath += sep + _T("MinGW");
  6.         if (!wxFileExists(m_MasterPath + sep + _T("bin") + sep + m_Programs.C))
  7.         {
  8. [...]
  9.         }
  10.         else
  11.             m_Programs.MAKE = _T("make.exe"); // we distribute "make" not "mingw32-make"
  12.  

Offline lbart

  • Single posting newcomer
  • *
  • Posts: 3
Re: Release 13.12, RC1-RC2 has arrived
« Reply #35 on: December 18, 2013, 09:58:27 pm »
Hello,
C:B 13.12 RC2 doesn't build on FreeBSD 10 with llvm/clang. The logs :
Log for FreeBSD amd64
Log for FreeBSD 10 i386

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12123
    • Travis build status
Re: Release 13.12, RC1-RC2 has arrived
« Reply #36 on: December 18, 2013, 11:37:05 pm »
C::B builds fine on linux with clang and libstd++, do you know if your version of clang is using libc++ or libstdc++?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline notonroof

  • Single posting newcomer
  • *
  • Posts: 7
Re: Release 13.12, RC1-RC2 has arrived
« Reply #37 on: December 21, 2013, 01:29:25 pm »
Code::Blocks is good IDE and I look forward to the next version.

Please, it is posible into next version add this small improvement:

When creating C/C++ Release target let the Wizard automaticaly defines NDEBUG preprocessor macro.

Because this macro is used by standard assert macro to switch off assertions in Release mode. In current RC2 is not macro NDEBUG automaticaly defined and must be always added manualy. If peoples dont know this, they are confused when get assert message from apps running in release mode.

Here is topic from 2007 with the same problem: http://forums.codeblocks.org/index.php?topic=6551.0;prev_next=prev

Thanks.
« Last Edit: December 21, 2013, 01:39:49 pm by notonroof »

Offline beqroson

  • Multiple posting newcomer
  • *
  • Posts: 63
Re: Release 13.12, RC1 has arrived
« Reply #38 on: December 21, 2013, 02:25:54 pm »
I agree to that. Even if I always suspected that "Thread search" would be a threaded search and nothing else, the question still kept popping up in the head if there was something more to it. "Threaded search" gives me the correct understanding much faster without figuring if there is some amazing hidden function beyond that.  ::)  ???
But then you get the wrong impression, because ThreadSearch uses just one 1 thread to search files.

Really??? Then what is all the point with thread search? Now I have no definition at all as what is the thing with it. Besides... ->

Maybe, you should update the wiki, as it clearly states multi threaded. -> http://wiki.codeblocks.org/index.php?title=ThreadSearch_plugin

Offline stanley82521

  • Single posting newcomer
  • *
  • Posts: 3
Re: Release 13.12, RC1-RC2 has arrived
« Reply #39 on: December 22, 2013, 04:54:49 pm »
Hi, the problem stated here hasn't been solved yet:

http://forums.codeblocks.org/index.php/topic,18015.msg123151.html
« Last Edit: December 22, 2013, 05:03:47 pm by stanley82521 »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9508
Re: Release 13.12, RC1-RC2 has arrived
« Reply #40 on: December 22, 2013, 05:29:25 pm »
Hi, the problem stated here hasn't been solved yet:
http://forums.codeblocks.org/index.php/topic,18015.msg123151.html
...fixed in SVN head. Thanks for the report!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Release 13.12, RC1-RC2 has arrived
« Reply #41 on: December 24, 2013, 04:32:42 am »
It would probably be a good idea to apply this, but I don't have a windows box to test it on ATM.

Code: [Select]
Index: src/src/resources/main_menu.xrc
===================================================================
--- src/src/resources/main_menu.xrc (revision 9395)
+++ src/src/resources/main_menu.xrc (working copy)
@@ -174,19 +174,16 @@
       <object class="wxMenuItem" name="idEditCut">
         <label>Cu&amp;t</label>
         <bitmap>images\16x16\editcut.png</bitmap>
-        <accel>Ctrl-X</accel>
         <help>Copy selected text to clipboard and erase it</help>
       </object>
       <object class="wxMenuItem" name="idEditCopy">
         <label>&amp;Copy</label>
         <bitmap>images\16x16\editcopy.png</bitmap>
-        <accel>Ctrl-C</accel>
         <help>Copy selected text to clipboard</help>
       </object>
       <object class="wxMenuItem" name="idEditPaste">
         <label>&amp;Paste</label>
         <bitmap>images\16x16\editpaste.png</bitmap>
-        <accel>Ctrl-V</accel>
         <help>Paste text from clipboard</help>
       </object>
       <object class="separator"/>
@@ -457,7 +454,6 @@
       <object class="separator"/>
       <object class="wxMenuItem" name="idEditSelectAll">
         <label>Select &amp;all</label>
-        <accel>Ctrl-A</accel>
         <help>Selects the entire text range</help>
       </object>
       <object class="wxMenuItem" name="idEditSelectNext">

It appears that setting those cut/copy/paste accelerators on Linux prevents use of Ctrl+C/V/X in non-editor widgets of the main C::B window. EDIT: Ctrl+A for Select All is also a problem. (Note for this to have a noticeable effect you might need to remove the keybindings for edit->copy/paste/cut/select all)
« Last Edit: December 24, 2013, 04:43:05 am by dmoore »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Release 13.12, RC1-RC2 has arrived
« Reply #42 on: December 24, 2013, 05:44:02 am »
I just test it under windows, I remove the <accel>Ctrl-X</accel> from main_menu.xrc, and the result C::B is: If the cbEditor is still the focus window, then Ctrl+X still cut some text in the editor.

BTW: I'm not fully understand how the key-strike to event handler works. ???
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: Release 13.12, RC1-RC2 has arrived
« Reply #43 on: December 24, 2013, 05:50:42 am »
I just test it under windows, I remove the <accel>Ctrl-X</accel> from main_menu.xrc, and the result C::B is: If the cbEditor is still the focus window, then Ctrl+X still cut some text in the editor.

(Did you make sure to run update.bat and clear out anything in related to those shortcuts in the keybinder plugin?)

The behavior you see is as it should be. You should also be able to use Ctrl-C/X/V/A in other text entry widgets (e.g. in the symbol browser search box). If I recall correctly, you could always do this on windows because I think it was just a linux issue but I could be wrong.

Quote
BTW: I'm not fully understand how the key-strike to event handler works. ???

To be honest, I don't completely either. All I know is that setting accelerators for actions that have system/toolkit default handlers creates problems on Linux, because the accelerators override the system defaults no matter what widget has the focus.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5247
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Release 13.12, RC1-RC2 has arrived
« Reply #44 on: December 24, 2013, 06:02:39 am »
I just test it under windows, I remove the <accel>Ctrl-X</accel> from main_menu.xrc, and the result C::B is: If the cbEditor is still the focus window, then Ctrl+X still cut some text in the editor.

(Did you make sure to run update.bat and clear out anything in related to those shortcuts in the keybinder plugin?)
I just build Codeblocks.cbp, and no other contributed plugins were build, so no keybinder.
I have run update.bat before, I don't think it is necessary here, because in the build log:
Code: [Select]
-------------- Build: src in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------

Target is up to date.
[ 25.0%] Running target post-build steps
[ 50.0%] cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
[ 75.0%] zip -jq9 devel\share\CodeBlocks\resources.zip src\resources\*.xrc
[100.0%] zip -jq9 devel\share\CodeBlocks\start_here.zip src\resources\start_here\*.html src\resources\start_here\*.png
cmd /c "cd src\resources & zip -0 -q ..\..\devel\share\CodeBlocks\resources.zip images\*.png images\16x16\*.png"

So, the xrc files was compressed to devel folders. Then I just start C::B by click the "run" or "start debug" toolbar button, this is the C::B in devel folder.

Also, there is no accelerator key shown in the menu item.

Quote
The behavior you see is as it should be. You should also be able to use Ctrl-C/X/V/A in other text entry widgets (e.g. in the symbol browser search box). If I recall correctly, you could always do this on windows because I think it was just a linux issue but I could be wrong.
I don't tried Ctrl-C/V/A, I think they are the same as Ctrl-X.

Quote
Quote
BTW: I'm not fully understand how the key-strike to event handler works. ???
To be honest, I don't completely either. All I know is that setting accelerators for actions that have system/toolkit default handlers creates problems on Linux, because the accelerators override the system defaults no matter what widget has the focus.

When you have CTRL+X in xrc file, then the cut event goes through:
Code: [Select]
void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)
{
    EditorBase* ed = Manager::Get()->GetEditorManager()->GetActiveEditor();
    if (ed)
        ed->Cut();
}
But if it was not in xrc, it goes through wxScintilla::OnKeyDown () : (see the bt)
Code: [Select]
[debug]#0  Editor::Cut (this=0x5216b50) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\scintilla\src\Editor.cxx:4253
[debug]#1  0x0117c66f in Editor::WndProc (this=0x5216b50, iMessage=2177, wParam=0, lParam=0) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\scintilla\src\Editor.cxx:7409
[debug]#2  0x01187a90 in ScintillaBase::WndProc (this=0x5216b50, iMessage=2177, wParam=0, lParam=0) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\scintilla\src\ScintillaBase.cxx:1024
[debug]#3  0x010dd194 in ScintillaWX::WndProc (this=0x5216b50, iMessage=2177, wParam=0, lParam=0) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\ScintillaWX.cpp:898
[debug]#4  0x01174b24 in Editor::KeyDownWithModifiers (this=0x5216b50, key=88, modifiers=2, consumed=0x8c4f598) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\scintilla\src\Editor.cxx:5741
[debug]#5  0x01174bd6 in Editor::KeyDown (this=0x5216b50, key=88, shift=false, ctrl=true, alt=false, consumed=0x8c4f598) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\scintilla\src\Editor.cxx:5752
[debug]#6  0x010de06f in ScintillaWX::DoKeyDown (this=0x5216b50, evt=..., consumed=0x8c4f598) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\ScintillaWX.cpp:1237
[debug]#7  0x010d88aa in wxScintilla::OnKeyDown (this=0x8c4f428, evt=...) at F:\cb_sf_git\trunk\src\sdk\wxscintilla\src\wxscintilla.cpp:5365
[debug]#8  0x627015f1 in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#9  0x6276a07e in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#10 0x6276a14a in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#11 0x6276a545 in wxEvtHandler::ProcessEvent(wxEvent&) () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#12 0x627a3c2c in wxWindow::HandleKeyDown(unsigned int, long) () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#13 0x627a5bc3 in wxWindow::MSWWindowProc(unsigned int, unsigned int, long) () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#14 0x627a0cee in wxWndProc(HWND__*, unsigned int, unsigned int, long)@16 () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#15 0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#16 0x0011068e in ?? ()
[debug]#17 0x7e418816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
[debug]#18 0x627a0ca0 in wxWindow::AssociateHandle(void*) () from E:\code\wx-mingw-build-481-dw2\wxWidgets-2.8.12\lib\gcc_dll\wxmsw28u_gcc_custom.dll
[debug]#19 0x7e4189cd in USER32!GetWindowLongW () from C:\WINDOWS\system32\user32.dll
[debug]#20 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:

My guess:
I'm not sure under Windows, if a key press is an accelerated key set in the mainframe, then the key press event was translated to some menu item click event.

« Last Edit: December 24, 2013, 06:04:24 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.