Erasing bytes from the Hex search box leaves blank spaces

[rohitab]

Far Manager version

3.0.6090.0 x64

OS version

10.0.22623.1095

Other software

No response

Steps to reproduce

1. Press Alt+F7 in a panel to open Find file dialog
2. Press Alt+H to switch to Hex mode
3. Type in some data in the Containing search box, say 01 02 03 04 05 06
4. Select the first three bytes 01 02 03 and press Del, Backspace or Ctrl+X

Expected behavior

The Containing search box should display 04 05 06

Actual behavior

The Containing search box displays 04 05 06, i.e. the three bytes are erased and replaced with spaces. The remaining three bytes remain in the same place, instead of moving left to the beginning of the control. If you now press Alt+T and Alt+H to switch to Text mode and back to Hex mode, the data is correctly displayed as 04 05 06, without the leading spaces. Note that regardless of the spaces, the search is performed correctly.

Cursor Position There is also a minor issue with positioning of the cursor in Hex mode. If the previous search was in Hex mode, and you reopen the Find file dialog, and press Alt+H to switch focus to the Containing search box, the cursor is positioned at the beginning of the control. If you then press Alt+T followed by Alt+H to switch to Text mode and back, the cursor is now positioned at the end of the control, which is the correct.

The above issue is also present in the Search dialog of the Viewer. In addition, if the previous search was in Text mode and you reopen Search using F7, the cursor is positioned at the end of the Search for box, which is correct. However, if press Alt+H to switch to Hex mode, then press Tab to switch to the Search for box, the cursor is positioned in the middle of the control (position is equal to length of text). This particular issue is not present in the Find file dialog.

For all unmodified controls, the cursor is normally positioned at the end of the control.

Copying Hex Data If you are in Hex mode of the Find file dialog and the search box contains 01 02 03 04, and you press Ctrl+A followed by Ctrl+C to select and copy all text to the clipboard, the clipboard will have: 01 02 03 04 i.e. 68 characters of data. If you repeat the same in Viewer search, the clipboard will contain 383 characters of data. Ideally, the clipboard should only contain 11 characters, i.e. the length of 01 02 03 04.

[MKadaner]

Thank for testing and summarizing all these details. So, basically, Hex Edit control misbehaves in many ways, and slightly differently when on different dialogs. While certainly annoying, all these issues do not seem critical, especially since most, if not all of them have been there for a long time. I may look at Hex Edit later, after I finish a couple of improvements already in the pipeline, but I cannot promise quick turnaround.

[rohitab]

No worries. You're right, these issues have been there for a while, and they are definitely not high-priority.

Looking forward to improvements.

[alabuzhev]

Erasing bytes from the Hex search box leaves blank spaces

Surprisingly, sometimes it is the right thing to do. And by "sometimes" I mean "probably almost always".

Masked input fields usually accept data in some fixed format. For example, DD/MM/YYYY and hh:mm:ss.xxxxxxx in Attributes dialog. If you decide to remove, say, the DD component for whatever reason, it makes no sense to have the the rest of the string flow to the left, e.g. 10/01/2023 Del Del 01/20/23 ???

And yet this is exactly what we have right now.

The only exceptions where the format is not actually fixed are these "hex" fields.

Come to think of it, using masked fields for "hex" inputs in Search/Find dialogs probably was not the best idea in the first place: it adds a lot of complexity (switching & hiding controls) and introduces ambiguities/misbehavings like the ones described in this particular issue, and the only benefits are spacing (which also means that only a 20-something bytes can be seen or entered) and preventing invalid inputs (not a big deal since we have to convert the string anyways).

I don't see why we can't have a simple plain text input for hex.

[MKadaner]

Readability maybe? But then I can imagine parsing from a plain string which deals with any separator or no separators. This way, all these inputs will be valid:

DEAD BEAF
DE-AD BE-AF
DE`AD`BE`AF

and so on.

Maybe reformat on lose focus to a "canonical" form, so that the user can see what he gets.

[rohitab]

I agree with most of what you said. However, instead of using a masked control or a simple plain text control, how about a slightly customized version of the plain text control? All that would be required is to limit the input to hex characters, and automatically format the control on input/paste.

Just to test it out, I wrote a Lua macro that converts the text input in the Find file dialog to a hex input just by using the DN_EDITCHANGE message. Most of the issues with the original hex control are not present here.

• You can type in unlimited data
• Copying all the text does not include additional spaces at the end
• Erasing text from the beginning/middle of the control automatically shifts the bytes and does not leave gaps
• You can also paste data into the control, including with or without separators/spaces
• Insert/overwrite modes work as well
• Keys like Ctrl+BS also work and erase the complete byte, unlike the existing hex control

Obviously, the code is for demonstration purposes only and is quickly/badly written. There are a few minor bugs, but since this is never going to be used, I didn't see a reason to fix them.

If you want to test it out, please do the following:

1. Extract Dialog.FindFile.Text2Hex.lua from the attached archive Dialog.FindFile.Text2Hex.zip
2. Copy Dialog.FindFile.Text2Hex.lua to %FARPROFILE%\Macros\scripts directory
3. Reload macros using macro:load or restart Far
4. Press Alt+F7 to open the Find file dialog
5. Press Alt+T to switch to Text mode
6. Type in data in the Containing box. It should work like a hex input control.

IMPORTANT: Remember to delete %FARPROFILE%\Macros\scripts\Dialog.FindFile.Text2Hex.lua otherwise the Find file dialog will not work for searching text.