Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on June 20, 2015, 04:50:41 pm

Title: The 19 June 2015 build (10341) is out.
Post by: killerbot on June 20, 2015, 04:50:41 pm
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.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:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna 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.

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).
Title: Re: The 19 June 2015 build (10341) is out.
Post by: shurick on June 21, 2015, 03:55:44 pm
Packages for openSUSE (http://codeblocks.esy.es) (binaries and sources) for 32-bit and 64-bit.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: 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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: raynebc on June 21, 2015, 04:41:50 pm
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 21, 2015, 04:50:47 pm
Yes, you are correct; it must be a MATE issue or something. I have double-checked it with Fluxbox and work as expected.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 21, 2015, 05:22:09 pm
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.


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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 21, 2015, 05:24:58 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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 21, 2015, 05:26:54 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: scarphin on June 21, 2015, 05:51:52 pm
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 21, 2015, 06:45:27 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on June 21, 2015, 06:56:16 pm
I'm not talking about this issue:)
But the one with lost settings.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 21, 2015, 07:09:06 pm
Eeemm...oops  ;D hahahaha  :P
Title: Re: The 19 June 2015 build (10341) is out.
Post by: scarphin on June 21, 2015, 09:06:43 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:
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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 24, 2015, 06:55:35 pm
With svn10343 when closing C::B, it aborts. I debugged it and got the following:

Code
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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 24, 2015, 09:30:22 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 24, 2015, 10:59:37 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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on June 25, 2015, 01:47:29 am
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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 25, 2015, 04:35:31 pm
No, the one that comes with GNU / Debian testing 64-bit

Code
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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on June 26, 2015, 12:30:07 am
Is this using the gtk2 or gtk3? The loaded libs are gtk2.
I'm really confused by your wx versions.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 26, 2015, 12:46:47 am
wx-config --list reports Default config is gtk2-unicode-3.0.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 26, 2015, 09:24:00 pm
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 27, 2015, 01:26:59 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on June 27, 2015, 03:11:34 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 27, 2015, 03:54:29 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.
 
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 27, 2015, 04:27:02 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)
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 27, 2015, 09:36:25 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 28, 2015, 12:41:45 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 28, 2015, 01:42:50 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.codeblocks.org/index.php/topic,20363.msg138702.html#msg138702 (http://forums.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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 28, 2015, 04:23:30 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.codeblocks.org/index.php/topic,20363.msg138702.html#msg138702 (http://forums.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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: eckard_klotz on June 28, 2015, 08:52:12 am
Hello Everybody.

Since this nightly ("CB_20150619_rev10341_win32") I have problems to add files to a project by the projects-browser:
Best regards,
                      Eckard Klotz
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 28, 2015, 03:13:29 pm
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.

Code
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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 28, 2015, 10:22:35 pm
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:

Code
  <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&amp;)" offset="00000000" file="/build/codeblocks-Uk3WYC/codeblocks-13.12/src/src/main.cpp" line="2755"/>
    <frame level="14" function="wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&amp;, wxEvent&amp;) const" offset="0000003e"/>
    <frame level="15" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&amp;, wxEvtHandler*, wxEvent&amp;)" offset="00000058"/>
    <frame level="16" function="wxEventHashTable::HandleEvent(wxEvent&amp;, wxEvtHandler*)" offset="0000008b"/>
    <frame level="17" function="wxEvtHandler::TryHereOnly(wxEvent&amp;)" offset="00000058"/>
    <frame level="18" function="wxEvtHandler::DoTryChain(wxEvent&amp;)" offset="00000043"/>
    <frame level="19" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000045"/>
    <frame level="20" function="wxEvtHandler::SafelyProcessEvent(wxEvent&amp;)" offset="00000007"/>
    <frame level="21" function="wxWindowBase::Close(bool)" offset="00000067"/>
    <frame level="22" function="wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&amp;, wxEvent&amp;) const" offset="0000003e"/>
    <frame level="23" function="wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&amp;, wxEvtHandler*, wxEvent&amp;)" offset="00000058"/>
    <frame level="24" function="wxEventHashTable::HandleEvent(wxEvent&amp;, wxEvtHandler*)" offset="0000008b"/>
    <frame level="25" function="wxEvtHandler::TryHereOnly(wxEvent&amp;)" offset="00000058"/>
    <frame level="26" function="wxEvtHandler::DoTryChain(wxEvent&amp;)" offset="00000043"/>
    <frame level="27" function="wxEvtHandler::ProcessEvent(wxEvent&amp;)" offset="00000045"/>
    <frame level="28" function="wxWindowBase::TryAfter(wxEvent&amp;)" offset="00000068"/>
    <frame level="29" function="wxEvtHandler::SafelyProcessEvent(wxEvent&amp;)" 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&amp;, 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>
