Hi,
I tried to use wxEditableListBox, but it doesn't works for me.
I see just "pythonw.exe application error" when I try to add item in wxPython demo at: More Windows/Controls -> wxEditableListBox
ActiveState Python 2.2.2
wxPython 2.4.0.2
I tried with Win2k and Win98SE - the same results.
Is it a bug? Should I upgrade to latest wxPython?
WBR, Oleg.
Oleg Deribas wrote:
Hi,
I tried to use wxEditableListBox, but it doesn't works for me.
I see just "pythonw.exe application error" when I try to add item in wxPython demo at: More Windows/Controls -> wxEditableListBoxActiveState Python 2.2.2
wxPython 2.4.0.2
I tried with Win2k and Win98SE - the same results.Is it a bug?
It was.
Should I upgrade to latest wxPython?
Yes.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
I just migrated my win box to the latest installer releases to/from:
Python 2.2 to 2.3a2
and
wxPython 2.3.4.2 to 2.4.0.7
This upgrade was quite painless and my solitary project didn't notice. Whoohoo. Although I didn't expect it would.
The reason I upgarded 
was for the find option in the demo
BTW: Good job Chris Munchenberg and all contributors!!!
--
Ok, I'm hiding this question at the bottom of this message, because... I don't really want a positive answer:
I'm contemplating altering all the files the demo to import via:
from wxPython import wx
Every time code gets swiped from the demo I do this, if the demo was already converted it'd probably save a lot of time. I'm sure most everyone would benifit. Seems like there was mention of this before, did anyone volenteer to do this already?
Should I go for it with your blessings?
-Joe
Joe Brown <joe@overdrivepc.com> writes:
Ok, I'm hiding this question at the bottom of this message, because...
I don't really want a positive answer:I'm contemplating altering all the files the demo to import via:
from wxPython import wx
Every time code gets swiped from the demo I do this, if the demo was
already converted it'd probably save a lot of time. I'm sure most
everyone would benifit. Seems like there was mention of this before,
did anyone volenteer to do this already?Should I go for it with your blessings?
How about the new package syntax: import wx and no "wx" prefix on wx
classes, functions, or constants. I think Robin plans to include the
wx package in one of the next releases. You can get the new package
now from cvs here:
The new wx package is documented in the wx.html file, including
example code.
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Will you or Robin please let us know when it is "okay" to use the
new package syntax and new wx package in production code?
--- "Patrick K. O'Brien" <pobrien@orbtech.com> wrote:
How about the new package syntax: import wx and no "wx" prefix on
wx classes, functions, or constants. I think Robin plans to
include the wx package in one of the next releases. You can get
the new package now from cvs here:PyCrust download | SourceForge.net
The new wx package is documented in the wx.html file, including
example code.
=====
Donnal Walter
Arkansas Children's Hospital
Donnal Walter <donnalcwalter@yahoo.com> writes:
>
> How about the new package syntax: import wx and no "wx" prefix on
> wx classes, functions, or constants. I think Robin plans to
> include the wx package in one of the next releases. You can get
> the new package now from cvs here:
>
> PyCrust download | SourceForge.net
>
> The new wx package is documented in the wx.html file, including
> example code.Will you or Robin please let us know when it is "okay" to use the
new package syntax and new wx package in production code?
The main drawback right now is that it isn't shipping with wxPython,
so users of production code would have to get it from you or the
PyCrust CVS. So you probably want to wait until Robin includes it
with wxPython. Including it with wxPython won't effect existing code,
and everyone who wants to ignore it can choose to do so. But we can't
really convert the demo or samples until we include the new wx package.
As soon as Robin does that, I'll probably covert PyCrust as a proof of
concept (and eating my own dogfood) and as a way to see how long it
takes to convert a real program. In the mean time, I'm creating
examples using the new package and it works just fine. Of course,
anyone worried about the speed difference should probably do some
testing.
--- "Patrick K. O'Brien" <pobrien@orbtech.com> wrote:
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
I've been using the new syntax regardless of the wx plans simply by
having a "FixNames" module that goes through dir(wx) and does a
setattr(wx, newName, value) where newName is "Foo" instead of "wxFoo".
Since I don't remove the old names and the new names point to the exact
same things (classes or functions), there are no compatibility issues.
My point is that you don't even need a particular version of wx to use
the wx.Foo style! I've been using it with a pristine version of
wxPython 2402.
On Tuesday 25 March 2003 01:05 pm, Donnal Walter wrote:
Will you or Robin please let us know when it is "okay" to use the
new package syntax and new wx package in production code?
--
Chuck
http://ChuckEsterbrook.com
Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:
On Tuesday 25 March 2003 01:05 pm, Donnal Walter wrote:
> Will you or Robin please let us know when it is "okay" to use the
> new package syntax and new wx package in production code?I've been using the new syntax regardless of the wx plans simply by
having a "FixNames" module that goes through dir(wx) and does a
setattr(wx, newName, value) where newName is "Foo" instead of "wxFoo".Since I don't remove the old names and the new names point to the exact
same things (classes or functions), there are no compatibility issues.My point is that you don't even need a particular version of wx to use
the wx.Foo style! I've been using it with a pristine version of
wxPython 2402.
That's basically how the new wx package is implemented, with a few
extra pieces handled, such as the modules in the lib directory and the
stuff that's not in the wx namespace, like html and stc. The wx
package I pointed to changes the namespace dynamically. That's what
Robin will distribute, until the next phase when the real names
change.
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Patrick K. O'Brien wrote:
Should I go for it with your blessings?
How about the new package syntax: import wx and no "wx" prefix on wx
classes, functions, or constants. I think Robin plans to include the
wx package in one of the next releases. You can get the new package
now from cvs here:PyCrust download | SourceForge.net
The new wx package is documented in the wx.html file, including
example code.
Thought about that, but it's a fairly huge undertaking to convert the demo, either way. I think it would be prudent to convert the demo to wx.wx first. I think this is the most advantageous approach.
It should be trivial to use the wart remove after the fact, but during the transition, I need to know why I broke what I broke. :o
-Joe
Patrick K. O'Brien:
Donnal Walter:
> Will you or Robin please let us know when it is "okay" to use
> the new package syntax and new wx package in production code?The main drawback right now is that it isn't shipping with
wxPython, so users of production code would have to get it
from you or the PyCrust CVS.
Hmmm. It certainly seems easy enough to include the wx package (and
its __init__.py module) in one's own distribution, so I will
probably convert my code to the new syntax before the next release.
=====
Donnal Walter
Arkansas Children's Hospital
Donnal Walter <donnalcwalter@yahoo.com> writes:
Patrick K. O'Brien:
> Donnal Walter:
> > Will you or Robin please let us know when it is "okay" to use
> > the new package syntax and new wx package in production code?
>
> The main drawback right now is that it isn't shipping with
> wxPython, so users of production code would have to get it
> from you or the PyCrust CVS.Hmmm. It certainly seems easy enough to include the wx package (and
its __init__.py module) in one's own distribution, so I will
probably convert my code to the new syntax before the next release.
By all means, feel free to do so. I consider the code complete. I'm
just working on examples and documentation. But if you find a
problem, let me know and we'll get it fixed asap.
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Thanks for the clarification.
BTW Any chance we can change foo.GetSomething() to a Python property: foo.something
I use that one too!
On Tuesday 25 March 2003 03:53 pm, Patrick K. O'Brien wrote:
That's basically how the new wx package is implemented, with a few
extra pieces handled, such as the modules in the lib directory and
the stuff that's not in the wx namespace, like html and stc. The wx
package I pointed to changes the namespace dynamically. That's what
Robin will distribute, until the next phase when the real names
change.
--
Chuck
http://ChuckEsterbrook.com
Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:
> That's basically how the new wx package is implemented, with a few
> extra pieces handled, such as the modules in the lib directory and
> the stuff that's not in the wx namespace, like html and stc. The wx
> package I pointed to changes the namespace dynamically. That's what
> Robin will distribute, until the next phase when the real names
> change.Thanks for the clarification.
BTW Any chance we can change foo.GetSomething() to a Python property: foo.something
I use that one too!
Sure. PythonCard does that. (I wrote that part of the code.) But
making that change to the wxPython API itself would have to be debated
here. I'm not sure it would fly, as it is a bigger break from the
wxWindows way. I don't think Robin has been in favor of this change
in the past. But maybe these other changes will pave the way. I'd
much rather have simple Python property syntax instead of (or as an
alternative to) all the Get/Set methods. Let's see what Robin thinks.
On Tuesday 25 March 2003 03:53 pm, Patrick K. O'Brien wrote:
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Kudos Robin -- Upgrading is smooth]
> That's basically how the new wx package is implemented, with a few
> extra pieces handled, such as the modules in the lib directory and
> the stuff that's not in the wx namespace, like html and stc. The wx
> package I pointed to changes the namespace dynamically. That's what
> Robin will distribute, until the next phase when the real names
> change.Thanks for the clarification.
BTW Any chance we can change foo.GetSomething() to a Python property:
foo.something
I use that one too!
If you haven't already, you may interested in taking a look at AnyGUI, which
is basically a wrapper for wxPython (and other GUI toolkits as well).
(http://anygui.sourceforge.net) It's still a ways from completion, but
they've already done this for many of the common/core classes. You can see
examples of the syntax in the tutorial, like "win.position = x, y" 
I
think they've done a very good job so far - you can't really tell from the
example code that the underlying libraries weren't developed in Python.
It's not there yet, but I think it's really the answer for those who want a
toolkit that feels like it was developed directly in Python. IMHO, I think
if there was an initiative to change properties, etc. it'd be best to just
build on what AnyGUI already has rather than rebuild it all in wxPython. And
heck, as an added bonus you can support BeOS and command line OSes!
Kevin
----- Original Message -----
From: "Chuck Esterbrook" <ChuckEsterbrook@yahoo.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Tuesday, March 25, 2003 5:05 PM
Subject: [wxPython-users] wxPython Properties [Was: Re: [wxPython-users]
On Tuesday 25 March 2003 03:53 pm, Patrick K. O'Brien wrote:
Thanks for the insight Kevin. I knew of AnyGUI but didn't realize it
wrapped up wxPython and other libs. It's last release was over a year
ago, so I think I'll stick with wxPython for now.
However, I don't agree that whatever good things have found their way
into AnyGUI (or PythonCard, ...) shouldn't come back into making
wxPython a better product out of the box. What wxPython supports by
default and does canonically has a big effect on demo source code,
wikis, etc. As one person on this list pointed out, his colleagues
rejected wxPython because it felt too much like C++.
On Tuesday 25 March 2003 08:39 pm, Kevin Ollivier wrote:
If you haven't already, you may interested in taking a look at
AnyGUI, which is basically a wrapper for wxPython (and other GUI
toolkits as well). (http://anygui.sourceforge.net) It's still a ways
from completion, but they've already done this for many of the
common/core classes. You can see examples of the syntax in the
tutorial, like "win.position = x, y"
good job so far - you can't really tell from the example code that
the underlying libraries weren't developed in Python.It's not there yet, but I think it's really the answer for those who
want a toolkit that feels like it was developed directly in Python.
IMHO, I think if there was an initiative to change properties, etc.
it'd be best to just build on what AnyGUI already has rather than
rebuild it all in wxPython. And heck, as an added bonus you can
support BeOS and command line OSes!
--
Chuck
http://ChuckEsterbrook.com
Patrick K. O'Brien wrote:
As soon as Robin does that, I'll probably covert PyCrust as a proof of
concept (and eating my own dogfood) and as a way to see how long it
takes to convert a real program. In the mean time, I'm creating
examples using the new package and it works just fine. Of course,
anyone worried about the speed difference should probably do some
testing.
It should be noted that the speed hit is only at import time. Once the new packages are imported then wxPython will be just as fast as before.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Joe Brown wrote:
PyCrust download | SourceForge.net
The new wx package is documented in the wx.html file, including
example code.Thought about that, but it's a fairly huge undertaking to convert the demo, either way. I think it would be prudent to convert the demo to wx.wx first. I think this is the most advantageous approach.
It should be trivial to use the wart remove after the fact, but during the transition, I need to know why I broke what I broke. :o
If you want to do wx.wx first that is fine, but I only want to apply one patch for the final version using the new wx package.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Patrick K. O'Brien wrote:
Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:
BTW Any chance we can change foo.GetSomething() to a Python property: foo.something
I use that one too!
Sure. PythonCard does that. (I wrote that part of the code.) But
making that change to the wxPython API itself would have to be debated
here. I'm not sure it would fly, as it is a bigger break from the
wxWindows way. I don't think Robin has been in favor of this change
in the past. But maybe these other changes will pave the way. I'd
much rather have simple Python property syntax instead of (or as an
alternative to) all the Get/Set methods. Let's see what Robin thinks.
Several years ago I experimented with "properties" using __setattr__ and __getattr__ in Python 1.5.2. It was nice but it broke several people's code and others felt uncomfortable by the "high level of magic involved" so I removed it.
I've been thinking about it again since Python now has explicit support for properties, but have held off until the documentation is in better shape. That is happening now so I will definitly consider adding properties, but I would rather wait until 2.5/3.0 since there is still the possibility of breaking existing code if the properties are the same name as some attributes people are using already, and also because SWIG 1.3 has some support for it too.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn <robin@alldunn.com> writes:
Joe Brown wrote:
>> PyCrust download | SourceForge.net
>>
>> The new wx package is documented in the wx.html file, including
>> example code.
>>
> Thought about that, but it's a fairly huge undertaking to convert
> the demo, either way. I think it would be prudent to convert the
> demo to wx.wx first. I think this is the most advantageous approach.
> It should be trivial to use the wart remove after the fact, but
> during the transition, I need to know why I broke what I broke. :oIf you want to do wx.wx first that is fine, but I only want to apply
one patch for the final version using the new wx package.
Personally, I would only want to do one conversion, rather than two.
For the most part it's a simple search and replace of "wx" with "wx.",
except when the "wx" is used in a comment to refer to wxWindows or
wxPython. If anything breaks I doubt it will be due to the new wx
package. But since I'm not volunteering to convert the demo (though I
probably would if nobody else volunteered) you can do it any way you
please.
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
I also would think that a single conversion would make the most sense.
And I earlier volunteered to help convert the demo -- so if you want to
get in touch with me, we can split it somewhere convenient. Of course,
we'll wait until Robin gives the go-ahead.... 
On Wed, 2003-03-26 at 12:57, Patrick K. O'Brien wrote:
Robin Dunn <robin@alldunn.com> writes:
> Joe Brown wrote:
> >> PyCrust download | SourceForge.net
> >>
> >> The new wx package is documented in the wx.html file, including
> >> example code.
> >>
> > Thought about that, but it's a fairly huge undertaking to convert
> > the demo, either way. I think it would be prudent to convert the
> > demo to wx.wx first. I think this is the most advantageous approach.
> > It should be trivial to use the wart remove after the fact, but
> > during the transition, I need to know why I broke what I broke. :o
>
> If you want to do wx.wx first that is fine, but I only want to apply
> one patch for the final version using the new wx package.Personally, I would only want to do one conversion, rather than two.
For the most part it's a simple search and replace of "wx" with "wx.",
except when the "wx" is used in a comment to refer to wxWindows or
wxPython. If anything breaks I doubt it will be due to the new wx
package. But since I'm not volunteering to convert the demo (though I
probably would if nobody else volunteered) you can do it any way you
please.--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
--------------------------------------------------------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
--
Anthony Tuininga
anthony@computronix.com
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada T5N 4A3
Phone: (780) 454-3700
Fax: (780) 454-3838