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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005

Oops, right. I meant Monday May 23.

Ste...@ao... wrote on 05/22/2005 07:46:20 AM:

> >$50 if it's fixed by Monday May 22! 
> >I can send via Paypal or check.
> 
> The last time May 22nd was a Monday was year 2000.
> 
> Time travel should be worth more than $50!
> 
> ;)
> 
> ---Tom Nally, New Orleans
Alex Tweedly wrote:
> bra...@om... wrote:
> 
>>
>> Any help on this would be greatly appreciated! I think it's a bug but 
>> I don't know
>> if its in wxPython or in PythonCard. I guess my next step is to try to 
>> do something
>> similar in wxPython. However, due to time constraints, I'm willing to put
>> out a bounty on fixing this bug, $50 if it's fixed by Monday May 22!
>> I can send via Paypal or check.
>>
> Here's a simple (perhaps too simple) wxPython prog that shows it works 
> OK on Win2000 and XP.
> Give it a try on the mac and if it fails there, you can send to wxPython 
> list ...
> 
> Good luck
> btw - I'm travelling for next day or two so may not be on email for a 
> couple of days ....)
> 
> 
> import  wx
> 
> #----------------------------------------------------------------------
> 
> class TestPanel(wx.Panel):
>     def __init__(self, parent, log):
>         wx.Panel.__init__(self, parent, -1)
>         self.log = log
>         self.count = 0
> 
>         self.lb = wx.StaticBox(self, -1, "This example uses the 
> wx.StaticBox.", (45, 100), (200,400))
>         self.btn = wx.Button(self, -1, "Test", (50,120))
>         wx.EVT_LEFT_DOWN(self.lb, self.on_box)
>         wx.EVT_LEFT_DOWN(self.btn, self.on_btn)
> 
> 
>     def on_box(self, event):
>         print "box"
>     def on_btn(self, event):
>         print "btn"
> #----------------------------------------------------------------------
> 
> if __name__ == '__main__':
>     import sys
>     app = wx.PySimpleApp()
>     frame = wx.Frame(None, -1, "title")
>     TestPanel(frame, sys.stdout)
>     frame.Show(True)
>     app.MainLoop()
> 
> -- 
> Alex Tweedly       http://www.tweedly.net
> 
>

Better late than never. I see the same problem with PythonCard from CVS, 
wxPython 2.5.3.1 and Python 2.3 on my iBook. I think the problem lies in 
the order that the widgets are created.

Your sample wx appliation works as expected. The on_btn method is 
executed if you click on the Button widget.

But if I swap the lines that create 'lb' and 'btn' in your example then 
the on_box method is executed when the mouse clicks anywhere inside the 
StaticBox and the on_btn method isn't.

So by observation I conclude that the static box in Brad's application 
is being created after the widgets within it. Does anyone fancy delving 
into model.py to see if this could be the cause of the problem?

Although I'm a little perturbed as to why this should be differ between 
the Mac and other platforms.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

This problem turned out to be a misunderstanding on my part (which I 
mentioned
in a different thread several weeks ago).

The problem was that I was always careful to send the StaticBox to the 
"back",
but that was the opposite of what I should have done. PythonCard uses the 
opposite
meanings of "back" and "front" compared with other GUI builders I've used.

In most GUI builders, "send to back" means push the widget into a layer
behind the other layers. However, in the PythonCard Resource Editor, it 
means put the widget last on the list of widgets, thus putting it in 
"front"
of every other widget.

My vote would be to switch around the terminology because I don't think
I'll be the only one confused by it...

Brad Allen
IT Desktop Support
Omnicom Management Services
Dallas, TX
http://www.omsdal.com

bra...@om... wrote:
> 
> This problem turned out to be a misunderstanding on my part (which I 
> mentioned
> in a different thread several weeks ago).
> 
> The problem was that I was always careful to send the StaticBox to the 
> "back",
> but that was the opposite of what I should have done. PythonCard uses 
> the opposite
> meanings of "back" and "front" compared with other GUI builders I've used.
> 
> In most GUI builders, "send to back" means push the widget into a layer
> behind the other layers. However, in the PythonCard Resource Editor, it
> means put the widget last on the list of widgets, thus putting it in 
> "front"
> of every other widget.
> 
> My vote would be to switch around the terminology because I don't think
> I'll be the only one confused by it...
> 
> Brad Allen
> IT Desktop Support
> Omnicom Management Services
> Dallas, TX
> http://www.omsdal.com

Yes, sorry about the delay, that's what happens when you neglect your 
email for a few weeks. I'm catching up now and random messages may start 
appearing on the mailing lists ;-)

