pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] Debian package update

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

For quite a while now, the Debian Pythoncard packages have been
uninstallable.  This is because the wxPython 2.5 packages disappeared
out of unstable, and the wxPython 2.6 packages had not yet made it into
unstable.  Now that wxPython 2.6 is in unstable and seems to be working,
I have been able to rebuild the Pythoncard packages against the new
python-wxgtk2.6 package, and everything should be installable again.  

Sorry that it's taken so long, but the transition for wxPython 2.6 took
longer than I expected, and then once the new package was available, I
was without access to my development environment for a while.

If you see any problems with the packages, please file a bug in the
Debian bug tracking system (using 'reportbug').

Thanks,

KEN

-- 
Kenneth J. Pronovici <pro...@ie...>
http://www.cedar-solutions.com/

Re: [Pythoncard-users] overriding flatfileDB's on_editNewCard_command? dialog bits?

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

On Sep 1, 2005, at 10:20 PM, richard k belew wrote:

> and btw, i get this from enabling logging via the samples/sample.py
> shell; while i can run my app from command line (pythonw bobNotes.py),
> i guess i don't know how to pass the -l option in this way?

You'll want to use python (python.exe) instead of pythonw (pythonw.exe) 
if you want to get stdout console output.

ka

Re: [Pythoncard-users] overriding flatfileDB's on_editNewCard_command? dialog bits?

[richard k b. <ri...@co...>]

thanks for your quick reply kevin!

On 9/1/05 8:41 PM, Kevin Altis wrote:
> 
> I just tried adding an on_editNewCard_command event handler in 
> samples\flatfileDatabase.py and the command did work just fine. Perhaps 
> you have a typo in the actual source file. If you want to reply with an 
> attachment we can take a look.

hmm,  cuz samples\flatfileDatabase.py is what i used as my starting 
point, too!?  anyway, my "bobNotes" application and resource files 
atttached.

> Also, just to make sure this isn't a 
> problem with an older version, are you using version 0.8.1 of 
> PythonCard? 

correct, i'm also using 0.8.1.

> If you run your application with the -l (L) command line 
> option you should see each handler being bound, so if there is a typo 
> you would see the original on_editNewCard_command bound as well as the 
> command with the typo.

i see only one on_editNewCard_command being bound:

> DEBUG: : Thu Sep  1 16:20:30 2005: imported component statictext
> DEBUG: : Thu Sep  1 16:20:30 2005: imported component staticbox
> DEBUG: : Thu Sep  1 16:20:30 2005: imported component textfield
> DEBUG: : Thu Sep  1 16:20:30 2005: imported component textarea
> DEBUG: : Thu Sep  1 16:20:30 2005: imported component button
> DEBUG: : Thu Sep  1 16:20:30 2005: imported component imagebutton
> DEBUG: : Thu Sep  1 16:20:30 2005: Initializing Background...
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_close
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editClear_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editCopy_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editCut_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editDeleteCard_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editNewCard_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editPaste_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_editRedo_command

	...

> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_minimize
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_save_command
> DEBUG: : Thu Sep  1 16:20:30 2005: _addHandler: on_sort_command
> INFO: : Thu Sep  1 16:20:32 2005: filename: userdata.txt
> INFO: : Thu Sep  1 16:20:32 2005: startup took 0.034445 seconds

and btw, i get this from enabling logging via the samples/sample.py
shell; while i can run my app from command line (pythonw bobNotes.py),
i guess i don't know how to pass the -l option in this way?

> BTW, running this sample I see that wx has developed a problem with the 
> transparent next.gif and prev.gif images so I'll have to report that bug 
> with wxPython 2.6.1.0.

ok, but the gifs seem ok to me?!

> The dialogs can go in any event handler, you can even try them out in 
> the shell since they are all single line function calls. 

i've now looked again for examples in samples, and
do find some that i'll hope to apply.  thanks again!

	rik

Re: [Pythoncard-users] overriding flatfileDB's on_editNewCard_command? dialog bits?

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

On Sep 1, 2005, at 4:55 PM, richard k belew wrote:

