"Paste" is wrongly disabled in some cases #11401

Yaron10 · 2022-03-16T23:20:05Z

STR:
Copy externally some file or image so that "Edit -> Paste" should be disabled.
Select some text in NPP.
Press "Ctrl+C".

Result:
"Edit -> Paste" is wrongly disabled.

Notepad++ v8.3.3 (64-bit)
Build time : Mar 15 2022 - 00:15:25
Path : C:---\notepad++.exe
Command Line :
Admin mode : ON
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 2009
OS Build : 19042.985
Current ANSI codepage : 1255
Plugins : ComparePlus.dll HTMLTag.dll MenuIcons.dll PythonScript.dll _CustomizeToolbar.dll

dfs- · 2022-03-17T08:55:33Z

Mhh, what would you expect a paste to do when a file is in the clipboard?

rimrul · 2022-03-17T10:01:17Z

Mhh, what would you expect a paste to do when a file is in the clipboard?

You missed the part where they copy text from notepad++ afterwards and paste stays disabled (until the cursor is moved).

You can in fact paste (via keyboard) in that situation, just the menu entry doesn't get updated right away.

Yaron10 · 2022-03-17T11:52:40Z

@rimrul,

Thank you for clarifying that.

dfs- · 2022-03-17T14:24:26Z

Oh, I am sorry.

Yaron10 · 2022-03-19T13:01:01Z

@Ashfaaq18,

A quick PR if you're interested. :)
Thank you.

After

notepad-plus-plus/PowerEditor/src/Notepad_plus.cpp

Line 729 in d9c5688

}

add

::AddClipboardFormatListener(hwnd);

After

notepad-plus-plus/PowerEditor/src/NppBigSwitch.cpp

Line 2814 in d9c5688

}

add

case WM_CLIPBOARDUPDATE:
{
	enableCommand(IDM_EDIT_PASTE, _pEditView->execute(SCI_CANPASTE), MENU | TOOLBAR);
	return FALSE;
}

After

notepad-plus-plus/PowerEditor/src/NppBigSwitch.cpp

Line 2131 in d9c5688

}

add

::RemoveClipboardFormatListener(hwnd);

xomx · 2022-03-19T16:01:09Z

It is weird that the N++ main wnd does not receive any notification or msg about the keyboard use in this case.

Here is also an 'one-place' solution for the ScintillaEditView.cpp:

	LRESULT lRes = _callWindowProc(_scintillaDefaultProc, hwnd, Message, wParam, lParam);

	if (Message == WM_KEYDOWN)
	{
		bool bCtrl = (::GetKeyState(VK_CONTROL) & 0x80000000) != 0;
		int iKey = static_cast<int>(wParam);
		if (bCtrl && ((iKey == 67) || (iKey == 88))) // Ctrl+C (WM_COPY) or Ctrl+X (WM_CUT)
		{
			// we need to ensure calling of the checkClipboard() in the parent after executing such messages ...
			SCNotification notification = {};
			notification.nmhdr.code = SCN_UPDATEUI;
			notification.nmhdr.hwndFrom = _hSelf;
			notification.nmhdr.idFrom = ::GetDlgCtrlID(_hSelf);
			::SendMessage(_hParent, WM_NOTIFY, 0, reinterpret_cast<LPARAM>(&notification));
		}
	}

	return lRes;
}

@Yaron10
Your solution is more universal. I did not test that, but it should work ok.

Yaron10 · 2022-03-19T20:25:05Z

@xomx,

Thank you for looking into it.

The problem also exists on copying via a plugin.

Another point which might help you pinpoint the cause:
Switching to another tab and back, the command is updated and enabled.

I did not test that, but it should work ok.

I did. :)

Yaron10 · 2022-03-19T20:40:10Z

@xomx,

Also, the user might set a different shortcut for copying.

xomx · 2022-03-19T21:10:04Z

@Yaron10

Also, the user might set a different shortcut for copying.

Ok, so then your solution is better.

I quickly checked the scite446 behavior in such situation and its main wnd receives a WM_COMMAND message, so it has not the same problem as the N++ (it also means, that it is not a problem of the included Scintilla control but a N++ one).

Switching to another tab and back, the command is updated and enabled.

Whatever issues the SCN_UPDATEUI notification fixes that (even a simple mouse-click inside the N++ main text window...)

Yaron10 · 2022-03-19T21:17:21Z

@xomx,

Switching to another tab and back, the command is updated and enabled.

Whatever issues the SCN_UPDATEUI notification fixes that

👍

I'd be glad if you could implement it as scite446 does.

Just curious: what's the WM_COMMAND message?

xomx · 2022-03-19T21:35:19Z

@Yaron10

WM_COMMAND

I think that the N++ has problem with translation of the accelerator keystrokes.

SciTe receives the Ctrl+C in its main-wnd SciTEWin::WndProc and acts accordingly:

		case WM_COMMAND:
			Command(wParam, lParam);
			break;

N++ main-wnd receives nothing, only the included Scintilla edit-control.

Yaron10 · 2022-03-19T21:47:45Z

@xomx,

I meant to ask what triggers the WM_COMMAND message on Ctrl+C.
Anyway - in NPP a plugin can also execute Copy, and this should be taken into consideration as well.

Thank you.

Yaron10 · 2022-03-19T21:53:22Z

Do you mean that since Ctrl+C is associated with Copy, a WM_COMMAND is sent but COPY_ID is NOT?

EDIT:
I assume you mean that scite446 only processes WM_COMMAND (on both Ctrl+C and Copy).

Yaron10 · 2022-03-19T23:11:34Z

@xomx,

I think that the N++ has problem with translation of the accelerator keystrokes.

👍
I think I understand it better now.
#9260 might be related.

xomx · 2022-03-20T00:59:48Z

@Yaron10

#9260 might be related.

Yes, that's it, perfect find!

That is why the relevant mouse-action (right-clicking & 'Copy') does not have this problem, because of it ends up in the N++ main wnd-proc with the WM_COMMAND, where it goes to the:

	case IDM_EDIT_COPY:
		_pEditView->execute(WM_COPY);
		checkClipboard();
		break;

Consequently it also ends up in the Scintilla wnd-proc:

	case SCI_COPY:
		Copy();
		break;

But when we press the Ctrl+C, it goes directly to that Scintilla part only.

Probably if we fix the N++ accelerator's stuff instead of fixing only this specific issue (e.g. by the patch suggested by you above), the issue 9260 will be fixed too.

Yaron10 · 2022-03-20T13:49:49Z

@xomx,

Thank you for the explanation.

On using the menu

notepad-plus-plus/PowerEditor/src/NppBigSwitch.cpp

Line 719 in d9c5688

command(LOWORD(wParam));

is called and then case IDM_EDIT_COPY:.

Is command(LOWORD(wParam)); never called on using any accelerators?

Probably if we fix the N++ accelerator's stuff instead of fixing only this specific issue (e.g. by the patch suggested by you above), the issue 9260 will be fixed too.

Great. That certainly would be better.

xomx · 2022-03-20T16:36:55Z

@Yaron10

On using the menu
...
is called and then case IDM_EDIT_COPY:.

Yes, using the N++ main menu 'Copy' is correctly interpreted as the IDM_EDIT_COPY via the WM_COMMAND. Like its mouse right-click equivalent.

Is command(LOWORD(wParam)); never called on using any accelerators?

No, I tried e.g. the Ctrl+R (reloading of the current file) and it works as it should, the command(LOWORD(wParam)) ends up here:

	case IDM_FILE_RELOAD:
		fileReload();
		break;

But keystrokes like the Ctrl+C are evidently handled differently, so these are not translated to the above IDM_EDIT_COPY.

alankilborn · 2022-03-20T16:52:03Z

But keystrokes like the Ctrl+C are evidently handled differently, so these are not translated to the above IDM_EDIT_COPY.

I did some "stuff" with this once, and had to investigate how it all works. It's HERE -- maybe there is something related of value there.

