Copying in Hex Mode

ulysse · Aug 22, 2005#12005-08-22T02:43+00:00

Since updating to version 11 from 10, I've bee having problem copying and pasting in hex mode. If I copy a block of bytes that start with an alphanumeric byte, I will end up only copying the alphanumeric bytes that follow, and none of the other bytes following.

For example: if I highlight and copy a block like "thisBlock%%%%" in hex mode, where "%" stands for some none-alphanumeric value, when I paste the block only "thisBlock" will showup, instead of the whole block.

Is this a bug or a new feature? How can I fix/disable it so that I can copy and paste the whole block?

Mofi · Aug 22, 2005#22005-08-22T17:30+00:00

I have already reported to IDM, that paste in hex mode is not working as expected, if the On paste convert line endings to destination type is activated in the general configuration dialog at v11.10b. The developers of IDM will disable this feature inside UltraEdit automatically, if a file is edited in hex mode at next version. As workaround turn the feature off while editing in hex mode and reactivate it after editing in hex mode is finished.

ulysse · Aug 23, 2005#32005-08-23T00:58+00:00

Yep, problem solved.

Many thanks.

May 31, 2007#42007-05-31T21:07+00:00

I've recently updated my Ultraedit from version 11 to 13.00a+2, and I've been experiencing problem with copying and pasting in hex mode. I had already had the same problem before, as I posted above. But the problem came up again in 13, only this time the workaround doesn't work anymore.

Basically, when I copy a block of data that starts with alphanumeric bytes but contains non-alphanumeric bytes, everything after the non-alphanumeric bytes will be cut off when I paste the block. This pretty much makes complex hex editing impossible.

I've tried disabling the "On paste convert line endings to destination type" option in File Handling, but that didn't help...

Any suggestion?

Mofi · Jun 01, 2007#52007-06-01T11:20+00:00

The problem written above with setting On paste convert line endings to destination type was fixed with UltraEdit v11.10b+4. No need to disable that setting anymore when working in hex edit mode.

I can't reproduce what you have written. Can you step by step explain what you do, beginning from opening the file.

Select the important part of the file, use Edit - Hex Functions - Hex Copy Selected View and paste it into your post enclosed in the BBCode tags

Code: Select all

(without the address column).

ulysse · Jun 01, 2007#62007-06-01T15:20+00:00

The problem occurs essentially as I described in the first post (for version 11). To take a specific example:

1. I open two files via drag&drop, named RB1.exe and RB2.exe respectively.

2. I copy the first 32b of RB1.exe by Ctrl-C, with the following content:
00000000h: 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00 ; MZ........ÿÿ..
00000010h: B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ; ¸.......@.......

3. I switch to RB2.exe (which has identical content for the first 32b), and paste via Ctrl-V, but only the first "4D 5A" (which are "MZ" in ascii) are pasted, resulting in the following 34b:
00000000h: 4D 5A 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF ; MZMZ........ÿÿ
00000010h: 00 00 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 ; ..¸.......@.....
00000020h: 00 00 ; ..

*The above is just a demonstration of how this problem can actually occur -- it's not really what I wanted to do.

Actually, the same problem occurs even within the same file. As far as I can tell, it's exactly the same problem I experienced with version 11.

Thanks.

Mofi · Jun 01, 2007#72007-06-01T19:46+00:00

I created the 2 files with your 32 bytes and then have done the same steps as you. But there is no problem. The 32 bytes of file 1 are correct inserted into file 2. I have used UltraEdit v13.10 Beta 2 and v13.00a+2 to verify this.

I suggest to contact IDM support by email, explain the problem, the version you use and the operating system and attach also your uedit32.ini to the email.

But before try following:

Make a copy of all files named uedit32.* (INI, UEK, ...) and then delete these files in your UltraEdit application data directory. Next start UltraEdit which creates now the default uedit32.ini and try the hex editing again.

If the effect does not appear anymore, there is a setting which causes UltraEdit not to work as it should. We can than compare your uedit32.ini with the default uedit32.ini to find out the setting which causes the effect and write an appropriate bug report email to IDM.

If the effect with paste in hex edit mode is also present with the default uedit32.ini, then only the IDM support can maybe help you further.

ulysse · Jun 02, 2007#82007-06-02T00:26+00:00

I've tried removing the application data files, didn't help either. I'll try the IDM support. Thanks for the help.

With a bit more experiment, I found the problem to be quite fickle. If I create a file from scratch and input the data I posted above, as I imagine you did, the problem indeed does not occur. Also, with the original file, if I change the "90" byte after the "MZ", the problem also does not occur. I've tried some other random steps and got varying results. The only sure way to reproduce this problem, it seems is with my RB1.exe and RB2.exe. Though I don't see why UE would have a file specific problem. If you're interested I can try to post these files.

Again, thanks for the help.

Mofi · Jun 03, 2007#92007-06-03T18:17+00:00

Well, if it only occurs with a special byte sequence than it is better to send the files to IDM support with the steps to reproduce. The IDM developers can debug what is going wrong which I can't do.

UltraEdit, UltraCompare, UEStudio forums