A bunch of questions about the new wx package

wxPython Users
1

Hi Patrick, Robin and all

py 2.2.1, wxpy 2.4.0.1, win98

The new wx package introduces a big change.
I read all the docs (well written) I could find about the
new wx package, but there are still a lot of points I would
like to be clarified.
I appreciate the effort to put some order in my/our wxPython
directory. The entropy of this subdirectory is far for
beeing zero!

1) Should we consider the new wx package as the de facto new
wxPython package, or is it only a transitional package?

2) Will it be part of the next 2.4.1 release?

3) If question 2) is true, I assume the complete demo should
be updated! To be consistent, all the py applications in
the wxPython dir should be modified. Will this be done?

4) I have more concerns about the documention. Will the
wx.chm file desappear and be replaced by the epydoc? I find
the .chm file far superior, specially for searching.

5) About epydoc, I will be nice if we can get the complete
doc (all files) in a zip file, so that we can use this doc
off line.

6) How may I test the wx package with wxPython 2.4.0.n?

7) Speed? This will introduce a speed penalty. If you import
the wx module only once, it is ok. A large wxPython
application may contain hundreds modules, each containing a
imprt wx.

8) Using the same logic, I may rewrite all the wx classes,
methods.. and replace wx**** by jm****.

9) I do not remember having seen people complaining about a
from wxPython.wx import * problem.

10) Finally, what is the opinion of the other users?

Thanks
Jean-Michel Fauth, Switzerland

2

Hi Patrick, Robin and all

py 2.2.1, wxpy 2.4.0.1, win98

The new wx package introduces a big change.
I read all the docs (well written) I could find about the
new wx package, but there are still a lot of points I would
like to be clarified.
I appreciate the effort to put some order in my/our wxPython
directory. The entropy of this subdirectory is far for
beeing zero!

1) Should we consider the new wx package as the de facto new
wxPython package, or is it only a transitional package?

There has been a major discussion a couple of weeks back. To my understanding
the majority agreed that for future releases the wx package should be the
standard. However the old way of doing things is still supported at least
until a major revision change. It's not only the demo that has to be
considered. There is a bunch of applications out there relying on the old way
of importing and names.
So if you write something new switch to the new
import wx
style. You can get the wx package from CVS and it works nicely with 2.4.0.xx

2) Will it be part of the next 2.4.1 release?

I think so

3) If question 2) is true, I assume the complete demo should
be updated! To be consistent, all the py applications in
the wxPython dir should be modified. Will this be done?

Do you volunteer to do the conversion ? I guess Robin will be very happy :slight_smile:

4) I have more concerns about the documention. Will the
wx.chm file desappear and be replaced by the epydoc? I find
the .chm file far superior, specially for searching.

The "what" file ? Ok, I guess this is the windows way of things. Can't answer
that question.

5) About epydoc, I will be nice if we can get the complete
doc (all files) in a zip file, so that we can use this doc
off line.

6) How may I test the wx package with wxPython 2.4.0.n?

Download the wx package from CVS (or search the mailing list. I think Patrick
made it available as zip file somewhere)
Put the wx folder into your site-packages directory.
Use "import wx" style. BTW: What I figured out - it won't work pretty well if
you mix "import wx" and "from wxPython import *" styles. At least it didn't
for me. I noted that when I switched my latest app from old to new. I
certainly missed the one or other module and got pretty weird errors.

7) Speed? This will introduce a speed penalty. If you import
the wx module only once, it is ok. A large wxPython
application may contain hundreds modules, each containing a
imprt wx.

Hmm - I'd say the penalty is higher with importing everything into the
namespace. But anyways - nice to see someone cares about speed and
ressources. Microsoft would just recommend buying a new computer :-))

8) Using the same logic, I may rewrite all the wx classes,
methods.. and replace wx**** by jm****.

To what avail ?

9) I do not remember having seen people complaining about a
from wxPython.wx import * problem.

Nope. It certainly works. However it pollutes the namespace incredibly and to
my understanding import * isn't very "pythonic". Most python packages use the
module type import.

10) Finally, what is the opinion of the other users?

I like it. The code looks much cleaner.

  UC

···

On Tuesday 27 May 2003 10:49 pm, Jean-Michel Fauth wrote:

--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417

3

I think it will be faster.

Surely "import wx" is very fast if the modules are
already loaded into memory? As far as I understood, if
the module wx is already loaded, "import wx" only creates
a new name "wx" in the current scope and lets that refer
to the module object.

E.g. if module x contains "import wx", I think the following
two are equivalent:

import x
import wx

or

import x
wx = x.wx

It's just one assignment. On the other hand, if you do
"from wxPython.wx import *" in several locations, you get
hundreds of assignments over and over.

···

