jovibor/hexctrl

Fully-featured Hex Control written in C++/MFC.

hexctrl's Issues

Data fill performance

Discussed in https://github.com/jovibor/HexCtrl/discussions/58

^{Originally posted by datasynergyuk October 23, 2021}
I have done some performance testing on the release build of the sample application. All testing was done on the same hardware (i7, 32GB RAM, SSD) using an 8GB test file. Each test was done with a fresh application launch to avoid caching effects. I think there may be some opportunity to improver performance further:

1. Fill zero - 2,200MB/sec

2. Fill with hex data 64 bytes at a time (e.g. 128 zeros) - >4,200MB/sec. This operation is essentially the same as the standard fill with zero feature but, by using the fill with data mode and supplying a buffer of 64 bytes, the performance is 2x. I would suggest the fill zero feature should be able to achieve something similar to the fill data feature using a string of "0000000...000".

3. Fill random - 380MB/sec. This is a big improvement on the previous performance.

4. Fill with 'random' hex data (e.g. 128 characters) - As above, this can achieve >4,200MB/sec. Please can I suggest an additional "fast but less random" fill mode that uses a repeating buffer of perhaps 4KB random data. This would be adequate for many cases and would have performance approx. > 10x the current "fill very random" feature. e.g. In this mode, the random data would only be generated once and then recycled every 4KB. This would be suitable for fast data sanitation tasks.

Minor bugfix: Fails to compile in VS2017

Suggest adding the following to CHexDlgSearch.cpp:

#include <cctype>

Fill random

Please I suggest fill random data option. This enhanced with option many pass for clean data secure.

Numeric keys 1-6 interpreted as A-F input [Num lock on]

Maybe this is intentional (?) but it seems inconsistent with normal input expectations.

Unable to compile for ARM

The recent introduction of "Intel Intrinsics" into the codebase is great and a huge speed improvement. However, it prevents the code from being compiled for the Windows/ARM platform. Please can I suggest that the original (slow) code is left in place or alternative ARM implementation provided so that it can still be conditionally compiled for the ARM platform. This is increasingly popular in Windows space (14% and growing) and it would be a shame to prevent HexCtrl natively running on that platform:

https://www.counterpointresearch.com/insights/arm-based-pcs-to-nearly-double-market-share-by-2027/

For example:

https://www.codeproject.com/Articles/5301747/Porting-Intel-Intrinsics-to-Arm-Neon-Intrinsics

Page (sector) divider no longer scrolls correctly

To reproduce: Modify sample program to with SetSectorSize(0x100), open test file and use mouse wheel to scroll down. The page divider position appears fixed on screen and does not scroll with data as expected.

Can't edit data less than 256 bytes?

Hi,
When I opened a 256-byte file, I found that it could not be edited in the widget. If it was less than 256 bytes, it was still like this. Is this a BUG?

[Feature] Keyboard shortcut to jump over relative offsets.

1. Disable Go button if no / invalid address present
2. Support Ctrl+Left Arrow and Ctrol+Right Arrow for forward / backwards last relative address (allows you to jump through document in increments)

Exception in CHexCtrl::Create()

The most recent changes cause an exception in CHexCtrl::Create() when the creation mode is
CREATE_CHILD. This doesn't happen in the Sample program because it uses CREATE_CUSTOMCTRL and this skips the call the CWnd::CreateEx().

The exception occurs because IsDataSet() is called before m_fCreated is set to TRUE.

Text display

Some text flow past the line. How can I fix.

Strange exception during long modify data operation (release build only)

I found a strange bug in HexCtrl. I have only been able to reproduce the bug in virtual data mode when compiled as a release build. I cannot reproduce it in non-virtual data mode (e.g. sample application) or in debug builds.

To reproduce:

1. Build application using virtual data mode
2. Compile as release build
3. Launch program and open a reasonably large file e.g. 4GB
4. Perform data modify operation e.g. Fill random or fill with data etc
5. Change focus to another window e.g. In my test case, this is easiest done by using Ctrl-Tab to move to another full screen application
6. Wait a moment and then return to HexCtrl based application
7. Application terminates

Hanzi character

I like your software how display Hanzi character

