SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: Peter Steinberg on April 10, 2020, 06:47:36 PM
-
SlickEdit Pro 2019 (v24.0.2.0 64-bit), 64-bit Windows 10.
The enter key on the numeric keypad normally works like the regular enter key.
After editing for a while suddenly I start getting the "Key not defined" message when I press the numeric keypad enter key.
The numeric keypad enter key also stops working in dialogs (find, etc.), the command line, etc.
This started happening when (or shortly after) I upgraded from 24.0.1 to 24.0.2
Any idea on how to fix this?
-
Hot fix checked in for this. I found two mistakes which would cause this (dynamic surround and the block_insert_mode command). You're probably hitting the dynamic surround case a lot.
Simple explanation. For convenience and backward compatibility, SlickEdit (by default) automatically converts KeyPad keys like Enter to their equivalent non KeyPad key variant if there is no binding for the keypad variant. This allows SlickEdit not to have specific bindings for KeyPad specific keys yet they still work. Also, users can can make a keypad key binding if they want the keypad key to do something different (some users really want this capability). However, there are cases where this auto keypad mapping feature has to be temporarily turned off. This is where some mistakes were made.
Thanks for posting about this.
-
Thanks for the quick reply; any idea on when the hotfix will be available?
-
PM sent!
-
Thanks, that looks like it has fixed the issue.
-
Any idea when this fix might be available? Since this is the Enter key that I always use, it is very annoying.
-
PM sent.
The hotfix will be published shortly at www.slickedit.com/hotfix
Regards,
SlickEdit Support
-
Was this in hotfix 5? Prior to applying that I had this issue and it's a right pain. I applied hotfix 5 and the pad enter splits the line (although maybe it won't soon!) but it doesn't auto-indent like the real enter key does.
If the hotfix didn't have this fix in it, could I have a PM too, please? I seem to use the pad enter more than the proper one.
-
I'm not able to reproduce this difference where one Enter key indents and the other doesn't. What is the language type of the file you are editing. I only tested C++ so far.
-
It is C/C++. Checking keybinding, pad enter is bound to split_insert_line(), just like enter.
Perhaps I need to be more specific. Given this code:
if (something) {
}
with the cursor at the end of the first line, pad enter inserts a blank link and puts the cursor under the if:
if (something) {
|
}So that's indenting to the start of the if statement. But enter indents to the beautifier depth, which in this case in a further indent:
if (something) {
|
}
I and use both keys in that if() and the indents are consistent and 100% reproducible.
Edit: 24.1 is fine.
-
Dunno why I didn't spot this before: the main enter key is bound to TONS of stuff, just one of which is split_insert_line(). Taking a punt I bound pad enter to c-enter and now it works as it should (in C files).
But shouldn't it be bound to all the functions that the big enter is bound to? If so, how come it isn't, and is there a quick (and simple) way to make it so?
-
If you bind your Pad Enter key, then it can function differently. Otherwise, SlickEdit is supposed to automatically map it onto your regular Enter key binding.
You might want to try a default config. Maybe you bound the Pad Enter key accidentally.
-
I don't bind keys, so no chance of that. I just installed 24.2 and let it copy my config from 24.1, which still works as it should. Definitely a 24.2 problems, whether it lost something or didn't copy something.
OK, I just unbound pad enter from everything and now it's back to the original issue: inserts a line and only indents as far as the 'if' in my example above. Or the start column of the previous line. That is, it's ignoring the beautifier settings. Enter works as expected.
-
Please post your user.cfg.xml. I'll remove any bindings you have for Pad Enter and see if I can reproduce this problem.
-
I'd prefer not to post that here since it has client identifiers in it. I tried to send a URL to you where you can download it, but apparently you don't accept PMs (or, at least, not from me). Any other way I can get this to you?
-
Uploaded to support@slickedit :)
-
Something has gone very wrong, I think. I closed SE and had lunch then came back and now the enter key is acting the same way: not indenting to the beautifier setting. I've changed nothing (that I'm aware of) but now I see that in all the binds that enter has, c-enter is missing.
-
The user.cfg.xml you posted works for me. There are no key bindings modifications for Enter or Pad Enter.
Enter and Pad Enter indent as expected in C++.
Did you define any beautifier profile overrides which could override the SHG Beautifier profile. For me, the SHG Beautifier profile is being used.
You could try turning of Beautify while typing just to see if that has anything to do with this issue.
Make sure hot fix 5 is loaded: Help>Product Updates> List Installed Fixes
-
I'm not aware of adding any beautifier override, but it's been a loooong time since I felt the need to play with it.
Since posting the previous comment I added c-enter to bother enter and pad enter so I could continue. Just now I exported the key config from 24.1 and imported to 24.2, and everything is as it should be. Looking at bindings, enter produces a massive list and pad enter nothing at all, so I guess it's fixed (at the expense of losing Kotlin, I think).
So then I imported the 24.2 config and it was back to how it was. Perhaps significantly, if I list pad enter bindings I got c-enter (expected) but also an entry of c-enter for the enter key too. Should that happen? I would have though only pad enter bindings would show and no enter key bindings.
I'll try changing the beautifier setting later (currently a bit rushed to get some stuff done), but using the 24.1 config would seem to be a solution meantime.
-
By default, PadEnter has no binding. When PadEnter has no binding, SlickEdit automatically converts it to Enter.
The c-enter command is used for many c-like languages.
-
The thought just occured to me that if I had the original problem with pad enter (that hotfix 5 solved) I might have added the split-insert-line binding to fix it (not realising it should be c-enter). Then later if I removed the binding would it then not have any binding (the logicial result) or default to being the same as enter because it has no binding (not quite so logical because then one couldn't unbind it from everything).
So with that in mind I just reverted to the 24.2 config then unbound pad enter from c-enter, leaving no binding for it. Restart SE and pad enter works as it should (not as expected or its previous incorrect behaviour). Hmmm. Unbound enter from specific c-enter too and enter still works as it should.
Maybe this was the configuration equivalent of water in the gas, and it's now flushed through. Whatever, seems to be working properly now! Thanks for your patience :)
-
Found the cause. Well, a way to make it happen but no idea why it happens.
When you do 'if (...' you get a red box which encloses the dependancies of the if. You can use cursor up/down to enclose or release whatever additional lines you want. Pretty cool :). However, after doing that the pad enter key is dead.
I am suspicious that there is something external to SE that is causing this since it's natural for me to use the num pad cursor keys and then hit pad enter (although this occurs even if pad enter isn't used) - it is so common for me that I think I should have noticed before now. The strange thing is it's only happened since upgrading to 24.2, but now I know how to force it I can make it happen in 24.1 too.
Once it occurs the numpad is borked until a restart, but after a restart it is fine again. That would explain why all the dicking around I posted about earlier would have different results, depending on whether SE had been restarted or not.
-
Found the cause. Well, a way to make it happen but no idea why it happens.
When you do 'if (...' you get a red box which encloses the dependancies of the if. You can use cursor up/down to enclose or release whatever additional lines you want. Pretty cool :). However, after doing that the pad enter key is dead.
This is the problem that this hot fix will fix. Load the hot fix. Some how it has been removed.
-
I'll do that. Is it possible to kind of uninstall a hotfix beforehand, or should just doing it again resolve that?
Also... this is 24.1 so the current hotfix 5 isn't applicable. Is there a 24.1 version of it or am I sool on that?
Edit: for clarity, I don't want to use 24.2 unless/until the windows/buffer thing is sorted out, hence why I am back on 24.1. I've got 24.1 hotfix 5 loaded, and reloaded, but that doesn't fix the issue. In fact, since that was loaded only recently, could it have caused this issue on 24.1?
-
There isn't a fix for this for 24.0.1.
You can load the 24.0.2 hot fix multiple times. If you didn't change config directories or delete your local state files, I'd sure like to know how it got unloaded.
-
Hmmm. Well 24.1 had a hotfix 5 applied. So I restored from backup from the 6th (the hotfix is dated 7th) and 24.1 is fine. There is no issue with pad enter at all. Whatever was in that hotfix caused the problem.
-
I tried to load the 24.0.2 hot fix 5 into 24.0.1 (by accident) and it wouldn't let me.
-
The 24.2 hotfix 5 won't load in 24.1, no. But this hotfix is for 24.1, hence why it does. It is 17.5MB whereas 24.2 hotfix 5 is 19.1MB.
I note that the hotfix info in the forum was vaped on the 7th, so maybe the download was 'cleaned up' at the same time.