You're not alone in your confusion though. I've been mucking about with 
PythonCard since the project started and I made the same mistake that 
you did with the resourceEditor.

I'm all in favour of swapping the behaviour of 'Move Forward'/'Bring to 
Front', 'Move Backward'/'Send to Back' in the resourceEditor.

In fact, if no one has any objections I can make it this weekend. The 
most important part will, of course, be to update the documentation.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

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

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

On Aug 26, 2005, at 12:20 PM, Kevin Altis wrote:

> 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.

     The convention I'm familiar with is that the top of an object  
list is the backmost. When a new object is added, it is typically  
added at the bottom of the object list, and to the front of the  
visual layout.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

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

Alex Tweedly wrote:
> Kevin Altis wrote:
> 
[snip]
> 
>> 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.
> 
> 
[snip]
> 

The point I was trying to make is that the current terminology used in 
the resourceEditor is wrong. When I bring a widget to the front I expect 
it to be on top of the other widgets when I run my application.

To the casual user this is the expected behaviour. The order of the 
widgets in the resource file or the way they are displayed in the 
property editor is, if not irrelevant, not nearly as important.

If I send my StaticBox to the back of my background in the 
resourceEditor then I expect the widgets in front of it to trap any 
events when the application is executed. Hence when I tried to replicate 
Brad's original problem I created a StaticBox (which I sent to the back) 
and then a Button (which I brought to the front) and was confused when 
the StaticBox intercepted all of the events in the running application.

The long and the short of it is that all we need to do is swap the 
method headers in resourceEditor.py as follows;

on_componentSendBack_command <-> on_componentBringFront_command
on_componentMoveBack_command <-> on_componentMoveForward_command

This trivial change will mean that the resource editor will work in the 
same way as any other GUI builder. This can only help the casual or new 
user.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005

Alex Tweedly wrote:
> Andy Todd wrote:
> 
>> The point I was trying to make is that the current terminology used in 
>> the resourceEditor is wrong. 
> 
> I disagree that the terminology is wrong.
> 
>> When I bring a widget to the front I expect it to be on top of the 
>> other widgets when I run my application.
>>
> That's what I currently observe happening.
> 
> If I bring a component "to the front" then (when the app is run) it 
> appears at the front (i.e. on top of other components). If I send it to 
> the back (and run the app) then it (dis)appears behind them.
> 
>> To the casual user this is the expected behaviour. The order of the 
>> widgets in the resource file or the way they are displayed in the 
>> property editor is, if not irrelevant, not nearly as important.
>>
> Forget the internals :
> 
> I created 4 overlapping buttons:
> I selected button1 and brought it to the front
> Then button2 and brought it to the front
> then button3
> then button4
> 
> then saved the file, and did File/Run
> 
> 4 in front
> 
> Then I selected button3 and brought it to the front, saved, and ran it.
> 
> 3 in front
> 
> then selected button2, brought it to the front, saved and ran that.
> 2 in front
> 
> 
> So, as I said, I see it as already behaving properly.
> 
>> If I send my StaticBox to the back of my background in the 
>> resourceEditor then I expect the widgets in front of it to trap any 
>> events when the application is executed. Hence when I tried to 
>> replicate Brad's original problem I created a StaticBox (which I sent 
>> to the back) and then a Button (which I brought to the front) and was 
>> confused when the StaticBox intercepted all of the events in the 
>> running application.
>>
> Unfortunately, on Win, the button produces events whether it's in front 
> or behind - so I can't reproduce this at all.
> Is the button inside the box ? Or overlapping the box border / text ?
> 
>> The long and the short of it is that all we need to do is swap the 
>> method headers in resourceEditor.py as follows;
>>
>> on_componentSendBack_command <-> on_componentBringFront_command
>> on_componentMoveBack_command <-> on_componentMoveForward_command
>>
>> This trivial change will mean that the resource editor will work in 
>> the same way as any other GUI builder. This can only help the casual 
>> or new user.
> 
> I think it's more complicated than that.
> Do you see the same overlapping with buttons as I see on Win ?   Or is 
> that also different ?
> 
> -- 
> Alex Tweedly       http://www.tweedly.net
> 

Fair enough, as Brad indicated in his original posting it's a Mac problem.

