For example, if you select “Copy as Hex Text” for BA10000E,
the copied value will be “BA 10 00 0E”.
Normally, no spaces are needed.
When editing, if a value like this is copied, it cannot be pasted anywhere as is.
Would it be OK to have the spaces be a setting? I prefer it as-is (i.e. including spaces). My typical usage for copied hex text is for it to be consumed by humans and I feel like spacing makes it much easier at which to look.
FWIW, I think it’s a lot easier to remove the spaces than it would be to have to add them in.
I’m not talking about ease of viewing.
I’m talking about ease of editing.
010 Editor is not a viewer, it’s an editor.
I think it’s normal for an editor to prioritize editing efficiency.
Where can I use data with spaces on the editing screen?
We are going to provide an option on whether to include spaces in the copy, hopefully in the next version. If you just want to copy a 32-bit or 64-bit value to another field in the program you can do the copy in the Inspector. By default the Inspector displays data as decimal but you can switch to hex by right-clicking on the table and choosing ‘Column Display Format > Value Column > Hex’. The Inspector also does byte swapping if you are using little-endian data. It’s also pretty easy to make up a short script to copy data as you want and then assign the script to a hotkey. We can show you how to do this if you are interested. Cheers!
Graeme
SweetScape Software
Currently I have created a script and registered copy without spaces in the right-click menu.
While it can be handled with a script for the time being, I think it’s problematic to have to take the trouble of creating a script for such a basic operation.
Copying from the Inspector has an “h” at the end, making it useless.
I don’t think I’ve communicated what I want very well, so I’ll give you an example.
For example, do you use the Inspector to paste something you copied in a text editor?
Normally, you would just paste what you copied and edit it, right?
I’m saying that the same should be true for hex editors.
For example, I can use hex bytes with spaces in the find dialog and it works fine (assuming I’m searching for hex bytes).
Where are you pasting the data where it doesn’t work with spaces? Perhaps the problem is more that the paste location doesn’t accept spaces rather than that the copied data has spaces in it.
I don’t think you quite understand what I mean.
I’m talking about the editing area.
For example, say you copy “ABC” in a text editor.
If you paste it as is and it becomes “A B C”, do you think this is normal behavior?
If it were a normal copy operation, I would expect the copy to as closely resemble the original data as possible, so I would expect a standard paste to have “ABC”. If I used a special copy (i.e. “copy as hex text”), then I would expect the clipboard to potentially have a different representation of the selected data. I wouldn’t use a special copy command unless I wanted the effect it gave. If I used a command like “copy as image”, I’d expect the clipboard to contain what I selected as an image, regardless of whatever it was originally.
If I’m in 010 and I want to copy something as it originally is, I use a plain “copy”. If I want to make a copy of some data in a file, I can use a normal copy-paste and the result will look like the original. I don’t use “copy as hex text” unless I want to paste the data in a text form. I use this all the time when I’m writing documentation or comments, for example.
I definitely feel like I’m not understanding… Perhaps it is a semantics problem. Would you say that “hex text” implicitly doesn’t have spaces in it? In my opinion, it could (although it is not required). Mentally, I expect “hex text” to look similar to the hex part of the editor window, which separates (typically) bytes.
Are you saying that, if you select the string “ABC”, select “copy as hex text”, and paste, you want it to paste the string “414243” instead of “41 42 43”?
That’s roughly it.
It would make sense if there was a special case of copying with spaces.
But I think the default behavior is usually not to include spaces.
OK. Thanks for helping me understand.
It sounds like they’re open to adding an option to control this, so both of us will get what we want in the future!
I hope so too.
Currently there aren’t many good hex editors that are under ongoing development, so I have high hopes for 101 Editor.