Remove line breaks from Alt+M

[ProgerXP]

Document:

|1
2
3

Press Ctrl+C to copy 1\n to clipboard, do Alt+M, Ctrl+V into Prefix text to lines. Expected result:

11
12
13

Actual result is different. Now do the same but Ctrl+V into Append text to lines - expected:

11
21
31

Again, result is different.

Solution: apply the same normalization as in #121 - remove \r \n from these two input values.

[cshnik]

The actual task is: to fix "paste from clipboard" functionality for these input fields. But I can't reproduce specified behavior in my environment. My local tests in XP, 7 and 10 always give me the correct results. I've found the only way to reproduce the issue: manually setup text values in the debugger.
It looks like there is a missing/incomplete step description in the provided scenario.
Please confirm if this is OK and required solution is described correctly.

[ProgerXP]

It only works if line ending style is CRLF. Try this:

1. Create new document
2. Alt+F8 to switch to LF
3. Enter a few lines (let's say 3)
4. Focus first line, Ctrl+Shift+C
5. Alt+M, Ctrl+V, Enter

Instead of 3 lines you now have 6 lines. Switch back to CRLF - this doesn't happen.

[cshnik]

Fixed.

[ProgerXP]

Isn't it simpler to just ignore \r \n after actual submission, without this magic with subclassing and WM_PASTE interception? When I have \r \n I don't see any difference in the text inputs, it doesn't really interfere in the dialog itself.

[cshnik]

Here are the points:

1. Subclassing is not a magic since it is a regular way to implement custom behavior when performing operations within standard controls.
2. Reusing of the code is always good: fewer errors, faster development.
3. Changes in the original sources (Notepad2) are minimal.
4. Storing of the raw (unfiltered) data is not a good way (in general) since it complicates development and support. Multiple places where the data is used should be analyzed and fixed (if required). UI may behave differently in other OSes (and may require additional changes).