xomx · 2022-03-20T17:06:08Z

Now I see, why it behaves like described in this issue.

@alankilborn
Thanks, I will read that.

Edited: Yes, the last paragraph in that Community discussion contribution describes this unusual Ctrl+C behavior.
But the question is, why the winKeyDefs[] array from the above link has these commented out:

//	{VK_NULL,	IDM_EDIT_UNDO,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_REDO,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_CUT,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_COPY,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_PASTE,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_DELETE,	 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_SELECTALL,					false, false, false, NULL},

Even the oldest (Apr 25, 2009) history for the "./PowerEditor/src/Parameters.cpp" has the same form.

Yaron10 · 2022-03-20T18:00:03Z

@xomx,

Now I see, why it behaves like described in this issue.

👍
Very nice! Thank you.

The more I understand the issue, the more I realize how some of my previous comments/questions here were irrelevant.
I hope the following should be better. :)

So we need to move the shortcuts whose commands we want to be handled by NPP from scintKeyDefs to winKeyDefs.
Is that correct?

@alankilborn,

👍
Very interesting. Thank you.

xomx · 2022-03-20T18:30:51Z

@Yaron10
I think you simply have found a tip of the iceberg ;-)
And seeing this did not improve my confidence that we will be able to solve this.

Yaron10 · 2022-03-20T18:40:09Z

@xomx,

I think you simply have found a tip of the iceberg ;-)

I'm looking forward to the ocean. :)

And seeing #9260 (comment) did not improve my confidence that we will be able to solve this.

May I ask why?
We can either remove one shortcut or move them both to winKeyDefs.

xomx · 2022-03-20T19:04:01Z

@Yaron10

We can either remove one shortcut or move them both to winKeyDefs.

Well, there are two possibilities:

either that commenting out has a good reason (I have none N++ experience in this area, isn't it connected to the shortcuts remapping?)
or we have found one of the oldest N++ bugs around

I will uncomment (and correct) these for myself, then I will test the behavior of such binary. We will see.

Yaron10 · 2022-03-20T19:10:51Z

either that commenting out has a good reason (I have none N++ experience in this area, isn't it connected to the shortcuts remapping?)

I don't know.

I will uncomment (and correct) these for myself, then I will test the behavior of such binary. We will see.

Great. 👍
Thank you.

Yaron10 · 2022-03-27T21:10:16Z

//	{VK_NULL,	IDM_EDIT_UNDO,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_REDO,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_CUT,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_COPY,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_PASTE,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_DELETE,	 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_SELECTALL,					false, false, false, NULL},

A possible explanation for commenting those commands in winKeyDefs:

Using { VK_DELETE, IDM_EDIT_DELETE, false, false, false, nullptr }, in winKeyDefs, and commenting {TEXT("SCI_CLEAR"), SCI_CLEAR, false, false, false, VK_DELETE, IDM_EDIT_DELETE}, in scintKeyDefs would result in the "DEL" key being disabled if there's no selection. And that's, obviously, wrong.

So perhaps for some "consistency" - they were all moved to scintKeyDefs.

The "Delete" menu entry is disabled if there's no selection in most editors and also in Windows Edit-Controls.
I don't understand why.

EDIT:
In Visual Studio the "Delete" menu entry is enabled even if there's no selection.

I also don't understand why checkClipboard(); is called in:

case IDM_EDIT_UNDO:
case IDM_EDIT_REDO:
case IDM_EDIT_CUT:
case IDM_EDIT_SELECTALL:

xomx · 2022-03-27T21:56:42Z

@Yaron10

I have not forgotten about this issue, I just do not have enough spare time.

My patched version of N++ is working ok, until now I did not register any problem. So I still does not understand, why these shortcuts have to be disabled in the winKeyDefs and enabled in the scintKeyDefs.

The winKeyDefs has appeared in the N++ v4.8.1 (2008!), up to the v4.7.5 there was only this:

void NppParameters::initScintillaKeys()
{
	// Cut/Copy/Paste
	_scintillaKeyCommands.push_back(ScintillaKeyMap("CUT", IDSCINTILLA_KEY_CUT, SCI_CUT, true, false, false, 0x58/*VK_X*/, IDM_EDIT_CUT));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("COPY", IDSCINTILLA_KEY_COPY, SCI_COPY, true, false, false, 0x43/*VK_C*/, IDM_EDIT_COPY));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("PASTE", IDSCINTILLA_KEY_PASTE, SCI_PASTE, true, false, false, 0x56/*VK_V*/, IDM_EDIT_PASTE));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("DEL", IDSCINTILLA_KEY_DEL, SCI_CLEAR, false, false, false, VK_DELETE, IDM_EDIT_DELETE));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("SELECT ALL", IDSCINTILLA_KEY_SELECTALL, SCI_SELECTALL, true, false, false, 0x41/*VK_A*/, IDM_EDIT_SELECTALL));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("OUTDENT", IDSCINTILLA_KEY_OUTDENT, SCI_BACKTAB, false, false, true, VK_TAB, IDM_EDIT_RMV_TAB));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("UNDO", IDSCINTILLA_KEY_UNDO, SCI_UNDO, true, false, false, 0x5A/*VK_Z*/, IDM_EDIT_UNDO));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("REDO", IDSCINTILLA_KEY_REDO, SCI_REDO, true, false, false, 0x59/*VK_Y*/, IDM_EDIT_REDO));

	// Line operation
	_scintillaKeyCommands.push_back(ScintillaKeyMap("DUPLICATE LINE", IDSCINTILLA_KEY_LINE_DUP, SCI_LINEDUPLICATE, true, false, false, 0x44/*VK_D*/, IDM_EDIT_DUP_LINE));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("CUT LINE", IDSCINTILLA_KEY_LINE_CUT, SCI_LINECUT, true, false, false, 0x4C/*VK_L*/));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("DELETE LINE", IDSCINTILLA_KEY_LINE_DEL, SCI_LINEDELETE, true, false, true, 0x4C/*VK_L*/));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("TRANSPOSE LINE", IDSCINTILLA_KEY_LINE_TRANS, SCI_LINETRANSPOSE, true, false, false, 0x54/*VK_T*/));
	_scintillaKeyCommands.push_back(ScintillaKeyMap("COPY LINE", IDSCINTILLA_KEY_LINE_COPY, SCI_LINECOPY, true, false, true, 0x54/*VK_T*/));
	//SCI_DELETEBACK
	//SCI_DELETEBACKNOTLINE
	
	//SCI_DELWORDLEFT
	//SCI_DELWORDRIGHT
	//SCI_DELLINELEFT
	//SCI_DELLINERIGHT
}

Maybe this was the historical reason, why these have remained under the scintKeyDefs jurisdiction...

Yaron10 · 2022-03-27T22:08:36Z

@xomx,

Thank you for replying. I appreciate it.
I didn't mean to "ping" you. :)

My patched version of N++ is working ok

Do you mean you have added { VK_DELETE, IDM_EDIT_DELETE, false, false, false, nullptr }, in winKeyDefs and removed {TEXT("SCI_CLEAR"), SCI_CLEAR, false, false, false, VK_DELETE, IDM_EDIT_DELETE}, in scintKeyDefs?

xomx · 2022-03-27T23:21:48Z

@Yaron10
Edited: So far I did tests only with the WM_COPY, WM_CUT and WM_PASTE. I will try also the others, WM_DELETE included.

Yaron10 · 2022-03-27T23:31:02Z

@xomx,

Thank you. Whenever you have free time.

xomx · 2022-04-04T16:43:20Z

@Yaron10

Using { VK_DELETE, IDM_EDIT_DELETE, false, false, false, nullptr }, in winKeyDefs, and commenting {TEXT("SCI_CLEAR"), SCI_CLEAR, false, false, false, VK_DELETE, IDM_EDIT_DELETE}, in scintKeyDefs would result in the "DEL" key being disabled if there's no selection. And that's, obviously, wrong.

