Viewer does not format hex bytes with spaces in message dialogs

[rohitab]

Far Manager version

3.0.6097.0 x64

OS version

10.0.22623.1180

Other software

No response

Steps to reproduce

1. Open a file in Viewer, preferably one that takes more than one screen to display
2. Press the Down key to change the position of the file. This will ensure that the first dialog is also displayed.
3. Press F7 to open Search
4. Press Alt+H to switch to Hex mode
5. Type in some hex bytes that are not present in the file, e.g. 72 6F 68 69 74 61 62 2D 64 65 61 64 63 30 64 65
6. Press Enter to search

Expected behavior

Viewer displays one of the following messages. Note that the hex bytes are formatted with spaces -- the same way they were entered/displayed in the Search for box

╔════════════════════ Search ═════════════════════╗
║           End of the document reached           ║
║  Continue from the beginning of the document?   ║
║ 72 6F 68 69 74 61 62 2D 64 65 61 64 63 30 64 65 ║
╟─────────────────────────────────────────────────╢
║               { Yes } [ Cancel ]                ║
╚═════════════════════════════════════════════════╝

╔════════════════════ Search ═════════════════════╗
║            Could not find the bytes             ║
║ 72 6F 68 69 74 61 62 2D 64 65 61 64 63 30 64 65 ║
╟─────────────────────────────────────────────────╢
║                     { OK }                      ║
╚═════════════════════════════════════════════════╝

Actual behavior

Viewer displays the following messages. Note that the hex bytes are formatted without spaces, which makes them less readable. Maybe this was intentional in order to reduce the size of the dialog?

╔═══════════════════ Search ═══════════════════╗
║         End of the document reached          ║
║ Continue from the beginning of the document? ║
║       726F68697461622D6465616463306465       ║
╟──────────────────────────────────────────────╢
║              { Yes } [ Cancel ]              ║
╚══════════════════════════════════════════════╝

╔═════════════ Search ═════════════╗
║     Could not find the bytes     ║
║ 726F68697461622D6465616463306465 ║
╟──────────────────────────────────╢
║              { OK }              ║
╚══════════════════════════════════╝

For Text input, the Viewer displays the text exactly as it was entered in the Search for box.

[MKadaner]

The idea might have been to show as much of the search string as would fit on the screen. Unlike the Search dialog where hex value is entered into a text box and can be scrolled left and right, these message boxes would truncate the string without chance to see the tail. I am not sure it is so much important though.

Preserving formatting spaces would be simple but do we really want it? Maybe replace label control with the readon-only text box, so the user can examine the entire string if they really want? If we even have read-only text boxes?

[rohitab]

I assumed it was intentional as well, in order to show as much of the string as possible. For a long length input, the user is probably not going to be examine/verify the input by looking at it in the dialog, especially when it's formatted without spaces. For smaller length input, spaces would definitely make it more readable, and easier to examine.

Of course, this is extremely low priority.

Please don't mind me reporting minor issues. Feel free to close these as Won't fix. I promise not to get offended! :neutral_face:

[MKadaner]

Personally, I'd keep this issue open, even though it's a very low priority indeed. Personally, I think it's the right thing to do to report even minor issues, and WontFix them only if we think them non-issues.

However, I know that some teams want to have clean backlog either by fixing issues quickly or aggressively closing them without assessing their merits. As such, the decision should be with project maintainers.