pythoncard-users — PythonCard Users and Developers

Re: [Pythoncard-users] Sizers for PythonCard

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

Hugh Kernohan wrote:
> I found PythonCard some time ago while looking for a way to write 'real 
> programmes' for Windows.  Its simplicity and logical structure appealed 
> to me.  Through it I have learnt a huge amount about both Python and 
> wxWidgets.  In particular the ability to adapt, amend and extend the 
> tools is very satisfying.
>
> Like others I found the inability to use sizers easily was a drawback.  
> Not so much of a drawback as to make me want to learn C++ and code in 
> wxWidgets, or to give up PythonCard, but at the same time I objected to 
> mixing programmatic generation of sizers into my code - it is also a 
> hard way to learn.
>
> Inspiration for a solution came with Alex Tweedly's simplesizer and I 
> set off with the aim of making sizers work for PythonCard while 
> maintaining what seem to be its two key characteristics:  the separation 
> of layout and processing, and the use of visual drag-and-drop tools for 
> layout.  A secondary aim was to develop the routines in a way which did 
> not break existing tools or code.
>
>   
That sounds great !
> I now have something which is firmly an alpha version and a work in 
> progress, but it does work in several regards.  I'd be happy to share my 
> code for comment and improvement but the mailing list rejected the zip 
> file (even if it was only 106Kb).  So I'd be glad if someone could 
> explain how to get round that.
>
>   
No easy way to get around it (as far as I know). Best thing is to put 
your code on a web-site from where anyone interested can download it and 
try it out. If you don't have a suitable place, feel free to email it 
direct to me (al...@tw...) and I'll put it on my site for downloads.

(And I'll give it a good try-out, and look over the code, etc. :-)

Thank you.

-- 

Alex Tweedly      mailto:al...@tw...      www.tweedly.net

Re: [Pythoncard-users] Sizers for PythonCard

[John H. <ec...@ya...>]

--- Hugh Kernohan <ma...@hu...> wrote:

> I found PythonCard some time ago while looking for a
> way to write 'real 
> programmes' for Windows.  Its simplicity and logical
> structure appealed 
> to me.  Through it I have learnt a huge amount about
> both Python and 
> wxWidgets.  In particular the ability to adapt,
> amend and extend the 
> tools is very satisfying.
> 

Agree.

> Like others I found the inability to use sizers
> easily was a drawback.  
> Not so much of a drawback as to make me want to
> learn C++ and code in 
> wxWidgets, or to give up PythonCard, but at the same
> time I objected to 
> mixing programmatic generation of sizers into my
> code - it is also a 
> hard way to learn.
> 

Out of necessity, I've gotten pretty good in using wx
sizers with Pythoncard.  It's definitely usable but as
you said, it's a hard way to learn.  Besides, it's
really hard sometimes to try to figure out why things
don't turn out the way I am expecting it to. 


> Inspiration for a solution came with Alex Tweedly's
> simplesizer and I 
> set off with the aim of making sizers work for
> PythonCard while 
> maintaining what seem to be its two key
> characteristics:  the separation 
> of layout and processing, and the use of visual
> drag-and-drop tools for 
> layout.  A secondary aim was to develop the routines
> in a way which did 
> not break existing tools or code.
> 

Very noble goals.  :-)

> I now have something which is firmly an alpha
> version and a work in 
> progress, but it does work in several regards.  I'd
> be happy to share my 
> code for comment and improvement but the mailing
> list rejected the zip 
> file (even if it was only 106Kb).  So I'd be glad if
> someone could 
> explain how to get round that.
> 

May be the Pythoncard developers can help, or may be
we can start an eGroup at Yahoo on Pythoncard.

> The elements are:
> (a) additions to the existing Layout Editor to
> create a visual Sizer 
> Editor which manipulates sizers and allows
> components to be dropped into 
> them and re-arranged at will; the effect of
> different settings can be 
> seen immediately;

