Re: [wx-dev] Re: incompatible changes in wxFileDialog in 2.8
Robin Dunn
>
> However this still begs the question why did we remove SetStyle() without
> deprecating it first and not even mentioning it in docs/changes.txt
I don't know the reasons, but it looks like it was from patch 1488371,
which was applied by you.
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/filedlg.h?rev=1.45&content-type=text/vnd.viewcvs-markup
http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/filedlg.h.diff?r1=1.44&r2=1.45
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
ABX
> why did we/I decide that applying
> it was a good idea...
IOW are you asking about these threads:
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/73937/focus=73937
http://thread.gmane.org/gmane.comp.lib.wxwidgets.devel/73562/focus=73562
?
ABX
Vadim Zeitlin
FM> the reason is simple, wxFileDialog::SetStyle() has no reason to exist
FM> given there's wxWindow::SetWindowStyle.
It's a valid reason to deprecate it, not to remove it...
FM> IIRC wxFileDialog was using its own m_style (or similar) variable.
FM> This is very bad since:
FM>
FM> wxFileDialog dlg(this, ..., wxFD_OPEN|wxFD_MULTIPLE...)
FM> bool has_fd_open = dlg.GetWindowStyle() & wxFD_OPEN;
FM>
FM> would set has_fd_open to false:
I also agree that removing the variable was the right thing to do but it
(for once :-) wasn't public. But the methods were.
FM> I agree that the new wxFD_* flags should be mentioned in changes.txt but
FM> doing a s/SetStyle/SetWindowStyle seems so easy to me that I don't think
FM> it's necessary to create a specific (deprecated) wrapper.
I am pretty sure it is. I really don't know why I decided we could remove
them when applying the patch, this is totally contrary to how we usually do
things. I don't know this code that well but I think the patch should be
trivial so I'll try to add the wrappers soon -- unless you beat me to it.
Regards,
VZ