pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] migration guide for release 0.8

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

Additional dialog migration issues below.

ka

On Aug 14, 2004, at 12:08 PM, Kevin Altis wrote:

> Dialogs
> The dialog module is now a thin wrapper around the wx.lib.dialogs 
> module. The biggest change to your code is that the result of dialogs 
> is now a DialogResults class instead of a dictionary. See the dialogs 
> sample for examples of usage, but in general if you had something like 
> result['accepted'] it will now be result.accepted.

The order of the message and title args for any dialogs that take both 
has been reversed from previous versions of PythonCard. The message arg 
comes before title now. For example,

     dialog.singleChoiceDialog(self, "message", "title", ['one', 'two', 
'three'])

Any optional style args now use wx constants rather the old dialog 
module aliases. For example, you'll need to use wx.TE_PASSWORD or 
wx.TE_MULTILINE for the textEntryDialog if you want one of those 
styles.

[Pythoncard-users] migration guide for release 0.8

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

The first pass of a migration guide for release 0.8 is below. I would 
really appreciate feedback from everyone on the list, but particularly 
anyone porting their code to run with release 0.8 (in cvs) from 
PythonCardPrototype 0.7.3.1.

http://cvs.sourceforge.net/viewcvs.py/pythoncard/PythonCard/

All of the PythonCard samples and tools have already been done, so it 
is hard for me to pinpoint mistakes and oversights I may have made 
below. I plan to start updating many of the documentation files this 
weekend, so that hopefully release 0.8 can be completed in the next 
week.

I'll try to fix any bugs, odd behavior, etc. that people report before 
making a release.

Thanks,

ka
---

Migration Guide

Last changed 2004-08-14.

Introduction
The purpose of this guide is to help people migrate their programs 
written for PythonCardPrototype release 0.7.3.1 to release 0.8. For a 
complete list of changes, please refer to the changelog.txt file. All 
the samples and tools included with PythonCard have already been 
updated to the new API, so you can also look at that code for examples. 
Some of the documentation included with PythonCard may still refer to 
the older APIs. If you spot a mistake, please email me at 
al...@se... and I will update the documentation for the next 
release.

Version 0.8 is the first release on the way to finalizing the 
PythonCard API for a 1.0 release later this year or early 2005, 
whenever wxPython 2.6 is released. Like previous releases of the 
prototype package (PythonCardPrototype) you can expect changes from 
release to release until version 1.0 is done. One of the biggest 
changes to be aware of is that PythonCard is now keeping pace with each 
new wxPython release with the intent of basing the PythonCard 1.0 API 
on wxPython 2.6, thus the minimum requirements have been changed. 
wxPython 2.4.x will not be supported by PythonCard, there are simply 
too many changes and no effective way to maintain a code base that 
supports older wxPython releases. In addition, Python 2.2.x will not be 
supported.


Minimum Requirements
Python 2.3 or later and wxPython 2.5.2.7 or later.


Package Name Change
The main package name has changed from PythonCardPrototype to 
PythonCard. Since the package name has been changed it is possible to 
run older PythonCardPrototype programs even with the new package 
installed.


Resource File Changes
The Stack class was removed, so the first line of your .rsrc.py file 
needs to have the 'stack' and 'Stack' strings replaced with 
'application' and 'Application' as shown below.

