pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] Latest pythoncard release dependencies

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

On Apr 14, 2004, at 5:23 AM, Stephen Boulet wrote:

> I'm trying to get the latest pythoncard release build script 
> up-to-date for
> Gentoo, but I'm a bit unsure about the wxPython dependencies.
>
> Do I need to update wxPython to 2.5.1.5 for pythoncard? And in order to
> upgrade wxPython to 2.5.1.5, do I first need to upgrade wxGTK to 
> something
> greater than 2.4.2?
>
> Thanks! It will be good to get everything updated on Gentoo.
>
No, you don't need to upgrade. 0.7.3.1 is supposed to work with 
wxPython 2.4.x as well as 2.5.1.5. I recommend wxPython 2.4.2.4 since 
that is stable, unless you're on Mac OS X, in which case 2.5.1.5 is 
better. Python 2.2.1 or higher is required as well.

When we get to release 0.8, or if you want to use the PythonCard branch 
in cvs you will need Python 2.3 or higher and wxPython 2.5.1.5 or 
higher. Release 0.8 won't be ready until probably early May.

ka

[Pythoncard-users] SQLDict

[ralph h. <1st...@1I...>]

Has anyone used SQLDict module with MYSql/PythonCard?

I am looking for an easy to use interface for SQL Interface.

_____________________________________________________________
 
 
 
=======================================
    www.StrictlyEmail.com ...our name says it all!

[Pythoncard-users] Latest pythoncard release dependencies

[Stephen B. <st...@th...>]

I'm trying to get the latest pythoncard release build script up-to-date for 
Gentoo, but I'm a bit unsure about the wxPython dependencies.

Do I need to update wxPython to 2.5.1.5 for pythoncard? And in order to 
upgrade wxPython to 2.5.1.5, do I first need to upgrade wxGTK to something 
greater than 2.4.2?

Thanks! It will be good to get everything updated on Gentoo.

-- 
Stephen      
              From here to there
             and there to here,
           funny things are everywhere.  -- Dr Seuss

[Pythoncard-users] Developing an app in PythonCard/MYSql

[ralph h. <1st...@1I...>]

I have created the rsrc file through PythonCard for a maintenance app.  I have some questions that I would like to leverage others experience on while writing the MYSql interface.

1.  What are methods to implement record operations:
     1. Delete Record
     2. Next Record  (select where key>=self.LastName.Text)
     3. Prev Record
     4. Update Record
     5. New Record

2.  How do I make the fields in each TextField UPPERCASE?

Thanks for any input.

_____________________________________________________________
 
 
 
=======================================
    www.StrictlyEmail.com ...our name says it all!

[Pythoncard-users] first batch of 0.8 changes are in cvs

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

Rowland and I burned through the first batch of release 0.8 changes 
today and the changes have been checked into cvs (PythonCard branch, 
not PythonCardPrototype). All wxPython related imports were changed to 
the wx package instead, minimum requirements are Python 2.3 and 
wxPython 2.5.1.5. We'll probably continue to make a bunch of changes 
this week. See the wiki page and changelog.txt file if you're wanting 
to keep up with changes to cvs.

http://wiki.wxpython.org/index.cgi/PythonCard08

Rowland and I have been using AIM to collaborate, but if you think you 
might want to do some coding or follow along we could potentially use 
irc instead, say a #pythoncard channel on irc.freenode.net. If you're 
interested, just email me directly. I'll continue to post progress here 
as major changes are checked in.

ka

[Pythoncard-users] ANN: PythonCard 0.7.3.1 RPMs

[Phil E. <ph...@li...>]

These are now available for download from:

http://www.linux2000.com/pythoncard.html

The installation documents and the download page on sourceforge will be 
updated shortly to reflect the new additions.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] PythonCard release 0.7.3.1 is now available

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

Since this is just a quick bug-fix release I'll just list the changes  
since last week and a link to the previous release announcement.

Release 0.7.3.1 2004-04-09
added _getId back to widget.py
menu.py workaround for FindMenuItem and GTK exception
updated MANIFEST.in and setup.py for PyPI/distutils
added testevents sample for debugging cross-platform
   event order

Release 0.7.3 announcement...

http://sourceforge.net/mailarchive/forum.php? 
thread_id=4181777&forum_id=740

