How to grow a frame upwards?

Hi all,

I have an atypical question. I basically have a frame that gets resized. When it get resized (say I add a button that adds a spacer of size (0, 100), it will grow vertically downwards. It seems the frame is pinned at the top left side (in LTR) point.

Is there any way to change it to grow upwards (i.e. pin the bottom left point of the frame)?

Currently I’m calling SetPosition to move it up the amount it grows. Unfortunately this is not a very smooth solution.

Thanks much!

-R

If you mean the downwards and rightwards behavior when resizing the widget, I don’t think so.
I run into this one-way direction problem before.
You might ask Robin, but in all my trials and errors, It’s downward/rightward flows smoothly only.
Ex: Resizing a frame from a BLR statusbar gripper or frame grip action.

I think this type of fix is worth some corporate cash for someone who has figured it out.

You might want to look at how I hacked half way around it in blender.

Blender GUI will be worse, since It has it’s own GUI code(and I provide a workaround), but the same principle apply with wx.
And as of yet, no-one(AFAIK) has come up with a solution.

···

On Monday, January 13, 2014 12:31:04 AM UTC-6, Rish wrote:

Hi all,

I have an atypical question. I basically have a frame that gets resized. When it get resized (say I add a button that adds a spacer of size (0, 100), it will grow vertically downwards. It seems the frame is pinned at the top left side (in LTR) point.

Is there any way to change it to grow upwards (i.e. pin the bottom left point of the frame)?

Currently I’m calling SetPosition to move it up the amount it grows. Unfortunately this is not a very smooth solution.

Thanks much!

Thanks for the reply.

here is some sample code that exhibits the behavior I’m aiming for using SetPosition (taken from another example). Its very choppy and I’d love to find something better. Additionally with a lot of controls it flickers a bit.

Robin would you be able to suggest something better?

test-sizer.py (3 KB)

···

On Mon, Jan 13, 2014 at 12:36 AM, Metallicow metaliobovinus@gmail.com wrote:

On Monday, January 13, 2014 12:31:04 AM UTC-6, Rish wrote:

Hi all,

I have an atypical question. I basically have a frame that gets resized. When it get resized (say I add a button that adds a spacer of size (0, 100), it will grow vertically downwards. It seems the frame is pinned at the top left side (in LTR) point.

Is there any way to change it to grow upwards (i.e. pin the bottom left point of the frame)?

Currently I’m calling SetPosition to move it up the amount it grows. Unfortunately this is not a very smooth solution.

Thanks much!

If you mean the downwards and rightwards behavior when resizing the widget, I don’t think so.
I run into this one-way direction problem before.

You might ask Robin, but in all my trials and errors, It’s downward/rightward flows smoothly only.
Ex: Resizing a frame from a BLR statusbar gripper or frame grip action.

I think this type of fix is worth some corporate cash for someone who has figured it out.

You might want to look at how I hacked half way around it in blender.
https://github.com/Metallicow/wxBlender
Blender GUI will be worse, since It has it’s own GUI code(and I provide a workaround), but the same principle apply with wx.

And as of yet, no-one(AFAIK) has come up with a solution.

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.

Haha. The sample started near the top of the screen. Everytime I hit the button… yep same type of behaviour occurred.
Then it(the sample frame) past the maximum screen resolution and I had to kill it manually, because standard window controls with a mouse where no longer accessably

Yeah sorta, something on that line of thought.

Basically this is a deep rooted windowing system issue since computers first had GUI’s, best handled at the operating system level(and implemented as a world-wide half standand), not in user code.
Maybe one day when everyone has multiprocessing-multithreaded computers with more than one core and enough resources to handle it,
Then all we will have to do is reverse the whole screen drawing algorithm(turn it upside down) and process all that info but then send that info back and make it look as the user would see normally, or at least expect.
It comes down to drawing graphics on the screen basically.
Top Left. Bottom Right. Every action starts at a single point. Ex: (0, 0)
From this point forward, developers have to decide on a standard way to go…

…which if displayed graphically on a plot/graph is center. or crosshair or +

Hardware and software manufactures have tried to hack around this issue for years with the usually the same results.
The first real mouse was a 1 button wonder by apple. The monitor for this monster was a apple shaped tube. Go figurehaha. Things have improved and innovated a little bit since then, but not much.
Same old story. Graphics at point 0.

···

On Monday, January 13, 2014 2:39:43 PM UTC-6, Rish wrote:

here is some sample code that exhibits the behavior I’m aiming for using SetPosition (taken from another example). Its very choppy and I’d love to find something better. Additionally with a lot of controls it flickers a bit.

You can use
self.SetDoubleBuffered(True)
for most flickering problems with widgets.
I think wx.CLIP_CHILDREN style bit might help a bit on MSW.

···

On Monday, January 13, 2014 2:39:43 PM UTC-6, Rish wrote:

Additionally with a lot of controls it flickers a bit.

Thanks. I’m using that and it works great in the context of Refresh/Layout. Unfortunately not so great in terms of SetPosition.

···

On Mon, Jan 13, 2014 at 4:37 PM, Metallicow metaliobovinus@gmail.com wrote:

On Monday, January 13, 2014 2:39:43 PM UTC-6, Rish wrote:

Additionally with a lot of controls it flickers a bit.

You can use
self.SetDoubleBuffered(True)
for most flickering problems with widgets.
I think wx.CLIP_CHILDREN style bit might help a bit on MSW.

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.

Andrea worked some sort of slide in effect(similar to QT) with panes into AGW.AUI
It isn’t the greatest visually, but it is a start. I believe it might be attached to a timer or something, but sure right off hand.
You might want to look at that…
The AUI Manager style bit is AUI_MGR_SMOOTH_DOCKING

···

On Tuesday, January 14, 2014 2:59:17 PM UTC-6, Rish wrote:

Thanks. I’m using that and it works great in the context of Refresh/Layout. Unfortunately not so great in terms of SetPosition.