#3280: Selection shifts when MemoryMap is updated

[foralost]

Restoring the selection after the MMap is updated by holding the no. of row which was selected earlier.

brave.exe.-.PID_.14892.-.Module_.chrome_elf.dll.-.Thread_.7908.-.x64dbg.2023-12-17.11-10-38.mp4

Closes #3280 .

[AppVeyorBot]

✅ Download x64dbg 1.0.1837 (commit 203a6a2b29 by @foralost)

[mrexodia]

Hm, I think it would be better to select based on the “closest” address since most likely the number of rows updates in an application with high memory pressure… I’ll take a look when I’m back home!

[foralost]

Hm, Im thinking about some delta like oldAdresses - currAddress, but im wondering what if there are multiple entries which are 'equally' distant?

... or maybe something more sophisticated

[mrexodia]

How about storing the currently-selected base+size and selecting the region that overlaps (or is just before) the previous range?

[mrexodia]

I don't think it's necessary to delay setting the selection and storing the state. You can directly call setSingleSelection here to simplify everything. Also the variable name is no longer accurate, it should be something like prevSelectedBase

[foralost]

the reloadData function below caused some problems with setSingleSelection (it was jumping around like crazy)

[foralost]

How about storing the currently-selected base+size and selecting the region that overlaps (or is just before) the previous range?

Ok, soooooo we would be interested in selecting only the region based on selected address?
Like:
User clicks address -> We find the base address & size -> We store them -> We select the whole region (base address + sections and stuff)

*** the memory updates ***
aaand tbh what now?

We look at the old base address -> We fetch its new base address & size -> We find the intersection (common range/addresses) -> We select now the intersected range?

[mrexodia]

It could be something like this:

void updateMemoryMap():
  oldStart = getCellUserdata(firstSelectedRow, ColAddress)
  oldEnd = getCellUserdata(lastSelectedRow, ColAddress) + getCellUserdata(lastSelectedRow, ColSize)

  firstSelectedRow = 0, lastSelectedRow = 0
  for(const region : memoryMap)
    if region.base < oldStart:
      firstSelectedRow++
    if region.base < oldEnd:
      lastSelectedRow++

    setCellContent(...)

  setSelection(firstSelectedRow, lastSelectedRow)

Since regions (lines) in the memory map never overlap each other there will be a few possibilities:

• We just find a region where region.base == oldStart
• The region was split, we will select the first region that overlaps with the old selection
• The region was freed, we will select the first region before the oldselection

The problem starts when multiple regions are selected, the algorithm for selecting the first region will work fine in this case but the part with lastSelectedRow is just made up and need experimentation...

Another issue will be with the sorting, in that case there isn't much we can do except find the first selected region and then just expanding the selection down with the same amount as initially.

[foralost]

Ok, will try to work on it this weekend ;)

[foralost]

Ok so as I have understood, instead of selection of specific table lines (addresses), we should always think about selectiong a region/span of addresses (including sizes).

This selection would indicate a range of addresses 000002BB03090000 - 00007DF433EA0000 + its size (both inclusive).

Whatever pop ups in this range of newly updated memoryview, should be also selected (cause its within range).

When something drops out select range (inside of it) we just don't select it in the newly outputted memory view (its line would be also gone). The selection stays as is.

When the beginning/ending line is dropped, then we should select a line which address + size overlaps with the old start/end, in the UI being it probably an upper/below line.

There is no possibility to select multiple regions in x64dbg, so I think its ok.
Hello from the dead ;)