Fixed by only processing text that's visible.
Also fixed the cursor jumping to breakpoint line when selected by
clicking the line number and added highlighting of the current editing
line. An optimization that caches the number of utf-8 chars in each line
was included as well.
Finally, an error that caused ImHex to crash if a pattern was saved as
itself was also fixed.
Reorganized source code into files named in the fashion of imhex and
split large functions into smaller ones. Moved all function definitions
out of the header except for one-liners. All variable types were
switched to use imHex standard (u8,...) and removed duplicated functions
that were needed when the text editor was isolated.
Minor improvements to find/replace while making sure they still worked
with utf-8 chars.
Also fixes two bugs:
1) error messages not staying visible
2) uncaught exception when struct name is duplicated.
A lot of the code using coordinates for start and end has been moved to
use Selections instead. Created more string manipulation code that uses
utf8 indices aka Coordinates directly. This makes implementing editing
functions easier by not having to go back and forth from string indices
to char indices and back. Currently, the substring, erase and []
operator support coordinates and str indices.
I noticed that an earlier fix was missing parenthesis, so I checked a
file of a big size and used a segment size of 1 and only 3 digits were
being displayed in spite of needing 6.
The scrollbar, mini map and the segment delimiters were also using the
incorrect bytes per row value when changing data size forced a change in
the number of bytes per row. From the definition of the new value it
follows that bytesPerRow/bytesPercell == m_bytesPerRow/bytesPerCell, so
it is not necessary to switch it when it is divided by that quantity.
The error was that if `m_bytesPerRow` was not divisible by the number of
bytes per column then ImHex would crash but wouldn't crash if it was.
When `m_bytesPerRow` is not equal to the resultant bytes per row
obtained by the product of column count and bytes per column, then the
later bytes per row were be allocated but the former bytes per row were
being written causing heap corruption and crashes.
Instead of resetting `m_bytePerRow` when it can't be used, a new
variable (`bytesPerRow`) is created with the correct value and used in
the rest of the function. This way if the user goes back to choose a
data size that divides the old `m_bytesPerRow` then the number would
still be available and not overwritten. Test indicate that this approach
works and previous crashes are eliminated while producing the desired
output.
allows the ability to assign colors to global placed and non-placed
variables, pattern, local and calculated pointer variables, template
arguments, function variables and arguments, etc etc etc. It
accomplishes this using the parser and the token sequence generated by
the lexer. It still uses the original colorizing code but the underlying
data holding the pattern has been updated to be easier to use and to
debug. The changes are too numerous to cite here.It is a big but
necessary step to bring the pattern editor to a somewhat useful state.
There may be one commit in the pattern language repo needed to be able
to run this code
Feature description
This pull request introduces full Polish language support to ImHex.
It is a new feature that allows users to switch the UI to Polish,
improving accessibility for Polish-speaking users.
Implementation description
-Translated a total of 10 JSON language files into Polish (pl_PL.json)
-All translations were done manually, with the help of tools such as
DeepL, large language models (LLMs), and technical dictionaries
-Validated the JSON files using [jsonlint.com](https://jsonlint.com/)
-Performed initial UI testing — all translated strings appear and render
correctly
Screenshots
Below is an example of the UI in Polish:
Additional things
-I'm a beginner with both ImHex and English, so I may have missed some
things
-I'm fully open to any suggestions or corrections — whether related to
translation accuracy or JSON formatting/style
-I would greatly appreciate it if the reviewer could:
-Confirm that the project still compiles correctly (it built fine on my
side using ninja)
-Check that the pl_PL.json files are properly formatted and follow the
project's standards
If there are preferred tools or workflows for validating and formatting
JSON in this repository, I’d be happy to adopt them in the future.
---------
Co-authored-by: paxcut <53811119+paxcut@users.noreply.github.com>
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
This is a fix for the ImHex bug "ImHex crashes when analysing any PE
file #2221"
### Implementation description
This is a fix for the ImHex bug "ImHex crashes when analysing any PE
file #2221". The fix requires changes to the Pattern Language and the
ImHex UI. Revision would be wise. We want to avoid collateral damage.
It's a big code base and I'm new to it and the compilers/build-systems
used. And the bug is complex and low-level. I suspect this will fix
other random crashes. The problem is caused by two issues:
- The std::sort algorithm conjuring up garbage due to the sorting
criteria not being a strict weak ordering. See
[this](https://github.com/Voultapher/sort-research-rs/blob/main/writeup/sort_safety/text.md)
link.
- We sort shared_ptr<ptrn::Pattern> by pointer value, and the
object is a clone. In essence we're changing the values as we're
sorting.
Fixes#2221
### IMPORTANT
I'm not sure how "plugins/builtin/source/content/data_formatters.cpp"
got into the PR. Been trying for an hour to rectify. I'm not a Git
expert (the last time I used source control seriously SourceSafe was a
thing) please ignore that file. It's a fix for another PR I submitted. I
suspect I stuffed up the branching and merging.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
The implementation of subpixel rendering using draw call lists with
callbacks prevents call list merging and their associated clip rects in
tables. As a result clip rects become as narrow as the columns of the
table which can clip previously renderable primitives. The hex editor
has several draw calls that render outside their column so if subpixel
rendering is selected those primitives cease to be displayed.
To fix this issue, and to verify that this was indeed the cause behind
the issue, we simply push an adequately sized clip rect before the draw
call command and pop it right after.
A problem with segment vertical separators not being rendered in the
first tow was also fixed.
