pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] PythonCard Error

[Phil E. <ph...@li...>]

On Friday 28 Apr 2006 14:00, Daniel Ryan wrote:
> Phil,
>
> Great- that worked.  Thanks!
>
> Now, another issue- I have my .exe file, but it works only when in the
> /dist directory where I created it.  If I move it to the desktop, it
> doesn't work.  Do I have to make sure I keep all the components in the
> /dist directory with it?
>

Yes, you do. That's why that folder is called 'dist' by default, because you 
have to distribute the contents in order to make your standalone version run 
on another computer. How you actually go about doing that is another whole 
discussion, although my preference is to use Inno Setup, which is a freeware 
software installer that you can download from:

http://www.jrsoftware.org/isdl.php

This packages up your program and all its supporting files into a single .EXE 
file which can be distributed to your end users. When they run it, your 
application is installed and an entry is added under Control Panel --> Add & 
Remove Software to allow the app to be un-installed easily as well.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] PythonCard Error

[Daniel R. <dv...@gm...>]

Phil,

Great- that worked.  Thanks!

Now, another issue- I have my .exe file, but it works only when in the /dis=
t
directory where I created it.  If I move it to the desktop, it doesn't
work.  Do I have to make sure I keep all the components in the /dist
directory with it?

Thanks,
Dan

On 4/28/06, Phil Edwards <ph...@li...> wrote:
>
> On Friday 28 Apr 2006 03:42, Daniel Ryan wrote:
> > All,
> >
> > I'm a newbie in the PythonCard world, and I'm encountering an error whe=
n
> I
> > use py2exe to create a stand-alone executable.  My error log looks like
> > this:
> > Traceback (most recent call last):
> >   File "GUI.py", line 555, in ?
> >   File "PythonCard\model.pyc", line 337, in __init__
> >   File "PythonCard\resource.pyc", line 48, in getResource
> >   File "PythonCard\resource.pyc", line 86, in __init__
> >   File "PythonCard\resource.pyc", line 91, in __init__
> >   File "PythonCard\resource.pyc", line 91, in __init__
> >   File "PythonCard\resource.pyc", line 96, in __init__
> >   File "PythonCard\resource.pyc", line 139, in enforceSpec
> >   File "PythonCard\resource.pyc", line 30, in loadComponentModule
> > ImportError: cannot import module 'staticline
> >
> > Anybody encounter this before/know the way to fix it?
> >
>
> Yup - what you need to do is add a line into your code which explicitly
> imports the required PythonCard components. For your GUI.py program,
> you'll
> need to add something like:
>
> from PythonCard.components import staticline, statictext, textarea, \
>     button
>
> Since these are the components you've got in your GUI.rsrc.py file. Just
> FYI,
> I'm using your code to help debug the latest version of standaloneBuilder=
,
> with some help from Alex Tweedly.
>
> --
>
> Regards
>
> Phil Edwards
> Brighton, UK
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>



--
Daniel Ryan
(410) 271-9673 (cell)

Re: [Pythoncard-users] PythonCard Error

[Phil E. <ph...@li...>]

On Friday 28 Apr 2006 03:42, Daniel Ryan wrote:
> All,
>
> I'm a newbie in the PythonCard world, and I'm encountering an error when I
> use py2exe to create a stand-alone executable.  My error log looks like
> this:
> Traceback (most recent call last):
>   File "GUI.py", line 555, in ?
>   File "PythonCard\model.pyc", line 337, in __init__
>   File "PythonCard\resource.pyc", line 48, in getResource
>   File "PythonCard\resource.pyc", line 86, in __init__
>   File "PythonCard\resource.pyc", line 91, in __init__
>   File "PythonCard\resource.pyc", line 91, in __init__
>   File "PythonCard\resource.pyc", line 96, in __init__
>   File "PythonCard\resource.pyc", line 139, in enforceSpec
>   File "PythonCard\resource.pyc", line 30, in loadComponentModule
> ImportError: cannot import module 'staticline
>
> Anybody encounter this before/know the way to fix it?
>

Yup - what you need to do is add a line into your code which explicitly 
imports the required PythonCard components. For your GUI.py program, you'll 
need to add something like:

from PythonCard.components import staticline, statictext, textarea, \
    button

Since these are the components you've got in your GUI.rsrc.py file. Just FYI, 
I'm using your code to help debug the latest version of standaloneBuilder,  
with some help from Alex Tweedly.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] PythonCard Error

[Daniel R. <dv...@gm...>]

All,

I'm a newbie in the PythonCard world, and I'm encountering an error when I
use py2exe to create a stand-alone executable.  My error log looks like
this:
Traceback (most recent call last):
  File "GUI.py", line 555, in ?
  File "PythonCard\model.pyc", line 337, in __init__
  File "PythonCard\resource.pyc", line 48, in getResource
  File "PythonCard\resource.pyc", line 86, in __init__
  File "PythonCard\resource.pyc", line 91, in __init__
  File "PythonCard\resource.pyc", line 91, in __init__
  File "PythonCard\resource.pyc", line 96, in __init__
  File "PythonCard\resource.pyc", line 139, in enforceSpec
  File "PythonCard\resource.pyc", line 30, in loadComponentModule
ImportError: cannot import module 'staticline

Anybody encounter this before/know the way to fix it?

Thanks,
Dan

Re: [Pythoncard-users] PythonCard, tree control, drag and drop

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

Aaron Howard wrote:

>I haven't really gone very far into the drag and drop functionality yet;
>I am putting this out to the mailing list for feedback, etc.  I'm
>basically trying to merge items via drag and drop.  
>  
>
If you need drag-and-drop (purely) within the tree, there is pretty good 
support built into the treeCtrl.

Basic examples (mentioned in case you didn't see them already) are in :
PythonCard / samples / minimalTree
wx Demo under Core Windows and controls / TreeCtrl
and then for drag/drop example, look at
http://wiki.wxpython.org/index.cgi/DragAndDropWithFolderMovingAndRearranging


>Also, as a dragged item moves across other items, I want to update the
>selected item to reflect which item the user would be dropping the
>dragged one onto as well as update the mouse cursor to indicate items
>that cannot be dropped onto.  (For instance, items could only be merged
>with items of the same depth on the tree or possibly promoted to a
>higher level, but not demoted, so to speak.)  Is there a "circle with a
>line through it" mouse pointer?  
>
>  
>
This (basic version) is done by treeCtrl's built-in support - but I 
think if you need the dynamic feedback to be different for each item you 
could drop onto then you'll need to take over the drag move response 
yourself.
See under wxCursor (wx.CURSOR_NO_ENTRY maybe ?)

>Lastly, should I be able to do this in a way that will work seamlessly
>on both Linux and Windows systems?
>
>I'm just getting started adding the drag and drop to this application so
>I'll be testing ideas over the next few days.  Any feedback is greatly
>appreciated.
>  
>
-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 24/04/2006

[Pythoncard-users] Proposal for adding sizer support to PythonCard and the layoutEditor

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

Comments, suggestions, or any other feedback, welcome.

Aims

1. To provide support for sizer-based layouts, making it easy to design 
new projects which are fully based on a set of hierarchical sizers.

2. To continue to support absolute position based layout.

3. To make it easy to convert an existing absolute position based 
project into a sizer based one.

Summary.

Add a new child window to the layoutEditor (sizerWindow), which holds 
the tree of sizers and components. It will also hold a separate tree of 
"unplaced" components - i.e. those components from the absolute layout 
which have not yet been placed into the sizer tree. It will be possible 
to create new sizers and add them to this "unplaced" tree, and indeed to 
add components to such sizers, prior to placing the sizer into the real 
application sizer tree.

The user will be able to select components (one or more) in the layout 
window or in the sizerWindow, and then allocate those components into a 
sizer in the sizerTree; each sizer or component will have the obvious 
parameters set (e.g. weight, position, growability, etc.)

The ideal edit mode for moving components into the sizer tree is 
probably drag-and-drop, but because of the limitations on how items can 
be dropped into a treeCtrl, the initial version will use right-clicking 
on the tree to provide a pop-up menu providing options (e.g. edit 
properties, unplace, add selected components before, add selected 
components after, etc.)

Since no component can be placed more than once in the placed sizer 
tree, we can "fake" the ability to select sizers in the layout window. 
When "placing selected components" into a sizer, any component which has 
already been allocated to a sizer will not be (cannot be) allocated; 
however if this applies to all components within a particular sizer 
(i.e. they have all been selected), then that sizer will be allocated. 
This will facilitate the building of sizer trees "bottom-up" from an 
existing absolute position layout.

Impact on infrastructure.

The sizer information will be kept in the "background" dictionary within 
the resource file, under the key name "sizers". This will contain a list 
of sizers, each of which is a dictionary containing a name, type, flags, 
and "contents" - a list of items (components or sizers) or, in the case 
of  GridBagSizer,  a list of lists of items.  There will also be a new 
piece of background info which indicates that the sizer info is to be used.

This is therefore fully backward compatible - existing versions of the 
framework will silently ignore this entry (assuming it is correct Python 
code). New version of the framework used with old resource files will, 
based on the lack of  "useSizer" info will also ignore it, but if the 
useSizer flag is set they will instantiate a sizer tree, and also set 
the 'visible' flag to False for any components not listed in the sizer 
tree (thereby allowing the user to override the placement of complex 
examples, such as the layoutEditor itself, which use overlapping 
alternate components, etc.).

When the useSizer flag is being set true within the layoutEditor, or 
thereafter when the file is saved, the user will be warned if there are 
any such unplaced components being set to invisible.

Debugging ?

Fairly soon, wxWidgets (or maybe wxPython) will include the ability to 
get visual indication of the sizer boundaries, but until then the sizer 
layout will include the ability to display these; and in addition there 
will be an ability to provide log / print info on the sizers being 
added. The layoutEditor will also be able to output Python code 
equivalent to the specified sizers, which will give an alternative way 
to understand and debug the resulting layouts.

Phases of development.

Phase 1.

Framework. Build the code to be used within the application to create 
sizers and add the components to them. Initially this will be supplied 
as a separate additional file - will be integrated with resource/model 
later.

Phase 2.

Add the basic sizerWindow, support BoxSizers only. Simple component 
selection and flag/parameter setting.

Phase 3.
Add support for GridBagSizers, probably help / tooltip / documentation / 
walkthrough / ...

Phase 4.
The rest :-)

Phase 5.
Add drag-and-drop, replacing treeCtrl with a custom control if needed.


I expect Phase 1 to be complete in a day or two, Phase 2 in a week or so 
(but I haven't used treeCtrl before, so this is subject to some 
uncertainty).


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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 24/04/2006

[Pythoncard-users] PythonCard, tree control, drag and drop

[Aaron H. <arc...@gm...>]

Hello all,

I have a PythonCard application using a tree control displaying
something akin to this:

- Root Item
  - Foo
    .Sub1
    .Sub2
  - Bar
    .Sub3
    .Sub4

And I want to enable a drag and drop feature where a user could just
grab "Bar" and drag it to "Foo" to get something akin to this:

- Root Item
  - Foo
    .Sub1
    .Sub2
    .Sub3
    .Sub4

I haven't really gone very far into the drag and drop functionality yet;
I am putting this out to the mailing list for feedback, etc.  I'm
basically trying to merge items via drag and drop. =20

Using the message watcher, I can see there is a mouseDrag event
occurring so I am quite sure I can do a .HitTest to determine which item
is being dragged.  I don't see a "mouseDrop" type event but I figure I
can just flag that a drag started and then trap the mouseUp event, do
another HitTest to determine which item the first was dropped onto and
go from there.

One thing I'd like to do as part of this for user feedback is to make it
visually appear the original item is indeed being "dragged" across the
screen.  I am thinking I could create a small opaque-ish window much
like a tooltip window that starts out on top of the selected item (the
item being dragged), with the same text in it, and moves with the mouse
during the drag, but is there any built-in functionality for doing that?

Also, as a dragged item moves across other items, I want to update the
selected item to reflect which item the user would be dropping the
dragged one onto as well as update the mouse cursor to indicate items
that cannot be dropped onto.  (For instance, items could only be merged
with items of the same depth on the tree or possibly promoted to a
higher level, but not demoted, so to speak.)  Is there a "circle with a
line through it" mouse pointer? =20

Lastly, should I be able to do this in a way that will work seamlessly
on both Linux and Windows systems?

I'm just getting started adding the drag and drop to this application so
I'll be testing ideas over the next few days.  Any feedback is greatly
appreciated.

Thanks in advance,

-Aaron Howard
Infinity Thrice, LLC
http://www.inthri.com

Re: [Pythoncard-users] XRC file support in PythonCard

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

On Apr 21, 2006, at 10:49 PM, Kevin Altis wrote:

>
> On Apr 19, 2006, at 2:34 PM, Winston Wolff wrote:
>
>> Is anybody thinking about integrating XRC files in PythonCard?
>>
>> Here are my reasons why it would be a good idea:
>> 	- Could use a number of GUI builders such as wxGlade.
>> 	- PythonCard's resourceEditor has problems including:
>> 		- on Mac OS X grow handles don't appear
>> 		- on Mac OS X sizes get "stuck" and I can't grow widgets
>> 		- Layouts/Sizers are not supported.
>>
>> I'm thinking about a resource loader in PythonCard that would load  
>> an .XRC file (XML file written out by wxGlade or XRCed) and then  
>> do the regular PythonCard magic for binding events to widgets.
>>
>> The great thing about PythonCard is how it links up widgets and  
>> handlers automatically, saving great amounts of time and  
>> simplifying your code.  Probably when it was first written,  
>> wxPython GUI editors were not very good, or didn't exist.  But now  
>> they are better than PythonCard's resourceEditor.  Let's leverage  
>> other's work on GUI editors, and take the good part from PythonCard.
>>
>> Would anybody use this?  Would I be allowed to add it to the  
>> sourceforge repository?  Any other technical issues?
>>
>> -Winston
>
> If all you really want is the auto-event binding that would be  
> relatively easy to separate from the rest of PythonCard. It could  
> even be done so that there isn't a central dispatcher if you don't  
> care about event tracing. What you would do is iterate over the  
> widgets after the XRC has been loaded. Dabo might be another tool  
> to look at.
>
> There isn't a one-to-one match between the standard  wxWidgets/ 
> wxPython widget attributes so at a minimum PythonCard would  
> probably need a custom XRC loader and some attributes that can be  
> set in the resourceEditor. For example, a wxButton in an XRC file  
> normally has the following possible attributes: XML ID, label,  
> default, pos, size, and style. In addition, it has the style  
> attributes: fg, bg, font, enabled, focused, hidden, tooltip. For  
> the most part the names are just different than what is used for  
> PythonCard so that is proably a simple translation. "XML ID" could  
> be treated as the PythonCard "name" attribute which is crucial for  
> event binding. The "command" attribute has no equivalent in XRC.
>
> Having PythonCard be able to support XRC files for resources that  
> follow some specific guidelines such as using XML ID as the "name"  
> probably wouldn't be that hard, though you might lose support for  
> some PythonCard attributes and/or wxWidget attributes that  
> PythonCard doesn't currently recognize. A module that was able to  
> load the XRC files directly would be preferable, but a conversion  
> tool would avoid requiring modification of the framework itself. If  
> the framework has to deal with it I suspect you would need to  
> "walk" the layout after it is loaded and translate between wxPython  
> attributes and PythonCard ones, doing GetXXX() method calls in most  
> cases.
>
> What is much more complicated and unlikely to happen is having the  
> resourceEditor be able to read and write generic XRC files. That  
> would be something to tackle after just being able to load was  
> implemented.
>
> ka
>

Another issue I forgot to mention is that none of the other layout  
tools that support XRC files are going to support PythonCard  
components which are all subclasses of wxPython controls. This means  
that even if you had a module that could load an XRC file and then  
bound the methods, you wouldn't have any of the helper methods or  
attributes so you would have to change the class of each object at  
runtime to the appropriate PythonCard component. Again, this makes an  
XRC -> PythonCard resource translator preferable for simplicity sake.

But the dabo approach to just embracing one form of sizer for layouts  
and abandoning fixed layouts except for backwards PythonCard 1.x  
compatibility is probably the right answer.

ka

Re: [Pythoncard-users] MulticolumnList and flatfiledatabase

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

On Mar 13, 2006, at 4:50 AM, David Bain wrote:

> I've created a variation of the flatfiledatabase example with a  
> MultiColumnList.
> But it won't save the content of the Multicolumn list.

MultiColumnList is not a supported data field type in the current  
flatfileDatabase.

ka

Re: [Pythoncard-users] Creating a timed dialog and mouse egg timer

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

Ray Allen wrote:

>Thanks - wx.BeginBusyCursor is just what I've been looking for with the 
>mouse, and I've just read a previous answer from you on using 
>wx.ProgressDialog (msg_id=8819839) which was very helpful too.  My code now 
>looks like this:
>
>  
>
ProgressDialog ? 

Hey, that's a good answer - wish I'd remembered that instead of what I 
suggested earlier :-)


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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 22/04/2006

Re: [Pythoncard-users] Creating a timed dialog and mouse egg timer

[Ray A. <ray...@sa...>]

Thanks - wx.BeginBusyCursor is just what I've been looking for with the 
mouse, and I've just read a previous answer from you on using 
wx.ProgressDialog (msg_id=8819839) which was very helpful too.  My code now 
looks like this:

wx.BeginBusyCursor()
wait=wx.ProgressDialog('Please wait..','Fetching attachment data',0)
...
wait.Destroy()
wx.EndBusyCursor()

Ray
----- Original Message ----- 
From: "Alex Tweedly" <al...@tw...>
To: "Ray Allen" <ray...@sa...>
Cc: <pyt...@li...>
Sent: Monday, April 24, 2006 12:25 PM
Subject: Re: [Pythoncard-users] Creating a timed dialog and mouse egg timer


Ray Allen wrote:

>I'd like to do two things in pythoncard related to informing the user that 
>a
>new modal child window is about to open (it involves fetching data and
>therefore can take a while): 1. Create a dialog that closes automatically
>when the child window opens (eg.  Please wait..data loading) and 2. give 
>the
>mouse arrow an egg timer.  Are these simple things to make happen in
>Pythoncard?   I'm hoping to stop the user repeatedly hitting a load button
>when the event has been called.  Thanks,
>
>

Yes, easy to do.

I don't think you want a dialog - a dialog *always* requires user input,
and after opening a dialog, control doesn't return to your code until
that user input has happened.

Two suggestions:

1. a simple child window containing the message. Create it as a child
window, separate resource file with just a static message. Mark it "not
visible on startup" in the layoutEditor's "Edit Background info".

In your initialization code,
   self.messageWindow = model.childWindow(self, message.MyBackground)

Then, when you start the process, you'd do something like
    self.messageWindow.visible = True
    wx.BeginBusyCursor()

and when the data is all loaded and you are ready to launch the real
child window, do
    self.messageWindow.visible = False
    wx.EndBusyCursor()

(btw - the Begins and Ends  must match - if there's any danger they
won't I've used the brute force method
    while wx.IsBusy():
          wx.EndBusyCursor()
)

Suggestion 2:
Use the child window you are loading the data for. On initial startup of
the data window, set all the "normal" components of that window to
invisible, and the "loading ... please wait" text to visible (and do the
wx.BeginBusyCursor()). Then once all the data is loaded, you can reverse
the visibility of those components.


I'd probably do the first of those - but the second does have the
advantage of being one fewer childwindow to deal with, and may be a
nicer UI with fewer windows "flashing" up and down again.


Either way, watch out for the fact that the cursor being busy is "per
window", so you may need to, or want to, also set the BeginBusyCursor()
within your message window / child window.

Also, if you can determine anything about the progress of the data
loading, it might be good to provide a progress bar.

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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 22/04/2006

Re: [Pythoncard-users] Creating a timed dialog and mouse egg timer

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

Ray Allen wrote:

>I'd like to do two things in pythoncard related to informing the user that a 
>new modal child window is about to open (it involves fetching data and 
>therefore can take a while): 1. Create a dialog that closes automatically 
>when the child window opens (eg.  Please wait..data loading) and 2. give the 
>mouse arrow an egg timer.  Are these simple things to make happen in 
>Pythoncard?   I'm hoping to stop the user repeatedly hitting a load button 
>when the event has been called.  Thanks,
>  
>

Yes, easy to do.

I don't think you want a dialog - a dialog *always* requires user input, 
and after opening a dialog, control doesn't return to your code until 
that user input has happened.

Two suggestions:

1. a simple child window containing the message. Create it as a child 
window, separate resource file with just a static message. Mark it "not 
visible on startup" in the layoutEditor's "Edit Background info".

In your initialization code,
   self.messageWindow = model.childWindow(self, message.MyBackground)

Then, when you start the process, you'd do something like
    self.messageWindow.visible = True
    wx.BeginBusyCursor()

and when the data is all loaded and you are ready to launch the real 
child window, do
    self.messageWindow.visible = False
    wx.EndBusyCursor()

(btw - the Begins and Ends  must match - if there's any danger they 
won't I've used the brute force method
    while wx.IsBusy():
          wx.EndBusyCursor()
)

Suggestion 2:
Use the child window you are loading the data for. On initial startup of 
the data window, set all the "normal" components of that window to 
invisible, and the "loading ... please wait" text to visible (and do the 
wx.BeginBusyCursor()). Then once all the data is loaded, you can reverse 
the visibility of those components.


I'd probably do the first of those - but the second does have the 
advantage of being one fewer childwindow to deal with, and may be a 
nicer UI with fewer windows "flashing" up and down again.


Either way, watch out for the fact that the cursor being busy is "per 
window", so you may need to, or want to, also set the BeginBusyCursor() 
within your message window / child window.

Also, if you can determine anything about the progress of the data 
loading, it might be good to provide a progress bar.

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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 22/04/2006