I can confirm that behavior.

The "Delete" menu entry is disabled if there's no selection in most editors and also in Windows Edit-Controls.
I don't understand why.

The problem is, how the TranslateMessage WINAPI handles some special keyboard input, namely the DELETE one. Usually the TranslateMessage converts key strokes WM_KEYDOWN messages into characters (WM_CHAR messages later...). Even some CTRL+key combinations are translated into ASCII control characters, e.g. Ctrl+C is then 0x03 (ASCII ETX) or Ctrl+V is then 0x16 (ASCII SYN). And such special WM_CHARS are then translated to the WM_COPY/WM_PASTE by the WM_CHAR DefWindowProc() later. But there does not exist such ASCII code for the DELETE key (BACKSPACE is ok, it is 0x08 aka the ASCII BS). So in N++ one has to either handle the WM_KEYDOWN/VK_DELETE manually or leave this tedious job to the Scintilla.

The current N++ implementation is lazy - the DELETE key handling is left to the underlying Scintilla, so it works even without selecting a text. But it means, that the main menu Edit->'Delete' cannot be used at all in this situation, so it is grayed. Quite inconsistent.

I successfully tested these moves (scintKeyDefs -> winKeyDefs):

Ctrl+C (copy)
Ctrl+V (paste)
Ctrl+X (cut)
Ctrl+A (select all)
Ctrl+Z (undo)
Ctrl+Y (redo)

I think that all of these should be in the winKeyDefs.

Yaron10 · 2022-04-04T17:37:23Z

@xomx,

Thank you for the explanation. 👍

The current N++ implementation is lazy
...
Quite inconsistent.

I agree it's inconsistent.
But this is the behavior in most editors (e.g. MS Notepad) and also in Windows Edit-Controls.

I think that all of these should be in the winKeyDefs.

I think so too.
But we'd have to remove enableCommand(IDM_EDIT_DELETE, hasSelection, MENU | TOOLBAR); from void Notepad_plus::checkClipboard(), correct?

OFF-TOPIC:

I've built the new source files (121a396) with Visual Studio 2017 (I've changed the Toolset to v141).

It's built successfully, but I get the following warnings:

lexilla\lexlib\stylecontext.cxx(57): warning C4505: 'getRange': 
unreferenced local function has been removed

LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
PowerEditor\visual.net\Release\libLexilla.lib

Should I change anything for the second warning when building x64?
Do you get it too?

I'd appreciate your help.

Yaron10 · 2022-04-05T07:35:16Z

@xomx,

I think that all of these should be in the winKeyDefs.

I think so too.
But we'd have to remove enableCommand(IDM_EDIT_DELETE, hasSelection, MENU | TOOLBAR); from void Notepad_plus::checkClipboard(), correct?

I misread your list.
Don't you think it should be better to move IDM_EDIT_DELETE too, and enable it even if there's no selection?

xomx · 2022-04-05T09:03:30Z

@Yaron10

Tried the same with the MSVS2017 and the current master just now:

I have got the same warning as you about the 'getRange'
but no such LINK : warning LNK4068 about the MACHINE

You can check your libLexilla MACHINE setting:

select the 'Lexilla' subproject in the MSVS Solution Explorer wnd
rightclick on it, click on the 'Properties' in the popup menu
check the 'Configuration Properties' -> 'Librarian' -> 'General' -> 'Target Machine', it should say "MachineX64 (/MACHINE:X64)"

Don't you think it should be better to move IDM_EDIT_DELETE too, and enable it even if there's no selection?

I intentionally did not move the IDM_EDIT_DELETE to winKeyDefs because of then I have to code the whole 'Delete' keystrokes handler myself, i.e. something like that in the ".\notepad-plus-plus-master\PowerEditor\src\NppBigSwitch.cpp":

case WM_KEYDOWN: 
            switch (wParam) 
            { 
                  case VK_DELETE: 
                      // process the 'Delete' key...
                      break; 
                
                  // process other non-character keystrokes
                  default: 
                      break; 
            }

This is what Scintilla does for us in such case:

".\notepad-plus-plus-master\scintilla\src\Editor.cxx" -> Editor::WndProc()

	case Message::Clear:
		Clear();
		SetLastXChosen();
		EnsureCaretVisible();
		break;

and I do not want to replicate these calls functionality myself, maybe you have more time for that?

rdipardo · 2022-04-05T09:17:52Z

You can check your libLexilla MACHINE setting:

select the 'Lexilla' subproject in the MSVS Solution Explorer wnd

rightclick on it, click on the 'Properties' in the popup menu

check the 'Configuration Properties' -> 'Librarian' -> 'General' -> 'Target Machine', it should say "MachineX64 (/MACHINE:X64)"

Or make sure the "Platform" configuration is explicitly "x64".
For example, I don't get a linker warning (only the C4505 compiler warning) when I do this:

> cd PowerEditor\visual.net
> msbuild /v:m /t:Lexilla /p:PlatformToolset=v141;Platform=x64;WindowsTargetPlatformVersion=%WindowsSDKVersion:~0,-1%

You can safely ignore the linker warning in any case. Both Lexilla and Scintilla are built as static libraries, which end up in the same EXE as the application code. The /MACHINE option does nothing since nothing is exported: the address of each function doesn't need locating, so the size of a pointer on the target "machine" doesn't matter.

Yaron10 · 2022-04-05T09:47:30Z

@xomx & @rdipardo,

Thank you both for the helpful replies. I appreciate it.

I have got the same warning as you about the 'getRange'

(only the C4505 compiler warning)

So this warning is not related to VS 2017 and it's generated when using VS 2019 without modifying anything. Is that correct?

it should say "MachineX64 (/MACHINE:X64)"

Or make sure the "Platform" configuration is explicitly "x64".

If I don't ignore it, should I manually change it when switching between x32 and x64?

I intentionally did not move the IDM_EDIT_DELETE to winKeyDefs because of then I have to code the whole 'Delete' keystrokes handler myself,

I don't quite understand it.

		case IDM_EDIT_DELETE:
			_pEditView->execute(WM_CLEAR);
			break;

Shouldn't the Delete keystrokes be processed by case Message::Clear:?

rdipardo · 2022-04-05T11:31:23Z

@Yaron10,

I have got the same warning as you about the 'getRange'

(only the C4505 compiler warning)

So this warning is not related to VS 2017 and it's generated when using VS 2019 without modifying anything. Is that correct?

Correct; it's emitted even if I pass /p:PlatformToolSet=v142 to msbuild.

From what I can tell, ::getRange was (re-)added by Notepad++ (probably for backward compatibility), against upstream's decision to move it into the LexAccessor namespace. Stripping it out may break application code, so an issue should be opened; possible remediations could be:

circumventing whatever optimization is removing it
refactoring the code that expects ::getRange to use LexAccessor::GetRange instead

it should say "MachineX64 (/MACHINE:X64)"

Or make sure the "Platform" configuration is explicitly "x64".

If I don't ignore it, should I manually change it when switching between x32 and x64?

It won't hurt; but again, as long as the compiler is generating object code for the right platform, the "librarian" should not need any hint about what to do with static libraries (i.e., nothing at all).

Yaron10 · 2022-04-05T11:55:27Z

@rdipardo,

Thanks again for the detailed explanation. Much appreciated.
I don't have VS installed on the PC I'm using now. If I encounter any problem with the "librarian", I'll allow myself to contact you again. :)

so an issue should be opened;

Would you mind doing that?

rdipardo · 2022-04-05T17:53:50Z

so an issue should be opened;

Would you mind doing that?

#11477

Yaron10 · 2022-04-05T19:29:33Z

@rdipardo,

Thank you.
Well explained. 👍

Yaron10 · 2022-07-08T11:49:18Z

//	{VK_NULL,	IDM_EDIT_UNDO,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_REDO,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_CUT,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_COPY,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_PASTE,		 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_DELETE,	 				false, false, false, NULL},
//	{VK_NULL,	IDM_EDIT_SELECTALL,					false, false, false, NULL},

Those shortcuts are commented in winKeyDefs and added instead to scintKeyDefs so that they should work in the non-main-editing windows.

For example:
Pressing Delete in the Search Results window, the current line in that window is deleted.
If the shortcuts were in winKeyDefs, a character in the main-editor would be deleted.

xomx · 2022-07-09T08:32:03Z

@Yaron10
Nice find, I will try that myself tomorrow.

Yaron10 · 2022-07-09T11:52:14Z

@xomx,

👍
Thank you.

xomx · 2022-07-10T19:39:51Z

@Yaron10

I tried - you are right, we cannot simply move the Ctrl+C, Ctr+V... to the winKeyDefs.

rdipardo mentioned this issue Apr 5, 2022

Dead code in StyleContext.cxx raising MSVC compiler warning #11477

Closed

Yaron10 mentioned this issue Nov 28, 2023

Fix visual glichy on multi-paste and make shortcut commands more coherent #14422

Closed

xomx mentioned this issue Nov 28, 2023

line operation (delete, copy & cut) problem #14401

Closed

donho mentioned this issue Nov 29, 2023

Fix visual glichy on multi-paste and make shortcut commands more coherent #14423

Closed

"Paste" is wrongly disabled in some cases #11401

"Paste" is wrongly disabled in some cases #11401

Comments

Yaron10 commented Mar 16, 2022

dfs- commented Mar 17, 2022

rimrul commented Mar 17, 2022

Yaron10 commented Mar 17, 2022

dfs- commented Mar 17, 2022

Yaron10 commented Mar 19, 2022

xomx commented Mar 19, 2022

Yaron10 commented Mar 19, 2022

Yaron10 commented Mar 19, 2022

xomx commented Mar 19, 2022 • edited

Yaron10 commented Mar 19, 2022 • edited

xomx commented Mar 19, 2022 • edited

Yaron10 commented Mar 19, 2022 • edited

Yaron10 commented Mar 19, 2022 • edited

Yaron10 commented Mar 19, 2022

xomx commented Mar 20, 2022 • edited

Yaron10 commented Mar 20, 2022

xomx commented Mar 20, 2022

alankilborn commented Mar 20, 2022

xomx commented Mar 20, 2022 • edited

Yaron10 commented Mar 20, 2022

xomx commented Mar 20, 2022

Yaron10 commented Mar 20, 2022

xomx commented Mar 20, 2022

Yaron10 commented Mar 20, 2022

Yaron10 commented Mar 27, 2022 • edited

xomx commented Mar 27, 2022

Yaron10 commented Mar 27, 2022

xomx commented Mar 27, 2022 • edited

Yaron10 commented Mar 27, 2022

xomx commented Apr 4, 2022

Yaron10 commented Apr 4, 2022

Yaron10 commented Apr 5, 2022

xomx commented Apr 5, 2022

rdipardo commented Apr 5, 2022

Yaron10 commented Apr 5, 2022

rdipardo commented Apr 5, 2022 • edited

Yaron10 commented Apr 5, 2022

rdipardo commented Apr 5, 2022

Yaron10 commented Apr 5, 2022

Yaron10 commented Jul 8, 2022

xomx commented Jul 9, 2022

Yaron10 commented Jul 9, 2022

xomx commented Jul 10, 2022

xomx commented Mar 19, 2022 •

edited

Yaron10 commented Mar 19, 2022 •

edited

xomx commented Mar 19, 2022 •

edited

Yaron10 commented Mar 19, 2022 •

edited

Yaron10 commented Mar 19, 2022 •

edited

xomx commented Mar 20, 2022 •

edited

xomx commented Mar 20, 2022 •

edited

Yaron10 commented Mar 27, 2022 •

edited

xomx commented Mar 27, 2022 •

edited

rdipardo commented Apr 5, 2022 •

edited