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

[Kevin A. <al...@se...>]

On Aug 26, 2005, at 7:09 AM, Alex Tweedly wrote:

>  Andy Todd wrote:You're not alone in your confusion though. I've been=20=

> mucking about with PythonCard since the project started and I made the=20=

> same mistake that you did with the resourceEditor.
>>
>>  I'm all in favour of swapping the behaviour of 'Move Forward'/'Bring=20=

>> to Front', 'Move Backward'/'Send to Back' in the resourceEditor.
>>
>>  In fact, if no one has any objections I can make it this weekend.=20
>> The most important part will, of course, be to update the=20
>> documentation.
>
>
>  I do have an objection - I think it's already correct. Utterly=20
> confusing - but I think correct.
>
>  Selecting a component and then menu Option / Bring to front does=20
> indeed bring it to the front when the app is run (etc.)
>
>  I *think* the confusion is caused by two problems:
>  =A0- the appearance in the resourceEditor is the unrelated to the=20
> appearance when you run the program
>  =A0- the order of components in the componentList field of the=20
> propertyEditor window is the reverse of what would feel natural to me.
>
>  I created 4 mutually overlapping buttons, then did
>  =A0=A0 - select a button
>  =A0=A0 - Options / Bring to front
>  =A0=A0 - File / Save
>  =A0=A0 - File / Run
>  selecting each button in turn - and the appearance on the running app=20=

> was what I expected. The z-order within the resource editor bore no=20
> relationship to the order when run, and the order in the component=20
> list was the reverse of what I find natural.

Um the display in the resourceEditor layout is just plain broken, it=20
isn't updating like it should. There is a method called=20
fixComponentOrder in resourceEditor.py that uses the wxPython method=20
Lower() to change the z-order. Unfortunately, both Raise and Lower are=20=

apparently only supported for managed windows (Frame and Dialog) now. I=20=

have no idea when that was changed in wxWidgets, but I'm assuming it=20
used to work for everything derived from the wxWindow base class or I=20
wouldn't have used it for so long. Anyway, unless there is some other=20
method for changing the window z-order the only option is to delete all=20=

the components and recreate them in the correct display order.

Sadly, that means all the components would have to be deleted and=20
recreated every time a new component is created as well since wxWidgets=20=

insists on the z-order following the order the components (controls)=20
are created on the panel, which is why a new component appears behind=20
everything else right now.

That is going to be slow on some machines, but might not be too bad if=20=

Freeze and Thaw are used. It is worth trying to ask on wx-users if=20
there is an alternative to Raise and Lower before adding the code to=20
handle the recreation of components.

>  However, the order in the component list matches the order in the=20
> resource file, and that matches the documentations text in=20
> general_concepts_and_limitations.html
>
>> Component tab traversal and order
>>
>> The component tab traversal order is determined by the order the=20
>> components are defined in the resource file. The first component=20
>> defined in the list is the first component tabbed to and it will=20
>> always be in front of the second, third, etc. components even if the=20=

>> components overlap. Look at any resource file and then observe the=20
>> behavior when you run the app. The resourceEditor is a good way to=20
>> experiment with how overlapping components look and behave.
>
>  So the first in the component window is the first in the resource=20
> file is the first to be tabbed to and is the front on when drawn.
>
>  Selecting a component, then selecting the menu Option / Bring to=20
> Front=A0=A0 will move the component to the top of the list, and the =
front=20
> of the final drawn window.
>
>  I naturally expect the order of components in the visible list to be=20=

> in "painter's order" - in fact it is the reverse of that.
>
>
>  btw - the only mention I can find in the docs of this is the one=20
> quoted above - the walkthroughs and the resource editor overview don't=20=

> mention it. When I revised the resource editor overview, I thought=20
> about adding a section on this topic (but chickened out because I find=20=

> it so confusing I was afraid I'd get it wrong).
>
>
> --=20
> Alex Tweedly       http://www.tweedly.net

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

ka