Open rohitab opened 1 year ago
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.
No worries. You're right, these issues have been there for a while, and they are definitely not high-priority.
Looking forward to improvements.
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.
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.
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.
Ctrl+BS
also work and erase the complete byte, unlike the existing hex controlObviously, 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:
Dialog.FindFile.Text2Hex.lua
from the attached archive Dialog.FindFile.Text2Hex.zipDialog.FindFile.Text2Hex.lua
to %FARPROFILE%\Macros\scripts
directorymacro:load
or restart FarAlt+F7
to open the Find file dialogAlt+T
to switch to Text modeIMPORTANT: Remember to delete %FARPROFILE%\Macros\scripts\Dialog.FindFile.Text2Hex.lua
otherwise the Find file dialog will not work for searching text.
Far Manager version
3.0.6090.0 x64
OS version
10.0.22623.1095
Other software
No response
Steps to reproduce
Alt+F7
in a panel to open Find file dialogAlt+H
to switch to Hex mode01 02 03 04 05 06
01 02 03
and pressDel
,Backspace
orCtrl+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 pressAlt+T
andAlt+H
to switch to Text mode and back to Hex mode, the data is correctly displayed as04 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 pressAlt+T
followed byAlt+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 pressAlt+H
to switch to Hex mode, then pressTab
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 pressCtrl+A
followed byCtrl+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 of01 02 03 04
.