Obvious place to do it.  Unfortunately it also means I
have to rely on the Layout Editor more.  I have
reported problems with the Layout Editor long ago but
there hasn't been any fix to it yet.  As it stands, I
can only use the Layout Editor in *very* simplistic
fashion: get the basic layout done, switch to editor
to edit the resource file, and switch back to layout
editor to show the work and so on...

We need to fix the layout editor!!!

> (b) the final sizer details are saved into the
> current .rsrc.py file;

Of course.

> (b) a short routine, called autoSizer, which
> processes the sizer data in 
> the .rsrc file when a main application is
> initialized.
> 
> The routines handle BoxSizers, GridSizers and
> StaticBoxSizers;  
> FlexGridSizers are implemented but I am not 100%
> convinced I've got them 
> right. The biggest omission is the ability to
> override manually the 
> sizer engine's calculation of minimum dimensions for
> components.
> 
> There is an option to ease the conversion of
> existing .rsrc.py layouts 
> to a sizer-based format.  A menu option creates a
> single vertical sizer 
> containing all the components in the .rsrc file
> (effectively an 
> on-screen list).  You can then define your desired
> sizer configuration 
> and drag and drop the components into the right
> places.  Eventually the 
> temporary vertical sizer can be deleted when it is
> empty.  Slightly 
> tedious but it works and it beats re-typing all your
> components.
> 
> I have had  trouble with setting minimum sizes, so
> I've parked that for 
> now.  I have also yet to master re-drawing the
> screen properly, dealing 
> with the sizing handles when they get misplaced, and
> the impact of the 
> MenuBar on the editor display.  Nor have I tested
> the interaction of my 
> sizer-based solutions with all the elements of
> Layout Editor, especially 
> multiple selections.  The GridBagSizer is a joy to
> come, as are global 
> and multiple edits of sizers, drag-and-drop in the
> sizer tree etc, etc!
> 
> Thanks, Hugh Kernohan
> 
> 

I am on a tight time schedule for now but I hope I can
of use beta testing the code during X'mas holidays.

Thanks for the effort, though.  Any improvements to
PythonCard is very much welcomed.



--
John Henry

[Pythoncard-users] Sizers for PythonCard

[Hugh K. <ma...@hu...>]

I found PythonCard some time ago while looking for a way to write 'real 
programmes' for Windows.  Its simplicity and logical structure appealed 
to me.  Through it I have learnt a huge amount about both Python and 
wxWidgets.  In particular the ability to adapt, amend and extend the 
tools is very satisfying.

Like others I found the inability to use sizers easily was a drawback.  
Not so much of a drawback as to make me want to learn C++ and code in 
wxWidgets, or to give up PythonCard, but at the same time I objected to 
mixing programmatic generation of sizers into my code - it is also a 
hard way to learn.

Inspiration for a solution came with Alex Tweedly's simplesizer and I 
set off with the aim of making sizers work for PythonCard while 
maintaining what seem to be its two key characteristics:  the separation 
of layout and processing, and the use of visual drag-and-drop tools for 
layout.  A secondary aim was to develop the routines in a way which did 
not break existing tools or code.

I now have something which is firmly an alpha version and a work in 
progress, but it does work in several regards.  I'd be happy to share my 
code for comment and improvement but the mailing list rejected the zip 
file (even if it was only 106Kb).  So I'd be glad if someone could 
explain how to get round that.

The elements are:
(a) additions to the existing Layout Editor to create a visual Sizer 
Editor which manipulates sizers and allows components to be dropped into 
them and re-arranged at will; the effect of different settings can be 
seen immediately;
(b) the final sizer details are saved into the current .rsrc.py file;
(b) a short routine, called autoSizer, which processes the sizer data in 
the .rsrc file when a main application is initialized.

The routines handle BoxSizers, GridSizers and StaticBoxSizers;  
FlexGridSizers are implemented but I am not 100% convinced I've got them 
right. The biggest omission is the ability to override manually the 
sizer engine's calculation of minimum dimensions for components.

There is an option to ease the conversion of existing .rsrc.py layouts 
to a sizer-based format.  A menu option creates a single vertical sizer 
containing all the components in the .rsrc file (effectively an 
on-screen list).  You can then define your desired sizer configuration 
and drag and drop the components into the right places.  Eventually the 
temporary vertical sizer can be deleted when it is empty.  Slightly 
tedious but it works and it beats re-typing all your components.

I have had  trouble with setting minimum sizes, so I've parked that for 
now.  I have also yet to master re-drawing the screen properly, dealing 
with the sizing handles when they get misplaced, and the impact of the 
MenuBar on the editor display.  Nor have I tested the interaction of my 
sizer-based solutions with all the elements of Layout Editor, especially 
multiple selections.  The GridBagSizer is a joy to come, as are global 
and multiple edits of sizers, drag-and-drop in the sizer tree etc, etc!

Thanks, Hugh Kernohan

[Pythoncard-users] changing wx.mixins

[tjerk h. <tj...@br...>]

An irritating behaviour of MultiColumnList are that they seem to sort=20
columns always like strings.  And if you put integers  in the =
MultiColumnList.items you get
errors so you have to change every thing to strings.(?)
So when you have a column with 'numbers' like  88,125,9,2
and click on the ColumnHeader it sorts thus  9,88,2,125
wich is mostly useless.
So now I changed some lines in the mixins from wx.
If anybody also wants a different sort behaviour do this.
In wx.lib.mixins.lstctrl change this lines in=20
__ColumnSorter(self,key1,key2):
    col =3D self._col
        ascending =3D self._colSortFlag[col]
        item1 =3D self.itemDataMap[key1][col]
        item2 =3D self.itemDataMap[key2][col]

        #--- Internationalization of string sorting with locale module
        if type(item1) =3D=3D type('') or type(item2) =3D=3D type(''):
            cmpVal =3D locale.strcoll(str(item1), str(item2))
        else:
            cmpVal =3D cmp(item1, item2)

lines added underlined

    col =3D self._col
        ascending =3D self._colSortFlag[col]
        item1 =3D self.itemDataMap[key1][col]
        item2 =3D self.itemDataMap[key2][col]

        #--- Internationalization of string sorting with locale module
        if type(item1) =3D=3D type('') or type(item2) =3D=3D type(''):
            if item1.isdigit() and item2.isdigit():
                cmpVal=3Dcmp(float(item1),float(item2))
            else:
                cmpVal =3D locale.strcoll(str(item1), str(item2))
        else:
            cmpVal =3D cmp(item1, item2)
      =20

So now the MultiColumnList recognizes numbers in the column, and sort =
according=20
to value...so  88,125,9,2  turns into 125,88,9,2


Any comments?
Tjerk Hoekstra
Castro Brazil

[Pythoncard-users] keep windows on top

[tjerk h. <tj...@br...>]

Thanks Phil,its ok now.
I have change the background info, and the application starts nice..and =
clean.
looks a lot more professional.
Please take a look at the other issue about keeping a certain window on =
top of the other.

Tjerk Hoekstra
Castro Brazil

Re: [Pythoncard-users] keep windows on top!

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

Phil Edwards wrote:
> tjerk hoekstra wrote:
>> *my application has 20 childwindows wich I create at startup and make 
>> invisible, when I need them*
>> *i change them to visible. OK it works but there are 2 issues...*
>> *1) When the application starts you see flickering of all the windows 
>> being created and then disappear,*
>> *        rather ugly..Any suggestion?*
> 
> In the resource editor, click on 'Edit' then 'Background Info'. Make 
> sure that the 'Visible on Startup' box is not ticked. All your child 
> windows will be created as normal but will not appear until you make a 
> call to something like myChildWindow.Show(). This ought to fix the 
> flicering.
> 

Hmmm....this reply doesn't actually explain what I meant, my apologies.

Load up the PythonCard resource editor. For each of your child windows, 
open the resource file associated with it. Click 'Edit' then click 
'Background info'. Make sure that the 'visible at startup' box is not 
ticked. Save the resource file if necessary. Move on to the next one.