ka

[Pythoncard-users] framework overview and component docs

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

I've reorganized the main documentation page.

http://pythoncard.sourceforge.net/documentation.html

The main reason I revised the page was to provide links to the 
Framework Overview documents. After rereading the old State of the 
Framework messages I decided these were worth having as an overview to 
the PythonCard framework, so I converted them to HTML and did some 
minor updates. The Components document links to a sub-directory of 
auto-generated documentation for most of the components; the output is 
generated by the widgets sample. Due to the way each image is grabbed 
from the sample, some images need to be replaced, I'll do that sometime 
next week.

The framework overview and component docs will be expanded and updated 
more regularly as we approach release 1.0. Comments and corrections are 
appreciated.

We still need a documentation manager for PythonCard to help write, 
edit, and organize documentation and help us standardize on tools for 
documenting PythonCard for release 1.0.

ka
p.s. The "easter bunny" says hi :) http://www.semi-retired.com/bunny/

Re: [Pythoncard-users] 0.7.3.1 release planned for Monday

[Phil E. <ph...@li...>]

On Thursday 08 Apr 2004 8:38 pm, Kevin Altis wrote:
>
> The current 0.7.3 release should be fine for everyone except Linux/GTK
> users running wxPython 2.5.1.5. Obviously we don't want to have a
> 0.7.3.2 release, so if you find any other critical problems, please
> report them ASAP.
>

I have one remaining problem with wxPython 2.5.1.5, but it's not down to 
PythonCard and I don't think 0.7.3.1 needs to be held up, but see what you 
think:

Using transparent PNG images on wx.wxBitmapButton controls seems to be broken 
compared to 2.4.2.4, specifically, the transparency part no longer works. 
What you end up with is your graphic on a black background overlaid on top of 
the button. The fault is present with both the GTK and GTK2 ports of wxPython 
on Linux. The problem is reproducible by amending the image file used in 
'demo/BitmapButton.py' from the wxPython 2.5 demo distributon to use any 
transparent PNG you happen to have on your machine.

I'll check the wxPython mailing lists and see if anyone else has reported 
this. 

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] release 0.8 and beyond minimum requirement issues

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

So far the opinion is jump to Python 2.3 and wxPython 2.5 - 2.6. I'll 
give people until Monday morning for any additional input against 
making the move, then Rowland and I are going to start making changes 
for Python 2.3 and wxPython 2.5.1.5.

ka

[Pythoncard-users] release 0.8 issues and to do list wiki page

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

http://wiki.wxpython.org/index.cgi/PythonCard08

This is extremely "raw" right now. Rowland and I needed some way of 
collaborating on possible issues and to do items as we think of them. 
We decided to do it as a wiki page to simplify other people adding 
their input.

The page isn't very pretty, there is little discussion text for each 
item so far and many items simply won't make any sense for 0.8 to 1.0, 
but it is better to get all the possibilities down.

Contributions welcome!

ka

Re: [Pythoncard-users] release 0.8 and beyond minimum requirement issues

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

On Apr 8, 2004, at 3:52 PM, Stephen C. Waterbury wrote:

> One thing I'm thinking of is a real-time collaborative
> spreadsheet-like thingy that uses Twisted's Perspective Broker.
> I don't know how familiar you are with Twisted, but there is a cool
> example of that concept.  It uses wxPython but I think it could
> easily be ported to PythonCard as the GUI features are *really*
> simple.  The example was developed by Axel Busch when he was
> learning Twisted.  I could send it to the list if you are
> interested -- if we ported it to PythonCard, I think it would
> make a killer example of using PythonCard with Twisted.
>
Yes please, we need to have a Twisted sample and I keep putting off 
figuring out what the initialization steps are, whether you have to 
have twisted or wxPython as the primary thread, etc. If I see the basic 
strategy I'm sure we could do a number of samples.

ka

[Pythoncard-users] PythonCard cvs tree is active

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

http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/

Anonymous cvs is at least a few hours behind developer cvs access, but 
you can now keep up with what will become release 0.8 and eventually 
1.0 without impacting your PythonCardPrototype package. Rowland has 
already done a global replace of PythonCardPrototype to PythonCard in 
the *.py, .txt, and *.html files. We will be checking in a file 
tomorrow to track planned changes, our progress, in addition to noting 
changes in the changelog.txt file. Relevant changes will also be 
brought up on the list.

