While investigating the UX for BackgroundAnalysisScope.ActiveFile analysis mode, I ran into an issue in VisualStudioActiveDocumentTracker that causes it to intermittently end up with no active document while switching document tabs, i.e. TryGetActiveDocumentId returns null even when you are editing a source document. The root cause seems to be in the below code:
|
int IVsSelectionEvents.OnElementValueChanged([ComAliasName("Microsoft.VisualStudio.Shell.Interop.VSSELELEMID")] uint elementid, object varValueOld, object varValueNew) |
|
{ |
|
AssertIsForeground(); |
|
|
|
if (elementid == (uint)VSConstants.VSSELELEMID.SEID_DocumentFrame) |
|
{ |
|
// Remember the newly activated frame so it can be read from another thread. |
|
|
|
if (varValueNew is IVsWindowFrame frame) |
|
{ |
|
TrackNewActiveWindowFrame(frame); |
|
} |
|
} |
|
|
|
return VSConstants.S_OK; |
|
} |
We currently handle SEID_DocumentFrame. However, sometimes we receive this callback with VSSELELEMID.SEID_WindowFrame instead of VSSELELEMID.SEID_DocumentFrame, such that the underlying frame type is still WINDOWFRAMETYPE_Document indicating it is a document being activated. I verified that handling this element ID and adding the check for frame type resolves this issue. I'll create a PR with this fix for review.
While investigating the UX for
BackgroundAnalysisScope.ActiveFileanalysis mode, I ran into an issue inVisualStudioActiveDocumentTrackerthat causes it to intermittently end up with no active document while switching document tabs, i.e.TryGetActiveDocumentIdreturnsnulleven when you are editing a source document. The root cause seems to be in the below code:roslyn/src/VisualStudio/Core/Def/Implementation/Workspace/VisualStudioActiveDocumentTracker.cs
Lines 175 to 190 in 16c658a
We currently handle
SEID_DocumentFrame. However, sometimes we receive this callback withVSSELELEMID.SEID_WindowFrameinstead ofVSSELELEMID.SEID_DocumentFrame, such that the underlying frame type is stillWINDOWFRAMETYPE_Documentindicating it is a document being activated. I verified that handling this element ID and adding the check for frame type resolves this issue. I'll create a PR with this fix for review.