pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] #pythoncard irc channel on freenode

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

I've started a #pythoncard channel on irc.freenode.net. Jeremy Fincher 
has graciously agreed to run supybot on the channel, so it should 
always be active and have a lot of commands available via supybot. I'll 
probably be in there pretty regularly until we know whether it will be 
a valuable forum for discussing PythonCard outside of the mailing list. 
If we get a group of regulars that can answer FAQ type questions that 
will be awesome. Maybe we'll even do a Supybot PythonCard plugin.

You can ask supybot to do something for you by using the @ command. 
Here's an example I just tried in the channel...

altis: @list
supybot: altis: Admin, Alias, Amazon, Babelfish, Bugzilla, Channel, 
ChannelLogger, ChannelStats, Config, Debian, Dict, Ebay, Enforcer, 
Factoids, Filter, Fun, FunDB, Gameknot, Google, Herald, Http, Karma, 
Lookup, Math, Misc, Network, News, Note, Owner, Python, Quotes, RSS, 
Relay, RootWarner, Scheduler, Seen, Services, Sourceforge, Status, 
Todo, Topic, URL, Unix, User, Utilities, Weather, and WordStats
altis: @help
supybot: altis: (help [<plugin>] <command>) -- This command gives a 
useful description of what <command> does. <plugin> is only necessary 
if the command is in more than one plugin.

See the Supybot site for more info...
http://supybot.sourceforge.net/

If you need some help with Internet Relay Chat (irc), check out 
http://www.irchelp.org/

On Mac OS X, I'm using Colloquy, http://colloquy.info/ as my client. On 
Windows, you might want to try mIRC, http://www.mirc.com/ There are a 
ton of irc clients to choose from on all platforms.

ka

Re: [Pythoncard-users] Re: creating SQL insert/Update stmts

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

Hi,
I want to generate the insert code from both the form and the columns.  The hard part seems to be the form fields.  Should I specify them in a list self.fields=['SSNUM','FirstName',...] and then simply use self.fields[index[... in my code?

--- "Mike C. Fletcher" <mcf...@ro...> wrote:
Kevin Altis wrote (quoting ralph heimburger):
...

>>insstmt="INSERT INTO MEMBER ("
>>            for colname in self.rowsDict: insstmt=insstmt+colname+","
>>            insstmt=insstmt[1:len(insstmt)-1]+") VALUES ("
>>            ##for textvalue in self.components:
>>            insstmt=insstmt+"'"+self.components.SSN.text+"',"
>>            insstmt=insstmt+"'"+self.components.FirstName.text+"',"
>>            ... (60+fields)
>>    
>>
Eeps, don't do this (just dump the text in with ' and ')!  Not only do 
you open yourself to all sorts of security problems, you're not getting 
any escaping of characters in the text, so it will fail if you have 
someone enter ain't can't or don't (which is also where the security 
problems start).  If you need something which generates SQL 
insert/update/refresh/delete code from a schema PyTable has code you can 
likely crib fairly easily:

http://cvs.sourceforge.net/viewcvs.py/pytable/table/pytable/dbrow.py?only_with_tag=HEAD&view=markup

The RowAction and it's various sub-classes being the ones in which 
you're likely to be interested.  Not sure how much of a schema you've 
got in "components", but the code there doesn't really do all *that* 
much with the schema other than figuring out the unique keys to use to 
specify the row.

At a minimum, use the database driver's escaping by passing in the query 
string with %(name)s or %s placeholders for each field and then pass the 
values in as extra arguments to execute.  (The SQLQuery class on which 
the RowAction is based actually does two-level escaping, in case you're 
wondering how the query is being composed in the dbrow module above, so 
the first substitution changes the query string and the second is done 
by the driver to get data-type escaping).

I know, I know, not quite on topic, but it just made me go "ouch" when I 
saw it...
Mike


_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/




-------------------------------------------------------
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=1470&alloc_id=3638&op=click
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users


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

RE: [Pythoncard-users] Re: creating SQL insert/Update stmts

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

> From: Kevin Altis
>
> You can also give the fields you want to process special names or
> a special
> prefix that you can compare against in a loop. You might also want to keep
> your own list of what you want to process. For example, in the
> openBackground event handler, create a list like:
>
>     self.fieldNames = ['SSN', 'FirstName']
>
> Then when you need to process those fields you can loop over the list. The
> loop below would print out the text of the SSN and FirstName fields.
>
>     for name in self.fieldNames:
>         print self.components[name].text

I should have mentioned that every component has a 'userdata' string
attribute that you can use to store whatever string info you need; userdata
is never touched by the framework, it is just for your use. The attribute is
editable in the resourceEditor. That might be an even simpler place for you
to stick info that you can check when you iterate over the components.
Personally, I like the list of field names solution above.

ka

RE: [Pythoncard-users] Strange behavior

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

Ok, I fixed the problem by changing the code to use the "command" of the button instead of the mouseDown as follows:
def on_DeleteRecord_command(self, event):

It now works properly.


--- "Kevin Altis" <al...@se...> wrote:
> From: ralph heimburger
>
> In my pythoncard app (memmaint.py),
> I have a dialog box displayed when they press the "delete"
> button.  When I click the delete button the code works as
> desired.  It displays the dialog with OK/CANCEL and then an alert
> to notify me that the record has been deleted.
>
> Apparently this changes the functionality of the form close event
> as well.  After I press Delete and then press File->Exit or the
> Close form (X) button, the delete event is fired again.

Hmm, I'm not sure, but you should be using a mouseClick handler instead of
mouseDown (i.e. on_DeleteButton_mouseClick). Do you already have a different
DeleteButton mouseClick handler? Do you have a on_close event handler that
interacts with the DeleteButton or anything else that might be related? The
only other thing I can think of is that an extra click is somehow getting
through to the background when you click OK on the alertDialog, perhaps an
accidental double-click? Does the Message Watcher show multiple mouseClicks
for the DeleteButton?

>     def on_DeleteButton_mouseDown(self, event):
>          keyfld="["+self.components.SSN.text+"]
> "+self.components.LastName.text+","+self.components.FirstName.text
>         result=dialog.messageDialog(self, 'Delete Member:
> '+keyfld,'Delete Member')
>         if result['accepted']:
>             whereclause="WHERE LNAME =
> '"+self.components.LastName.text+"' AND FNAME
> ='"+self.components.FirstName.text+"' AND MI =
> '"+self.components.MI.text+"' AND SSNUM ='"+self.components.SSN.text+"'"
>             Memselect="SELECT * from member "+whereclause
>             self.Memcursor.execute (Memselect)
>             rows=int(self.Memcursor.rowcount)
>             if rows == 1:
>                #Insert into member_deleted
>                Memselect="insert INTO members_deleted SELECT *
> from member "+whereclause
>                self.Memcursor.execute (Memselect)
>                #Delte from member
>                Memselect="DELETE FROM member "+whereclause
>                self.Memcursor.execute (Memselect)
>                self.rowcount -= 1
>                self.showSelected()
>                dialog.alertDialog(self, 'Member DELETED', 'Information')
>

In general, when reporting bugs, go ahead and list the platform and version
info to make it easier to diagnose the bug. You can get that info from the
About dialog under the Debug menu by running any sample or tool with the -d
(Debug) or any other runtime window command-line option. For example, on my
machine I'm running:

PythonCard version: 0.8
wxPython version: 2.5.1.5
PyCrust version: 0.9.4
Python version: 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit
(Intel)]
Platform: win32

Hmm, I suppose we should make this easier to get to by putting it in the
codeEditor and resourceEditor. Perhaps we should even have a separate debug
info tool that would list other useful info such the users PYTHONPATH,
environment variables, and other system info that could provide clues.
Another potential 0.8 release item. :)

ka



-------------------------------------------------------
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=1470&alloc_id=3638&op=click
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users


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

Re: [Pythoncard-users] Re: creating SQL insert/Update stmts

[Mike C. F. <mcf...@ro...>]

Kevin Altis wrote (quoting ralph heimburger):
...

>>insstmt="INSERT INTO MEMBER ("
>>            for colname in self.rowsDict: insstmt=insstmt+colname+","
>>            insstmt=insstmt[1:len(insstmt)-1]+") VALUES ("
>>            ##for textvalue in self.components:
>>            insstmt=insstmt+"'"+self.components.SSN.text+"',"
>>            insstmt=insstmt+"'"+self.components.FirstName.text+"',"
>>            ... (60+fields)
>>    
>>
Eeps, don't do this (just dump the text in with ' and ')!  Not only do 
you open yourself to all sorts of security problems, you're not getting 
any escaping of characters in the text, so it will fail if you have 
someone enter ain't can't or don't (which is also where the security 
problems start).  If you need something which generates SQL 
insert/update/refresh/delete code from a schema PyTable has code you can 
likely crib fairly easily:

http://cvs.sourceforge.net/viewcvs.py/pytable/table/pytable/dbrow.py?only_with_tag=HEAD&view=markup

The RowAction and it's various sub-classes being the ones in which 
you're likely to be interested.  Not sure how much of a schema you've 
got in "components", but the code there doesn't really do all *that* 
much with the schema other than figuring out the unique keys to use to 
specify the row.

At a minimum, use the database driver's escaping by passing in the query 
string with %(name)s or %s placeholders for each field and then pass the 
values in as extra arguments to execute.  (The SQLQuery class on which 
the RowAction is based actually does two-level escaping, in case you're 
wondering how the query is being composed in the dbrow module above, so 
the first substitution changes the query string and the second is done 
by the driver to get data-type escaping).

I know, I know, not quite on topic, but it just made me go "ouch" when I 
saw it...
Mike


_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

Re: [Pythoncard-users] a Python Card Builder???

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

On Apr 16, 2004, at 7:01 AM, Brian Debuire wrote:

> Hi everyone!
> =A0
> Since=A0I=A0have been working with Pyhton Card, a lot of upgrades come =
to=20
> my mind every day, some are functional and others are focused on the=20=

> GUI.
> But the staying with the "kiss" thing i disagree, python card should=20=

> be more like a=A0builder program like JBuilder, CBuilder etc. and i =
hope=20
> it will get like that. Ithink python is even better that java and=20
> simpliest so it needs a powerful tool.
> That is just my opinion and i will accept any critics nicely :)