You should now find that when you run your main application, the 
'flickering windows' effect has gone away. If you have added code in the 
on_initialize() section of your application to hide all of your child 
windows, you can remove these lines as they are no longer needed.

Hope that's a bit clearer.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] keep windows on top

[tjerk h. <tj...@br...>]

> *2) Lets say that from the Mainwindow I call a childwindow, and then=20
> some widget in the childwindow calls a Dialog*
> *    when the Dialog is done with, the childwindow is hidden behind =
the=20
> Mainwindow..is there any way to keep her op Top?*

Sorry I was wrong it isn=B4t a dialog that the childwindow calls it is =
another window.
So we have this window1..opens childwindow2...wichs opens =
childwindow3(childfromwindow1)
when I close childwindow3...childwindow2 is open but hidden behind =
window1. That is not what I want..
I want to continue on childwindow2...(yes I can click on her tab to =
bring her on top but users could get confused)

Tjerk Hoekstra
Castro Brazil

Re: [Pythoncard-users] keep windows on top!

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

tjerk hoekstra wrote:
> *my application has 20 childwindows wich I create at startup and make 
> invisible, when I need them*
> *i change them to visible. OK it works but there are 2 issues...*
> *1) When the application starts you see flickering of all the windows 
> being created and then disappear,*
> *        rather ugly..Any suggestion?*

In the resource editor, click on 'Edit' then 'Background Info'. Make 
sure that the 'Visible on Startup' box is not ticked. All your child 
windows will be created as normal but will not appear until you make a 
call to something like myChildWindow.Show(). This ought to fix the 
flicering.

> *2) Lets say that from the Mainwindow I call a childwindow, and then 
> some widget in the childwindow calls a Dialog*
> *    when the Dialog is done with, the childwindow is hidden behind the 
> Mainwindow..is there any way to keep her op Top?*

Not sure about this one, I don't see this happening on my machine. Do 
you have some example code you can post here?


-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] keep windows on top!

[tjerk h. <tj...@br...>]

I really am  making progress with pythoncard..thanks everbody who =
contributes.
The Pythoncard editor is the best around, and other RADS like =
boa-constructor sucks.
By the way I also like reportlab to make PDF files...but thats another =
issue.
And for the list of honour I would like to recommend standalone Builder  =
it works !!
But help me resolve these issues:
my application has 20 childwindows wich I create at startup and make =
invisible, when I need them
i change them to visible. OK it works but there are 2 issues...
1) When the application starts you see flickering of all the windows =
being created and then disappear,
        rather ugly..Any suggestion?
2) Lets say that from the Mainwindow I call a childwindow, and then some =
widget in the childwindow calls a Dialog
    when the Dialog is done with, the childwindow is hidden behind the =
Mainwindow..is there any way to keep her op Top?

Thanks for reading, keep posting so that everybody knows we are alive.

Tjerk Hoekstra
Castro  Brazil

Re: [Pythoncard-users] PythonCard dialogs -- return values

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

Neil Hughes wrote:
> On 31/10/2007 12:03, Phil Edwards wrote:
>> If nobody has any objection or alternative suggestions for the wording, 
>> I'll do this today and check the amended docs back into CVS.
> 
> Sounds good....it needs to be changed before it confuses anybody else. I 
> suspect that I've looked at those notes in the past and either missed 
> the fact they're out of date or just thought "they should be changed" 
> and forgotten to notify anyone.
> 

Okay, that's now done and CVS has been updated.


-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] PythonCard dialogs -- return values

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 31/10/2007 12:03, Phil Edwards wrote:
> 
> If nobody has any objection or alternative suggestions for the wording, 
> I'll do this today and check the amended docs back into CVS.

Sounds good....it needs to be changed before it confuses anybody else. I 
suspect that I've looked at those notes in the past and either missed 
the fact they're out of date or just thought "they should be changed" 
and forgotten to notify anyone.

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] PythonCard dialogs -- return values

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