> i'm a pythonCard newby, and these questions are probably way stupid.
> but answers to either would help me considerably:
>
>  #1: i've trying to make a minor, test change to the flatfileDatabase
> sample.  i thought i would decorate each card with a bit
> of static text that shows its creation timestamp.
>
> so i added a new component in the .rsrc.py file:
>
>> {'type':'StaticText',     'name':'enterDate',     'position':(427, 
>> 19),     'text':'yymmdd',     },
>
> using resourceEditor i see that the command associated
> with the "New Card" button is "editNewCard" and so i
> then added a handler to my class:
>
>> 	def on_editNewCard_command(self, event):
>> 		print "editNew"
>> 		self.components.enterDate.text = 
>> datetime.datetime.now().strftime('%y/%m/%d %H:%M')
>> 		flatfileDatabase.FlatfileDatabase.on_editNewCard_command(self, 
>> event)
>
> but nothing happens?!  whether i click on the NewCard
> button, or use the Menu's "New Card" option (which
> MenuEditor shows me emits the same command), i DO
> get a new card, but i do NOT
> get the enterDate static string to be anything other
> than its default "yymmdd".  i also do NOT see the "editNew"
> debugging message printed (whether i have full logging
> and debugging on or not).

I just tried adding an on_editNewCard_command event handler in 
samples\flatfileDatabase.py and the command did work just fine. Perhaps 
you have a typo in the actual source file. If you want to reply with an 
attachment we can take a look. Also, just to make sure this isn't a 
problem with an older version, are you using version 0.8.1 of 
PythonCard? If you run your application with the -l (L) command line 
option you should see each handler being bound, so if there is a typo 
you would see the original on_editNewCard_command bound as well as the 
command with the typo.

BTW, running this sample I see that wx has developed a problem with the 
transparent next.gif and prev.gif images so I'll have to report that 
bug with wxPython 2.6.1.0.

> #2: i'd like to make use of dialogs described at:
> 	pythoncard.sourceforge.net/dialogs/
> using the codeEditor's scriptlets seems helpful,
> but can you point me to JUST WHERE these bits should
> be dropped, into an application like flatfile, addressbook...?
>
> thanks for any help.
>
> 	rik

The dialogs can go in any event handler, you can even try them out in 
the shell since they are all single line function calls. Your event 
handler will lose control to the dialog until the dialog is dismissed. 
You can see numerous examples of using the various dialogs in the 
PythonCard samples and tools.

ka

[Pythoncard-users] overriding flatfileDB's on_editNewCard_command? dialog bits?

[richard k b. <ri...@co...>]

i'm a pythonCard newby, and these questions are probably way stupid.
but answers to either would help me considerably:

  #1: i've trying to make a minor, test change to the flatfileDatabase
sample.  i thought i would decorate each card with a bit
of static text that shows its creation timestamp.

so i added a new component in the .rsrc.py file:

> {'type':'StaticText', 
>     'name':'enterDate', 
>     'position':(427, 19), 
>     'text':'yymmdd', 
>     },
> 

using resourceEditor i see that the command associated
with the "New Card" button is "editNewCard" and so i
then added a handler to my class:

> 	def on_editNewCard_command(self, event):
> 		print "editNew"
> 		self.components.enterDate.text = datetime.datetime.now().strftime('%y/%m/%d %H:%M')
> 		flatfileDatabase.FlatfileDatabase.on_editNewCard_command(self, event)

but nothing happens?!  whether i click on the NewCard
button, or use the Menu's "New Card" option (which
MenuEditor shows me emits the same command), i DO
get a new card, but i do NOT
get the enterDate static string to be anything other
than its default "yymmdd".  i also do NOT see the "editNew"
debugging message printed (whether i have full logging
and debugging on or not).

#2: i'd like to make use of dialogs described at:
	pythoncard.sourceforge.net/dialogs/
using the codeEditor's scriptlets seems helpful,
but can you point me to JUST WHERE these bits should
be dropped, into an application like flatfile, addressbook...?

thanks for any help.

	rik

Re: [Pythoncard-users] PythonCard - Using wxSTAY_ON_TOP

[<gre...@gm...>]

The self.Raise() method brings my app on top of some windows but not on top=
=20
of others.=20

I'm seeing, it goes above Outlook and a dos window,
but does not go on top of IE, Firefox, or Textpad.

Since I want to be copying information from the browser I definately want i=
t=20
to work with Firefox. Any other ideas?


Greg


On 8/29/05, Gregory Pi=F1ero <gre...@gm...> wrote:
>=20
> Thanks Alex.=20
>=20
> That might be worth a try. I want my app to stay on top because I need to=
=20
> copy stuff off of web pages and paste it into my app and it's annoying to=
=20
> always have to click back to it. It would probably be smarter to integrat=
e=20
> my app into Firefox as an extension but then I'd have to learn a whole ne=
w=20
> set of skills!
>=20
> -Greg
>=20
>=20
> On 8/29/05, Alex Tweedly <al...@tw...> wrote:
> >=20
> > Gregory Pi=F1ero wrote:
> >=20
> > > Do you know of any way to keep it in front of all other applications?
> > >
> > Yes - but I think it's such a spectacularly bad idea to write such an
> > application, I'm tempted not to tell you :-) :-)=20
> >=20
> >=20
> > OK - what I tried was to create timer (I just fired it once per second)=
,
> > and had it do this
> >=20
> > > def on_TextField1_timer(self, event):
> > > self.childWindow.Raise()
> > > self.Raise ()
> >=20
> > self.Raise() will raise the main window to the top (i.e. over other
> > apps), but not over any dialog window invoked from the main window (the
> > dialog window will also come up to above other apps)
> >=20
> > Just to try if it could be done, this test also raises a child window -=
=20
> > nasty flicker if they overlap and I suspect some tricky cases possible
> > with interaction between the main window, any dialog and the child 0 bu=
t
> > otherwise works.
> >=20
> > I still say you shouldn't do it :-)
> >=20
> > --
> > Alex Tweedly http://www.tweedly.net=20
> >=20
> >=20
> >=20
> > --
> > No virus found in this outgoing message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.344 / Virus Database: 267.10.16 /83 - Release Date:=20
> > 26/08/2005
> >=20
> >=20
>=20
>=20
> --=20
> Gregory Pi=F1ero
> Chief Innovation Officer
> Blended Technologies
> (www.blendedtechnologies.com <http://www.blendedtechnologies.com>)=20
>=20



--=20
Gregory Pi=F1ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com <http://www.blendedtechnologies.com>)

Re: [Pythoncard-users] PythonCard - Using wxSTAY_ON_TOP

[<gre...@gm...>]

Thanks Alex.=20

That might be worth a try. I want my app to stay on top because I need to=
=20
copy stuff off of web pages and paste it into my app and it's annoying to=
=20
always have to click back to it. It would probably be smarter to integrate=
=20
my app into Firefox as an extension but then I'd have to learn a whole new=
=20
set of skills!

-Greg


On 8/29/05, Alex Tweedly <al...@tw...> wrote:
>=20
> Gregory Pi=F1ero wrote:
>=20
> > Do you know of any way to keep it in front of all other applications?
> >
> Yes - but I think it's such a spectacularly bad idea to write such an
> application, I'm tempted not to tell you :-) :-)
>=20
>=20
> OK - what I tried was to create timer (I just fired it once per second),
> and had it do this
>=20
> > def on_TextField1_timer(self, event):
> > self.childWindow.Raise()
> > self.Raise()
>=20
> self.Raise() will raise the main window to the top (i.e. over other
> apps), but not over any dialog window invoked from the main window (the
> dialog window will also come up to above other apps)
>=20
> Just to try if it could be done, this test also raises a child window -
> nasty flicker if they overlap and I suspect some tricky cases possible
> with interaction between the main window, any dialog and the child 0 but
> otherwise works.
>=20
> I still say you shouldn't do it :-)
>=20
> --
> Alex Tweedly http://www.tweedly.net=20
>=20
>=20
>=20
> --
> 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/200=
5
>=20
>=20


--=20
Gregory Pi=F1ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com <http://www.blendedtechnologies.com>)

Re: [Pythoncard-users] PythonCard - Using wxSTAY_ON_TOP

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

Gregory Piñero wrote:

> Do you know of any way to keep it in front of all other applications?
>
Yes - but I think it's such a spectacularly bad idea to write such an 
application, I'm tempted not to tell you :-) :-)


OK - what I tried was to create timer (I just fired it once per second), 
and had it do this

>     def on_TextField1_timer(self, event):
>         self.childWindow.Raise()
>         self.Raise()

self.Raise() will raise the main window to the top (i.e. over other 
apps), but not over any dialog window invoked from the main window (the 
dialog window will also come up to above other apps)

Just to try if it could be done, this test also raises a child window - 
nasty flicker if they overlap and I suspect some tricky cases possible 
with interaction between the main window, any dialog and the child 0 but 
otherwise works.

I still say you shouldn't do it :-)

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

Re: [Pythoncard-users] PythonCard - Using wxSTAY_ON_TOP

[<gre...@gm...>]

Do you know of any way to keep it in front of all other applications?

Greg


On 8/29/05, Kevin Altis <al...@se...> wrote:
>=20
> On Aug 29, 2005, at 9:59 AM, Gregory Pi=F1ero wrote:
>=20
> > Hey guys,
> >
> > I heard that wxPython had a thing called wxSTAY_ON_TOP that would let
> > me always keep my application in the foreground. Do you know how I
> > would use such a thing in PythonCard?
> >
> > Any help would be much appriciated.
> >
> > Thanks
> >
> > --
> > Gregory Pi=F1ero
> > Chief Innovation Officer
> > Blended Technologies
> > (www.blendedtechnologies.com <http://www.blendedtechnologies.com> )
> >
>=20
> I think that flag, which is passed as one of the style flags during
> wx.Frame init just keeps that frame always in front of other frames for
> the application and has no impact on other applications.
>=20
> ka
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf=
=20
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...=20
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users=20
>=20



--=20
Gregory Pi=F1ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com <http://www.blendedtechnologies.com>)

Re: [Pythoncard-users] PythonCard - Using wxSTAY_ON_TOP

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

On Aug 29, 2005, at 9:59 AM, Gregory Pi=F1ero wrote:

> Hey guys,
>
> I heard that wxPython had a thing called wxSTAY_ON_TOP that would let
> me always keep my application in the foreground.  Do you know how I
> would use such a thing in PythonCard?
>
> Any help would be much appriciated.
>
> Thanks
>
> --=20
> Gregory Pi=F1ero
> Chief Innovation Officer
> Blended Technologies
> (www.blendedtechnologies.com)
>

I think that flag, which is passed as one of the style flags during=20
wx.Frame init just keeps that frame always in front of other frames for=20=

the application and has no impact on other applications.

ka

[Pythoncard-users] PythonCard - Using wxSTAY_ON_TOP

[<gre...@gm...>]

Hey guys,

I heard that wxPython had a thing called wxSTAY_ON_TOP that would let
me always keep my application in the foreground.  Do you know how I
would use such a thing in PythonCard?

Any help would be much appriciated.

Thanks

--=20
Gregory Pi=F1ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com)

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

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

Kevin Altis wrote:

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

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

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

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

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

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

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



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

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

[Ed L. <ed...@le...>]

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

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

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

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

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

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

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

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

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

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

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

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

the components and recreate them in the correct display order.

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

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

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

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

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

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

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

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

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

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

ka

Re: [Pythoncard-users] Re: [Pythonmac-SIG] PythonCard on OS X 10.4 with Python 2.4.1

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

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

[Pythoncard-users] Re: [Pythonmac-SIG] PythonCard on OS X 10.4 with Python 2.4.1

[<ad...@eu...>]

Hello listers,


"Samuel M. Smith" <sm...@sa...> wrote on 08/25/2005 10:53:55 
AM:

> Anybody have any luck in getting PythonCard to work on OS X 10.4x 
> with Python 2.4.1?
> The PythonCard websit is limited to Panther instructions. I saw a 
> post where someone got it to work with Python 2.3.5.

There's a current thread about this in the PythonCard-users group,
under the non-clear subject name: 

        Re: update (was: Re: [Pythoncard-users] supposed bug in 
PythonCard)


Yes I originated the thread. I found a bug in Pythoncard with python 2.4.1 and wxPython 2.6.1.0 and
PythonCard 0.8.1

It's not "supposed". It's a quite clearly a bug.

The installation worked. The "Minimal" application started correctly and you can consider this as a
test for correct installation, as stated in the tutorial.

What I found is:

a) when starting the resource editor, a .cfg file was looked for in PythonCard/somethin/something/
instead it was in PythonCard/
Now I don't remember exactly but you can read my posts. I reported it, I think
Or you can follow the tutorial instructions and you probably reproduce it