Well, we all have our opinions, but those people that actually write=20
some PythonCard framework code get to commit those opinions to cvs=20
<wink> Anyone that wants to join the team can, they just need to start=20=

supplying some code, samples, bug fixes, enhancements, etc.

It is important for PythonCard to be easy to learn and use. If you want=20=

to create something like JBuilder, CBuilder, etc. then that sounds=20
great to me as long as it doesn't require the underlying PythonCard API=20=

to become overly complex and you aren't expecting me to write all that=20=

code; I haven't ever used JBuilder or CBuilder. We can always include=20
multiple "builder tools" that will appeal to different developer skill=20=

levels.

If you want a more complex and feature rich API then you might actually=20=

be happier just coding in "raw" wxPython and using a tool like=20
Boa-constructor which is modeled after Delphi. If you decide to try=20
Boa, just make sure you check it out from cvs, since the release=20
version is very old.

> By the way, on my dreaming of A python Builder i have wrote a Py Card=20=

> app that coul be called a builder, but it just creates a standard app=20=

> for pygame, but i think it would help new Pyhton Card and pygame=20
> programmers, so if it is of interest i could send it to Kevin Altis to=20=

> aprove it and maybe release it with the other pyhton card examples.

Sounds good to me. If you have a URL we can go ahead and add it to the=20=

More Applications page now. If you don't have it available on a website=20=

and it isn't too large, then you can just send it to the mailing list=20
as a .zip attachment, otherwise email the zip directly to me.

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

> Greetings, and nice work to the develop and testing python card team!
> =A0
> Brian

ka

RE: [Pythoncard-users] Strange behavior

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

> From: ralph heimburger
>
> In my pythoncard app (memmaint.py),
> I have a dialog box displayed when they press the "delete"
> button.  When I click the delete button the code works as
> desired.  It displays the dialog with OK/CANCEL and then an alert
> to notify me that the record has been deleted.
>
> Apparently this changes the functionality of the form close event
> as well.  After I press Delete and then press File->Exit or the
> Close form (X) button, the delete event is fired again.

Hmm, I'm not sure, but you should be using a mouseClick handler instead of
mouseDown (i.e. on_DeleteButton_mouseClick). Do you already have a different
DeleteButton mouseClick handler? Do you have a on_close event handler that
interacts with the DeleteButton or anything else that might be related? The
only other thing I can think of is that an extra click is somehow getting
through to the background when you click OK on the alertDialog, perhaps an
accidental double-click? Does the Message Watcher show multiple mouseClicks
for the DeleteButton?

>     def on_DeleteButton_mouseDown(self, event):
>          keyfld="["+self.components.SSN.text+"]
> "+self.components.LastName.text+","+self.components.FirstName.text
>         result=dialog.messageDialog(self, 'Delete Member:
> '+keyfld,'Delete Member')
>         if result['accepted']:
>             whereclause="WHERE LNAME =
> '"+self.components.LastName.text+"' AND FNAME
> ='"+self.components.FirstName.text+"' AND MI =
> '"+self.components.MI.text+"' AND SSNUM ='"+self.components.SSN.text+"'"
>             Memselect="SELECT * from member "+whereclause
>             self.Memcursor.execute (Memselect)
>             rows=int(self.Memcursor.rowcount)
>             if rows == 1:
>                #Insert into member_deleted
>                Memselect="insert INTO members_deleted SELECT *
> from member "+whereclause
>                self.Memcursor.execute (Memselect)
>                #Delte from member
>                Memselect="DELETE FROM member "+whereclause
>                self.Memcursor.execute (Memselect)
>                self.rowcount -= 1
>                self.showSelected()
>                dialog.alertDialog(self, 'Member DELETED', 'Information')
>

In general, when reporting bugs, go ahead and list the platform and version
info to make it easier to diagnose the bug. You can get that info from the
About dialog under the Debug menu by running any sample or tool with the -d
(Debug) or any other runtime window command-line option. For example, on my
machine I'm running:

PythonCard version: 0.8
wxPython version: 2.5.1.5
PyCrust version: 0.9.4
Python version: 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit
(Intel)]
Platform: win32

Hmm, I suppose we should make this easier to get to by putting it in the
codeEditor and resourceEditor. Perhaps we should even have a separate debug
info tool that would list other useful info such the users PYTHONPATH,
environment variables, and other system info that could provide clues.
Another potential 0.8 release item. :)

ka

RE: [Pythoncard-users] Re: creating SQL insert/Update stmts

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

Another pre morning coffee email, let's see if I do better this time <wink>

> From: ralph heimburger
>
> I am looking for an easy way to create the insert/update SQL
> statements and how to reference self.components.<TextField>.text objects.
>
> Is there a programatic way to do a for fieldname in
> self.components.fields???

self.components is a custom dictionary based on the UserDict class.

http://www.python.org/doc/current/lib/module-UserDict.html

Since components is a "mapping" type object that means the standard mapping
operations apply.

http://www.python.org/doc/current/lib/typesmapping.html

Using that info, we can run the widgets sample with the shell (-s on the
command-line) to experiment. There are actually several ways you could solve
your problem. If you just want to match components of type TextField and not
subclasses of TextField like TextArea, then the second comparison below
(c.__class__ is TextField) is probably what you want to use. You can also do
a string compare against the __class__.__name__ if you don't want to import
the class.