[Pythoncard-users] Creating a timed dialog and mouse egg timer

[Ray A. <ray...@sa...>]

I'd like to do two things in pythoncard related to informing the user that a 
new modal child window is about to open (it involves fetching data and 
therefore can take a while): 1. Create a dialog that closes automatically 
when the child window opens (eg.  Please wait..data loading) and 2. give the 
mouse arrow an egg timer.  Are these simple things to make happen in 
Pythoncard?   I'm hoping to stop the user repeatedly hitting a load button 
when the event has been called.  Thanks,
Ray 

[Pythoncard-users] Testers wanted for experimental undo/redo capability in layoutEditor; not Sizers.

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

I said yesterday I'd send a write up of my thought on adding sizers to 
the layoutEditor.

The bad news is I got distracted, and that won't happen for a few more days.

I went back to read over my notes about how I might tackle this - and 
was reminded that in my personal prioritization, undo/redo came much 
higher than support for sizers ..... so I decided to do that first.

The good news is that I have an alpha version of undo/redo apparently 
working, and would like some testers to have a poke at it, please.

Remember that it is definitely an ALPHA version - backup any files 
before using it, save early and often, etc.

The files (layoutEditor.py and layoutEditor.rsrc.py) can be downloaded from

http://www.tweedly.net/Python/layoutEditor with undo.zip

They can simply replace the same named files within your 
PythonCard/tools/resourceEditor directory.

(Note - tested only on Win XP so far - but shouldn't be platform dependent.)

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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/322 - Release Date: 22/04/2006

Re: [Pythoncard-users] XRC file support in PythonCard

[Ed L. <ed...@le...>]

On Apr 22, 2006, at 10:31 AM, Alex Tweedly wrote:

> I think that you can achieve the kind of layout / resizing you want  
> (including x-platform) with the sizers in wxWidgets - BoxSizers and  
> FlexGridSizer get you most of the way, adding GridBagSizer gets you  
> everything else (hopefully once I understand them better, I'll be  
> sure that FlexGridSizer is unnecessary, and that BoxSizers +  
> GridBagSizer is enough).

	Agreed. After playing around with all the various sizer options in  
wxPython, we settled on just that combination: dSizer is based on the  
wx.BoxSizer, and dGridSizer is based on wx.GridBagSizer. That seems  
to cover any layout situation I've come across.

> I've been looking, on and off, for a while at adding sizers to the  
> layout editor.  So, triggered by your first email on this topic,  
> I've started writing up how I think this could be (simply) done -  
> I'll get that (first draft) out this weekend, and if you're up for  
> it we can perhaps collaborate on it.

	If it saves you some effort, I went through the same effort with the  
Dabo Class Designer. I started with a PythonCard-like approach, with  
objects that used absolute positioning, and then tried to add sizers  
into that mix. It was impossible to visually represent that mix of  
sizer and non-sizer layouts together.

	The only approach that seemed to be feasible was to go with the  
sizers-only design, in which you create the sizers and allocate  
'slots' that then get filled with controls. I have a couple of  
screencasts that show this approach in action, and also try to  
educate people who are new to sizers how to approach laying out a  
form; perhaps they might be helpful to your ideas on adding sizers to  
PythonCard.

http://leafe.com/screencasts/sizers1.html
http://leafe.com/screencasts/sizers2.html


-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

Re: [Pythoncard-users] XRC file support in PythonCard

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

Winston Wolff wrote:

>> There isn't a one-to-one match between the standard  wxWidgets/ 
>> wxPython widget attributes ... The "command" attribute has no  
>> equivalent in XRC.
>
>
> Yes, the lack of a "command" parameter in an XRC file is a problem.
>
> The more I fiddle with wxPython, the more I realize how nice  
> PythonCard is, and how much time it saves.  Perhaps a better use of  
> my effort would be to add Sizers into PythonCard.  Apple's Cocoa/ 
> AppKit has the best sizers in my opinion.  What would be the  
> technical hurdles of adding that to PythonCard?
>
I'm not real familiar with Cocoa / Appkit / Xcode / Interface Builder   
- in fact, I've just spent the last ten minutes Googling and browsing 
around, and that's the sum of my knowledge of them :-)

As far as I can see, the Interface Builder approach to resizing is the 
"rods and springs" style, as in the old Hypercard. This approach I 
always found easy to use, but it's generally considered less capable 
than the "sizer" approach. This is particularly relevant for Pythoncard 
(really, for wxWidgets which underlies PythonCard / wxPython). One big 
issue in wxPython for cross-platform development is that basic system 
characteristics (e.g. menu font, button font, button sizes and how much 
space a button needs, etc.) vary between systems.

A "rods and springs" constrained layout can run into problems when even 
the basic visual features turn out to be larger than they had been in 
the original layout, and hence the constraints can't necessarily be 
satisfied prior to stretching, which can result in ugly overlapping 
components, etc.  I haven 't seen a  good way to get around that 
problem, so I eventually had to agree that the sizer approach is the 
better one - even though it's not as easy to use (or at least, I haven't 
found a layout editor that makes it easy to use).

I think that you can achieve the kind of layout / resizing you want 
(including x-platform) with the sizers in wxWidgets - BoxSizers and 
FlexGridSizer get you most of the way, adding GridBagSizer gets you 
everything else (hopefully once I understand them better, I'll be sure 
that FlexGridSizer is unnecessary, and that BoxSizers + GridBagSizer is 
enough).

