Tapatalk

Find Replace HEX Mode Oddity

Find Replace HEX Mode Oddity

2

    Jul 27, 2016#1

    We have used UE for ages, so this could just be some newer configuration, but in version 23.xx when we search for hex, it works fine in the "simple" find dialog, but if using the newer find/replace "dockable utility", UE searches for the value in hex and in ASCII which I can't imagine anyone wanting ever.

    Is that a bug, or a really bizarre feature that can be turned off?

    Thanks!
    6,685587
    Grand MasterGrand Master
    6,685587

      Jul 30, 2016#2

      Wow, you have by chance detected - lets call it a quirks - which I was not aware of since I'm using UltraEdit which is more than 15 years.

      It is indeed possible to use the regular Find dialog even with a regular expression string to find displayed text in hex edit mode. This can be achieved with two different methods:
      1. The Find and Replace window is docked on any side with or without auto-hide enabled and used to run a find on a file opened in hex edit mode.
      2. The Find and Replace window is opened with active file being in text edit mode, for example a new, blank file, and while the Find and Replace is opened, the active file is switched to a file in hex edit mode and on this file the text search is executed.
      In both cases the regular Find/Replace window for searching in text files is now active for searching in displayed text of the file in hex edit mode.

      The search is in this case done really on displayed text of the file opened in hex edit mode and not on the bytes in file. So if you enter for example 00 40 03 32 and this 11 characters can be really found in text buffer containing the displayed text, UltraEdit finds it and selects the found "text" in hex edit mode area.

      But the entire file is not searched for the 4 bytes specified in hexadecimal, just the text buffer with the displayed text. So with removing the spaces, no bytes will be found in hex edit area of the file as the hex edit area displays the bytes with a space between each hexadecimal representation. It is also possible to enter an odd number of hexadecimal digits as this search is not a byte search, but a text search in display buffer.

      It is also possible to search for ASCII strings in ASCII representation area with this quirks. It is even possible to search for an address in address area with this quirks, but the caret can't be set to address area and is therefore positioned right of the address.

      But the text mode search on hex edited file is done only on text of display buffer, not on entire file. So it is no real file search. For a real file search on file in hex edit mode it is necessary to press Ctrl+F to open the dialog window for a hexadecimal byte or ASCII text search in file.

      The method of having a binary (or text) file opened in hex edit mode and for example a new, blank file is the active file, then open the regular text find window with Ctrl+F, make the file opened in hex edit mode active, and run now the text find on displayed text of binary file works even with UE v10.10c which is the oldest version which I have still archived.

      So this quirks exists already very long (more than 15 years) and nobody has detected it before or at least has reported it in the forum since I moderate the forums.
      Best regards from an UC/UE/UES for Windows user from Austria
      19176
      MasterMaster
      19176

        Jul 30, 2016#3

        Hi, I detected and reported this when the dockable Find dialog was really new :)
        I recommend to integrate Hex search/replace into this new Find dialog as new tabs. Perhaps UE 25 will bring us this :)
        2

          Aug 02, 2016#4

          I appreciate the confirmation, guys. Version 14.2 was the oldest version that I had (and was using until recently) and I did not notice this issue with that version.

          Also, when attempting to use Replace in Hex Mode, stepping through the find-and-replace one-by-one, UE will even replace the values found within the ASCII buffer text along with the bytes. However, upon saving the document, only the proper values have been changed, from what I can tell.