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.)
-------------------
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.
This appears to be the culprit.
// 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"
It would probably be a good idea to apply this, but I don't have a windows box to test it on ATM.
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&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>&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>&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 &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)
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:
-------------- 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.
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.
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:
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)
[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.
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:
void MainFrame::OnEditCut(cb_unused wxCommandEvent& event)
{
EditorBase* ed = Manager::Get()->GetEditorManager()->GetActiveEditor();
if (ed)
ed->Cut();
}
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.
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:
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.