Title: Re: The 19 June 2015 build (10341) is out.
Post by: 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 29, 2015, 12:18:44 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 29, 2015, 05:53:29 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 29, 2015, 08:45:41 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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on June 29, 2015, 09:41:14 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 29, 2015, 10:02:12 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...
Code
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.

Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on June 29, 2015, 10:14:28 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...
Code
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 29, 2015, 10:33:45 pm
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 29, 2015, 11:26:23 pm
Nothing changed; the issue remains as is...  :-\
Title: Re: The 19 June 2015 build (10341) is out.
Post by: 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/)

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:

http://paste.debian.net/267453/ (http://paste.debian.net/267453/)
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 30, 2015, 02:42:23 am
Quote
D /trunk/src/wxsmith/GenericSingleChoiceList.wxs

Code
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
Code
stahta01@TIMWIN7-32 /c/SourceCode/OpenSourceCode/Apps/IDE/Codeblocks/codeblocks-svn/src/wxsmith
$ svn log -v > log.txt

Tim S.


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/)

Title: Re: The 19 June 2015 build (10341) is out.
Post by: 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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on June 30, 2015, 03:24:49 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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on June 30, 2015, 07:29:32 am
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).
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on June 30, 2015, 09:46:04 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.

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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on June 30, 2015, 09:57:40 am
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...
Code
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ToApolytoXaos on June 30, 2015, 04:50:00 pm
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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: BlueHazzard on June 30, 2015, 09:24:54 pm
it is nested in a wxApp Class and i think the main is behind this macro in app.c
Code
IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on July 01, 2015, 07:42:14 am
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: eckard_klotz on July 05, 2015, 05:44:56 pm
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.codeblocks.org/index.php/topic,19596.msg134069.html#msg134069 (http://forums.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.codeblocks.org/index.php/topic,3232.0.html (http://forums.codeblocks.org/index.php/topic,3232.0.html) a small workaround.

Best regards,
                      Eckard Klotz.


 

Best regards,
                      Eckard Klotz
Title: Re: The 19 June 2015 build (10341) is out.
Post by: grf on July 11, 2015, 07:53:50 pm
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':

Code
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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Hans Henrik on July 27, 2015, 06:16:33 pm
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..  :(

Code
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
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on July 27, 2015, 09:54:29 pm
To ignore the message just untick the 'show this dialog the next time' and click continue.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ollydbg on July 29, 2015, 02:09:30 pm
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?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: 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 ;)
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ollydbg on July 29, 2015, 02:34:36 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:

Code
 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&#x0A;   in %APPDATA%\\codeblocks\\UserTemplates (for Windows) or&#x0A;   ~/Library/Application Support/CodeBlocks (for Mac OS X) or&#x0A;   ~/.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 &quot;codeblocks&quot;!</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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: BlueHazzard on July 29, 2015, 05:40:45 pm
i have applied the patch and now it works, but i get the error message:
Code
Unknows Style Flag wxALIGN_NOT
Title: Re: The 19 June 2015 build (10341) is out.
Post by: Jenna on July 29, 2015, 06:48:38 pm
i have applied the patch and now it works, but i get the error message:
Code
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 ?
Title: Re: The 19 June 2015 build (10341) is out.
Post by: BlueHazzard on July 29, 2015, 07:28:52 pm
i only have applied the patch (not on trunk but on r10356 )

i get also the following error:
Code
resource file must have same version number!
on startup and following error if i create a new project:
Code
Unknows Style Flag wxALIGN_NOT

without "--verbose" i get no errors

greetings
Title: Re: The 19 June 2015 build (10341) is out.
Post by: stahta01 on July 29, 2015, 07:30:15 pm
i have applied the patch and now it works, but i get the error message:
Code
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
Code
#include "sdk_precomp.h"

#ifndef CB_PRECOMP
    #include <wx/button.h>
after
Code
#include "sdk_precomp.h"

#ifndef CB_PRECOMP
    #include <wx/defs.h>
    #include <wx/button.h>
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ollydbg on August 06, 2015, 08:05:16 am
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.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)

Title: Re: The 19 June 2015 build (10341) is out.
Post by: ollydbg on August 06, 2015, 09:13:33 am
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.

Code
<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.codeblocks.org/index.php/topic,20363.msg139246.html#msg139246), the text "Large icons"(bottom right of the dialog) is not shown correctly.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on August 06, 2015, 09:18:12 am
Probably it is removed but mistake, because wxsmith doesn't add it automatically. (this is just a guess)
Title: Re: The 19 June 2015 build (10341) is out.
Post by: killerbot on August 09, 2015, 10:40:24 am
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.codeblocks.org/index.php/topic,20491.msg139414.html#msg139414
Title: Re: The 19 June 2015 build (10341) is out.
Post by: oBFusCATed on August 12, 2015, 09:52:39 am
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.


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.

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.
Title: Re: The 19 June 2015 build (10341) is out.
Post by: ollydbg on August 18, 2015, 01:30:26 am
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.codeblocks.org/index.php/topic,20491.msg139544/topicseen.html#msg139544)