pythoncard-devel Mailing List for PythonCard (Page 7)

bra...@om... wrote:
> 
> While looking at the PythonCard source code, I noticed a couple of 
> "except:" statements
> lacking specific qualifiers. So I did a search of all the source code 
> and found that that's
> really the predominant practice in PythonCard.
> 
> I don't have much experience handling exceptions from wx, but even if we 
> have no
> idea what kind of exception we're getting back, we can at least trap for 
> the general
> Exception object, and maybe print something about it.
> 
> As in,
> 
> try:
> #something
> except Exception, thisErr:
> print 'Found an error here:', thisErr
> 
> 
> In cases where we know the specific error to expect, we could actually 
> trap for it.
> For instance, in model.py, the very first try block uses assertions to 
> make sure
> a minimum version of Python and wx are available. We could trap for 
> AssertionError.
> 
> *
> Brad Allen*
> IT Desktop Support
> _
> __b...@om..._ <mailto:bra...@om...>
Indeed, and I've made a start and checked in a number of changes today. 
If anybody else wants to join in I hereby declare September 'remove 
catch all exceptions' month.
The only point to add to Brad's is that I've found one instance (in 
sound.py) of an explicit 'raise' without a named exception. I added a 
custom exception (inheriting from the standard Exception class) and 
tested for it in the sample application code. If anyone spots any 
'raise' statements elsewhere in the code I recommend doing the same.
Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Just checked in a minor change which fixes a bug in the project save
routine which was cropping up under certain obscure circumstances using
SMB mounted filesystems under Linux. I've also added a button to the UI
which allows the main script file of the project to be opened in your
preferred text editor.
Still to do on this:
1. Menu bar items are completely out of synch with the main interface
2. Better error trapping in the build process
3. Add code to make it work with py2exe instead of/as well as McMillan
Installer.
-- 
Phil Edwards
Brighton, UK

Alex Tweedly wrote:
>
> 1. sizer design / geometry management
>
> Yes, you can add sizer code - but it's just so un-PythonCard-like. It 
> feels as bad as writing in wxPython :-)
>
> In fact, I think I want two kinds of geometry management:
> a. something very simple.
> In the resource editor, select an option that says "resizeable 
> components" and it just does it.
> Very simple assumptions (all textareas expand in both directions, all 
> textfields in X only, everything else is fixed size and just spreads 
> out ....) - BUT it does imply GetBestSize() on each component, so 
> should handle cross-platform issues for that subset of cases where it 
> works at all.
>
> Sometimes it will work, many times it won't - but if you're doing some 
> simple utility with a minimal GUI (2 or 3 preferences, a couple of 
> text input fields, a button or two plus one or two scrollable areas 
> for output), this could get it close enough.
I've written a simple sizer that (I think) does what I was thinking of. 
It's pretty simple-minded, but if you have a simple, straightforward 
layout, this will "work" most of the time. It's not always great - 
layouts can often look stretched, but it achieves the main purpose of 
making fields larger as the window size is increased. It should 
(untested) manage simple cross-platform issues (buttons should be larger 
on Mac, etc.) - though if that means they overlap, well, they just 
overlap. You can lay out the design with a bit of slop in Windows and it 
should be OK.
To try it out (please do)
1. the file (simpleSizer.py) is attached - put it in PythonCard directory
2. add from PythonCard import simpleSizer
3. in the background's on_initialize(), add a call 
 simpleSizer.autoSizer(self)
4. remember you may need to make the app resizeable in the resource editor.
I've tried it out on most of the Samples, as well as on findfiles 
(findfiles needed tweaking in the resourceEditor - the released version 
is not careful about the layout because the sizer code cleaned the 
layout up anyway. simpleSizer doesn't do that, so the layout needs to be 
correct in the resource file).
Let me know if it works for you, or if it doesn't tell me how it goes 
wrong..
Thanks,
-- 
Alex Tweedly http://www.tweedly.net

On Aug 31, 2005, at 1:49 PM, Kevin Altis wrote:
> I've posted a question to the wx-users mailing list via gmane on the 
> status of the Raise/Lower methods, so hopefully the post will go 
> through and get a reply this week. Without those methods or some sort 
> of substitute methods for changing z-order at runtime I don't see how 
> the display in the resourceEditor can accurately reflect the running 
> program z-order of components without recreating the components after 
> every change to z-order.
>
Well I got a quick reply from Vadim Zeitlin saying that wxWidgets 2.6.2 
supports z-order changes with Raise and Lower for all windows even if 
2.6.1 doesn't. I'm unable to verify this myself. I'm not inclined to 
create a workaround for this issue in the PythonCard resourceEditor, 
but would prefer to just wait for a 2.6.2 or a later release even if 
that won't be available until the end of this year.
ka