Aaron Stevens wrote:
> Alrighty then, that's what I had intuited. Perhaps we could put what you
> just wrote into the doc pages? Might I offer to update those doc pages? 
> 

I've just had a look through the documents in CVS and they all need to 
be updated. :-(

I have CVS commit access but I can't give the same to you as I'm not a 
project admin. I propose that the docs should be updated so that 
wherever it says:

"The <blah>Dialog component returns <number> values, stored as elements 
of the Python dictionary called "results" returned by all PythonCard 
dialogs. These results are shown in the following table."

we change this to read:

"The <blah>Dialog component returns a wxPython DialogResults object 
which contains <number> values, as shown in the following table."

If nobody has any objection or alternative suggestions for the wording, 
I'll do this today and check the amended docs back into CVS.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] PythonCard dialogs -- return values

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

Aaron Stevens wrote:
> 
> For example, when I used the FileDialog, the result has members
> 'accepted' and paths -- but according to the documentation these are
> supposed to be mapped in a dict. Any clarification expected.
> 
>         result = dialog.fileDialog(self, 'Open', '', '', '*' )
> 
>         if result.accepted == True:
>             filename = result.paths[0]
> 

Hi Aaron:

The documentation is simply out of date, that's all. The behaviour you 
describe is as expected - when version 0.8.2 (I think!) of PythonCard 
was released, the dialog components were changed so that they are 
sub-classes of wx.lib.dialogs.

Where the documentation talks about a dictionary item, e.g. 
result['someName'], you just substitute result.someName.

The change was designed to make some bits of PythonCard more 'pythonic' 
and to make it easier to hand-roll your own custom dialogs.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] PythonCard dialogs -- return values

[Aaron S. <az...@bu...>]

Hi all,

I'm new to PythonCard, so please forgive me if this is old-hat to you
guys...

I'm starting to use the built-in dialogs, and I'm confused about the
return values. The documentation says that all dialogs return a dict of
results, but the actual results are not a dict, but rather some other
undocumented objects -- different for each dialog, so far as I can tell.

For example, when I used the FileDialog, the result has members
'accepted' and paths -- but according to the documentation these are
supposed to be mapped in a dict. Any clarification expected.

        result = dialog.fileDialog(self, 'Open', '', '', '*' )

        if result.accepted == True:
            filename = result.paths[0]

Thanks!
Aaron
(and many questions to follow, I promise!)

Re: [Pythoncard-users] setting radiogroup items dynamically?

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 24/10/2007 23:09, Alec Bennett wrote:
> 
> http://wiki.wxpython.org/PythonCardTricks
> 
> I added:
> 
> - "How do I launch a pure WX window from a PythonCard app?" and

Thanks Alec....this is something I need to do in the near future to tack 
a custom print dialog window onto a PythonCard front-end (to a legacy 
Win32 application....phew!), so your example is most welcome.

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] setting radiogroup items dynamically?

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

Alec Bennett wrote:
> 
> - "How do I make my PythonCard app minimize to the system tray?"
> 

I added a sample called 'sysTray' to the PythonCard CVS tree quite a 
while ago. Unfortunately this was after the release of 0.8.2, so my code 
is still just in CVS, but I can upload a copy to my web site if anyone 
is interested - just reply here and let me know.

I tested it on WinXP and Linux (using KDE) and ended up very pleased 
with it, despite almost tearing my hair out with a couple of issues that 
took much Google-fu and experimenting to resolve. :-)

Re: [Pythoncard-users] setting radiogroup items dynamically?

[Alec B. <wry...@gm...>]

I wound up making the window in pure wxPython. Which got me to thinking: a
nice and relatively easy way to extend the power of PythonCard would be to
document integration with it and pure WX. In other words, how to add
components from WX to your PythonCard app.

With that in mind I made a couple of additions to this Wiki page:

http://wiki.wxpython.org/PythonCardTricks

I added:

- "How do I launch a pure WX window from a PythonCard app?" and

- "How do I make my PythonCard app minimize to the system tray?"