{ 'stack':{ 'type':'Stack',

to

{ 'application':{ 'type':'Application',

In addition, in your source, self.stack.app references are now just 
self.application.


PythonCardApp Class Renamed
PythonCardApp was renamed to Application. The application 
initialization and startup code for your module will need to be updated 
to use the Application class. For example, here's the new code for the 
minimal sample.

if __name__ == '__main__':
     app = model.Application(Minimal)
     app.MainLoop()


Events
openBackground was renamed to initialize, so rename your 
on_openBackground event handlers to on_initialize.

restore (inverse of minimize) and deactivate (inverse of activate) 
background window events were added.

The event binding and dispatch system was completely rewritten and 
simplified for release 0.8. If you were using any of the internal event 
classes or relying on how events were bound and dispatched, you should 
double-check your code to make sure it still works. A complete 
discussion of the changes is not appropriate for this document, so 
please bring up any issues you have on the pythoncard-users mailing 
list.


New-style Classes and Attributes (Properties)
wxPython now uses new-style classes. This allowed the PythonCard 
components to be changed to use the property() function for attributes 
instead of __getattr__ and __setattr__ methods. Once again, this 
dramatically simplified the framework sources for components. In 
addition, we were able to remove get/set methods for position, size, 
foregroundColor, backgroundColor, etc. in the Background and 
CustomDialog classes and replace those get/set methods with attributes.


selection and stringSelection Attributes
The Choice, ComboBox, List, RadioGroup components were updated to use 
'selection' and 'stringSelection' attributes instead of 
mixed-capability 'selected' and 'selection' attributes. If you were 
using these attributes previously, you will have to update both your 
source and resource files.


mixedCase Method Names
All methods in PythonCard exposed to user code now use the mixedCase 
naming style to distinguish PythonCard methods from wxPython, which 
uses the CamelCase style for method names. In the PythonCard shell, the 
wxPython method names are suppressed in the auto-complete popup window.


wx Import Change
All imports from the wxPython.wx package have been changed to use the 
new wx package. For example:

from wxPython import wx

has been changed to

import wx

The biggest impact is that the wx prefix is no longer used (e.g. 
wx.wxFrame is now wx.Frame) in the framework or samples except for 
wxPython constants.


Module Names Changes

Old          New
-----------------------------
config.py    configuration.py
pom.py       component.py
res.py       resource.py


Added Modules
timer.py contains a simple wx.Timer class wrapper.


Deleted Modules
dispatch.py


Dialogs
The dialog module is now a thin wrapper around the wx.lib.dialogs 
module. The biggest change to your code is that the result of dialogs 
is now a DialogResults class instead of a dictionary. See the dialogs 
sample for examples of usage, but in general if you had something like 
result['accepted'] it will now be result.accepted.


Calendar Component
The Calendar component was changed to use the 
CAL_SEQUENTIAL_MONTH_SELECTION style. A style attribute may need to be 
added to the Calendar component in future releases to allow different 
calendar styles to be used.


Image Component
PythonCard now uses wx.lib.statbmp.GenStaticBitmap on GTK for the Image 
component so that the Image component can get mouse events on all 
platforms. If you want to use a bitmap with transparency, then you'll 
also want to use the Image component to get the same appearance on all 
platforms.


StatusBar
statusbar.StatusBar a direct subclass of wx.StatusBar so it is now 
possible to provide your own StatusBar subclass to use instead of the 
default. See the createStatusBar method in model.py


Miscellaneous
Renamed stc-styles.rc.cfg to stc-styles.cfg, but this shouldn't impact 
any user programs.

[Pythoncard-users] [wxPython-users] ANN: wxPython 2.5.2.7

[Robin D. <ro...@al...>]

Announcing
----------

I'm pleased to announce the 2.5.2.7 release of wxPython, now available
for download at http://wxpython.org/download.php or
https://sourceforge.net/project/showfiles.php? 
group_id=10718&package_id=10559&release_id=260444


What is wxPython?
-----------------

wxPython is a GUI toolkit for the Python programming language. It
allows Python programmers to create programs with a robust, highly
functional graphical user interface, simply and easily. It is
implemented as a Python extension module that wraps the popular
wxWidgets cross platform GUI library, which is written in C++.

wxPython is a cross-platform toolkit. This means that the same program
will usually run on multiple platforms without modifications.
Currently supported platforms are 32-bit Microsoft Windows, most Linux
or other Unix-like systems using GTK or GTK2, and Apple Macintosh OS
X.


Changes in 2.5.2.7
------------------

The changes in this version are too numerous to list here, please see
the following web sites for more details.  If you are upgrading from a
previous version then please do read the MigrationGuide fully before
getting started as there are some backwards incompatible changes.

      http://wxpython.org/recentchanges.php
      http://wxpython.org/migrationguide.php


New Docs
--------

Also available with this release is a sneak peak at the work in
progress for the new Python-specific reference documentation.  While
much of the content is not yet present, the docs are still usable, and
in fact helpful since they already accurately document what classes
and methods are present in wxPython and what the parameter names
are. You can download a tarball containing the new docs by following
the wxPythonNewDocs link on the download page, and it can also be
accessed online at http://wxPython.org/docs/api/.


-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!


---------------------------------------------------------------------
To unsubscribe, e-mail: wxP...@li...
For additional commands, e-mail: wxP...@li...

Re: [Pythoncard-users] need opinions on two changes for 0.8

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

On Aug 12, 2004, at 5:39 AM, Alex Tweedly wrote:

> At 10:31 10/08/2004 -0700, Kevin Altis wrote:
>
>
>> The two issues I want comments on are whether to leave the 
>> BitmapCanvas draw operations as separate x, y and width, height args 
>> or to use tuples (x, y) and (width, height). What's in cvs right now 
>> are tuple versions, but since wxPython switched back to separate args 
>> after the 2.5.1.5 outcry, my inclination on odd days is to go ahead 
>> and switch back as well since it matches the wxPython arg list and is 
>> probably simpler for people to remember. On even days I think using 
>> tuples is more consistent since it matches the init args for 
>> components, but the wxPython API uses both forms for a lot of 
>> different methods. As a brief example, here's drawLine as used in the 
>> doodle sample with separate args followed by tuple args. If nobody 
>> replies I'll go ahead and revert all the sample, BitmapCanvas, etc. 
>> before 0.8 is released.
>>
>> event.target.drawLine(self.x, self.y, x, y)
>>
>> event.target.drawLine((self.x, self.y), (x, y))
>
> No big deal either way - I'd go with the same as wxPython; the easier 
> it is to slip past Pythoncard into wxPython (when necessary) the 
> better.

I'm flip flopping again, so I'm going to hold off on this change and 
ponder it while the dialog changes below get a little more testing.

>> The second issue is that for a long time I've been thinking about 
>> just using the wx.lib.dialogs function wrappers for system dialogs 
>> instead of the ones in PythonCard.dialog. I wrote most of the code in 
>> wx.lib.dialogs last year, so it has the same goal as the current 
>> PythonCard dialog code, which is to make all system dialogs function 
>> calls. However, the arg lists are changed, mostly for the better, and 
>> the result is a class instead of a dict. What I plan to do is leave 
>> the PythonCard.dialog module in place, but just import the 
>> appropriate functions from wx.lib.dialogs or provide thin wrappers 
>> where PythonCard still needs some special handling such as the result 
>> returned by the fontDialog. This change will impact every sample and 
>> tool that uses system dialogs as well as the documentation Dan Shafer 
>> wrote, so I don't want to switch if everyone is going to complain and 
>> I have to switch all the code back. Again, if there aren't a lot of 
>> dissents, I'll make the change later this week. Anyone that is 
>> interested in the changes, should just look at the wx.lib.dialogs.py 
>> code in wxPython 2.4.2.4 or later.
>
> Any chance you could provide a simple "what the code looks like before 
> and after" example to make it easier to have an opinion on this one ?
>

Too late, I just did a massive check-in. I won't be surprised if I made 
a typo here and there, but after doing extensive searches of the 
sources I'm pretty sure I obliterated all traces of the old dictionary 
style access. The only system dialog that needed more than an alias was 
fontDialog, so dialog.py has been dramatically simplified. I also 
updated samples and tools using CustomDialog to use the 
dialog.DialogResults class.

Anyone working from cvs, could always save a copy of their current 
PythonCard package and sub-dirs for comparison. However, as a simple 
example, here's a common usage of the openFileDialog from the 
codeEditor in the old and new forms.

OLD:
         result = dialog.openFileDialog(None, 
self.resource.strings.openFile, '', '', wildcard)
         if result['accepted']:
             path = result['paths'][0]

NEW:
         result = dialog.openFileDialog(None, 
self.resource.strings.openFile, '', '', wildcard)
         if result.accepted:
             path = result.paths[0]

The result is an instance of the DialogResults class now, so "dot 
notation" is used to access an attribute rather than accessing a 
dictionary key in the old form. Another change is that if you were 
using constants such as dialog.ICON_INFORMATION you now have to use the 
equivelant wx constants which typically just requires substituting wx 
for dialog (e.g. wx.ICON_INFORMATION).

Since all of the samples and tools were updated to the new form there 
are plenty of examples, just use findfiles to search for dialog\. or 
result\.accepted, dialog\.messageDialog, etc.

ka

Re: [Pythoncard-users] PythonCard Background as a child window of wxPython App

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

On Aug 12, 2004, at 11:37 AM, bartek wilczynski wrote:

> Great thanks, I think I'm getting to the final solution (or rather 
> workaround
> ;). The only thing I can't do is creating this "invisible" PythonCard 
> background
> - i can run everything fine, but the resource i have to provide need 
> to contain
> at least one background - otherwise it refuses to start.
>

In the Background Info dialog in the resourceEditor there is an option 
for "Visible at Startup" which you just need to uncheck.

ka

Re: [Pythoncard-users] PythonCard Background as a child window of wxPython App

[bartek w. <ba...@re...>]

Great thanks, I think I'm getting to the final solution (or rather workaround
;). The only thing I can't do is creating this "invisible" PythonCard background
- i can run everything fine, but the resource i have to provide need to contain
at least one background - otherwise it refuses to start.
-- 
   Bartek Wilczynski


Cytowanie Kevin Altis <al...@se...>:

> On Aug 12, 2004, at 9:45 AM, Bartosz Wilczy¨˝ski wrote:
> 
> > Thanks for your quick response,
> >
> > If I understand You correctly, I should, in a way, wrap my whole 
> > wxPython
> > Application in a non visible PythonCard App,
> > but it brings me to another question :
> >
> > How do I start my wxPython App as a child window of PythonCardApp ?
> >
> > Thanks again for your help (and for PythonCard in general :)
> > -- 
> >    Bartek Wilczynski
> >
> You won't be able to start another wx.App instance. Instead you'll just 
> move whatever app initialization you need and make your own wx.Frames 
> child windows of the main PythonCard background which can be created 
> during the openBackground event handler. For example, here's a simple 
> addition to the minimal sample using PythonCard 0.7.3.1 syntax.
> 
> import wx
> 
> class Minimal(model.Background):
>      def on_openBackground(self, event):
>          self.rawWx = wx.Frame(self, -1, 'plain wxPython window', 
> pos=(100, 30), size=(200, 100))
>          self.rawWx.Show()
> 
> You could subclass model.PythonCardApp, call its __init__ as part of 
> your __init__ and then do the rest of your initialization there.
> 
> ka
> 
> 
> ------------------------------
> Scanned for viruses by MKS_Vir
> Last update:
> ------------------------------
> 

Re: [Pythoncard-users] PythonCard Background as a child window of wxPython App

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

On Aug 12, 2004, at 9:45 AM, Bartosz Wilczy=A8=BDski wrote:

> Thanks for your quick response,
>
> If I understand You correctly, I should, in a way, wrap my whole=20
> wxPython
> Application in a non visible PythonCard App,
> but it brings me to another question :
>
> How do I start my wxPython App as a child window of PythonCardApp ?
>
> Thanks again for your help (and for PythonCard in general :)
> --=20
>    Bartek Wilczynski
>
You won't be able to start another wx.App instance. Instead you'll just=20=

move whatever app initialization you need and make your own wx.Frames=20
child windows of the main PythonCard background which can be created=20
during the openBackground event handler. For example, here's a simple=20
addition to the minimal sample using PythonCard 0.7.3.1 syntax.

import wx

class Minimal(model.Background):
     def on_openBackground(self, event):
         self.rawWx =3D wx.Frame(self, -1, 'plain wxPython window',=20
pos=3D(100, 30), size=3D(200, 100))
         self.rawWx.Show()
=00
You could subclass model.PythonCardApp, call its __init__ as part of=20
your __init__ and then do the rest of your initialization there.

ka

Re: [Pythoncard-users] PythonCard Background as a child window of wxPython App

[Bartosz <ba...@mi...>]

Thanks for your quick response,

If I understand You correctly, I should, in a way, wrap my whole wxPython
Application in a non visible PythonCard App,
but it brings me to another question :

How do I start my wxPython App as a child window of PythonCardApp ?

Thanks again for your help (and for PythonCard in general :)
-- 
   Bartek Wilczynski


Citing Kevin Altis <al...@se...>:

> I don't think you're going to be able to do this without some clunky 
> workaround. If you created a background that isn't visible as your main 
> PythonCard window and started as a PythonCard app, then your wxPython 
> window could be set to be your main top level window and it would look 
> just the same as if you started as a wxPython app. When you need to 
> create your PythonCard child window you can call child window using the 
> hidden window as the parent then store a reference to the child in your 
> wxPython window as well.
> 
> There is a lot of initialization that is done for PythonCard when the 
> application is created, so without having a base PythonCard app a lot 
> of variables just don't exist. The childWindow function itself is very 
> simple, so you could do your own version to work around the parent 
> problem.
> 
> ka
> On Aug 11, 2004, at 11:55 PM, Bartosz Wilczy¨˝ski wrote:

Re: [Pythoncard-users] PythonCard Background as a child window of wxPython App

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

I don't think you're going to be able to do this without some clunky=20
workaround. If you created a background that isn't visible as your main=20=

PythonCard window and started as a PythonCard app, then your wxPython=20
window could be set to be your main top level window and it would look=20=

just the same as if you started as a wxPython app. When you need to=20
create your PythonCard child window you can call child window using the=20=

hidden window as the parent then store a reference to the child in your=20=

wxPython window as well.

There is a lot of initialization that is done for PythonCard when the=20
application is created, so without having a base PythonCard app a lot=20
of variables just don't exist. The childWindow function itself is very=20=

simple, so you could do your own version to work around the parent=20
problem.

ka
On Aug 11, 2004, at 11:55 PM, Bartosz Wilczy=A8=BDski wrote:

> Hi,
>
> I'm trying to embed Pythoncard in an existing wxPython Application.=20
> What I want
> to do is to open a pythoncard background as a child window of my=20
> wxpython app.
>
> The problem I have is that I can either try to use
>
> model.childWindow(wxApp,someClass)
>
> - but it does not work as wxApp has no stack
>
> model.PythonCardApp(someClass)
>
> - which does the wxApp initialization again and breaks everything.
>
> There should be at least one (and preferably only one) elegant method=20=

> to do it.
>
> Anyone has any ideas ?
>
> Thanks for any help in advance
> --
>    Bartek Wilczynski

Re: [Pythoncard-users] need opinions on two changes for 0.8

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

At 10:31 10/08/2004 -0700, Kevin Altis wrote:


>The two issues I want comments on are whether to leave the BitmapCanvas 
>draw operations as separate x, y and width, height args or to use tuples 
>(x, y) and (width, height). What's in cvs right now are tuple versions, 
>but since wxPython switched back to separate args after the 2.5.1.5 
>outcry, my inclination on odd days is to go ahead and switch back as well 
>since it matches the wxPython arg list and is probably simpler for people 
>to remember. On even days I think using tuples is more consistent since it 
>matches the init args for components, but the wxPython API uses both forms 
>for a lot of different methods. As a brief example, here's drawLine as 
>used in the doodle sample with separate args followed by tuple args. If 
>nobody replies I'll go ahead and revert all the sample, BitmapCanvas, etc. 
>before 0.8 is released.
>
>event.target.drawLine(self.x, self.y, x, y)
>
>event.target.drawLine((self.x, self.y), (x, y))

No big deal either way - I'd go with the same as wxPython; the easier it is 
to slip past Pythoncard into wxPython (when necessary) the better.

>The second issue is that for a long time I've been thinking about just 
>using the wx.lib.dialogs function wrappers for system dialogs instead of 
>the ones in PythonCard.dialog. I wrote most of the code in wx.lib.dialogs 
>last year, so it has the same goal as the current PythonCard dialog code, 
>which is to make all system dialogs function calls. However, the arg lists 
>are changed, mostly for the better, and the result is a class instead of a 
>dict. What I plan to do is leave the PythonCard.dialog module in place, 
>but just import the appropriate functions from wx.lib.dialogs or provide 
>thin wrappers where PythonCard still needs some special handling such as 
>the result returned by the fontDialog. This change will impact every 
>sample and tool that uses system dialogs as well as the documentation Dan 
>Shafer wrote, so I don't want to switch if everyone is going to complain 
>and I have to switch all the code back. Again, if there aren't a lot of 
>dissents, I'll make the change later this week. Anyone that is interested 
>in the changes, should just look at the wx.lib.dialogs.py code in wxPython 
>2.4.2.4 or later.

Any chance you could provide a simple "what the code looks like before and 
after" example to make it easier to have an opinion on this one ?

Thanks
-- Alex Tweedly.

[Pythoncard-users] Debugger ?

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

What do you use to debug Pythoncard programs ?

Pythonwin naturally doesn't work.

IDLE works - but it seems to be pretty fragile (I've resorted to Task 
Manager to clean up 4 or 5 times in my first hour of trying to use it for 
Pythoncard programs). Even when "working", the shell appears to be 
disabled, so there's no way to examine variables beyond what the "locals" 
and "globals" choose to show you.

Is there another, better way ?

Thanks
-- Alex.

[Pythoncard-users] PythonCard Background as a child window of wxPython App

[bartek w. <ba...@re...>]

It seems that my message didn't make it to the list, so I'm resending in. I'm
sorry if it will appear more than once.

Hi,

I'm trying to embed Pythoncard in an existing wxPython Application. What I want
to do is to open a pythoncard background as a child window of my wxpython app.

The problem I have is that I can either try to use

model.childWindow(wxApp,someClass)  

- but it does not work as wxApp has no stack

model.PythonCardApp(someClass)

- which does the wxApp initialization again and breaks everything.

There should be at least one (and preferably only one) elegant method to do it.

Anyone has any ideas ?

Thanks for any help in advance
-- 
   Bartek Wilczynski 

[Pythoncard-users] PythonCard Background as a child window of wxPython App

[Bartosz <ba...@mi...>]

Hi,

I'm trying to embed Pythoncard in an existing wxPython Application. What I want
to do is to open a pythoncard background as a child window of my wxpython app. 

The problem I have is that I can either try to use

model.childWindow(wxApp,someClass)  

- but it does not work as wxApp has no stack 

model.PythonCardApp(someClass) 

- which does the wxApp initialization again and breaks everything.

There should be at least one (and preferably only one) elegant method to do it.

Anyone has any ideas ?

Thanks for any help in advance
--
   Bartek Wilczynski

[Pythoncard-users] need opinions on two changes for 0.8

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

It looks like the next release of wxPython is very close to being=20
ready. For those of you that want to test it and the version of=20
PythonCard that is in cvs, you can find wxPython 2.5.2 test candidates=20=

at:

http://starship.python.net/crew/robind/wxPython/preview/

2.5.2.4 is the most recent build as of this morning, but there will=20
likely be a 2.5.2.5 or 2.5.2.6 depending on issues people report to the=20=

wxPython-dev mailing list before the final 2.5.2 release.

Once that is available I plan to do a PythonCard 0.8 release, so I=20
would appreciate comments from anyone working from cvs that wants to=20
identify bugs or any other issues they find. PythonCard 0.8 requires=20
wxPython 2.5.2.x as a minimum!

The two issues I want comments on are whether to leave the BitmapCanvas=20=

draw operations as separate x, y and width, height args or to use=20
tuples (x, y) and (width, height). What's in cvs right now are tuple=20
versions, but since wxPython switched back to separate args after the=20
2.5.1.5 outcry, my inclination on odd days is to go ahead and switch=20
back as well since it matches the wxPython arg list and is probably=20
simpler for people to remember. On even days I think using tuples is=20
more consistent since it matches the init args for components, but the=20=

wxPython API uses both forms for a lot of different methods. As a brief=20=

example, here's drawLine as used in the doodle sample with separate=20
args followed by tuple args. If nobody replies I'll go ahead and revert=20=

all the sample, BitmapCanvas, etc. before 0.8 is released.

event.target.drawLine(self.x, self.y, x, y)=00

event.target.drawLine((self.x, self.y), (x, y))=00

The second issue is that for a long time I've been thinking about just=20=

using the wx.lib.dialogs function wrappers for system dialogs instead=20
of the ones in PythonCard.dialog. I wrote most of the code in=20
wx.lib.dialogs last year, so it has the same goal as the current=20
PythonCard dialog code, which is to make all system dialogs function=20
calls. However, the arg lists are changed, mostly for the better, and=20
the result is a class instead of a dict. What I plan to do is leave the=20=

PythonCard.dialog module in place, but just import the appropriate=20
functions from wx.lib.dialogs or provide thin wrappers where PythonCard=20=

still needs some special handling such as the result returned by the=20
fontDialog. This change will impact every sample and tool that uses=20
system dialogs as well as the documentation Dan Shafer wrote, so I=20
don't want to switch if everyone is going to complain and I have to=20
switch all the code back. Again, if there aren't a lot of dissents,=20
I'll make the change later this week. Anyone that is interested in the=20=

changes, should just look at the wx.lib.dialogs.py code in wxPython=20
2.4.2.4 or later.

ka=

[Pythoncard-users] PyUnicodeUCS2_AsWideChar

[John S. <sch...@co...>]

ImportError: /usr/lib/python2.3/site-packages/wx/_core.so: undefined 
symbol: PyUnicodeUCS2_AsWideChar

I'm running Fedora Core 1.  I installed the .gz file from sourceforge, 
and the samples emit the error message above.  Yum tells me I have 
recent stuff installed.

What should I do to try out pythoncard?

John

Re: [Pythoncard-users] thanks! pythoncard is great

[Steve C. <stn...@xm...>]

There's still a lot of work I need to do before it's ready. Mostly
speed-up, and some minor tweaks to the UI.  I also still need to get the
deck editor interface working.

I'm not sure how decent a sample it'll be, there is quite a bit of data
you'd need to download before it would work.  I'm planning to put it
onto SourceForge in the next couple weeks. 

-Steve

> Hey Steve,
> Sweet! Can I go ahead and add this to the list of more applications? In 
> other words, is the application available for download or would you 
> like to add it to the samples?
> 
> http://pythoncard.sourceforge.net/moreapplications.html
> 
> ka
> On Aug 6, 2004, at 5:49 PM, Steve Christensen wrote:
> 
> >I figured people like to see or hear about the applications people are
> >developing with PythonCard, so here's some information about what I'm
> >working on and also a thank-you for creating it.
> >
> >It's been very easy to work with. I was able to do all my development 
> >on
> >Linux and not have to change anything to run it on Windows.
> >
> >My application is a browser for Magic: The Gathering cards. A separate
> >script imports card lists/images from MTGPlay (http://www.mtgplay.com)
> >and the the official card lists from Wizards, and generates XML output.
> >The pythoncard app reads one or more of the XML files, and gives the
> >users optional filters to select which cards to display.
> >
> >For example, here's a screenshot of the results after filtering for all
> >cards with the word 'squirrel' in the rules printed in the card's rules
> >text:
> >
> >    http://www.xmission.com/~stnchris/mtgbrowse.jpg
> >
> >
> >-Steve
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

Re: [Pythoncard-users] Overlapping Image and TextField components

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Sat, 7 Aug 2004 08:47:06 -0700, Kevin Altis wrote:

>The Mac version of wxPython 2.5.2.3 is dramatically improved over 
>previous releases, but it still has some z-order issues and doesn't 
>really support overlapping widgets like you can do on Windows.

OK. At least now that I've worked out why the Background Info wasn't
working for me I can switch to that instead. 

>
>If you are using a background image set via the Background Info... 
>dialog instead of an actual component like Image, ImageButton, or 
>BitmapCanvas, then that is different since the background image is just 
>drawn on the panel and not actually an overlapping control. Using a 
>background image seems to work reasonably well on the Mac with the 
>upcoming wxPython release except that text fields will leave behind a 
>white rectangle when the field loses focus and it will probably require 
>an extra Refresh() and Update() call on the underlying panel to get 
>that to be cleaned up.

The background image I'm using is mostly white at the moment (a scanned
image of a paper report), so that's not too much of a problem. I was
planning on giving the controls a different background colour
(sorry...color) to make them stand out to the user, so I'll bear that in mind.

Neil

Re: [Pythoncard-users] Bitmap problem

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Sat, 7 Aug 2004 08:39:12 -0700, Kevin Altis wrote:

>There have been some wxWidget/wxPython bugs that could account for this  
>problem, but neither of the ones I submitted below actually led to an  
>assert.
>
>http://sourceforge.net/tracker/? 
>func=detail&aid=885104&group_id=9863&atid=109863
>
>http://sourceforge.net/tracker/? 
>func=detail&aid=909546&group_id=9863&atid=109863
>
>If you want, you can wait for wxPython 2.5.2.3 to be released or try  
>the wxPython-dev developer preview and see if it fixes the problem.
>
>http://starship.python.net/crew/robind/wxPython/preview/2.5.2.3/
>
>Of course, there could be a bug in PythonCard, but that sounds unlikely  
>given the error you reported.
>
>If the image can't be handled by wxWidgets, then I would like to get it  
>from you, but don't email it to the list. Send me an email offlist with  
>the size of the image and we'll figure out how to transfer it so I can  
>reproduce the problem.

(To the moderator(s): I posted this and the following message earlier
from the wrong email address and got a warning that they were on-hold -
please delete the old ones).

OK....cause found.

The image needs to be in the same directory as the resource file. If you
use the "File" browser button to select a graphic file from a different
directory then the path is not recorded in the resource file, just the
file name. Presumably if I wanted to use an image in a different
directory I could manually type in the path.

What confused me was the error message coming back from wxPython - the
invalid bitmap and handler errors don't make it clear that in fact the
problem is that the application can't find the file. Having said that,
the OSX error dialog's first line does give you a bit of a clue :-) Not
the Windows version though.

Neil

Re: [Pythoncard-users] Bitmap problem

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Sat, 7 Aug 2004 13:35:28 +0100, Andy Todd wrote:
>It's a bit tricky to figure out what's going on without your code. 
>Perhaps you could show us the method where you are loading up the bitmap.
>
>Even better, a version of the minimal sample including your code and 
>which shows the error would help the list subscribers to figure out what 
>may be going wrong.
>

The error's actually appearing in the console window for the resource
editor - I open the background info window and use the file browser
button for the "Image:" field, select the bitmap file and then try to
close the info window. Any redrawing of the resource window keeps
bringing up the error.

I just tried this on OSX and I get a dialog appearing with the following:
"Can't load image from file 'page1b.bmp': file does not exist.
no bitmap handler for type 1 defined"

This is with an existing project, or creating a new one and using the
resource editor 'wizard' to generate the necessary .rsrc.py file in while
case the background section looks like:
'backgrounds': [
    {'type':'Background',
     'name':'bgTemplate',
     'title':'Standard Template with File->Exit menu',
     'position':(267, 301),
     'size':(800, 600),
     'image':'page1b.bmp',
     'style':['resizeable'],

I decided to try out a 'safe' bitmap file of 640x480x8 bit (BMP and JPG)
but got the same issue.

Neil

Re: [Pythoncard-users] Overlapping Image and TextField components

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

On Aug 6, 2004, at 3:53 PM, XXXXXXXXXXX wrote:

> Is it OK to overlap Image and TextField components? As mentioned in
> another thread, I've used a large bitmap as an Image and place 
> TextField
> components on top. I've noticed a couple of things:
>
> 1) Every time I change a property in one of the TextFields, all of the
> TextFields redraw and the current one disappears behind the Image. I 
> can
> use the "move to front" to get it back, or if I save the resource 
> project
> then upon reloading the TextFields are still all on top.
>
> This is 0.7.3.1 on Windows NT SP6a
>
> 2) When I move the project to Mac OSX 10.3.3/Pythoncard 0.7.3.1 the
> TextFields are not visible - if you click in the right place in the
> resource editor then you can see the cursor and type into them, but 
> once
> you click elsewhere the contents disappear. If you run the project then
> again the TextFields appear but once you select them they stay on top.
>
> Using the resource editor's "move to front", etc. doesn't make any
> difference, but I think it's a drawing problem rather than a depth one
> (if that makes sense).
>
> Like I said, maybe I'm not using the components in the fashion they 
> were
> intended?
>
> Neil
>
The Mac version of wxPython 2.5.2.3 is dramatically improved over 
previous releases, but it still has some z-order issues and doesn't 
really support overlapping widgets like you can do on Windows.

If you are using a background image set via the Background Info... 
dialog instead of an actual component like Image, ImageButton, or 
BitmapCanvas, then that is different since the background image is just 
drawn on the panel and not actually an overlapping control. Using a 
background image seems to work reasonably well on the Mac with the 
upcoming wxPython release except that text fields will leave behind a 
white rectangle when the field loses focus and it will probably require 
an extra Refresh() and Update() call on the underlying panel to get 
that to be cleaned up.

ka

Re: [Pythoncard-users] Bitmap problem

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

On Aug 6, 2004, at 3:31 PM, XXXXXXXXXXX wrote:

> Hello..I'm just getting into Pythoncard, so if any of my questions fall
> into the categories of FAQ or RTFM, please don't hesitate to let me  
> know...
>
> I'm creating an application that mimics the output of a database report
> writer, allowing the user to add extra notes that get stored along with
> the "proper" data. To do this I want to display a bitmap - the sample  
> one
> to start is a little unusual - it's a 1000 x 630 pixels x 16-bit BMP
> file. When I try to use this in the resource editor as a background I  
> get:
>
> wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in
> ..\..\src\ms
> w\dc.cpp(1024): invalid bitmap in wxDC::DrawBitmap
>
> (this isn't the full traceback, but I have that if anyone's  
> interested).
>
> My first thought is that my bitmap is just too odd - would this be
> correct? I've worked around the problem by using the same bitmap file  
> in
> an Image component (some questions on that to follow!)
>
> Neil

There have been some wxWidget/wxPython bugs that could account for this  
problem, but neither of the ones I submitted below actually led to an  
assert.

http://sourceforge.net/tracker/? 
func=detail&aid=885104&group_id=9863&atid=109863

http://sourceforge.net/tracker/? 
func=detail&aid=909546&group_id=9863&atid=109863

If you want, you can wait for wxPython 2.5.2.3 to be released or try  
the wxPython-dev developer preview and see if it fixes the problem.

http://starship.python.net/crew/robind/wxPython/preview/2.5.2.3/

Of course, there could be a bug in PythonCard, but that sounds unlikely  
given the error you reported.

If the image can't be handled by wxWidgets, then I would like to get it  
from you, but don't email it to the list. Send me an email offlist with  
the size of the image and we'll figure out how to transfer it so I can  
reproduce the problem.

ka

Re: [Pythoncard-users] Bitmap problem

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

XXXXXXXXXXX wrote:
> Hello..I'm just getting into Pythoncard, so if any of my questions fall
> into the categories of FAQ or RTFM, please don't hesitate to let me know...
> 
> I'm creating an application that mimics the output of a database report
> writer, allowing the user to add extra notes that get stored along with
> the "proper" data. To do this I want to display a bitmap - the sample one
> to start is a little unusual - it's a 1000 x 630 pixels x 16-bit BMP
> file. When I try to use this in the resource editor as a background I get:
> 
> wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in
> ..\..\src\ms
> w\dc.cpp(1024): invalid bitmap in wxDC::DrawBitmap
> 
> (this isn't the full traceback, but I have that if anyone's interested).
> 
> My first thought is that my bitmap is just too odd - would this be
> correct? I've worked around the problem by using the same bitmap file in
> an Image component (some questions on that to follow!)
> 
> Neil
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

It's a bit tricky to figure out what's going on without your code. 
Perhaps you could show us the method where you are loading up the bitmap.

Even better, a version of the minimal sample including your code and 
which shows the error would help the list subscribers to figure out what 
may be going wrong.

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

Re: [Pythoncard-users] thanks! pythoncard is great

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

Hey Steve,
Sweet! Can I go ahead and add this to the list of more applications? In 
other words, is the application available for download or would you 
like to add it to the samples?

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

ka
On Aug 6, 2004, at 5:49 PM, Steve Christensen wrote:

> I figured people like to see or hear about the applications people are
> developing with PythonCard, so here's some information about what I'm
> working on and also a thank-you for creating it.
>
> It's been very easy to work with. I was able to do all my development 
> on
> Linux and not have to change anything to run it on Windows.
>
> My application is a browser for Magic: The Gathering cards. A separate
> script imports card lists/images from MTGPlay (http://www.mtgplay.com)
> and the the official card lists from Wizards, and generates XML output.
> The pythoncard app reads one or more of the XML files, and gives the
> users optional filters to select which cards to display.
>
> For example, here's a screenshot of the results after filtering for all
> cards with the word 'squirrel' in the rules printed in the card's rules
> text:
>
>     http://www.xmission.com/~stnchris/mtgbrowse.jpg
>
>
> -Steve

[Pythoncard-users] thanks! pythoncard is great

[Steve C. <stn...@xm...>]

I figured people like to see or hear about the applications people are
developing with PythonCard, so here's some information about what I'm
working on and also a thank-you for creating it.

It's been very easy to work with. I was able to do all my development on
Linux and not have to change anything to run it on Windows.

My application is a browser for Magic: The Gathering cards. A separate
script imports card lists/images from MTGPlay (http://www.mtgplay.com)
and the the official card lists from Wizards, and generates XML output.
The pythoncard app reads one or more of the XML files, and gives the
users optional filters to select which cards to display.

For example, here's a screenshot of the results after filtering for all
cards with the word 'squirrel' in the rules printed in the card's rules
text:

    http://www.xmission.com/~stnchris/mtgbrowse.jpg


-Steve

[Pythoncard-users] Bitmap problem

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

Hello..I'm just getting into Pythoncard, so if any of my questions fall
into the categories of FAQ or RTFM, please don't hesitate to let me know...

I'm creating an application that mimics the output of a database report
writer, allowing the user to add extra notes that get stored along with
the "proper" data. To do this I want to display a bitmap - the sample one
to start is a little unusual - it's a 1000 x 630 pixels x 16-bit BMP
file. When I try to use this in the resource editor as a background I get:

wx.core.PyAssertionError: C++ assertion "wxAssertFailure" failed in
..\..\src\ms
w\dc.cpp(1024): invalid bitmap in wxDC::DrawBitmap

(this isn't the full traceback, but I have that if anyone's interested).

My first thought is that my bitmap is just too odd - would this be
correct? I've worked around the problem by using the same bitmap file in
an Image component (some questions on that to follow!)

Neil