If I make address column too small and then close edb and then open it again, I get disassembly view that looks like this:
If I trace the values of l1, l2, l3, l4 in DrawingContext I will get something like this: (165 380 231 1194), while before reopening it was (165 190 223 11940). As I found out the line2_ loaded correctly in QDisassemblyView::restoreState and then is reset to 0 in QDisassemblyView::setRegion.
You might compare it with this commit 8f2c83137a4432a948778c8d9b5c6bf6ed905e57. :-)
Now the question is what is the proper way of fixing the problem. One might argue that writing line2 without updating line3 and line4_ breaks class invariants. And updating them too would fix the visual glitch, but I would say that resetting column widths set by user is not a good behavior.
To fix the visual glitch, but also to address #492, I would like to suggest having different column width settings for 32 and for 64 bit modes.
---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/89001704-address-and-instruction-bytes-column-overlap-after-reopening?utm_campaign=plugin&utm_content=tracker%2F14326212&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F14326212&utm_medium=issues&utm_source=github).
If I make address column too small and then close edb and then open it again, I get disassembly view that looks like this:
If I trace the values of l1, l2, l3, l4 in DrawingContext I will get something like this: (165 380 231 1194), while before reopening it was (165 190 223 11940). As I found out the line2_ loaded correctly in QDisassemblyView::restoreState and then is reset to 0 in QDisassemblyView::setRegion.
At first my diff to fix the problem was:
You might compare it with this commit 8f2c83137a4432a948778c8d9b5c6bf6ed905e57. :-)
Now the question is what is the proper way of fixing the problem. One might argue that writing line2 without updating line3 and line4_ breaks class invariants. And updating them too would fix the visual glitch, but I would say that resetting column widths set by user is not a good behavior.
To fix the visual glitch, but also to address #492, I would like to suggest having different column width settings for 32 and for 64 bit modes.