If wx.TextCtrl has style flags wx.TE_MULTILINE | wx.TE_PROCESS_ENTER, it would be nice if pressing SHIFT+ENTER would produce a new line and not trigger the Enter key event right away (as is the status quo).
Also, after normally pressing ENTER, the caret is moved to the next line after the focus is returned back to the text control. Can you please make the caret stay where it is?
Bo�tjan Mejak wrote:
If wx.TextCtrl has style flags wx.TE_MULTILINE |wx.TE_PROCESS_ENTER, it would be nice if pressing SHIFT+ENTER
would produce a new line and not trigger the Enter key event right
away (as is the status quo).
Do you have a sample that shows this?� If you run TextCtrl.py from
the wx demo, Shift-Enter behaves exactly like Enter.
Also, after normally pressing ENTER, the caret is moved to thenext line after the focus is returned back to the text control.
Can you please make the caret stay where it is?
The behavior you see is that of the operating system's native text
control.� By default, if you take focus away from a text control and
then return focus, the behavior is to select all of the text in the
control.� However, you should be able to do whatever you want, if
you handle the OnSetFocus and OnKillFocus events yourself.
Boštjan Mejak wrote:
If wx.TextCtrl has style flags wx.TE_MULTILINE | wx.TE_PROCESS_ENTER,
it would be nice if pressing SHIFT+ENTER would produce a new line and
not trigger the Enter key event right away (as is the status quo).Do you have a sample that shows this? If you run TextCtrl.py from the
wx demo, Shift-Enter behaves exactly like Enter.
I think that is the point he is trying to make. He would like there to be different behavior for Shift-Enter.
I doubt that wx will officially support this as it is preferred to allow the native widgets to behave as they normally do, but you can probably do it by handling the key and other events yourself. BTW, I've seen cases where Ctrl-Enter behaving like this, have you tried that?
Also, after normally pressing ENTER, the caret is moved to the next
line after the focus is returned back to the text control. Can you
please make the caret stay where it is?The behavior you see is that of the operating system's native text
control. By default, if you take focus away from a text control and
then return focus, the behavior is to select all of the text in the
control. However, you should be able to do whatever you want, if you
handle the OnSetFocus and OnKillFocus events yourself.
The selection actually happens after the focus event, but you can still reset the selection (or whatever) if you use wx.CallAfter to do it. Be sure to call event.Skip from the focus handler as some ports need to do additional work and will cause problems if they are not able to.
On 10/14/11 11:02 AM, Tim Roberts wrote:
--
Robin Dunn
Software Craftsman
Windows’ UI is messed up badly. These native controls are so buggy that I hate coding on Windows just because of this tiny reason.
Bo�tjan Mejak wrote:
Windows' UI is messed up badly. These native controls are so buggythat I hate coding on Windows just because of this tiny reason.
I disagree **strongly** .� The fact that the native controls do
not react in exactly the way you wish does not make them buggy.� The
fact is that, with very few exceptions, the Windows control behave
the way they do because Microsoft has spent tens of millions of
dollars on user interface research to find out what most people
expect.
That same effort has not gone into widget sets for other
environments, the result being that the user interface guidelines
tend there tend to be crafted by computer programmers, and
programmers as a class SUCK at user interface design.
Why should Shift-Enter behave different from Enter?� Do you think
your secretary expects it to be different?� There are hundreds of
times more people like her using this software than there are people
like us.
The only time I’ve seen Shift+Enter mean anything is in Microsoft Word (and other Office products), when you want to force a single carriage return instead of a double (like for bullet points). For some reason, CTRL+Enter jumps me to the beginning of the next page in Word. Interesting. I learned something new. I personally like most of the Windows UI, although I’m still getting used to the RibbonBar.
The only time I've seen Shift+Enter mean anything is in Microsoft Word
(and other Office products),
...
For some reason,
CTRL+Enter jumps me to the beginning of the next page in Word.
It is the accelerator for inserting a hard page-break.
On 10/14/11 2:04 PM, Mike Driscoll wrote:
--
Robin Dunn
Software Craftsman
For some reason, CTRL+Enter jumps me to the beginning of the next page in Word. Interesting. I learned something new.
Just last week I noticed for the first time that holding down CTRL and spinning the mouse wheel in Word changes the zoom %. (That happens to be true for Boa Constructor, too…and probably lots of text windows).
On a multi line textctrl Enter (and shift enter) is "return" and ctrl-enter going to next control.
Werner
On 10/14/2011 08:23 PM, Robin Dunn wrote:
On 10/14/11 11:02 AM, Tim Roberts wrote:
Boštjan Mejak wrote:
If wx.TextCtrl has style flags wx.TE_MULTILINE | wx.TE_PROCESS_ENTER,
it would be nice if pressing SHIFT+ENTER would produce a new line and
not trigger the Enter key event right away (as is the status quo).Do you have a sample that shows this? If you run TextCtrl.py from the
wx demo, Shift-Enter behaves exactly like Enter.I think that is the point he is trying to make. He would like there to be different behavior for Shift-Enter.
I doubt that wx will officially support this as it is preferred to allow the native widgets to behave as they normally do, but you can probably do it by handling the key and other events yourself. BTW, I've seen cases where Ctrl-Enter behaving like this, have you tried that?
Correct. It was introduced silentely in one of the
2.8.n series. No comment, no documentation. It has
forced me to adapt and correct all of my major
applications.
On 15 oct, 10:51, werner <wbru...@free.fr> wrote:
On a multi line textctrl Enter (and shift enter) is "return" and
ctrl-enter going to next control.
---
The keys/chars handling has *never* worked correctly
since I discovered wxPython at the release 2.1 something
like 10 years ago.
To tell you the truth, it is the main reason why some
time ago I decided to take a closer look at other
Python GUIs, like PySide, PyQt or Tkinter. I quicky
noticed that these toolkits were working very smoothly
and correctly. Regarding the keys/chars handling, they
show EXACLY the same behavior it can be found in other tools
like Visual Basic, Delphi, Java, Borland (vcl) or Visual
Basic for Applications. (I never progammed in Java, I
took the time to dive deeply in the documentation, enough
to realise, it's like the MS api).
-----
About Ctrl+Enter Robin Dunn wrote:
"It is the accelerator for inserting a hard page-break."
Yes, but the key point is to know where this is
pragrammaticaly done. Is there a special flag for this
or it is just working fine because the keys/chars handling,
in that case, probably, an "OnKeyDown", is working correctly?
I do not know, my feeling is on the latter case. The Microsoft
Visual Basic 3 (three!) book gave an exemple, how to
program it.
----
The real question is this. Why does a TextCtrl propose
a wx.TE_PROCESS_ENTER flag when all this stuff has to
be in an OnKeyDown handler?
Answer, I suspect the main reason lies in the fact
that the keys/chars handling in wxWidgets is a mess.
There is absolutely no reason, that a widget alters a keys
combination. Not only, it does not work properly, it does
not allow a user to program correctly.
---
GetKeyCode? Still not working on my keyboard! Curiously, no
problem with Qt derivatives and tkinter.
---
A few months ago. I fell on a web discussion initiated
by a guy who has problems with the "Transana" product:
keyboard issues. From his explanation, it took me
less than 10 seconds to understand the origin of
the problem.
---
After all these years. I do not know what to think
about wxPython.
Most of the people in this list are disucussing about
icons in dlgs or icons in tree list view.
The basic stuff a computer is supposed to do, input from
a keyboard or text displaying/rendering (on of the other
wxWidgets issue) is not working properly.
---
I left away from this discussion, the internal representation
of a Unicode, in wxWidgets 
jmf
Hi jmf,
you seem to me in a "rumbling" mood lately.
Isn't a key difference between tkinter and qt that they implement mostly there own widgets, i.e. don't fall back to the platform native widget - which probably makes things just a little bit easier.
Anyhow I am very happy with wxPython and had recently looked at pySide and didn't see a reason to switch - actually one of the big reasons not to switch is this list.
I am a bit surprised that you still seem to follow this list very closely even so it sounds that you already switched to one of these other kits;-) .
0.02 � from a fellow Swiss in the South of France.
Werner
On 10/15/2011 01:55 PM, jmfauth wrote:
On 15 oct, 10:51, werner<wbru...@free.fr> wrote:
On a multi line textctrl Enter (and shift enter) is "return" and
ctrl-enter going to next control.Correct. It was introduced silentely in one of the
2.8.n series. No comment, no documentation. It has
forced me to adapt and correct all of my major
applications.---
The keys/chars handling has *never* worked correctly
since I discovered wxPython at the release 2.1 something
like 10 years ago.To tell you the truth, it is the main reason why some
time ago I decided to take a closer look at other
Python GUIs, like PySide, PyQt or Tkinter. I quicky
noticed that these toolkits were working very smoothly
and correctly. Regarding the keys/chars handling, they
show EXACLY the same behavior it can be found in other tools
like Visual Basic, Delphi, Java, Borland (vcl) or Visual
Basic for Applications. (I never progammed in Java, I
took the time to dive deeply in the documentation, enough
to realise, it's like the MS api).-----
About Ctrl+Enter Robin Dunn wrote:
"It is the accelerator for inserting a hard page-break."Yes, but the key point is to know where this is
pragrammaticaly done. Is there a special flag for this
or it is just working fine because the keys/chars handling,
in that case, probably, an "OnKeyDown", is working correctly?
I do not know, my feeling is on the latter case. The Microsoft
Visual Basic 3 (three!) book gave an exemple, how to
program it.----
The real question is this. Why does a TextCtrl propose
a wx.TE_PROCESS_ENTER flag when all this stuff has to
be in an OnKeyDown handler?Answer, I suspect the main reason lies in the fact
that the keys/chars handling in wxWidgets is a mess.
There is absolutely no reason, that a widget alters a keys
combination. Not only, it does not work properly, it does
not allow a user to program correctly.---
GetKeyCode? Still not working on my keyboard! Curiously, no
problem with Qt derivatives and tkinter.---
A few months ago. I fell on a web discussion initiated
by a guy who has problems with the "Transana" product:
keyboard issues. From his explanation, it took me
less than 10 seconds to understand the origin of
the problem.---
After all these years. I do not know what to think
about wxPython.
Most of the people in this list are disucussing about
icons in dlgs or icons in tree list view.
The basic stuff a computer is supposed to do, input from
a keyboard or text displaying/rendering (on of the other
wxWidgets issue) is not working properly.---
I left away from this discussion, the internal representation
of a Unicode, in wxWidgetsjmf
Yes, you are right and I should say that I have a little
bit lost my fun in programming.
Now the technical discussion. The keys/chars handling in
wxWidgets has never worked properly. Even VZ on the dev-list
wrote "it is a mess". Unfortunately, this is a fact and a real
fact. There is not too much to say or to argue, it is very simple
to check that this is wrongly working.
The point that it seems you are missing is the following.
I'm not advocating tkinter [1] or a qt derivative over wxPython
(mainly a wxWidgets problem), without counting pyGTK I never
really tested.
The point is that, because I'm perpetuously annoyed by this,
I decided a year ago to really spend some time with these
toolkits in order to check seriously the situation.
And I should recognize that I did no find any issue [2]. Not
only there are working as expected, but they are working as
smoothly as another tools you can find for a Windows platorms.
I dropped Visual Basic long time ago when I discovered Python.
However, I take the time to check and to wrote some VBA "macros"
with a recent version of MS Office machine, just to check
if "Windows" has changed something on this level. No problem.
I'm no more writing "large" applications. I'm only maintaining
Python interactive interpreters (PySide, PyQt4 for Python 3 and
tkinter Python 3) because Python is so funny.
I did not switch or ditch wxPython, just toying with
other toolkits.
I perfectly understand there may be a bug in a toolkit. But
when you pressed a key and this "key" is not rendered on a
widget, it seems to me that there is a problem. If you
add to this, this is existing since 10 (ten) years and
in various different forms varying with the misc. versions
of wxWidgets (even in the same serie), I'm allowing me
to ask if there is not something wrong somewhere.
jmf
[1] Python 3 helped me to finally dive in tkinter.
[2] Except a very special keys combination envolving a
Tab key. A known and reported Qt bug.
[3] File archeolgy, code in one of my old version of my
interactive interpreter:
def OnKeyDown(self, event):
kc = event.GetKeyCode()
modif = event.GetModifiers()
# ctrl+return seems to be used now for tab navigation (!), only
MOD_NONE is
tested.
if kc in [wx.WXK_RETURN, wx.WXK_NUMPAD_ENTER] and modif !=
wx.MOD_NONE:
return
On 15 oct, 16:20, werner <wbru...@free.fr> wrote:
Hi jmf,
you seem to me in a "rumbling" mood lately.
Note that my statement was about Ctrl-Enter in MS Word, and has nothing to do with wx.
On 10/15/11 4:55 AM, jmfauth wrote:
About Ctrl+Enter Robin Dunn wrote:
"It is the accelerator for inserting a hard page-break."Yes, but the key point is to know where this is
pragrammaticaly done. Is there a special flag for this
or it is just working fine because the keys/chars handling,
in that case, probably, an "OnKeyDown", is working correctly?
I do not know, my feeling is on the latter case. The Microsoft
Visual Basic 3 (three!) book gave an exemple, how to
program it.
--
Robin Dunn
Software Craftsman
In Facebook, for example, when you comment something, you can write your comment and press Enter to send the comment. If you want to create a new line in your comment, you need to press Shift+Enter in order to do that. So my question was regarding this same behaviour, but in a multilined wx.TextCtrl. Is that possible to implement?
I’m coming late to this discussion, but won’t event.ShiftDown() allow you to distinguish between a newline and a form submission (or whatever you want to call it)?
-Nat
On Sat, Oct 15, 2011 at 12:04 PM, Boštjan Mejak bostjan.mejak@gmail.com wrote:
In Facebook, for example, when you comment something, you can write your comment and press Enter to send the comment. If you want to create a new line in your comment, you need to press Shift+Enter in order to do that. So my question was regarding this same behaviour, but in a multilined wx.TextCtrl. Is that possible to implement?
Good morning,
Hi jmf,
you seem to me in a "rumbling" mood lately.
Yes, you are right and I should say that I have a little
bit lost my fun in programming.Now the technical discussion. The keys/chars handling in
wxWidgets has never worked properly. Even VZ on the dev-list
wrote "it is a mess". Unfortunately, this is a fact and a real
fact. There is not too much to say or to argue, it is very simple
to check that this is wrongly working.The point that it seems you are missing is the following.
The point I am not getting is what you are expecting to accomplish with the posts in this thread. I probably miss something but in my view you are bringing up problems without details on how to recreate these problems nor on possible solution and/or work around. Sorry, but I think this is not very productive.
I'm not advocating tkinter [1] or a qt derivative over wxPython
(mainly a wxWidgets problem), without counting pyGTK I never
really tested.
The point is that, because I'm perpetuously annoyed by this,
I decided a year ago to really spend some time with these
toolkits in order to check seriously the situation.And I should recognize that I did no find any issue [2]. Not
only there are working as expected, but they are working as
smoothly as another tools you can find for a Windows platorms.I dropped Visual Basic long time ago when I discovered Python.
However, I take the time to check and to wrote some VBA "macros"
with a recent version of MS Office machine, just to check
if "Windows" has changed something on this level. No problem.I'm no more writing "large" applications. I'm only maintaining
Python interactive interpreters (PySide, PyQt4 for Python 3 and
tkinter Python 3) because Python is so funny.I did not switch or ditch wxPython, just toying with
other toolkits.I perfectly understand there may be a bug in a toolkit. But
when you pressed a key and this "key" is not rendered on a
widget, it seems to me that there is a problem. If you
add to this, this is existing since 10 (ten) years and
in various different forms varying with the misc. versions
of wxWidgets (even in the same serie), I'm allowing me
to ask if there is not something wrong somewhere.jmf
[1] Python 3 helped me to finally dive in tkinter.
[2] Except a very special keys combination envolving a
Tab key. A known and reported Qt bug.
[3] File archeolgy, code in one of my old version of my
interactive interpreter:def OnKeyDown(self, event):
kc = event.GetKeyCode()
modif = event.GetModifiers()# ctrl+return seems to be used now for tab navigation (!), only
MOD_NONE istested.
if kc in [wx.WXK_RETURN, wx.WXK_NUMPAD_ENTER] and modif !=
wx.MOD_NONE:
return
IIRC ctrl+return is used for tab navigation in addition to using tab in a textctrl.
Just played with the textctrl in the wxPython demo 2.9.2.4 and I don't see any problem, i.e. all the characters I tried to enter also show up in the control, pressing enter in a single line moves to the next control, pressing enter in the multi line ones inserts a "new line" and ctrl+enter or tab move to the next control.
Looking at the RichTextCtrl and/or the StyledTextCtrl I don't see any issue either, as they are more "word processing" type controls in them the tab key actually inserts a tab but besides that again all the key strokes I pressed also showed up in the controls.
You are seeing a problem but with the information you provided I can't duplicate it.
Werner
On 10/15/2011 06:51 PM, jmfauth wrote:
On 15 oct, 16:20, werner<wbru...@free.fr> wrote: