Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Copy from edit database cell broken in binary mode #1485

9 tasks
tlhackque opened this issue Jul 29, 2018 · 3 comments
9 tasks

Copy from edit database cell broken in binary mode #1485

tlhackque opened this issue Jul 29, 2018 · 3 comments


Copy link
Task lists! Give feedback

@tlhackque tlhackque commented Jul 29, 2018

Details for the issue

What did you do?

  • Look at a data cell in binary.
  • Select and attempt to copy,

What did you expect ?

Able to copy what I see.

What did you see instead?

a) if I select in either the text or the binary side, the other is also selected. This is OK.
b) However, the selection stops short of the address column, like this:
Note that the first "2" is selected, but the blue background doesn't cover the whole character cell. It is not possible to extend the selection to the address. (with either mouse or keyboard)
c) There is no right-click copy
d) If I copy with Control-C & paste elsewhere, I get the hex (but not the ASCII). And there are no spaces between the bytes. The address is not copied. E.g.


I expected:

0000 2e 6e 65 77 2e 2e 2e 6c 6f 67 69 6e  .new...login

e) If I export, I get just the text (and only Save as *.txt & *.* as export options):


This seems to be a regression from #1438 -- I thought that had save as binary implemented, with save as text in the pipeline.

The data in this cell is actually text - I selected Binary to make sure than there is not glyph-aliasing going on. So perhaps you are choosing an export mode based on what you think the cell contents is, rather than what I selected. It's great to have you guess what the cell contents is & select a mode based on the guess.

But if I select Binary mode, I expect export to be .bin (binary) as an option. Just because something looks like text doesn't mean that I want it treated that way (e.g. line ending conversions.) In general, once the user selects a mode, DB4S should treat the data as specified by the user, not according to any guess it made.

(Context: I wanted to provide the hex dump as supporting data in a commit to another project.)

FWIW: The database is open read-only.

Useful extra information

The info below often helps, please fill it out if you're able to. :)

What operating system are you using?

  • [x ] Windows: ( _version:_10 pro 1803 ___ )
  • Linux: ( distro: ___ )
  • Mac OS: ( version: ___ )
  • Other: ___

What is your DB4S version?

  • 3.10.1
  • 3.10.0
  • 3.9.1
  • Other: _25-Jul

Did you also

mgrojo added a commit that referenced this issue Sep 29, 2018
When the data source is the hex editor we are able to save whatever
data type as shown in the widget, so additionally to set the filters
according to the data type a "Hex dump files (*.txt)" filter option is

If the user selects this option for saving, the hexadecimal dump of the
widget content is saved to the file. Note that the check must be performed
using the selected filter by the user and not the file ending, which would
be the same for text data exported as plain text.

The Null case is disregarded as it is useless for exporting.

See issues #1438 and #1485
@mgrojo mgrojo self-assigned this Sep 30, 2018
mgrojo added a commit that referenced this issue Sep 30, 2018

Added a new copy action to the binary editor context menu for copying the
selected text as seen by the user, instead of the stream of hexadecimal
digits copied by default by qhexedit.

In order to support copying from the context menu, qhexedit has been
modified for not resetting the selection when the left mouse button is
pressed. This will be converted to a pull request to qhexedit afterwards.

See related issue #1485
Copy link

@mgrojo mgrojo commented Sep 30, 2018

@tlhackque, I managed to implement the part about:

Able to copy what I see.

A new action (shortcut Ctrl+Shift+C) included in the context menu has been added for copying the selection, including the addresses, the hex digits and the ASCII part.

I've noted these behaviours of the qhexedit library that we are using, and I cannot change without modifying the library (this may be what the user wants or not):

  • The addresses are adjusted to the begin of the selection. They aren't the original addresses.
  • The ASCII part is different to the one displayed. In the display, Latin-1 is allowed, but in the copied
    data, only US-ASCII (7bits) is present.

Nevertheless, I had to make a change for being able to copy using the context menu and I'll make a pull request, so it can be added to the official library.

Could you try the new action in tomorrow's nightly build and confirm that it's working for you?

Copy link

@justinclift justinclift commented Dec 8, 2018

Looking the two issues we have marked as "release blockers" for 3.11.0, is this one still current?

Copy link

@mgrojo mgrojo commented May 3, 2020

Looking the two issues we have marked as "release blockers" for 3.11.0, is this one still current?

It wasn't definitely a release-blocker, and in fact, we didn't mind for releasing it 😉. @tlhackque reported what could be considered a bug (being able to copy what I see), but also other things, which are good suggestions for enhancements; so I'll leave it open but remove the bug and release-blocker labels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants