Hi friends,
For those of you that have to write or use non-English alphabet it's
common to write something in their own language (e.g. in a GUI app
static text box) and just after that to see the same text coverted to
'\xcf\xd4\xde\xce' or something of the kind. In most cases that is
not a problem - when the frame is displayed you can see the original
text even though Pythos stores it as '\x\x\x\x'.
So here comes my question: I am using Boa Constrauctor 0.4.0 +Python
2.4.1+ wxPython 2.5.5.1 on os Win98 SE for creating user interfce of
Firebird database . For visualization of the data in the base on
computer screen I tried to use wxGrid that could arrange the data in
something like a spreadsheet table. But when I tried to use
wxGrid::SetCellValue (row, col, string), instead of the orirginal text
(in my case Bulgarian -cyrillic- text), in the cell I saw
'\xcf\xd4\xde\xce' . So that's the problem.
Today it's my fourth day of reading manuals, mail lists, various posts
and examples, but nothing useful have I found. I am not quite sure that
using wxGrid is the only way to display data in a table-like format,
perhaps you can suggest some other way. If it's too long to explain
just give me a hint - I will do whatever it takes to get the right
result.
Thank you very much in advance!
degoor
To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

Hello everyone,

I'm new to wxPython and new to GUI programming in general but, with a
lot of patience and heavy use of the demos, documentation and the
wxPython wiki, I've managed to get most of my problems figured out
eventually. But now I'm stumped and could use a little hand holding

I'm running XP/SP2 using Python 2.4 (ActiveState install) and a very
recent version of wxPython based on wxWidgets 2.6.0.

I have two issues, both of which have to do with capturing keyboard
events. The easy one first

My application has several dialog entry forms, all of which are derived
from wx.Dialog. I would like to capture the ESC key and, in response,
perform the same action as I would when the user clicks on the 'Done' or
'Cancel' button (or whatever button is appropriate for the situation).
The best I can figure out to do is something like this:

Near the end of the __init__() for my derived dialog class I have the line

wx.EVT_CHAR(self, Char)

Then I have a method, Char(self, event), that (for the time being)
does nothing but print "I'm here!" to the console. The trouble is
Char() appears NEVER to be called no matter what keys I press. It
seems like binding the ESC key should be a simple thing to do. I
suspect it is and I'm just missing something. I saw an earlier post
where the poster was having a similar problem but I'm afraid I didn't
comprehend the fix. Anyone want to have another go?

Problem 2:

This is also related to keyboard capture. Like all wxPython
applications (I guess), I derive an application class from wx.App and
that class does little other than instantiating an instance of
MainWindow (a class I wrote derived from wx.Frame), calling
SetTopWindow() on it and making it visible. The code in my derived
MainWindow class represents the bulk of my application. In the
__init__() for MainWindow(), I lay out the widgets that make up my
application interface which, in this case, consists of a handful of
buttons, a few labels and an htmlWindow.

Now I would like to bind keyboard shortcuts to a few of the buttons. I
tried wx.EVT_CHAR() here too and met with the same problem as before --
the Char() method never seems to get called no matter what key I
press. I saw an earlier post where someone suggested using an
AcceleratorTable. I set one up and hey! That mostly works! My
specific trouble has to do with the exact keys I'm trying to bind --
SPACE, BACK and RETURN. This is an unusual set, I know, but this code
is a port from an earlier Python/Tkinter version of the application and
that version used SPACE, BACK and RETURN. If possible, I'd like to
continue using them rather than explaining to people that I was too dumb
to figure out how! :-)

BACK and RETURN handling seems to work exactly like I want. SPACE
however is troublesome. The AcceleratorTable technique picks up the
SPACE event no problem and it does the right thing with it. The trouble
is, whatever button happens to have focus at the time also picks up the
SPACE event and acts on it resulting in two actions -- one wanted, one
unwanted.

How can I prevent the button with focus from acting on the SPACE event?
Is there a way to make the buttons so they can't ever have keyboard
focus in the same way that labels, say, don't get keyboard focus?
(Actually I would prefer that anyway) Alternatively, all my buttons are
instances of my own button class derived from wx.Button. Is there a way
I can capture and ignore the SPACE event if they do have focus?

Thanks,

All suggestions or comments welcome!

Charlie Hubbard

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

Robin Dunn wrote:
>My application has several dialog entry forms, all of which are
>derived from wx.Dialog. I would like to capture the ESC key and, in
>response, perform the same action as I would when the user clicks on
>the 'Done' or 'Cancel' button (or whatever button is appropriate for
>the situation).

This should already happen automatically if you give your button an ID
of wx.ID_CANCEL.

Damn that was simple! I never would have figured that out. I added it
to all my dialog boxes and now the ESC key is handled exactly the way I
want.

>Problem 2:
>>
>How can I prevent the button with focus from acting on the SPACE
>event? Is there a way to make the buttons so they can't ever have
>keyboard focus in the same way that labels, say, don't get keyboard
>focus? (Actually I would prefer that anyway) Alternatively, all my
>buttons are instances of my own button class derived from wx.Button.
>Is there a way I can capture and ignore the SPACE event if they do
>have focus?

Yep. Bind a handler for wx.EVT_KEY_DWN and only call evt.Skip for the
events that you do want the native control to receive.

This too worked exactly as advertised! I spent hours kludging in
different things, all of which failed. This was easy!

Thanks for the quick response and the spot on advice! It was very much
appreciated.

Charlie Hubbard

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

I'm using XP/SP2 with Python 2.4 (ActiveState) and xwPython based on
wxWidgets 2.6.

I have several buttons on the main window of my application. I see that
I can cause a specific character in a button's label to appear
underlined by prefixing that character with an '&' character in the
label text. So, for instance, the label text "&Pass" appears on the
button with the 'P' underlined. Perfect! However, I have a dialog box
containing nothing but buttons and I would like to bind hotkeys to some
of them. I used the '&' character trick to indicate which letter in the
label I mean to bind and would like to be underlined. The actual
binding works fine. When I press the associated key the action bound to
the button is performed. Great! But the character in the label is NT
underlined. It just appears like any other of the button label
characters. Anyone know why?

I don't think this is related but, just to clarify, I should point out
that I'm not explicitly .Bind()ing anything. I just added the '&' in
front of the letter I want to be a hotkey and suddenly that key is
magically bound.

Functionally, the program is working fine. I'm just puzzled that the
associated character in the text of the button label isn't underlined.
As far as appearance is concerned, the '&' trick seems to work for
buttons in the main window but doesn't work for buttons in the dialog
box. I'm clueless.

Charlie Hubbard

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

Robin Dunn wrote:
Charlie Hubbard wrote:
When I press the associated key the action
>bound to the button is performed. Great! But the character in the
>label is NT underlined. It just appears like any other of the button
>label characters. Anyone know why?

I think that whether the underline shows up or not is a Windows
preference setting. Do they show up if you press and release the alt key?

You were exactly right! I guess you can tell I'm not much of a Windows
expert.

The "feature" of hiding the underlines can be turned off from the XP
"Display Properties" dialog, under the "Appearance" tab, under the
"Effects" button. I can't think of a more useless feature and I
can't believe that, by default, it's in its least useful mode, but there
you have it. Thanks again, Robin.

Charlie Hubbard

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

I'm running XP/SP2 using Python 2.4 (ActiveState install) and wxPython
based on wxWidgets 2.6.1.0

In my application I have a dialog box class derived from wx.Dialog which
contains a virtual list control and a few buttons at the bottom (Add,
Edit, Delete, Done). The list control widget in the dialog box is
instantiated from my own class, MyVirtualListControl(wx.ListCtrl), which
does nothing special other than to override GetItemText() and
GetItemAttr().

I've encountered some strange behavior that I can't explain and can't
figure out how to fix. When the dialog first opens, the list control
has focus (it's the first widget in the dialog box). If I D NT use the
mouse to click somewhere within the list control first, then the first
time I press any letter key, the application locks up tight and uses
100% of the CPU. If I D click anywhere in the list control first, then
everything works fine and no amount of key pressing causes a lock up.

Now assume I don't touch the mouse once the dialog is open
I can use the TAB and SHIFT-TAB keys to move the focus to the buttons.
When I do this, pressing any letter key (that hasn't been bound to a
button) generates the expected "beep" sound indicating that key doesn't
do anything but the application runs fine with no lock ups. If I press
a bound letter key, the action associated with the corresponding button
takes place. If I TAB or SHIFT-TAB back so the list control has focus
again, the first time I press any letter key, the application locks up
as previously described. The only way I can find to eliminate the lock
ups is to make sure I've used the mouse to click within the list control
at least once at any point before pressing a letter key. that's
been done, I can TAB/SHIFT-TAB to my heart's content, move around in the
list control (with the mouse or with keys), press any letter keys I feel
like and the application continues to run just fine.

Anyone have any ideas? I've tried binding EVT_LIST_KEY_DWN and
EVT_KEY_DWN in the dialog and I've set up the handlers for those just
to print "LIST_KEY_DWN" or "KEY_DWN" respectively. If I don't do the
mouse click trick first, "LIST_KEY_DWN" gets printed exactly once.
After that the application is frozen and my CPU usage is at 100%. I've
alternately tried using event.Skip() and not using event.Skip() in my
handlers but neither way seems to alter the behavior.

Does anyone know what I've forgotten to do? Is there some way I can
simulate this magical initial mouse click? I've tried explicitly
setting focus on the list control (self.mylist.SetFocus()) and then
explicitly selecting the first entry in the list (self.mylist.Select(0,
True). Those seem to do what you'd expect (when the dialog box opens
the list control has focus and the first entry is selected) but it still
exhibits the lock up behavior unless I actually click somewhere inside
the list control first before pressing any letter keys.

This is really weird. Any help would be most appreciated!

Charlie Hubbard

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

I'm running XP/SP2 using Python 2.4 (ActiveState) and wxPython based on
wxWidgets 2.6.1.0

I described this problem in a post yesterday but, although I tried to be
specific, I think my description was probably too vague to be useful.
This time I've cut down my application to its bare essentials (about 80
lines) so others could at least test it. Please see the attached .zip
file. I've renamed the extension to '.piz' because my mailer gets upset
when I try to send .zip files. But it's a .zip! Just rename it! :-)

To briefly redescribe the problem

I have a virtual ListCtrl inside a dialog box. The ListCtrl has an
overridden GetItemText() method (this is required for virtual
ListCtrls) that supplies the list data. I open the dialog box, if
I press any letter key BEFRE ever having clicked inside the ListCtrl
with the mouse, the program locks up. If I click inside the ListCtrl at
least once anytime before pressing a letter key, the program doesn't
lock up.

I figure there must be some interaction between the ListCtrl and the
dialog box because the virtual ListCtrl demo (which isn't in a dialog
box) runs fine for me both from within the demo viewer application and
when run stand-alone. I didn't see anything in the demo code that I'm
not already doing (or have tried). The only difference I see is my
ListCtrl is in a dialog box.

I'd appreciate it if someone wouldn't mind trying the code on their
system and seeing if the behavior is the same. If you do, also try it
after uncommenting the "print" line in GetItemText(). With that line
in place, you can see that when the program is locked up, it appears to
be asking for row data over and over and over without end. I'm not sure
what that means but it seems like it might be a helpful clue to someone
more experienced than myself.

Thanks!

Charlie Hubbard

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

Dom, 2005-06-26 00:13 -0700, Charlie Hubbard escreveu:
I'm running XP/SP2 using Python 2.4 (ActiveState) and wxPython based on
wxWidgets 2.6.1.0

To briefly redescribe the problem

I have a virtual ListCtrl inside a dialog box. The ListCtrl has an
overridden GetItemText() method (this is required for virtual
ListCtrls) that supplies the list data. I open the dialog box, if
I press any letter key BEFRE ever having clicked inside the ListCtrl
with the mouse, the program locks up. If I click inside the ListCtrl at
least once anytime before pressing a letter key, the program doesn't
lock up.

It happens to me too, and it's strange because if I set the items count
to >= 1001 ( self.myList.SetItemCount(1001) ) this doesn't happen.
If I set to <= 1000 ( self.myList.SetItemCount(1000) ) this happen
again.

See if you see this behaviour?

Ricardo

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

Ricardo, that was an interesting find! It happens on my system too. If
the item count is set to 1000 or smaller, it locks up. Above 1000 it
doesn't. The same is true with the ListCtrl_virtual.py demo program so
apparently my theory of it being related to the dialog box was wrong.
Maybe this is a real bug and not just a mistake in my code.

Charlie Hubbard

Ricardo Pedroso wrote:
Dom, 2005-06-26 00:13 -0700, Charlie Hubbard escreveu:

>>I'm running XP/SP2 using Python 2.4 (ActiveState) and wxPython based on
>>wxWidgets 2.6.1.0


