How to make register window settings more persistent? lazarus / 12-Debugger ---------------------------------------------------------------------- ccrause · 2020-01-26 12:30 I am getting a bit frustrated with having to change the display setting of the register window to hex every time the values are updated. Digging through the IDE logic (TRegistersDlg, TCurrentIDERegisters and so forth) suggest the following situation: The register list used to store register names, values and display settings get created and freed at the drop of a hat, so to speak.  Or more technically, a few debugger state changes calls CurrentRegisterList.Clear, which frees the current register lists and the associated states.  New instances are created on demand.  Hence the problem with persistence of display settings in a debug session. My current attempt at fixing the persistence of register display settings is to replace the Clear method with TRegistersList.Invalidate, which sets the DataValididty state to dssUnknown.  Although this does not free the old entries, the complex behaviour of TCurrentIDERegisters.Count result in the creation of new register items.  I've simplified this to always return the real count of items and to request new data if the state is ddsUnknown (since other code seem to rely on this behaviour of Count). At the moment this approach result in persistence of display settings during a debug session (for a single threaded test), but the register view is not cleared when debugging is stopped. Can anyone knowledgeable about the internal workings of this IDE functionality comment on whether this is a sensible approach, or am I heading in a direction that will eventually end in many complications? ---------------------------------------------------------------------- Martin_fr · 2020-01-26 15:05 There already is a bugreport about this. IIRC - but its a while since I took a look - the problem is in the debugger backend, where the register list is cleared and recreated. Probably somewhere in the DebuggerState changed code. ---------------------------------------------------------------------- ccrause · 2020-01-26 16:18 At the moment the changes seem to work as intended, tested with fpdebug, gdb and fpdebug+gdb. Changes can be viewed in this github branch. ---------------------------------------------------------------------- ccrause · 2020-01-26 19:36 Quote from: Martin_fr on January 26, 2020, 04:05:05 pmThere already is a bugreport about this. I think I'll move the discussion to the mentioned bug report ---------------------------------------------------------------------- Martin_fr · 2020-01-26 20:23 I applied the patch. Big thanks Other data suppliers have a separate CountValidState.  But that would not have helped, if it becomes invalid too. And from review, I think at least gdbmi code would update the name list, if needed. ------------------- I assume your tests where *nix? I tested under Win, and noted (unrelated) that the TListView flickers like hell, if BeginUpdate is used. I disabled that for Win.... Any such thing under *nix? ---------------------------------------------------------------------- ccrause · 2020-01-27 05:00 Quote from: Martin_fr on January 26, 2020, 09:23:08 pmI applied the patch. Big thanks Other data suppliers have a separate CountValidState.  But that would not have helped, if it becomes invalid too. And from review, I think at least gdbmi code would update the name list, if needed. ------------------- I assume your tests where *nix? I tested under Win, and noted (unrelated) that the TListView flickers like hell, if BeginUpdate is used. I disabled that for Win.... Any such thing under *nix? Yes, I tested this only in LInux where I didn't notice flickering. Perhaps the complex Count method was previously used to limit the update frequency of the listview? ---------------------------------------------------------------------- Martin_fr · 2020-01-27 13:56 It seems that BeginUpdate on windows sets a "no paint" flag. But then the listbox still clears (paints all which / EraseBackground??). Since there are some "no change" updates, the above leads to flicker. IMHO an issue in TListBox.