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://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc492-TDM.7z
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc492-TDM.7z
The 19 June 2015 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2015/CB_20150619_rev10341_win32.7z
- Linux :
none
The current SDK version is : 1.25.0
Resolved Fixed:
- CC: fix SF ticket 41 CC can`t parse defines with Doxygen single-line comment
- script_plugin: Fix creating multiple menus from a script plugin
- fix for pch-creation with gcc 5.x
- BrowseTracker-plugin: "make dist"-fix; missing images iand xrc-file
- CC: SF ticket 175, solve typedef declarations in class templates.
- Fix bug in wxSmith, see http://forums.next.codeblocks.org/index.php/topic,20338.msg138489.html#msg138489
- EnvVar: Make the fix from r10309 be conditionally compiled only for non wxMSW2.8 builds(thanks stahta01)
- CC: apply #178 patch for element access functions belonging to STL containers.
Regressions/Confirmed/Annoying/Common bugs:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (https://apt.jenslody.de/).
These packages are build against wxWidgets 3.0 from Debian repos and mght not be as stable than the versions build against wx2.8, but there are no wx2.8 packages available (at least for stable) from official repos.
Please test and give feedback.
Currently compiling, will soon be uploaded.
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc20, fc21, fc22 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (only 64-bit at the moment) can be found in my rpm-repo (https://copr.fedoraproject.org/coprs/jenslody/).
I recently switched to copr (https://copr.fedoraproject.org/) to build and host my Fedora and CentOS packages.
Instructions how to use it can be found on my server (https://rpm.jenslody.de/) (easier) or on copr (https://copr.fedoraproject.org/coprs/jenslody/) (a little more handwork needed).
Packages for ppc64le are also available on copr (https://copr.fedoraproject.org/coprs/jenslody/) for Fedora 21, 22 and Rawhide (not tested).
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
I have been facing this issue with 103xx revisions.
It seems hotkeys don't toggle, like F2 or Shift+F2; they just close "Logs & others" and "Management" but don't bring it back.
This is under GNU / Linux Debian testing 64-bit with gcc (Debian 4.9.2-16) 4.9.2.
Can anyone confirm this?
I use the F2 hotkey a lot. In every nightly I've used (including this latest one) in Windows, that hotkey has worked for me.
Yes, you are correct; it must be a MATE issue or something. I have double-checked it with Fluxbox and work as expected.
It works for me.
svn build rev 10329 (2015-06-11 22:33:15) gcc 4.9.2 Linux/unicode - 64 bit
wxWidgets 3.0
From jens repository
Debian "Jessie" 8.1 using Mate desktop.
I only have these CB Plugins enabled
Compiler,
Debugger
Environment variables
Foreign projects importer
Project options manipulator
Scripted wizard
wxSmith
Note: I would try turning off keybinder first to see if the problem goes away.
Quote from: ToApolytoXaos on June 21, 2015, 04:40:07 PM
I have been facing this issue with 103xx revisions.
It seems hotkeys don't toggle, like F2 or Shift+F2; they just close "Logs & others" and "Management" but don't bring it back.
This is under GNU / Linux Debian testing 64-bit with gcc (Debian 4.9.2-16) 4.9.2.
Can anyone confirm this?
Quote from: stahta01 on June 21, 2015, 05:22:09 PM
Note: I would try turning off keybinder first to see if the problem goes away.
Thank you stahta01. That was indeed the problem. What's the use of this plugin anyway?
Quote from: ToApolytoXaos on June 21, 2015, 05:24:58 PM
Quote from: stahta01 on June 21, 2015, 05:22:09 PM
Note: I would try turning off keybinder first to see if the problem goes away.
Thank you stahta01. That was indeed the problem. What's the use of this plugin anyway?
It changes the keybinding to something other than the normal.
I have never used it, myself.
Tim S.
Keybinder doesn't work correctly most of the time. It changes some of the shortcuts back to default sometimes, doesn't work with events configured with bind() or connect() (can anyone associate a shortcut with any of the debug windows?) and I've seen it corrupt the shortcut config file (cbkeybindings or something) in user folder. One of the most buggy plugins in CB imo. I change the defaults or assign new ones from the source code on my local copy to deal with those problems which are otherwise unbearable.
Do you have any steps that can be used to reproduce the problem?
Keep in mind that if you debug cb from cb it might screw your keybinder settings.
I don't know why, but I'm sure it can happen.
On my work machine where I don't debug cb from cb the keybindings are pretty stable.
Quote from: oBFusCATed on June 21, 2015, 06:28:36 PM
Do you have any steps that can be used to reproduce the problem?
Keep in mind that if you debug cb from cb it might screw your keybinder settings.
I don't know why, but I'm sure it can happen.
On my work machine where I don't debug cb from cb the keybindings are pretty stable.
Well, as I I have said, I'm using GNU / Linux Debian testing 64-bit, fully updated using MATE Desktop Environment 1.8.2 and currently compiled svn10341 debian packages with
dpkg-buildpackage -us -uc command.
To reproduce it, just run
codeblocks under MATE and as soon as you load a project, press either F2 or shift-F2 while you have keybinder plugin enabled and you will see that it does not toggle at all; it only closes the windows, it does not reopen them.
I'm not talking about this issue:)
But the one with lost settings.
Eeemm...oops ;D hahahaha :P
Quote from: oBFusCATed on June 21, 2015, 06:28:36 PM
Do you have any steps that can be used to reproduce the problem?
I'm not able to find what triggers the missing shortcuts, they appear to be random. Steps to reproduce for the unbindable debug windows shortcuts are the same as I described them on my post in 27 October 2014 build (10016) thread:
Quote from: scarphin on November 06, 2014, 12:22:18 AM
svn rev 10020 still exhibits the same problem. Unfortunately I couldn't find a working build after checking all the nightlies I have (back to rev 9673).
Steps to reproduce:
1- Launch cb, see the 'debugging windows' bindings are there before loading a project,
2- Load a project,
3- Check again to see the bindings are gone.
Some older revisions doesn't change 'cbkeybinder10.ini' file after closing cb even though the bindings are not listed on the shortcuts dialog, they don't work either. But latest nightlies change the file to add the targets of the opened project.
The bug is still there as of rev10333 in case someone wants to take a look at it. Apart from those, the help and tools plus plugin entries also exhibit the same behavior. Inspecting the source revealed none of them uses a EVT_MENU entry to link to the actual events (tools plus uses EVT_MENU_RANGE) so I think their linkage methods are the reason for the keybinder plugin to mulfunction.
Win7 x64
With svn10343 when closing C::B, it aborts. I debugged it and got the following:
19:51:46: Debug: 3 threads were not terminated by the application.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000030 in ?? ()
(gdb) list
308 #endif // wxCHECK_VERSION
309 };
310 #if wxCHECK_VERSION(3,0,0)
311 void cbMessageOutputNull::Output(cb_unused const wxString &str){}
312 #else
313 void cbMessageOutputNull::Printf(cb_unused const wxChar* format, ...){}
314 #endif
315 } // namespace
316
317 IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.
(gdb) bt
#0 0x0000000000000030 in ?? ()
#1 0x00007ffff5d1378b in ~wxEventTableEntryBase (
this=0x7ffff5fc3d40 <wxTreeListCtrl::sm_eventTableEntries>,
__in_chrg=<optimized out>) at ../include/wx/event.h:3177
#2 ~wxEventTableEntry (
this=0x7ffff5fc3d40 <wxTreeListCtrl::sm_eventTableEntries>,
__in_chrg=<optimized out>) at ../include/wx/event.h:3196
#3 __tcf_0 () at ../src/generic/treelist.cpp:987
#4 0x00007ffff153bf4f in __cxa_finalize (d=0x7ffff5fc1030)
at cxa_finalize.c:56
#5 0x00007ffff5c79073 in __do_global_dtors_aux ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0
#6 0x00007fffffffe090 in ?? ()
#7 0x00007ffff7deb00a in _dl_fini () at dl-fini.c:252
Backtrace stopped: frame did not save the PC
(gdb) c
Continuing.
Program received signal SIGABRT, Aborted.
0x00007ffff1539107 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff1539107 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff153a4e8 in __GI_abort () at abort.c:89
#2 0x00007ffff4b6d6e1 in wxFatalSignalHandler ()
at ../src/unix/utilsunx.cpp:1397
#3 <signal handler called>
#4 0x0000000000000030 in ?? ()
#5 0x00007ffff5d1378b in ~wxEventTableEntryBase (
this=0x7ffff5fc3d40 <wxTreeListCtrl::sm_eventTableEntries>,
__in_chrg=<optimized out>) at ../include/wx/event.h:3177
#6 ~wxEventTableEntry (
this=0x7ffff5fc3d40 <wxTreeListCtrl::sm_eventTableEntries>,
__in_chrg=<optimized out>) at ../include/wx/event.h:3196
#7 __tcf_0 () at ../src/generic/treelist.cpp:987
#8 0x00007ffff153bf4f in __cxa_finalize (d=0x7ffff5fc1030)
at cxa_finalize.c:56
#9 0x00007ffff5c79073 in __do_global_dtors_aux ()
from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0
#10 0x00007fffffffe090 in ?? ()
#11 0x00007ffff7deb00a in _dl_fini () at dl-fini.c:252
Backtrace stopped: frame did not save the PC
(gdb)
Any advice?
Cheers
Quote from: ToApolytoXaos on June 24, 2015, 06:55:35 PM
With svn10343 when closing C::B, it aborts. I debugged it and got the following:
Any advice?
Cheers
The debug info is not something I can follow.
But, I would suggest disabling each plugin one at a time and see if one crashes.
After, all the CB Plugins are disabled I would see if shutting CB still causes a crash.
If it no longer causes a crash, I would turn on one plugin at a time to see what plugin causes the crash.
Tim S.
Quote from: stahta01 on June 24, 2015, 09:30:22 PM
The debug info is not something I can follow.
But, I would suggest disabling each plugin one at a time and see if one crashes.
After, all the CB Plugins are disabled I would see if shutting CB still causes a crash.
If it no longer causes a crash, I would turn on one plugin at a time to see what plugin causes the crash.
Tim S.
Tim, I did exactly what you said and the issue remains the same. It's not a plugin's fault, but something else.
Cheers
Oh, so it is not the debugger error reported by valrgind, I've fixed...
What version of wx are you using this time? Self compiled wx?
No, the one that comes with GNU / Debian testing 64-bit
libwxbase3.0-0:amd64
libwxbase3.0-0-dbg:amd64
libwxbase3.0-dev
libwxgtk-media3.0-0:amd64
libwxgtk-media3.0-0-dbg:amd64
libwxgtk-media3.0-dev
libwxgtk-webview3.0-0:amd64
libwxgtk-webview3.0-0-dbg:amd64
libwxgtk-webview3.0-dev
libwxgtk3.0-0:amd64
libwxgtk3.0-0-dbg:amd64
libwxgtk3.0-dev
wx-common
wx3.0-examples
wx3.0-headers
Is this using the gtk2 or gtk3? The loaded libs are gtk2.
I'm really confused by your wx versions.
wx-config --list reports Default config is gtk2-unicode-3.0.
This issue appears to affect Code::Blocks due to the use of wx3.0 package. Since svn10315 that Debian decided to remove wx2.8.x from testing, I have this 'aborted' message.
Quote from: jens on June 20, 2015, 05:08:11 PM
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (https://apt.jenslody.de/).
These packages are build against wxWidgets 3.0 from Debian repos and mght not be as stable than the versions build against wx2.8, but there are no wx2.8 packages available (at least for stable) from official repos.
Please test and give feedback.
Currently compiling, will soon be uploaded.
Any update on Debian build status?
Edit: Thank you, I am now installing 10345.
Edit2: Will post update when I get it installed; Internet download speed really slow today. Likely storm or flood related local issues.
Edit3: Installed CB; building CB core wx28 project to test operation of installation.
Edit4: I did not see shutdown issue reported by ToApolytoXaos; but, I do have wxGTK2.8 installed. And, I am on Debian 8.1 Jessie instead of Debian testing.
Tim S.
Quote from: stahta01 on June 27, 2015, 01:26:59 PM
Quote from: jens on June 20, 2015, 05:08:11 PM
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (https://apt.jenslody.de/).
These packages are build against wxWidgets 3.0 from Debian repos and mght not be as stable than the versions build against wx2.8, but there are no wx2.8 packages available (at least for stable) from official repos.
Please test and give feedback.
Currently compiling, will soon be uploaded.
Any update on Debian build status?
Tim S.
I moved my server to a larger one and migrated from debian to centos.
So I had to crossbuild pbuilder for centos and create new scripts to generate the repo.
This should be done now.
Please test and give feedback.
Quote from: jens on June 27, 2015, 03:11:34 PM
Quote from: stahta01 on June 27, 2015, 01:26:59 PM
Any update on Debian build status?
Tim S.
I moved my server to a larger one and migrated from debian to centos.
So I had to crossbuild pbuilder for centos and create new scripts to generate the repo.
This should be done now.
Please test and give feedback.
The build installed without any issue.
It built CB wx28 core project and the project ran and shutdown without any problems.
Tested on Debian 8.1 Jessie with wxGTK2.8 and wxGTK3.0 development packages installed.
Tim S.
Quote from: stahta01 on June 27, 2015, 03:54:29 PM
The build installed without any issue.
It built CB wx28 core project and the project ran and shutdown without any problems.
Tested on Debian 8.1 Jessie with wxGTK2.8 and wxGTK3.0 development packages installed.
Tim S.
That's odd; wxGTK2.8 got removed from jessie and onwards. Did you download the package and installed it manually yourself @stahta01?
https://packages.debian.org/source/jessie/misc/wxwidgets3.0 (https://packages.debian.org/source/jessie/misc/wxwidgets3.0)
Quote from: ToApolytoXaos on June 27, 2015, 04:27:02 PM
Quote from: stahta01 on June 27, 2015, 03:54:29 PM
The build installed without any issue.
It built CB wx28 core project and the project ran and shutdown without any problems.
Tested on Debian 8.1 Jessie with wxGTK2.8 and wxGTK3.0 development packages installed.
Tim S.
That's odd; wxGTK2.8 got removed from jessie and onwards. Did you download the package and installed it manually yourself @stahta01?
https://packages.debian.org/source/jessie/misc/wxwidgets3.0 (https://packages.debian.org/source/jessie/misc/wxwidgets3.0)
Yes, I downloaded the source package from sid and built and installed it, myself.
Tim S.
It should work if you enable the oldstable (wheezy) repos and isnatll it from there. At least it did short after jessie became stable.
Quote from: jens on June 28, 2015, 12:07:08 AM
It should work if you enable the oldstable (wheezy) repos and isnatll it from there. At least it did short after jessie became stable.
I am 90% sure you will have minor problem doing both wx28 and wx30 dev that way.
The package was changed in a way that wx-common is now supplied by wx30.
But, maybe installing wx-common from wx30 first will prevent problems.
Tim S.
Quote from: stahta01 on June 28, 2015, 12:41:45 AM
I am 90% sure you will have minor problem doing both wx28 and wx30 dev that way.
The package was changed in a way that wx-common is now supplied by wx30.
But, maybe installing wx-common from wx30 first will prevent problems.
Tim S.
I have
wx-common already installed and mentioned it before at http://forums.next.codeblocks.org/index.php/topic,20363.msg138702.html#msg138702 (http://forums.next.codeblocks.org/index.php/topic,20363.msg138702.html#msg138702)
I have tried to find the crashing issue, but it's extremely difficult for me as I lack the knowledge you guys have.
Can you do something about it or at least show me what to read so I may become able in the near future to fix bugs.
Cheers
Quote from: ToApolytoXaos on June 28, 2015, 01:42:50 AM
Quote from: stahta01 on June 28, 2015, 12:41:45 AM
I am 90% sure you will have minor problem doing both wx28 and wx30 dev that way.
The package was changed in a way that wx-common is now supplied by wx30.
But, maybe installing wx-common from wx30 first will prevent problems.
Tim S.
I have wx-common already installed and mentioned it before at http://forums.next.codeblocks.org/index.php/topic,20363.msg138702.html#msg138702 (http://forums.next.codeblocks.org/index.php/topic,20363.msg138702.html#msg138702)
I have tried to find the crashing issue, but it's extremely difficult for me as I lack the knowledge you guys have.
Can you do something about it or at least show me what to read so I may become able in the near future to fix bugs.
Cheers
Did you check the weird things that can cause crashing on shutdown.
1. Not having write access to the config files
2. Having an corrupted config files
The above is the only two things I can think of right now.
Tim S.
Hello Everybody.
Since this nightly ("CB_20150619_rev10341_win32") I have problems to add files to a project by the projects-browser:
When I try to add files by the projects-browser the wait symbol (turning cycle) will be displayed before the associated File-dialogue opens. CodeBlocks is doing nothing any more and I have to quit it with the task-manager.
When I try to add files by the files-browser it works. When I try to add files recursively by the projects-browser the associated folder dialogue opens.
I closed my workspace and tried it out with a complete new empty-project with the same result.
The effect occurs under Win 8.1. with this nightly where I use the content of all provided 7z files.
As far as I remember I tried it out on Win 7 also and there it worked. I try to reproduce it tomorrow if i have a Win 7 computer available again if you wish.
I have tested it out with the nightly before ("CB_20150604_rev10320_win32") and there it works.
Please ask me for some more details if my description is not helpful ...
Best regards,
Eckard Klotz
Quote from: stahta01 on June 28, 2015, 04:23:30 AM
Did you check the weird things that can cause crashing on shutdown.
1. Not having write access to the config files
2. Having an corrupted config files
The above is the only two things I can think of right now.
Tim S.
Yes, I have noticed this behavior, but when I attempted to remove
wx-common, it informed me that the following packages will be removed and I cancelled the procedure.
libwxgtk-media3.0-dev
libwxgtk-webview3.0-dev
libwxgtk3.0-dev
wx-common
You see the name of the uninstalled package mentioned again? I don't know why this behavior exists.
Could it be the
/usr/bin/wxrc line that exists in
wx-common package that causes the strange behavior with config issues?
This wx3.0 thing is really breaking things badly. I have removed Code::Blocks packages I built myself and installed the official packages, 13.12.
It crashed again upon exit:
<stack>
<frame level="0" function="CodeBlocksApp::OnFatalException()" offset="00000000" file="/build/codeblocks-Uk3WYC/codeblocks-13.12/src/src/app.cpp" line="845"/>
<frame level="1"/>
<frame level="2"/>
<frame level="3" function="NativeParser::DeleteParser(cbProject*)" offset="0000003e"/>
<frame level="4" function="NativeParser::ClearParsers()" offset="00000031"/>
<frame level="5" function="CodeCompletion::OnRelease(bool)" offset="00000043"/>
<frame level="6" function="cbPlugin::Release(bool)" offset="00000074"/>
<frame level="7" function="PluginManager::DetachPlugin(cbPlugin*)" offset="00000039"/>
<frame level="8" function="PluginManager::UnloadPlugin(cbPlugin*)" offset="00000022"/>
<frame level="9" function="PluginManager::UnloadAllPlugins()" offset="0000002e"/>
<frame level="10" function="PluginManager::~PluginManager()" offset="0000003a"/>
<frame level="11" function="PluginManager::~PluginManager()" offset="00000009"/>
<frame level="12" function="Manager::Shutdown()" offset="00000076"/>
<frame level="13" function="MainFrame::OnApplicationClose(wxCloseEvent&)" offset="00000000" file="/build/codeblocks-Uk3WYC/codeblocks-13.12/src/src/main.cpp" line="2755"/>
<frame level="14" function="wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const" offset="0000003e"/>
<frame level="15" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)" offset="00000058"/>
<frame level="16" function="wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)" offset="0000008b"/>
<frame level="17" function="wxEvtHandler::TryHereOnly(wxEvent&)" offset="00000058"/>
<frame level="18" function="wxEvtHandler::DoTryChain(wxEvent&)" offset="00000043"/>
<frame level="19" function="wxEvtHandler::ProcessEvent(wxEvent&)" offset="00000045"/>
<frame level="20" function="wxEvtHandler::SafelyProcessEvent(wxEvent&)" offset="00000007"/>
<frame level="21" function="wxWindowBase::Close(bool)" offset="00000067"/>
<frame level="22" function="wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const" offset="0000003e"/>
<frame level="23" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)" offset="00000058"/>
<frame level="24" function="wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)" offset="0000008b"/>
<frame level="25" function="wxEvtHandler::TryHereOnly(wxEvent&)" offset="00000058"/>
<frame level="26" function="wxEvtHandler::DoTryChain(wxEvent&)" offset="00000043"/>
<frame level="27" function="wxEvtHandler::ProcessEvent(wxEvent&)" offset="00000045"/>
<frame level="28" function="wxWindowBase::TryAfter(wxEvent&)" offset="00000068"/>
<frame level="29" function="wxEvtHandler::SafelyProcessEvent(wxEvent&)" offset="00000007"/>
<frame level="30" function="wxMenuBase::SendEvent(int, int)" offset="000000a1"/>
<frame level="31"/>
<frame level="32" function="g_closure_invoke" offset="00000145"/>
<frame level="33"/>
<frame level="34" function="g_signal_emit_valist" offset="00000fd8"/>
<frame level="35" function="g_signal_emit" offset="0000008f"/>
<frame level="36" function="gtk_widget_activate" offset="00000076"/>
<frame level="37" function="gtk_menu_shell_activate_item" offset="000000fd"/>
<frame level="38"/>
<frame level="39"/>
<frame level="40" function="g_closure_invoke" offset="00000145"/>
<frame level="41"/>
<frame level="42" function="g_signal_emit_valist" offset="00000ae5"/>
<frame level="43" function="g_signal_emit" offset="0000008f"/>
<frame level="44"/>
<frame level="45" function="gtk_propagate_event" offset="000000c4"/>
<frame level="46" function="gtk_main_do_event" offset="000003ab"/>
<frame level="47"/>
<frame level="48" function="g_main_context_dispatch" offset="0000024d"/>
<frame level="49"/>
<frame level="50" function="g_main_loop_run" offset="000000c2"/>
<frame level="51" function="gtk_main" offset="000000b7"/>
<frame level="52" function="wxGUIEventLoop::DoRun()" offset="00000025"/>
<frame level="53" function="wxEventLoopBase::Run()" offset="000000a0"/>
<frame level="54" function="wxAppConsoleBase::MainLoop()" offset="00000056"/>
<frame level="55" function="CodeBlocksApp::OnRun()" offset="00000000" file="/build/codeblocks-Uk3WYC/codeblocks-13.12/src/src/app.cpp" line="811"/>
<frame level="56" function="wxEntry(int&, wchar_t**)" offset="00000070"/>
<frame level="57" function="main" offset="00000000" file="/build/codeblocks-Uk3WYC/codeblocks-13.12/src/src/app.cpp" line="276"/>
<frame level="58" function="__libc_start_main" offset="000000f5"/>
<frame level="59"/>
</stack>
There is no point trying wx3.x and 13.12 togather.
It will be broken and no one would bother to fix it.
Quote from: oBFusCATed on June 28, 2015, 11:43:23 PM
There is no point trying wx3.x and 13.12 togather.
It will be broken and no one would bother to fix it.
OK, should we report this to Debian? This combination is available for Jessie (stable) which makes Code::Blocks look like a broken program by nature and that's not right.
Quote from: ToApolytoXaos on June 29, 2015, 12:18:44 PM
Quote from: oBFusCATed on June 28, 2015, 11:43:23 PM
There is no point trying wx3.x and 13.12 togather.
It will be broken and no one would bother to fix it.
OK, should we report this to Debian? This combination is available for Jessie (stable) which makes Code::Blocks look like a broken program by nature and that's not right.
Please post where it says it is available for Jessie (stable); I missed seeing it.
Found it. jessie-backports
https://packages.debian.org/jessie-backports/codeblocks (https://packages.debian.org/jessie-backports/codeblocks)
Tim S.
Quote from: stahta01 on June 29, 2015, 05:53:29 PM
Please post where it says it is available for Jessie (stable); I missed seeing it.
Found it. jessie-backports
https://packages.debian.org/jessie-backports/codeblocks (https://packages.debian.org/jessie-backports/codeblocks)
Tim S.
Glad you found it Tim. So, what should we do? It's not the best feeling to have a broken IDE when you really need it, even though I could kind-of work with vim..but I really need Code::Blocks ;D
Quote from: ToApolytoXaos on June 29, 2015, 08:45:41 PM
Quote from: stahta01 on June 29, 2015, 05:53:29 PM
Please post where it says it is available for Jessie (stable); I missed seeing it.
Found it. jessie-backports
https://packages.debian.org/jessie-backports/codeblocks (https://packages.debian.org/jessie-backports/codeblocks)
Tim S.
Glad you found it Tim. So, what should we do? It's not the best feeling to have a broken IDE when you really need it, even though I could kind-of work with vim..but I really need Code::Blocks ;D
So you can try my repo with Code::Blocks nightlies for debian, build against wxWidgets 3.02 from the official repo.
Quote from: jens on June 29, 2015, 09:41:14 PM
So you can try my repo with Code::Blocks nightlies for debian, build against wxWidgets 3.02 from the official repo.
Is everything alright jens? I can't fetch updates for some reason...
W: Failed to fetch https://apt.jenslody.de/testing/dists/stretch/Release Unable to find expected entry 'main/source/Sources' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
Quote from: ToApolytoXaos on June 29, 2015, 10:02:12 PM
Quote from: jens on June 29, 2015, 09:41:14 PM
So you can try my repo with Code::Blocks nightlies for debian, build against wxWidgets 3.02 from the official repo.
Is everything alright jens? I can't fetch updates for some reason...
W: Failed to fetch https://apt.jenslody.de/testing/dists/stretch/Release Unable to find expected entry 'main/source/Sources' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
Sources are not (yet) available.
As stated before, I switched my server to CentOS and had to create my own pbuilder-package and a script that updates the repo (based on troubleshootingrange.blogspot.de/2012/09/hosting-simple-apt-repository-on-centos.html?_escaped_fragment_ ).
I will work on recreating the sources stuff as soon as possible.
For the moment you have to comment out the deb-src line for my repo.
I managed to install your nightlies; still the issue persists.
I have noticed though that I have updates for wxGTK now.
Let's hope that it was a bug somewhere along the packages.
Nothing changed; the issue remains as is... :-\
OK, from where to start...
I have attempted to search "m_ptr" term with ThreadSearch toolbar and got a rather awkward message about a
/home/stefanos/SVN_REPOSITORIES/CodeBlocks/src/wxsmith/GenericSingleChoiceList.wxs does not exist whatever that behavior means.. yeah I know it's a wxSmith file.
No, it's not missing from my fork; it does not exist on SVN repository either: http://svn.code.sf.net/p/codeblocks/code/trunk/src/wxsmith/ (http://svn.code.sf.net/p/codeblocks/code/trunk/src/wxsmith/)
Another issue is when you right-click on the menu bar and assert() messages start popping up like crazy. I have discovered a crazy bug with the following steps:
- Right-click on the menu bar, close all the assert() messages
- Go to your Plugins and select the first one to get highlighted and press Shift and use PageDown button to select all plugins until the end
- Click Disable button...BOOM! You should get a huge crashing without a debugger and if you do, read the error code below.
http://paste.debian.net/267453/ (http://paste.debian.net/267453/)
QuoteD /trunk/src/wxsmith/GenericSingleChoiceList.wxs
r10270 | jenslody | 2015-05-15 06:57:08 -0400 (Fri, 15 May 2015) | 1 line
Changed paths:
M /trunk/src/plugins/scriptedwizard/buildtargetpanel.cpp
M /trunk/src/plugins/scriptedwizard/buildtargetpanel.h
M /trunk/src/plugins/scriptedwizard/compilerpanel.cpp
M /trunk/src/plugins/scriptedwizard/compilerpanel.h
M /trunk/src/plugins/scriptedwizard/filepathpanel.cpp
M /trunk/src/plugins/scriptedwizard/filepathpanel.h
M /trunk/src/plugins/scriptedwizard/genericselectpath.cpp
M /trunk/src/plugins/scriptedwizard/genericselectpath.h
M /trunk/src/plugins/scriptedwizard/genericsinglechoicelist.cpp
M /trunk/src/plugins/scriptedwizard/genericsinglechoicelist.h
M /trunk/src/plugins/scriptedwizard/infopanel.cpp
M /trunk/src/plugins/scriptedwizard/infopanel.h
M /trunk/src/plugins/scriptedwizard/projectpathpanel.cpp
M /trunk/src/plugins/scriptedwizard/projectpathpanel.h
M /trunk/src/plugins/scriptedwizard/resources/avr/wizard.xrc
M /trunk/src/plugins/scriptedwizard/resources/lf/wizard.xrc
M /trunk/src/plugins/scriptedwizard/resources/matlab_csf/wizard.xrc
M /trunk/src/plugins/scriptedwizard/resources/mcs51/wizard.xrc
M /trunk/src/plugins/scriptedwizard/resources/plugins/wizard.xrc
M /trunk/src/plugins/scriptedwizard/resources/tricore/wizard.xrc
M /trunk/src/plugins/scriptedwizard/resources/wxwidgets/wizard.xrc
M /trunk/src/wxsmith/BuildTargetPanel.wxs
M /trunk/src/wxsmith/CompilerPanel.wxs
M /trunk/src/wxsmith/FilePathPanel.wxs
M /trunk/src/wxsmith/GenericSelectPath.wxs
D /trunk/src/wxsmith/GenericSingleChoiceList.wxs
M /trunk/src/wxsmith/InfoPanel.wxs
M /trunk/src/wxsmith/ProjectPathPanel.wxs
My guess it was deleted in error and needs restored and likely edited.
Edit2: How I found out when it was deleted; learned something new about SVN
stahta01@TIMWIN7-32 /c/SourceCode/OpenSourceCode/Apps/IDE/Codeblocks/codeblocks-svn/src/wxsmith
$ svn log -v > log.txt
Tim S.
Quote from: ToApolytoXaos on June 30, 2015, 02:03:20 AM
OK, from where to start...
I have attempted to search "m_ptr" term with ThreadSearch toolbar and got a rather awkward message about a /home/stefanos/SVN_REPOSITORIES/CodeBlocks/src/wxsmith/GenericSingleChoiceList.wxs does not exist whatever that behavior means.. yeah I know it's a wxSmith file.
No, it's not missing from my fork; it does not exist on SVN repository either: http://svn.code.sf.net/p/codeblocks/code/trunk/src/wxsmith/ (http://svn.code.sf.net/p/codeblocks/code/trunk/src/wxsmith/)
Could it possibly be the reason with all these assert()s? That would be mindblowing ;D
Update: When do you think you can push the changes to repository so I can pull?
Quote from: ToApolytoXaos on June 30, 2015, 02:53:02 AM
Could it possibly be the reason with all these assert()s? That would be mindblowing ;D
Update: When do you think you can push the changes to repository so I can pull?
wx30 is the likely reason for the asserts.
I an NOT a CB Dev; just a long term poster to this site.
Tim S.
I readded the wxs-file to trunk.
A missing wxs-file can not cause any issues, because it's only used to configure/generate the cpp/h-files it belongs to.
If it is part of a project it might lead to an error if you search in project-files with (e.g.) threadsearch.
The cashing at the end of wx3 is know and it's a hard to trackdown bug.
We already fixed several event-related issues a long time ago.
On comandline I get a xxx threads not closed message when closing C::B all the time.
When running C::B through C::B in the debugger I get a (more or less random) crash deep in some system and/or wx-files when closing C::B.
It's the next I try to work on (if no other more urgent stuff will come).
Quote from: jens on June 30, 2015, 07:29:32 AM
The cashing at the end of wx3 is know and it's a hard to trackdown bug.
We already fixed several event-related issues a long time ago.
So you're able to reproduce it? I'm not. Interesting.
Quote from: jens on June 30, 2015, 07:29:32 AM
On comandline I get a xxx threads not closed message when closing C::B all the time.
These are caused by the file manager object. And the threads are not stopped deliberately, I don't know the reason and svn blame doesn't give much hints. I've tried to stop these threads, but I was getting crashes, so I've to investigate further.
Quote from: jens on June 29, 2015, 10:14:28 PM
Quote from: ToApolytoXaos on June 29, 2015, 10:02:12 PM
Quote from: jens on June 29, 2015, 09:41:14 PM
So you can try my repo with Code::Blocks nightlies for debian, build against wxWidgets 3.02 from the official repo.
Is everything alright jens? I can't fetch updates for some reason...
W: Failed to fetch https://apt.jenslody.de/testing/dists/stretch/Release Unable to find expected entry 'main/source/Sources' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
Sources are not (yet) available.
[...]
For the moment you have to comment out the deb-src line for my repo.
Should work again.
Yep, I have tested it on my VirtualBox and works now.
By the way, I wanted to ask: what's the first line Code::Blocks is using to start? I haven't found any main() code inside any source file.
Where should I look?
it is nested in a wxApp Class and i think the main is behind this macro in app.c
IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.
I possibly found the cause for the crash at shutdown (not related to the unfinished threads):
wx3 provides wxTreeListCtrl and wxContribItems does it too.
For testing purposes I removed it completely in autofoo-stuff and the wx30-project-files (only tested on linux).
It should be added to wxSmith, but the wxs*-files for it need a complete overhaul and have to be moved from wxSmithContribItems to wxSmith itself (for wx30).
So as written for testing purposes I removed it completetely.
Please test the attached patch and give feedback, if possible.
Hello Everybody.
Quote
Since this nightly ("CB_20150619_rev10341_win32") I have problems to add files to a project by the projects-browser:
When I try to add files by the projects-browser the wait symbol (turning cycle) will be displayed before the associated File-dialogue opens. CodeBlocks is doing nothing any more and I have to quit it with the task-manager.
When I try to add files by the files-browser it works. When I try to add files recursively by the projects-browser the associated folder dialogue opens.
I closed my workspace and tried it out with a complete new empty-project with the same result.
The effect occurs under Win 8.1. with this nightly where I use the content of all provided 7z files.
As far as I remember I tried it out on Win 7 also and there it worked. I try to reproduce it tomorrow if i have a Win 7 computer available again if you wish.
I have tested it out with the nightly before ("CB_20150604_rev10320_win32") and there it works.
Please ask me for some more details if my description is not helpful ...
After some trials I found out the real reason. When I waited longer I've got a message from my virus-scanner that
codeblocks.exe seems to act in a suspicious way and he asked me to remove it. Since I already know a similar problem with
CbLauncher.exe I checked it directly with my virus-scanner and after he approved that he found no problem inside
codeblocks.exe, I put it on his white-list. After that I was able to add files to a project by the projects-browser again.
We had such an discussion last year ()http://forums.next.codeblocks.org/index.php/topic,19596.msg134069.html#msg134069 (http://forums.next.codeblocks.org/index.php/topic,19596.msg134069.html#msg134069) and I since I know now how to deal with this I don't want to start it again. How ever it may be helpful for others to add in http://forums.next.codeblocks.org/index.php/topic,3232.0.html (http://forums.next.codeblocks.org/index.php/topic,3232.0.html) a small workaround.
Best regards,
Eckard Klotz.
Best regards,
Eckard Klotz
Hello,
at least since 10341 and also with the latest 10356 I get the following assertion when I mark a variable and try to use following item of the context menu (right mouse click): Find occurences of: 'name':
ASSERT INFO:
../src/generic/listctrl.cpp(4091): assert "index >= 0 && (size_t)index < GetItemCount()" failed in EnsureVisible(): invalid index in EnsureVisible
BACKTRACE:
[1] wxGenericListCtrl::EnsureVisible(long)
[2] ThreadSearchLoggerList::OnThreadSearchEvent(ThreadSearchEvent const&)
[3] ThreadSearchView::OnTmrListCtrlUpdate(wxTimerEvent&)
[4] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] wxTimerImpl::SendEvent()
[12] g_main_context_dispatch
[13] g_main_loop_run
[14] gtk_main
[15] wxGUIEventLoop::DoRun()
[16] wxEventLoopBase::Run()
[17] wxAppConsoleBase::MainLoop()
[18] CodeBlocksApp::OnRun() /home/msk/test/codeblocks/trunk/src/src/app.cpp:850
[19] wxEntry(int&, wchar_t**)
[20] main /home/msk/test/codeblocks/trunk/src/src/app.cpp:317
[21] __libc_start_main
[22] _start /home/abuild/rpmbuild/BUILD/glibc-2.19/csu/../sysdeps/x86_64/start.S:125
I used the latest trunk with wxWidgets 3.0.2 (compiled by my own) on my OpenSuse 13.2.
I haven't used codeblocks (nor c++) for a long time, but recently installed the nightly (via jens lody) on a debian 8, and i am getting crashes all over the place..
the dev-cpp project importer is bugged and will make paths like "..\..\foo.cpp" even on linux where ..\ is invalid and should be ../../ ~
every time i try to delete a Build Target, i get an (seemingly) unlimited loop of assertion errors like this: (http://i.imgur.com/ow8HCey.png)
and it always seem to segfault after 2-10 minutes of use.. :(
ASSERT INFO:
./projectfile.h(234): assert "iIndex != (-1)" failed in Remove(): removing inexistent element in wxArray::Remove
BACKTRACE:
[1] ProjectFile::RemoveBuildTarget(wxString const&)
[2] cbProject::RemoveBuildTarget(int)
[3] std::vector<ProjectFile*, std::allocator<ProjectFile*> >::_M_insert_aux(__gnu_cxx::__normal_iterator<ProjectFile**, std::vector<ProjectFile*, std::allocator<ProjectFile*> > >, ProjectFile* const&)
[4] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxWindowBase::TryAfter(wxEvent&)
[11] wxWindowBase::TryAfter(wxEvent&)
[12] wxWindowBase::TryAfter(wxEvent&)
[13] wxWindowBase::TryAfter(wxEvent&)
[14] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[15] g_signal_emit_valist
[16] g_signal_emit
[17] g_signal_emit_valist
[18] g_signal_emit
[19] g_closure_invoke
[20] g_signal_emit_valist
[21] g_signal_emit
[22] gtk_propagate_event
[23] gtk_main_do_event
[24] g_main_context_dispatch
[25] g_main_loop_run
[26] gtk_main
[27] wxGUIEventLoop::DoRun()
[28] wxEventLoopBase::Run()
[29] wxDialog::ShowModal()
[30] wxDC::~wxDC()
[31] wxDC::~wxDC()
[32] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, wxEvent&) const
[33] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[34] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[35] wxEvtHandler::TryHereOnly(wxEvent&)
[36] wxEvtHandler::DoTryChain(wxEvent&)
[37] wxEvtHandler::ProcessEvent(wxEvent&)
[38] wxWindowBase::TryAfter(wxEvent&)
[39] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[40] wxMenuBase::SendEvent(int, int)
[41] g_closure_invoke
[42] g_signal_emit_valist
[43] g_signal_emit
[44] gtk_widget_activate
[45] gtk_menu_shell_activate_item
[46] g_closure_invoke
[47] g_signal_emit_valist
[48] g_signal_emit
[49] gtk_propagate_event
[50] gtk_main_do_event
[51] g_main_context_dispatch
[52] g_main_loop_run
[53] gtk_main
[54] wxGUIEventLoop::DoRun()
[55] wxEventLoopBase::Run()
[56] wxAppConsoleBase::MainLoop()
[57] wxEntry(int&, wchar_t**)
[58] __libc_start_main
To ignore the message just untick the 'show this dialog the next time' and click continue.
When using this nightly build release, I notice that the new project wizard's dialog can't be resized(thus it is a bit small), see image below:
(http://imagizer.imageshack.us/v2/720x435q90/537/sf3ZkI.png)
The other dialogs don't have this issue, see the about dialog, I can resize it by drag on the corner, see image below:
(http://imagizer.imageshack.us/v2/471x377q90/910/e8NWGu.png)
Can you confirm this?
i can confirm this...
i noticed it a few revisions before but thought it is a feature for small screens ;)
Quote from: BlueHazzard on July 29, 2015, 02:12:40 PM
i can confirm this...
i noticed it a few revisions before but thought it is a feature for small screens ;)
Thanks, I think this patch should fix this issue:
src/sdk/resources/new_from_template.xrc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/sdk/resources/new_from_template.xrc b/src/sdk/resources/new_from_template.xrc
index 3b524f6..b46123f 100644
--- a/src/sdk/resources/new_from_template.xrc
+++ b/src/sdk/resources/new_from_template.xrc
@@ -3,6 +3,7 @@
<object class="wxScrollingDialog" name="dlgNewFromTemplate">
<title>New from template</title>
<centered>1</centered>
+ <style>wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER</style>
<object class="wxFlexGridSizer">
<cols>2</cols>
<rows>2</rows>
@@ -196,14 +197,14 @@
<object class="wxStaticText" name="ID_STATICTEXT6">
<label>* To delete a user template, delete the similarly named folder created
 in %APPDATA%\\codeblocks\\UserTemplates (for Windows) or
 ~/Library/Application Support/CodeBlocks (for Mac OS X) or
 ~/.config/codeblocks (for other platforms).</label>
</object>
- <flag></flag>
+ <flag>wxALIGN_NOT</flag>
</object>
<object class="sizeritem">
<object class="wxStaticText" name="ID_STATICTEXT7">
<label> Please note the dot (.) in front of "codeblocks"!</label>
<fg>#800000</fg>
</object>
- <flag></flag>
+ <flag>wxALIGN_NOT</flag>
</object>
</object>
</object>
I don't know whether we need the second hunk of this patch, because wxsmith automatically add them. :(
I think it is the change in rev10260 which cause the regression.
i have applied the patch and now it works, but i get the error message:
Unknows Style Flag wxALIGN_NOT
Quote from: BlueHazzard on July 29, 2015, 05:40:45 PM
i have applied the patch and now it works, but i get the error message:
Unknows Style Flag wxALIGN_NOT
Did you apply the patch or did you use wxSmith ?
I get the same afte adding the resize-border-flag with wxSmith, the funny thing is wxALIGN_NOT is defined in defs.h of wxWidgets.
I try to investigate further.
Do you get the message always or only if you run C::B with -v parameter ?
i only have applied the patch (not on trunk but on r10356 )
i get also the following error:
resource file must have same version number!
on startup and following error if i create a new project:
Unknows Style Flag wxALIGN_NOT
without "--verbose" i get no errors
greetings
Quote from: jens on July 29, 2015, 06:48:38 PM
Quote from: BlueHazzard on July 29, 2015, 05:40:45 PM
i have applied the patch and now it works, but i get the error message:
Unknows Style Flag wxALIGN_NOT
Did you apply the patch or did you use wxSmith ?
I get the same afte adding the resize-border-flag with wxSmith, the funny thing is wxALIGN_NOT is defined in defs.h of wxWidgets.
I try to investigate further.
Do you get the message always or only if you run C::B with -v parameter ?
Edit: This is a wild guess based on seeing something like this error long ago when doing PCH fixes.
Try editing newfromtemplatedlg.cpp by adding "#include <wx/defs.h>"
Before
#include "sdk_precomp.h"
#ifndef CB_PRECOMP
#include <wx/button.h>
after
#include "sdk_precomp.h"
#ifndef CB_PRECOMP
#include <wx/defs.h>
#include <wx/button.h>
Add the "<style>wxDEFAULT_DIALOG_STYLE|wxRESIZE_BORDER</style>" to the xrc file don't solve the full issue.
If I revert the "new_from_template.xrc" to the revision before the commit rev10260(- core: alignment fixes to avoid asserts and broken layout with wx3), I get a size fixed dialog which is much bigger than the one I mentioned in the post: Re: The 19 June 2015 build (10341) is out. (http://forums.next.codeblocks.org/index.php/topic,20363.msg139246.html#msg139246).
Suggest:
1, a dialog have the resize feature is quite good than a fixed dialog, so we should add "wxRESIZE_BORDER" to the xrc
2, I initial size of the dialog should be larger(like the same size before the rev 10260)
I think I have found the reason, I see in the old revision, there is a minimal size of the first item of the wxFlexGridSizer.
<minsize>480,320</minsize>
And in the commit rev10260, it was removed.
BTW: I'm not sure why in the newer revision as the image in Re: The 19 June 2015 build (10341) is out. (http://forums.next.codeblocks.org/index.php/topic,20363.msg139246.html#msg139246), the text "Large icons"(bottom right of the dialog) is not shown correctly.
Probably it is removed but mistake, because wxsmith doesn't add it automatically. (this is just a guess)
I have noticed this too with this dialog, I remember that once it popped up, and nearly all was on 1 line, and I had to scroll big time to the right ;-)
By the way, related maybe, yet another dialog no longer ok : http://forums.next.codeblocks.org/index.php/topic,20491.msg139414.html#msg139414
Quote from: grf on July 11, 2015, 07:53:50 PM
at least since 10341 and also with the latest 10356 I get the following assertion when I mark a variable and try to use following item of the context menu (right mouse click): Find occurences of: 'name':
It should be fixed in svn trunk, please re-test.
Quote from: Hans Henrik on July 27, 2015, 06:16:33 PM
the dev-cpp project importer is bugged and will make paths like "..\..\foo.cpp" even on linux where ..\ is invalid and should be ../../ ~
Can you report this in the issues tracker, so it won't get lost?
Please post a bit more detailed steps to reproduce it.
Quote from: Hans Henrik on July 27, 2015, 06:16:33 PM
every time i try to delete a Build Target, i get an (seemingly) unlimited loop of assertion errors like this...
This should be fixed in svn-trunk, please test again and report any more problems with it.
Thanks both of you for reporting these issues.
If you see more similar issues don't hesitate to report them.
I found the reason about the warning of wxALIGN_NOT, let's discuss this issue in a separate thread, see my post Re: size of "add include path dialog" (http://forums.next.codeblocks.org/index.php/topic,20491.msg139544/topicseen.html#msg139544)