b) The ResourceEditor doesn't start correctly. It looks for sources to load in the wrong position,
i don't know why.

That' s it

I think you can reproduce theese problems quite easly, if you try

And if you can find something more than what I found, I'd be grateful if you would report too.

Thanks so much
Bye
Adriano

[Pythoncard-users] [Pythonmac-SIG] PythonCard on OS X 10.4 with Python 2.4.1

[Samuel M. S. <sm...@sa...>]

Anybody have any luck in getting PythonCard to work on OS X 10.4x  
with Python 2.4.1?
The PythonCard websit is limited to Panther instructions. I saw a  
post where someone got it to work with Python 2.3.5.


_______________________________________________
Pythonmac-SIG maillist  -  Pyt...@py...
http://mail.python.org/mailman/listinfo/pythonmac-sig

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

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

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

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

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

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/

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

[<bra...@om...>]

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

Re: update (was: Re: [Pythoncard-users] supposed bug in PythonCard)

[<bra...@om...>]

Kevin Altis wrote on 08/23/2005 08:28:42 PM:


> Well this is quite annoying, either a path bug with the pythonw2.4 on 
> the Mac (seems most likely) or the way the paths are manipulated in 
> model.py is causing a problem. Anyway, I assume this is happening in 
> resourceEditor.py due to this line
> 
> from modules.propertyEditor import PropertyEditor
> 
> which is different from the other imports where we have stuff coming 
> from the modules directory. I'm not even sure why this was done, but 
> normally that kind of import is not a problem. Anyway, change it to
> 
> from modules import propertyEditor
> 
> and then change the following line so that the propertyEditor module is 
> prefixed before the class (roughly line 138).
> 
>          self.propertyEditorWindow = model.childWindow(self, 
> PropertyEditor)
> 
> becomes
> 
>          self.propertyEditorWindow = model.childWindow(self, 
> propertyEditor.PropertyEditor)
> 
> Then try running it again with -l to get the log and see if it bugs out 
> again or manages to open up.


