Re: [Pythoncard-devel] Re: [Pythoncard-users] major problem on Mac with StaticBox

[Alex T. <al...@tw...>]

Kevin Altis wrote:

> Um the display in the resourceEditor layout is just plain broken, it 
> isn't updating like it should. There is a method called 
> fixComponentOrder in resourceEditor.py that uses the wxPython method 
> Lower() to change the z-order. Unfortunately, both Raise and Lower are 
> apparently only supported for managed windows (Frame and Dialog) now. 
> I have no idea when that was changed in wxWidgets, but I'm assuming it 
> used to work for everything derived from the wxWindow base class or I 
> wouldn't have used it for so long. Anyway, unless there is some other 
> method for changing the window z-order the only option is to delete 
> all the components and recreate them in the correct display order.
>
> Sadly, that means all the components would have to be deleted and 
> recreated every time a new component is created as well since 
> wxWidgets insists on the z-order following the order the components 
> (controls) are created on the panel, which is why a new component 
> appears behind everything else right now.
>
I don't see why that would need to be done - if we keep the current 
convention that a newly added component goes at the back, it would be 
unnecessary to delete & recreate them all just for adding a new 
component. We'd only need to do it when the user re-orders things - i.e. 
fairly rarely.

> That is going to be slow on some machines, but might not be too bad if 
> Freeze and Thaw are used. It is worth trying to ask on wx-users if 
> there is an alternative to Raise and Lower before adding the code to 
> handle the recreation of components.

Anyone want to ask ?   (if no one else does, I will - but it would be 
better if there is someone already on that list.....)

> As for reversing the list, it seems wrong to me that the top of the 
> list would be the "back" instead of the "front", but if other GUI 
> builders follow that convention we could consider switching it. It 
> isn't a trivial change unless you simply change which methods are 
> called by the Send to Back, Bring to Front, etc. menu items and leave 
> the list display as is.

I don't know that other GUI builders tie the z-order to the visible 
order of components in any list - but I've seen as number of them them 
use icons (image buttons) to control z-order - and those typically use 
pseudo-perspective arrows, with an arrow pointing "towards" you for 
"move towards front" and an arrow pointing "away" from the user being 
"move towards back". The "perspective" view is therefore an arrow 
pointing more or less downwards as "move towards front", and more or  
less upwards as towards the back - supporting the idea that top of list 
should be "back".

But I reckon we wouldn't need to change this if we can make the main 
window properly reflect the order. At most, we could add some labelling 
to indicate front and back - but I think it would be better to ignore 
the visible list order (which I think everyone would do if the display 
was reflecting the changes properly).

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.15/80 - Release Date: 23/08/2005