>>To briefly redescribe the problem
>>
>>I have a virtual ListCtrl inside a dialog box. The ListCtrl has an
>>overridden GetItemText() method (this is required for virtual
>>ListCtrls) that supplies the list data. I open the dialog box, if
>>I press any letter key BEFRE ever having clicked inside the ListCtrl
>>with the mouse, the program locks up. If I click inside the ListCtrl at
>>least once anytime before pressing a letter key, the program doesn't
>>lock up.

It happens to me too, and it's strange because if I set the items count
to >= 1001 ( self.myList.SetItemCount(1001) ) this doesn't happen.
If I set to <= 1000 ( self.myList.SetItemCount(1000) ) this happen
again.

See if you see this behaviour?

Ricardo

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

.

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

Dom, 2005-06-26 09:11 -0700, Charlie Hubbard escreveu:
Ricardo, that was an interesting find! It happens on my system too. If
the item count is set to 1000 or smaller, it locks up. Above 1000 it
doesn't. The same is true with the ListCtrl_virtual.py demo program so
apparently my theory of it being related to the dialog box was wrong.
Maybe this is a real bug and not just a mistake in my code.

Yes. I agree. It seems to be a bug in wxwidgets.

I found in the wxwidgets code (src/msw/listctrl.cpp), this:

case LVNDFINDITEM:
// this message is only used with the virtual list control but
// even there we don't want to always use it: in a control with
// sufficiently big number of items (defined as 1000 here),
// accidentally pressing a key could result in hanging an
// application waiting while it performs linear search
if ( IsVirtual() && GetItemCount() <= 1000 )
{

I think this explains the magic number 1000 and problably the bug.

Ricardo

Ricardo Pedroso wrote:
Dom, 2005-06-26 00:13 -0700, Charlie Hubbard escreveu:

>>I'm running XP/SP2 using Python 2.4 (ActiveState) and wxPython based on
>>wxWidgets 2.6.1.0


>>To briefly redescribe the problem
>>
>>I have a virtual ListCtrl inside a dialog box. The ListCtrl has an
>>overridden GetItemText() method (this is required for virtual
>>ListCtrls) that supplies the list data. I open the dialog box, if
>>I press any letter key BEFRE ever having clicked inside the ListCtrl
>>with the mouse, the program locks up. If I click inside the ListCtrl at
>>least once anytime before pressing a letter key, the program doesn't
>>lock up.

It happens to me too, and it's strange because if I set the items count
to >= 1001 ( self.myList.SetItemCount(1001) ) this doesn't happen.
If I set to <= 1000 ( self.myList.SetItemCount(1000) ) this happen
again.

See if you see this behaviour?

Ricardo

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

.

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org

That was great work, Ricardo. My particular application typically runs
with about 2,000 items in the list so it shouldn't normally hurt me.
Yesterday though I was using a smaller database during development (40
entries). For now I've changed my code to SetItemCount(1001) if the
database size is smaller than that and re-did my GetItemText() and
GetItemAttr() methods to return dummy values when necessary. It's not
pretty, but it's better than having the program lock up!

Thank you for your help on this.

Charlie Hubbard

Ricardo Pedroso wrote:
Dom, 2005-06-26 09:11 -0700, Charlie Hubbard escreveu:

>>Ricardo, that was an interesting find! It happens on my system too. If
>>the item count is set to 1000 or smaller, it locks up. Above 1000 it
>>doesn't. The same is true with the ListCtrl_virtual.py demo program so
>>apparently my theory of it being related to the dialog box was wrong.
>>Maybe this is a real bug and not just a mistake in my code.

Yes. I agree. It seems to be a bug in wxwidgets.

I found in the wxwidgets code (src/msw/listctrl.cpp), this:

case LVNDFINDITEM:
// this message is only used with the virtual list control but
// even there we don't want to always use it: in a control with
// sufficiently big number of items (defined as 1000 here),
// accidentally pressing a key could result in hanging an
// application waiting while it performs linear search
if ( IsVirtual() && GetItemCount() <= 1000 )
{

I think this explains the magic number 1000 and problably the bug.

Ricardo

To unsubscribe, e-mail: wxPython-users-unsubscribe (AT) lists (DOT) wxwidgets.org
For additional commands, e-mail: wxPython-users-help (AT) lists (DOT) wxwidgets.org