Sample project cannot be built (in VS 2017)

Error C2511 'BOOL HEXCTRL::INTERNAL::CHexDlgEncoding::Create(UINT,CWnd *)': overloaded member function not found in 'HEXCTRL::INTERNAL::CHexDlgEncoding' Sample Project

CHexCtrl::SetSelection() doesn't scroll target into view

The current implementation of CHexCtrl::SetSelection() calls SetSelection() with scroll disabled. This means that when the selection is distant (not currently visible) nothing appears to happen. I tried adding an extra parameter to enable scroll and pass this down to SetSelection(). However, this didn't work.

Please can I suggest there is an option to bring the new selection into view. Maybe the solution would be to add SetCaretPos() to IHexCtrl?

Recent change has broken virtual data mode

The most recent change in af79727 seems to have broken virtual data mode. I think the problem is in the modified CHexCtrl::GetData() function which returns an empty data span.

HexCtrl appears to hang after long search is cancelled

To reproduce:

1. Open large binary file with Sample project
2. Use the Find All option to search for random ASCII text e.g. "ahsdfkjahsdfjk"
3. After a few seconds, click Cancel
4. Attempt to close the Search dialog

Cause: The loop in CHexDlgSearch::Find() appears to still be running after the search has been cancelled.

Chinese charset question?

Hello, I'm a Chinese developer, I use HexCtrl in my MFC App, using it with 'Building From The Sources' type,create window with these code:

RECT rcClient = { 0 };
::GetClientRect(GetSafeHwnd(), &rcClient);
HEXCREATESTRUCT hcs;
hcs.enCreateMode = EHexCreateMode::CREATE_CHILD;
hcs.hwndParent = m_hWnd;
hcs.rect = rcClient;
if (m_HexCtrl->Create(hcs))
{
// Set China locale
m_HexCtrl->SetEncoding(936);
// Init string whith Chinese Char
std::string str = "0123456789,零一二三四五六七八九十,零壹贰叁肆伍陆柒捌玖拾";
HEXDATASTRUCT hds;
hds.pData = (std::byte*)str.data();
hds.ullDataSize = str.size();

  m_HexCtrl->SetData(hds);
  m_HexCtrl->SetEncoding(936);
  // INT dpiX = GetDeviceCaps(hScreen, LOGPIXELSX);
  // float m_dScale = dpiX * 100.00f / 96.00f;
  // m_dScale = 2.0
  // m_HexCtrl->SetFontSize(UINT(14 * 2));

}

these code compiled ok, But after I run the App and click the data shown in the HEX View wnd, The data Changed random,is it a bug?

Minor bug fixes / UI suggestions for search dialog

1. Suggest provide edit / combo-box to select number of results to return for "Find All". Current default is 1000 but user cannot change this.

2. Suggest dialog could update "Start Search at" position each time it is made visible (from the current caret position). Current implementation seems to remember this from first invocation. Alternatively, perhaps add button to allow user to do this from current caret position? Currently user must either click on previous search result or enter this manually.

3. "Find all" seems to ignore "Start Search at" position and always starts at the beginning. It is therefore impossible to use this feature to find the >1000th instance or to use the "Find All" feature again to find the next 1000 records.

4. Suggest show what wildcard characters are supported in the dialog (similar to the GoTo dialog). Currently, it is displayed in a tool tip which is nice but not obvious to the user (I had tried to use it several times but only found out how it worked by looking in the source code).

5. Suggest re-label numeric search types as "LE" or "Little-Endian". Terms like (u)int8_t don't convey endianness and current UI cannot search for big-endian. Suggest instead, something like: "char/byte LE". This will be more consistent with data interpreter dialog and allow big-endian search to be added in the future.

I hope this helps.

Sometimes data is left out

Hi，
I use GetDataSize() in my program to get the data length , GetData() to get the data and write to the file, but I find that sometimes the last byte is missed.

Suggestion: Update next/previous bookmark index when jumping to bookmark

Please can I suggest updating the current bookmark index (m_iCurrent) when the bookmark manager is used to jump to a specific bookmark (CHexBookmarks::GoBookmark). This will make subsequent next/previous bookmark behaviour more consistent.

