User forums > Help
wxsmith crashing after upgrade to Ubuntu 17.04
oBFusCATed:
--- Quote from: awake on June 09, 2017, 03:07:57 am ---As I said, it could be argued that this is a wxWidgets problem ... but they DO recommend using the static box as the parent, and if that is done (for all of the widgets that are inside the static box sizer), then drag and drop works as advertised ... so perhaps wxsmith ought to be changed to reflect that recommendation?
--- End quote ---
Do you have a link with their recommendation?
awake:
Here you go - look under the Detailed Description: http://docs.wxwidgets.org/3.0/classwx_static_box.html
On looking back at it, it is not a very strongly worded recommendation: "Note that while the previous versions required that windows appearing inside a static box be created as its siblings (i.e. use the same parent as the static box itself), since wxWidgets 2.9.1 it is also possible to create them as children of wxStaticBox itself and you are actually encouraged to do it like this if compatibility with the previous versions is not important." (my emphasis added)
Certainly they do not spell out what the implications are for doing it the old way, e.g., that DnD won't work. (I wonder if anything else might not work properly in this situation - I've got some old gremlins that I've worked around, that might possibly be related to a similar issue ... have to do some digging. My guess is that the static box is "on top of" the other widgets, so they are not getting "seen" - but my guess probably reveals more about my ignorance of the inner workings of wxWidgets than anything else!)
I tried a simple test - create a frame, sizer, panel, sizer. Inside are two sizers, one a regular sizer and one a static box sizer. Inside each is a list box, set up to accept drag-and-drop files. Created the "old" way (as wxsmith does it now), the list box inside the regular sizer works just fine; the one in the static box is oblivious to attempts to drag and drop. I've come up with three possible alternatives:
* Work around: Set the static box associated with the static box sizer as the drag and drop target, but code it to put the results in the desired widget. For the current app, this will work fine, and it's an easy work-around. Possible problem: often I have more than one widget inside a static box sizer, so the question will be whether more than one of them requires DnD, or whether it will be confusing to drop files on, say, an edit control only to see them show up in the list box.
* Alter wxsmith by having it set all widgets inside a static box sizer to have their parent as the static box associated with the sizer. Note that if you set just one of the widgets to be parented by the static box, but the rest to be as normal (e.g., parented by the panel), the other widgets do not display correctly. However, if you set all of the widgets to the static box parent, they all display correctly, work correctly, and individually accept DnD. I tested this by adjusting the wxsmith generated code - but obviously, the next time I tweak the UI using wxsmith, all of those changes will get overwritten. Possible major problem: wxsmith would have to distinguish whether it was designing for pre-2.91 or post-2.91 wxWidgets, since parenting by the static box would apparently not work in pre-2.91. (See more reflection on this problem below.)
* Possible alternative work around, though I haven't tried it: perhaps one could let wxsmith generate its code, and then after that re-parent each of the widgets inside the static box sizer. I'll have to give that a try to see if it works. Again, I assume it would have to be all widgets, not just some, in order to avoid display problems.After thinking it through systematically in the list above, honestly, my best guess is that it would be better to leave wxsmith alone for the moment, and instead encourage wxWidgets to document this peculiarity of behavior and publish the possible work-arounds. My thinking is that there is probably still a large user base using pre-2.91 wxWidgets, and others who may switch from, say, 3.x to 2.8 because of problems - which would then break all of the code that wxsmith would have built - and it could get awfully confusing trying to anticipate which version is going to be used when.
oBFusCATed:
Can you try to reproduce this problem in a wx sample and try to ask on same of wx's mailing lists if this is a bug or this is expected problem that couldn't be solved?
We could modify wxsmith, but we need to keep it compatible, so it can still generate wx2.8 code. Parts of c::b are done with wxsmith...
awake:
Sure, I can give that a whirl. As noted, I came to the conclusion that it would be better NOT to try to change wxsmith - since it still needs to support 2.8. I'd say wx could label it a bug, or could simply offer [more easily found] clarity about the inconsistent behavior.
awake:
I have created a sample program to illustrate the problem, which I've included below in case anyone is interested. The problem may be limited to Linux (wxGTK) - ? In any case, I have reported it through the wxWidgets bug tracker, but since this is my first report, it will have to pass through the moderator(s). We'll see what happens ...
On Linux (maybe also Windows/MingW??), the following code can be compiled via command line as follows: g++ example.cpp `wx-config --cxxflags --libs` -o example
When run, the leftmost and rightmost listboxes will accept drag-and-drop of files from a browser, but the middle one will not; the difference is whether the parent is the underlying panel (appropriate for 2.8 builds, and how wxsmith currently generates the code) or is the static box attached to the wxStaticBoxSizer.
--- Code: ---#include "wx/wxprec.h"
#ifdef __BORLANDC__
#pragma hdrstop
#endif
#ifndef WX_PRECOMP
#include "wx/wx.h"
#endif
#include <wx/app.h>
#include <wx/frame.h>
#include <wx/listbox.h>
#include <wx/menu.h>
#include <wx/panel.h>
#include <wx/sizer.h>
#include <wx/dnd.h>
#include <wx/intl.h>
#include <wx/string.h>
class testApp : public wxApp
{
public:
virtual bool OnInit();
};
class testFrame: public wxFrame
{
public:
testFrame(wxWindow* parent,wxWindowID id = -1);
virtual ~testFrame();
private:
void OnQuit(wxCommandEvent& event);
wxListBox* lbPlain;
wxListBox* lbStatic1;
wxListBox* lbStatic2;
DECLARE_EVENT_TABLE()
};
class DF : public wxFileDropTarget
{
public:
DF ( wxListBox * lb_target );
virtual bool OnDropFiles ( wxCoord x, wxCoord y, const wxArrayString & files );
protected:
wxListBox * m_target;
};
IMPLEMENT_APP(testApp);
bool testApp::OnInit()
{
testFrame* Frame = new testFrame(0);
Frame->Show();
SetTopWindow(Frame);
return true;
}
//#include <wx/msgdlg.h>
BEGIN_EVENT_TABLE(testFrame,wxFrame)
END_EVENT_TABLE()
testFrame::testFrame(wxWindow* parent,wxWindowID id)
{
wxBoxSizer* bsOuter;
wxPanel* Panel1;
wxBoxSizer* bsInner;
wxBoxSizer* bsPlain;
wxStaticBoxSizer* bsStaticBox1;
wxStaticBoxSizer* bsStaticBox2;
Create(parent, id, wxEmptyString, wxDefaultPosition, wxDefaultSize, wxDEFAULT_FRAME_STYLE, _T("id"));
// Create the basic foundation: frame contains a standard box sizer (bsOuter)
// which contains a panel (Panel1) which contains a standard box sizer (bsInner)
bsOuter = new wxBoxSizer(wxHORIZONTAL);
Panel1 = new wxPanel(this, wxID_ANY);
bsInner = new wxBoxSizer(wxHORIZONTAL);
// Create a standard sizer containing a listbox and place it in the inner sizer
bsPlain = new wxBoxSizer(wxHORIZONTAL);
lbPlain = new wxListBox(Panel1, wxID_ANY);
lbPlain->SetMinSize(wxSize(200,400));
bsPlain->Add(lbPlain, 1, wxALL|wxEXPAND, 5);
bsInner->Add(bsPlain, 1, wxALL|wxEXPAND, 5);
// Create a Static Box sizer containing a listbox and place it in the inner sizer
// (next to the "plain" sizer created above). Note that the list box it contains is
// created according to the pre-2.9.1 rules, i.e., parent is Panel1
bsStaticBox1 = new wxStaticBoxSizer(wxHORIZONTAL, Panel1, _("Static Box Sizer 1"));
lbStatic1 = new wxListBox(Panel1, wxID_ANY);
bsStaticBox1->Add(lbStatic1, 1, wxALL|wxEXPAND, 5);
bsInner->Add(bsStaticBox1, 1, wxALL|wxEXPAND, 5);
// Create another Static Box sizer containing a listbox and place it next to the
// bsStaticBox1 created above. Note that the list box this one contains is
// created according to the 2.9.1 and above rules, i.e., parent is the wxStaticBox
// contained within the Static Box sizer.
bsStaticBox2 = new wxStaticBoxSizer(wxHORIZONTAL, Panel1, _("Static Box Sizer 2"));
lbStatic2 = new wxListBox(bsStaticBox2->GetStaticBox(), wxID_ANY);
bsStaticBox2->Add(lbStatic2, 1, wxALL|wxEXPAND, 5);
bsInner->Add(bsStaticBox2, 1, wxALL|wxEXPAND, 5);
Panel1->SetSizer(bsInner);
bsInner->Fit(Panel1);
bsInner->SetSizeHints(Panel1);
bsOuter->Add(Panel1, 1, wxALL|wxALIGN_CENTER_HORIZONTAL|wxALIGN_CENTER_VERTICAL, 5);
SetSizer(bsOuter);
bsOuter->Fit(this);
bsOuter->SetSizeHints(this);
lbPlain->SetDropTarget(new DF(lbPlain));
lbStatic1->SetDropTarget(new DF(lbStatic2));
lbStatic2->SetDropTarget(new DF(lbStatic2));
}
testFrame::~testFrame()
{
}
void testFrame::OnQuit(wxCommandEvent& event)
{
Close();
}
DF::DF ( wxListBox * lb_target )
{
m_target = lb_target;
}
bool DF::OnDropFiles ( wxCoord x, wxCoord y, const wxArrayString & files )
{
m_target->Append(files);
return true;
}
--- End code ---
Navigation
[0] Message Index
[*] Previous page
Go to full version