I've seen a couple of other examples describing minimizing to the system
tray, but nothing very complete. And obviously if anyone notices problems
with those tutorials, please update or let me know.

Maybe someone could post instructions for adding, say, a radiogroup from
pure python to a PythonCard app? Or if someone knows of some existing
documentation for doing things like this?






On 10/24/07, Phil Edwards <ph...@li...> wrote:
>
> Alex Tweedly wrote:
> >>
> >> Is there some other way to set the radiogroup items dynamically?
> >>
> > Very embarrassingly, I can't try this out right now, but you might get
> > it to work as
> >
> > self.components.myradiogroup.SetItemLabel(1,'choice1')
> > self.components.myradiogroup.SetItemLabel(2,'choice2')
> > etc.
> >
>
> Just tried that on my laptop and it works, with the proviso that you
> can't use this method to change the number of items in the group, i.e.
> if we tried to add a 3rd radio button by doing:
>
> self.components.myradiogroup.SetItemLabel(3, 'choice3')
>
> then this gets ignored.
>
> --
>
> Regards
>
> Phil Edwards
> Brighton, UK
>

Re: [Pythoncard-users] setting radiogroup items dynamically?

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

Alex Tweedly wrote:
>>
>> Is there some other way to set the radiogroup items dynamically?
>>
> Very embarrassingly, I can't try this out right now, but you might get 
> it to work as
> 
> self.components.myradiogroup.SetItemLabel(1,'choice1')
> self.components.myradiogroup.SetItemLabel(2,'choice2')
> etc.
> 

Just tried that on my laptop and it works, with the proviso that you 
can't use this method to change the number of items in the group, i.e. 
if we tried to add a 3rd radio button by doing:

self.components.myradiogroup.SetItemLabel(3, 'choice3')

then this gets ignored.

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] setting radiogroup items dynamically?

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

Alec Bennett wrote:
> I'm guessing this isn't possible in Pythoncard, since calling, for 
> example:
>
> self.components.myradiogroup.items = ['choice1', 'choice2']
>
> returns NotImplementedError.
>
> Is there some other way to set the radiogroup items dynamically?
>
Very embarrassingly, I can't try this out right now, but you might get 
it to work as

self.components.myradiogroup.SetItemLabel(1,'choice1')
self.components.myradiogroup.SetItemLabel(2,'choice2')
etc.


-- 

Alex Tweedly      mailto:al...@tw...      www.tweedly.net

[Pythoncard-users] setting radiogroup items dynamically?

[Alec B. <wry...@gm...>]

I'm guessing this isn't possible in Pythoncard, since calling, for example:

self.components.myradiogroup.items = ['choice1', 'choice2']

returns NotImplementedError.

Is there some other way to set the radiogroup items dynamically?

Re: [Pythoncard-users] PythonCard and wxPython 2.8

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

Aha! Following an e-mail from Kevin about this, I took a look in the 
release notes for 2.8.6.0:

"Some Menu APIs added to make things more consistent. Added 
wx.MenuBar.SetMenuLabel, wx.MenuBar.GetMenuLabel, 
wx.MenuBar.GetMenuLabelText, wx.Menu.GetLabelText, 
wx.MenuItem.SetItemLabel, wx.MenuItem.GetItemLabel, 
wx.MenuItem.GetItemLabelText, wx.MenuItem.GetLabelText. The Get...Label 
functions get the raw label with mnemonics and accelerators, and the 
Get...LabelText functions get the text only, without 
mnemonics/accelerators."

It looks like some of the code in menu.py can be simplified for this 
release of wx. I'll take a look when I get home tonight and see what I 
can come up with.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] PythonCard and wxPython 2.8

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

Hi All:

I've downloaded the wxPython 2.8 source RPM and attempted to 
build/install it on a Mandriva 2007.0 machine alongside PythonCard 
0.8.2. When I run the resource editor, I get an assertion error:

[phile@localhost:/home/phile]
$ /usr/share/PythonCard/tools/resourceEditor/resourceEditor.py
Traceback (most recent call last):
   File 
