As to
CSV import, no problem whatsoever:
In UR import, I have field delimiter TAB, text qualifier " (double-quote), and template "text"); within the column that goes to the UR content field ("ItemText"), my newlines are as LF (line feed, Ascii 010, hex 0A, binary 00001010, U+000A), my record delimiter is CRLF (LF as before, and the CR is Ascii 013, hex 0D, binary 00001101, U+000D).
Btw, TABs (see above for tabs in UR's Data Explorer), are Ascii 009, hex 09, binary 00001001, U+0009; there is NO difference between the Windows-1252 char table and UTF-8 (up to) here.
I also tried CRLF instead of just LF for newlines, and also TABs, both within the "-delimited content field (the "..." not being needed for regular data fields btw), and it all works as expected, so it's perfectly possible to replicate any tree within UR, preserving tabs and all sorts of newlines (CRLF, LF, CR) for the "content") in case.
As to
find/replace the above control characters in UR Content ("Item Details" pane), I am lost, though, albeit having discovered a quite weird phenomenon:
It's possible to enter those (venerable Ascii) chars (from 1990 or before) into UR's content's "Find" dialog (e.g. Alt-10, Alt13, on the Numpad), and they then appear as symbols (from the Eighties, Ninetees...) in that dialog's "Find what" field then; ditto for "all the other" such control chars then represented by symbols (younger UR users will not even recognize anymore I suppose), and just entering Alt-0 (for Null character NUL) will have not effect in that dialog. (Doing Alt-10, Alt-13, etc, within UR's content pane, directly, will have NO effect though.)
Then, you can copy those chars from the "Find what" field (select them, then ^c), and you can then paste them into the content field (^v), where they appear as symbols exactly as you have seen them in the "Find what" field...
And then, from entering them (by ^v or by Alt-13, etc.) into the "Find what" field, the Find dialog will FIND them in Content! - i.e. find the symbols, NOT find anything those symbols represent, unfortunately...
So just the real TABs, LFs and real CRs are not found this way yet, but there should be a trick? (I also experimented with U+ and binary input, but may have missed the right way to do so?)
EDIT:
And I don't know if there is a realistic, possibly quite easy way to tweak the MS rtf control (i.e. just one of the two or more controls we could use), by something like
SetWindowText(HandleOfYourRTFControl, "Line1\nLine2")
(
https://social.msdn.microsoft.com/Fo...orum=vcgeneral ) - understood that here, the problem is the search within the control, so perhaps that'll be impossible indeed?
EDIT 2:
It just occurred to me that it might be possible (?) to just create alternative "Find" and "Replace" dialogs, and which would then be triggered in lieu of the native ones... and which would send the pertinent LF, CR and TAB codes to the MS rtf control, from some code to be entered within the dialog... if (sic!) the problem is just sending the correct code to the control, instead of the dialog sending all strings literally. Just an idea...