I've been looking, on and off, for a while at adding sizers to the 
layout editor.  So, triggered by your first email on this topic, I've 
started writing up how I think this could be (simply) done - I'll get 
that (first draft) out this weekend, and if you're up for it we can 
perhaps collaborate on it.


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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 21/04/2006

Re: [Pythoncard-users] XRC file support in PythonCard

[Winston W. <win...@st...>]

> There isn't a one-to-one match between the standard  wxWidgets/ 
> wxPython widget attributes ... The "command" attribute has no  
> equivalent in XRC.

Yes, the lack of a "command" parameter in an XRC file is a problem.

The more I fiddle with wxPython, the more I realize how nice  
PythonCard is, and how much time it saves.  Perhaps a better use of  
my effort would be to add Sizers into PythonCard.  Apple's Cocoa/ 
AppKit has the best sizers in my opinion.  What would be the  
technical hurdles of adding that to PythonCard?

-ww


On Apr 22, 2006, at 1:49 AM, Kevin Altis wrote:

>
> On Apr 19, 2006, at 2:34 PM, Winston Wolff wrote:
>
>> Is anybody thinking about integrating XRC files in PythonCard?
>>
>> Here are my reasons why it would be a good idea:
>> 	- Could use a number of GUI builders such as wxGlade.
>> 	- PythonCard's resourceEditor has problems including:
>> 		- on Mac OS X grow handles don't appear
>> 		- on Mac OS X sizes get "stuck" and I can't grow widgets
>> 		- Layouts/Sizers are not supported.
>>
>> I'm thinking about a resource loader in PythonCard that would load  
>> an .XRC file (XML file written out by wxGlade or XRCed) and then  
>> do the regular PythonCard magic for binding events to widgets.
>>
>> The great thing about PythonCard is how it links up widgets and  
>> handlers automatically, saving great amounts of time and  
>> simplifying your code.  Probably when it was first written,  
>> wxPython GUI editors were not very good, or didn't exist.  But now  
>> they are better than PythonCard's resourceEditor.  Let's leverage  
>> other's work on GUI editors, and take the good part from PythonCard.
>>
>> Would anybody use this?  Would I be allowed to add it to the  
>> sourceforge repository?  Any other technical issues?
>>
>> -Winston
>
> If all you really want is the auto-event binding that would be  
> relatively easy to separate from the rest of PythonCard. It could  
> even be done so that there isn't a central dispatcher if you don't  
> care about event tracing. What you would do is iterate over the  
> widgets after the XRC has been loaded. Dabo might be another tool  
> to look at.
>
> There isn't a one-to-one match between the standard  wxWidgets/ 
> wxPython widget attributes so at a minimum PythonCard would  
> probably need a custom XRC loader and some attributes that can be  
> set in the resourceEditor. For example, a wxButton in an XRC file  
> normally has the following possible attributes: XML ID, label,  
> default, pos, size, and style. In addition, it has the style  
> attributes: fg, bg, font, enabled, focused, hidden, tooltip. For  
> the most part the names are just different than what is used for  
> PythonCard so that is proably a simple translation. "XML ID" could  
> be treated as the PythonCard "name" attribute which is crucial for  
> event binding. The "command" attribute has no equivalent in XRC.
>
> Having PythonCard be able to support XRC files for resources that  
> follow some specific guidelines such as using XML ID as the "name"  
> probably wouldn't be that hard, though you might lose support for  
> some PythonCard attributes and/or wxWidget attributes that  
> PythonCard doesn't currently recognize. A module that was able to  
> load the XRC files directly would be preferable, but a conversion  
> tool would avoid requiring modification of the framework itself. If  
> the framework has to deal with it I suspect you would need to  
> "walk" the layout after it is loaded and translate between wxPython  
> attributes and PythonCard ones, doing GetXXX() method calls in most  
> cases.
>
> What is much more complicated and unlikely to happen is having the  
> resourceEditor be able to read and write generic XRC files. That  
> would be something to tackle after just being able to load was  
> implemented.
>
> ka
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users




______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

Re: [Pythoncard-users] XRC file support in PythonCard

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

On Apr 19, 2006, at 2:34 PM, Winston Wolff wrote:

> Is anybody thinking about integrating XRC files in PythonCard?
>
> Here are my reasons why it would be a good idea:
> 	- Could use a number of GUI builders such as wxGlade.
> 	- PythonCard's resourceEditor has problems including:
> 		- on Mac OS X grow handles don't appear
> 		- on Mac OS X sizes get "stuck" and I can't grow widgets
> 		- Layouts/Sizers are not supported.
>
> I'm thinking about a resource loader in PythonCard that would load  
> an .XRC file (XML file written out by wxGlade or XRCed) and then do  
> the regular PythonCard magic for binding events to widgets.
>
> The great thing about PythonCard is how it links up widgets and  
> handlers automatically, saving great amounts of time and  
> simplifying your code.  Probably when it was first written,  
> wxPython GUI editors were not very good, or didn't exist.  But now  
> they are better than PythonCard's resourceEditor.  Let's leverage  
> other's work on GUI editors, and take the good part from PythonCard.
>
> Would anybody use this?  Would I be allowed to add it to the  
> sourceforge repository?  Any other technical issues?
>
> -Winston

If all you really want is the auto-event binding that would be  
relatively easy to separate from the rest of PythonCard. It could  
even be done so that there isn't a central dispatcher if you don't  
care about event tracing. What you would do is iterate over the  
widgets after the XRC has been loaded. Dabo might be another tool to  
look at.

