You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is possible to have multiple debug sessions running simultaneously, and it is likely desirable to connect a given memory inspector instance to a given session to ensure that updates from one session don't affect a view showing memory from another session.
The text was updated successfully, but these errors were encountered:
That is a very good point! Currently each memory inspector is always in the context of the active debug session, so I'm just wondering what the best option is to determine that. Should the session be determined based on the time the inspector is opened or should it be a deliberate user action to lock the view to a particular session which can later also be unlocked? I feel like giving the user more control over this is probably the best way to go forward. If we do so, we really need to think about a good UX concept for all the options because we now have a lot of display options for which the user already needs to scroll sometimes and then we have the label editing, the freezing to avoid updates, the new lock to avoid updates from other sessions, etc.
It is possible to have multiple debug sessions running simultaneously, and it is likely desirable to connect a given memory inspector instance to a given session to ensure that updates from one session don't affect a view showing memory from another session.
The text was updated successfully, but these errors were encountered: