I recently updated my wxPython application from 2.8 to 2.9. The transition was largely smooth, but one stubborn issue continues to get the best of me. The app consists of two main Frames, only one of which should be active (visible) at a time. They should also have the same position, as if they were a single Frame - the point is to never see the inactive Frame hidden behind the active one. It’s also important to note that one Frame is the parent of the other.
To keep the Frames’ positions synced, I added an EVT_MOVE handler to each Frame. When the parent is moved, it sets the child’s position to match, and vice versa. This worked without issue in 2.8. However, at some point on the road to 2.9 (I’m actually running against 2.9.4.0), the handling of movement for parent/child Frames changed. In 2.8, moving a parent window doesn’t affect the child’s position. In 2.9, moving the parent moves the child as well. You can see this by running the attached SSCCE.
Now, the problem: Try dragging the child Frame running against 2.9. Behold, it and the parent Frame quickly fly off the screen! This is because moving the child calls its movement handler, which moves the parent, which then moves its child, calling the child’s movement handler and repeating the process ad infinitum.
Is there any way to stifle this tie between parent and child position in 2.9? I realize that the way I’m creating/associating Frames may be incorrect/nonstandard, it’s a vestige of my predecessor and has proven painful to change for a variety of reasons. Thus I’d like a workaround/fix for this issue that leaves the goofy Frame setup untouched if possible.
The sample code worked properly on my system using the move buttons and/or dragging either parent or child. The first move synchronizes the two and then they follow each other, regardless of whether I move the parent or child first or whether I used the buttons or dragging first.
Windows 7
Python version=2.7.5 final 0
wxPython version=2.9.5.0 msw (classic)
···
On 10/16/2013 9:41 PM, Brian G wrote:
I recently updated my wxPython application from 2.8 to 2.9. The transition was largely smooth, but one stubborn issue continues to get the best of me. The app consists of two main Frames, only one of which should be active (visible) at a time. They should also have the same position, as if they were a single Frame - the point is to never see the inactive Frame hidden behind the active one. It's also important to note that one Frame is the parent of the other.
To keep the Frames' positions synced, I added an EVT_MOVE handler to each Frame. When the parent is moved, it sets the child's position to match, and vice versa. This worked without issue in 2.8. However, at some point on the road to 2.9 (I'm actually running against 2.9.4.0), the handling of movement for parent/child Frames changed. In 2.8, moving a parent window doesn't affect the child's position. In 2.9, moving the parent moves the child as well. You can see this by running the attached SSCCE.
Now, the problem: Try dragging the child Frame running against 2.9. Behold, it and the parent Frame quickly fly off the screen! This is because moving the child calls its movement handler, which moves the parent, which then moves its child, calling the child's movement handler and repeating the process ad infinitum.
Is there any way to stifle this tie between parent and child position in 2.9? I realize that the way I'm creating/associating Frames may be incorrect/nonstandard, it's a vestige of my predecessor and has proven painful to change for a variety of reasons. Thus I'd like a workaround/fix for this issue that leaves the goofy Frame setup untouched if possible.
Any help/thoughts would be greatly appreciated!
--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I recently updated my wxPython application from 2.8 to 2.9. The
transition was largely smooth, but one stubborn issue continues to get
the best of me. The app consists of two main Frames, only one of which
should be active (visible) at a time. They should also have the same
position, as if they were a single Frame - the point is to never see the
inactive Frame hidden behind the active one. It's also important to note
that one Frame is the parent of the other.
To keep the Frames' positions synced, I added an EVT_MOVE handler to
each Frame. When the parent is moved, it sets the child's position to
match, and vice versa. This worked without issue in 2.8. However, at
some point on the road to 2.9 (I'm actually running against 2.9.4.0),
the handling of movement for parent/child Frames changed. In 2.8, moving
a parent window doesn't affect the child's position. In 2.9, moving the
parent moves the child as well. You can see this by running the attached
SSCCE.
Now, the problem: Try dragging the child Frame running against 2.9.
Behold, it and the parent Frame quickly fly off the screen! This is
because moving the child calls its movement handler, which moves the
parent, which then moves its child, calling the child's movement handler
and repeating the process ad infinitum.
Is there any way to stifle this tie between parent and child position in
2.9? I realize that the way I'm creating/associating Frames may be
incorrect/nonstandard, it's a vestige of my predecessor and has proven
painful to change for a variety of reasons. Thus I'd like a
workaround/fix for this issue that leaves the goofy Frame setup
untouched if possible.
You don't mention platform so I'm guessing that you're on OSX. I also noticed this issue back when the changes were first made and I thought it was weird too so I asked about it. The answer is that this is the proper behavior for native parent/child windows on OSX and that many considered it a bug that it didn't behave as if the child is tied to the parent. The recommended workaround is to not have one frame be the child of the other.
That’s correct, Robin. I thought I’d seen this behavior on Windows so didn’t specify an OS, but I was clearly mistaken. Looks like I’ll have to tackle the Frame parentage issue to solve this, thanks for the help.
···
On Monday, October 21, 2013 6:47:46 PM UTC-5, Robin Dunn wrote:
Brian G wrote:
I recently updated my wxPython application from 2.8 to 2.9. The
transition was largely smooth, but one stubborn issue continues to get
the best of me. The app consists of two main Frames, only one of which
should be active (visible) at a time. They should also have the same
position, as if they were a single Frame - the point is to never see the
inactive Frame hidden behind the active one. It’s also important to note
that one Frame is the parent of the other.
To keep the Frames’ positions synced, I added an EVT_MOVE handler to
each Frame. When the parent is moved, it sets the child’s position to
match, and vice versa. This worked without issue in 2.8. However, at
some point on the road to 2.9 (I’m actually running against 2.9.4.0),
the handling of movement for parent/child Frames changed. In 2.8, moving
a parent window doesn’t affect the child’s position. In 2.9, moving the
parent moves the child as well. You can see this by running the attached
SSCCE.
Now, the problem: Try dragging the child Frame running against 2.9.
Behold, it and the parent Frame quickly fly off the screen! This is
because moving the child calls its movement handler, which moves the
parent, which then moves its child, calling the child’s movement handler
and repeating the process ad infinitum.
Is there any way to stifle this tie between parent and child position in
2.9? I realize that the way I’m creating/associating Frames may be
incorrect/nonstandard, it’s a vestige of my predecessor and has proven
painful to change for a variety of reasons. Thus I’d like a
workaround/fix for this issue that leaves the goofy Frame setup
untouched if possible.
You don’t mention platform so I’m guessing that you’re on OSX. I also
noticed this issue back when the changes were first made and I thought
it was weird too so I asked about it. The answer is that this is the
proper behavior for native parent/child windows on OSX and that many
considered it a bug that it didn’t behave as if the child is tied to the
parent. The recommended workaround is to not have one frame be the
child of the other.