If you aren't already a developer on the PythonCard project, but have 
been wanting to contribute, please let us know. This is pretty 
exciting, finally heading to version 1.0.

Thanks,

ka

Re: [Pythoncard-users] release 0.8 and beyond minimum requirement issues

[Stephen C. W. <go...@co...>]

Kevin Altis wrote:
> Can you elaborate on the kinds of things you would port from wxPython to 
> PythonCard? I'm curious since in general someone that is already 
> comfortable with the wxPython APIs wouldn't see much value in PythonCard 
> and its simplified and more limited approach.

Good observation.  We probably wouldn't port *everything* to
PythonCard, but some of the simpler things that could serve
as extensible template-like modules for "enterprise developers"
who may not be familiar with wxPython (more likely VB, Cold Fusion,
etc.) to customize and/or extend.

Some of our wxPython app probably *would* be difficult to
implement in PythonCard, so we'll most likely continue to have
a "heavy" GUI that is all wxPython, with possibly some
customizability for programmers who are comfy with
wxPython.

> Also, I would be 
> interested to hear the types of things you want to build or your 
> expected user base for PythonCard since that could help shape the 
> changes as we move to 1.0 status.

They would probably be simple things with tabular widgets
and relatively simple event-driven "live" status displays.

One thing I'm thinking of is a real-time collaborative
spreadsheet-like thingy that uses Twisted's Perspective Broker.
I don't know how familiar you are with Twisted, but there is a cool
example of that concept.  It uses wxPython but I think it could
easily be ported to PythonCard as the GUI features are *really*
simple.  The example was developed by Axel Busch when he was
learning Twisted.  I could send it to the list if you are
interested -- if we ported it to PythonCard, I think it would
make a killer example of using PythonCard with Twisted.

> I'm emailing you privately in case you 
> don't want to make the info public on the list.

Thanks -- very considerate!  But it's no problem.  All our
stuff is destined to be OS, even though at this point we're
still in "cathedral mode".  ;)

Cheers,
Steve

Re: [Pythoncard-users] release 0.8 and beyond minimum requirement issues

[Andy T. <an...@ha...>]

Kevin Altis wrote:
> Rowland and I are both chomping at the bit to start the cleanup and 
> major changes for release 0.8. I've requested that SourceForge copy the 
> existing PythonCardPrototype tree to a new tree called PythonCard. At 
> the earliest, 0.8 won't be ready to go until May.
> 
> The main issue that I need feedback on now is the decision to drop 
> support for wxPython 2.4.x. In order to support new style classes and 
> cleanup the code we really need to move away from wxPython 2.4.x. Thus, 
> I don't see keeping 2.4.x compatibility as a realistic option. But this 
> move isn't without some pain, so here's what it means.
> 
> We are shooting for PythonCard 1.x working with wxPython 2.6, the next 
> stable API release of wxWidgets/wxPython. The wxPython 2.5.x API won't 
> stabilize completely until 2.6 is released, which is this summer at the 
> earliest, and could be toward the end of the year. If and when the 2.5.x 
> API changes, each version of PythonCard will have to track those changes 
> and the minimum version requirement may change until we get to wxPython 
> 2.6.x. For example, PythonCard release 0.8 may require wxPython 2.5.1.5 
> as a minimum and release 0.8.1 or 0.9 might require wxPython 2.5.2.1, etc.
> 
> If you've built a standalone or want to stick with an older version of 
> PythonCard for a while you won't be impacted until you want to support 
> the latest version.
> 
> I won't be using or testing wxPython 2.4.x at all once we start the 
> changes, so if you have an objection or issue with this decision that 
> you want to raise, the time to do so is now.
> 
> A less important decision is whether to require Python 2.3.x or higher. 
> Are most Linux releases still using Python 2.2.x? If so, will it be a 
> pain to require Python 2.3.x for PythonCard? So far, I can think of few 
> reasons why we have to have 2.3, but I no longer run Python 2.2.x myself 
> on any of my machines, so unless someone else is going to step up and do 
> extensive testing for Python 2.2.1, 2.2.2, 2.2.3, etc. I'm inclined to 
> stop supporting it.
> 
> ka
> 

