I'm not sure why yet, but having that option on while typing pre-processor directives, notably back to back #pragma, eventually results in an access violation for me afer typing "#pr". I've narrowed down the cause, but I still have no idea what triggers it. The call stack at the time of death is as follows:
wow64.dll!Wow64LdrpInitialize 0x8e1
wow64.dll!Wow64LdrpInitialize 0x9eb
codeblocks.dll!ListBoxImpl::Length() 0x3
codeblocks.dll!ScintillaWX::WndProc(unsigned int, unsigned long, long) 0xe3
codeblocks.dll!wxScintilla::AutoCompSelect(wxString const&) 0x7b
codeblocks.dll!CCManager::OnCompleteCode(CodeBlocksEvent&) 0x7de
codeblocks.dll!Manager::ProcessEvent(CodeBlocksEvent&) 0x6d
codeblocks.dll!EditorHooks::CallHooks(cbEditor*, wxScintillaEvent&) 0x33
wxmsw28u_gcc_cb.dll!wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const 0x22
wxmsw28u_gcc_cb.dll!wxWindowBase::TryParent(wxEvent&) 0x78
wxmsw28u_gcc_cb.dll!wxEvtHandler::ProcessEvent(wxEvent&) 0x4a
codeblocks.dll!wxScintilla::NotifyParent(SCNotification*) 0xf3
codeblocks.dll!ScintillaWX::NotifyParent(SCNotification) 0x15
codeblocks.dll!ScintillaBase::AddCharUTF(char const*, unsigned int, bool) 0x44
codeblocks.dll!ScintillaWX::DoAddChar(int) 0xca
wxmsw28u_gcc_cb.dll!wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent&), wxEvent&) const 0x22
wxmsw28u_gcc_cb.dll!wxEvtHandler::ProcessEvent(wxEvent&) 0x4a
wxmsw28u_gcc_cb.dll!wxWindow::HandleChar(unsigned int, long, bool) 0xad
wxmsw28u_gcc_cb.dll!wxWindow::MSWWindowProc(unsigned int, unsigned int, long) 0x17d8
wxmsw28u_gcc_cb.dll!_Z9wxWndProcP6HWND__jjl@16 0x66
USER32.dll!gapfnScSendMessage 0x4e0
USER32.dll!gapfnScSendMessage 0x5d3
USER32.dll!GetKeyboardLayout 0x93c
USER32.dll!IsDialogMessageW 0x10a
wxmsw28u_gcc_cb.dll!wxWindow::MSWProcessMessage(tagMSG*) 0xbd
wxmsw28u_gcc_cb.dll!wxEventLoop::PreProcessMessage(tagMSG*) 0x11d
wxmsw28u_gcc_cb.dll!wxEventLoop::Dispatch() 0x11d
wxmsw28u_gcc_cb.dll!wxEventLoopManual::Run() 0x128
From what I can gather, the problem occurs here:
public _ZN11ListBoxImpl6LengthEv
_ZN11ListBoxImpl6LengthEv proc near
mov eax, [ecx+4]
mov ecx, [eax+144h]
mov eax, ds:_ZNK10wxListCtrl12GetItemCountEv
jmp eax
_ZN11ListBoxImpl6LengthEv endp
Put simply, GetItemCount() is called on a null pointer with win as seen here:
inline wxSCIListBoxWin* GETLBW(WindowID win) {
return ((wxSCIListBoxWin*)win);
}
inline wxListView* GETLB(WindowID win) {
return GETLBW(win)->GetLB();
}
int ListBoxImpl::Length()
{
return GETLB(wid)->GetItemCount();
}
Had I more time to devote to this, I could probably find the culprit of this null WIndowID, yet time escapes me. Thus here I am, seeking some aid after having been several times a victim of this bug. I appreciate any assistance in the resolution of this matter.