[wxPython] TextCtrl, KeyEvent filtering -> segmentation fault

Anthony_Brooker · September 15, 2002, 12:45am

Some versions before I forget, ok at least the RPMs I've got installed.

wxPython-gl-2.3.2.1-1
wxGTK-2.3.2-1
wxGTK-gl-2.3.2-1
wxPython-2.3.2.1-1

Let's start with kudos for a pretty spiffy product of someone's serious
effort. I've been aware of Python for a few years but never really did
more than play with it. I discovered wxPython just before a job
application a year or so ago. Two weeks ago I decided to try a non
trivial but not too serious GUI and I have to say that I'm pretty
impressed with wxPython. I've used TCL/Tk in the past and I always felt
like I was fighting the implementation or the docs. With wxPython I've
managed to put together a basic GUI from scratch and it looks very much
like a "real" application. So I have to say thanks to anyone reading
this who's actually involved in the production of wxPython.

And I am seeking guidance on a couple of things. The first is a
question of the "right way" to do something. The second is too actually
but it's more of a feedback issue.

First let me say that what I would like is a little single line entry
widget with a simple history mechanism, you know a place for the user to
type in commands and be able to whizz up and down them with the cursor
keys for selecting a previously entered string. I thought about a
ComboBox but the binding seemed to be all wrong and I'm not clear on how
to change existing bindings. So what I did was use a TextCtrl and try
to add an event handler to filter out WXK_UP and down and simply change
the control's value:

        input = wxTextCtrl(self, id, style = wxTE_PROCESS_ENTER)
        EVT_CHAR(input, self.OnChar)
....
    def OnChar(self, event):
        if event.KeyCode() in [ WXK_UP, WXK_DOWN ] and len(self.cmds):
            wxPostEvent(self.input, HistoryEvent(event.KeyCode()))
        else:
            event.Skip()

    def HistSub(self, event):
        if event.data == WXK_UP:
            cmd = self.cmds.prev
        else:
            cmd = self.cmds.next

        i = self.input.GetInsertionPoint()
        self.input.SetValue(cmd())
        self.input.SetInsertionPoint(i)

The problem is that when I do this I get a segmentation fault when
running. I added the extra event in case it helped on the basis that it
might be a timing related issue. It didn't really change much, maybe
the frequency of the faults.

So the first question is Is there a(nother| better) way of achieving the
goal? Should I really try altering the bindings for the ComboBox
instead?

The second is that regardless of the nature of my stupidity I consider
the segfault a bug. (BTW removing just the history portion allows the
application to run for extended periods so I think it's pretty certain
to be wxPython/wxWindows rather than Python or libc) So does anyone
have any pointers for things to do to make the report more palatable?
And what might help narrow it down a bit more? And what the most
appropriate forum for recording it is?

All help appreciated.

Cheers.

Robin · September 16, 2002, 12:17pm

The problem is that when I do this I get a segmentation fault when
running. I added the extra event in case it helped on the basis that it
might be a timing related issue. It didn't really change much, maybe
the frequency of the faults.

Please send a small as possible standalone sample that shows the trouble so
I can track it down.

So the first question is Is there a(nother| better) way of achieving the
goal? Should I really try altering the bindings for the ComboBox
instead?

Have you seen the FileBrowseButton sample? The second row uses a combo and
shows something like what you are after. It's implementation is in
wxPython/lib/filebrowsebutton.py

The second is that regardless of the nature of my stupidity I consider
the segfault a bug.

Yes, we're getting better at trapping those. It will improve over time.

···

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

Anthony_Booker · September 16, 2002, 2:10pm

>
> The problem is that when I do this I get a segmentation fault when
> running. I added the extra event in case it helped on the basis that it
> might be a timing related issue. It didn't really change much, maybe
> the frequency of the faults.

Please send a small as possible standalone sample that shows the trouble so
I can track it down.

I'm working on it If I had it to hand I'd have sent it instead of
the ramblings.

> So the first question is Is there a(nother| better) way of achieving the
> goal? Should I really try altering the bindings for the ComboBox
> instead?

Have you seen the FileBrowseButton sample? The second row uses a combo and
shows something like what you are after. It's implementation is in
wxPython/lib/filebrowsebutton.py

I hadn't but I have now, thanks for the pointer, I think I have other
things to scan through for idea now too, hopefully even the answer to
the following.

