My app has a progress dialog. I am calling dlg.Destroy() at the end of
the program when it is no longer required. On OS X it disappears and
the app exits. On MSW and GTK (linux), the dialog is not destroyed and
I have to press the OK button for it to disappear and the app to exit.
What would cause dlg.Destroy() not to destroy a dialog ??
Are there some extra parameters that need to be used on MSW and GTK ??
Actually, I'm calling dlg.Update() and it does not return.
All other calls to Update() return. The only difference to this call is
that the value is set to the maximum, so I guess that is what causing
Update() to wait.
Should Update() wait for the button to be pressed when the value is set
to the maximum ??
I assume the functionality should be the same on all platforms, yes ??
It seems OS X behaves differently, as Update() seems to return immediately.
Thanks, Brendan.
···
On 23/05/10 5:55 PM, Brendan Simon (eTRIX) wrote:
My app has a progress dialog. I am calling dlg.Destroy() at the end of
the program when it is no longer required. On OS X it disappears and
the app exits. On MSW and GTK (linux), the dialog is not destroyed and
I have to press the OK button for it to disappear and the app to exit.
What would cause dlg.Destroy() not to destroy a dialog ??
Are there some extra parameters that need to be used on MSW and GTK ??
Actually, I'm calling dlg.Update() and it does not return.
All other calls to Update() return. The only difference to this call is
that the value is set to the maximum, so I guess that is what causing
Update() to wait.
Should Update() wait for the button to be pressed when the value is set
to the maximum ??
I assume the functionality should be the same on all platforms, yes ??
It seems OS X behaves differently, as Update() seems to return immediately.
My app has a progress dialog. I am calling dlg.Destroy() at the end of
the program when it is no longer required. On OS X it disappears and
the app exits. On MSW and GTK (linux), the dialog is not destroyed and
I have to press the OK button for it to disappear and the app to exit.
What would cause dlg.Destroy() not to destroy a dialog ??
Are there some extra parameters that need to be used on MSW and GTK ??
Attached is a small sample to demonstrate the problem.
Interestingly, if the 'style' keyword to the constructor is NOT passed,
then the dialog closes immediately when the maximum value is set, such
that the maximum value can NOT be seen. This is consistent on both MSW
and OSX. Is this expected ??
On a slightly different problem with ProgressDialog, if the initial
message is a multi-line message (e.g. 10 lines) then the width of the
dialog goes way off the screen. It looks like a simple string length is
being used to set the dialog box width. A better approach would be to
use string.split('\n') and determine the maximum string length of all
the lines.
My app has a progress dialog. I am calling dlg.Destroy() at the end of
the program when it is no longer required. On OS X it disappears and
the app exits. On MSW and GTK (linux), the dialog is not destroyed and
I have to press the OK button for it to disappear and the app to exit.
What would cause dlg.Destroy() not to destroy a dialog ??
Are there some extra parameters that need to be used on MSW and GTK ??
On 5/23/10 2:33 AM, Brendan Simon (eTRIX) wrote:
Actually, I'm calling dlg.Update() and it does not return.
All other calls to Update() return. The only difference to this call is
that the value is set to the maximum, so I guess that is what causing
Update() to wait.
Should Update() wait for the button to be pressed when the value is set
to the maximum ??
I assume the functionality should be the same on all platforms, yes ??
It seems OS X behaves differently, as Update() seems to return
immediately.
My app has a progress dialog. I am calling dlg.Destroy() at the end of
the program when it is no longer required. On OS X it disappears and
the app exits. On MSW and GTK (linux), the dialog is not destroyed and
I have to press the OK button for it to disappear and the app to exit.
What would cause dlg.Destroy() not to destroy a dialog ??
Are there some extra parameters that need to be used on MSW and GTK ??
Actually, I'm calling dlg.Update() and it does not return.
All other calls to Update() return. The only difference to this call is
that the value is set to the maximum, so I guess that is what causing
Update() to wait.
Should Update() wait for the button to be pressed when the value is set
to the maximum ??
I assume the functionality should be the same on all platforms, yes ??
It seems OS X behaves differently, as Update() seems to return
immediately.
Attached is a small sample to demonstrate the problem.
Interestingly, if the 'style' keyword to the constructor is NOT passed,
then the dialog closes immediately when the maximum value is set, such
that the maximum value can NOT be seen. This is consistent on both MSW
and OSX. Is this expected ??
Yes. The default style is wx.PD_AUTO_HIDE | wx.PD_APP_MODAL.
The C++ docs say that if wx.PD_AUTO_HIDE is not given then the dialog becomes modal when the max is reached, so it sounds like Update is not supposed to return in that case until the dialog is closed manually. If that's the case then it sounds like the Mac version has a bug. You can create a ticket for this at trac.wxwidgets.org.
On a slightly different problem with ProgressDialog, if the initial
message is a multi-line message (e.g. 10 lines) then the width of the
dialog goes way off the screen. It looks like a simple string length is
being used to set the dialog box width. A better approach would be to
use string.split('\n') and determine the maximum string length of all
the lines.
You can also create a ticket for this one. If you are able to do it then you can attach a patch there too that changes this behavior and it will then be more likely to be done.
Actually, I'm calling dlg.Update() and it does not return.
All other calls to Update() return. The only difference to this
call is
that the value is set to the maximum, so I guess that is what causing
Update() to wait.
Should Update() wait for the button to be pressed when the value is set
to the maximum ??
I assume the functionality should be the same on all platforms, yes ??
It seems OS X behaves differently, as Update() seems to return
immediately.
Attached is a small sample to demonstrate the problem.
Interestingly, if the 'style' keyword to the constructor is NOT passed,
then the dialog closes immediately when the maximum value is set, such
that the maximum value can NOT be seen. This is consistent on both MSW
and OSX. Is this expected ??
Yes. The default style is wx.PD_AUTO_HIDE | wx.PD_APP_MODAL.
The C++ docs say that if wx.PD_AUTO_HIDE is not given then the dialog
becomes modal when the max is reached, so it sounds like Update is not
supposed to return in that case until the dialog is closed manually. If
that's the case then it sounds like the Mac version has a bug. You can
create a ticket for this at trac.wxwidgets.org.
Done. Ticket #12104.
Ticket #2895 is similar -- regarding the modal/non-modal issue.
On a slightly different problem with ProgressDialog, if the initial
message is a multi-line message (e.g. 10 lines) then the width of the
dialog goes way off the screen. It looks like a simple string length is
being used to set the dialog box width. A better approach would be to
use string.split('\n') and determine the maximum string length of all
the lines.
You can also create a ticket for this one. If you are able to do it
then you can attach a patch there too that changes this behavior and it
will then be more likely to be done.
Done. Ticket #12108.
I presume a patch would be a C++ patch ??
I'd prefer not to obtain the entire wxWidgets source code and set up the
build environment, etc. If I just obtained the PD C++ file and create
an untested patch, would that be acceptable ??
Does wxWidgets release sub-releases for wx-2.8 (e.g. wx-2.8.10.1,
wx-2.8.9.2 ) or this just a wxPython thing ??
Could I expect the PD fix in wx-2.9 backported to wx-2.8.11.1, followed
by a wxPython-2.8.11.1 release ??
I'd be happy to do the backport if a subsequent release of
wxpython-2.8.11 is to be scheduled.
The tentative roadmap suggests that wx-2.9.1 and wxPython-2.9.1 is
likely to be released "soonish". I'd be happy to wait for that too, but
I presume wx-2.9 comes with some risks, especially on OS X.
It might not be wise to incorporate in a commercial product that is
already released with wxPython-2.8 ??
Are odd numbers (e.g. 2.7, 2.9) considered "development" or "stable"
releases ??
Thanks, Brendan.
···
On 31/05/10 11:25 PM, Brendan Simon (eTRIX) wrote:
On 29/05/10 4:57 AM, Robin Dunn wrote:
On a slightly different problem with ProgressDialog, if the initial
message is a multi-line message (e.g. 10 lines) then the width of the
dialog goes way off the screen. It looks like a simple string length is
being used to set the dialog box width. A better approach would be to
use string.split('\n') and determine the maximum string length of all
the lines.
You can also create a ticket for this one. If you are able to do it
then you can attach a patch there too that changes this behavior and it
will then be more likely to be done.
Done. Ticket #12108.
I presume a patch would be a C++ patch ??
I'd prefer not to obtain the entire wxWidgets source code and set up the
build environment, etc. If I just obtained the PD C++ file and create
an untested patch, would that be acceptable ??
Maybe creating my own pure wxPython ProgressDialog would be easier ??
Would there be any interest from the wxPython community for a pure
wxPython version of ProgressDialog ??
Brendan.
···
On 1/06/10 9:57 PM, Brendan Simon (eTRIX) wrote:
On 31/05/10 11:25 PM, Brendan Simon (eTRIX) wrote:
On 29/05/10 4:57 AM, Robin Dunn wrote:
On a slightly different problem with ProgressDialog, if the initial
message is a multi-line message (e.g. 10 lines) then the width of the
dialog goes way off the screen. It looks like a simple string length is
being used to set the dialog box width. A better approach would be to
use string.split('\n') and determine the maximum string length of all
the lines.
You can also create a ticket for this one. If you are able to do it
then you can attach a patch there too that changes this behavior and it
will then be more likely to be done.
Done. Ticket #12108.
I presume a patch would be a C++ patch ??
I'd prefer not to obtain the entire wxWidgets source code and set up the
build environment, etc. If I just obtained the PD C++ file and create
an untested patch, would that be acceptable ??
Does wxWidgets release sub-releases for wx-2.8 (e.g. wx-2.8.10.1,
wx-2.8.9.2 ) or this just a wxPython thing ??
Could I expect the PD fix in wx-2.9 backported to wx-2.8.11.1, followed
by a wxPython-2.8.11.1 release ??
I'd be happy to do the backport if a subsequent release of
wxpython-2.8.11 is to be scheduled.
The tentative roadmap suggests that wx-2.9.1 and wxPython-2.9.1 is
likely to be released "soonish". I'd be happy to wait for that too, but
I presume wx-2.9 comes with some risks, especially on OS X.
It might not be wise to incorporate in a commercial product that is
already released with wxPython-2.8 ??
Are odd numbers (e.g. 2.7, 2.9) considered "development" or "stable"
releases ??
There already is one, and it’s included in wxPython since version 2.8.10.1 (as wx.lib.agw.pyprogress.PyProgress). I don’t know if it will solve your string width problem (I had the same problem with one of Andrea’s other generic dialogs), but if not, it should be relatively straightforward to patch it to use wx.lib.wordwrap. (I still think this should be the default behavior.)
On a slightly different problem with ProgressDialog, if the initial
message is a multi-line message (e.g. 10 lines) then the width of the
dialog goes way off the screen. It looks like a simple string length is
being used to set the dialog box width. A better approach would be to
use string.split('\n') and determine the maximum string length of all
the lines.
You can also create a ticket for this one. If you are able to do it
then you can attach a patch there too that changes this behavior and it
will then be more likely to be done.
Done. Ticket #12108.
I presume a patch would be a C++ patch ??
I'd prefer not to obtain the entire wxWidgets source code and set up the
build environment, etc. If I just obtained the PD C++ file and create
an untested patch, would that be acceptable ??
Does wxWidgets release sub-releases for wx-2.8 (e.g. wx-2.8.10.1,
wx-2.8.9.2 ) or this just a wxPython thing ??
Just wxPython.
Could I expect the PD fix in wx-2.9 backported to wx-2.8.11.1, followed
by a wxPython-2.8.11.1 release ??
I'd be happy to do the backport if a subsequent release of
wxpython-2.8.11 is to be scheduled.
As of now I'm not planning on spending much (if any) time on 2.8 so I can get 2.9 moving forward faster. That doesn't mean that it won't happen, it's just less likely based on current plans.
The tentative roadmap suggests that wx-2.9.1 and wxPython-2.9.1 is
likely to be released "soonish". I'd be happy to wait for that too, but
I presume wx-2.9 comes with some risks, especially on OS X.
It might not be wise to incorporate in a commercial product that is
already released with wxPython-2.8 ??
Are odd numbers (e.g. 2.7, 2.9) considered "development" or "stable"
releases ??