Menu
▾
▴
[Pythoncard-users] Re: Pythoncard-users digest, Vol 1 #797 - 7 msgs
|
From: jamesr <cir...@gm...> - 2004-09-14 03:03:49
|
To adress the questions on the mailing list, i have already developed what i call the 'AdvancedEventFramework' that allows for tabbed interfaces, as well as the dynamic growing and shrinking of windows to accomodate them, if needed. I have myself and possibly a friend helping. It makes the creation of larger pycard program very painless, and i would like it to be considered as a contribution to the project. Since the capabilities it offers are extremely flexible (i have already begun development of a 'visual python' using it), i would like to see it's incorporation spark development along those lines. i have been using it for every program i have written for pycard since it's creation. I am wondering how or in what context i could introduce this? I am sincerely motivated and impressed by pycard, James. On Mon, 13 Sep 2004 15:09:14 -0700, pyt...@li... <pyt...@li...> wrote: > Send Pythoncard-users mailing list submissions to > pyt...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > or, via email, send a message with subject or body 'help' to > pyt...@li... > > You can reach the person managing the list at > pyt...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythoncard-users digest..." > > Today's Topics: > > 1. Re: [Pythonmac-SIG] quicktime info? (Arthur Elsenaar) > 2. Re: PythonCard suitability for a project; looking for > opinions (bra...@om...) > 3. Re: PythonCard suitability for a project; looking for opinions (Kevin Altis) > 4. generic container model (Donnal Walter) > 5. Re: generic container model (Alex Tweedly) > 6. Re: PythonCard suitability for a project; looking for opinions (normanwinn) > > --__--__-- > > Message: 1 > From: Arthur Elsenaar <ar...@ia...> > Date: Mon, 13 Sep 2004 19:36:34 +0200 > To: pyt...@li... > Subject: [Pythoncard-users] Re: [Pythonmac-SIG] quicktime info? > > On Sep 13, 2004, at 18:08, Kevin Altis wrote: > > >>> looked around the archives and documentation, but can't find > >>> information on how to use some very limited quicktime functionality. > >>> > >>> The main functionality I need are the movieplayer to load a sound > >>> file, duration and position information. > >>> > >>> I like to add this an existing pythoncard application, so I suspect > >>> a PyObjC solution is out the door? > >> > >> Well, I'm in the process of developing wxQtMovie for wxPython, which > >> should already do what you need. (There's also wxSound, though I > >> don't think you can get duration or position information with it.) > >> Since pythoncard uses wxPython underneath, I think all that's needed > >> is for Kevin A. to make the class accessible from pythoncard itself. > >> I'm forwarding this to wxPython developer's list so that we can > >> discuss this further and work out a solution. > >> > > PythonCard already wraps wx.Sound with its own Sound class in > > PythonCard/sound.py that is demonstrated by the sound sample > > application. There is another sample application, mp3player that uses > > the PyGame movie module to play MP3 files and the PyGame movie module > > definitely lets you do all the positional manipulation for MPEG. On > > the QuickTime front, as soon as Kevin O.'s module is part of the > > general wxPython distribution I will make a wrapper component for it, > > so maybe wxPython 2.5.2.9? > > yes, I tried the mp3player example, but diverted to using pygame.mixer > as I need more channels and .wav and .aif support. I have this working, > but sound.get_length() gives an attribute error.. (mailed the issue to > the pygame list). So when Kevin O. will have quicktime working in wx, > that would be perfect for my app -> can we test this? > > Anyway, here's the relevant -commented out- code from the mp3player, > but that works fine for me. > > ## NOTE WE DON'T IMPORT PYGAME UNTIL NOW. Don't put "import > pygame" at the top of the file. > import pygame > self.movie = pygame.movie.Movie(filename) > self.movie.play() > > # it was a good idea at first, but mixer simply doesn't work, > at least on the Mac > ## assert os.path.exists(filename) > ## from pygame import mixer > ## mixer.init(44100, 2) > ## mixer.music.load(filename) > ## mixer.music.play() > ## print mixer.music.get_busy() > ## #time.sleep(5) > ## #mixer.music.stop() > > Why do you say in the first line pygame shouldn't be imported at an > earlier stage in the code? > > Arthur > > --__--__-- > > Message: 2 > To: pyt...@li... > Cc: Brad Allen <bra...@ma...>, > Walker Hale <wa...@ma...> > Subject: Re: [Pythoncard-users] PythonCard suitability for a project; looking for > opinions > From: bra...@om... > Date: Mon, 13 Sep 2004 13:57:05 -0500 > > This is a multipart message in MIME format. > --=_alternative 00681A5786256F0E_= > Content-Type: text/plain; charset="US-ASCII" > > Steven D'Aprano <st...@cy...> wrote on 09/13/2004 05:45:35 AM: > > > On Sat, Sep 11, 2004 at 12:59:14PM -0500, Brad Allen wrote: > > > > > Here is the first question: Am I crazy for considering PythonCard for > > > use in a production environment? PythonCard is obviously not yet > > > mature, and still has many gaps in the feature set, not to mention > > > bugs. On the plus side, it seems to me that when users report bugs on > > > this mailing list, they are generally identified quickly and fixed. > > > It also seems to me that if we run into problems or gaps in the > > > PythonCard feature set, we can fall back on the more mature wxPython, > > > and so have a mix of wxPython and PythonCard in our GUI logic. Also, > > > because PythonCard is open source, we can look under the hood figure > > > out what's wrong if we need to. Is this a fair assessment? > > > > It sounds like you've already answered your own question. Perhaps you > are > > looking for something that you can take to your bosses and show them a > > "real" [cough] application, something with grunt. > > Well, FileMaker was ok when our needs were simpler, but it didn't scale > well as our application grew in complexity. FileMaker 7 addresses some of > these issues, but we'd be looking at a complete rewrite. Meanwhile, most > of the other company databases are on SQL Server, so it makes sense to > move in that direction. And, yes, Python has a lot more "grunt" than > FileMaker. > > > Perhaps not quite Microsoft Office written in PythonCard, but something > > like MYOB or Quickbooks? > > This is a custom in-house application; it won't have the sophistication of > a commercial app, but it does need to be stable and have a streamlined > user interface to allow users to work quickly (web interfaces are too slow > and limited, and don't have access to the local filesystem on Macs). > > > > Second question: Do you see PythonCard as primarily a tool for > > > building GUIs for small, simple apps, or do you think it will scale > > > well to more complex apps, in terms of managing that complexity ? > > > The app I'm imagining will require many windows, many dialog boxes, > > > dynamically changing global menus, contextual menus, keyboard > > > shortcuts (including function keys), and validation for data entry > > > fields. It would also be nice but not required to have search results > > > that populate as the user types, layouts changing within a given > > > window, tab order between fields, drag & drop of files onto fields to > > > populate paths, user-draggable icon objects, and tabbed interface in > > > some windows. > > > > That sounds less like a question about PythonCard itself and more like a > > > question about your ability to design and manage the GUI. Unless I'm > badly > > mistaken, PythonCard can provide all of those interface objects. > > Good; that's what I was hoping to hear. Over the past couple of days, I've > found ways to do some of those things, though I didn't see a widget for a > tabbed interface in Resource Editor, and am not clear on how to produce a > contextual menu. > > > Can PythonCard talk to your database (assuming you have one)? Knock up a > > > quick test to see. If it fails, again you've saved yourself a lot of > time. > > I'm not concerned about PythonCard connecting to the database; that's a > job for Python itself. > > > The idea is, before you commit to 1000 man-hours to build the > application, > > commit to 30 hours to build a few test apps and run some benchmarks. > > I will do as you advise, and build a test application; thanks! > > --=_alternative 00681A5786256F0E_= > Content-Type: text/html; charset="US-ASCII" > > <br><font size=2><tt>Steven D'Aprano <st...@cy...> wrote on > 09/13/2004 05:45:35 AM:<br> > <br> > > On Sat, Sep 11, 2004 at 12:59:14PM -0500, Brad Allen wrote:<br> > > <br> > > > Here is the first question: Am I crazy for considering PythonCard > for <br> > > > use in a production environment? PythonCard is obviously not > yet <br> > > > mature, and still has many gaps in the feature set, not to mention > <br> > > > bugs. On the plus side, it seems to me that when users report > bugs on <br> > > > this mailing list, they are generally identified quickly and > fixed. <br> > > > It also seems to me that if we run into problems or gaps in the > <br> > > > PythonCard feature set, we can fall back on the more mature wxPython, > <br> > > > and so have a mix of wxPython and PythonCard in our GUI logic. > Also, <br> > > > because PythonCard is open source, we can look under the hood > figure <br> > > > out what's wrong if we need to. Is this a fair assessment?<br> > > <br> > > It sounds like you've already answered your own question. Perhaps > you are <br> > > looking for something that you can take to your bosses and show them > a <br> > > "real" [cough] application, something with grunt.<br> > </tt></font> > <br><font size=2><tt>Well, FileMaker was ok when our needs were simpler, > but it didn't scale well as our application grew in complexity. FileMaker > 7 addresses some of these issues, but we'd be looking at a complete rewrite. > Meanwhile, most of the other company databases are on SQL Server, so it > makes sense to move in that direction. And, yes, Python has a lot more > "grunt" than FileMaker. </tt></font> > <br><font size=2><tt><br> > > Perhaps not quite Microsoft Office written in PythonCard, but something > <br> > > like MYOB or Quickbooks?<br> > </tt></font> > <br><font size=2><tt>This is a custom in-house application; it won't have > the sophistication of a commercial app, but it does need to be stable and > have a streamlined user interface to allow users to work quickly (web interfaces > are too slow and limited, and don't have access to the local filesystem > on Macs).</tt></font> > <br><font size=2><tt><br> > > > Second question: Do you see PythonCard as primarily a tool for > <br> > > > building GUIs for small, simple apps, or do you think it will > scale <br> > > > well to more complex apps, in terms of managing that complexity > ? <br> > > > The app I'm imagining will require many windows, many dialog > boxes, <br> > > > dynamically changing global menus, contextual menus, keyboard > <br> > > > shortcuts (including function keys), and validation for data > entry <br> > > > fields. It would also be nice but not required to have search > results <br> > > > that populate as the user types, layouts changing within a given > <br> > > > window, tab order between fields, drag & drop of files onto > fields to <br> > > > populate paths, user-draggable icon objects, and tabbed interface > in <br> > > > some windows.<br> > > <br> > > That sounds less like a question about PythonCard itself and more > like a <br> > > question about your ability to design and manage the GUI. Unless I'm > badly <br> > > mistaken, PythonCard can provide all of those interface objects.<br> > </tt></font> > <br><font size=2><tt>Good; that's what I was hoping to hear. Over the past > couple of days, I've found ways to do some of those things, though I didn't > see a widget for a tabbed interface in Resource Editor, and am not clear > on how to produce a contextual menu.</tt></font> > <br><font size=2><tt><br> > > Can PythonCard talk to your database (assuming you have one)? Knock > up a <br> > > quick test to see. If it fails, again you've saved yourself a lot > of time.<br> > </tt></font> > <br><font size=2><tt>I'm not concerned about PythonCard connecting to the > database; that's a job for Python itself.</tt></font> > <br><font size=2><tt><br> > > The idea is, before you commit to 1000 man-hours to build the application, > <br> > > commit to 30 hours to build a few test apps and run some benchmarks.<br> > </tt></font> > <br><font size=2><tt>I will do as you advise, and build a test application; > thanks! </tt></font> > <br> > <br><font size=2><tt><br> > </tt></font> > <br> > --=_alternative 00681A5786256F0E_=-- > > --__--__-- > > Message: 3 > Date: Mon, 13 Sep 2004 13:04:17 -0700 > From: "Kevin Altis" <al...@se...> > To: bra...@om... > Cc: "Walker Hale" <wa...@ma...>, pyt...@li..., > "Brad Allen" <bra...@ma...> > Subject: Re: [Pythoncard-users] PythonCard suitability for a project; looking for opinions > > --Apple-Mail-7-834540175 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > On Sep 13, 2004, at 11:57 AM, bra...@om... wrote: > > > Good; that's what I was hoping to hear. Over the past couple of days, > > I've found ways to do some of those things, though I didn't see a > > widget for a tabbed interface in Resource Editor, and am not clear on > > how to produce a contextual menu. > > > There is no built-in support for the wx.Notebook class right now, which > is what you would use to do a real tabbed interface. This is mostly due > to PythonCard having a "flat" layout model rather than supporting a > generic container model where you could have a different layout in each > notebook tab/page. This has been discussed a number of times on the > mailing list and is obviously a big missing feature, but I don't really > know how to support it correctly. There was one attempt to incorporate > this into the framework and resourceEditor, but it was never > incorporated into the main cvs code or updated for release 0.8. > > It is probably time for a separate discussion thread on the issues and > possible solutions such as treating each page as a type of child window > where only the components of the child window resource are used. I'm > just brainstorming here. You would end up with a separate source and > resource file for each tab/page. I guess the references to each tab > layout would end up being something like > self.components.notebook[0].components.field1, etc. where each page > (window) of the notebook is referenced via a list. > > You'll also need to do the context (popup) menu yourself. For that you > just create a wx.Menu in a on_somecomponent_mouseContextUp event > handler or mouseContextClick in the case of a MultiColumnList. If you > look at the fpop.py code in cvs you'll see an example of this > > http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/samples/ > fpop/fpop.py > > The relevant methods are initContextMenu and > on_mclHeaders_mouseContextClick. fpop is not included as part of the > normal PythonCard releases because it is too rough to allow out in the > wild and people could end up deleting email accidentally. > > ka > > --Apple-Mail-7-834540175 > Content-Transfer-Encoding: 7bit > Content-Type: text/enriched; > charset=US-ASCII > > On Sep 13, 2004, at 11:57 AM, bra...@om... wrote: > > <excerpt><fixed><smaller>Good; that's what I was hoping to hear. Over > the past couple of days, I've found ways to do some of those things, > though I didn't see a widget for a tabbed interface in Resource > Editor, and am not clear on how to produce a contextual > menu.</smaller></fixed> > > </excerpt>There is no built-in support for the wx.Notebook class right > now, which is what you would use to do a real tabbed interface. This > is mostly due to PythonCard having a "flat" layout model rather than > supporting a generic container model where you could have a different > layout in each notebook tab/page. This has been discussed a number of > times on the mailing list and is obviously a big missing feature, but > I don't really know how to support it correctly. There was one attempt > to incorporate this into the framework and resourceEditor, but it was > never incorporated into the main cvs code or updated for release 0.8. > > It is probably time for a separate discussion thread on the issues and > possible solutions such as treating each page as a type of child > window where only the components of the child window resource are > used. I'm just brainstorming here. You would end up with a separate > source and resource file for each tab/page. I guess the references to > each tab layout would end up being something like > self.components.notebook[0].components.field1, etc. where each page > (window) of the notebook is referenced via a list. > > You'll also need to do the context (popup) menu yourself. For that you > just create a wx.Menu in a on_somecomponent_mouseContextUp event > handler or mouseContextClick in the case of a MultiColumnList. If you > look at the fpop.py code in cvs you'll see an example of this > > http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/samples/fpop/fpop.py > > The relevant methods are initContextMenu and > on_mclHeaders_mouseContextClick. fpop is not included as part of the > normal PythonCard releases because it is too rough to allow out in the > wild and people could end up deleting email accidentally. > > ka > > --Apple-Mail-7-834540175-- > > --__--__-- > > Message: 4 > Date: Mon, 13 Sep 2004 13:47:18 -0700 (PDT) > From: Donnal Walter <don...@ya...> > To: pyt...@li... > Cc: Kevin Altis <al...@se...> > Subject: [Pythoncard-users] generic container model > > Kevin Altis" <al...@se...> > > There is no built-in support for the wx.Notebook class > > right now, which is what you would use to do a real tabbed > > interface. This is mostly due to PythonCard having a "flat" > > layout model rather than supporting a generic container > > model ... > > <delurking> > Aha! A critical insight. If I understand correctly this "flat" > model also explains (at least in part) why sizers are problematic > to implement in the framework. Ideally, each container should have > a built-in sizer to which components are automatically added as > they are added to the container. The kind of sizer should be > determined by the container, and the parameters for each component > should be passed like 'size' and 'pos' are now. (Another useful > parameter for each component would be a data model from some kind > of abstraction layer.) > > > ... where you could have a different layout in each notebook > > tab/page. This has been discussed a number of times on the > > mailing list and is obviously a big missing feature, but I > > don't really know how to support it correctly. There was one > > attempt to incorporate this into the framework and > > resourceEditor, but it was never incorporated into the main > > cvs code or updated for release 0.8. > > > > It is probably time for a separate discussion thread on the > > issues and possible solutions such as treating each page as > > a type of child window where only the components of the child > > window resource are used. I'm just brainstorming here. ... > > Brainstorming further, I would suggest that for PythonCard *2.0* a > class-based rather than an instance-based framework be considered. > Each container would be defined as a *class* (with an appropriate > resource-file notation, something other than a dictionary), such > that multiple instances could be created if so desired. In either > case, however, as the class is instantiated (initialized) the > parent-child relationships are established as well as sizer > relationships. > > > ... You would end up with a separate source and resource file > > for each tab/page. I guess the references to each tab layout > > would end up being something like > > self.components.notebook[0].components.field1, etc. where > > each page (window) of the notebook is referenced via a list. > > In a class-based framework, the top-level resource file would > import component resource files as they are needed. Just a thought. > </delurking> > > Regards, > Donnal Walter > Arkansas Children's Hospital > > --__--__-- > > Message: 5 > Date: Mon, 13 Sep 2004 22:40:47 +0100 > To: Donnal Walter <don...@ya...>, > pyt...@li... > From: Alex Tweedly <al...@tw...> > Subject: Re: [Pythoncard-users] generic container model > Cc: Kevin Altis <al...@se...> > > --=======45E481F======= > Content-Type: text/plain; x-avg-checked=avg-ok-444150A3; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 8bit > > At 13:47 13/09/2004 -0700, Donnal Walter wrote: > ><delurking> > >Aha! A critical insight. If I understand correctly this "flat" > >model also explains (at least in part) why sizers are problematic > >to implement in the framework. Ideally, each container should have > >a built-in sizer to which components are automatically added as > >they are added to the container. The kind of sizer should be > >determined by the container, and the parameters for each component > >should be passed like 'size' and 'pos' are now. > > If PythonCard had a non-flat model, then it would be easier to change it to > have explicit containers (each being a sizer of one kind or another). > > But I think there's a more fundamental problem: it would require a > different approach to laying out your GUI. Using sizers kind of requires > that you have a plan for the layout of controls, and can then describe a > hierarchy of sizers and place controls within them. This is, I think, > rather contrary to the freedom that PythonCard gives you to rapidly > prototype and play with different controls and arrangements of them. > > There's certainly a contradiction between the idea that you "place" > controls (as in Pythoncard) versus "arrange the order and relative > position" of controls, and let sizers shuffle them into their final (but > dynamic) positions. > > I've been playing around with sizers in Pythoncard; I've built a couple of > "auto-sizer" functions that take a component layout as found in a resource > file, and generate a reasonable first-cut at arranging those into sizers. > > Basic idea is that it should take the component positions (and use some > default assumptions about different components) to build a default set of > sizers. This can be aided by some "hints" added to the component data > (currently using "custom data" in the components, but if the idea ever gets > anywhere, it might be possible to add something to the resource editor to > support this more directly) to guide its actions. The auto-sizer can then > either just operate, or it can spit out the source code that will make > equivalent simple sizer calls, and can therefore be the starting point for > custom programming. > > I was feeling quite optimistic about it a couple of weeks ago - and then > got side-tracked. I'll work on it a bit more, and if I can come up with > something that works well enough, and is easy to explain, I'll make it > available to anyone who wants to play around with sizers. > > -- Alex. > > --=======45E481F=======-- > > --__--__-- > > Message: 6 > Date: Tue, 14 Sep 2004 00:08:43 +0200 > From: normanwinn <nor...@on...> > Reply-To: nor...@on... > To: pyt...@li... > Subject: [Pythoncard-users] Re: PythonCard suitability for a project; looking for opinions > > Kevin Altis asked: > > >In particular, I would like to > >hear about features that products like FileMaker Pro provide that are > >needed for an OS tool that users could transition to without feeling > >like they are taking a step backwards. > > > > I'd like to start more positively. My major client would forgive a great > deal if he got more speed. And I'm pretty sure he will get it if I go > down this, the Python/PythonCard, road. I start with this comment as > much of what Filemaker does is probably not worth reproducing providing > the user experience in the new environment is perceived as positive. > > Filemaker 7 has just come out and it is much slower than version 6. On > moving to OS X we already took a speed hit so, in the four years I have > been working on this thing, instead of hardware improvements making > things slick it has all got slower. On top of this, FM7 requires > relearning much of what one has done + obliges a rewrite. Hence the > reason my search is on. > > I looked at many possibilities, some commercial, some open source. The > reasons my quest has brought me here are: > > 1) I liked python from the moment I started to play with it. > 2) one of the wx demos (then on OS X - now working mainly on a PC) > showed some really rapid responsiveness to events. > > Here is what Filemaker gives: > > No need to define field lengths for any type of field. This seems > trivial but gives an amazing freedom in database design. > > Pretty maintenance free. Most sites have no database expert. I have > never lost data (have come pretty close). However, no rollback. > > Almost transparently cross platform - some font and printing issues. But > client (as opposed to FM Server) not available on Linux. This latter is > political as, now that the Mac is Unix based, doing the port would > involve little work. > > No connection hassles. FM mixes data, scripts, layouts and stuff all in > one file per database (in FM7 this become per table). > > An integrated form designer that, being designed for the purpose of > databases, is pretty easy to use. > Same tool is used to design reports. > > A relationship model that makes one to one, one to many, many to many, > many to one relationships pretty easy to get a grasp of. (At least > that's how it seems now, looking back). > > Where SQL would use scripts (I believe) to select a group of records, FM > frequently uses calculation fields as part of the relationship. > > Calculations can appear in scripts as well as field definitions. These > make great use of an extensive set of 'Status' functions. > > FM is responsive to what is showing on the screen. If you haven't seen > this it needs some explanation. If you go to a layout that contains > references to another file(file = table in version < 7) then that file > gets opened. If you open that layout in a small window only what is > showing and referenced gets opened. > > Pretty neat pop-up lists that can be up to 64k characters (much more in > v7). On clicking in a field that has a pop-up the list becomes live to > the keyboard i.e. typing 'be' takes one to entries beginning with 'be'. > These lists can be based on > a) custom values > b) a value list from another file > c) the values from a field > d) the values from a field via a relationship. > One pretty neat thing here is that a relationship can be defined from > virtually anywhere - deep withing the creation of a value list or during > field definition or script creation. > > However, there is no inbuilt type-ahead searching. > > What is horrible and nasty: > > No event based scripting. > > No automated field or layout creation. Nothing of this type can be done > on the fly. > > Can't get at the controls when some speed tweaks are needed. > > Incremental back ups are difficult to implement. Built in back up method > can be slow as much more than the raw data is getting backed up. Can > export fields and specify just data fields. Problem is that this process > cannot be dynamically scripted. > > Wide area network performance is lamentable as, at start up, the whole > caboodle has to be dragged over the wires before anything happens. (This > is another one that would lead my client to accept re-learning an interface) > > Every user has to have a full copy of FM - form designer, script maker > et al included. This is expensive and adds unnecessary security risks > (there is a so-called kiosk version but these are not net workable). > > Limited ability to produce dynamic dialogues. > > Poor documentation once above novice level. Poor response to bugs and > queries from FM, the company. (Happily, there are a couple of good lists). > > Can't save or access scripts as text so can't cut and past chunks. > > Until v7, no application wide globals, no parameters for scripts (a > nightmare). > > Oh, I forgot - no variables. Filemaker uses what it call 'global fields' > for this. A real pain. > > No regular expression searches. No wildcards. > > __________________- > > Apologies if I have been too detailed or not enough. > > With all those downers some of you must be wondering why there is > hesitation. It is worth noting that most Filemaker developers are doing > quite nicely. FM, once mainly a Mac thing, now has 80% of new sales on > Windows. And sales are (or at least, were, up till v7) growing fast. > Many of these new users are tempted in by the ease with which > rudimentary databases can be produced. They then come searching for guys > like me when things get more complicated (as they inevitably do), > > Norman Winn > > --__--__-- > > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users > > End of Pythoncard-users Digest > |