"/usr/lib/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
14345, in <lambda>
     lambda event: event.callable(*event.args, **event.kw) )
   File "/usr/share/PythonCard/tools/resourceEditor/resourceEditor.py", 
line 149, in on_initialize
     self.updatePanel(self.rsrc)
   File "/usr/share/PythonCard/tools/resourceEditor/resourceEditor.py", 
line 1273, in updatePanel
     self.menuBar.setEnabled('menuFileRun', True)
   File "/usr/lib/python2.4/site-packages/PythonCard/menu.py", line 427, 
in setEnabled
     self.Enable(id, aBoolean)
   File 
"/usr/lib/python2.4/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 
11151, in Enable
     return _core_.MenuBar_Enable(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "item" failed at 
../src/common/menucmn.cpp(1072) in Enable(): attempt to enable an item 
which doesn't exist

As you can probably surmise from the message, this is a Unicode build of 
wx against GTK2.

Has anybody been able to successfully run PythonCard with wx 2.8 on Linux?

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] Question/Problem with

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On 16/10/2007 23:26, Alex Tweedly wrote:
> [ Note - this is typed from memory &/or reading code - not from actually 
> trying it - I'm unfortunately not in a position to reach a computer I 
> can do that on right now .... so it should be treated with a small 
> amount of caution ]

Well, it would appear that your memory serves you well....the examples 
all seem to work as predicted :-)

-- 
XXXXXXXXXXX

Re: [Pythoncard-users] Question/Problem with

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

Christoph Schneeberger wrote:
> Hi,
>
> I have a problem with the |dialog.textEntryDialog when using
> |wx.TE_PASSWORD (and wx.TE_MULTILINE) as in the following code:
>
> result = dialog.textEntryDialog(self, 'Password for user ', 'Password',
> '', wx.TE_PASSWORD)
>
> as soon as I add the fourth argument (wx.TE_PASSWORD or wx.TE_MULTILINE)
> I get no more OK/Cancel buttons in the dialog and Enter doesn't help too.
>
> I even tried adding it to the sample dialog and it behaved the same way,
> so I assume it has something to do with my platform: Win2000,
> Python2.51, Pythoncard 0.82, wxpython 2.8.4.2.
>   
[ Note - this is typed from memory &/or reading code - not from actually 
trying it - I'm unfortunately not in a position to reach a computer I 
can do that on right now .... so it should be treated with a small 
amount of caution ]

When you add the fourth parameter, you need to completely specify what 
you want. The default is to have OK and Cancel buttons, so instead of

> result = dialog.textEntryDialog(self, 'Password for user ', 'Password',
> '', wx.TE_PASSWORD)
>   
you should have

> result = dialog.textEntryDialog(self, 'Password for user ', 'Password',
> '', wx.TE_PASSWORD | wx.OK | wx.CANCEL)
>   

or you could simply use the convenience dialogs, as in

> result = dialog.passwordTextEntryDialog(self, 'Password for user ', 'Password',
> '')
>   



-- 

Alex Tweedly      mailto:al...@tw...      www.tweedly.net

[Pythoncard-users] Question/Problem with

[Christoph S. <cs...@bo...>]

Hi,

I have a problem with the |dialog.textEntryDialog when using
|wx.TE_PASSWORD (and wx.TE_MULTILINE) as in the following code:

result = dialog.textEntryDialog(self, 'Password for user ', 'Password',
'', wx.TE_PASSWORD)

as soon as I add the fourth argument (wx.TE_PASSWORD or wx.TE_MULTILINE)
I get no more OK/Cancel buttons in the dialog and Enter doesn't help too.

I even tried adding it to the sample dialog and it behaved the same way,
so I assume it has something to do with my platform: Win2000,
Python2.51, Pythoncard 0.82, wxpython 2.8.4.2.

Thanks for any tips/help in advance,
Christoph Schneeberger

-- 


          "Quis custodiet ipsos custodes?"