The thing about the combo box is it "steals" the enter key to display
that list. I want the enter key to indicate the user's selection of the
displayed entry. I want to assign WXK_UP and WXK_DOWN to display and
move the selection in the drop down list. I couldn't find anything that
seemed to lead to that, hence I tried the snippet you saw.

> The second is that regardless of the nature of my stupidity I consider
> the segfault a bug.

Yes, we're getting better at trapping those. It will improve over time.

Don't misunderstand me, I'm not at all perturbed by the segfault.
Improvements are always welcome but I was thinking more pragmatically.
Is the "right thing to do", to pop up hear and say,
"The attached file gives problem X."
Or is there another list or a web page that feeds into a system to track
known issues? I was just looking for a pointer to the best way to
report what I believed to be a bug, rather than ask for help with my
ignorance of the environment.

As a developer it frustrates the hell out of me when I trip over an
issue that everyone in the field says is a "known" issue and engineering
is the only group that doesn't know it.

Thanks very much for your time and help.

···

On Mon, 2002-09-16 at 12:13, Robin Dunn wrote:

Corrado_Santoro · September 17, 2002, 12:40am

Hi all,
I'm using a TextCtrl to edit an RTF Text. I'm able to change fonts, colors,
etc., but when I use the method GetValue () to get the text, all information
regarding color change points is missing. What I'm doing wrong? Is there a
method to get the *complete* RTF information?

Thanks in advance.

-Corrado

···

-------------------------------------------------
This mail sent through IMP: http://www.cdc.unict.it/

Robin · September 17, 2002, 2:30pm

I'm using a TextCtrl to edit an RTF Text. I'm able to change fonts,

colors,

etc., but when I use the method GetValue () to get the text, all

information

regarding color change points is missing. What I'm doing wrong? Is there a
method to get the *complete* RTF information?

No, unfortunately not. The wxTextCtrl was not meant to be a RTF editor, but
some RTF capabilites are exposed in order to get viewable colors and etc.

···

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

David_C_Fox2 · September 17, 2002, 3:30pm

Anthony Brooker wrote:

First let me say that what I would like is a little single line entry
widget with a simple history mechanism, you know a place for the user to
type in commands and be able to whizz up and down them with the cursor
keys for selecting a previously entered string. I thought about a
ComboBox but the binding seemed to be all wrong and I'm not clear on how
to change existing bindings. So what I did was use a TextCtrl and try
to add an event handler to filter out WXK_UP and down and simply change
the control's value:

        input = wxTextCtrl(self, id, style = wxTE_PROCESS_ENTER)
        EVT_CHAR(input, self.OnChar)
....
    def OnChar(self, event):
        if event.KeyCode() in [ WXK_UP, WXK_DOWN ] and len(self.cmds):
            wxPostEvent(self.input, HistoryEvent(event.KeyCode()))
        else:
            event.Skip()

    def HistSub(self, event):
        if event.data == WXK_UP:
            cmd = self.cmds.prev
        else:
            cmd = self.cmds.next

        i = self.input.GetInsertionPoint()
        self.input.SetValue(cmd())
        self.input.SetInsertionPoint(i)

The problem is that when I do this I get a segmentation fault when
running. I added the extra event in case it helped on the basis that it
might be a timing related issue. It didn't really change much, maybe
the frequency of the faults.

