You’re right to remind me to integrate it into a new version of WinGUp, and include it into the new release.

Thank you for your reminding!

The original author of this other post hasn’t come back to see my recommendation to post a reply here, so I’ll do it on their behalf: they noticed that, even though wingup pull #48 (fixing some proxy difficulty) has been incorporated into the wingup repo since November 21, 2023, that updated wingup was never tagged; thus, even though there have been three Notepad++ releases since that merge (making this the fourth), the gup.exe that’s shipping with Notepad++ still doesn’t incorporate that fix, which makes it harder to do Notepad++ updates in corporate environments that use a proxy.

I know it’s not a “regression” with this release, and I don’t know whether that’s critical enough to include as a change before converting this RC into a full release or not, but from proxy-users’ perspective, sooner rather than later is probably good – but since the change was accepted last Fall, just not tagged or released, I thought I’d remind you here.

Please explain that a bit more.

I did exactly what you’ve done.
With or without %APPDATA%\Notepad++\noColumnToMultiSelect.xml, after creating a column, the arrow forward key (->) doesn’t cancel the column mode, but the whole column returns to vertical carets and move forward.

Obviously there’s something special in my configuration. I’ll find it out.

Thank you for the testing and the confirmation.

I just found a regression/bug:
Putting noColumnToMultiSelect.xml into %APPDATA%\Notepad++\ has no effect after restarting Notepad++.

Could anyone here confirm this regression please?

Please explain that a bit more. I have been using noColumnToMultiSelect.xml in %APPDATA%\Notepad++\ and it seems to be working with v8.6.3. I renamed the file, exit/restart npp, and npp was in multiselect mode.

My test was using the keyboard. While holding Shift+Alt down I used the arrow keys to create a column. I released the Shift+Alt keys and tapped an arrow key.

• With a noColumnToMultiSelect.xml file present the editor goes back to normal single cursor mode.
• Without a noColumnToMultiSelect.xml file the editor is in multi-cursor mode.

I put the noColumnToMultiSelect.xml file back and the desired behavior is restored. Thus, I’m not certain what to look for that may be a regression.

Could anyone here confirm this regression please?

• ES_MULTILINE <-> TextBox.MultiLine (this is necessary for a textbox to take up more than one line of vertical space, so there’s really no way to turn this off without ruining the visual presentation of the relevant controls)
• ES_WANTRETURN <-> TextBox.AcceptsReturn (the default is False, I tried setting this to True and it didn’t do anything.)

Currently I have a KeyUp trigger that (if a textbox is MultiLine) replaces the selected text in \r\n and then scrolls to the caret. This fix is OK, but:

• it doesn’t replace the loss of ability to hold down Enter to add a bunch of consecutive newlines
• it overwrites the entire TextBox’s text, which can add latency when there’s a lot of text

Since this discussion is straying away from the topic of Notepad++ 8.6.3, I’m going to repost this as a reply to this topic and suggest that any further suggestions go there.

2. Hitting the Enter key no longer creates a newline in multiline textboxes (presumably because the KeyUp message has been consumed by the preprocessing here?)

Does the edit control have both ES_MULTILINE and ES_WANTRETURN styles set?

1. KeyUp and KeyPress event handlers no longer work consistently
2. Hitting the Enter key no longer creates a newline in multiline textboxes (presumably because the KeyUp message has been consumed by the preprocessing here?)
3. Hitting the Tab key does not traverse the form’s controls in TabIndex order, but instead follows the order in which the controls became visible/enabled (I think).

To be clear, I am not mentioning these issues to shame Don Ho, or to suggest that NPPM_MODELESSDIALOG is net negative for Notepad++. Don Ho obviously has a hard enough job as it is without having to worry about weird interactions between legacy C++ APIs and Windows Forms. I just want to crystallize generalized “maybe NPPM_MODELESSDIALOG is bad?” concerns into specific issues.

If you’re going to include code to work around the cut/copy/paste keyboard shortcut failure in plugins with modeless dialogs that don’t call NPPM_MODELESSDIALOG, why not put it where it will work all the time, instead of only when the corresponding menu options are enabled?

It’s not about only cut/copy/paste keyboard shortcuts, it could, in the future, Ctrl-Z & Ctrl-Y and other Scintilla keyboard shortcuts are moved into Notepad++ code (though it’s not planned yet).
OTOH, the generic solution (NPPM_MODELESSDIALOG) is there for that purpose, and it works fine.
As a result, adding workaround in Notepad++ code for the plugins which don’t want to call (or ignore) the message NPPM_MODELESSDIALOG will not be considered.

Note that there might be the same copy/cut problem that we discovered in v8.6.1 on text fields for some non C++ plugins.

I’m being somewhat of a Devil’s advocate here, but I think the question is sure to be raised sooner or later:

If you’re going to include code to work around the cut/copy/paste keyboard shortcut failure in plugins with modeless dialogs that don’t call NPPM_MODELESSDIALOG, why not put it where it will work all the time, instead of only when the corresponding menu options are enabled?

For those trying to follow what is going on:

1. Changes in how cut, copy and paste work in Notepad++ required changing those commands to be Notepad++ commands instead of Scintilla commands.
2. That caused problems in certain plugins that neglected a Notepad++ requirement. (My guess is that one or more commonly-used templates for C# plugins omit the required calls to NPPM_MODELESSDIALOG in the model code for docking dialogs.)
3. A work-around was added in Notepad++ to the part of the code that implements cut, copy and paste commands to redirect those commands back to the plugins when they come from windows that aren’t part of Notepad++ itself.
4. The changes (1 above) to cut and copy made them functional even when nothing is selected. That bothered enough users that an option is added in this release to restore the old behavior, where those commands are disabled when no text is selected in the edit window.
5. If the old behavior is chosen, when nothing is selected in the edit window, since the cut and copy commands are disabled, the work-around (3 above) never gets called and the keyboard shortcuts fail in the plugins that needed the work-around.

What could be done:

Instead of putting the work-around in the code that implements the commands, it could go in IsDlgsMsg, just before the return false at the end. The idea would be:

1. Check to see if the target window for the message is a window from Notepad++ code. (It might be sufficient just to check if it is the main or secondary Scintilla window.)
2. If it isn’t, check to see if the message is a WM_KEYDOWN for x, c, v, Insert or Delete.
3. If so, call GetKeyState to see if the right modifier keys are down to make this a cut, copy or paste keyboard shortcut.
4. If so, find the first dialog window that is an ancestor of (or is) the target window and call IsDialogMessage using that window.
5. Otherwise, return false.
6. Get rid of the work-around code in the cut, copy and paste command implementations.

I can attempt to sort out the details and create a commit and a pull request for this if you want it, @donho, though I am unable to promise how quickly I can do it.