I don't know if everyone caught this post earlier this month about 
Robin's status, so here is the link and critical quote on when Robin 
might be working on wxPython again.
http://article.gmane.org/gmane.comp.python.wxpython/25159
"I had planned and hoped on being back at work a couple of weeks ago, 
but
unfortunately it looks like that won't happen until November or
December."
I haven't heard anything about people at OSAF or other developers on 
wxPython-dev doing major wxPython CVS updates or revving releases so I 
suspect that the current will 2.6.x release will have to do through the 
end of the year.
BTW, looking at the versions of wxPython I still had installed on my 
main Windows box I was able to determine that Raise/Lower was 
functional with version 2.5.1.5, but was gone by 2.5.2.7. I don't have 
every version of wxPython installed, so I'm not sure precisely which 
version was the first with the Raise/Lower nerf.
ka

I've posted a question to the wx-users mailing list via gmane on the 
status of the Raise/Lower methods, so hopefully the post will go 
through and get a reply this week. Without those methods or some sort 
of substitute methods for changing z-order at runtime I don't see how 
the display in the resourceEditor can accurately reflect the running 
program z-order of components without recreating the components after 
every change to z-order.
During the "major problem on Mac with StaticBox" thread there was also 
discussion about changing the property editor component list display so 
that the list would be reversed to how it has always appeared in past 
versions of the resourceEditor. I've looked over the code a bit, and 
there doesn't appear to be as much code as I originally expected that 
would have to be modified to support this change. The crucial item is 
that the order of the actual components (self.components) is not 
impacted and that we continue to create the resource file with the same 
order used today.
It sounded to me from the folks responding to the thread that other 
programs they are familiar with put the "frontmost" widget at the 
bottom of the list and the top of the list is the "back". Anyway, I'm 
not changing anything until I get a decent answer on the Raise/Lower 
methods, but if you want to chime in on the issue, reply to this 
message.
ka

Begin forwarded message:
> From: "Stefan Csomor" <cs...@ad...>
> Date: August 27, 2005 8:49:59 AM PDT
> To: wxP...@li...
> Subject: RE: [wxPython-mac] non-standard button height display problem
> Reply-To: wxP...@li...
>
> Hi
> =A0
> as I've mentioned before you cannot get a system pushbutton=A0drawn=A0in=
=20
> other sizes that the default normal, small and mini. I have to decide=20=
> at creation time whether I want to use another native button type=20
> (BevelButton) which can be rendered in different sizes. The only=20
> discriminator I have implemented now is the occurance of a newline in=20=
> the button title. But if we find another condition for this behaviour=20=
> I can add it
> =A0
> Best,
> =A0
> Stefan

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

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/

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

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/

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:
> 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/

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

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

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

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

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/

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

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/

I suspect that this email should perhaps be titled "Thoughts on 1.5" (or 
maybe even "...on 1.1) .... these changes may not be big enough to 
require, or justify, a change in major version number. So maybe these 
aren't being ambitious enough ....
(this email only lists 3 out of a long list I have waiting to be thought 
about and/or written up ...)
1. sizer design / geometry management
Yes, you can add sizer code - but it's just so un-PythonCard-like. It 
feels as bad as writing in wxPython :-)
In fact, I think I want two kinds of geometry management:
a. something very simple.
In the resource editor, select an option that says "resizeable 
components" and it just does it.
Very simple assumptions (all textareas expand in both directions, all 
textfields in X only, everything else is fixed size and just spreads out 
....) - BUT it does imply GetBestSize() on each component, so should 
handle cross-platform issues for that subset of cases where it works at all.
Sometimes it will work, many times it won't - but if you're doing some 
simple utility with a minimal GUI (2 or 3 preferences, a couple of text 
input fields, a button or two plus one or two scrollable areas for 
output), this could get it close enough.
b. complex.
Resource Editor allows definition of "pseudo-components" for sizers and 
spacers, multi-component selection to insert/remove components to 
hierarchical sizers - with maybe a treeCtrl view.
2. more types of windows / panels.
We can currently only do single panel windows, and notebooks. Would be 
good to be able to do say sash or splitter windows as well. Hopefully 
using some generalization so that you can write the panel code without 
pre-determining which of those types is to be used.
This should be extended to include the default single-panel window - so 
that you can start off writing a simple app, and then when it grows more 
complicated, other panels can simply be added without changing all the 
code done so far.
3. full undo/redo in resourceEditor
obvious.
-- 
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

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/77 - Release Date: 18/08/2005