No luck. I made the two changes you suggested and get the exact
same result.

[Pythoncard-users] Re: [Pythonmac-SIG] PythonCard on OS X 10.4 with Python 2.4.1

[<bra...@om...>]

"Samuel M. Smith" <sm...@sa...> wrote on 08/25/2005 10:53:55 
AM:

> Anybody have any luck in getting PythonCard to work on OS X 10.4x 
> with Python 2.4.1?
> The PythonCard websit is limited to Panther instructions. I saw a 
> post where someone got it to work with Python 2.3.5.

There's a current thread about this in the PythonCard-users group,
under the non-clear subject name: 

        Re: update (was: Re: [Pythoncard-users] supposed bug in 
PythonCard)

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

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

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/

RE: [Pythoncard-users] Installing PythonCard and Python24

[Howard H. <hr...@co...>]

> -----Original Message-----
> From: pyt...@li... [mailto:pythoncard-
use...@li...] On Behalf Of Alex Tweedly
> Sent: Monday, August 22, 2005 4:36 PM
> To: Howard Hansen
> Cc: pyt...@li...
> Subject: Re: [Pythoncard-users] Installing PythonCard and Python24

> Howard Hansen wrote:

>> I get the following error message when I try to run PythonCard's
>> CodeEditor.  Python23.dll not found 

>Which versions of PythonCard and wxPython ?

Thanks for the reply.  Your hint fixed my problem.  Because Source
Forge's
installation page for PythonCard only lists one version of wxpython I
didn't know there was more than one version of wxpython.  The version of
wxpython listed on Source Forge's PythonCard installation page only
works with Python version 2.3. Using your hint I searched Source Forge's
Web Site and found a version of wxpython designed to work with Python
version 2.4. Upgrading wxpython to
wxPython2.6-win32-ansi-2.6.1.0-py24.exe 
enables PythonCard's CodeEditor to work with Python version 2.4.

> Do the wxPython Demos work (separate download for "Docs and Demos" ) ?

