http://wxwidgets.org/news/2018/12/wxwidgets-3.1.2-released/
i really hope we can abandon wx2.8 soon, to get rid of a lot of this project files...
The files for wx2.8 are just two sets. The files for the various 3.x releases are getting out of control. :(
QuoteThe files for the various 3.x releases are getting out of control.
may be, but it works by using 31 versions and adjusting the wx31 environment variable to wxWidgets-3.1.2 correct path.
It is good that we don't need another set of cbp files. 8)
I will use this release in the next nightly. Any objections ?
Nope.
There is a segmentation fault with wx3.1.2, see ticket 773
https://sourceforge.net/p/codeblocks/tickets/773/ (https://sourceforge.net/p/codeblocks/tickets/773/)
Quote from: oBFusCATed on December 11, 2018, 08:31:02 PM
The files for wx2.8 are just two sets. The files for the various 3.x releases are getting out of control. :(
Well if we use wx3.1 we can kick out wx30 ( never used it honestly) too beside wx28
I think we should have an easy way to switch the version. So we have a single set of 3.x files for windows as is done on linux. (another set is possible for 64bit builds of course)
QuoteThere is a segmentation fault with wx3.1.2, see ticket 773
Problem reproduced with gcc 4.9.2 on Windows 7 64 bits. (C::B compiled in 32 or 64 bits)
Does not happen with wxWidgets 3.1.1 (same C::B svn version 11520 !).
Apparently some incompatibilities (or bug) within Code Completion (With wxWidgets 3.1.2, no problems if code completion is disabled !)
So, I'll stay with 3.1.1 version. :-[
gd_on
I suggest to switch to mingw-w64 and something like 7.x or 8.x release! GCC 4.9 and 5.1 are getting too old.
Quote from: oBFusCATed on December 13, 2018, 07:06:33 AM
I think we should have an easy way to switch the version. So we have a single set of 3.x files for windows as is done on linux. (another set is possible for 64bit builds of course)
The old discussion ;)
http://forums.next.codeblocks.org/index.php/topic,21696.0.html
[Edit:] I try to create a feature, where the global variables have default values, and a descriptive text to give it an dialog something like in CMake with a list where you can enter the values, see the project default values and a descriptive text... But this all does not come together nicely. If i have some kind of idea i will open a topic...
Quote from: Miguel Gimenez on December 12, 2018, 08:46:30 PM
There is a segmentation fault with wx3.1.2, see ticket 773
https://sourceforge.net/p/codeblocks/tickets/773/ (https://sourceforge.net/p/codeblocks/tickets/773/)
I can confirm this bug on my Win7(64bit), wx3.1.2 32bit and MinGW-w64's gcc 7.2, C::B trunk.
Quote from: ollydbg on December 13, 2018, 04:25:28 PM
Quote from: Miguel Gimenez on December 12, 2018, 08:46:30 PM
There is a segmentation fault with wx3.1.2, see ticket 773
https://sourceforge.net/p/codeblocks/tickets/773/ (https://sourceforge.net/p/codeblocks/tickets/773/)
I can confirm this bug on my Win7(64bit), wx3.1.2 32bit and MinGW-w64's gcc 7.2, C::B trunk.
If you set a breakpoint in PlatWX.cpp line 1883, you will see the window get destroyed when you hit the "#", later you will get the crash because wid is zero.
QuoteIf you set a breakpoint in PlatWX.cpp line 1883, you will see the window get destroyed when you hit the "#", later you will get the crash because wid is zero.
As I interpret this, when the autocomplete window is shown the editor loses focus and then the OnKillFocus event is fired, killing the autocomplete window. May be this window claims focus in wx312 while it didn't in wx311.
Quote from: Miguel Gimenez on December 14, 2018, 02:04:04 PM
QuoteIf you set a breakpoint in PlatWX.cpp line 1883, you will see the window get destroyed when you hit the "#", later you will get the crash because wid is zero.
As I interpret this, when the autocomplete window is shown the editor loses focus and then the OnKillFocus event is fired, killing the autocomplete window. May be this window claims focus in wx312 while it didn't in wx311.
Yes, I agree with you. I think there are some code in PlatWX.cpp, such as listbox, when get focus event, it just reset the focus to its parent window, it looks like this refocus does not happen in cb build against wx3.1.2.
I can't test until monday, but it can be related to this wxWidgets commit:
https://github.com/wxWidgets/wxWidgets/commit/79a37a2a65d8bde315bcd863838f21c72912840a (https://github.com/wxWidgets/wxWidgets/commit/79a37a2a65d8bde315bcd863838f21c72912840a)
Can someone reproduce this in the stc sample of wxwidgets and report this on the wx devs?
I cannot reproduce this on linux.
QuoteCan someone reproduce this in the stc sample of wxwidgets
I have just tested the stc sample; it has code highlighting but no code completion, so there is no popup window when typing. The popup menu associated to the right button works OK.
The wxPopupWindow used in Code Completion was reimplemented under MSW with heavy changes, see:
https://github.com/wxWidgets/wxWidgets/commit/56c419116838045f23f046112960d4e42f98f80d#diff-ae8d87556bfe1b32c101c69c2fb1cec4 (https://github.com/wxWidgets/wxWidgets/commit/56c419116838045f23f046112960d4e42f98f80d#diff-ae8d87556bfe1b32c101c69c2fb1cec4)
This changes include moving focus back and forth; these must be triggering the KillFocus event which destroys the popup.
Someone needs to report this to wx devs. I intend to do some testing in the next days, but I'm not sure that my windows would start up. So if someone can modify the stc sample to reproduce the problem it will be best.
It seems this is a critical issue, so moving forward with wx 3.1.2 is blocked by this. Interesting why codelite is not affected...
I don't know if this is helpful or not, but here's a patch to add a very rudimentary type of autocompletion to the wxWidgets stc sample. It doesn't show the crash under discussion, so it might not be helpful at all.
diff --git a/samples/stc/edit.cpp b/samples/stc/edit.cpp
index 7e7f412ec2..c16b1aae2b 100644
--- a/samples/stc/edit.cpp
+++ b/samples/stc/edit.cpp
@@ -60,6 +60,21 @@ const int ANNOTATION_STYLE = wxSTC_STYLE_LASTPREDEFINED + 1;
// Edit
//----------------------------------------------------------------------------
+static char * pound_xpm[] = {
+"10 10 2 1",
+" c None",
+". c #BD08F9",
+" .. .. ",
+" .. .. ",
+"..........",
+"..........",
+" .. .. ",
+" .. .. ",
+"..........",
+"..........",
+" .. .. ",
+" .. .. "};
+
wxBEGIN_EVENT_TABLE (Edit, wxStyledTextCtrl)
// common
EVT_SIZE ( Edit::OnSize)
@@ -177,6 +192,10 @@ Edit::Edit (wxWindow *parent, wxWindowID id,
CmdKeyClear (wxSTC_KEY_TAB, 0); // this is done by the menu accelerator key
SetLayoutCache (wxSTC_CACHE_PAGE);
UsePopUp(wxSTC_POPUP_ALL);
+
+ wxImage::AddHandler(new wxXPMHandler);
+ wxBitmap b(pound_xpm);
+ RegisterImage(0, b);
}
Edit::~Edit () {}
@@ -483,6 +502,13 @@ void Edit::OnCharAdded (wxStyledTextEvent &event) {
SetLineIndentation (currentLine, lineInd);
GotoPos(PositionFromLine (currentLine) + lineInd);
}
+ else if (chr == '#') {
+ wxString s = "define?0 elif?0 elifdef?0 elifndef?0 else?0 endif?0 "
+ "error?0 if?0 ifdef?0 ifndef?0 include?0 line?0 line?0 "
+ "pragma?0 undef?0";
+
+ AutoCompShow(0,s);
+ }
}
Strange. I guess we're doing something 'advanced'...
There are many code in the file: sdk\wxscintilla\src\PlatWX.cpp, which change focus to it's parent, maybe, they get conflict which the current wx3.1.2's implementation.
Quote from: oBFusCATed on December 18, 2018, 08:41:51 PM
Interesting why codelite is not affected...
This is because CodeLite does not use the builtin wxSTC popup window, I created my own (for other reasons) couple of years ago.
https://github.com/eranif/codelite/blob/master/Plugin/wxCodeCompletionBox.cpp
Quote from: New Pagodi on December 18, 2018, 11:55:06 PM
I don't know if this is helpful or not, but here's a patch to add a very rudimentary type of autocompletion to the wxWidgets stc sample. It doesn't show the crash under discussion, so it might not be helpful at all.
diff --git a/samples/stc/edit.cpp b/samples/stc/edit.cpp
index 7e7f412ec2..c16b1aae2b 100644
--- a/samples/stc/edit.cpp
+++ b/samples/stc/edit.cpp
@@ -60,6 +60,21 @@ const int ANNOTATION_STYLE = wxSTC_STYLE_LASTPREDEFINED + 1;
// Edit
//----------------------------------------------------------------------------
+static char * pound_xpm[] = {
+"10 10 2 1",
+" c None",
+". c #BD08F9",
+" .. .. ",
+" .. .. ",
+"..........",
+"..........",
+" .. .. ",
+" .. .. ",
+"..........",
+"..........",
+" .. .. ",
+" .. .. "};
+
wxBEGIN_EVENT_TABLE (Edit, wxStyledTextCtrl)
// common
EVT_SIZE ( Edit::OnSize)
@@ -177,6 +192,10 @@ Edit::Edit (wxWindow *parent, wxWindowID id,
CmdKeyClear (wxSTC_KEY_TAB, 0); // this is done by the menu accelerator key
SetLayoutCache (wxSTC_CACHE_PAGE);
UsePopUp(wxSTC_POPUP_ALL);
+
+ wxImage::AddHandler(new wxXPMHandler);
+ wxBitmap b(pound_xpm);
+ RegisterImage(0, b);
}
Edit::~Edit () {}
@@ -483,6 +502,13 @@ void Edit::OnCharAdded (wxStyledTextEvent &event) {
SetLineIndentation (currentLine, lineInd);
GotoPos(PositionFromLine (currentLine) + lineInd);
}
+ else if (chr == '#') {
+ wxString s = "define?0 elif?0 elifdef?0 elifndef?0 else?0 endif?0 "
+ "error?0 if?0 ifdef?0 ifndef?0 include?0 line?0 line?0 "
+ "pragma?0 undef?0";
+
+ AutoCompShow(0,s);
+ }
}
Hi, thanks for the contribution, I just test the stc sample with your patch.
The auto suggestion(auto completion) window shows correctly after I hit the "#", and I can keep typing in the editor, while the correct item is selected.
The issue I see is that if I "deactivate" the stcsample's main frame, the auto completion list is still active, which covers every active application's window. :(
The same effect can be achieved when we comment out the line:
void cbStyledTextCtrl::OnKillFocus(wxFocusEvent& event)
{
// cancel auto-completion list when losing focus
//if ( AutoCompActive() )
// AutoCompCancel();
if ( CallTipActive() )
CallTipCancel();
event.Skip();
}
With the above changes in sdk\cbstyledtextctrl.cpp, we can avoid the crash issue, but we get the same issue as the stc sample with your patch. :)
When debugging, I found the reason comes from this code flow:
void AutoComplete::Show(bool show) {
lb->Show(show); // set bp1 here
if (show)
lb->Select(0); // set bp2 here
}
When you try to show a autocompletion window, you first hit the bp1, then I see that a lose focus event happens before I hit the bp2, so the function
void cbStyledTextCtrl::OnKillFocus(wxFocusEvent& event)
{
// cancel auto-completion list when losing focus
if ( AutoCompActive() )
AutoCompCancel();
if ( CallTipActive() )
CallTipCancel();
event.Skip();
}
is called between bp1 and bp2.
Finally, when we goes to bp2, the window is already destroyed (wid==0). :(
@New Pagodi:
You can use this patch to reproduce the problem:
diff --git a/samples/stc/edit.cpp b/samples/stc/edit.cpp
index 855c18f..6a1c428 100644
--- a/samples/stc/edit.cpp
+++ b/samples/stc/edit.cpp
@@ -117,6 +117,7 @@ wxBEGIN_EVENT_TABLE (Edit, wxStyledTextCtrl)
EVT_STC_CHARADDED (wxID_ANY, Edit::OnCharAdded)
EVT_KEY_DOWN( Edit::OnKeyDown )
+ EVT_KILL_FOCUS(Edit::OnKillFocus)
wxEND_EVENT_TABLE()
Edit::Edit (wxWindow *parent, wxWindowID id,
@@ -472,6 +473,17 @@ void Edit::OnMarginClick (wxStyledTextEvent &event) {
}
}
+void Edit::OnKillFocus(wxFocusEvent& event)
+{
+ if ( AutoCompActive() )
+ AutoCompCancel();
+
+ if ( CallTipActive() )
+ CallTipCancel();
+
+ event.Skip();
+}
+
void Edit::OnCharAdded (wxStyledTextEvent &event) {
char chr = (char)event.GetKey();
int currentLine = GetCurrentLine();
@@ -485,6 +497,21 @@ void Edit::OnCharAdded (wxStyledTextEvent &event) {
SetLineIndentation (currentLine, lineInd);
GotoPos(PositionFromLine (currentLine) + lineInd);
}
+ else
+ {
+ wxString items;
+ items += "test1\r";
+ items += "test2\r";
+ items += "test3\r";
+ items += "test4\r";
+ items += "test5\r";
+
+ AutoCompSetIgnoreCase(true);
+ AutoCompSetMaxHeight(14);
+ AutoCompSetTypeSeparator(wxT('\n'));
+ AutoCompSetSeparator(wxT('\r'));
+ AutoCompShow(0, items);
+ }
}
diff --git a/samples/stc/edit.h b/samples/stc/edit.h
index 703ebae..2762a85 100644
--- a/samples/stc/edit.h
+++ b/samples/stc/edit.h
@@ -107,6 +107,7 @@ public:
void OnCharAdded (wxStyledTextEvent &event);
void OnKeyDown(wxKeyEvent &event);
+ void OnKillFocus(wxFocusEvent& event);
//! language/lexer
wxString DeterminePrefs (const wxString &filename);
I've found that the issue was that this commit (https://github.com/wxWidgets/wxWidgets/commit/56c419116838045f23f046112960d4e42f98f80d) changed the style of window used for popups on MSW. I've got a proposal for a fix that restores the old behavior if the popup is created with a certain style.
While working on this, I discovered several other issues with auto completion. I've got a work in progress here (https://github.com/NewPagodi/wxWidgets/tree/stcautocompfixes). It needs quite a bit of clean up and has some problems compiling on GTK. As soon as I get everything presentable, I was going to start a thread on the wxWidgets developers list asking if those fixes are acceptable.
Cool thanks.
Would it be possible to add the kill focus event to the stc sample?
So there is an easy way to test our use case in the future.
I've started a thread on the problems with autocompletion on the wxdev list here (https://groups.google.com/forum/#!topic/wx-dev/R--2avQzHdo) if anyone wants to join in.
But I guess none of those changes proposed there will help with with getting codeblocks to work with wxWidgets 3.1.2. In order to do that, somehow the old popup behavior has to be restored in codeblocks itself - at least until 3.1.3. Looking over the codeblocks sources, I think the easiest way to do that is to define a popup class in src/sdk/wxscintilla/src/PlatWX.cpp between
#if wxUSE_POPUPWIN //-----------------------------------
#include "wx/popupwin.h"
and
// A popup window to place the wxSCIListBox upon
class wxSCIListBoxWin : public wxPopupWindow
Here's the a cut and paste of the old popupwindow code with a few minor modifications:
#ifdef __WXMSW__
#include "wx/msw/private.h" // for GetDesktopWindow()
class wxNonActivatingPopupWindow : public wxPopupWindowBase
{
public:
wxNonActivatingPopupWindow() { }
wxNonActivatingPopupWindow(wxWindow *parent, int flags = wxBORDER_NONE)
{ (void)Create(parent, flags); }
bool Create(wxWindow *parent, int flags = wxBORDER_NONE);
virtual void SetFocus() wxOVERRIDE;
virtual bool Show(bool show = true) wxOVERRIDE;
// return the style to be used for the popup windows
virtual WXDWORD MSWGetStyle(long flags, WXDWORD *exstyle) const wxOVERRIDE;
// get the HWND to be used as parent of this window with CreateWindow()
virtual WXHWND MSWGetParent() const wxOVERRIDE;
};
bool wxNonActivatingPopupWindow::Create(wxWindow *parent, int flags)
{
// popup windows are created hidden by default
Hide();
return wxPopupWindowBase::Create(parent) &&
wxWindow::Create(parent, wxID_ANY,
wxDefaultPosition, wxDefaultSize,
flags | wxPOPUP_WINDOW);
}
WXDWORD wxNonActivatingPopupWindow::MSWGetStyle(long flags, WXDWORD *exstyle) const
{
// we only honour the border flags, the others don't make sense for us
WXDWORD style = wxWindow::MSWGetStyle(flags & wxBORDER_MASK, exstyle);
if ( exstyle )
{
// a popup window floats on top of everything
*exstyle |= WS_EX_TOPMOST | WS_EX_TOOLWINDOW;
}
return style;
}
WXHWND wxNonActivatingPopupWindow::MSWGetParent() const
{
// we must be a child of the desktop to be able to extend beyond the parent
// window client area (like the comboboxes drop downs do)
//
// NB: alternative implementation would be to use WS_POPUP instead of
// WS_CHILD but then showing a popup would deactivate the parent which
// is ugly and working around this, although possible, is even more
// ugly
return (WXHWND)::GetDesktopWindow();
}
void wxNonActivatingPopupWindow::SetFocus()
{
// Focusing on a popup window does not work on MSW unless WS_POPUP style is
// set (which is never the case currently, see the note in MSWGetParent()).
// We do not even want to try to set the focus, as it returns an error from
// SetFocus() on recent Windows versions (since Vista) and the resulting
// debug message is annoying.
}
bool wxNonActivatingPopupWindow::Show(bool show)
{
if ( !wxWindowMSW::Show(show) )
return false;
if ( show )
{
// raise to top of z order
if (!::SetWindowPos((HWND)GetHWND(), HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE))
{
wxLogLastError(wxT("SetWindowPos"));
}
// and set it as the foreground window so the mouse can be captured
::SetForegroundWindow((HWND)GetHWND());
}
return true;
}
// temporarily define wxPopupWindow to be the new class
#define wxPopupWindow wxNonActivatingPopupWindow
#endif //__WXMSW__
The class can obviously be renames as needed. I've tested this with wxSTC, but I don't know how to compile codeblocks to see if it works there too.
Thanks, for us it would probably be easier if we patch our version of wx3.1.2 after your fixes are approved.
Quote from: New Pagodi on January 06, 2019, 06:47:36 AM
I've started a thread on the problems with autocompletion on the wxdev list here (https://groups.google.com/forum/#!topic/wx-dev/R--2avQzHdo) if anyone wants to join in.
But I guess none of those changes proposed there will help with with getting codeblocks to work with wxWidgets 3.1.2. In order to do that, somehow the old popup behavior has to be restored in codeblocks itself - at least until 3.1.3. Looking over the codeblocks sources, I think the easiest way to do that is to define a popup class in src/sdk/wxscintilla/src/PlatWX.cpp between
#if wxUSE_POPUPWIN //-----------------------------------
#include "wx/popupwin.h"
and
// A popup window to place the wxSCIListBox upon
class wxSCIListBoxWin : public wxPopupWindow
Here's the a cut and paste of the old popupwindow code with a few minor modifications:
...
The class can obviously be renames as needed. I've tested this with wxSTC, but I don't know how to compile codeblocks to see if it works there too.
Hi, I just tested it with you suggested changes, it works without crash with wx3.1.2, thanks!
I'm using C::B with New Pagodi's patch and CC works OK, but sometimes the caret disappears while editing: you can't see it, but typing works normally. The only way to make it visible again is changing focus to another window and then to the current window.
If I disable CC this does not happen. I can't test without the patch because C:B crashes.
Using Windows 7 64 bits, wx3.1.2 32 bits, revision 11552.
Quote from: Miguel Gimenez on January 15, 2019, 11:53:39 AM
I'm using C::B with New Pagodi's patch and CC works OK, but sometimes the caret disappears while editing: you can't see it, but typing works normally. The only way to make it visible again is changing focus to another window and then to the current window.
If I disable CC this does not happen. I can't test without the patch because C:B crashes.
Using Windows 7 64 bits, wx3.1.2 32 bits, revision 11552.
I can confirm this issue.
EDIT: it looks like this issue happens when I hover the mouse on some variable, which means it's a calltip related issue.
Also, when this issue happens, the high light of the current line is also missing.
Quote from: ollydbg on January 15, 2019, 03:15:53 PM
Quote from: Miguel Gimenez on January 15, 2019, 11:53:39 AM
I'm using C::B with New Pagodi's patch and CC works OK, but sometimes the caret disappears while editing: you can't see it, but typing works normally. The only way to make it visible again is changing focus to another window and then to the current window.
If I disable CC this does not happen. I can't test without the patch because C:B crashes.
Using Windows 7 64 bits, wx3.1.2 32 bits, revision 11552.
I can confirm this issue.
EDIT: it looks like this issue happens when I hover the mouse on some variable, which means it's a calltip related issue.
Also, when this issue happens, the high light of the current line is also missing.
My guess here is that we have such code in sdk\ccmanager.cpp
//{ Unfocusable popup
// imported with small changes from PlatWX.cpp
class UnfocusablePopupWindow :
#if wxUSE_POPUPWIN
public wxPopupWindow
#else
public wxFrame
#endif // wxUSE_POPUPWIN
{
public:
#if wxUSE_POPUPWIN
typedef wxPopupWindow BaseClass;
UnfocusablePopupWindow(wxWindow* parent, int style = wxBORDER_NONE) :
wxPopupWindow(parent, style)
#else
typedef wxFrame BaseClass;
UnfocusablePopupWindow(wxWindow* parent, int style = 0) :
wxFrame(parent, wxID_ANY, wxEmptyString, wxDefaultPosition, wxDefaultSize,
style | wxFRAME_NO_TASKBAR | wxFRAME_FLOAT_ON_PARENT | wxNO_BORDER | wxFRAME_SHAPED
#ifdef __WXMAC__
| wxPOPUP_WINDOW
#endif // __WXMAC__
)
#endif // wxUSE_POPUPWIN
{
Hide();
}
bool Destroy() override;
void OnFocus(wxFocusEvent& event);
void ActivateParent();
void DoSetSize(int x, int y, int width, int height, int sizeFlags = wxSIZE_AUTO) override;
bool Show(bool show = true) override;
private:
DECLARE_EVENT_TABLE()
};
This means we need to use the same wxNonActivatingPopupWindow class as New Pagodi's patch?
QuoteThis means we need to use the same wxNonActivatingPopupWindow class as New Pagodi's patch?
I have just tested this and the issue is still present.
If I apply New Pagodi's patch to src\sdk\wxscintilla\src\ScintillaWX.cpp (near line 110) then the isssue goes away (caret doesn't disappear and call tips are shown).
Probably patching src\sdk\ccmanager.cpp as you suggested solves an still unseen problem.
The changes to wxPopupWindow in wx3.1.2 are a big issue for Code Completion. New Pagodi has a pull request in wxWidgets site restoring old behaviour, it is accepted (but not yet applied) for wx3.1.3.
We can patch Scintilla, backport New Pagodi's changes to wx3.1.2 (this would force all developers and outsiders like me to use patched wx libraries) or wait and jump directly from 3.1.1 to 3.1.3 when it is ready.
First we wait for the changes to enter wx-master. Then we'll decide what course of action we'll take for night/release binaries. I don't think waiting for wx3.1.3 is viable option. wx releases are very infrequent.
Quote from: Miguel Gimenez on January 15, 2019, 08:29:53 PM
If I apply New Pagodi's patch to src\sdk\wxscintilla\src\ScintillaWX.cpp (near line 110) then the isssue goes away (caret doesn't disappear and call tips are shown).
Can you share the whole patch against C::B, thanks.
I see New Pagodi's patch for the wx trunk is huge. :)
This is the patch for PlatWX and ScintillaWX, please note it is a quick and dirty modification intended for testing.
There are more uses of wxPopupWindow:
- src\include\infowindow.h
- src\sdk\ccmanager.cpp (as you noted)
- src\src\watchesdlg.cpp and src\src\watchesdlg.h
For me, build 11554 with wxWidgets 3.1.2 (compilation in 64 bits) still crash when I introduce a # as a 1rst character in a line. Workaround : disabling CC.
gd_on
The temporary patch above fixes this issue and another (calltips not showing and caret becoming invisible).
Quote from: Miguel Gimenez on January 16, 2019, 04:47:20 PM
This is the patch for PlatWX and ScintillaWX, please note it is a quick and dirty modification intended for testing.
There are more uses of wxPopupWindow:
- src\include\infowindow.h
- src\sdk\ccmanager.cpp (as you noted)
- src\src\watchesdlg.cpp and src\src\watchesdlg.h
Thanks for your sharing!
EDIT: For the next C::B Windows release, I think we either use 3.1.1 or we need a patched 3.1.2. But waiting for 3.1.3 may takes too long time.
Thanks M. Gimenez. No more problem (until the next one ;D) with your temporary patch ;).
gd_on
Quote from: oBFusCATed on January 15, 2019, 09:09:38 PM
First we wait for the changes to enter wx-master. Then we'll decide what course of action we'll take for night/release binaries. I don't think waiting for wx3.1.3 is viable option. wx releases are very infrequent.
New Pagodi's changes to wxPopupWindow have been commited today:
https://github.com/wxWidgets/wxWidgets/commit/07f64c3b75c79b79b46a7e8ac8db585a618c57da (https://github.com/wxWidgets/wxWidgets/commit/07f64c3b75c79b79b46a7e8ac8db585a618c57da)
EDIT: I have just compiled C::B revision 11558 with this commit in MSW, the issues with Code Completion are gone.
Would it be possible to create a patch only containing this change against 3.1.2 and see if everything works fine.
@killerbot: Are you willing to use a patched version of 3.1.2 for the night builds?
I have patched my wx3.1.2 library with New Pagodi´s changes and Code Completion works fine.
I have generated a diff file, but I don't know if it can be applied without some tweaking (indexes probably are invalid).
Just in case I am attaching also the affected files (including the interface one, although it is not needed).
Does this new wxPopupWindow patch is cumulative with the precedent one (declared as temporary on january 16) or should we start from the original version ?
If wxWidgets is patched then the temporary patch should be removed, because it hides the library's wxPopupWindow.
Quote from: Miguel Gimenez on January 28, 2019, 08:44:58 PM
I have patched my wx3.1.2 library with New Pagodi´s changes and Code Completion works fine.
I have generated a diff file, but I don't know if it can be applied without some tweaking (indexes probably are invalid).
Just in case I am attaching also the affected files (including the interface one, although it is not needed).
Nice work, I just tested it, and it works fine!
If devs choose patching wxWidgets 3.1.2 to solve CC crashes I suggest adding this code (or similar) somewhere so people compiling from SVN in MSW with 3.1.2 know what to do.
#if wxUSE_POPUPWIN && defined(__WXMSW__) && wxVERSION_NUMBER == 3102
#include "wx/popupwin.h"
#ifndef wxPU_CONTAINS_CONTROLS
#error wxWidgets 3.1.2 must be patched or CC will crash
#endif
#endif