>>> from PythonCardPrototype.components.textfield import TextField
>>> for c in self.components.itervalues():
...     if isinstance(c, TextField):
...         print c.name
...
fldPasswordField
fldTextFieldNoBorder
fldTextArea
fldTextField
>>> for c in self.components.itervalues():
...     if c.__class__ is TextField:
...         print c.name
...
fldTextFieldNoBorder
fldTextField
>>> self.components.fldTextField.__class__.__name__
'TextField'
>>>

You can also give the fields you want to process special names or a special
prefix that you can compare against in a loop. You might also want to keep
your own list of what you want to process. For example, in the
openBackground event handler, create a list like:

    self.fieldNames = ['SSN', 'FirstName']

Then when you need to process those fields you can loop over the list. The
loop below would print out the text of the SSN and FirstName fields.

    for name in self.fieldNames:
        print self.components[name].text

> How would I handle date columns?

I don't know what you mean.

> insstmt="INSERT INTO MEMBER ("
>             for colname in self.rowsDict: insstmt=insstmt+colname+","
>             insstmt=insstmt[1:len(insstmt)-1]+") VALUES ("
>             ##for textvalue in self.components:
>             insstmt=insstmt+"'"+self.components.SSN.text+"',"
>             insstmt=insstmt+"'"+self.components.FirstName.text+"',"
>             ... (60+fields)

ka
p.s. Just in case anyone was wondering, yes components will probably become
a direct subclass of the built-in dict type instead of UserDict. When
PythonCard was started we were using Python 2.1. I'll add that to the 0.8 to
do list.

[Pythoncard-users] a Python Card Builder???

[Brian D. <deb...@ho...>]

<html><div style='background-color:'><DIV class=RTE>Hi everyone!</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>Since&nbsp;I&nbsp;have been working with Pyhton Card, a lot of upgrades come to my mind every day, some are functional and others are focused on the GUI.</DIV>
<DIV class=RTE>But the staying with the "kiss" thing i disagree, python card should be more like a&nbsp;builder program like JBuilder, CBuilder etc. and i hope it will get like that. Ithink python is even better that java and simpliest so it needs a powerful tool.</DIV>
<DIV class=RTE>That is just my opinion and i will accept any critics nicely :)</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>By the way, on my dreaming of A python Builder i have wrote a Py Card app that coul be called a builder, but it just creates a standard app for pygame, but i think it would help new Pyhton Card and pygame programmers, so if it is of interest i could send it to Kevin Altis to aprove it and maybe release it with the other pyhton card examples.</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>Greetings, and nice work to the develop and testing python card team!</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>Brian</DIV>
<DIV class=RTE>&nbsp;</DIV></div><br clear=all><hr>Tired of spam? Get <a href="http://g.msn.com/8HMBEN/2734??PS=">advanced junk mail protection</a> with MSN 8.</html>

[Pythoncard-users] Re: creating SQL insert/Update stmts

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

I am looking for an easy way to create the insert/update SQL statements and how to reference self.components.<TextField>.text objects.

Is there a programatic way to do a for fieldname in self.components.fields???

How would I handle date columns?

insstmt="INSERT INTO MEMBER ("
            for colname in self.rowsDict: insstmt=insstmt+colname+","
            insstmt=insstmt[1:len(insstmt)-1]+") VALUES ("
            ##for textvalue in self.components: 
            insstmt=insstmt+"'"+self.components.SSN.text+"',"
            insstmt=insstmt+"'"+self.components.FirstName.text+"',"
            ... (60+fields)




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

[Pythoncard-users] Strange behavior

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

In my pythoncard app (memmaint.py),
I have a dialog box displayed when they press the "delete" button.  When I click the delete button the code works as desired.  It displays the dialog with OK/CANCEL and then an alert to notify me that the record has been deleted.

Apparently this changes the functionality of the form close event as well.  After I press Delete and then press File->Exit or the Close form (X) button, the delete event is fired again.

    def on_DeleteButton_mouseDown(self, event):
         keyfld="["+self.components.SSN.text+"] "+self.components.LastName.text+","+self.components.FirstName.text
        result=dialog.messageDialog(self, 'Delete Member: '+keyfld,'Delete Member')
        if result['accepted']:
            whereclause="WHERE LNAME = '"+self.components.LastName.text+"' AND FNAME ='"+self.components.FirstName.text+"' AND MI = '"+self.components.MI.text+"' AND SSNUM ='"+self.components.SSN.text+"'"
            Memselect="SELECT * from member "+whereclause
            self.Memcursor.execute (Memselect)
            rows=int(self.Memcursor.rowcount)
            if rows == 1:
               #Insert into member_deleted
               Memselect="insert INTO members_deleted SELECT * from member "+whereclause
               self.Memcursor.execute (Memselect)
               #Delte from member
               Memselect="DELETE FROM member "+whereclause
               self.Memcursor.execute (Memselect)
               self.rowcount -= 1
               self.showSelected()
               dialog.alertDialog(self, 'Member DELETED', 'Information')

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