> I vaguely remember (but can't currently find) a message about needing 
> PythonCard-0.8.1-FIXED.win32.exe  (rather than simply 
> PythonCard-0.8.1.win32.exe) - (I think that was) to run with Python
2.4

-- 
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.13/78 - Release Date:
19/08/2005



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Re: update (was: Re: [Pythoncard-users] supposed bug in PythonCard)

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

On Aug 23, 2005, at 5:02 PM, bra...@om... wrote:

>
> Alex Tweedly wrote on 08/23/2005 04:07:27 PM:
>
> > Could you possibly try running it with the logging option ("-l" =20
> appended) also ?
>
> Ok, here it is:
>
>
> oms-ballen:/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor =20
> ballen$ pythonw2.4 resourceEditor.py -l
> wx.PlatformInfo: ('__WXMAC__', 'wxMac', 'unicode', 'wx-assertions-on')
> wx.VERSION: (2, 6, 0, 0, '')
> DEBUG: : Tue Aug 23 18:59:18 2005: default: (None, 'mac-roman')
> DEBUG: : Tue Aug 23 18:59:18 2005: ['resourceEditor.mac.rsrc.py', =20
> 'resourceEditor.rsrc.py']
> DEBUG: : Tue Aug 23 18:59:18 2005: Initializing Background...
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =
on_bottomLeft_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_bottomMiddle_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_bottomRight_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_close
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =
on_componentAdd_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_componentBringFront_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_componentDelete_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_componentDuplicate_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_componentMoveBack_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_componentMoveForward_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_componentSendBack_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_displayAttributes_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_doHelpAboutPythonCard_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_editBackgroundInfo_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_editDialogInfo_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_editMenubar_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_editStackInfo_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_editStrings_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_exit_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_filePreviewDialog_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_fileRunOptions_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_fileRunWithInterpreter_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_fileRun_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_initialize
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_keyPress
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_menuEditCopy_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_menuEditCut_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =
on_menuEditPaste_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_menuFileNewDialog_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_menuFileNew_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_menuFileOpen_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_menuFileRevert_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_menuFileSaveAs_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_menuFileSave_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =
on_menuHelpAbout_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_menuOptionsAlignToGrid_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_menuOptionsShowGridLines_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_menuViewPropertyEditor_select
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =
on_middleLeft_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_middleRight_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_minimize
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_mouseDoubleClick
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_mouseDown
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_mouseEnter
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_mouseLeave
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_mouseUp
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_optionGridSize_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_showPythonCardDocumentation_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: =20
> on_showResourceEditorDocumentation_command
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_size
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_topLeft_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_topMiddle_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: _addHandler: on_topRight_mouseDrag
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component bitmapcanvas
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component button
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component calendar
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component checkbox
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component choice
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component codeeditor
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component combobox
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component floatcanvas
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component gauge
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component htmlwindow
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component image
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component imagebutton
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component list
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component multicolumnlist
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component notebook
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component passwordfield
> DEBUG: : Tue Aug 23 18:59:18 2005: imported component radiogroup
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component slider
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component spinner
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component staticbox
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component staticline
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component statictext
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component textarea
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component textfield
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component togglebutton
> DEBUG: : Tue Aug 23 18:59:19 2005: imported component tree
> DEBUG: : Tue Aug 23 18:59:19 2005: default: (None, 'mac-roman')
> DEBUG: : Tue Aug 23 18:59:19 2005: =20
> ['/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor/=20
> propertyEditor.mac.rsrc.py', =20
> '/OMS/dev/pythonPackages/PythonCard/tools/resourceEditor/=20
> propertyEditor.rsrc.py']
> no resource file for =20
> /OMS/dev/pythonPackages/PythonCard/tools/resourceEditor/propertyEditor
> Traceback (most recent call last):
> =A0 File =20
> "//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/=20
> site-packages/wx-2.6-mac-unicode/wx/_core.py", line 11904, in <lambda>
> =A0 =A0 lambda event: event.callable(*event.args, **event.kw) )
> =A0 File "resourceEditor.py", line 138, in on_initialize
> =A0 =A0 self.propertyEditorWindow =3D model.childWindow(self, =
PropertyEditor)
> =A0 File "/OMS/dev/pythonPackages/PythonCard/model.py", line 220, in =20=

> childWindow
> =A0 =A0 rsrc =3D resource.ResourceFile(filename).getResource()
> =A0 File "/OMS/dev/pythonPackages/PythonCard/resource.py", line 45, in =
=20
> __init__
> =A0 =A0 self.dictionary =3D util.readAndEvalFile(rsrcFileName)
> =A0 File "/OMS/dev/pythonPackages/PythonCard/util.py", line 37, in =20
> readAndEvalFile
> =A0 =A0 f =3D open(filename)
> TypeError: coercing to Unicode: need string or buffer, NoneType found
> ^C

Well this is quite annoying, either a path bug with the pythonw2.4 on =20=

the Mac (seems most likely) or the way the paths are manipulated in =20
model.py is causing a problem. Anyway, I assume this is happening in =20
resourceEditor.py due to this line

from modules.propertyEditor import PropertyEditor

which is different from the other imports where we have stuff coming =20
from the modules directory. I'm not even sure why this was done, but =20
normally that kind of import is not a problem. Anyway, change it to

from modules import propertyEditor

and then change the following line so that the propertyEditor module is =20=

prefixed before the class (roughly line 138).

         self.propertyEditorWindow =3D model.childWindow(self, =20
PropertyEditor)

becomes

         self.propertyEditorWindow =3D model.childWindow(self, =20
propertyEditor.PropertyEditor)

Then try running it again with -l to get the log and see if it bugs out =20=

again or manages to open up.

ka