I had no doubts about the Alan software.
But you answered well, and above all targeted my problem well.
This was not directly related to version 8.6.1.
But Sante doubts its update.
After investigation, I resolved the issue.
The software settings had been changed.
In particular FTP instead of SFTP, as well as port 21 instead of 22.
So everything is much better now.
Thank you for your answer.

Merci aussi mkupper

Please provide more detail to help others reproduce works and what does not work

And remember, only critical issues for the 8.6.1 release should be reported in this thread. I guarantee that @Sealex83 's problem is NOT related to 8.6.1, despite the fact that he is convinced this is so. Non-critical 8.6.1 issues are best reported by creating a new issue on github; see this site’s FAQ for detail.

There seems to be a weird bug where you can’t use Ctrl+V to paste text into the text fields of forms for certain plugins. Right-clicking and selecting “Paste” from the drop-down menu still works

Fixed in:
https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14569

@Mark-Olson said in Notepad++ v8.6.1 Release:

Does the following link solve your problem?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14557

No.

Thank you for your feedback.

This is probably obvious, but in case it isn’t:

Removing the Ctrl+X/C/V shortcuts from their Edit commands does restore their function in JsonTools. When disableLineCopyCutDelete.xml has been added, Ctrl+X/C/V can be added to the corresponding Scintilla commands (thus restoring their function in the main editor) without impairing their function in JsonTools.

The underlying problem is that mapped shortcuts other than Scintilla commands are sent to Notepad++ when used in a non-modal dialog that doesn’t register with NPPM_MODELESSDIALOG. Apparently many plugins never did this, because the most commonly used shortcuts were Scintilla commands. Moving three very common shortcuts from Scintilla commands to Notepad++ accelerators changes that.

I don’t think there is a non-hacky solution that both allows for Cut/Copy/Paste to have functions not supported directly by Scintilla commands and doesn’t disrupt plugins that have (probably unknowingly) relied on this “loophole” in keystroke processing.

The simplest and least hacky solution is probably some form of the one @rdipardo suggests on GitHub, which amounts to forwarding WM_CUT/COPY/PASTE when it can be detected that IDM_CUT/COPY/PASTE has been called for a message to a window that isn’t an editor window.

Does the following link solve your problem?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14557

No.

I added an empty file named disableLineCopyCutDelete.xml to my %Appdata%/Notepad++ directory as instructed in your post.
I then rebuilt JsonTools with the code that fixed the issue commented out, to isolate whether your proposed fix had any effect.
Ctrl+V still did not work in any of my forms, dockable or otherwise.

Thank you for your feedback.
Could you create an issue on GitHub if it’s not been created yet?

@PeterJones said in Notepad++ v8.6.1 Release:

Making everyone who uses plugin dialogs or docked windows put in a zero byte config file to undo the recent problematic new feature seems the wrong way around to me.

As much as the magic copy/cut/delete is a cool way to imitate VS, is the cool new feature really worth the problems it has caused in v8.6 and v8.6.1?

No, it isn’t indeed.
I will see what I can do about it.

    Fix a regression: the position in the previous session is now restored correctly in cloned document. (Fix [#14164])

Unfortunately this seems to be still not fixed for me in 8.6.1.

Indeed.
Fixed in PR https://github.com/notepad-plus-plus/notepad-plus-plus/pull/14565
The fix will be included in the next release.

donho said:

2. Fix a regression: the position in the previous session is now restored correctly in cloned document. (Fix [#14164])

Unfortunately this seems to be still not fixed for me in 8.6.1.

Can the existing Issue be re-opened or do I have to create a new one?

The only other real-life problem I’ve seen described is that a couple people using AutoHotKey depended on clearing the clipboard, then sending Ctrl+c to Notepad++ and checking for an empty clipboard to determine whether anything is selected. I don’t use AutoHotKey, but I found what appears to be a more reliable way to test for an empty selection. I don’t know if anyone has tried it.

It works fine:

SendMessage, 2650,,, Scintilla2, ahk_class Notepad++ ; SCI_GETSELECTIONEMPTY
msgbox % "empty = " ErrorLevel

It’s also cleaner for the Autohotkey coder because it avoids wiping out the current clipboard and a subsequent restore if needed.

That’s only a part of the picture.

Despite some of what I’ve written… I agree with you. Breaking plugins is never good; it alienates users and plugin authors.

As I just recently suggested, a sensible compromise would be to use Scintilla functions for this. That would mean losing cut-without-selection. Copy and copy-whole-line-when-nothing-is-selected would be available, and paste would take care of itself. Whichever is the default for copy, users could use the Scintilla commands tab of the Shortcut mapper dialog to change to the other one.

Because Scintilla shortcuts are translated by Scintilla, and not by the message loop, the behavior of plugins would return to the pre-8.6.1 status quo.

The only other real-life problem I’ve seen described is that a couple people using AutoHotKey depended on clearing the clipboard, then sending Ctrl+c to Notepad++ and checking for an empty clipboard to determine whether anything is selected. I don’t use AutoHotKey, but I found what appears to be a more reliable way to test for an empty selection. I don’t know if anyone has tried it.

There is still, perhaps, a question which function should be Copy on the Edit menu — SCI_COPY or SCI_COPYALLOWLINE — but it doesn’t seem like the overall impact could be that big… if we could give up the non-Scintilla “CUTALLOWLINE” function, thus letting everything else be handled by Scintilla.

in this case I think it’s more like “making plugin authors code their plugins correctly.”

That’s only a part of the picture. If the final solution from Notepad++ is that “plugins must be edited”, these three things are true, none of which are pleasant to have true:

1. Notepad++ communicates to users that their use of and desire for plugins is unimportant, and that they either need to stop using any problematic plugin until they’ve been updated (and then re-submitted to the plugins admin and included in some random future release), or they need to turn off auto-update checks and stay with an older version of Notepad++ so that they can use the plugins they have grown accustomed to – and either way, the users’ opinions of Notepad++ and its ecosystem are soured, possibly to the point of stopping using Notepad++.

2. Notepad++ communicates to plugin developers that it doesn’t care about plugin developers, and is willing to implement breaking changes in the behavioral contract (explicit and implied) between Notepad++ and plugins (which includes but is not limited to the API) without any notice, and is willing to sour people’s opinions of a given plugin because Notepad++ makes a change which unexpectedly breaks plugins, and then lays the blame on the plugin developer for not being able to foresee the design decisions that they made given that it worked under the current version, years of existing behavior giving weight to the conclusion that their decisions were reasonable and correct. This could quite easily chase away plugin developers who decide that they don’t want to spend their time supporting and developing plugins when they cannot guess when a potentially-breaking change might be made.

3. It ignores the other issues involved in the new magic copy/cut, including the fact that the implementation decisions made for v8.6 necessitated the zero-byte config file disableLineCopyCutDelete.xml be added to v8.6.1 in order for people to turn off behavior which did not meet reasonable user expectation.

So yes, plugin authors should definitely fix their plugins now that they know about the true implications of the NPPM_MODELESSDIALOG message, but the only way to undo this major regression in a reasonable amount of time is for Notepad++ to take on some of the blame and responsibility, and do a v8.6.2 release as soon as possible to fix this. The longer this situation lasts, the more users, and plugin developers, will decide that Notepad++ and its ecosystem isn’t worth the hassle.

Addenda: If I sound a bit strong in this post, its because I care deeply for Notepad++: I’ve been a user since circa 2005 – the vast majority of Notepad++'s 20 years, and a significant portion of my adult computing life – and have been a proponent of Notepad++ since I first tried it, and I have been a major contributor to this Community since I joined 8 years ago. So at this point, I am emotionally and psychologically invested in the success of Notepad++. And I think that how Don chooses to handle this issue is going to be a huge part of deciding (or at the very least, an indicator of) whether Notepad++ will continue to be a viable editor in the next few years, let alone in the next 20. And I’d really like to be able to continue using Notepad++ for the next 20 years if possible.

There seems to be a weird bug where you can’t use Ctrl+V to paste text into the text fields of forms for certain plugins.

I’m not familiar with C# or with dockable dialogs. However, I was able to reproduce the Ctrl+V failure in the Search (non-modal) dialog of my (C++) Columns++ plugin by commenting out the lines that send NPPM_MODELESSDIALOG messages.

I believe the entire “problem” arises from the failure to send those messages. (Searching the git repositories of some of the plugins cited as having this problem suggests that they do not send NPPM_MODELESSDIALOG messages.)

Can anyone demonstrate a case of this happening in a modal dialog, or in a non-modal dialog that has been properly registered using NPPM_MODELESSDIALOG?

@PeterJones

Making everyone who uses plugin dialogs or docked windows put in a zero byte config file

I’m not crazy about some of the recent changes either, but in this case I think it’s more like “making plugin authors code their plugins correctly.” NPPM_MODELESSDIALOG goes back at least as far as version 5.6.7, so it’s not like this is a new thing.

Edit to add:

One more thing of note is that a user of previous versions of Notepad++ who assigned Ctrl+V to something other than the default a Scintilla command would also experience failure to paste in non-modal dialogs that don’t register with NPPM_MODELESSDIALOG. (Tested with 8.5.8 and 8.6, using Columns++/Search as the test with registration and JsonTools/Open JSON tree viewer as the test without registration.)

Oh, and all this applies to Ctrl+x and Ctrl+c, too.

Even if separate menu items were created, a user who wanted Ctrl+x/c/v to perform the new, extended functions in the Scintilla control would have to give up having them work at all in non-modal dialogs that don’t register using NPPM_MODELESSDIALOG. The solution is to fix the plugins.

As further evidence that modal forms are immune, F# Interactive’s configuration menu functions just like before.

It’s obvious by now that any child window with an edit control will inherit N++'s own non-responsiveness to Ctrl+V. The choice of programming language really has nothing to do with it.

Making everyone who uses plugin dialogs or docked windows put in a zero byte config file to undo the recent problematic new feature seems the wrong way around to me.

As much as the magic copy/cut/delete is a cool way to imitate VS, is the cool new feature really worth the problems it has caused in v8.6 and v8.6.1?

As @Alan-Kilborn has suggested here and at other times, if it’s implemented so that the magic copy/cut are separate menu entries, with the default shortcuts set to the old entries (ie, v8.5.8), then people will get what they expect by default, but have the ability to decide for themselves to change the shortcut to access the magic version: that gives everyone what they want, without causing problems with the standard installation.

I’m also finding that soon after undocking that window, Notepad++ freeezes…

Known issue, though one with a relatively trivial fix, i.e.,

intptr_t attributes = ::GetWindowLongPtr(wincontrol.Handle, GWL_EXSTYLE);
::SetWindowLongPtr(wincontrol.Handle, GWL_EXSTYLE, attributes | WS_EX_CONTROLPARENT);

Weirdly enough, the CSVLint plugin, which is also C#, does not appear to have this issue.

The ConvertData and Settings dialogs don’t (just as your Settings dialog doesn’t) because they are modal. Modal dialogs have their own message loop and don’t depend on the calling program’s loop, so Notepad++’s changes in how keystrokes are processed don’t affect them.

The CSV Lint window (dockable) does show this behavior (Shift+Insert pastes, Ctrl+V does nothing) in the left-hand pane. (I’m also finding that soon after undocking that window, Notepad++ freeezes… I don’t normally have that plugin installed, and I haven’t yet tested whether it’s an interaction with some other plugin.)

JsonTools has the grepper form and the sort form , neither of which is dockable or spawned from a dockable dialog, and those both have the Ctrl+V issue.

They appear to be non-modal dialogs opened without setting the Notepad++ window as parent and without sending NPPM_MODELESSDIALOG messages.

As per my message above, I suspect not using NPPM_MODELESSDIALOG is the common factor; but I haven’t worked with dockable dialogs and don’t know whether they can, should or usually do register as modeless dialogs.

The owning window receives the key event first.

Both the modal and non-modal dialogs in Columns++ are created with the Notepad++ window as the owner. I don’t think that can be the problem. It’s not the owning window, but the message loop, that receives and dispatches keystroke messages.

What does matter is that my non-modal dialog calls NPPM_MODELESSDIALOG when it opens and closes. This adds it to the table used to call IsDialogMessage in this code. Without that, keyboard navigation and underlined dialog accelerators don’t work as expected.

When the JsonTools panel is open and the focus is in the input area, Ctrl+f opens the Notepad++ find dialog. When the (non-modal) Search dialog in Columns++ is open and focused, Ctrl+f doesn’t do anything.

So I’m guessing these dockable dialogs are not registered using NPPM_MODELESSDIALOG and hence are subject to the main Notepad++ accelerator table. That changed, I believe, to support the new cut/copy/paste without selection behavior, which I would guess is why the dockable dialogs are seeing something different than before.

I think it’s possible that it’s dockable dialogs, not C# forms, that trigger the problem.

No, it’s more complicated than that.

JsonTools has the grepper form and the sort form, neither of which is dockable or spawned from a dockable dialog, and those both have the Ctrl+V issue.

Weirdly enough, the CSVLint plugin, which is also C#, does not appear to have this issue.

@donho

Does the following link solve your problem?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14557

No.

• I added an empty file named disableLineCopyCutDelete.xml to my %Appdata%/Notepad++ directory as instructed in your post.
• I then rebuilt JsonTools with the code that fixed the issue commented out, to isolate whether your proposed fix had any effect.
• Ctrl+V still did not work in any of my forms, dockable or otherwise.

@rdipardo

I tried Shift+INS and it works for every plugin with an edit control, whether native or delegated to the .NET runtime

I tested this, and it does indeed work even when Ctrl+V doesn’t. If this issue isn’t fixed, that’s probably what I will advise my users to do.

See Issue #14561 for details and workaround.

Edit: Ugh. Apparently this is a Scintilla change, as explained in a comment to the issue.

It seems Notepad++ and Scintilla are in agreement: nothing is too standard, familiar and time-honored to be broken if it improves multiple selection.

The Tree Viewer in JsonTools and the NavigateTo dialog are both dockable dialogs. The Settings dialog in JsonTools is modal and non-dockable. Columns++ has both modal and non-modal dialogs, but none are dockable.

Dockable dialogs are owned by the Notepad++ window, i.e., they’re constructed with a handle to the application window (not to be confused with the editor handle, which belongs to Scintilla). Modal dialogs typically have no owner (handle = 0); “non-modal” (floating?) dialogs may have one or the other.

The owning window receives the key event first. My guess is that whatever N++ now does with CTR+V is not propagated to the (docked) child windows. I tried Shift+INS and it works for every plugin with an edit control, whether native or delegated to the .NET runtime. A GitHub user explains that Shift+INS is a system-defined key combo, which ought to bypass both N++ and Scintilla’s key handlers and “just work” in all cases.

In the (unlikely) event there’s a corrective intervention upstream, it would involve some manner of broadcasting Ctrl+V to the child windows, the way Scintilla (implicitly?) did when Ctrl+V was mapped to SCI_PASTE. In other words, restore Scintilla’s former role in the key event life cycle.

As far as I know, this only affects Windows Forms (made by plugins based off the C# plugin template ), because of the following pattern I observed:

JsonTools 6.1.1 , a C# plugin, has this bug.
NavigateTo 2.7 , also a C# plugin, has this bug.
Columns++ 1.0.2 , a C++ plugin, does not appear to have this bug.
ComparePlus 1.1 , a C++ plugin, does not appear to have this bug.

I note that JsonTools shows this behavior in the Json Tree Viewer window, but not in the Settings dialog.

The Tree Viewer in JsonTools and the NavigateTo dialog are both dockable dialogs. The Settings dialog in JsonTools is modal and non-dockable. Columns++ has both modal and non-modal dialogs, but none are dockable. I haven’t looked at ComparePlus in depth, but it does not appear to have any dockable dialogs.

I think it’s possible that it’s dockable dialogs, not C# forms, that trigger the problem.

As far as I know, this only affects Windows Forms (made by plugins based off the C# plugin template ), because of the following pattern I observed:

Does the following link solve your problem?
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14557