There isn't a one-to-one match between the standard  wxWidgets/ 
wxPython widget attributes so at a minimum PythonCard would probably  
need a custom XRC loader and some attributes that can be set in the  
resourceEditor. For example, a wxButton in an XRC file normally has  
the following possible attributes: XML ID, label, default, pos, size,  
and style. In addition, it has the style attributes: fg, bg, font,  
enabled, focused, hidden, tooltip. For the most part the names are  
just different than what is used for PythonCard so that is proably a  
simple translation. "XML ID" could be treated as the PythonCard  
"name" attribute which is crucial for event binding. The "command"  
attribute has no equivalent in XRC.

Having PythonCard be able to support XRC files for resources that  
follow some specific guidelines such as using XML ID as the "name"  
probably wouldn't be that hard, though you might lose support for  
some PythonCard attributes and/or wxWidget attributes that PythonCard  
doesn't currently recognize. A module that was able to load the XRC  
files directly would be preferable, but a conversion tool would avoid  
requiring modification of the framework itself. If the framework has  
to deal with it I suspect you would need to "walk" the layout after  
it is loaded and translate between wxPython attributes and PythonCard  
ones, doing GetXXX() method calls in most cases.

What is much more complicated and unlikely to happen is having the  
resourceEditor be able to read and write generic XRC files. That  
would be something to tackle after just being able to load was  
implemented.

ka

Re: [Pythoncard-users] XRC file support in PythonCard

[Winston W. <win...@st...>]

Dear Andy and Alex-

Thanks for the fast and informed response.  It sounds like this  
project has some serious leaders who know the code which makes me  
glad.  If I'm going to invest some time, I don't want it to go into a  
black hole.

Right now I'm working on a deadline and put aside PythonCard in favor  
of straight wxPython to get the job done.  Sometime in the next month  
or two I'd like to work on this.  I'll let you know of I make any  
progress.

-ww

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

Re: [Pythoncard-users] XRC file support in PythonCard

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