Fill zero performance

Fill with zero performance is approx. 6x slower than fill with hex data (long hex string ~ 16 digits). This is inexplicable because the operations are essentially the same. Suggest modifying fill with zero to use a longer source buffer for extra performance.

Exception in CHexCtrl::SnapshotUndo()

I found found a strange exception in SnapshotUndo(). It is easy to reproduce but I cannot re-create it with the stock sample application with either in-memory data or memory mapped file. This leads me to think it maybe related to DATA_VIRTUAL mode.

To reproduce:

1. Open a 4MB file e.g. 4,194,304 bytes with DATA_VIRTUAL
2. Right click
3. Select Modify / Fill with Data / Random

The problem occurs towards the end of SnapshotUndo() in the call to std::copy_n() when the data is copied into the newly allocated undo buffer.

Moving caret with mouse no longer sends HEXCTRL_MSG_CARETCHANGE

Previously, the HEXCTRL_MSG_CARETCHANGE notification was sent whenever the caret position changed.

Now it is only sent when the caret is programmatically moved BUT not when it is moved by the user e.g. mouse click

Suggestion: Open bookmark manager with the current bookmark highlighted in list control

The user interface could be improved by opening the bookmark manager (by default) with the current bookmark selected. Now the current bookmark is tracked internally, this should work for both standard and virtual bookmarks.

[Suggestion] Ability to change code-page for the text area.

Many hex editor applications provide support for non-ANSI code pages.

This can be useful for working with legacy data or data that was originally authored in a different language or character set such as EBCDIC. Currently, HexCtrl masks treats all text as "ASCII" and masks out text interpretation of characters <32 and > 127. This means the text interpretation is less useful for non-English languages (like French, German and Russian) that use accented or special characters > 127 and even less useful for languages such as Chinese or Korean that typically use Unicode.

It would be fantastic if HexCtrl supported code pages and Unicode text directly. This is not a feature that can easily be added in a parent application because the text conversion occurs directly inside HexCtrl. I would suggest that this work may not be all that difficult because Windows already has the MultiByteToWideChar() function for such conversions. For efficiency, it may be possible to convert one line (e.g. 16 bytes) of data at a time.

I would suggest there are two distinct scenarios to consider:

1. Different code pages - e.g. 7/8 bit characters that were represented using differently in original form. There is a list of OS supported code pages here: https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers

2. Unicode text - Text that was originally stored using fixed size 16-bit characters

My proposal leaves open the question of UTF-8 and other variable sized characters. MultiByteToWideChar() does support this but the interpretation may depend on previous / next bytes and I imagine this could be more complex to implement.

Bookmark Manager

Two minor issues with context menu. Both are related to multi-select:

1. Remove - When multi-selection present, only one bookmark is removed
2. Edit - When multi-selection present, "Edit" option should be disabled

Whether we should disable these three windows on the dialog when we are not in edit mode？

IDC_HEXCTRL_SEARCH_EDIT_REPLACE
IDC_HEXCTRL_SEARCH_BUTTON_REPLACE
IDC_HEXCTRL_SEARCH_BUTTON_REPLACE_ALL

Recent changes break public bookmark interface

You have removed BkmGetData from the public interface. This means the inner bookmark deque is no longer accessible. This breaks our application which manipulates loads/saves bookmarks via XML.

Please can I suggest this change is reversed or you add the following to the interface so similar behaviour can be implemented: BkmGetByIndex() and BkmGetCount()

does not support High DPI and multibyte(MFC APP)？

Hi, Big Boss:
I found this perfect Lib, I like to test it, I found it does not support High DPI and multibyte(MFC APP) now, do you have plan to perfect it？

Minor memory leak

There are two potential issues with the new call to StringFromIID(). Suggest initialise pointer before call with LPWSTR lpwstr=nullptr and then free memory afterwards with CoTaskMemFree() to avoid memory leak. See: https://docs.microsoft.com/en-gb/windows/win32/api/combaseapi/nf-combaseapi-stringfromiid

NB: The reason this code used sprintf() originally was that it came from a codebase which could not assume COM had been initialised. Can you always assume that CoInitialize() etc has been called in every app that uses HexCtrl?