Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: MortenMacFly on December 01, 2013, 07:48:36 pm

Title: Release 13.12, RC1-RC2 has arrived
Post by: MortenMacFly on December 01, 2013, 07:48:36 pm
For the announcement see here:
http://forums.codeblocks.org/index.php/topic,18636.0.html

...and here:
http://forums.codeblocks.org/index.php/topic,18673.0.html

...this thread is for the feedback. Keep it coming!
Title: Re: Release 13.12, RC1 has arrived
Post by: scarphin on December 02, 2013, 12:20:41 am
There were a couple of not so important things that had drawn my attention in the past. Considering a new release is on its way, I thought they should be mentioned. I'll try to remember them all in the meantime. Here are a few.

1- There is a typo in 'settings->environment->colours'. Item 'Editor:Highlight occurrence' is written as 'Editor:Highlihgt occurrence'.
2- In 'settings->editor->syntax highlighting', the chosen color for 'active line' isn't reflected in the sample code below.
3- The installer for 13.12RC1 displays '12.11' while loading but I'm sure that will change in the final release.
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 02, 2013, 12:55:59 am
1 is fixed in trunk now. Thank you for reporting it.
Title: Re: Release 13.12, RC1 has arrived
Post by: MortenMacFly on December 02, 2013, 08:52:36 am
3- The installer for 13.12RC1 displays '12.11' while loading but I'm sure that will change in the final release.
If you mean the logo - this is surely subject to change in the final version.
Title: Re: Release 13.12, RC1 has arrived
Post by: gd_on on December 02, 2013, 09:37:51 am
Two small patches to allow the translation of some menu items.

gd_on
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 02, 2013, 10:25:06 am
In svn...
Title: Re: Release 13.12, RC1 has arrived
Post by: Calexus on December 02, 2013, 11:30:00 am
How about an osx build?  ;D
Title: Re: Release 13.12, RC1 has arrived
Post by: MortenMacFly on December 02, 2013, 02:37:32 pm
How about an osx build?  ;D
Wasn't OSX that proprietary non-developer / open source friendly OS? Well... I'll try if I feel comfortable enough. :-)
Title: Re: Release 13.12, RC1 has arrived
Post by: dmoore on December 03, 2013, 06:19:19 am
I don't know if these rise to the level of important enough to fix for next release, but I found a few case and/or wording inconsistencies in some of the menu items (mostly contrib plugins, many of them mine :( )

patch attached. I didn't apply because wasn't sure if changing some of these items might break stuff.
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 03, 2013, 09:58:53 am
"Focus thread search" should have at least two capitals, because thread search is the name of a plugin. Probably this is the most consistent "Focus Thread search"
Title: Re: Release 13.12, RC1 has arrived
Post by: dmoore on December 03, 2013, 03:54:21 pm
"Focus thread search" should have at least two capitals, because thread search is the name of a plugin. Probably this is the most consistent "Focus Thread search"

That doesn't look good to me (and out of place with the other "Focus" menu items in the "View" menu. I don't think we are going for strictly grammatically correct but instead for consistency of menu look and feel. I don't think we have a rule for menu labels, but one might be: (1) uppercase first letter, (2) upper case acronyms, and (3) upper case for first letter or proper nouns but only if a lowercase letter would lead to ambiguity. That leaves some ambiguity for that Thread Search item (why isn't it called Threaded Search?), but I think we should avoid making up names that are proper nouns for things that exist only in C::B.

If that's the rule we follow then I need to fix a few more plugins. (e.g. Valgrind)
Title: Re: Release 13.12, RC1 has arrived
Post by: beqroson on December 03, 2013, 05:34:47 pm
(why isn't it called Threaded Search?)

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.  ::)  ???
Title: Re: Release 13.12, RC1 has arrived
Post by: gd_on on December 03, 2013, 06:42:55 pm
An other small patch to allow one translation in options_pgifortran.xml. In the original version, it contains " characters inside an xml string, but this is not correctly interpreted/detected when translating. Using \" looks better (at least works on my PC !)

gd_on
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 03, 2013, 07:46:58 pm
gd_on:
I don't think your patch is acceptable. The " is the correct way to escape " characters in XML files.
You can always prove me wrong by quoting some kind of a standard or output of a xml verifier.
Until then you'll have to find a better way to fix your problem.
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 03, 2013, 07:48:35 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.
Title: Re: Release 13.12, RC1 has arrived
Post by: stahta01 on December 04, 2013, 01:21:30 am
Minor issues noticed on Release 13.12, RC1.

OS: Windows 7
WX: 3.0 SVN Branch
Under Manage Plugins "Install New" says plugin failed to install when it really did install.

Tested using cbDiff.cbplugin and two other plugins.

Does it ever say the Plugin was successfully installed?

Edit: Found a message in CB Log "C:\GreenApps\CodeBlocks-13_12\share\codeblocks\plugins\cbDiff.dll: not loaded (missing symbols?)"

Might be plugin issue instead of CB issue.

Tim S.



Title: Re: Release 13.12, RC1 has arrived
Post by: dmoore on December 04, 2013, 01:29:28 am
Minor issues noticed on Release 13.12, RC1.

OS: Windows 7
WX: 3.0 SVN Branch
Under Manage Plugins "Install New" says plugin failed to install when it really did install.

Tested using cbDiff.cbplugin and two other plugins.

Does it ever say the Plugin was successfully installed?

Edit: Found a message in CB Log "C:\GreenApps\CodeBlocks-13_12\share\codeblocks\plugins\cbDiff.dll: not loaded (missing symbols?)"

Might be plugin issue instead of CB issue.

Tim S.


I have seen this with a number of plugins.  Not consistently though... I thought it might be happening if resources already exist. I can take a closer look in the next few days if noone else does.
Title: Re: Release 13.12, RC1 has arrived
Post by: gd_on on December 04, 2013, 10:42:06 am
Quote
gd_on:
I don't think your patch is acceptable. The " is the correct way to escape " characters in XML files.
You can always prove me wrong by quoting some kind of a standard or output of a xml verifier.
Until then you'll have to find a better way to fix your problem.

I have found a workaround to this problem.
When I extract strings from the xml file, I obtain those " strings. But, in C::B when using the _(...) macro, it's not the original string which is viewed by the macro, but a sting containing \". It was the reason of my proposed patch.
So, a workaround, is to detect the occurrences of " in the output file of xgettext, replace them by \" by a sed command for example, and that's OK now.
If I don't find some other problem, I'll publish a corrected version of my extracting tool in the forum (help wanted / Code::Blocks' translation thread).

gd_on
Title: Re: Release 13.12, RC1 has arrived
Post by: dmoore on December 06, 2013, 04:12:03 am
Spellchecker is doing something evil to the editor on Ubuntu 13.10 AMD 64 (scrolling and general C::B performance becomes extremely sluggish). I am using rev9469, so not quite RC1.
Title: Re: Release 13.12, RC1 has arrived
Post by: stahta01 on December 06, 2013, 04:51:13 am
FYI: I had CB 13.12, RC1 crash and it failed to create a crash report.

Using Dependency Walker I found that exchndl.dll requires LIBINTL-8.dll could this be why the crash report was NOT created?

Edit: Likely not, because 12.11 exchndl.dl had the same requirement.

Had a second crash this time with a report. Note: I had added the missing LIBINTL-8.dll  and two other DLLs (I think they were NOT needed; but, I am NOT sure.)

Code
-------------------

Error occured on Thursday, December 5, 2013 at 23:37:04.

C:\GreenApps\CodeBlocks-13_12\codeblocks.exe caused an Access Violation at location 77522d37 in module C:\Windows\SYSTEM32\ntdll.dll Reading from location 5717c915.

Registers:
eax=00000001 ebx=086bbbb0 ecx=003d0000 edx=086bbbb0 esi=5717c911 edi=086bbba8
eip=77522d37 esp=0022f49c ebp=0022f4d0 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206

Call stack:
77522D37  C:\Windows\SYSTEM32\ntdll.dll:77522D37  RtlFreeHeap
77522CE8  C:\Windows\SYSTEM32\ntdll.dll:77522CE8  RtlFreeHeap
76F698CD  C:\Windows\system32\msvcrt.dll:76F698CD  free
03EA67EF  C:\GreenApps\CodeBlocks-13_12\share\codeblocks\plugins\compiler.dll:03EA67EF
03EB42C5  C:\GreenApps\CodeBlocks-13_12\share\codeblocks\plugins\compiler.dll:03EB42C5
03EB565F  C:\GreenApps\CodeBlocks-13_12\share\codeblocks\plugins\compiler.dll:03EB565F
76F698CD  C:\Windows\system32\msvcrt.dll:76F698CD  free
6CCC0614  C:\GreenApps\CodeBlocks-13_12\wxmsw28u_gcc_cb.dll:6CCC0614  _ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler
6CC79EA6  C:\GreenApps\CodeBlocks-13_12\wxmsw28u_gcc_cb.dll:6CC79EA6  _ZN10wxListBase12DoDeleteNodeEP10wxNodeBase

Tim S.
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 06, 2013, 05:59:05 am
Can you remember what have you deleted from a list ctrl?
Title: Re: Release 13.12, RC1 has arrived
Post by: stahta01 on December 06, 2013, 06:33:17 am
Can you remember what have you deleted from a list ctrl?

I am not sure I deleted anything from a list ctrl; but, I was compiling a modified version of the Contrib Workspace.
And, at the same time I was editing some of the projects (inside that workspace) in an external editor.
So, I would NOT think crashing is really something to be highly concerned about.
But, I would suggest testing the crash reporting to confirm the 3 DLLs I added was NOT required under windows.
(I do NOT place any MinGW Installation in the system path because I have problems caused by that.)

Tim S.
Title: Re: Release 13.12, RC1 has arrived
Post by: MortenMacFly on December 07, 2013, 07:53:31 am
Spellchecker is doing something evil to the editor on Ubuntu 13.10 AMD 64
Hmmm... works fine on Ubuntu 13/04 - maybe an Ubuntu issue?
Title: Re: Release 13.12, RC1 has arrived
Post by: oBFusCATed on December 07, 2013, 10:30:13 am
Or just broken graphics driver issue?
Title: Re: Release 13.12, RC1 has arrived
Post by: dmoore on December 08, 2013, 02:47:07 pm
Or just broken graphics driver issue?

Bingo! (Had switch to fglrx, I guess the squiggly lines or something were problematic with the default open source driver?)
Title: Re: Release 13.12, RC1 has arrived
Post by: killerbot on December 08, 2013, 08:24:41 pm
when do we aim for RC2 ? Wednesday ?
Title: Re: Release 13.12, RC1 has arrived
Post by: MortenMacFly on December 12, 2013, 05:00:02 pm
when do we aim for RC2 ? Wednesday ?
Done now.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: scarphin on December 13, 2013, 02:31:55 am
I've reported this before but I'm beginning to think either I couldn't make myself clear or it's the intended behavior, not a bug. I won't report this again so for the last time with a screenshot I'll try to make myself clear if I couldn't in the first place.

In 'settings->editor->syntax highlighting', the color picked for 'Selection' or 'Active line' isn't reflected in the sample code window below, please see screenshot. I may be misinterpreting those lines as highlighted, so can anyone please clear that out for me?

Btw sorry for attachment, my picture host doesn't let me upload pics anymore so I had to upload it here.

Win7 x64 SP1
CB 13.12 RC2


[attachment deleted by admin]
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: oBFusCATed on December 13, 2013, 02:38:35 am
The active line is common for all editors. I'm not sure why it is in syntax highlight settings in the first place...
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: scarphin on December 13, 2013, 06:24:37 am
What about 'Selection'? Its color too isn't reflected. I can provide a screenshot for it too if need be?
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: oBFusCATed on December 13, 2013, 10:06:39 am
No need, I'm looking at it.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: Alpha 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.)
(http://www.pasteall.org/pic/show.php?id=64002)
(Code::Blocks rev. 9487)
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: devian 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.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: stahta01 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.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: Alpha on December 16, 2013, 05:16:45 pm
This appears to be the culprit.
Code: plugins/compilergcc/compilermingw.cpp
        // look first if MinGW was installed with Code::Blocks (new in beta6)
        m_MasterPath = ConfigManager::GetExecutableFolder();
        if (!wxFileExists(m_MasterPath + sep + _T("bin") + sep + m_Programs.C))
            // if that didn't do it, look under C::B\MinGW, too (new in 08.02)
            m_MasterPath += sep + _T("MinGW");
        if (!wxFileExists(m_MasterPath + sep + _T("bin") + sep + m_Programs.C))
        {
[...]
        }
        else
            m_Programs.MAKE = _T("make.exe"); // we distribute "make" not "mingw32-make"
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: lbart 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 (https://redports.org/~lbartoletti/20131218203008-11925-164789/codeblocks-13.12.log)
Log for FreeBSD 10 i386 (https://redports.org/~lbartoletti/20131218203008-11925-164790/codeblocks-13.12.log)
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: oBFusCATed 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++?
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: notonroof 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 (http://forums.codeblocks.org/index.php?topic=6551.0;prev_next=prev)

Thanks.
Title: Re: Release 13.12, RC1 has arrived
Post by: beqroson 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 (http://wiki.codeblocks.org/index.php?title=ThreadSearch_plugin)
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: stanley82521 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
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: MortenMacFly 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!
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: dmoore 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
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)
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: ollydbg 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. ???
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: dmoore 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.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: ollydbg 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
-------------- 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
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
[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.

Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: dmoore on December 24, 2013, 06:47:50 am
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.

Ok, that sounds the same as under Linux. But IMO, this behavior stinks because it means you can't use those accelerators for anything but the active editor in C::B.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: ollydbg on December 24, 2013, 08:17:16 am
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.

Ok, that sounds the same as under Linux. But IMO, this behavior stinks because it means you can't use those accelerators for anything but the active editor in C::B.
Yes, see: Re: wxAcceleratorTable - what I am doing wrong? (http://forums.wxwidgets.org/viewtopic.php?f=1&t=31244&hilit=wxAcceleratorTable#p133279) EDIT: also http://wiki.wxwidgets.org/Catching_key_events_globally#Accelerator_table

We can:
disable the "global" accelerated key table
Or
enable the accelerated key table (and its menu item) only when editor is active
Or
Change the way we did in:
Code
void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)
{
    EditorBase* ed = Manager::Get()->GetEditorManager()->GetActiveEditor();
    if (ed)
        ed->Cut();
}

Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: ollydbg on December 24, 2013, 03:51:23 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.)
(http://www.pasteall.org/pic/show.php?id=64002)
(Code::Blocks rev. 9487)

I can reproduce the bug by a very simple code:
A project only have one cpp file. the cpp file contains below contents.
Code
class Y
{
    enum ABC
    {
        ebABC1,
        ebABC2,
        ebABC3,
        ebABC4,
        ebABC5,
        ebABC6
    };
};

Now, delete "C" in "ebABC3", then enter "C" again, see the screen shot:
(http://i.imgur.com/sNLDZOV.png)

Look, only the enumerator before the caret get duplicated.

Reason: I guess the duplicated enumerator are produced by CC try to parse a local block of the code, in this case, from the class definition start to the caret, which is:
Code
class Y
{
    enum ABC
    {
        ebABC1,
        ebABC2,
        ebABC
So, you see, the "ebABC1" and "ebABC2" were found as some kind of enumerators which are marked as temporary. (just like the function local variables), I don't know how to fix this bug, maybe, we can still simply remove the tokens which has the same name and same Tokenkind?

I'm not sure why in your case, you have many duplications, not twice, but several times.



Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: ollydbg on December 25, 2013, 04:14:19 am
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.

Ok, that sounds the same as under Linux. But IMO, this behavior stinks because it means you can't use those accelerators for anything but the active editor in C::B.
Some information: #11320 (Accelerators take precedence over wxTextCtrl shortcuts) – wxWidgets (http://trac.wxwidgets.org/ticket/11320), it looks like OBF has already reported this bug?
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: dmoore on December 26, 2013, 05:54:12 am
Some information: #11320 (Accelerators take precedence over wxTextCtrl shortcuts) – wxWidgets (http://trac.wxwidgets.org/ticket/11320), it looks like OBF has already reported this bug?

So forget about my patch for release given where we are at now. But I still want to apply either my patch or something better in trunk. Clearly the wxWidgets crew aren't going to fix this without a patch that works for Mac/Linux/Windows, which could be a very long time in coming, so I think we need to workaround their bug. The question is whether there is a better approach than just removing the accelerators? (Maybe some people like that Ctrl-C/V/X/A always apply to the active editor? But they can always use the keybinder to get that behavior back) Some time back, I had played around the idea suggested in the wxWidgets trac ticket of finding the focused widget and vetoing the accelerator if it's a text-like control that has the focus, but I never did figure out how to do that correctly.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: ollydbg on December 26, 2013, 06:36:45 am
Some time back, I had played around the idea suggested in the wxWidgets trac ticket of finding the focused widget and vetoing the accelerator if it's a text-like control that has the focus, but I never did figure out how to do that correctly.
I'm not quite understand what wx dev said in that trac, so if there is a workaround(patch on the function: void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)???), I would like to try it on Windows.
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: Barrie on February 28, 2014, 07:15:34 pm
I use Windows 8.1 with Code Blocks 13.12

When building a Console Project that contains 1 or more Classes in separate files the linker gives "undefined reference to WinMain@16" error. Once the Project is saved, closed and then reopened the error no longer appears and the Project builds and runs normaly.

I was assured in another forum that this is probably a bug.

Please forgive me if this is not the place to comment this problem, I did read the rules and search all the fórums and this seemed to be the logical place to post it. Thanks

Barrie
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: BlueHazzard on February 28, 2014, 09:53:43 pm
http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28general%29#Q:_How_do_I_report_a_compilation_problem_on_the_forums.3F
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: Squall on January 22, 2016, 01:19:36 pm
I/ve not tried RC2 yet, but:

wxSmith, with a custom control the "Syle" property is not saved to the .wxs file.

I put a 0 in the field, but it is not saved, which gives build errors each time I re-open the project.

The following is missing <style>0</style> in my case

<object class="Custom" name="ID_CUSTOM1" subclass="wxGraph" variable="graph1" member="yes">
                           <creating_code>$(THIS) = new $(CLASS)($(PARENT),$(ID),$(POS),$(SIZE),$(STYLE),$(NAME));</creating_code>
                           <include_file>wxGraph.h</include_file>
                           <local_include>1</local_include>
                           <minsize>640,480</minsize>
</object>

which generates incorrect code, with a missing argument:

graph1 = new wxGraph(this,ID_CUSTOM1,wxDefaultPosition,wxDefaultSize,,_T("ID_CUSTOM1"));
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: oBFusCATed on January 22, 2016, 08:05:05 pm
So what version have you used?
Hopefully it wasn't 13.12rcX, because there is 13.12 final release and also there is the 15.12rc1!  :o
Title: Re: Release 13.12, RC1-RC2 has arrived
Post by: Squall on January 22, 2016, 11:23:45 pm
So what version have you used?
Hopefully it wasn't 13.12rcX, because there is 13.12 final release and also there is the 15.12rc1!  :o

Sorry, 15.12RC1. I'll try latest shortly