I've written something similar as part of the VoiceCode project (VoiceCode Programming by Voice Toolbox download | SourceForge.net) I'm working on. You can use the BrowseCVS interface at SourceForge to take a look at my (GPL'd) source, wxCmdPrompt.py:

It is also not a minimal sample, and depends on stuff in CmdPrompt.py and Object.py in the same directory, but it may still be helpful.

I don't see anything obviously wrong with your code above, though of course you've omitted the definition of HistoryEvent, or how it gets hooked to HistSub, or how self.cmds.prev() works.

The SetInsertionPoint seems a bit of an odd design choice, since where you are in the current command doesn't necessarily have anything to do with where you want to be when you edit the previous command. I just use SetInsertionPointEnd. However, I've just checked that setting the insertion point beyond the end of the control just sets it to the last position, under both Windows and GTK, so that doesn't seem to be the cause of the segmentation fault.

Otherwise, the main difference in my code seems to be that I do the SetValue and SetInsertionPoint right in the key event handler, rather than posting another event, but I assume that is what you had before adding the second event.

So the first question is Is there a(nother| better) way of achieving the
goal? Should I really try altering the bindings for the ComboBox
instead?

Don't know, but it's definitely doable with wxTextCtrl.

David

Anthony_Booker · September 21, 2002, 10:35am

All righty then!

I am a doofus. I whittled away and tweaked and played and modeled to
get code that failed and I _couldn't_ get the fault to reproduce. Then
I went away to try looking at a different bit of functionality for a
break. That's when I spotted a nasty little (debug) call to a GUI
routine in an event posting call. Once this was cleared up all of the
previously tried approaches worked fine. Sorry for wasting everyone's
time.

But now I have 5 or 6 different ways to implement my history mechanism.

David,

Thanks for the pointers I haven't looked at your stuff yet since it's a
self inflicted wound.

BTW I waffle on the cursor position during history movement but
basically the idea is, if I am in the middle of a string and push "up
arrow" my eye gets confused when the cursor goes winging off to a
different column. If I go up two then down two I want the display to be
unchanged.

···

On Mon, 2002-09-16 at 14:07, Anthony Booker wrote:

On Mon, 2002-09-16 at 12:13, Robin Dunn wrote:
> >
> > The problem is that when I do this I get a segmentation fault when
> > running. I added the extra event in case it helped on the basis that it
> > might be a timing related issue. It didn't really change much, maybe
> > the frequency of the faults.
>
> Please send a small as possible standalone sample that shows the trouble so
> I can track it down.

I'm working on it If I had it to hand I'd have sent it instead of
the ramblings.

David_C_Fox2 · September 21, 2002, 11:25am

Anthony Booker wrote:

David,

Thanks for the pointers I haven't looked at your stuff yet since it's a
self inflicted wound.

BTW I waffle on the cursor position during history movement but
basically the idea is, if I am in the middle of a string and push "up
arrow" my eye gets confused when the cursor goes winging off to a
different column. If I go up two then down two I want the display to be
unchanged.

What I did in my class was this:

If you are at the end of the history (i.e. entering a new command) and move up, I store the text and selection. If you later move back down to the end, both the text and the selection are restored. However, if you move up, start to edit a command, and then move up or down and back again, neither the text nor the selection are restored. I did it that way so that if you start to edit a previous command, realize you've messed up and want to get back the original version of that command, you can do so by moving down and up (or vice versa).

Of course, that means the selection is always jumping (to the end for commands in the history, or to its previous range for the new command).

I was mostly guided in my UI choices by the tcsh command history, which is what I'm most used to (except that tcsh doesn't store/restore the new command).

David

···

On Mon, 2002-09-16 at 14:07, Anthony Booker wrote:

On Mon, 2002-09-16 at 12:13, Robin Dunn wrote:

Robin · September 21, 2002, 2:00pm

Anthony Booker wrote:

···

On Mon, 2002-09-16 at 14:07, Anthony Booker wrote:

On Mon, 2002-09-16 at 12:13, Robin Dunn wrote:

The problem is that when I do this I get a segmentation fault when
running. I added the extra event in case it helped on the basis that it
might be a timing related issue. It didn't really change much, maybe
the frequency of the faults.

Please send a small as possible standalone sample that shows the trouble so
I can track it down.

I'm working on it If I had it to hand I'd have sent it instead of
the ramblings.

All righty then!

I am a doofus. I whittled away and tweaked and played and modeled to
get code that failed and I _couldn't_ get the fault to reproduce. Then
I went away to try looking at a different bit of functionality for a
break. That's when I spotted a nasty little (debug) call to a GUI
routine in an event posting call. Once this was cleared up all of the
previously tried approaches worked fine. Sorry for wasting everyone's
time.

This is exactly why I insist that people whittle down their problems into the simplest possible example of the problem. Much of the time the problem evaporates in the process.

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

Anthony_Booker · September 21, 2002, 4:10pm

Unless we're talking about the problem of thread safety in the GUI.

···

On Sat, 2002-09-21 at 13:53, Robin Dunn wrote:

Anthony Booker wrote:
> break. That's when I spotted a nasty little (debug) call to a GUI
> routine in an event posting call. Once this was cleared up all of the
> previously tried approaches worked fine.

This is exactly why I insist that people whittle down their problems
into the simplest possible example of the problem. Much of the time the
problem evaporates in the process.