IMPORTANT : THIS IS THE THIRD BUILD THAT USES WX 303 AND IS A 64 BIT APPLICATION.
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(s) for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw30u_gcc_cb_wx303_gcc510-TDM-2.7z
The 29 April 2018 build is out.
- Windows :
http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2018/CB_20180429_rev11386_win64.7z
- Linux :
none
The current SDK version is : 1.36.0
Resolved Fixed:
- lexer: Add lexer for Markdown (ticket #640, thanks Christophe Marc BERTONCINI)
- UI: Make sure the current project is always visible in the project tree while moving it up/down (ticket #617, thanks bluehazzard)
- ToDo plugin: Fix memory corruption due to splashscreen (ticket #635)
- fixed part #1 of bug #641 (EnvVars can lose environment variables when opening the environment configuration dialog)
- wx3-gtk3: Fix crash when doing Control-A, Control-V (ticket #629)
- scintilla: Update to version 3.7.5; use wxstc from wx-master as a base for the wx part of the control
- scintilla-wx: Update the wx files to be in sync with the same files in wx's master
- scintilla-wx patch: Make the auto-completion list wider and taller if needed
- scintilla patch: wxSmith lexer changes (part
- scintilla patch: Add changebar to scintilla/wxscintilla
- editor: Enable pasting when there are multiple cursors and typing with them is enabled
- scintilla-cb: Don't break 3rd party plugins like FortranProject, Clang, MiniDoc etc...
- editor: Make it possible to set the whitespace mode to "Only indent"
- KeyBinder - Fix F2, Shift-F2 and allow linux to handle any View menu check items. see https://sourceforge.net/p/codeblocks/tickets/273/
- UI: Fix crash when reloading multiple projects in a workspace and they have dependencies
- CodeSnippets - Apply modified patches by Miguel Gimenez and bluehazzard
Adds DnD to projectmanagerui, removes it from the plugin, and fixes asserts
- UI: Minimize the time needed to open the file/replace dialog for the LLVM project
- editor: Fix the feature which restores editor folds when the project/editor is reloaded
- UI: Fix unsorted menu items in the editor's context menu
- OccurrenceHighlighting: Make it possible to set the plugin to override the text colour
- OccurrenceHighlighting: Handle editor open events to highlight all words that match the set for permanent highlights
- OccurrenceHighlighting: Update the permanent occurrence highlights when editor is spli
- scitinilla-wx: Cherry-pick changes from wx-master (better calltips/autocompletion; crash on macOS)
- UI: DefaultMimeHandler: Set min size for the selection dialog
- UI: Make sure that the file path control in the EditPath is larger, so longer paths could be reviewed
- UI: Set the focus to the OK button in the Multi Select dialog (used when adding files to a project)
- compiler: Show the build message when the user requests goto prev/next error
- compiler: Make sure the goto prev/next build error goes only on errors
- wx30: Fix assert introduced with rev 9667
- wxSmith: Fix assert after inserting wxListCtrl (ticket #671, thanks Miguel Gimenez)
- autosave: Add option to save log rotated backup files in a sub-folder (ticket #132, thanks Alatar)
- wxSmith: Add Radio as possible wxAuiToolBarItem item kind (ticket #15, thanks blurhazzard)
- wxSmith: Fix use-after-free error when moving a control in a sizer
- wxSmith: Fix assert when using the wxGridBagSizer (ticket #664, thanks bluehazzard)
- editor config: Make it possible to type in the syntax highlight preview
Regressions/Confirmed/Annoying/Common bugs:
is this ok?
Quote
Scanning for plugins in C:\Dev-CodeBlocks\share\codeblocks\plugins
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\Cccc.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\CppCheck.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\Cscope.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\DoxyBlocks.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\EditorConfig.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\headerfixup.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\ThreadSearch.zip'.
Tools Plus Plugin: Registering shell type Piped Process Control
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\ToolsPlus.zip'.
Manager failed to load XRC resource 'C:\Dev-CodeBlocks\share\codeblocks\wxSmithAui.zip'.
Loaded 60 plugins
nope, and I seem to have the same problem.
Building again ...
Hi.
This isn't a 'new' problem : see here : http://forums.next.codeblocks.org/index.php/topic,22235.msg151443.html#msg151443
And oBFusCATed said it could be ignored (next post)
Regards
Xav'
Hi.
OS X version of this rev can be downloaded from my Google Drive (https://drive.google.com/open?id=0B2rFQ8rNHzEeN0xtU3R6emdhUWs).
Debian Stretch (32 and 64 bits) can be installed from my repo (https://wxstuff.xaviou.fr/article/debian-repository.html).
Regards
Xav'
Congratulations to all involved in this great work!
indeed, with a new clean build this also occurs.
The sdk indicated by 'killerbot' is 1.34.0
The sdk specified by C::B after compilation is 1.36.0 (svn 11350, 2018-03-28)
Quote from: killerbot on April 30, 2018, 04:19:17 PM
indeed, with a new clean build this also occurs.
so is there a problem with those existing plugins?
Is the xrc file missing all together or something else?
Quoteso is there a problem with those existing plugins?
Is the xrc file missing all together or something else?
As far as i know this plugins do not have xrc files, but the resource management of wxWidgets expects xrc files. Adding dummy xrc files can probably solve this...
Quote from: BlueHazzard on May 02, 2018, 07:57:39 PM
Quoteso is there a problem with those existing plugins?
Is the xrc file missing all together or something else?
As far as i know this plugins do not have xrc files, but the resource management of wxWidgets expects xrc files. Adding dummy xrc files can probably solve this...
sounds like a good idea... hope it works out...
Quote from: LETARTARE on May 02, 2018, 03:18:52 PM
The sdk indicated by 'killerbot' is 1.34.0
The sdk specified by C::B after compilation is 1.36.0 (svn 11350, 2018-03-28)
my mistake, I forgot to check this, adjusting the post.
I noticed a massive slowdown for opening editors on windows with wx3.0.2. Is this only for me? Opening a source file from the project manager tab takes quite some seconds before it is shown. This was not that bad in the old*) version i used for production.
If some one else has the same issue i will try to investigate...
*) i have no idea what version it was....
How large are your files? Have you measured the performance on linux?
What happens if you disable all plugins?
edit: Have you seen this effect with your own builds? If you see this effect on your builds then can you add some stop watches to measure the time to open an editor? Unfortunately profiling on windows requires proprietary/commercial tools, so it is not as easy as on linux. :(
edit2: What happens if you comment the Colourise call at the end of cbEditor::InternalSetEditorStyleAfterFileOpen? On linux the performance improves 3-5x with this call commented. (src/src/main.cpp opens for 26msec without and 122msec with on wx28, wx31 is similar but a bit faster).
as an Added note this says compiled against wxWidgets (v3.0.3)
the latest stable version is v3.0.4 lol ;)
correct, the plan is for the next nightly to step up to wx 3.1.x, that's why we didn't bother anymore to take the step towards 3.0.4.
oh ook...
Problems with checking spelling are still the same. Now there are no word breaks, but only the last letters are spelling, ... after this the code::blocks is very quickly destroyed.
Quote from: Khram on May 05, 2018, 05:12:26 PM
Problems with checking spelling are still the same.
Unfortunately your bug reporting skills haven't improved either... 8)
Hi.
I've just noticed that it was no more possible to move files betwen/from/to virtual folders in the projects tree.
Is there now an option I missed to re-activate this ?
Tested on Windows 10 with the "official binary", and on OS-X and Debian.
Regards
XAv'
Does it work with the previous night build?
Quote from: oBFusCATed on May 09, 2018, 09:23:22 AM
Does it work with the previous night build?
Yes, it works.
I have also tested with a personnal build (rev 11374) and it doesn't work.
Regards
Xav'
Can you find the commit that breaks it?
Quote from: oBFusCATed on May 09, 2018, 06:48:24 PM
Can you find the commit that breaks it?
I'll try...
Regards
Xav'
I think I've found the commit : it seems to be rev 11345 :
- CodeSnippets - Apply modified patches by Miguel Gimenez and bluehazzard
Adds DnD to projectmanagerui, removes it from the plugin, and fixes asserts
Its not just a supposition related to the comments above : I've built both rev-11344 and rev-11345.
But I've not made 'clean builds' (just svn update and build for both revs) so I can't be 100% sure of what I'm saying.
I have also built the last rev (11400) with
src/src/projectmanagerui.cpp of rev 11344 (just before the problematic modification witch was the last modification made on this file) and it works (files can be dragged between virtual folders).
But I don't know witch other impact it can have : it was just for testing purpose.
Hope it'll help
Regards
Xav'
It seems pecan disabled dragging in the project tree on purpose:
Quote// we disallow the drag of files within the project tree
This is my fault....
I will look into it and post a patch
This should fix the issue
diff --git a/src/src/projectmanagerui.cpp b/src/src/projectmanagerui.cpp
index cbd93a6fe..6ca7d0926 100644
--- a/src/src/projectmanagerui.cpp
+++ b/src/src/projectmanagerui.cpp
@@ -977,11 +977,8 @@ void ProjectManagerUI::OnTreeBeginDrag(wxTreeEvent& event)
wxDropSource dragSource(m_pTree);
dragSource.SetData(dropObject);
dragSource.DoDragDrop();
- // we disallow the drag of files within the project tree
- return;
}
-
- // allowed
+ // Allow drag and drop within the project tree
event.Allow();
}
On windows the handling is somehow bugged: If you drag a file the "forbidden" cursor will be shown as long as you hold the mouse button. As soon you release the button the normal "drag&drop" cursor will appear and drag and drop is possible...
It works, but i still will look further...
QuoteOn windows the handling is somehow bugged: If you drag a file the "forbidden" cursor will be shown as long as you hold the mouse button. As soon you release the button the normal "drag&drop" cursor will appear and drag and drop is possible...
It works, but i still will look further...
i am not quite sure if this is wxWidgets behaviour:
http://docs.wxwidgets.org/3.0/overview_dnd.html
QuoteDragging: The call to DoDragDrop() blocks the program until the user releases the mouse button (unless you override the wxDropSource::GiveFeedback function to do something special). When the mouse moves in a window of a program which understands the same drag-and-drop protocol (any program under Windows or any program supporting the XDnD protocol under X Windows), the corresponding wxDropTarget methods are called - see below.
The forbidden cursor appears because the project manager window should be also a drop target.
I have investigated future about the drag and drop thing. In my opinion this should be implemented the right way (implement proper Drag Objects for project files ecc.), but this is tons of work. I can try to do it but first i want to know if the implementation for the fix i suggested a few posts above is really a problem (also on other platforms like mac or unix)
Hi
Quote from: BlueHazzard on May 15, 2018, 01:13:10 AM
I can try to do it but first i want to know if the implementation for the fix i suggested a few posts above is really a problem (also on other platforms like mac or unix)
I've tested (OS-X and Windows) : it is not really a problem if you know how it works (especially on OS-X where the "forbidden" icon isn't shown).
But it is really an unusual behavior and I think it shouldn't stay "as is".
Regards
Xav'
I have temporary disabled external drag and drop from projectmanagerui.
External drag and drop is incompatible with wxTreeCtrl internal use of drag and drop.
We can use one or the other, but not both in a wxTreeCtrl.
This means that the Snippets plugin will not be able to drag items out of the project tree. However, it can copy and paste them.
I will look for or create a solution that allows external drag and drop from a wx tree control.
Quote from: BlueHazzard on May 10, 2018, 09:51:16 PM
This should fix the issue
diff --git a/src/src/projectmanagerui.cpp b/src/src/projectmanagerui.cpp
index cbd93a6fe..6ca7d0926 100644
--- a/src/src/projectmanagerui.cpp
+++ b/src/src/projectmanagerui.cpp
@@ -977,11 +977,8 @@ void ProjectManagerUI::OnTreeBeginDrag(wxTreeEvent& event)
wxDropSource dragSource(m_pTree);
dragSource.SetData(dropObject);
dragSource.DoDragDrop();
- // we disallow the drag of files within the project tree
- return;
}
-
- // allowed
+ // Allow drag and drop within the project tree
event.Allow();
}
On windows the handling is somehow bugged: If you drag a file the "forbidden" cursor will be shown as long as you hold the mouse button. As soon you release the button the normal "drag&drop" cursor will appear and drag and drop is possible...
It works, but i still will look further...
QuoteI have temporary disabled external drag and drop from projectmanagerui.
External drag and drop is incompatible with wxTreeCtrl internal use of drag and drop.
We can use one or the other, but not both in a wxTreeCtrl.
i have started to work on a implementation with dedicated drag and drop objects, but this is a lot work because the whole logic (moving files between virtual folders without the internal tree control api ecc....) has to be rewritten. And i have no time for this at the moment....
I believe I've just solved this issue, but I want to test it for awhile.
I'll commit in a day or two.
Quote from: BlueHazzard on May 24, 2018, 08:04:27 PM
QuoteI have temporary disabled external drag and drop from projectmanagerui.
External drag and drop is incompatible with wxTreeCtrl internal use of drag and drop.
We can use one or the other, but not both in a wxTreeCtrl.
i have started to work on a implementation with dedicated drag and drop objects, but this is a lot work because the whole logic (moving files between virtual folders without the internal tree control api ecc....) has to be rewritten. And i have no time for this at the moment....
ProjectManagerUI external drag and drop fixed rev 11413