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?