pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] RTS World Editor

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

Hi there,

I wonder if it is posible that Python Card can be suitable for making a 
Starcraft like World Editor.

I think the specific question should be how to obtain a scrollable bitmap 
canvas.

Thanks in advance,

Brian

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

[Pythoncard-users] Notebook page - how to select self

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

I tried the self.Raise() which works for child windows but not for 
selecting 
Notebook pages. 

Right now, the only way I know how to select a Notebook page is
based on the index or the title of the page. Can a Notebook page
(a PageBackground object) find its own name or index so that
it can self-select?

Something like either of these two things might be nice:

myIndex = self.GetPageIndex() # this function doesn't exist
self.getParent().notebook.SetSelection (myIndex)

or 

myTitle = self.GetPageTitle() # this function doesn't exist
self.getParent().notebook.stringSelection = myTitle

Is there already something like what I'm looking for, or should I build 
these
functions from scratch?

Thanks!

Re: [Pythoncard-users] how to trigger on_closefield for the focused

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

VGhhbmtzIGZvciB0aGUgaW5mbywgQmVybmllLiBIb3dldmVyLCBJIHN0aWxsIGhhdmVuJ3QgYmVl
biBhYmxlIHRvIGZpeCBteSANCmJ1Zy4NCg0KIEkgdHJpZWQgT25DbG9zZS4gIEl0IGFwcGVhcnMg
dGhhdCBPbkNsb3NlIGdldHMgc2VudCBhZnRlciBvbl9jbG9zZS4NCiBJIHB1dCBhbiBldmVudC5z
a2lwKCkgYW5kIGEgcHJpbnQgc3RhdGVtZW50IGludG8gdGhvc2UgaGFuZGxlcnMgdG8NCmZpbmQg
b3V0IHRoZSBvcmRlciBvZiBldmVudHMuDQoNCmNhdWdodCBvbl9jbG9zZQ0KY2F1Z2h0IE9uQ2xv
c2UNCmNhdWdodCBvbl9jbG9zZUZpZWxkOg0KDQpUaGUgcHJvYmxlbSBoZXJlIGlzIHRoYXQgSSBu
ZWVkIHRvIGNhdGNoIHRoZSBvbl9jbG9zZUZpZWxkIGJlZm9yZSB0aGUNCk9uQ2xvc2UgZ29lcyBv
ZmYuIEl0IHdvdWxkIGJlIG5pY2UgaWYgUHl0aG9uQ2FyZCBwYXNzZWQgdGhlIGV2ZW50cyBpbg0K
dGhhdCBvcmRlciAoY2xlYW4gdXAgYmVmb3JlIHRoZSBjbG9zZSB3aW5kb3cgaGFwcGVucyksIGJ1
dCBmYWlsaW5nIHRoYXQNCkknbSBsb29raW5nIGZvciBhIHdheSB0byBkZXRlY3Qgd2hpY2ggZmll
bGQgaGFkIHRoZSBmb2N1cyBkdXJpbmcgb25fY2xvc2UsDQphbmQgc29tZWhvdyBnZW5lcmF0ZSB0
aGUgb25fY2xvc2VGaWVsZCBldmVudCBvbiBiZWhhbGYgb2YgdGhhdA0KcGFydGljdWxhciBmaWVs
ZCB3aWRnZXQuDQoNClRoYW5rcyENCg0KDQoNCkJlcm5pZSBIb2dhbiA8YmVybmllLmhvZ2FuQHV0
b3JvbnRvLmNhPiB3cm90ZSBvbiAwNS8yMi8yMDA1IDAzOjMyOjAwIFBNOg0KDQo+IEhpIEJyYWQs
IA0KPiANCj4gQWxsIHdpbmRvd3MgaGF2ZSBhbiBPbkNsb3NlKCkgbWV0aG9kOg0KPiANCj4gSXQg
ZGVyYWlscyBhbnkgY2xvc2luZyBldmVudCDigJMgc28gYmUgc3VyZSB0byBoYXZlIGEgc2VsZi5E
ZXN0cm95IGEgDQo+IHRoZSBlbmQg4oCTIGluIHRoZSBtaWRkbGUganVzdCBzdGljayBpbiB3aGF0
IHlvdSB3YW50LiANCj4gDQo+IFRyeSB0aGlzOg0KPiAgICAgZGVmIE9uQ2xvc2Uoc2VsZiwgZXZl
bnQpOg0KPiAgICAgICAgIGRsZyA9IHd4TWVzc2FnZURpYWxvZyhzZWxmLCAiV291bGQgeW91IGxp
a2UgdG8gc2F2ZSBiZWZvcmUgDQo+IHlvdSBjbG9zZT8iLCAiSG1tbS4uLi4iLCB3eFlFU19OTykN
Cj4gICAgICAgICBpZiAoZGxnLlNob3dNb2RhbCgpID09IHd4SURfWUVTKToNCj4gICAgICAgICAg
ICAgc2VsZi5kb1NhdmUoZXZlbnQpDQo+ICAgICAgICAgc2VsZi5EZXN0cm95KCkNCj4gDQo+IEJF
Uk5pRQ0KPiANCj4gQmVybmllIEhvZ2FuDQo+IFBoRCBTdHVkZW50DQo+IERlcGFydG1lbnQgb2Yg
U29jaW9sb2d5DQo+IE5ldExhYiwgS25vd2xlZGdlIE1lZGlhIERlc2lnbiBJbnN0aXR1dGUNCj4g
VW5pdmVyc2l0eSBvZiBUb3JvbnRvDQo+IA0KPiBJIHJlY2VpdmVkIGEgbWVzc2FnZSBmcm9tIGJy
YWQuYWxsZW5Ab21zZGFsLmNvbSBhdCBhcHByb3hpbWF0ZWx5IA0KPiA1LzIyLzA1IDQ6MjEgUE0u
IEFib3ZlIGlzIG15IHJlcGx5Lg0KDQo+IA0KPiBXaGVuIGEgd2luZG93IGNsb3NlcywgSSB3YW50
IHRvIHByb21wdGVkIHRoZSB1c2VyIHRvIHNhdmUgY2hhbmdlcyBpZg0KPiBuZWVkZWQuIFRoZSBz
Y3JpcHQgDQo+IGJlbG93IHNlZW1zIHRvIHdvcmsgZmluZSBmb3IgdGhhdCwgZXhjZXB0IGZvciBv
bmUgZ2xpdGNoOiBpZiB0aGUgDQo+IHVzZXIgZWRpdHMgYSBmaWVsZCwgdGhlbiBjbGlja3MgDQo+
IHRoZSBjbG9zZWJveCBvbiB0aGUgd2luZG93LCBhbiBvbl9jbG9zZWZpZWxkIG5ldmVyIGdldHMg
c2VudC4gSSdkIA0KPiBsaWtlIHRvIHNlbmQgYSBjbG9zZWZpZWxkIA0KPiBldmVudCB0byB0aGUg
d2lkZ2V0IHRoYXQgaGFzIHRoZSBmb2N1cyAoaWYgaXQncyBhIGZpZWxkKS4gSSd2ZSB0cmllZA0K
PiB1c2luZyBzZWxmLmNvbXBvbmVudHMuZ2V0Rm9jdXMsIA0KPiBhbW9uZyBvdGhlciB0aGluZ3Mu
Li50aGVyZSBtdXN0IGJlIHNvbWV0aGluZyBvYnZpb3VzIEknbSBtaXNzaW5nLiANCj4gDQo+IFRo
YW5rcyENCj4gDQo+IA0KPiAgICAgICAgIGRlZiBvbl9jbG9zZSAoc2VsZiwgZXZlbnQpOiANCj4g
ICAgICAgICAgICAgICAgcHJpbnQgJ2NhdWdodCBhIGNsb3NlIHdpbmRvdycgDQo+ICAgICAgICAg
ICAgICAgIGlmIGhhc2F0dHIgKHNlbGYsICdlbnRpdHknKTogDQo+ICAgICAgICAgICAgICAgICAg
ICAgICAgaWYgbGVuIChzZWxmLmVudGl0eS5uZXdEYXRhKSA+IDA6IA0KPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICByZXN1bHQgPSBzZWxmLndhcm5pbmdVbnNhdmVkQ2hhbmdlcygpIA0K
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiByZXN1bHQuYWNjZXB0ZWQ6IA0KPiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIHJlc3VsdC5yZXR1cm5lZFN0
cmluZyA9PSAnTm8nOiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgcHJpbnQgIkRvbid0IHNhdmUgDQo+IGNoYW5nZXM7IGNsb3NlIHdpbmRvdyIgDQo+ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbGYucmV2ZXJ0KCkg
DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbGYudmlz
aWJsZSA9IEZhbHNlIA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGVs
c2U6IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjc2F2
ZSBjaGFuZ2VzIA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB0cnk6IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHNlbGYuc2F2ZSgpIA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHNlbGYudmlzaWJsZSA9IA0KRmFsc2UgDQo+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGV4Y2VwdCBFeGNlcHRpb24sIHRoaXNF
cnI6IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGVyck1zZyA9IA0Kc3RyKHRoaXNFcnIpIA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbGYuDQo+IHdhcm5pbmdHZW5lcmFsICgnUHJv
YmxlbSBzYXZpbmcgY2hhbmdlczogJyArIGVyck1zZykgDQo+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGVsc2U6IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHBhc3MgI2RvIG5vdGhpbmc7IGRvIG5vdCBjbG9zZSANCndpbmRvdyANCj4gICAgICAgICAgICAg
ICAgICAgICAgICBlbHNlOiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI25vdGhp
bmcgdG8gc2F2ZSANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VsZi52aXNpYmxl
ID0gRmFsc2UgDQo+ICAgICAgICAgICAgICAgIGVsc2U6IA0KPiAgICAgICAgICAgICAgICAgICAg
ICAgIHByaW50ICJ0aGlzIG11c3Qgbm90IGJlIGEgd2luZG93IHdpdGggYSANCj4gRGJFbnRpdHk7
IG5vdGhpbmcgdG8gc2F2ZSIgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgZXZlbnQuc2tpcCgp
IA0KPiANCj4gDQo+IA0KPiAtLSANCg0K

Re: [Pythoncard-users] how to trigger on_closefield for the focused

[Bernie H. <ber...@ut...>]

Hi Brad,=20

All windows have an OnClose() method:

It derails any closing event =AD so be sure to have a self.Destroy a the end =
=AD
in the middle just stick in what you want.

Try this:
    def OnClose(self, event):
        dlg =3D wxMessageDialog(self, "Would you like to save before you
close?", "Hmmm....", wxYES_NO)
        if (dlg.ShowModal() =3D=3D wxID_YES):
            self.doSave(event)
        self.Destroy()

BERNiE

Bernie Hogan
PhD Student
Department of Sociology
NetLab, Knowledge Media Design Institute
University of Toronto

I received a message from bra...@om... at approximately 5/22/05
4:21 PM. Above is my reply.

>=20
> When a window closes, I want to prompted the user to save changes if need=
ed.
> The script=20
> below seems to work fine for that, except for one glitch: if the user edi=
ts a
> field, then clicks
> the closebox on the window, an on_closefield never gets sent. I'd like to=
 send
> a closefield=20
> event to the widget that has the focus (if it's a field). I've tried usin=
g
> self.components.getFocus,
> among other things...there must be something obvious I'm missing.
>=20
> Thanks!
>=20
>=20
>         def on_close (self, event):
>                print 'caught a close window'
>                if hasattr (self, 'entity'):
>                        if len (self.entity.newData) > 0:
>                               result =3D self.warningUnsavedChanges()
>                               if result.accepted:
>                                       if result.returnedString =3D=3D 'No':
>                                              print "Don't save changes; c=
lose
> window"=20
>                                              self.revert()
>                                              self.visible =3D False
>                                       else:
>                                              #save changes
>                                              try:
>                                                      self.save()
>                                                      self.visible =3D False
>                                              except Exception, thisErr:
>                                                      errMsg =3D str(thisErr=
)
>                                                      self.warningGeneral
> ('Problem saving changes: ' + errMsg)
>                               else:
>                                       pass #do nothing; do not close wind=
ow
>                        else:
>                               #nothing to save
>                               self.visible =3D False
>                else:
>                        print "this must not be a window with a DbEntity;
> nothing to save"=20
>                        event.skip()
>        =20


--=20

[Pythoncard-users] how to trigger on_closefield for the focused

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

When a window closes, I want to prompted the user to save changes if 
needed. The script
below seems to work fine for that, except for one glitch: if the user 
edits a field, then clicks
the closebox on the window, an on_closefield never gets sent. I'd like to 
send a closefield
event to the widget that has the focus (if it's a field). I've tried using 
self.components.getFocus,
among other things...there must be something obvious I'm missing.

Thanks!


        def on_close (self, event):
                print 'caught a close window'
                if hasattr (self, 'entity'):
                        if len (self.entity.newData) > 0:
                                result = self.warningUnsavedChanges()
                                if result.accepted:
                                        if result.returnedString == 'No':
                                                print "Don't save changes; 
close window"
                                                self.revert()
                                                self.visible = False
                                        else:
                                                #save changes
                                                try:
                                                        self.save()
                                                        self.visible = 
False
                                                except Exception, thisErr:
                                                        errMsg = 
str(thisErr)
 self.warningGeneral ('Problem saving changes: ' + errMsg)
                                else:
                                        pass #do nothing; do not close 
window
                        else:
                                #nothing to save
                                self.visible = False
                else:
                        print "this must not be a window with a DbEntity; 
nothing to save"
                        event.skip()
 

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

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

Oops, right. I meant Monday May 23.

Ste...@ao... wrote on 05/22/2005 07:46:20 AM:

> >$50 if it's fixed by Monday May 22! 
> >I can send via Paypal or check.
> 
> The last time May 22nd was a Monday was year 2000.
> 
> Time travel should be worth more than $50!
> 
> ;)
> 
> ---Tom Nally, New Orleans

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

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005

Re: [Pythoncard-users] WSIWYG printing?

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.13 - Release Date: 19/05/2005

[Pythoncard-users] WSIWYG printing?

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

Is there a simple way to print a PythonCard window just as it appears on 
the screen? 

Thanks!

Re: [Pythoncard-users] greedy events / double buffering?

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.11 - Release Date: 16/05/2005

RE: [Pythoncard-users] greedy events / double buffering?

[Sean D. <se...@tr...>]

Alex,=20

=20

I figured out the first problem - I was only responding to
on_*_mouseMove events, not on_*_mouseDrag.

=20

With the second problem.. I need to use clear() so that I can drag
primitives around the canvas (not draw with them like doodly.py does,
but rather arrange their position). Eventually I'd like to use bitmaps
for my nodes, but right now I'm just using drawRectangle() calls.

=20

I put Freeze() and Thaw() around the code that renders the nodes at
their positions:

=20

    def Render(self):

        if hasattr(self,"app"):

            self.components.GraphCanvas.Freeze()

            self.components.GraphCanvas.clear()

            for node in self.app.node_list:

                pos =3D node.pos

                self.components.GraphCanvas.drawRectangle(pos,(10,10))

            self.components.GraphCanvas.Thaw()

=20

Pretty simple stuff.. Except then I had the following interesting
side-effects:

=20

* Before I added the Freeze()/Thaw() pair, the on_*_mouseDrag event
would only fire once for every mouse movement. Now it just rapidly fires
once the button is down, without moving the mouse.

* Whereas without Freeze()/Thaw() the interface blinks as I drag a node,
with the pair, it doesn't update at all during dragging. I have verified
that the above code is evaluating, though.. After I mouseUp, it draws
everything, with a very noticable single blinking of the whole canvas
which I assume is the buffer blit not being in sync?

=20

So it appears these two problems are very interrelated.. My theory is
that for some reason the mouseDrag event is firing uncontrollably, and
because I redraw the canvas on each drag update, I get a bunch of
recursive Freeze()/Thaw() calls that don't finish popping (and showing
the buffer) until I release the mouse button. It smells like there might
be a forced mouseDrag event firing in wx when Thaw() is called. Anyone
have experience with this issue?=20

=20

I tried a really dumb workaround - before I call Freeze(), I set a class
member (self.thawing) to True, and then when a mouseDrag fires, I check
to see if self.thawing is true, and if it is, I set it to False and
early return, else it updates some data and redraws the canvas:

=20

    def on_GraphCanvas_mouseDrag(self, event):

        if self.thawing:

            self.thawing =3D False

            return

        cur_pos =3D event.position

        if self.drag_mode and len(self.app.selected)>0:

            delta_pos =3D (cur_pos[0] - self.last_mouse_pos[0], =
cur_pos[1]
- self.last_mouse_pos[1])

            self.app.AddRelativeNodePosition(self.app.selected,
delta_pos)

        self.last_mouse_pos =3D cur_pos

        self.Render()

=20

This seems to work, and I can drag my boxes around and it refreshes (and
I totally realize this isn't thread safe)... The remaining problem being
that I now get that sync blinking on every frame. So how do I stabilize
the blit sync? Is the sync even the problem?

=20

I would attach the full source/resource files in this email, but I'm not
sure what the policies are on this list. Is that kind of think ok?

=20

Thanks,

Sean

=20

=20

  _____ =20

From: Alex Tweedly [mailto:al...@tw...]=20
Sent: Tuesday, May 17, 2005 3:23 PM
To: Sean Dunn
Cc: pyt...@li...
Subject: Re: [Pythoncard-users] greedy events / double buffering?

=20

Sean Dunn wrote:=20

I've been using PythonCard for simple interfaces for about a year now.
Recently I decided to try something much more complex - implementing a
custom interface inside a BitmapCanvas. There are two problems I'm
facing at the moment:

=20

* I can't seem to fire a mouseDown event without blocking mouseMove
events until I get a mouseUp event. This basically means I can't click
and drag something interactively inside the BitmapCanvas.

There shouldn't be any problem doing this. Can you be more specific
about the problem ?
Or maybe look at the resourceEditor, which does this kind of thing in
both mouseDown/mouseDrag and in doResize



* I can't figure out how to double-buffer the BitmapCanvas. I'd like to
do a clear() and then redraw my interface without causing the canvas to
blink. Is there a way to do some kind of buffer toggling from inside
PythonCard?

=20

I think you should be able to get what you want from Freeze() and
Thaw().=20
(though in general you ought to avoid clear() and redraw() if possible
.... why do you need to do that ?)



I'd much appreciate if anyone has some sage advice.

=20

By the way, what I'm really trying to do is create a simple interface
for creating node graphs: the kind you see in 2D graphics compositing
programs/visual programming languages where you can arrange node
operators and interconnect them to form a data flow. If anyone knows of
a free Python (or even C++) API for doing this, let me know!

=20

Don't know of one, sorry. There is something along those lines in the
Object Graphic Library (part of wxPython) =3D- see the wxPython demo
(under miscellaneous / OGL - night give you a start towards what you
want.




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

[Pythoncard-users] dbBrowser sample now supports sqlite2

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

If you read your Daily Python ( http://www.pythonware.com/daily/ ) you 
might notice that pysqlite2 (final - i.e. non-beta) was released today. 
As it happens, I spent a couple of hours today playing with it, and 
decided a good way to get to know it better would be to add support for 
pysqlite2 into the dbBrowser sample.

I just downloaded and tested the released version (actually, 2.0.1) and 
it is fine.

As well as support for the basic dbBrowser, there is also a utility to 
convert a CSV file with headers into a sqlite database. It does only 
trivial checks that the headers are suitable names to be db column names 
- but other than that it's an easy way to create a sqlite database to 
play with, and the utility program itself is a simple, but non-trivial, 
example of using pysqlite2.

(The documentation on pysqlite2 is, um, sparse  .....)

So if you get the latest PythonCard from CVS, you'll get this sample.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.11 - Release Date: 16/05/2005

Re: [Pythoncard-users] greedy events / double buffering?

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.11 - Release Date: 16/05/2005

[Pythoncard-users] greedy events / double buffering?

[Sean D. <se...@tr...>]

I've been using PythonCard for simple interfaces for about a year now.
Recently I decided to try something much more complex - implementing a
custom interface inside a BitmapCanvas. There are two problems I'm
facing at the moment:

=20

* I can't seem to fire a mouseDown event without blocking mouseMove
events until I get a mouseUp event. This basically means I can't click
and drag something interactively inside the BitmapCanvas.

* I can't figure out how to double-buffer the BitmapCanvas. I'd like to
do a clear() and then redraw my interface without causing the canvas to
blink. Is there a way to do some kind of buffer toggling from inside
PythonCard?

=20

I'd much appreciate if anyone has some sage advice.

=20

By the way, what I'm really trying to do is create a simple interface
for creating node graphs: the kind you see in 2D graphics compositing
programs/visual programming languages where you can arrange node
operators and interconnect them to form a data flow. If anyone knows of
a free Python (or even C++) API for doing this, let me know!

=20

Thanks,

Sean

=20

Re: [Pythoncard-users] No Module named PythonCard Prototype

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

Brian Facey wrote:

>Dear Pythoncard Users,
>
>I recently installed Python 2.4.1, PythonCard-0.8.1, simpleParse
>2.0.1a3, wxPython 2.6.0.0 (ANSI) for Python 2.4 and vb2py 0.2.1 and
>vb2pygui-0.2.1.
>
>When tried to launch vb2pygui :
>
>python ./lib/site-packages/vb2pygui/vb2puyGUI.pyw
>
>Traceback(most recent call last):
>
>File ./lib/site-packages/vb2pygui/vb2puyGUI.pyw, line 6, in ?
>
>got ImportError: No Module named PythonCard Prototype.
>
>Please advise on what I missed or what is needed to make vb2pygui launch
>properly.
>  
>
PythonCardPrototype was the old name used by Pythoncard, prior to 0.8
It looks like vb2Py hasn't been updated in a while (last version was 
January 2004), so it needs the very old version (0.7.3.1 is still 
available from www.pythoncard.org).

There's no problem with having the old and current versions on your 
system at the same time, because they use different package names - but 
if you do use the old one, you'll be missing out on a lot of 
improvements and features in the latest version.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 12/05/2005

[Pythoncard-users] No Module named PythonCard Prototype

[Brian F. <fac...@ba...>]

Dear Pythoncard Users,

I recently installed Python 2.4.1, PythonCard-0.8.1, simpleParse
2.0.1a3, wxPython 2.6.0.0 (ANSI) for Python 2.4 and vb2py 0.2.1 and
vb2pygui-0.2.1.

When tried to launch vb2pygui :

python ./lib/site-packages/vb2pygui/vb2puyGUI.pyw

Traceback(most recent call last):

File ./lib/site-packages/vb2pygui/vb2puyGUI.pyw, line 6, in ?

got ImportError: No Module named PythonCard Prototype.

Please advise on what I missed or what is needed to make vb2pygui launch
properly.

Thanks,

Brian

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor - now at v0.3

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

"""
__version__ = "$Revision: 1.136 $"
__date__ = "$Date: 2005/03/28 17:29:37 $"
"""

import wx
import event
import error
import font
import graphic
import component


def makeNewId(id):
    if id == -1:
        return wx.NewId()
    else:
        return id


class WidgetSpec( component.ComponentSpec ) :
    def __init__( self, name, parent, events, subclassAttributes ) :
        events.extend( event.WIDGET_EVENTS )
        attributes = {
            'id':{'presence':'optional', 'default':-1},
            'enabled' : { 'presence' : 'optional', 'default' : 1 },
            'visible' : { 'presence' : 'optional', 'default' : 1 },
            'foregroundColor' : { 'presence' : 'optional', 'default' : None },
            'backgroundColor' : { 'presence' : 'optional', 'default' : None },
            #'helpText' : { 'presence' : 'optional', 'default' : '' },
            'toolTip' : { 'presence' : 'optional', 'default' : '' },
            'font' : { 'presence' : 'optional', 'default' : None },
            'position' : { 'presence' : 'optional', 'default' : [ -1, -1 ] },
            'size' : { 'presence' : 'optional', 'default' : [ -1, -1 ] },
            'nameSpecified' : {'presence':'optional', 'default': 0 },
            'labelSpecified' : {'presence':'optional', 'default': 0 },
            'userdata' : {'presence':'optional', 'default':''}
            }
        attributes.update(subclassAttributes)
        component.ComponentSpec.__init__( self, name, parent, events, attributes )        
       

class Widget(component.Component):
    """
    The base class for all of our GUI controls.
    Each Widget must bind itself to the wxPython
    event model.  When it receives an event
    from wxPython, it will convert the event
    to a PythonCArd event.Event ( SelectEvent, ClickEvent,
     etc ) and post the event to the EventQueue.
    """
   # _spec = WidgetSpec()

    def __init__(self, aParent, aResource):
        component.Component.__init__(self, aResource)
        self._parent = aParent
        self._resource = aResource
        self._setNameSpecified(self._resource.nameSpecified)
        self._setLabelSpecified(self._resource.labelSpecified)                
        self._setUserdata(self._resource.userdata)
        # KEA 2004-04-23
        # Controls are enabled and visible by default
        # so no need to enable and call Show unless False.
        if not self._resource.enabled:
            self._setEnabled(self._resource.enabled)
        if not self._resource.visible:
            self._setVisible(self._resource.visible)
        if self._resource.foregroundColor is not None:
            self._setForegroundColor(self._resource.foregroundColor)
        if self._resource.backgroundColor is not None:
            self._setBackgroundColor(self._resource.backgroundColor)
        if self._resource.toolTip != "":
            self._setToolTip(self._resource.toolTip)
        if self._resource.font is None:
            self._font = None
        else:
            self._setFont(font.Font(self._resource.font, self))

    def __repr__(self):
        return str(self.__dict__)

    def _getId(self):
        # KEA 2004-04-20
        # the id is generated using makeNewId by the base wxPython control
        return self.GetId()

    def _setId(self, id):
        raise AttributeError, "id attribute is read-only"

    # KEA 2004-04-21
    # finding the parent is probably going to be a common task
    # I'm tempted to make this a read-only attribute like id
    # but the user would never specify it, so it won't show up
    # in the spec, but before that is done the framework, samples,
    # and tools have to be checked for use of a parent variable
    def getParent(self):
        return self.GetParent() 
    
    def _getToolTip(self):
        try:
            return self.GetToolTip().GetTip()
        except:
            return ""
    
    def _getFont(self):
        if self._font is None:
            desc = font.fontDescription(self.GetFont())
            self._font = font.Font(desc)
        return self._font
    
    def _setForegroundColor( self, aColor ) :
        aColor = self._getDefaultColor( aColor )
        self.SetForegroundColour( aColor )
        self.Refresh()   # KEA wxPython bug?
    
    def _setBackgroundColor( self, aColor ) :
        aColor = self._getDefaultColor( aColor )
        self.SetBackgroundColour( aColor )
        self.Refresh()   # KEA wxPython bug?
        
    def _setToolTip(self, aString):
        toolTip = wx.ToolTip(aString)
        self.SetToolTip(toolTip)
    
    def _setFont(self, aFont):
        if isinstance(aFont, dict):
            aFont = font.Font(aFont, aParent=self)
        else: # Bind the font to this widget.
            aFont._parent = self
        self._font = aFont
        aWxFont = aFont._getFont()
        self.SetFont( aWxFont )

    def _getNameSpecified(self):
        return self._nameSpecified

    def _setNameSpecified(self, aBoolean):
        self._nameSpecified = aBoolean

    def _getLabelSpecified(self):
        return self._labelSpecified

    def _setLabelSpecified(self, aBoolean):
        self._labelSpecified = aBoolean

    def _getUserdata(self):
        return self._userdata 

    def _setUserdata(self, aString):
        self._userdata = aString

    def _getDefaultColor( self, aColor ) :
        if aColor is None :
            return wx.NullColour
        else :
            # KEA 2001-07-27
            # is the right place for this check?
            if isinstance(aColor, tuple) and len(aColor) == 3:
                return wx.Colour(aColor[0], aColor[1], aColor[2])
            else:
                return aColor

    # KEA 2004-04-16
    # can the method below be replaced with
    #setFocus = wx.Window.SetFocus
    # even if Widget doesn't subclass wx.Window?
    # the same issue applies to other aliases that might be created
    # above and below
    # if not perhaps Widget should subclass wx.Window?
    def setFocus(self):
        self.SetFocus()

    def _getPosition(self):
        # get the actual position, not (-1, -1)
        return self.GetPositionTuple()  

    def _setPosition(self, aPosition):
        self.Move(aPosition)

    def _getSize(self):
        # return the actual size, not (-1, -1)
        return self.GetSizeTuple()

    def _setSize(self, aSize):
        self.SetSize(aSize)

    def _getEnabled(self):
        return self.IsEnabled()

    def _setEnabled(self, aBoolean):
        self.Enable(aBoolean)

    def _getVisible(self):
        return self.IsShown()

    def _setVisible(self, aBoolean):
        self.Show(aBoolean)

    def _getForegroundColor(self):
        return self.GetForegroundColour()

    def _getBackgroundColor(self):
        return self.GetBackgroundColour()

    def redraw(self):
        """Force an immediate redraw without waiting for an event handler to finish."""
        self.Refresh()
        self.Update()

    # KEA 2004-04-16
    # if a subclass overrides any of the methods below then it needs to
    # set the property as well so the appropriate method gets used
    backgroundColor = property(_getBackgroundColor, _setBackgroundColor)
    font = property(_getFont, _setFont)
    foregroundColor = property(_getForegroundColor, _setForegroundColor)
    enabled = property(_getEnabled, _setEnabled)
    id = property(_getId, _setId)
    #position = property(wx.Window.GetPositionTuple, wx.Window.Move)
    position = property(_getPosition, _setPosition)
    size = property(_getSize, _setSize)
    toolTip = property(_getToolTip, _setToolTip)
    nameSpecified = property(_getNameSpecified, _setNameSpecified)
    labelSpecified = property(_getLabelSpecified, _setLabelSpecified)
    userdata = property(_getUserdata, _setUserdata)
    visible = property(_getVisible, _setVisible)

    # KEA 2004-05-02
    # this will probably end up in Scriptable or Component
    # it should be completely generic
    # the only problem part would be the reference to the parent (background)
    # where the events are actually defined which would make this problematic
    # for a compound component or events bound to a Panel
    # what we really want is a reference to the application instance
    # there is probably some method to give us that in wxWidgets
    # UPDATE - I think GetTopLevelParent is what I was looking for
    def _bindEvents(self, eventList):
        # shouldn't components be subclasses of Scriptable?
        # components would have their own handlers but when
        # looking for a handler match it will search the parents
        # for now just grab handlers from the background
        
        # the references below would be self.findHandler instead of
        # background.findHandler
        
        # KEA 2004-09-13
        # switching back to the earlier hack for finding the parent background
        # in order to support the PageBackground experiments
        #background = self.GetParent().GetParent()
        parent = self.GetParent()
        if isinstance(parent, wx.Dialog):
            background = parent
        else:
            background = parent.GetParent()

        if wx.GetApp()._showDebugMenu:
            bindUnusedEvents = True
        else:
            bindUnusedEvents = False
        
        # helper variable to simplify test for whether to bind InsteadOfTypeEvents
        # there is a good chance we will need to know
        # which events are bound, if we want to dynamically add or remove
        # events later, so go ahead and keep a reference to the list
        self.boundEvents = {}
        
        self.eventIdToHandler = {}
        self.wxEventIdMap = {}

        if 0:
            print "\nBINDING...", self.name

        actionBindings = {}
        if self.actionBindings is not None:
            actionBindings = self.actionBindings
        for eventClass in eventList:
        #for eventClass in ButtonEvents:
            # need to figure out a way to avoid the need
            # for this id to class mapping which is used in _dispatch below
            self.wxEventIdMap[eventClass.id] = eventClass
            # command handler overrides normal mouseClick or select handler
            # so dispatch will automatically dispatch to the command handler
            # by looking up the handler this way
            # it also means that if there is a command association with this component
            # then the regular mouseClick or select handler will never be bound, just ignored
            if issubclass(eventClass, event.CommandTypeEvent) and self.command:
                handler = background.findHandler('on_' + self.command + '_command')
                if not handler:
                    handler = background.findHandler('on_' + self.name + '_' + eventClass.name)
            else:
                handler = background.findHandler('on_' + self.name + '_' + eventClass.name)
            if not handler:
                handler = background.findHandler('on_' + eventClass.name)
            if not handler:
                handlerData = actionBindings.get(eventClass.name)
                if handlerData is not None:
                    handlerObjectName, handlerFunction = handlerData
                    handlerObject = background.components.get(handlerObjectName)
                    if handlerObject is not None:
                        handler = getattr(handlerObject, handlerFunction, None)
                    if not handler:
                        handler = background.findHandler('on_' + handlerObjectName + '_' + handlerFunction)
            if handler or bindUnusedEvents:
                # only bind events that have an event handler
                # in this scenario unused events are never bound
                # which is more efficient, but the Message Watcher needs
                # to be changed
                # alternatively we can bind everything and then in _dispatch
                # if there isn't a match in eventIdToHandler then we know
                # the event isn't used and we can set used to False
                # the complication would be that we probably have to have to
                # always call Skip() which may or may not be a hassle with components
                
                # this doesn't bind command events
                # they would be of the form on_somename_command
                # or perhaps on_command but I don't think we would want
                # to support that
                # the event binding would be specific to a component
                # since on dispatch command overrides something like mouseClickEvent
                # but the name of the command is not related to the component
                # need to look at whether self.command has a value and then bind
                # with ButtonMouseClickEvent.binding if that isn't already bound
                # then in dispatch have to check again I think
                
                # need to avoid double binding
                # also binding shouldn't be order-specific
                # so how to avoid binding mouseDrag to _dispatch
                # if mouseMove is already bound or if binding mouseMove
                # not rebinding if mouseDrag is already bound
                # perhaps MouseDragEvent keeps a reference to MouseMoveEvent
                # and that is inserted into boundEvents, then we check boundEvents
                # prior to rebinding?
                if not self.boundEvents.get(eventClass.binding, None):
                    self.Bind(eventClass.binding, self._dispatch)
                    self.boundEvents[eventClass.binding] = eventClass.name
                if handler:
                    if 0:
                        print "  binding", self.name, eventClass.name, handler.__name__, eventClass.id
                    # KEA 2004-05-02
                    # change to just using the method directly, Handler class not needed
                    # actually the Handler class isn't needed at all
                    # so if the initial list built to simplify findHandler
                    # just stores a reference to the method that would be fine
                    # as long as the whole system uses that
                    # the only reason we don't just build the list ourselves
                    # in _bindEvents is that every component needs to do findHandler
                    # so it is more efficient to do once when the Scriptable object
                    # is created than to reparse for each component
                    #self.eventIdToHandler[eventClass.id] = handler
                    #self.eventIdToHandler[eventClass.id] = handler.getFunction()
                    self.eventIdToHandler[eventClass.id] = handler

        if 0:
            print "\n  boundEvents:"
            for name in self.boundEvents.values():
                print "   ", name
            print "\n\n"
            print "\n  self.eventIdToHandler:"
            for id in self.eventIdToHandler:
                # KEA 2004-05-02
                # change to just using the method directly, Handler class not needed
                #print "   ", id, self.eventIdToHandler[id]._function
                print "   ", id, self.eventIdToHandler[id]
            print "\n\n"

    def _dispatch(self, aWxEvent):
        eventType = aWxEvent.GetEventType()
        eventClass = self.wxEventIdMap[eventType]
        
        eventClassInstance = eventClass()
        # decorate will add the relevant event attributes
        aWxEvent = eventClassInstance.decorate(aWxEvent, self)

        if self.command and isinstance(eventClassInstance, event.CommandTypeEvent):
            # need to report the name for the handler if it exists
            eventName = 'command ' + self.command
        else:
            if isinstance(eventClassInstance, event.InsteadOfTypeEvent):
                # changes eventType if needed
                # e.g. mouseDrag instead of mouseMove
                eventType = eventClassInstance.translateEventType(aWxEvent)
            eventName = self.wxEventIdMap[eventType].name
            
        # cleanup
        eventClass = None
        eventClassInstance = None

        # it shouldn't be possible to be in _dispatch for an event
        # that wasn't bound above, but just in case...
        # KEA 2004-05-02
        # change to just using the method directly, Handler class not needed
        #handler = self.eventIdToHandler.get(eventType, None)
        handler = self.eventIdToHandler.get(eventType, None)
        # KEA 2005-03-28
        # don't fire events when objects are in the process of being deleted
        if handler and not aWxEvent.target.IsBeingDeleted():
            event.EventLog.getInstance().log(eventName, self.name, True)
            if 0:
                print "dispatching", handler.__name__
            # make a lowercase alias
            aWxEvent.skip = aWxEvent.Skip

            # the event handlers are part of the Background so
            # we have to have a reference to call the handler below
            
            # if Scriptable takes over the dispatch then
            # this would need to work differently if the actual
            # handler could be somewhere else
            
            # KEA 2004-09-13
            # switching back to the earlier hack for finding the parent background
            # in order to support the PageBackground experiments
            #background = self.GetParent().GetParent()
##            background = wx.GetTopLevelParent(self)
            parent = self.GetParent()
            if isinstance(parent, wx.Dialog):
                background = parent
            else:
                background = parent.GetParent()

            # this is what is in event.py
            # aHandler.getFunction()( aOwner, self.getSource(), self )
            # KEA 2004-05-02
            # change to just using the method directly, Handler class not needed
            #handler.getFunction()(background, aWxEvent)
            handler(background, aWxEvent)
            
            # do we have to clean up this alias?
            aWxEvent.skip = None
            # how about this local reference to handler?
            handler = None
            background = None
        else:
            event.EventLog.getInstance().log(eventName, self.name, False)
            # hopefully this is all we need to do for "unused events"
            aWxEvent.Skip()

        # cleanup
        aWxEvent.target = aWxEvent.eventObject = None


class Panel(wx.Panel):

    def __init__(self, aParent, imageFile, tiled):
        wx.Panel.__init__(self, aParent, -1, 
            style=wx.TAB_TRAVERSAL | wx.NO_FULL_REPAINT_ON_RESIZE)
        self._frame = aParent
        self._imageFile = imageFile
        self._backgroundTiling = tiled
        # KEA 2001-07-27
        # Load the bitmap once and keep it around
        # this could fail, so should be a try/except.
        if imageFile is not None :
            self._bitmap = graphic.Bitmap(imageFile)
            wx.EVT_ERASE_BACKGROUND( self, self.onEraseBackground )
            
        wx.EVT_WINDOW_DESTROY(self, self._OnDestroy)

    def _OnDestroy(self, event):
        # memory leak cleanup
        self._bitmap = None

    def tileBackground(self, deviceContext):
        # tile the background bitmap
        sz = self.GetClientSize()
        bmp = self._bitmap.getBits()
        w = bmp.GetWidth()
        h = bmp.GetHeight()

        if isinstance(self, wx.ScrolledWindow):
            # adjust for scrolled position
            spx, spy = self.GetScrollPixelsPerUnit()
            vsx, vsy = self.GetViewStart()
            dx,  dy  = (spx * vsx) % w, (spy * vsy) % h
        else:
            dx, dy = (w, h)

        x = -dx
        while x < sz.width:
            y = -dy
            while y < sz.height:
                deviceContext.DrawBitmapPoint(bmp, (x, y))
                y = y + h
            x = x + w

    def getForegroundColor(self):
        return self.GetForegroundColour()

    def getBackgroundColor(self):
        return self.GetBackgroundColour()

    def _getDefaultColor(self, aColor):
        if aColor is None :
            return wx.NullColour
        else :
            # KEA 2001-07-27
            # is the right place for this check?
            if isinstance(aColor, tuple) and len(aColor) == 3:
                return wx.Colour(aColor[0], aColor[1], aColor[2])
            else:
                return aColor
            
    def setForegroundColor(self, aColor):
        aColor = self._getDefaultColor(aColor)
        self.SetForegroundColour(aColor)
        self.Refresh()   # KEA wxPython bug?
    
    def setBackgroundColor(self, aColor):
        aColor = self._getDefaultColor(aColor)
        self.SetBackgroundColour(aColor)
        self.Refresh()   # KEA wxPython bug?

    def onEraseBackground(self, aWxEvent):
        deviceContext = aWxEvent.GetDC()
        
        if not deviceContext :
            deviceContext = wx.ClientDC(self)
            r = self.GetUpdateRegion().GetBox()
            deviceContext.SetClippingRegion(r.x, r.y, r.width, r.height)
                                                       
        if self._backgroundTiling:
            self.tileBackground( deviceContext )
        else:
            deviceContext.DrawBitmapPoint(self._bitmap.getBits(), (0, 0))

    position = property(wx.Panel.GetPositionTuple, wx.Panel.SetPosition, doc="position of the panel") 
    size = property(wx.Panel.GetSizeTuple, wx.Panel.SetSize, doc="size of the panel") 

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor - now at v0.3

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

Alex Tweedley wrote on 05/06/2005 03:53:27 PM:

> 
> > Unfortunately, 0.3 will not be out tonight as previously expected.
> 
> Version 0.3 is now available, at 
> www.tweedly.net/Python/newresourceEditorv0.3.zip 
> Note in particular the need to update Pythoncard/widget.py for this 
> version.

I am trying .3 for the first time with PythonCard .82, and have replaced
the widget.py. I notice that the CVS version number on your widget.py (
1.133)
is older than the one in PythonCard .82  (1.136).

When I launch the NewResourceEditor.0.3, I get the following error:

oms-ballen:~ ballen$ pythonw2.4 
/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py 
Traceback (most recent call last):
  File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", 
line 11904, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
  File "/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py", line 163, 
in on_initialize
    self.components[sizingHandle] = self.sizingHandleTemplate
  File "/OMS/dev/pythonPackages/PythonCard/model.py", line 98, in 
__setitem__
    control = component.ComponentFactory().createComponent(self.parent, 
self.parent.panel, item)
  File "/OMS/dev/pythonPackages/PythonCard/component.py", line 347, in 
createComponent
    component = clazz(aParent, aResource)
  File "/OMS/dev/pythonPackages/PythonCard/components/image.py", line 70, 
in __init__
    widget.Widget.__init__( self, aParent, aResource )
  File "/OMS/dev/pythonPackages/PythonCard/widget.py", line 63, in 
__init__
    component.Component.__init__(self)


At that point, the new ResourceEditor launches, but when I create a widget 
I get a similar
error:

TypeError: __init__() takes exactly 2 arguments (1 given)
Traceback (most recent call last):
  File "/OMS/dev/pythonPackages/PythonCard/menu.py", line 204, in 
_dispatch
    handler(background, aWxEvent)
  File "/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py", line 1685, 
in on_componentAdd_command
    self.create_component(desc)
  File "/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py", line 1543, 
in create_component
    self.components[name] = desc
  File "/OMS/dev/pythonPackages/PythonCard/model.py", line 98, in 
__setitem__
    control = component.ComponentFactory().createComponent(self.parent, 
self.parent.panel, item)
  File "/OMS/dev/pythonPackages/PythonCard/component.py", line 347, in 
createComponent
    component = clazz(aParent, aResource)
  File "/OMS/dev/pythonPackages/PythonCard/components/textfield.py", line 
85, in __init__
    widget.Widget.__init__(self, aParent, aResource)
  File "/OMS/dev/pythonPackages/PythonCard/widget.py", line 63, in 
__init__
    component.Component.__init__(self)

Re: [Pythoncard-users] anchor layout manager

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005

Re: [Pythoncard-users] anchor layout manager

[Michael S. <mik...@ya...>]

--- Alex Tweedly <al...@tw...> wrote:
> Michael Sorich wrote:
> 
> >Attached is my latest attempt at a simple layout
> >manager. Once again, it is based on anchors with
> >automatic partitioning of the background into a
> grid
> >based on the positioning of expandable components.
> >Major changes from the previous attempt include:
> >  
> >
> >3) can now anchor so relative position of component
> to
> >both sides is held constant (component size does
> not
> >change)
> >
> >An example is attached. If anyone has a pythoncard
> >example where they have used wx sizers, see if this
> >method can replicate the result. Alternatively,
> send
> >the code to me and I will give it a go. 
> >  
> >
> The findfiles tool that comes with PythonCard is a
> good example using 
> sizers.

Findfiles seems to be a very simple example - the
listResults expands in the x and y dimensions and the
rest of the components remain anchored left and above.
Simply set the xAnchor and yAnchor values for
listResults (defaults will suffice for the rest) and
pass the components to GridAnchorLayout. Also, the
components defined in the resource file need to be
properly laid out (presumably because sizers were to
be used and hence positioning them well did not
matter). This reproduces the sizing on my windows box.
I don't have a Mac or a computer running Linux, so I
can't tell how cross platform the result is.

self.components.listResults.xAnchor = 'Both (resize)'
self.components.listResults.yAnchor = 'Both (resize)'
self.panel.layoutManager =
anchor.GridAnchorLayout(self.components)
self.visible = True
##self.sizerLayout()
 
> >I think that this method would be enhanced if it
> could
> >be complemented with an easy means of using
> splitter
> >windows (the split would not need to be visible or
> >user adjustable). This method divides the
> background
> >into a grid. In some/many cases different parts of
> the
> >background should have separate grids. 
> >
> >This method deals with resizing/repositioning of
> the
> >components with a change in the background size. It
> >does not deal with changes as a result of font size
> >changes.
> >  
> >
> I had to change your code slightly - in anchor.py,
> there were 3 cases of
>      for component in self.components:
> that needed to be
>      for component in self.components.itervalues(): 

Sorry about this. I find calling .itervalues()
unintuitive and have made components directly
iterable. I should remove the alteration so I am a
forced to use itervalues. 

> I also noticed that if I made the window wide
> enough, button3 and 
> button1 would overlap - was that expected ?

Due to the reduction in the number of gridlines
produced, it is now possible to set the anchors such
that the components overlap upon expansion of the
container (an obvious example having 2 components and
setting the left one to be right anchored and the
right one to be left anchored). In the example
provided only Button3 and StaticText2 have their
anchors explicitly set. All the rest are using default
values. The default value for buttons is left and
above. Button1 (and StaticText1) should really have
xAnchor = 'Right'. I originally had the default anchor
being the closest gridline, however in some examples
this did not come out right and it seemed to be best
to stick to left and above. I don't think that it will
be possible to correctly set anchors automatically for
all components.

> For splitter lines: I'd suggest a (temporary)
> convention using "Static 
> line"s that follow some naming scheme, e.g.
>  any Static Line whose name is anchorXyz is used as
> a splitter

I am not sure how this would work. Eg if you had a
horizontal static line that spanned only half the x
range of the container, what would this mean? Would
this be equivalent to a horizontal splitter at y =
staticLine.position[1]?  I think The alternative would
be too complicated. What happens when there are both
horizontal and vertical staticLineSplitters? Unless
placed well, it would be difficult to tell which takes
precedence (with 2 partions there are 2 choices for
producing 3 regions as would occur with a splitter
window) or whether they cross and produce a grid with
4 regions. I am not sure whether it would be more
difficult to write this hack or to simply tackle the
container issues of pythoncard :) 

>  there is a call available to turn all such lines
> invisible
>      (I almost said do that automatically - but it
> would be interesting 
> for now to see them, so make it under prog control)
> 
> Do you think there's room for using "Static box" in
> a similar way - the 
> box is treated as a separate sub-grid ?

I am not sure. I think that it is very important to
have use cases of layouts that need to be handled.
Most of the pythoncard samples are either trivial or
the components placed so haphazardly that I cannot
tell how they should be repositioned/resized.

> The biggest thing I'd like to see, which I think
> should be possible, is 
> to combine the anchor/constraint scheme with sizers
> used at the level of 
> built-in components. i.e. as you do the sizing, you
> allow components to 
> produce their own min size according to "standard"
> sizer methods, and 
> then use that within the constraint layout. IF
> that's possible, then I 
> think you have a good chance of overcoming the most
> significant 
> advantage of sizer schemes (automatic handling of
> cross-platform font 
> and decoration variations).

Is it possible to simulate cross-platform changes in
fonts etc using a single platform (windows in my
case)? Perhaps by simply changing the font? It would
make it easier to test some of these layout methods. I
suspect the repositioning/resizing method used to
adjust to font changes would be quite different to
adjusting to container resizing. I presume that the
adjustments would only need to be done once (at
initialization). If so, the font and container
adjustments would probably operate independently. When
the app is initialized the layout is adjusted for the
font used. Subsequently the container resizing layout
manager is initialized and used.

I am not completely sure what you are getting at in
regard to using "sizers at the level of built-in
components". Is this simply in regard to querying the
components for their minSize? If you could give and
example, it would be great.

Thanks for the comments.

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



Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Re: [Pythoncard-users] anchor layout manager

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

Michael Sorich wrote:

>Attached is my latest attempt at a simple layout
>manager. Once again, it is based on anchors with
>automatic partitioning of the background into a grid
>based on the positioning of expandable components.
>Major changes from the previous attempt include:
>  
>
>3) can now anchor so relative position of component to
>both sides is held constant (component size does not
>change)
>
>An example is attached. If anyone has a pythoncard
>example where they have used wx sizers, see if this
>method can replicate the result. Alternatively, send
>the code to me and I will give it a go. 
>  
>
The findfiles tool that comes with PythonCard is a good example using 
sizers.

>I think that this method would be enhanced if it could
>be complemented with an easy means of using splitter
>windows (the split would not need to be visible or
>user adjustable). This method divides the background
>into a grid. In some/many cases different parts of the
>background should have separate grids. 
>
>This method deals with resizing/repositioning of the
>components with a change in the background size. It
>does not deal with changes as a result of font size
>changes.
>  
>
I had to change your code slightly - in anchor.py, there were 3 cases of
     for component in self.components:
that needed to be
     for component in self.components.itervalues():

I also noticed that if I made the window wide enough, button3 and 
button1 would overlap - was that expected ?

For splitter lines: I'd suggest a (temporary) convention using "Static 
line"s that follow some naming scheme, e.g.
 any Static Line whose name is anchorXyz is used as a splitter
 there is a call available to turn all such lines invisible
     (I almost said do that automatically - but it would be interesting 
for now to see them, so make it under prog control)

Do you think there's room for using "Static box" in a similar way - the 
box is treated as a separate sub-grid ?

The biggest thing I'd like to see, which I think should be possible, is 
to combine the anchor/constraint scheme with sizers used at the level of 
built-in components. i.e. as you do the sizing, you allow components to 
produce their own min size according to "standard" sizer methods, and 
then use that within the constraint layout. IF that's possible, then I 
think you have a good chance of overcoming the most significant 
advantage of sizer schemes (automatic handling of cross-platform font 
and decoration variations).


-- Alex.

 

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 10/05/2005

[Pythoncard-users] anchor layout manager

[Michael S. <mik...@ya...>]

Attached is my latest attempt at a simple layout
manager. Once again, it is based on anchors with
automatic partitioning of the background into a grid
based on the positioning of expandable components.
Major changes from the previous attempt include:

1) number of partitions minimised

2) adding it to your applications is simplified
>>import anchors
add line to on_initialize
>>self.panel.layoutManager =
anchor.GridAnchorLayout(self.components)

3) can now anchor so relative position of component to
both sides is held constant (component size does not
change)

An example is attached. If anyone has a pythoncard
example where they have used wx sizers, see if this
method can replicate the result. Alternatively, send
the code to me and I will give it a go. 

I think that this method would be enhanced if it could
be complemented with an easy means of using splitter
windows (the split would not need to be visible or
user adjustable). This method divides the background
into a grid. In some/many cases different parts of the
background should have separate grids. 

This method deals with resizing/repositioning of the
components with a change in the background size. It
does not deal with changes as a result of font size
changes.

Thanks to Alex for his help.

Cheers,

Michael

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

[Pythoncard-users] Relative file names for image/imageButton

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

I think there's a problem with the way relative file names are currently 
used for image and imageButtons.

The filename is taken as a path relative to the application directory. 
This is problematic for two reasons

1. It's different from what the resourceEditor does - it takes the file 
name to be relative to the directory in which the resource file being 
edited resides.

2. It makes it difficult to build a library of multiple-use dialogs or 
child windows, since the image files need to be replicated within (or 
relative to) each application directory.

For example, in the (new) resource Editor, the directory structure is

  editor /
         / images
         / modules
                   / propertyEditor.py
                     propertyEditor.rsrc.py

The propertyEditor resource now includes imageButtons - and the image 
files need to be in editor/images for when the application runs - but 
need to be in editor/modules/images in order to edit the resource file. 
(Currently I have duplicated the images as a short-term workaround).

I propose that we change this such that when the resource file is read 
by the running application, it will check whether the file exists 
relative to the application directory, and if it does not, will look for 
it relative to the resource file's directory. This has the advantage of 
being upwards compatible - all existing cases will continue to work, 
while allowing new cases to (automatically) use resource-relative paths 
- hence allowing re-usable dialogs and child windows by default.  It 
will also thus be possible to put application-specific image files in 
the application-relative directory to override the default images.

[ There is an alternative approach, which would store the 
resource-directory path when the resource file is read - and do the 
directory substitution when the image is used. This is more complex, and 
doesn't seem tome to offer any significant advantage. ]

If no one comes up with a disadvantage to this approach, or other reason 
not to do it, I'll go ahead and make this change.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 06/05/2005

Re: [Pythoncard-users] Slider in 0.81

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

Bernie Hogan wrote:

>Hi Everyone, 
>
><gripe>
>Using the slider in the resource editor (pyCard 0.81) is a nightmare.
>
I haven't used sliders much (ok- I've only ever used them in the last 5 
minutes ...), so need to ask for a bit more info.

> The
>numbers don't line up spontaneously,
>
I don't see any problem with the numbers lining up - the min and max 
values look to be fully aligned, and the "current value" box is aligned 
with the top of the min text (which means the actual characters are down 
a few pixels). Is that the problem - or is there something I haven't 
seen yet ?   If it the alignment of current with min/max, it's almost 
certainly a wxWidgets issue.

>sometimes it decides to resize the
>slider to (-15, -1), 
>
I'm pretty sure that'll be part of the general resizing problem - fixed 
in the experimental resource editor. I'm hoping it proves to be both 
stable and popular enough to replace the current resource Editor - but 
even if it isn't, the 2 or 3 actual bug fixes found so far will be 
backported to the current one.

>and recently its been deciding that my names with
>underscores are not allowed (using a dialog that I can't clear - leading to
>me killing without saving)
>  
>
I've never got completely stuck in the dialog - I can always get out 
after 2 or three tries, and changing the name back to a valid one let's 
me carry on.

Currently, "_" is disallowed in component names - but the checks are 
incomplete, so they can slip through in some places. (As a workaround, 
you can use Copy/Paste to create a new component with the name you want, 
rather than renaming the  existing component).

The reason for this restriction is because the "_"s are used to pick 
apart names for the automatic event binding. I suspect that it would be 
possible to (partially) relax this restriction.

