There are issues with users changing the behaviour of the enter, tab, or arrow keys.
(Potentially a wxPython specific bug with tab).
Now, there are a few options:
1. If any reserved keys are encountered, return their keyvalue, and check the returned keyvalue instead of the event keyvalue. This would allow a disconnect between keys and their behaviour for things like indentation.
2. Simply do not allow users to override these keys.
3. (Current) Politely warn users that things may not behave as expected if they edit these keys.
It seems like either 1 or 2 would be ideal. The question is, is there a use for editing the tab key to do something other than tab?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>I have added to the docs that you should not mess with
>Enter, Tab, or the Arrow keys. My reasoning being that
>these are used in the document, ...
The reason, I have a tab script is, that I don't like the
tab behaviour in the core.
I think, a easy solution should be enought.
I cannot imagine to overwrite the enter or arrow keys with a function.
This would really make no sense.
>I suppose I could put in some extra code to return a special
>value if enter, or tab, or the arrow keys are encountered
>(like the key value).... Perhaps I should do this?
If this is possible for the tab key, this would be great.
BTW: there is another bug (in the help forum with the enter key)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason for Mytab is
you have a selection: tab => clears the text: annoying.
If you like this we could integrate this into the core, no need of my tab.
Also rectangular selection: => it inserts one space:
There are issues with users changing the behaviour of the enter, tab, or arrow keys.
(Potentially a wxPython specific bug with tab).
Now, there are a few options:
1. If any reserved keys are encountered, return their keyvalue, and check the returned keyvalue instead of the event keyvalue. This would allow a disconnect between keys and their behaviour for things like indentation.
2. Simply do not allow users to override these keys.
3. (Current) Politely warn users that things may not behave as expected if they edit these keys.
It seems like either 1 or 2 would be ideal. The question is, is there a use for editing the tab key to do something other than tab?
>I have added to the docs that you should not mess with
>Enter, Tab, or the Arrow keys. My reasoning being that
>these are used in the document, ...
The reason, I have a tab script is, that I don't like the
tab behaviour in the core.
I think, a easy solution should be enought.
I cannot imagine to overwrite the enter or arrow keys with a function.
This would really make no sense.
>I suppose I could put in some extra code to return a special
>value if enter, or tab, or the arrow keys are encountered
>(like the key value).... Perhaps I should do this?
If this is possible for the tab key, this would be great.
BTW: there is another bug (in the help forum with the enter key)
The reason for Mytab is
you have a selection: tab => clears the text: annoying.
If you like this we could integrate this into the core, no need of my tab.
Also rectangular selection: => it inserts one space:
MyTab.py on:
http://mitglied.lycos.de/drpython/
I've done it.
Basically, RunShortcuts now returns the stc command (if applicable), which is used in drprompt and drtext.
This should make things work if the users decides to make the enter key, tab, and the tab key mean 'left', etc.