Re: [Pythoncard-users] more on keyPress handler for uppercase

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

On Apr 15, 2004, at 10:39 AM, ralph heimburger wrote:

> Forgive my lack of extensive pythonic knowledge but wouldn't a tr work 
> better?
>
> Would I have to create a separate event for all 66 fields?
>
What's a tr? If you want a single keyPress handler to deal with all 
fields then just remove the field name from the event handler.

def on_keyPress(self, event):

The caveat is that any component that generates a keyPress event and 
doesn't have its own specific event handler will use that method (e.g. 
a ComboBox). So, the first thing you would want to do in the handler is 
check the component type or name or something that tells you that you 
have the right component and if not, just call event.skip()

ka

Re: [Pythoncard-users] more on keyPress handler for uppercase

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

Forgive my lack of extensive pythonic knowledge but wouldn't a tr work better?

Would I have to create a separate event for all 66 fields?

--- "Kevin Altis" <al...@se...> wrote:
> From: Kevin Altis
>
> On Apr 15, 2004, at 8:06 AM, Schollnick, Benjamin wrote:
>
> >
> >> Since you have control over what goes in the field within
> >> your own code,
> >> keyPress is probably the easiest since it would just deal
> >> with what a user
> >> types.
> >>
> >> Given a TextField named 'fld' the following event handler
> >> should do what you
> >> want for plain ascii as well as unicode strings
> >>
> >>     def on_fld_keyPress(self, event):
> >>         upper = chr(event.keyCode).upper()
> >>         if chr(event.keyCode) != upper:
> >>             event.target.replaceSelection(upper)
> >>         else:
> >>             event.skip()

Well I have egg on my face now. So much for writing and testing code before
I have my morning coffee. I thought I had tested arrow keys, but I guess not
since chr() will throw a value error for keyCodes outside the range 0-255.
At a minimum you need to catch that exception.

    def on_field1_keyPress(self, event):
        try:
            upper = chr(event.keyCode).upper()
            if chr(event.keyCode) != upper:
                event.target.replaceSelection(upper)
            else:
                event.skip()
        except ValueError:
            event.skip()

However, now that I think about it more I don't see how this is going to
deal with Unicode characters outside the ASCII range. It might be simpler to
check whether the keyCode is in the wxWidgets defined key codes to see if it
is a special character. Sadly, I don't know enough about Unicode to take
this much further. Maybe someone else can chime in with the solution to deal
with non-ASCII.

ka



-------------------------------------------------------
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=1470&alloc_id=3638&op=click
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users


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

[Pythoncard-users] more on keyPress handler for uppercase

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

> From: Kevin Altis
>
> On Apr 15, 2004, at 8:06 AM, Schollnick, Benjamin wrote:
>
> >
> >> Since you have control over what goes in the field within
> >> your own code,
> >> keyPress is probably the easiest since it would just deal
> >> with what a user
> >> types.
> >>
> >> Given a TextField named 'fld' the following event handler
> >> should do what you
> >> want for plain ascii as well as unicode strings
> >>
> >>     def on_fld_keyPress(self, event):
> >>         upper = chr(event.keyCode).upper()
> >>         if chr(event.keyCode) != upper:
> >>             event.target.replaceSelection(upper)
> >>         else:
> >>             event.skip()

Well I have egg on my face now. So much for writing and testing code before
I have my morning coffee. I thought I had tested arrow keys, but I guess not
since chr() will throw a value error for keyCodes outside the range 0-255.
At a minimum you need to catch that exception.

    def on_field1_keyPress(self, event):
        try:
            upper = chr(event.keyCode).upper()
            if chr(event.keyCode) != upper:
                event.target.replaceSelection(upper)
            else:
                event.skip()
        except ValueError:
            event.skip()

However, now that I think about it more I don't see how this is going to
deal with Unicode characters outside the ASCII range. It might be simpler to
check whether the keyCode is in the wxWidgets defined key codes to see if it
is a special character. Sadly, I don't know enough about Unicode to take
this much further. Maybe someone else can chime in with the solution to deal
with non-ASCII.

ka

RE: [Pythoncard-users] making components less restrictive about attributes

[Steve H. <sh...@ho...>]

[Kevin]
> > From: ralph heimburger
> >
> > Speaking of attributes, TextField esp. is there a way to force
> > the field to be UPPERCASE?
> >
> > In DataFlex all we needed to do was add {CAPSLOCK} to the
> entry field.
>
> There is no attribute for the TextField to force text to be
> UPPERCASE. If
> you need that capability a lot you would probably be best off
> creating a
> subclass of the TextField component to give you that
> functionality. Is this
> a capability a lot of people need for dealing with databases?
>
I'd say it's much more usual simply to convert mixed-case inputs to all
upper after input if all upper is a database requirement.

[how to force upper-case ...]
>
> Finally, if you just want to make sure the text is uppercase
> before you plug
> it into a database or wherever you're going to use the text,
> you can do the
> upper() conversion in your code (e.g.
> self.components.fld.text.upper() ) and
> not worry about what the user sees.
>
Yup.

regards
 Steve

Re: [Pythoncard-users] making components less restrictive about a ttributes

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

On Apr 15, 2004, at 8:06 AM, Schollnick, Benjamin wrote:

>
>> Since you have control over what goes in the field within
>> your own code,
>> keyPress is probably the easiest since it would just deal
>> with what a user
>> types.
>>
>> Given a TextField named 'fld' the following event handler
>> should do what you
>> want for plain ascii as well as unicode strings
>>
>>     def on_fld_keyPress(self, event):
>>         upper = chr(event.keyCode).upper()
>>         if chr(event.keyCode) != upper:
>>             event.target.replaceSelection(upper)
>>         else:
>>             event.skip()
>
> Why even check to see the keycode is uppercase?
> Is there really that much latency with the uppercase
> function?  Yet, do we care if it was already uppercase?
> Uppercasing a uppercase letter results in a uppercase
> letter....
>
> Since the desire is for the result to be uppercase,
> there is two ways to approach this.
>
> At data entry, which is what you presented...
> Here's my alteration of your code:
>
>      def on_fld_keyPress(self, event):
> 	"""Force the results from the keypress to be uppercase.
> 	"""
>          event.target.replaceSelection( chr(event.keyCode).upper() )

Did you actually test this code? If you did then you should have gotten 
some errors when you used the arrow keys, backspace characters would 
have been inserted into the text, etc. So yes, there is a reason for 
the check and in order to deal with ASCII as well as Unicode, the the 
logic I chose is a simple solution. There could be other boundary 
conditions that will break it, I didn't do extensive testing or try it 
with a unicode build of wxPython, but I'm pretty sure it is correct.

> Or alternatively, when the entry is done and the user moves to the next
> field, just do a .upper() on the text string as you leave the field.

You can do that easily with a closeField handler, which only occurs 
when the contents of a field have been changed.

> I would suggest that as a standard pythoncard option, that the field be
> untouched, or made uppercase, lowercase or normal after leaving the 
> field.
> The logic for that should only be a few lines of code, but would be 
> quite
> helpful...
>
I don't see the benefit to this for the standard field. I would like to 
have a masked input field sometime and/or validated field which can 
automatically deal with various transformations and restricted input, 
but due to the extra complexity of such a component I see that as 
something separate from a simple TextField.

ka

RE: [Pythoncard-users] making components less restrictive about a ttributes

[Schollnick, B. <Ben...@us...>]

> Since you have control over what goes in the field within 
> your own code,
> keyPress is probably the easiest since it would just deal 
> with what a user
> types.
> 
> Given a TextField named 'fld' the following event handler 
> should do what you
> want for plain ascii as well as unicode strings
> 
>     def on_fld_keyPress(self, event):
>         upper = chr(event.keyCode).upper()
>         if chr(event.keyCode) != upper:
>             event.target.replaceSelection(upper)
>         else:
>             event.skip()

Why even check to see the keycode is uppercase?
Is there really that much latency with the uppercase
function?  Yet, do we care if it was already uppercase?
Uppercasing a uppercase letter results in a uppercase
letter....

Since the desire is for the result to be uppercase,
there is two ways to approach this.

At data entry, which is what you presented...
Here's my alteration of your code:

     def on_fld_keyPress(self, event):
	"""Force the results from the keypress to be uppercase.
	"""
         event.target.replaceSelection( chr(event.keyCode).upper() )

Or alternatively, when the entry is done and the user moves to the next
field, just do a .upper() on the text string as you leave the field.

I would suggest that as a standard pythoncard option, that the field be
untouched, or made uppercase, lowercase or normal after leaving the field.
The logic for that should only be a few lines of code, but would be quite
helpful...

		- Benjamin

RE: [Pythoncard-users] making components less restrictive about attributes

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

> From: ralph heimburger
>
> Speaking of attributes, TextField esp. is there a way to force
> the field to be UPPERCASE?
>
> In DataFlex all we needed to do was add {CAPSLOCK} to the entry field.

There is no attribute for the TextField to force text to be UPPERCASE. If
you need that capability a lot you would probably be best off creating a
subclass of the TextField component to give you that functionality. Is this
a capability a lot of people need for dealing with databases?

However, it is easy to force text to be uppercase with event handlers. There
are two events worth investigating, textUpdate which is received every time
the text in a field changes and keyPress which occurs as the user is typing.
Since you have control over what goes in the field within your own code,
keyPress is probably the easiest since it would just deal with what a user
types.

Given a TextField named 'fld' the following event handler should do what you
want for plain ascii as well as unicode strings

    def on_fld_keyPress(self, event):
        upper = chr(event.keyCode).upper()
        if chr(event.keyCode) != upper:
            event.target.replaceSelection(upper)
        else:
            event.skip()

The textUpdate solution is a bit more complex since we need to keep track of
the selection as well. Since changing the text in the middle of the
textUpdate event will cause another text update event, you have to have a
check like the one below to avoid a recursion problem. On Linux/GTK you
might also have to save and restore the insertion point as well as the
selection, but I can't test that from here.

    def on_fld_textUpdate(self, event):
        text = event.target.text
        upper = text.upper()
        if text != upper:
            start, end = event.target.getSelection()
            event.target.text = upper
            event.target.setSelection(start, end)
        else:
            event.skip()

Finally, if you just want to make sure the text is uppercase before you plug
it into a database or wherever you're going to use the text, you can do the
upper() conversion in your code (e.g. self.components.fld.text.upper() ) and
not worry about what the user sees.

ka

RE: [Pythoncard-users] making components less restrictive about attributes

[Steve H. <sh...@ho...>]

[Kevin]
> PythonCard components in the past have been restrictive about
> attributes, that is an attribute had to be pre-defined, otherwise an
> AttributeError would be thrown at runtime if you tried to use an
> attribute that didn't already exist. For example, given a TextField
> named 'fld',
>
> self.components.fld.txt = 'hello'
>
> would generate a runtime error. If you make a typo (e.g. txt
> instead of
> text), then this can help uncover errors in your program, but it is
> also more restrictive than a normal Python class where attributes can
> be added on the fly. If field1 was a normal Python object, the code
> above would not generate an error. Note that unless fld.txt
> was defined
> earlier, then something like
>
> print self.components.fld.txt
>
> would still generate an error even without restrictive
> attributes since
> txt isn't defined.
>
Right. It's a nice catch to trap the assignment, though.

> Anyway, we've been pulling off the restrictive attributes through the
> use of __getattr__ and __setattr__; some or all of that
> behavior might
> be doable now with slots. Only Font, Widget (base class for
> components), and StatusBar in release 0.7.3.1 are
> restrictive. If we're
> going to continue this type of usage, then for consistency all the
> classes exposed to user code should probably be just as
> restrictive or
> perhaps only classes that are unlikely to be subclassed would be
> restrictive; having to pre-define attributes for Background
> would be a
> major pain.
>
By which I presume you wouldn't even want to define Background's
__slots__?

> I've argued back and forth with myself about the pros and cons and my
> recommendation is that we drop the use of __getattr__ and __setattr__
> and have PythonCard classes work like any other Python class.
> User code
> will be able to make typos that lead to errors, but even the largest
> PythonCard program is unlikely to be more than a few thousand
> lines of
> code, so tracking down that kind of bug shouldn't be that hard. In
> fact, since we'll still have component specs and tools like
> PyChecker,
> source checking can probably be automated. The framework code will be
> much simpler, especially since we'll be using the built-in Python
> property() to define attributes. It should be much simpler to wrap
> wxPython controls and subclass existing components too.
>
"Simple is better than complex"

> I already changed statusbar.py in the PythonCard branch of cvs to see
> how this change would impact some real code and Rowland and I plan to
> change widget.py and font.py sometime tomorrow. However,
> since this is
> Open Source I like to give people a chance to voice opinions even if
> they aren't doing the coding <wink>, so if you would like to
> argue for
> keeping the restrictive access, please do so ASAP.
>
> Thanks,
>
I want to be clear I'm not arguing for the restrictions to remain. But I
can't help wondering if a little discipline might allow you to define a
testing (restrictive) framework and a production ( relaxed) one? If
there's no easy way to do so, just go ahead and ditch the restrictions.

regards
--
Steve Holden                                 http://www.holdenweb.com/
ReportLab Enterprise Publishing Solutions    http://www.reportlab.com/
Chairman, PyCON DC 2004                          http://www.pycon.org/
Telephone: +1-800 494 3119                        Fax: +1 703 278 8289

Re: [Pythoncard-users] making components less restrictive about attributes

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

Speaking of attributes, TextField esp. is there a way to force the field to be UPPERCASE?

In DataFlex all we needed to do was add {CAPSLOCK} to the entry field.



--- "Kevin Altis" <al...@se...> wrote:
PythonCard components in the past have been restrictive about 
attributes, that is an attribute had to be pre-defined, otherwise an 
AttributeError would be thrown at runtime if you tried to use an 
attribute that didn't already exist. For example, given a TextField 
named 'fld',

self.components.fld.txt = 'hello'

would generate a runtime error. If you make a typo (e.g. txt instead of 
text), then this can help uncover errors in your program, but it is 
also more restrictive than a normal Python class where attributes can 
be added on the fly. If field1 was a normal Python object, the code 
above would not generate an error. Note that unless fld.txt was defined 
earlier, then something like

print self.components.fld.txt

would still generate an error even without restrictive attributes since 
txt isn't defined.

Anyway, we've been pulling off the restrictive attributes through the 
use of __getattr__ and __setattr__; some or all of that behavior might 
be doable now with slots. Only Font, Widget (base class for 
components), and StatusBar in release 0.7.3.1 are restrictive. If we're 
going to continue this type of usage, then for consistency all the 
classes exposed to user code should probably be just as restrictive or 
perhaps only classes that are unlikely to be subclassed would be 
restrictive; having to pre-define attributes for Background would be a 
major pain.

I've argued back and forth with myself about the pros and cons and my 
recommendation is that we drop the use of __getattr__ and __setattr__ 
and have PythonCard classes work like any other Python class. User code 
will be able to make typos that lead to errors, but even the largest 
PythonCard program is unlikely to be more than a few thousand lines of 
code, so tracking down that kind of bug shouldn't be that hard. In 
fact, since we'll still have component specs and tools like PyChecker, 
source checking can probably be automated. The framework code will be 
much simpler, especially since we'll be using the built-in Python 
property() to define attributes. It should be much simpler to wrap 
wxPython controls and subclass existing components too.

I already changed statusbar.py in the PythonCard branch of cvs to see 
how this change would impact some real code and Rowland and I plan to 
change widget.py and font.py sometime tomorrow. However, since this is 
Open Source I like to give people a chance to voice opinions even if 
they aren't doing the coding <wink>, so if you would like to argue for 
keeping the restrictive access, please do so ASAP.

Thanks,

ka



-------------------------------------------------------
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=1470&alloc_id=3638&op=click
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users


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

[Pythoncard-users] making components less restrictive about attributes

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

PythonCard components in the past have been restrictive about 
attributes, that is an attribute had to be pre-defined, otherwise an 
AttributeError would be thrown at runtime if you tried to use an 
attribute that didn't already exist. For example, given a TextField 
named 'fld',

self.components.fld.txt = 'hello'

would generate a runtime error. If you make a typo (e.g. txt instead of 
text), then this can help uncover errors in your program, but it is 
also more restrictive than a normal Python class where attributes can 
be added on the fly. If field1 was a normal Python object, the code 
above would not generate an error. Note that unless fld.txt was defined 
earlier, then something like

print self.components.fld.txt

would still generate an error even without restrictive attributes since 
txt isn't defined.

Anyway, we've been pulling off the restrictive attributes through the 
use of __getattr__ and __setattr__; some or all of that behavior might 
be doable now with slots. Only Font, Widget (base class for 
components), and StatusBar in release 0.7.3.1 are restrictive. If we're 
going to continue this type of usage, then for consistency all the 
classes exposed to user code should probably be just as restrictive or 
perhaps only classes that are unlikely to be subclassed would be 
restrictive; having to pre-define attributes for Background would be a 
major pain.

I've argued back and forth with myself about the pros and cons and my 
recommendation is that we drop the use of __getattr__ and __setattr__ 
and have PythonCard classes work like any other Python class. User code 
will be able to make typos that lead to errors, but even the largest 
PythonCard program is unlikely to be more than a few thousand lines of 
code, so tracking down that kind of bug shouldn't be that hard. In 
fact, since we'll still have component specs and tools like PyChecker, 
source checking can probably be automated. The framework code will be 
much simpler, especially since we'll be using the built-in Python 
property() to define attributes. It should be much simpler to wrap 
wxPython controls and subclass existing components too.

I already changed statusbar.py in the PythonCard branch of cvs to see 
how this change would impact some real code and Rowland and I plan to 
change widget.py and font.py sometime tomorrow. However, since this is 
Open Source I like to give people a chance to voice opinions even if 
they aren't doing the coding <wink>, so if you would like to argue for 
keeping the restrictive access, please do so ASAP.

Thanks,

ka

Re: [Pythoncard-users] Latest pythoncard release dependencies

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

On Apr 14, 2004, at 5:43 PM, Stephen Boulet wrote:

> On Wednesday 14 April 2004 12:49 pm, Kevin Altis wrote:
>> 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
>
> Ok, I submitted an ebuild (build script) for the Gentoo distribution.
> Hopefully it will get added soon.
>
>   http://bugs.gentoo.org/show_bug.cgi?id=47864
>

Thanks. Since I don't run Gentoo myself yet, it is hard for me to know 
if the script is complete. Hopefully, all the docs, samples, and tools 
get included. The LICENSE field should read BSD; yes I know we need to 
update our home page. :)

ka

Re: [Pythoncard-users] Latest pythoncard release dependencies

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

On Wednesday 14 April 2004 12:49 pm, Kevin Altis wrote:
> 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

Ok, I submitted an ebuild (build script) for the Gentoo distribution. 
Hopefully it will get added soon.

  http://bugs.gentoo.org/show_bug.cgi?id=47864

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

Re: [Pythoncard-users] SQLDict

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

On Apr 14, 2004, at 11:05 AM, Andy Todd wrote:

> ralph heimburger wrote:
>> Has anyone used SQLDict module with MYSql/PythonCard?
>> I am looking for an easy to use interface for SQL Interface.
>> _____________________________________________________________
>>
>
> I'm using SQL Object on a couple of different modules, one of which 
> has a PythonCard front end.
>
> I can't recommend it highly enough, for my money it is the best (and 
> most Pythonic) object-relational mapper available today. If you are an 
> OO programmer you don't have to worry about persisting your value 
> objects because SQL Object will take of it for you. If you want to 
> leverage more power from your database then it supports 'proper' 
> relational concepts as well.
>
I hereby volunteer Andy to write at least one article about using 
PythonCard with databases :)

ka

Re: [Pythoncard-users] SQLDict

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

ralph heimburger wrote:
> Has anyone used SQLDict module with MYSql/PythonCard?
> 
> I am looking for an easy to use interface for SQL Interface.
> 
> _____________________________________________________________
>  

I'm using SQL Object on a couple of different modules, one of which has 
a PythonCard front end.

I can't recommend it highly enough, for my money it is the best (and 
most Pythonic) object-relational mapper available today. If you are an 
OO programmer you don't have to worry about persisting your value 
objects because SQL Object will take of it for you. If you want to 
leverage more power from your database then it supports 'proper' 
relational concepts as well.

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