However, I believe that we should keep the restriction that component 
names must not start with an underscore (and perhaps also that they must 
not finish with one).  Would your names be OK with that restriction ?

>I also noticed that the numbers on the slider are not on the same pane.
>  
>
Sorry - you got me there .... what do you mean ?

></gripe>
>
>Was the slider a late introduction? 
>
Doesn't seem like it - it was there at least as early as 0.7.3 
(according to the docs - I didn't really use anything earlier than 0.8, 
so can't confirm it).

>It seems much less solid than the other widgets. Has it been fixed a more recent release? 
>
No (except for the resizing issue).  And the naming restriction seems 
like it should be easily fixable.

>Is this really a wxPython problem in disguise?
>  
>
The alignment might be.
The problem of needing to click in the main (slider) part to select the 
component to move it is (indirectly) a wxWidget problem.
The name restriction certainly isn't.
.

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



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 04/05/2005

[Pythoncard-users] Slider in 0.81

[Bernie H. <ber...@ut...>]

Hi Everyone, 

<gripe>
Using the slider in the resource editor (pyCard 0.81) is a nightmare. The
numbers don't line up spontaneously, sometimes it decides to resize the
slider to (-15, -1), and recently its been deciding that my names with
underscores are not allowed (using a dialog that I can't clear - leading to
me killing without saving).

I also noticed that the numbers on the slider are not on the same pane.
</gripe>

Was the slider a late introduction? It seems much less solid than the other
widgets. Has it been fixed a more recent release? Is this really a wxPython
problem in disguise?

Take Care,
BERNiE

 

--