pythoncard-users Mailing List for PythonCard (Page 174)

Okay. Well, I got that "rule" out of Jim Fulton's paper:

"A persistent object must not implement __getattr__ or __setattr__ .
These special methods are already implemented by the persistence system.
Overriding them correctly, while possible, is extremely difficult."

At this point I'm talking about the current StandaloneZODB that is
available, not the ZODB in the Zope3 branch of CVS. So for StandaloneZODB
1.0, does this rule apply or not?

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: zod...@zo... [mailto:zod...@zo...]On Behalf
> Of Chris Withers
> Sent: Tuesday, February 26, 2002 4:18 AM
> To: po...@or...
> Cc: Pythoncard; ZODB
> Subject: Re: [ZODB-Dev] Excellent overview of ODBMS and my take on ZODB
>
>
> "Patrick K. O'Brien" wrote:
> >
> > Persistent base class, and you cannot use __getattr__ or __setattr__
> > methods.
>
> Not true.

[snip]

cheers,

Chris

_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZOD...@zo...
http://lists.zope.org/mailman/listinfo/zodb-dev

"Patrick K. O'Brien" wrote:
> 
> Persistent base class, and you cannot use __getattr__ or __setattr__
> methods. 

Not true.

> which is why I created a Field class in my Bulldozer project. ZODB is also
> slightly behind in supporting the new classes in Python 2.2 and the new
> capabilities that those bring.

I think those are being used in the Zope 3 development effort.

> ZODB does assign Object Identifiers automatically. And you can get to them
> if you know the attribute/method call. 

But that's 'bad'. I think you may want the ObjectHub in Zope 3.

> Especially if you expect to be able to use the OID as a link to data in some
> other system, such as a relational database. At this point you are better
> off generating your own "key" value.

Yeah, definitely ObjectHub.

> Distributed storage is not supported by ZODB at this point. And I don't get
> the impression that this is on anyone's to-do list, though rumor has it that
> Jim Fulton has been heard whispering about such things
> (http://lists.zope.org/pipermail/zodb-dev/2001-May/000801.html). The storage
> enhancement requests/proposals that I could find are:
> 
> 1. Standby (http://www.zope.org/Wikis/ZODB/StandbyStorage)
> 2. MixedMode (http://www.zope.org/Wikis/ZODB/MixedModeStorage)
> 3. Replicated
> (http://dev.zope.org/Wikis/DevSite/Projects/ZEOReplicatedStorage/FrontPage).

I think Jim sees replication as an 'application level' problem. I'm inclined to
agree, but it's a shame it can't all happen magically ;-)

> ZODB does not have an Object Query capability. On the Zope side there is the
> Catalog capability, which has some query-like features. But, imho, ZODB
> really needs its own indexing and cataloging features minus the Zope
> overhead.

Don't think it's gonna happen.

cheers,

Chris

There is an update to the addressesZODB sample available. Nothing changed
but infrastructure. I'm continuing to simplify things so that defining the
database classes is as simple as possible. There is now a database.py file
with the Field, Entity and Database class definitions. You'll need to
download the latest Bulldozer to make this work. And you'll have to delete
any existing Addresses.fs* files or you'll get very strange errors.

---
Patrick K. O'Brien
Orbtech

Good. As for the importing, if you launch it from a dos/unix shell there are
print statements that will appear and you'll see that about 95% of the
processing time (rough guess) is waiting for the data from Outlook. Writing
to the ZODB happens pretty quick. (Not that writing to the ZODB is all that
quick in general compared to other storage mechanisms.)

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of David
> LeBlanc
> Sent: Monday, February 25, 2002 1:36 PM
> To: Pythoncard-Users@Lists. Sourceforge. Net
> Subject: [Pythoncard-users] Works
>
>
> AddressesZODB now works, including importing OutLook address book.
> Reasonably quick too.
>
> Dave LeBlanc
> Seattle, WA USA
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

AddressesZODB now works, including importing OutLook address book.
Reasonably quick too.

Dave LeBlanc
Seattle, WA USA

First of all, I feel sort of stupid for not doing this a long time ago.
Python has a -i command-line option to launch a script with the interpreter.
If you have a script with a syntax error or a module can't be imported or
any other reason that keeps the script from starting then you are left in
the interpreter with an error message rather than having the console
disappear on you.

So, I added a "Run with interpreter" menu item to the File menu in the
resourceEditor. If you try the "Run" menu item (Ctrl+R) and your program
doesn't run, then just "Run with interpreter" (Ctrl+Shift+R) and when the
script fails you'll be left in the Python interpreter. Type Ctrl+Z and then
the return key to exit the interpreter when you're done.

Please report any problems to the list.

Thanks to Neil Hodgson for sending me his code which helped me look in the
right direction.

ka

Here is a very nice overview of ODBMS in general:

http://www.versant.com/products/vds/whitepapers/WP_001001r6W.pdf

And here is my assessment of ZODB as it relates to this overview (feel free
to correct any mistakes or misunderstandings on my part):

ZODB does let you store (just about) any complex object model in the
database. A few caveats are that your classes have to subclass the
Persistent base class, and you cannot use __getattr__ or __setattr__
methods. This does limit what you can do to intercept attribute access,
which is why I created a Field class in my Bulldozer project. ZODB is also
slightly behind in supporting the new classes in Python 2.2 and the new
capabilities that those bring.

ZODB does assign Object Identifiers automatically. And you can get to them
if you know the attribute/method call. However, they are somewhat limited by
the fact that they get reassigned if/when you export your objects to another
storage type (for example from File Storage to Berkeley). This isn't
necessarily the worst thing in the world, but it is a bit of a wart.
Especially if you expect to be able to use the OID as a link to data in some
other system, such as a relational database. At this point you are better
off generating your own "key" value.

Navigation in Persistent objects is identical to navigation in Python. So
you can just do "oneInvoice.customer" and the customer object is retrieved
from the ZODB transparently. (Unless it is already in memory, etc. The main
point is you don't have to worry about those details in your application
code. It is all transparent.)

ZODB is as transparent as the Java example in the white paper. So
oneInvoice.customer.name = 'Versant' would be the Python equivalent and this
name change would get persisted on the next commit().

Distributed storage is not supported by ZODB at this point. And I don't get
the impression that this is on anyone's to-do list, though rumor has it that
Jim Fulton has been heard whispering about such things
(http://lists.zope.org/pipermail/zodb-dev/2001-May/000801.html). The storage
enhancement requests/proposals that I could find are:

1. Standby (http://www.zope.org/Wikis/ZODB/StandbyStorage)
2. MixedMode (http://www.zope.org/Wikis/ZODB/MixedModeStorage)
3. Replicated
(http://dev.zope.org/Wikis/DevSite/Projects/ZEOReplicatedStorage/FrontPage).

ZODB does not have an Object Query capability. On the Zope side there is the
Catalog capability, which has some query-like features. But, imho, ZODB
really needs its own indexing and cataloging features minus the Zope
overhead. (I've just started hacking up my own versions of these to strip
out all the Zope assumptions. Yuck. I, personally, consider this a major
weakness of ZODB.)

ZODB has an Object Cache as well. Refer to the Jim Fulton paper for the gory
details:

HTML -
http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html
PDF -
http://www.python.org/workshops/2000-01/proceedings/papers/fulton/fulton-zod
b3.pdf

Hope this proves useful to someone.

---
Patrick K. O'Brien
Orbtech

When I posted my response to Andy, I also sent an email to Alex Martelli. As
expected, Alex had some interesting things to say about finding dictionary
keys based on value.

ka
---
-----Original Message-----
Subject: Re: finding a dictionary key based on value


On Tuesday 19 February 2002 18:35, Kevin Altis wrote:
> Hi Alex,

Hi Kevin,

There is no way given a dictionary to check what keys if any have a
given value (there may be any number, 0 up) except by linear iteration
on all items.  A dictionary maps keys to values very fast, but for the
reverse mapping you need a linear loop (or, bundle two dictionaries
that go either way!).

Fastest/simplest is a list comprehension:
[key for key in thedict if thedict[key] == thevalue]

this is 2.2 due to the "for key in dict" idiom, but you can use a slightly
slower equivalent in 2.1 with "for key in dict.keys()".  It's slower (for a
large dictionary) because it needs to construct the whole list of keys
just to let you loop on them while 2.2's iterators avoid doing that.

This returns a list, empty if no key has that value, or else with any
suitable number of entries.  I don't see how it makes sense to just
return one key when there might be several, and the None returned
to mean "no such key" is confusable with None itself being a key
(no problem using None as a dictionary key, after all).  I'd definitely
produce/return a list unless supplied with lots of application specific
extra info, in which case I would point out that extra info in a quite
prominent way.  Just the fact that you "know" that no more than one
key will have that value is no reason not to use empty list to mean
'none' and one-item list to mean 'this is it' (no ambiguity).

If you have uniqueness you only need to subclass dict and override
mutators, e.g. using only __setitem__ for example we'd have:

class TwoWayDict(dict):
    def __init__(self):
        dict.__init__(self)
        self.byValue = {}
    def __setitem__(self, key, value):
        try: del self.byValue[value]
        except: pass
        dict.__setitem__(self, key, value)
        self.byValue[value] = key

now use d=TwoWayDict() and just d.byValue[avalue] to get the
corresponding key (or a KeyError if absent).  Of course you'd also
want to override setdefault, update, pop, and so on, and probably
also check for the uniqueness constraint (very easy to violate it!),
but I hope the general idea is clear.  If you have uniqueness and
are all the time doing lookups either way, this can help.


Alex

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Tuesday, February 19, 2002 2:10 PM
> To: Pythoncard-Users
> Subject: RE: [Pythoncard-users] Brain Fade
>
>
> The cvs version of PythonCardPrototype is using direct subclasses of
> wxPython controls, so you can use the client data methods if you want to
> give that a try.
>
> In general, I would say you are better off creating a second
> dictionary that
> uses the values as keys and the keys as values, assuming the values are
> unique, which they probably are if you're displaying them in a Choice
> component. I suppose there is a good reason that the descriptions are not
> already being used as the keys? How big are the dictionaries?
>
> The brute force method of finding a key based on value looks like this:
> >>> d = {1:'one', 2:'two', 3:'three', 4:'four'}
> >>> def getKeyByValue(d, value):
> ...     for k in d.items():
> ...         if k[1] == value:
> ...             return k[0]
> ...     return None
> ...
> >>> getKeyByValue(d, 'four')
> 4
>
> There is probably a clever lambda or iterator that would do a better job,
> but that function gets the job done. Is this what you needed?
>
> ka
>
> > -----Original Message-----
> > From: pyt...@li...
> > [mailto:pyt...@li...]On Behalf Of Andy
> > Todd
> > Sent: Tuesday, February 19, 2002 3:50 AM
> > To: Pythoncard-Users
> > Subject: [Pythoncard-users] Brain Fade
> >
> >
> > Evening all,
> >
> > Its late, but I can't find any examples of what I want to do anywhere.
> > This is a fairly frequent occurrence in the world of relational
> > databases and I've been scratching my head trying to figure out how to
> > represent it in PythonCard.
> >
> > Enough teasing, I have a table which contains keys and descriptions and
> > I want to display the available descriptions in a 'choice' widget. Which
> > is fairly easy. But when the user selects an element in the choice
> > widget I want my code to know the corresponding key value. Is there any
> > way to associate multiple items (say tuples?) with a choice widget?
> >
> > At the moment I'm returning the key-description pairs into a dictionary,
> > so of course it would be nice to just get the key from the description
> > value but I don't know of a way to do this in ordinary Python, unless I
> > am being more of an idiot than usual.
> >
> > I don't think I can associate multiple values with each item in
> > PythonCard (or wxPython for that matter) so I probably need to do this
> > in my program.
> >
> > But, and this is a big but, I don't want to have to iterate through all
> > of the available key-description pairs to find the key I'm looking for
> > based on the value from the choice widget.
> >
> > Any suggestions?
> >
> > Regards,
> > Andy
> > --
> > -----------------------------------------------------------------------
> >  From the desk of Andrew J Todd esq.
> > Smiggins Hole 2010 - Unleash the Mongrel
> >
> >
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> >
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Here is an idea for a PythonCard app. (Cuz I need this for my own app.)
Create something that will take a phone number or address or ZIP Code, and
will return the timezone. I've even got lat/lon on most of my records, if
that helps.

Anyone have any idea how to do this conversion? Or is there a web service
that will do this?

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: Jon Edwards [mailto:jo...@pc...]
> Subject: RE: [Pythoncard-users] hello. new to the list, pythoncard and
> python!
> 
> 
> One approach might be to make your blogging-app "speak" the BloggerAPI
(or
> even the ManilaAPI if you're feeling ambitious!). Then create an
> add-on/option for textRouter that allows it to use Word as an editor
(or
> maybe to import and tidy-up a Word doc?)
> 
> That way, your blog-app would be usable with any of the (many) blog-
> clients
> which can speak to the BloggerAPI, giving it a wider potential
audience.
> And, for your GUI, you could take advantage of all the nice stuff
that's
> already built in textRouter, rather than starting from scratch?
> 

Hi Jon,

Something like the word add-on might come out of my efforts, but really
the whole point is to eliminate blogger. I already use blogger and
compose in word (using a little copynpaste). I don't want to write a
server app that replaces blogger, like greymatter. Eventually I want
this to grow into a tool to manage my whole site so it's more like a
content management app ala frontpage. The difference is that I don't
want wysiwyg page design, I just want wysiwyg in-line text editing (that
autocorrects!). I'm a writer.

http://ftrain.com is an inspiration. XML-izing my content opens up a lot
of options for presenting it to my readers.

After doing this for 5 years, I'm just tired of using other people's
products to build and manage my site. They always end up limiting me or
outright screwing me. If I have to wait for features or start over and
redesign my whole site, I'd rather it be because of something I did.

davep

Hi David,

I'm a newbie too (coming from Zope), just thinking aloud, so take the
following with a large pinch of salt! :-)

> I've looked at textrouter and was impressed with its sophistication. It
> would be nearly perfect except for the storage format and that I want to
> compose in word. Simon also has DiaryXML but that's perl-based. I hope
> to build this app for myself and then, if I can manage it, clean it up
> and make it available to others.

One approach might be to make your blogging-app "speak" the BloggerAPI (or
even the ManilaAPI if you're feeling ambitious!). Then create an
add-on/option for textRouter that allows it to use Word as an editor (or
maybe to import and tidy-up a Word doc?)

That way, your blog-app would be usable with any of the (many) blog-clients
which can speak to the BloggerAPI, giving it a wider potential audience.
And, for your GUI, you could take advantage of all the nice stuff that's
already built in textRouter, rather than starting from scratch?

Hope that's helpful!

Cheers, Jon

I forgot to mention that I checked it in to PythonCard's CVS. (Though I
suppose you might have correctly assumed that.)

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Patrick K. O'Brien
> Sent: Sunday, February 24, 2002 9:33 PM
> To: an...@ha...; wh...@oz...
> Cc: pyt...@li...
> Subject: RE: [Pythoncard-users] AddressesZODB Bug
>
>
> Too late. I just coded it. <wink> You'll need to get the latest
> Bulldozer as
> well, because I had to add a UnicodeField to handle the Unicode
> data coming
> from Outlook.
>
> ---
> Patrick K. O'Brien
> Orbtech

Too late. I just coded it. <wink> You'll need to get the latest Bulldozer as
well, because I had to add a UnicodeField to handle the Unicode data coming
from Outlook.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> an...@ha...
> Sent: Sunday, February 24, 2002 8:43 PM
> To: wh...@oz...
> Cc: pyt...@li...
> Subject: Re: [Pythoncard-users] AddressesZODB Bug
>
>
> Dave,
>
> This feature is 'awaiting implementation' in the ZODB version of
> the addresses sample, as Patrick alluded to in his e-mail
> earlier. Basically the code in the on_fileImportOutlook_command
> method is copied from the original addresses sample and hasn't
> been amended to use 'bulldozer' (Patrick's persistence mechanism)
> like the rest of the code in addresses.py.
>
> Of course, if you'd like to patch it and contribute the code you
> would be more than welcome.
>
> Regards,
> Andy

Dave,

This feature is 'awaiting implementation' in the ZODB version of the addresses sample, as Patrick alluded to in his e-mail earlier. Basically the code in the on_fileImportOutlook_command method is copied from the original addresses sample and hasn't been amended to use 'bulldozer' (Patrick's persistence mechanism) like the rest of the code in addresses.py.

Of course, if you'd like to patch it and contribute the code you would be more than welcome.

Regards,
Andy

On Sun, 24 February 2002, "David LeBlanc" wrote:

> 
> J:\Python21\PythonCardPrototype\samples\addressesZODB>addresses.py
> attempting to load Outlook
> loading records...
> importing into addresses
> Traceback (most recent call last):
>   File "J:\Python21\PythonCardPrototype\menu.py", line 304, in doMenu
>     item.notifyEventListeners( evt )
>   File "J:\Python21\PythonCardPrototype\event.py", line 322, in
> notifyEventListeners
>     listener.eventOccurred( event )
>   File "J:\Python21\PythonCardPrototype\dispatch.py", line 78, in
> eventOccurred
>     handler.getFunction()(self._scriptable, aEvent.getSource(), nativeEvent)
>   File "J:\Python21\PythonCardPrototype\samples\addressesZODB\addresses.py",
> line 250, in on_fil
> eImportOutlook_command
>     self.document.records.append(aRecord)
> AttributeError: Document instance has no attribute 'records'
> 
> This is based on CVS code downloaded at 17:20 PST on 200020224
> 
> Dave LeBlanc
> 
> 

I just wanted to say hi. I've been reading a lot of your posts over the
last couple of days and I hope that one day I can help out with
pythoncard. I've just started learning python but I'm lovin it so far.
My programming skills are pretty amateurish. I can do vbscript and have
written a few simple system admin and html preprocessing utilities but
nothing that I could give to other people. 

I've done the new tutorial and it's much better, I though the biggest
hole was explaining how to bootstrap a pythoncard environment on win32.
Even with the auto installers and 15 years of computer administration
experience I found it hard to setup the python development environment.
Figuring out which components to download,
wxWin,win32com,phython,activestate etc, which version to use, and which
tool/ide is the right one is much harder than writing python code! I'm
sure one reason this is lacking is because it's hard to describe a
moving (opensource) target. Looking forward to the next part because I'm
still not sure how to debug interactively without using PythonWin.

I'm going to try to write a blogging / content management system with
python, xml and xslt. Originally I'd hoped to do it just with xml and
xslt being driven by some batch scripts but I've found that xslt is
really hard to program in and its support of dates and times is just too
limited right now. 

The thing that's making this tough is that I want to use word to edit my
posts and then have each entry stored in a big xml doc that then is
parsed by xslt to create the site. This involves automation of word (I
think I can do this by saving temp working files as filtered html),
using pythoncard to build a database-like form to manage the posts and
then scripting various xslt transforms to build the pages. I'm going to
all this trouble because I want my writing to be stored in a more open
format and I want to be able to generate a static site and avoid
blogger. I have over 200 html pages on my site, over 300 photographs and
I'm planning on making this all xml / xslt based but I'm going to start
with the blog as a proof of concept. I currently generate my website
from an access database and some WSH vbscripts.

I've looked at textrouter and was impressed with its sophistication. It
would be nearly perfect except for the storage format and that I want to
compose in word. Simon also has DiaryXML but that's perl-based. I hope
to build this app for myself and then, if I can manage it, clean it up
and make it available to others.

I guess the majority of what I'll be doing with python and pythoncard is
reading and editing an xml document and scripting simple xslt
transforms. I'm still trying to figure out the best python xml tools.
DOM, SAX etc. DOM looks cleaner at this point as a result of doing xslt
for a couple of months. And, I found some better tutorials and
sourcecode using python and DOM. I've written a simple xml-xml transform
using expat ('cause xslt is "not fit for human consumption"). Any links
or samples are greatly appreciated of course. 

One question: shouldn't I just start writing the xml serialization and
automation code and then when that's done, put the GUI on top? I'm
guessing this would be the way to go.

I think I'm going to call it "posterchild"

davep

J:\Python21\PythonCardPrototype\samples\addressesZODB>addresses.py
attempting to load Outlook
loading records...
importing into addresses
Traceback (most recent call last):
  File "J:\Python21\PythonCardPrototype\menu.py", line 304, in doMenu
    item.notifyEventListeners( evt )
  File "J:\Python21\PythonCardPrototype\event.py", line 322, in
notifyEventListeners
    listener.eventOccurred( event )
  File "J:\Python21\PythonCardPrototype\dispatch.py", line 78, in
eventOccurred
    handler.getFunction()(self._scriptable, aEvent.getSource(), nativeEvent)
  File "J:\Python21\PythonCardPrototype\samples\addressesZODB\addresses.py",
line 250, in on_fil
eImportOutlook_command
    self.document.records.append(aRecord)
AttributeError: Document instance has no attribute 'records'

This is based on CVS code downloaded at 17:20 PST on 200020224

Dave LeBlanc

Just to prove that I am the worlds most efficient 'prototyper', Kevin looked at my code and immediately came up with a much more elegant solution.

Basically, if you are not running on Windows the 'Import  Outlook' menu item is disabled. If you are running Windows nothing *now* happens until you select the menu item. If you don't have Outlook and you select the menu item them my old friend the installation wizard comes up and serve you right for doing so. If you do have Outlook and select the menu item then your contacts database is imported into the sample application - maybe, I'm not running Outlook so I can't tell you whether or not it works ;-)

So, changes are checked into CVS and ignore the '-o' flag that I posted in the original message.

Regards,
Andy

On Sun, 24 February 2002, "Patrick K. O'Brien" wrote:

> 
> Thanks. Which reminds me, I haven't gotten around to making the Outlook
> import work yet anyway.
> 
> ---
> Patrick K. O'Brien
> Orbtech
> 
> > -----Original Message-----
> > From: pyt...@li...
> > [mailto:pyt...@li...]On Behalf Of
> > an...@ha...
> > Sent: Sunday, February 24, 2002 5:35 PM
> > To: pyt...@li...
> > Subject: [Pythoncard-users] Disabling outlook integration in
> > addressesZODB
> >
> >
> > I've been playing with Patrick's latest changes to the
> > addressesZODB sample and the accompanying ZODB interaction  in
> > the shell. Thanks Patrick, its very nice stuff.
> >
> > However, I'm running on Windows but I don't use Outlook. I do
> > have MS Office installed though, so the Outlook installation
> > wizard was firing up every time I started the application. After
> > four or five "no I don't want to install this software" I decided
> > to do something about it.
> >
> > I've added a command line flag to the application to get rid of
> > it. If you are running on Windows and don't use Outlook, just
> > start the application with a '-o' option and the Outlook
> > integration will be disabled.
> >
> > e.g. start a DOS window and type;
> >
> > C:> cd samples\addressesZODB
> > C:> python addresses.py -o
> >
> > And no annoying installation wizards will appear. Sweet.
> >
> > Regards,
> > Andy
> >
> >
> >
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Thanks. Which reminds me, I haven't gotten around to making the Outlook
import work yet anyway.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> an...@ha...
> Sent: Sunday, February 24, 2002 5:35 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] Disabling outlook integration in
> addressesZODB
>
>
> I've been playing with Patrick's latest changes to the
> addressesZODB sample and the accompanying ZODB interaction  in
> the shell. Thanks Patrick, its very nice stuff.
>
> However, I'm running on Windows but I don't use Outlook. I do
> have MS Office installed though, so the Outlook installation
> wizard was firing up every time I started the application. After
> four or five "no I don't want to install this software" I decided
> to do something about it.
>
> I've added a command line flag to the application to get rid of
> it. If you are running on Windows and don't use Outlook, just
> start the application with a '-o' option and the Outlook
> integration will be disabled.
>
> e.g. start a DOS window and type;
>
> C:> cd samples\addressesZODB
> C:> python addresses.py -o
>
> And no annoying installation wizards will appear. Sweet.
>
> Regards,
> Andy
>
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

I've been playing with Patrick's latest changes to the addressesZODB sample and the accompanying ZODB interaction  in the shell. Thanks Patrick, its very nice stuff. 

However, I'm running on Windows but I don't use Outlook. I do have MS Office installed though, so the Outlook installation wizard was firing up every time I started the application. After four or five "no I don't want to install this software" I decided to do something about it.

I've added a command line flag to the application to get rid of it. If you are running on Windows and don't use Outlook, just start the application with a '-o' option and the Outlook integration will be disabled. 

e.g. start a DOS window and type;

C:> cd samples\addressesZODB
C:> python addresses.py -o

And no annoying installation wizards will appear. Sweet.

Regards,
Andy

I just checked in some more changes:
I created a Run Options dialog for setting the command-line options for the
Run command and removed them from the Options menu. I moved the Duplicate
and Delete menu items from the Components menu to the Edit menu. I renamed
the View->Attributes menu item to View->Resource...

ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, February 23, 2002 5:39 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] refactored resourceEditor with new Property
> Editor window
>
>
> I changed the resourceEditor so that it no longer relies on the runtime
> Property Editor. I've checked in the changes to cvs.
>
> I created a Property Editor background
> (modules\propertyEditor.py) based on
> the runtime Property Editor so that the resourceEditor would be a little
> more intuitive. Eventually, I'm going to redo the layout of the
> window, but
> not for this next release.
>
> The changes I made should make the resourceEditor more intuitive and
> streamline the layout process. When you Add a component a unique name is
> automatically chosen and the component is placed on the layout;
> the user is
> no longer required to use the TextEntryDialog to set values for the
> initialization dictionary. When you select a component in the Property
> Editor, it is automatically selected on the layout. The resizing
> handles are
> automatically updated to reflect the new position and size of a component.
> You can change attributes that were previously read-only: name, alignment,
> layout, style, border. The resourceEditor will recreate the component and
> put it back in the layout in its original order. Note that I am
> not locking
> the screen yet, so updates to the layout and Property Editor
> lists are shown
> while the component order is updated. I plan to hide the updates
> before the
> next release. With these changes, there should no longer be a need to
> manually edit a .rsrc.py file.
>
> Since I'm still testing the changes, the Shell is automatically
> opened when
> the resourceEditor starts up and the new window is titled "Property Editor
> 2" so it isn't confused with the regular runtime Property Editor. I would
> appreciate feedback and testing of the changes from anyone that
> is using the
> cvs version of PythonCardPrototype. I don't want to make a new
> release until
> I'm sure the kinks are worked out. In case of bugs, please only work on
> duplicates of resource files to avoid losing any data.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

I just checked in one minor tweak to the addresses sample that exposes the
database in the PythonCard shell. Now if you run the app with the shell,
you'll see the following in the shell:

>>> bg = pcapp.getCurrentBackground()
>>> comp = bg.components

To which you can add:

>>> db = bg.document.db

Now you can access the database through the shell:

>>> db.addresses.count()
1
>>> db.Address(Name="Patrick K. O'Brien", Company="Orbtech")
<Address instance at 0193AB50>
>>> db.addresses.count()
2
>>> kevin = db.Address(Name="Kevin Altis", Company="Hot Tubs, Inc.")
>>> kevin.Company
<StringField instance at 0193D3A0>
>>> kevin.Company()
'Hot Tubs, Inc.'
>>>

Boy, am I having fun with this.

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Patrick K. O'Brien
> Sent: Sunday, February 24, 2002 11:23 AM
> To: Pythoncard
> Subject: [Pythoncard-users] Major changes to Bulldozer and addressesZODB
> sample app.
>
>
> Anyone looking at Bulldozer and the new addresses sample should get the
> latest of each out of CVS. I did a major restructuring of both that I am
> quite pleased with. Nearly killed me, but the result is much
> simpler in many
> ways. Enjoy.
>
> Bulldozer: http://sourceforge.net/projects/bdoz
>
> ---
> Patrick K. O'Brien
> Orbtech
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Anyone looking at Bulldozer and the new addresses sample should get the
latest of each out of CVS. I did a major restructuring of both that I am
quite pleased with. Nearly killed me, but the result is much simpler in many
ways. Enjoy.

Bulldozer: http://sourceforge.net/projects/bdoz

---
Patrick K. O'Brien
Orbtech

I went ahead and added an experimental Cut, Copy, Paste (no Undo/Redo) so
you can select a component, Copy or Cut its description to the clipboard and
then Paste the description to create a new component on the layout. If there
is a name conflict, you'll be prompted for a new name. Copy and Paste should
be useful for reusing a component description in another layout/sample. Just
open a .rsrc.py file, select the component you're interested in, Copy it to
the clipboard, then create a new layout or open an existing one and Paste.
You can also paste the description in the shell or external editor.

I've only done the briefest of tests of this feature, but it seems to work.
There are a couple of issues to watch out for. One, wxPython does not
preserve the clipboard when you quit the application, so you need to do your
pasting prior to exiting the resourceEditor. Two, Cut/Copy/Paste can be a
bit confusing when you have an editable text field selected, I'll have to
play with this more to see what workarounds I can do. Finally, I haven't
bound Ctrl+X, Ctrl+C, Ctrl+V to the background window, so you need to select
the menu items rather than using the shortcuts.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Saturday, February 23, 2002 5:39 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] refactored resourceEditor with new Property
> Editor window
>
>
> I changed the resourceEditor so that it no longer relies on the runtime
> Property Editor. I've checked in the changes to cvs.
>
> I created a Property Editor background
> (modules\propertyEditor.py) based on
> the runtime Property Editor so that the resourceEditor would be a little
> more intuitive. Eventually, I'm going to redo the layout of the
> window, but
> not for this next release.
>
> The changes I made should make the resourceEditor more intuitive and
> streamline the layout process. When you Add a component a unique name is
> automatically chosen and the component is placed on the layout;
> the user is
> no longer required to use the TextEntryDialog to set values for the
> initialization dictionary. When you select a component in the Property
> Editor, it is automatically selected on the layout. The resizing
> handles are
> automatically updated to reflect the new position and size of a component.
> You can change attributes that were previously read-only: name, alignment,
> layout, style, border. The resourceEditor will recreate the component and
> put it back in the layout in its original order. Note that I am
> not locking
> the screen yet, so updates to the layout and Property Editor
> lists are shown
> while the component order is updated. I plan to hide the updates
> before the
> next release. With these changes, there should no longer be a need to
> manually edit a .rsrc.py file.
>
> Since I'm still testing the changes, the Shell is automatically
> opened when
> the resourceEditor starts up and the new window is titled "Property Editor
> 2" so it isn't confused with the regular runtime Property Editor. I would
> appreciate feedback and testing of the changes from anyone that
> is using the
> cvs version of PythonCardPrototype. I don't want to make a new
> release until
> I'm sure the kinks are worked out. In case of bugs, please only work on
> duplicates of resource files to avoid losing any data.
>
> ka
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

I changed the resourceEditor so that it no longer relies on the runtime
Property Editor. I've checked in the changes to cvs.

I created a Property Editor background (modules\propertyEditor.py) based on
the runtime Property Editor so that the resourceEditor would be a little
more intuitive. Eventually, I'm going to redo the layout of the window, but
not for this next release.

The changes I made should make the resourceEditor more intuitive and
streamline the layout process. When you Add a component a unique name is
automatically chosen and the component is placed on the layout; the user is
no longer required to use the TextEntryDialog to set values for the
initialization dictionary. When you select a component in the Property
Editor, it is automatically selected on the layout. The resizing handles are
automatically updated to reflect the new position and size of a component.
You can change attributes that were previously read-only: name, alignment,
layout, style, border. The resourceEditor will recreate the component and
put it back in the layout in its original order. Note that I am not locking
the screen yet, so updates to the layout and Property Editor lists are shown
while the component order is updated. I plan to hide the updates before the
next release. With these changes, there should no longer be a need to
manually edit a .rsrc.py file.

Since I'm still testing the changes, the Shell is automatically opened when
the resourceEditor starts up and the new window is titled "Property Editor
2" so it isn't confused with the regular runtime Property Editor. I would
appreciate feedback and testing of the changes from anyone that is using the
cvs version of PythonCardPrototype. I don't want to make a new release until
I'm sure the kinks are worked out. In case of bugs, please only work on
duplicates of resource files to avoid losing any data.

ka

Dan and I just finished doing a new entry-level walk-through for PythonCard
aimed at raw newbies using Windows. We'd really appreicate you reviewing it
and getting back with comments and corrections ASAP. I want to get release
0.6.4 out early next week with a new rev of the prototype.

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

this has links to the installation and learning Python material.
http://pythoncard.sourceforge.net/installation.html
http://pythoncard.sourceforge.net/learning_python.html

Mark Pilgrim was kind enough to let us just use his set of links from
http://diveintopython.org/

Installation or other suggestions specific to Linux would also be
appreciated. I think we could do separate installation docs for each
platform to reduce confusion. Neither Dan or I are running Linux.

ka