My vote is for Python 2.3 as it is standard on my operating systems 
(Debian and OSX).

wxPython 2.5 hasn't made it into Debian yet, but I expect it will be 
available soon (at least in unstable). So lets go for that as well.

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

Re: [Pythoncard-users] release 0.8 and beyond minimum requirement issues

[Kenneth P. <pro...@sk...>]

On Thu, Apr 08, 2004 at 01:22:03PM -0700, Kevin Altis wrote:
> We are shooting for PythonCard 1.x working with wxPython 2.6, the next 
> stable API release of wxWidgets/wxPython. The wxPython 2.5.x API won't 
> stabilize completely until 2.6 is released, which is this summer at the 
> earliest, and could be toward the end of the year. If and when the 
> 2.5.x API changes, each version of PythonCard will have to track those 
> changes and the minimum version requirement may change until we get to 
> wxPython 2.6.x. For example, PythonCard release 0.8 may require 
> wxPython 2.5.1.5 as a minimum and release 0.8.1 or 0.9 might require 
> wxPython 2.5.2.1, etc.

For Debian, I may have a hard time tracking individual releases of
wxPython, since I don't maintain that package.  We'll have to see.

For the time being, the wxPython 2.5 packages are only in Debian's
'experimental' distribution.  This is not a mainline distribution, i.e.
packages from 'experimental' do not get automatically propogated to
'testing'.

This means that whenever you start requiring 2.5, I'll need to release
my PythonCard packages to the 'experimental' distribution instead of
'unstable', until 2.5 itself moves into 'unstable'.  

> A less important decision is whether to require Python 2.3.x or higher. 

Python 2.3 is the standard Python in Debian 'sarge', which will be the
next stable release.   I do not (and will not) support any backports to
earlier Debian releases, so from my perspective, it would be OK to
require Python 2.3.

KEN

-- 
Kenneth J. Pronovici <pro...@sk...>
Personal Homepage: http://www.skyjammer.com/~pronovic/
"They that can give up essential liberty to obtain a little 
 temporary safety deserve neither liberty nor safety." 
      - Benjamin Franklin, Historical Review of Pennsylvania, 1759 

Re: [Pythoncard-users] release 0.8 and beyond minimum requirement issues

[Stephen C. W. <go...@co...>]

Kevin Altis wrote:

> The main issue that I need feedback on now is the decision to drop 
> support for wxPython 2.4.x. ...
> 
> We are shooting for PythonCard 1.x working with wxPython 2.6, the next 
> stable API release of wxWidgets/wxPython. The wxPython 2.5.x API won't 
> stabilize completely until 2.6 is released [so the] 2.5.x 
> ... version[s] of PythonCard will have to track those changes 
> ... until we get to wxPython 
> 2.6.x. ...

That makes sense to me.  (We don't have a released PythonCard app
yet, but that strategy would definitely make me more disposed to
move some things we have developed in wxPython to PythonCard.
At any rate, we will wait to begin using PythonCard until it starts
tracking wxPython 2.5.x or later.  :)

> A less important decision is whether to require Python 2.3.x or higher. 
> .... I'm inclined to
> stop supporting it.

Not a problem for us -- we moved all our apps to 2.3.x almost immediately.

Cheers,
Steve

[Pythoncard-users] release 0.8 and beyond minimum requirement issues

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

Rowland and I are both chomping at the bit to start the cleanup and 
major changes for release 0.8. I've requested that SourceForge copy the 
existing PythonCardPrototype tree to a new tree called PythonCard. At 
the earliest, 0.8 won't be ready to go until May.

The main issue that I need feedback on now is the decision to drop 
support for wxPython 2.4.x. In order to support new style classes and 
cleanup the code we really need to move away from wxPython 2.4.x. Thus, 
I don't see keeping 2.4.x compatibility as a realistic option. But this 
move isn't without some pain, so here's what it means.

We are shooting for PythonCard 1.x working with wxPython 2.6, the next 
stable API release of wxWidgets/wxPython. The wxPython 2.5.x API won't 
stabilize completely until 2.6 is released, which is this summer at the 
earliest, and could be toward the end of the year. If and when the 
2.5.x API changes, each version of PythonCard will have to track those 
changes and the minimum version requirement may change until we get to 
wxPython 2.6.x. For example, PythonCard release 0.8 may require 
wxPython 2.5.1.5 as a minimum and release 0.8.1 or 0.9 might require 
wxPython 2.5.2.1, etc.

If you've built a standalone or want to stick with an older version of 
PythonCard for a while you won't be impacted until you want to support 
the latest version.

I won't be using or testing wxPython 2.4.x at all once we start the 
changes, so if you have an objection or issue with this decision that 
you want to raise, the time to do so is now.

A less important decision is whether to require Python 2.3.x or higher. 
Are most Linux releases still using Python 2.2.x? If so, will it be a 
pain to require Python 2.3.x for PythonCard? So far, I can think of few 
reasons why we have to have 2.3, but I no longer run Python 2.2.x 
myself on any of my machines, so unless someone else is going to step 
up and do extensive testing for Python 2.2.1, 2.2.2, 2.2.3, etc. I'm 
inclined to stop supporting it.

ka

[Pythoncard-users] 0.7.3.1 release planned for Monday

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

I checked in a fix for menu.py yesterday so what's in cvs should work 
on all platforms with wxPython 2.4.2.4 and wxPython 2.5.1.5. I just 
checked in a change to model.py that delays the event bindings for 
background events so openBackground should occur before move, size, and 
idle on GTK regardless of whether debug runtime windows are used or 
not; that change should show up in anonymous cvs later today. As part 
of that fix I moved the Debug menu initialization to the Background 
_createMenus method. Initial tests don't show any problems. However, I 
would like to give everyone with cvs access a chance to check these 
changes before making the 0.7.3.1 release, so that release won't happen 
until Monday.

The current 0.7.3 release should be fine for everyone except Linux/GTK 
users running wxPython 2.5.1.5. Obviously we don't want to have a 
0.7.3.2 release, so if you find any other critical problems, please 
report them ASAP.

ka

Re: [Pythoncard-users] clearing up outstanding bugs on SF

[Phil E. <ph...@li...>]

On Thursday 08 Apr 2004 3:11 am, Kevin Altis wrote:
> If you have submitted one of the bugs that is still outstanding at
>
> http://sourceforge.net/tracker/?atid=119015&group_id=19015&func=browse
>
> I need your help to squash them. Of course, even if you didn't submit

Bug 818681 can be closed. I can't close it from here for some reason.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] clearing up outstanding bugs on SF

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

If you have submitted one of the bugs that is still outstanding at

http://sourceforge.net/tracker/?atid=119015&group_id=19015&func=browse

I need your help to squash them. Of course, even if you didn't submit 
the original report, if you can confirm that the bug is still a problem 
with 0.7.3 and with which OS, version of wxPython, etc. it will be 
helpful. Some of these were submitted last fall when I wasn't coding 
and others I'm not sure are really bugs or I can't test them myself 
(e.g. Linux, all distributions). In the case of a Linux problem, I'll 
need someone else to help code up a fix.

Just go ahead and add additional comments to the individual bug reports 
or bring up the issue on the mailing list if you think it requires 
discussion or input from other people.

Thanks,

ka

Re: [Pythoncard-users] life.py bug and fix

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

On Apr 5, 2004, at 3:34 PM, Kevin Altis wrote:
>
> =00In addition, Rowland Smith has found that on Linux with wxPython=20
> 2.4.2.4 the size event is not firing before the idle event. That's=20
> actually a wxPython bug as far as I'm concerned (Windows and Mac OS X=20=

> don't have this problem), but I don't know yet whether this bug exists=20=

> in wxPython 2.5.1.5 on Linux. The fix is to add
>
>         self.resizing =3D 0
>
> to the beginning of the on_openBackground handler.
>
> Since nobody on Linux has ever reported this problem before I'll just=20=

> assume that people running Linux never tried the sample or had low=20
> expectations <wink>
>
This has turned out to be a deeper problem than I expected. Due to the=20=

way initialization is done on GTK, the event message order with=20
PythonCard is different depending on whether you use the runtime tools=20=

or not when you start a sample or tool. What ends up happening is=20
'size' and 'idle' messages are sent before openBackground which defeats=20=