Alex Tweedly wrote:
> Winston Wolff wrote:
> 
>> Is anybody thinking about integrating XRC files in PythonCard?
>>
[snip]
> 
> 
> Assuming it was completely "parallel" to existing stuff, I can't see a 
> reason why it couldn't be added to the repository.
> 
> I think the main technical issue will be the mis-match between the set 
> of controls presented by the editor(s) and what can actually be handled 
> by PythonCard (but that's an off-the-cuff response - I'll give it some 
> thought (and take a closer look at the editors and xrc itself and get 
> back to you if I see anything else looming ....)
> 

I've got an item on my to do list to write a utility to convert 
PythonCard resource files to XRC and vice versa. You are more than 
welcome to progress it as I'm not likely to get to it soon.

At present there are no plans to replace PythonCard's resource files 
with XRC for the reasons that Alex mentions.

With a conversion utility as a starting point the two may get closer 
together though.

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

Re: [Pythoncard-users] XRC file support in PythonCard

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

Winston Wolff wrote:

> Is anybody thinking about integrating XRC files in PythonCard?
>
> Here are my reasons why it would be a good idea:
>     - Could use a number of GUI builders such as wxGlade.
>     - PythonCard's resourceEditor has problems including:
>         - on Mac OS X grow handles don't appear
>         - on Mac OS X sizes get "stuck" and I can't grow widgets

As far as I know, these two have been fixed in the latest version 
(layoutEditor in 0.8.2, only in cvs). If you aren't using that, I'd 
recommend an update (you can get it using anonymous cvs access - see 
instructions under "Development" on the left menu of www.pythoncard.org

And if you're already using the latest version and still seeing these 
problems, I'd appreciate a full bug report so I can fix them :-)

>         - Layouts/Sizers are not supported.
>
I agree that's a problem. Partly it's because there's something of a 
conflict between the desirability of using sizers (on the one hand) and 
the desire to keep it simple and quick to make a basic app in PythonCard 
(I've yet to see a sizer-based layout editor that I'd describe as simple 
or quick).

> I'm thinking about a resource loader in PythonCard that would load  an 
> .XRC file (XML file written out by wxGlade or XRCed) and then do  the 
> regular PythonCard magic for binding events to widgets.
>
I think the tricky part will be deciding what to do when the XRC file 
contains controls, options or values that PythonCard doesn't support.

> The great thing about PythonCard is how it links up widgets and  
> handlers automatically, saving great amounts of time and simplifying  
> your code.  Probably when it was first written, wxPython GUI editors  
> were not very good, or didn't exist.  But now they are better than  
> PythonCard's resourceEditor.  Let's leverage other's work on GUI  
> editors, and take the good part from PythonCard.
>

> Would anybody use this?  Would I be allowed to add it to the  
> sourceforge repository?  Any other technical issues?

I'd give it a try (of course), but whether or not I'd use it is a much 
harder question. That would depend on the features and "style" of the 
GUI editors that can create xrc files. The issue I have with all the 
sizer-based GUI editors I've seen is that they work best when you 
already have a good idea of what your finished UI is going to look like 
(including how you want the controls split into sizers), whereas I tend 
to build the UI incrementally, adding controls, moving them around, etc. 
as the project evolves. Then (at some point) it feels settled enough 
that I could reasonably design a sizer tree and start allocating 
controls to branches of it. (currently of course I need to do that in 
code, which feels "wrong" but not too bad because it rarely changes much 
after that).

It's been a while since I looked at the range of editors available, so 
if there is one that handles sizer-tree reconfiguration well I'd be very 
happy to hear about it.


Assuming it was completely "parallel" to existing stuff, I can't see a 
reason why it couldn't be added to the repository.

I think the main technical issue will be the mis-match between the set 
of controls presented by the editor(s) and what can actually be handled 
by PythonCard (but that's an off-the-cuff response - I'll give it some 
thought (and take a closer look at the editors and xrc itself and get 
back to you if I see anything else looming ....)

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



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.4/318 - Release Date: 18/04/2006

[Pythoncard-users] XRC file support in PythonCard

[Winston W. <win...@st...>]

Is anybody thinking about integrating XRC files in PythonCard?

Here are my reasons why it would be a good idea:
	- Could use a number of GUI builders such as wxGlade.
	- PythonCard's resourceEditor has problems including:
		- on Mac OS X grow handles don't appear
		- on Mac OS X sizes get "stuck" and I can't grow widgets
		- Layouts/Sizers are not supported.

I'm thinking about a resource loader in PythonCard that would load  
an .XRC file (XML file written out by wxGlade or XRCed) and then do  
the regular PythonCard magic for binding events to widgets.

The great thing about PythonCard is how it links up widgets and  
handlers automatically, saving great amounts of time and simplifying  
your code.  Probably when it was first written, wxPython GUI editors  
were not very good, or didn't exist.  But now they are better than  
PythonCard's resourceEditor.  Let's leverage other's work on GUI  
editors, and take the good part from PythonCard.

Would anybody use this?  Would I be allowed to add it to the  
sourceforge repository?  Any other technical issues?

-Winston

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york

Re: [Pythoncard-users] Not enjoying win32 programming...

[Ruben M. <rmc...@ya...>]

Phil,

You probably found the answer to this issue by now,
but just in case you haven't here is a tip.  Check
your quotes.  See here for an interesting sample.

http://jason.diamond.name/weblog/2005/04/14/dont-quote-me-on-this

-Ruben

--- Phil Edwards <ph...@li...> wrote:

> Hi All:
> 
> Coming from a Linux background, I'm struggling to
> understand some of the 
> things that appear to be going on behind the scenes
> when I'm coding stuff to 
> run under Windows XP.
> 
> The application in question has a textfield
> containing the name of a Python 
> source code file and an 'Edit...' button next to it.
> When I click the button, 
> I'm running this code:
> 
>     def on_mainScriptEditBtn_mouseClick(self,
> event):
>         editor = self.cfg.get('ConfigData',
> 'codeeditor')
>         item =
> self.pathJoin(self.components.mainScript.text)
>         item =
> os.path.join(self.components.baseDir.text, item)
>         item =
> os.path.join(self.cfg.get('ConfigData', 'projects'),
> item)
>         if sys.platform.startswith('win'):
>             editor = GetShortPathName(editor)
>             item = GetShortPathName(item)
>         print editor + ' ' + item
>         os.system(editor + ' ' + item)
> 
> When the code runs, it prints out what I'm
> expecting, namely that I'm trying 
> to run the Pythoncard code editor with the name of a
> script file as the only 
> parameter on the command line. I then get the
> standard 'windows cannot open 
> this file' dialog box and I get to tell Windows that
> I want codeEditor.py to 
> be opened using the program called 'python'. The
> codeEditor duly opens up, 
> but it seems as though Windows is somehow losing my
> command line parameter 
> and all I end up with is a blank codeEditor window,
> instead of it opening the 
> file I wanted it to. Adding a simple 'print
> sys.argv' to the top of the 
> codeEditor proves that this is the case.
> 
> Could somebody please explain to a dumb UNIX user
> what vital piece of 
> information I'm missing in order to make this work?
> 
> 
> 
> -- 
> 
> Regards
> 
> Phil Edwards
> Brighton, UK
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by xPML, a
> groundbreaking scripting language
> that extends applications into web and mobile media.
> Attend the live webcast
> and join the prime developer group breaking into
> this new coding territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
>
https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Pythoncard-users] installation of pythoncard

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

Alan Craigon wrote:
> Thanks for that, unfortunately this did not work as there appears to be
> a problem with wxPython. The install went without a problem so I do not
> understand why pythoncard can not see wx.
> 
>>>> Andy Todd <an...@ha...> 27/03/2006 10:35 >>>
> Alan Craigon wrote:
>> I have wxPython installed, python 2.4 installed and have a folder
> with 
>> python card files ready to install. Every time I try to install on my
> 
>> Linux system using setup.py build & setupt.py install everything
> appears 
>> to work but I am unable to start pythoncard. What am I doing wrong?
> 
> What are you trying to run? When you install PythonCard on a Linux 
> system from the .tar.gz all of the files are installed into your 
> site-packages directory. On my (Ubuntu) box this is 
> /usr/lib/python2.4/site-packages
> 
> So, for instance, to run the resourceEditor tool you'll need a command
> like;
> 
> $ 
> /usr/lib/python2.4/site-packages/PythonCard/tools/resourceEditor/resourceEditor.py
> 
> To run your own PythonCard applications you'll just need to make the
> .py 
> file executable and run it from a shell.
> 
> Regards,
> Andy

Which installation went without a problem? wxPython or PythonCard? Have 
you looked at the installation log files?

If you think wxPython installed correctly can you run any of the 
wxPython demo programs to verify this?

What happens when you try and run any of the PythonCard sample 
applications or tools?

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

Re: [Pythoncard-users] MulticolumnList and flatfiledatabase

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

David Bain wrote:
> I've created a variation of the flatfiledatabase example with a 
> MultiColumnList.
> But it won't save the content of the Multicolumn list.

What error message do you get? What were you expecting to happen? Can 
you show us the relevant sections of code? With a bit more information 
we can probably help.

As you've modified a sample application it should probably be enough 
just to show the changes you've made to it along with the other 
information I mentioned above.

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