Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I'm checking out Dr. Python, and it took me a minute to figure out that the reason my programs where crashing was that the enter buttons are treated differently.
Windows XP, Python 2.4.0, wxPython 188.8.131.52, Dr Python 3.8.5.
In IDLE, and the when ran on their own, the treat both enters fine. But in Dr. Python the numeric keypad enter key is treated only as a line feed, and not as an end of line.
I can't see any options in Dr. Python, and my google didn't turn up anything that might help as a work around. Is this intentional? A bug? Is there a work around?
I see. strange.
If you have "WIN" or "UNIX"line endings, it inserts a CR only on numpad enter.
This is rather funny. In SciTE, this is not the case.
I have tried it in SPE, the same behaviour.
Maybe an stc bug? both keycodes are 13 dec.
So I patched wxPython Demo to set ViewLineEndings.
Also the same.
I will post this into the wxpyhton-user-mailing list.
This is a known issue in wxPython.
Fix checked in. Thanks.
for the time being, hm don't know a solution.
Catch the enter key (no event.Skip() and process it extra? for a workaround)
I have a workaround:
put in OnKeyDown in drText, or if you have KeyBoardMacros installed, into KeyboardMacros.py:
-> means one tab.
def OnKeyDown(self, event):
->keycode = event.GetKeyCode()
->if (not self.grandparent.RunShortcuts(event, self)):
->->if (keycode == wx.WXK_RETURN or keycode == wx.WXK_NUMPAD_ENTER) and (self.grandparent.prefs.docautoindent):
->->->self.needtoindent = 1
->->if (keycode == wx.WXK_NUMPAD_ENTER):
in the last line, one '->' (tab) was missing
This seems to ignore any input.
Let me see if I get this right: I'm supposed to open DrText.py in the DrPython program directory, scrool down to the function OnKeyDown and replace that function, with the function you provided, replacing all ->'s with tabs, and adding one more tab to that last line, right?
Now the IDE does not accept any input what so ever. However, I've added one more indent infront of all of them, because the original function was indented one level as well.
this issue is getting more and more entangled.
First: this fix, I meant for the version (22.02.2005), and
it doesn't work anymore, because in drText something has changed.
Second, I wondered, why on my pc, the numpad enter
key inserts currently, what I expected (right UNIX and right
WIN line endings).
I downloaded the new wxPython 184.108.40.206 pre release and
this bug is fixed. I double checked it with 220.127.116.11 again.
So if you download:
it should work (at least on my win-xp Python 2.4).
The autoindent indeed isn't working,
I'm sure, Dan will include (a modified) version into the core, when he will have time again.
(I use -> for tabs, because after posting, all tab disappear)
no need to update wxPython, because I have tested
it and (should) work with 18.104.22.168 and 22.214.171.124.
I will post this also to DrPython-Patches.
->def OnKeyDown(self, event):
->->#catch numpad_enter before, because wx.WXK_NUMPAD_ENTER isn't processed properly
->->if event.GetKeyCode() == wx.stc.wx.WXK_NUMPAD_ENTER:
->->->result = wx.stc.wx.WXK_NUMPAD_ENTER
->->->result = self.grandparent.RunShortcuts(event, self, self.DisableShortcuts)
->->if result > -1:
->->->if (result == wx.stc.STC_CMD_NEWLINE or result == wx.stc.wx.WXK_NUMPAD_ENTER) and (self.grandparent.prefs.docautoindent):
->->->if result == wx.stc.STC_CMD_TAB:
Ahoy, sorry for weighing in on this so late:
The numberpad has different keycodes. (Apparently this is fixed for the next version of wxPython?).
I think manually binding the key would not be the best solution, as that prohibits people from assigning that enter key to a different function.
So, when I am settled in, one consideration is allowing multiple keys for each function. This would be pretty easy to implement (the only real work would be in the dialog, and in loading/saving files). (Of course, I could be wrong, and this may be a mess not worth doing. If this is the case, I can go the manual route as an option in preferences).
Turns there was a different solution from out the patch (which manually bound the key):
Simply treat numpad enter as enter in RunShortcuts.
So anything bound to enter would apply to numpad enter.