the whole purpose of openBackground as an initialization method.

I spent all of yesterday investigating this with Rowland and we have=20
some tests so that now I think we understand what is going on and might=20=

have a different way of doing openBackground.

We also found that on all platforms we are seeing a gainFocus message=20
for the first item on a Background, so that is a long-standing bug, but=20=

probably not critical because it isn't used much or at least not in a=20
case where it relies on prior initialization. The problem with=20
openBackground on GTK is more serious, so I hope to figure something=20
out for 0.7.3.1.

ka

Re: [Pythoncard-users] Problem with 0.7.3, wx 2.5, python 2.2.2

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

Sadly, the problem was related but much more critical and we definitely  
have to do a 0.7.3.1 release for Linux/GTK. I have checked in a  
potential fix for menu.py. Rowland has checked it with 2.4.2.4 and  
2.5.1.5 and we think it works. I haven't seen problems with Windows or  
Mac either, but I want to do more testing.

Anyway, the problem is that FindMenuItem on GTK doesn't actually strip  
the tab and characters after the tab in a menu item label string so  
something like "E&xit\tAlt+x" will never get a match on GTK, so it  
always returns an id of -1. My menu.py code was faulty for not checking  
for a -1 return value from FindMenuItem. In wxPython 2.4.x you could  
pass an id of -1 to Enable, Check, etc. and the methods would just fail  
silently, but since I wasn't running GTK I never thought to check this.  
In 2.5.1.5 they throw an assert when you pass invalid ids like -1 which  
is the error Phil reported. Basically, the menu code for enabling and  
checking menu items has always been broken on GTK when the menu item  
labels contained a \t... for defining a key equivalent like Alt+X,  
Ctrl+C, etc.

So, I've brought this up on wxPython-dev and I think I've fixed the  
problem in cvs, but we need to do more testing to make sure the code  
works correctly on all platforms with both 2.4.2.4 and 2.5.1.5 before  
doing a 0.7.3.1 release.

There is an unrelated complication in that it appears the  
resourceEditor dragging and resizing code isn't working correctly with  
wxPython 2.5.1.5 on GTK either. More on this later.

ka
On Apr 7, 2004, at 11:02 AM, Kevin Altis wrote:

> On Apr 7, 2004, at 10:30 AM, Kevin Altis wrote:
>
>> So, to verify this, simply comment out the lines menuLabel =  
>> m.label.strip('&') and see if the problem goes away. If that's it  
>> (FindMenuItem) then I'll have to do a workaround and do a 0.7.3.1  
>> release.
>>
> Oops, that should have been, replace
>
> menuLabel = m.label.strip('&')
>
> with
>
> menuLabel = m.label
>
> The diff in cvs...
>
> http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCardPrototype/ 
> menu.py?r1=text&tr1=1.22&r2=text&tr2=1.24&diff_format=h
>
> ka

Re: [Pythoncard-users] Problem with 0.7.3, wx 2.5, python 2.2.2

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

On Apr 7, 2004, at 10:30 AM, Kevin Altis wrote:

> So, to verify this, simply comment out the lines menuLabel =  
> m.label.strip('&') and see if the problem goes away. If that's it  
> (FindMenuItem) then I'll have to do a workaround and do a 0.7.3.1  
> release.
>
Oops, that should have been, replace

menuLabel = m.label.strip('&')

with

menuLabel = m.label

The diff in cvs...

http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCardPrototype/ 
menu.py?r1=text&tr1=1.22&r2=text&tr2=1.24&diff_format=h

ka

Re: [Pythoncard-users] Problem with 0.7.3, wx 2.5, python 2.2.2

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

Son of a...

I'm pretty sure I know what is going on. On the Mac I found that the =20
'&' in the menu label was causing FindMenuItem to fail. Here's the =20
explanation I sent Robin, Stefan, etc.

"""
Well as usual my earlier assumption was wrong about where the bug was =20=

which a sample cleared up. It isn't the reference to the menubar that =20=

is the problem it is wxMenuBar::FindMenuItem method. As far as I can =20
tell, unless you remove the ampersand from the menu name, then on the =20=

Mac the search will always fail and return -1. It doesn't seem to =20
matter if you leave the ampersand in for the menu item name, only the =20=

menu. For example, FindMenuItem('File', '&New') and =20
FindMenuItem('File', 'New') are okay on the Mac, but =20
FindMenuItem('&File', 'New') will return -1. FindMenuItem on Windows =20
doesn't have this problem and I'm pretty sure it has always worked on =20=

GTK as well. Note that FindMenu does not have a problem with an =20
ampersand in the name and as mentioned previously I don't think this =20
was broke prior to 2.5.1.0p8.

You can fire up the PyShell on the Mac to confirm this.

 >>> mbar =3D shell.GetParent().GetMenuBar()
 >>> mbar.FindMenuItem('File', 'New ')
5002
 >>> mbar.FindMenuItem('File', '&New ')
5002
 >>> mbar.FindMenuItem('&File', '&New ')
-1
=00>>> mbar.FindMenu('&File')
0
 >>> mbar.FindMenu('File')
0
"""

So I changed getMenuId, setChecked, and setEnabled in menu.py to strip =20=

the '&' which works fine on Windows (wxPython 2.4.2.4 and wxPython =20
2.5.1.5) and Mac (wxPython 2.5.1.5), but of course I don't use Linux =20
and apparently nobody else was testing the samples and tools on Linux =20=

which will tickle this particular bug: codeEditor, resourceEditor, =20
addresses, conversions, jabberChat, life, radioclient, slideshow, =20
turtle, webserver. Maybe GTK needs the & to make a match and =20
furthermore it is just wxPython 2.5.x that causes the problem.

So, to verify this, simply comment out the lines menuLabel =3D =20
m.label.strip('&') and see if the problem goes away. If that's it =20
(FindMenuItem) then I'll have to do a workaround and do a 0.7.3.1 =20
release.

ka
On Apr 7, 2004, at 9:55 AM, Phil Edwards wrote:

> On Wednesday 07 Apr 2004 12:22 pm, Phil Edwards wrote:
>>
>> I've got a hard drive problem on one of my machines - I've got =20
>> backups so
>> it's an inconvenience as opposed to a major disaster, but it means =20=

>> the new
>> RPM's won't be ready until the end of today at the earliest. :-(
>
> Okay, back up and running, thank $DEITY for recordable DVD's....
>
> Now, I have a problem with 0.7.3 when running with python 2.2.2 and =20=

> wxPython
> 2.5. I've installed 0.7.3 from the tarball and wxPython from the RPM =
on
> wxpython.org.
>
> When I run the resource editor from a command line prompt, I get this:
>
> -----begin-----
> [phile@localhost phile]$
> /usr/lib/python2.2/site-packages/PythonCardPrototype/tools/=20
> resourceEditor/resourceEditor.py
> Traceback (most recent call last):
>   File =20
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/binding.py", =20
> line
> 268, in dispatchOpenBackground
>     self.scriptable.dispatch.eventOccurred( event.OpenBackgroundEvent(
> self.scriptable ) )
>   File =20
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/dispatch.py",
> line 83, in eventOccurred
>     handler.getFunction()(self._scriptable, nativeEvent)
>   File
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/tools/=20
> resourceEditor/resourceEditor.py",
> line 134, in on_openBackground
>     self.updatePanel(self.rsrc)
>   File
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/tools/=20
> resourceEditor/resourceEditor.py",
> line 1243, in updatePanel
>     self.menuBar.setEnabled('menuFileRun', 1)
>   File "/usr/lib/python2.2/site-packages/PythonCardPrototype/menu.py", =
=20
> line
> 309, in setEnabled
>     self.Enable(id, aBoolean)
>   File "/usr/lib/python2.2/site-packages/wx/core.py", line 7602, in =20=

> Enable
>     return _core.MenuBar_Enable(*args, **kwargs)
> wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in
> ../src/common/menucmn.cpp(896): attempt to enable an item which =20
> doesn't exist
>
> ------end------
>
> The problem is that at line 309 (line 316 in the code below) of =20
> menu.py, the
> value of 'id' is set to -1 when it tries to call self.Enable(). As far =
=20
> as I
> can see, the code in this part of menu.py hasn't changed between 0.7.2 =
=20
> and
> 0.7.3, so I'm stumped as to what's going on. I put a bunch of print
> statements into menu.py so it looks like this:
>
> 299    def setEnabled( self, aString, aBoolean=3D1) :
> 300        print 'setEnabled, aString =3D [%s], aBoolean =3D [%s]' % =20=

> (aString,
> aBoolean)
> 301        i =3D 0
> 302        for m in self.menus:
> 303            print 'm is now [%s]' % m
> 304            menuLabel =3D m.label.strip('&')
> 305            print 'm.label =3D [%s], menuLabel =3D [%s]' % =
(m.label, =20
> menuLabel)
> 306            if m.name =3D=3D aString:
> 307                print 'm.name =3D=3D aString'
> 308                self.EnableTop(i, aBoolean)
> 309                break
> 310            for mi in m.items:
> 311                print 'mi is now [%s]' % mi
> 312                if mi.name =3D=3D aString:
> 313                    print 'mi.name =3D=3D aString, menuLabel =3D =
[%s]' %
> menuLabel
> 314                    id =3D self.FindMenuItem(menuLabel, mi.label)
> 315                    print 'found menu id [%s]' % id
> 316                    self.Enable(id, aBoolean)
> 317                    break
> 318            i +=3D 1
>
> When I run with this code, my output is:
>
> m.label =3D [&File], menuLabel =3D [File]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d3d6c>],
> 'checked': 0, 'name': 'menuFileNew', 'this': '_783a7d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': None, 'label':
> '&New...\tCtrl+N'}]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d4e14>],
> 'checked': 0, 'name': 'menuFileOpen', 'this': =
'_90587d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': None, 'label':
> '&Open...\tCtrl+O'}]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d592c>],
> 'checked': 0, 'name': 'menuFileSave', 'this': =
'_585d7d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': None, 'label':
> 'Save\tCtrl+S'}]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d5ffc>],
> 'checked': 0, 'name': 'menuFileSaveAs', 'this': =20
> '_10627d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': None, 'label': =20=

> 'Save
> &As...'}]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d647c>],
> 'checked': 0, 'name': 'menuFileRevert', 'this': =20
> '_d06e7d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': None, 'label':
> 'Revert'}]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d6e8c>],
> 'checked': 0, 'name': 'fileSep1', 'this': '_08747d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': None, 'label': =20=

> '-'}]
> mi is now [MenuItem=3D{'_listeners':
> [<PythonCardPrototype.dispatch.EventDispatch instance at 0x87d7604>],
> 'checked': 0, 'name': 'menuFileRun', 'this': '_08787d08_p_wxMenuItem',
> 'checkable': 0, 'thisown': 1, 'enabled': 1, 'command': 'fileRun', =20
> 'label':
> '&Run\tCtrl+R'}]
> mi.name =3D=3D aString, menuLabel =3D [File]
> found menu id [-1]
> Traceback (most recent call last):
>   File =20
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/binding.py", =20
> line
> 268, in dispatchOpenBackground
>     self.scriptable.dispatch.eventOccurred( event.OpenBackgroundEvent(
> self.scriptable ) )
>   File =20
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/dispatch.py",
> line 83, in eventOccurred
>     handler.getFunction()(self._scriptable, nativeEvent)
>   File
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/tools/=20
> resourceEditor/resourceEditor.py",
> line 134, in on_openBackground
>     self.updatePanel(self.rsrc)
>   File
> "/usr/lib/python2.2/site-packages/PythonCardPrototype/tools/=20
> resourceEditor/resourceEditor.py",
> line 1243, in updatePanel
>     self.menuBar.setEnabled('menuFileRun', 1)
>   File "/usr/lib/python2.2/site-packages/PythonCardPrototype/menu.py", =
=20
> line
> 316, in setEnabled
>     self.Enable(id, aBoolean)
>   File "/usr/lib/python2.2/site-packages/wx/core.py", line 7602, in =20=

> Enable
>     return _core.MenuBar_Enable(*args, **kwargs)
> wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in
> ../src/common/menucmn.cpp(896): attempt to enable an item which =20
> doesn't exist
>
> I've tried some of the other samples (proof, addresses, etc) and these =
=20
> run
> without any problems, it looks like its just the resource editor in =20=

> this
> case.
>
> --=20
>
> Regards
>
> Phil Edwards
> Brighton, UK
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>