At 07:49 2003-05-28 +0200, Jean-Michel Fauth wrote:

7) Speed? This will introduce a speed penalty. If you import
the wx module only once, it is ok. A large wxPython
application may contain hundreds modules, each containing a
imprt wx.

--
Magnus Lycka (It's really Lyckå), magnus@thinkware.se
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program

4

Hi all,

I have come across some problems using a customised grid cell editor. The
problems occur only with MSW, not with Linux. Platforms are Windows 2000,
Python 2.2.2, wxPython 2.4.0.2u, and RedHat 8, Python 2.2.2, wxPython
2.4.0.2.

1. Pressing "enter" on a cell normally takes you to the next row. If you are
inside a customised grid cell editor, and if there is a default button on
the panel, pressing "enter" activates the button instead.

2. Pressing "tab" on a cell normally takes you to the next cell. If you are
inside a customised grid cell editor, you are taken to the next control
outside the grid. If you continue tabbing until you reach the grid again,
the cell editor completes correctly. Even if there are no other controls on
the panel, you still have to tab at least one extra time. The demo does not
show this problem as it does not use a panel.

The attached sample shows a simple grid of 3 rows by 5 columns. The
customised editor is activated for the whole of row 1 (i.e. the second row).
You can easily comment/uncomment a couple of lines to use a panel or not,
and to use a GridTable or not. In fact using a GridTable makes no
difference, but my application uses one, so I had to check if that was
causing the problem.

If Robin reads this, you will see that I have used the SetMaxLength() method
of the text control, and it works well - all cells in row 1 are restricted
to a length of 3. Assuming I can solve these other problems, this means that
method of wxGridCellTextEditor - you may recall that you promised to look
into this for me.

Thanks in advance for any assistance.

Frank Millman

fm10.py (5.35 KB)

···

from my point of view there is no urgency in fixing the SetParameters()

5

Jean-Michel Fauth wrote:

Hi Patrick, Robin and all

py 2.2.1, wxpy 2.4.0.1, win98

The new wx package introduces a big change.
I read all the docs (well written) I could find about the
new wx package, but there are still a lot of points I would
like to be clarified.
I appreciate the effort to put some order in my/our wxPython
directory. The entropy of this subdirectory is far for
beeing zero!

1) Should we consider the new wx package as the de facto new
wxPython package, or is it only a transitional package?

It is currently "transitional" but eventually will be the standard. Currenly it just imports and renames things from the wxPython.wx and other wxPython packages. The next phase of the transition will make the wx package be the real thing and wxPython.wx will use renamers for compatibility.

2) Will it be part of the next 2.4.1 release?

Yes.

3) If question 2) is true, I assume the complete demo should
be updated! To be consistent, all the py applications in
the wxPython dir should be modified. Will this be done?

It's on my ToDo list, and I've also received a script to help do it somewhat automatedly, but havn't got it done yet.

4) I have more concerns about the documention. Will the
wx.chm file desappear and be replaced by the epydoc? I find
the .chm file far superior, specially for searching.

The next phase of the transition won't be done until there is Python specific docs for wxPython. Whether that will use epydoc or something else is still to be determined (although I do like epydoc's markup.) In any case, it should still be possible to put it in a .chm file.

5) About epydoc, I will be nice if we can get the complete
doc (all files) in a zip file, so that we can use this doc
off line.

Yep.

6) How may I test the wx package with wxPython 2.4.0.n?

As you've discovered, just download the wx package and put it on the PYTHONPATH somewhere.

7) Speed? This will introduce a speed penalty. If you import
the wx module only once, it is ok. A large wxPython
application may contain hundreds modules, each containing a
imprt wx.

During the transition there will be a bit of a startup speed penalty since the wx pacakge imports wxPython.wx and dynamically builds the namespace. As others have mentioned importing just wx instead of wxPython.wx.* will be a bit more efficient, but probably not enough to make up for the renaming. After the transition when the wx package is the real package then there should be a small net gain.

···

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

6

Frank Millman wrote:

1. Pressing "enter" on a cell normally takes you to the next row. If you are
inside a customised grid cell editor, and if there is a default button on
the panel, pressing "enter" activates the button instead.

2. Pressing "tab" on a cell normally takes you to the next cell. If you are
inside a customised grid cell editor, you are taken to the next control
outside the grid. If you continue tabbing until you reach the grid again,
the cell editor completes correctly. Even if there are no other controls on
the panel, you still have to tab at least one extra time. The demo does not
show this problem as it does not use a panel.

The normal gridcelleditor uses a style of wxTE_PROCESS_TAB | wxTE_MULTILINE | wxTE_NO_VSCROLL | wxTE_AUTO_SCROLL when on MSW. I think that should solve both of the above.

