[wxPython] basic window for viewing text

Thanks for the suggestions. I added the following code:

       evt.WriteText('\n')

and obtained the following error message:

AttributeError: wxCommandEventPtr instance has no attribute 'WriteText'

···

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Thanks for the suggestions. I added the following code:

       evt.WriteText('\n')

and obtained the following error message:

AttributeError: wxCommandEventPtr instance has no attribute 'WriteText'

You can't call a method if the class does not have it. Are you sure you
wanted to tell the event object to write text?

···

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

Today, I suddenly got an error message I never saw before:

   Fatal Python error: PyThreadState_Get: no current thread

   abnormal program termination

Can anyone say something about this? I'm not explicitly using
threads in my application, and the program works as usual if I
comment out

     sys.stderr = wxPyNonFatalErrorDialogWithTraceback( ...

I wasn't very fond of those error dialogs anyway, so I don't
mind that a lot, but I'm still a bit puzzled over the error.
Can someone explain what this is all about?

···

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

I asked this question yest :slight_smile: Here was Robin's answer. You need to
patch the source. Definitely solved the problem for me.

  Fatal Python error: PyThreadState_Get: no current thread
  Aborted

[...]

#9 0x401edc9e in wxSize_asTuple (self=0x82a5560) at src/gtk/misc.cpp:1305

Edit src/gtk/misc.cpp and change all the *_asTuple functions to be like
this:
static PyObject * wxSize_asTuple(wxSize *self) {
    wxPyBeginBlockThreads(); // <-- Add this
    PyObject* tup = PyTuple_New(2);
    PyTuple_SET_ITEM(tup, 0, PyInt_FromLong(self->x));
    PyTuple_SET_ITEM(tup, 1, PyInt_FromLong(self->y));
    wxPyEndBlockThreads(); // <-- and this
    return tup;
}

                    -- Mike

···

On Fri, Apr 12 @ 00:07, Magnus Lyckå wrote:

Today, I suddenly got an error message I never saw before:

   Fatal Python error: PyThreadState_Get: no current thread

   abnormal program termination

Can anyone say something about this? I'm not explicitly using
threads in my application, and the program works as usual if I
comment out

     sys.stderr = wxPyNonFatalErrorDialogWithTraceback( ...

I wasn't very fond of those error dialogs anyway, so I don't
mind that a lot, but I'm still a bit puzzled over the error.
Can someone explain what this is all about?

--
Michael Gilfix
mgilfix@eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html

Today, I suddenly got an error message I never saw before:

   Fatal Python error: PyThreadState_Get: no current thread

   abnormal program termination

Can anyone say something about this? I'm not explicitly using
threads in my application, and the program works as usual if I
comment out

That message happens if we try get the current Python threadstate (there is
always at least one) and it isn't set. In order to have a well behaved
Python extension we have to release the global interpreter lock (GIL) while
doing C++ stuff and then aquire it again before returning to Python. This
lets other Python threads run while the current thread is off doing other
things. The trick comes when making callbacks for event handlers or
whatever and in aquiring the GIL and restoring the same threadstate again,
but that is probably more detail than anybody really wants. (If you do then
look in helpers.cpp at wxPyBeginAllowThreads, wxPyEndAllowThreads,
wxPyBeginBlockThreads, and wxPyEndBlockThreads.)

Anyway, as we discovered yesterday, there are a couple spots where I should
have been aquiring the GIL and restoring the threadstate that I wasn't.
It's been fixed and will be in the next 2.3.3 preview.

     sys.stderr = wxPyNonFatalErrorDialogWithTraceback( ...

Did you track it down any further than that? I'm just curious if it was in
the same methods we found yesterday or somewhere else.

···

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

Anyway, as we discovered yesterday, there are a couple spots where I should
have been aquiring the GIL and restoring the threadstate that I wasn't.
It's been fixed and will be in the next 2.3.3 preview.

That's odd. I've been using the same wxPython version for months, but
some change I did yesterday triggered this.

Did you track it down any further than that? I'm just curious if it was in
the same methods we found yesterday or somewhere else.

No, the sys.sdterr = was very early in the code, and I noticed that
I crashed at an early point, and I've been a bit suspicious about
those error handling routines... I'm almost glad to get rid of them. :wink:

I guess I could have a look in the CVS...

···

At 15:49 2002-04-11 -0700, you wrote:

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

I have a frame with entry fields and buttons that I would
like to close on pressing Esc. I fixed that simply in
another frame (with a tree control) using a accelerator
table, but it didn't work as expected here.

I can catch things such as Alt-X with the accelerator table,
but I guess the Esc is eaten up by something else. First I
thought it was just the text entry fields that ate my Esc,
but it turns out that even if a button is in focus, it won't
work. (I've got buttons in the window with the tree control
too, and there it works.)

The relevant part of the code looks like this:

         EVT_CLOSE(self, self.OnClose)

         ...

         ID_CLOSE = wxNewId()
         EVT_MENU(self, ID_CLOSE, self.OnClose)
         aTable = wxAcceleratorTable(
             [(wxACCEL_NORMAL, WXK_ESCAPE, ID_CLOSE),
              (wxACCEL_ALT, ord('X'), ID_CLOSE)]
             )
         self.SetAcceleratorTable(aTable)

This is in __init__ for the Frame. There is also a panel.

Alt-X works (but that's not what I want here) but Esc
does not. Exactly (?) the same code works in another
frame...

···

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

I can catch things such as Alt-X with the accelerator table,
but I guess the Esc is eaten up by something else. First I

What else is in the frame?

···

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

I'll try to summarize... There are sizers, maybe they matter?
Here is some pieces of the code. (I just kept the lines that
seems most relevant. This will surely not run.) Basically all
controls are in a sizer in a sizer [sic].

class EntityDetailFrame(wxFrame):
     def __init__(self, parent, id, entity, owningObject = None):
         p = wxPanel(self, -1, size=wxSize(-1, -1))
         p.mainSizer = wxFlexGridSizer(4, 1, 10, 1)
         dt = dragdrop.EntityDropTarget(self, self.klass)
         self.SetDropTarget(dt)
         p.attrSizer = wxFlexGridSizer(1, 10, 1, 2)
         self.ID = wxTextCtrl(p, -1, size = wxSize(1,20))
         myValidator = gridobj.OneCharValidator(self.klass.typeChoices,
         self.type = wxTextCtrl(p, -1, size = wxSize(30,20), validator=myValidator)
         self.system = wxChoice(p, ID_SYSTEM, (100, 20), choices = self.getSystems())
         EVT_CHOICE(self.system, ID_SYSTEM, self.changeSystem)
         self.partOf = DropZoneListBox(p, PART_OF_ID, wxPoint(80, 50),
         p.listSizer.AddWindow(self.partOf, 0, wxALIGN_CENTER_VERTICAL, 5)
         self.newBtn = wxButton(p, NEW_BUTTON_ID, '&New %s' % className)
         p.buttonSizer.AddMany([
         EVT_BUTTON(self, CLOSE_BUTTON_ID, self.OnClose)
         EVT_MENU(self, ID_CLOSE, self.OnClose)
         aTable = wxAcceleratorTable(
             [(wxACCEL_NORMAL, WXK_ESCAPE, ID_CLOSE), # Doesn't work :frowning:
              (wxACCEL_ALT, ord('X'), ID_CLOSE)] # Works!
             )
         self.SetAcceleratorTable(aTable)

         # Finish sizer setup
         p.SetSizer(p.mainSizer)
         p.SetAutoLayout(true)
         self.Refresh()

         # Enter data into fields
         self.populate()

···

At 16:25 2002-04-12 -0700, you wrote:

> I can catch things such as Alt-X with the accelerator table,
> but I guess the Esc is eaten up by something else. First I

What else is in the frame?

--
Magnus Lyckå, Thinkware AB
Älvans väg 99, SE-907 50 UMEÅ
tel: 070-582 80 65, fax: 070-612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

> > I can catch things such as Alt-X with the accelerator table,
> > but I guess the Esc is eaten up by something else. First I
>
>What else is in the frame?

I'll try to summarize... There are sizers, maybe they matter?

No, they shouldn't. All they do is layout, no events.

Here is some pieces of the code. (I just kept the lines that
seems most relevant. This will surely not run.) Basically all
controls are in a sizer in a sizer [sic].

Try removing controls untli it works to see which is causing the problem,
then send a full sample that shows it.

···

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