On the Mac you get the polar opposite of the behaviour you describe on 
Windows. Which is bad.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Andy Todd wrote:

>
> Fair enough, as Brad indicated in his original posting it's a Mac 
> problem.
>
> On the Mac you get the polar opposite of the behaviour you describe on 
> Windows. Which is bad.

I'm not sure whether it's a Mac-specific problem for static-boxes, or 
for all components.

The wxWidgets docs talk about controlling z-order by the order of 
component creation - so it would seem that the intent is for it to be 
controllable. I think I'll try to write a little wxPython program (i.e. 
no Pythoncard involved) to demonstrate the issue, and see if we can 
verify that the Mac and PC behave differently. (just in case it's a Mac 
vs PC difference within Python that is causing the controls to be 
created in a different order. I couldn't see anything in model.py that 
looked likely to do that, but then I suspect it won't be that obvious 
anyway.)

If I can get that done, I'll post it for others to try on Mac (and 
hopefully Unix too).
It's either that or I use this as the excuse I needed to buy that Mac 
Mini ...

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

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005

Alex Tweedly wrote:
> Andy Todd wrote:
> 
>> The point I was trying to make is that the current terminology used in 
>> the resourceEditor is wrong. 
> 
> I disagree that the terminology is wrong.
> 
>> When I bring a widget to the front I expect it to be on top of the 
>> other widgets when I run my application.
>>
> That's what I currently observe happening.
> 
> If I bring a component "to the front" then (when the app is run) it 
> appears at the front (i.e. on top of other components). If I send it to 
> the back (and run the app) then it (dis)appears behind them.
> 
>> To the casual user this is the expected behaviour. The order of the 
>> widgets in the resource file or the way they are displayed in the 
>> property editor is, if not irrelevant, not nearly as important.
>>
> Forget the internals :
> 
> I created 4 overlapping buttons:
> I selected button1 and brought it to the front
> Then button2 and brought it to the front
> then button3
> then button4
> 
> then saved the file, and did File/Run
> 
> 4 in front
> 
> Then I selected button3 and brought it to the front, saved, and ran it.
> 
> 3 in front
> 
> then selected button2, brought it to the front, saved and ran that.
> 2 in front
> 
> 
> So, as I said, I see it as already behaving properly.
> 
>> If I send my StaticBox to the back of my background in the 
>> resourceEditor then I expect the widgets in front of it to trap any 
>> events when the application is executed. Hence when I tried to 
>> replicate Brad's original problem I created a StaticBox (which I sent 
>> to the back) and then a Button (which I brought to the front) and was 
>> confused when the StaticBox intercepted all of the events in the 
>> running application.
>>
> Unfortunately, on Win, the button produces events whether it's in front 
> or behind - so I can't reproduce this at all.
> Is the button inside the box ? Or overlapping the box border / text ?
> 
>> The long and the short of it is that all we need to do is swap the 
>> method headers in resourceEditor.py as follows;
>>
>> on_componentSendBack_command <-> on_componentBringFront_command
>> on_componentMoveBack_command <-> on_componentMoveForward_command
>>
>> This trivial change will mean that the resource editor will work in 
>> the same way as any other GUI builder. This can only help the casual 
>> or new user.
> 
> I think it's more complicated than that.
> Do you see the same overlapping with buttons as I see on Win ?   Or is 
> that also different ?
> 
> -- 
> Alex Tweedly       http://www.tweedly.net
> 
> 

Just FYI, here's how your sample appears on Mac OSX 10.3 with Python 
2.3, wxPython 2.5.3.1 and PythonCard from CVS.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.16/83 - Release Date: 26/08/2005

On Aug 27, 2005, at 6:57 AM, Alex Tweedly wrote:

>  Andy Todd wrote:
>>  Just FYI, here's how your sample appears on Mac OSX 10.3 with Python 
>> 2.3, wxPython 2.5.3.1 and PythonCard from CVS.
>>
>
> <unknown.png>
>
>  Are the labels really outside the ovals in the original ?

Every version of wxWidgets/wxPython on the Mac has had different 
display issues and the button label problem mentioned is apparent even 
with version 2.6.1.0. If you use any height other than the default size 
for the button then the text will be centered vertically for the height 
of the button, but the button graphic itself will remain at the default 
height.

I don't remember what Stefan's explanation was for this particular 
problem, so I'll forward on the message to wxPython-mac and maybe 
create a wxWidgets bug report too.

ka

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

pythoncard-devel