If Robin reads this, you will see that I have used the SetMaxLength() method
of the text control, and it works well - all cells in row 1 are restricted
to a length of 3. Assuming I can solve these other problems, this means that
from my point of view there is no urgency in fixing the SetParameters()
method of wxGridCellTextEditor - you may recall that you promised to look
into this for me.

Already done and checked in.

···

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

7

Frank Millman wrote:
>
> 1. Pressing "enter" on a cell normally takes you to the next row. If you

are

> inside a customised grid cell editor, and if there is a default button

on

> the panel, pressing "enter" activates the button instead.
>
> 2. Pressing "tab" on a cell normally takes you to the next cell. If you

are

> inside a customised grid cell editor, you are taken to the next control
> outside the grid. If you continue tabbing until you reach the grid

again,

> the cell editor completes correctly. Even if there are no other controls

on

> the panel, you still have to tab at least one extra time. The demo does

not

> show this problem as it does not use a panel.

Robin Dunn wrote:

The normal gridcelleditor uses a style of wxTE_PROCESS_TAB |
wxTE_MULTILINE | wxTE_NO_VSCROLL | wxTE_AUTO_SCROLL when on MSW. I
think that should solve both of the above.

It does indeed - thanks. Unfortunately this style messes up in Linux, so I
now have another "if sys.platform == 'win32' ..." :frowning:

> If Robin reads this, you will see that I have used the SetMaxLength()

method

> of the text control, and it works well - all cells in row 1 are

restricted

> to a length of 3. Assuming I can solve these other problems, this means

that

> from my point of view there is no urgency in fixing the SetParameters()
> method of wxGridCellTextEditor - you may recall that you promised to

look

> into this for me.

Already done and checked in.

What can I say - outstanding service as usual. Many thanks.

Frank Millman

8

Hi all,

I have a feeling that this question has been asked recently, but I cannot
find the exact answer. I want to generate a KeyEvent, so that it will be
detected and actioned by the event handler. Specifically I want to be able
to generate a tab or shift-tab, so that if someone tabs to a control, I can
force it to go to the next or previous control immediately.

I have tried something like this -

myevt = wxKeyEvent(self.GetId(), wxEVT_KEY_DOWN, KeyCode=WXK_TAB,
ShiftDown=True)
self.GetEventHandler().ProcessEvent(myevt)

It does not work. This may be because it is entirely wrong, or because the
arguments to wxKeyEvent are incorrect.

Please could someone explain the correct way to do this.

Many thanks

Frank Millman

9

Frank Millman wrote:

Hi all,

I have a feeling that this question has been asked recently, but I cannot
find the exact answer. I want to generate a KeyEvent, so that it will be
detected and actioned by the event handler.

In mosst cases you can't generate the low level events like this and make things behave as you expect. This is because there is no code in place to turn the wx event into a native message and send it to the native widget. (Normally it doesn't have to since the platform is sending us the message, not the other way around...)

Specifically I want to be able
to generate a tab or shift-tab, so that if someone tabs to a control, I can
force it to go to the next or previous control immediately.

But in this case you can probably do what you want by sending a wxNavigationKeyEvent. I don't have any code handy that shows how to use it but you can probably find something in the list archives.

···

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

10

Frank Millman wrote:
> Hi all,
>
> I have a feeling that this question has been asked recently, but I

cannot

> find the exact answer. I want to generate a KeyEvent, so that it will be
> detected and actioned by the event handler.

Robin Dunn wrote:

In most cases you can't generate the low level events like this and
make things behave as you expect. This is because there is no code in
place to turn the wx event into a native message and send it to the
native widget. (Normally it doesn't have to since the platform is
sending us the message, not the other way around...)

> Specifically I want to be able
> to generate a tab or shift-tab, so that if someone tabs to a control, I

can

> force it to go to the next or previous control immediately.

But in this case you can probably do what you want by sending a
wxNavigationKeyEvent. I don't have any code handy that shows how to use
it but you can probably find something in the list archives.

Thanks, Robin. There was one posting in the archive relating to this, but it
had no details. However, by messing around, I have come up with something
that seems to work.

From an EVT_SET_FOCUS handler, if I decide to skip the control, I execute

the following -

    myevt = wxNavigationKeyEvent()
    myevt.SetDirection(direction) # 1 = forwards , 0 = backwards
    self.GetEventHandler().ProcessEvent(myevt)

The second line is not required if you know that the direction is "1".

The third line assumes that "self" is the parent window. If the event
handler is called from a subclass of wxTextCtrl (as it is in my case),
replace "self" with "self.parent".

With GTK, it is important *not* to evt.Skip() - with MSW it makes no
difference.

I must still test it extensively, and I will report back if I find any
problems, but at the moment it looks as if it does just what I want :slight_smile:

Thanks again.

Frank Millman