Thanks Mike,
I didn't know that page on the wiki. I arrived to the same solution but I'm
not satisfied with it.
First, for each dialog I need to write at least two functions, the first one
to open it and the second one to answer to the close action, and with many
dialogs as in my application it means to duplicate the functions, deal with
initialization and finalization of dialogs or data in two places and so on.
But the main reason is that I need to deal with standard dialogs in a
different way. And I still don't understand why standard dialogs behave
differently in Windows and how this is possible. In addition I found that on
Linux a standard dialog and a custom dialog both behave as expected: they
are modal for the application.
So at the moment my favourite option is to leave everything as it is: custom
dialogs modals to the application and standard dialogs modals to the frame
(only on Windows).
Thanks, Enrico
···
I think what you're looking for is Parent-Modal dialogs. Fortunately,
there's a recipe or two for just such a beast on the wiki:
Thanks Mike,
I didn't know that page on the wiki. I arrived to the same solution but I'm
not satisfied with it.
First, for each dialog I need to write at least two functions, the first one
to open it and the second one to answer to the close action, and with many
dialogs as in my application it means to duplicate the functions, deal with
initialization and finalization of dialogs or data in two places and so on.
But the main reason is that I need to deal with standard dialogs in a
different way. And I still don't understand why standard dialogs behave
differently in Windows and how this is possible. In addition I found that on
Linux a standard dialog and a custom dialog both behave as expected: they
are modal for the application.
So at the moment my favourite option is to leave everything as it is: custom
dialogs modals to the application and standard dialogs modals to the frame
(only on Windows).
Thanks, Enrico
I'm pretty sure Robin Dunn has mentioned this on the list several
times within the last month, but standard dialogs on Windows aren't
really "controlled" by wx. They're actually the real Windows dialogs
(for all intents and purposes), which is why wx has very little
control over them.
As for your other problem, you should be able to sub-class wx.Frame
and create various instances with it. Something like this:
Thanks Mike,
I didn't know that page on the wiki. I arrived to the same solution but I'm
not satisfied with it.
First, for each dialog I need to write at least two functions, the first one
to open it and the second one to answer to the close action, and with many
dialogs as in my application it means to duplicate the functions, deal with
initialization and finalization of dialogs or data in two places and so on.
But the main reason is that I need to deal with standard dialogs in a
different way. And I still don't understand why standard dialogs behave
differently in Windows and how this is possible.
Windows started off using application modal dialogs, but I believe in XP they changed it to be window modal. So whenever wx uses a native Win dialog, it is window modal, but when wx creates its own dialogs, it still uses the old app modal behavior.
In addition I found that on
Linux a standard dialog and a custom dialog both behave as expected: they
are modal for the application.
So at the moment my favourite option is to leave everything as it is: custom
dialogs modals to the application and standard dialogs modals to the frame
(only on Windows).
That's probably best for now. Hopefully in 3.0 there will be a way to do frame modal dialogs on all platforms. The inability to do this via wx API means we can't do sheets, which is a real shame.
Regards,
Kevin
···
On Dec 7, 2009, at 1:06 AM, ricercar@infinito.it wrote:
Thanks, Enrico
I think what you're looking for is Parent-Modal dialogs. Fortunately,
there's a recipe or two for just such a beast on the wiki:
