Open MariaSolOs opened 2 years ago
What's your reason for needing to get an output pane by its name? The reason I ask is that I'm concerned about what would happen when running Visual Studio in a different language. If you're extension is using the name of the output window instead of the GUID, then your extension is unlikely to work for users who use Visual Studio in a different language.
@reduckted so maybe my case is a bit of a niche scenario: I'm developing an LSP extension and the window\logMessage
notification causes an output pane to be created with the client's name. Because the pane creation is performed by the base language server code and not the language client that I'm implementing, I don't have access to the pane's GUID. All that I know is that the output pane has the client's name as its title.
I now want to use this pane to output other messages, while preserving the ones from the protocol's notifications.
Ah, OK, that makes sense. 👍
I just had a look through the Visual Studio assemblies with ILSpy, and the Microsoft.VisualStudio.LanguageServer.Client.Implementation.dll
assembly (under IDE/CommonExtensions/Microsoft/LanguageServer/
) looks like it creates an output window. I don't know if it's the same one that you're trying to find, but you could use this GUID to see if it is:
new Guid("{34E76E81-EE4A-11D0-AE2E-00A0C90FFFC3}")
@reduckted Good try, but I'm afraid that I'm sure that that GUID isn't fixed (else all language clients would share the same output pane).
Ah yes, that's the GUID for the actual output window, rather than the pane. 🤦♂️
Looking at the code further, it's generating a new GUID for the output pane, which means the only option would be to get the pane by name as you originally intended.
Currently the only way to get an existing output pane is via its GUID. However, in some scenarios the GUID might be unknown to the caller or just storing the pane's name might be best.
Note that the
DTE2
interface offers a service to get an output pane from its title, but the toolkit must not use theDTE
internally to avoid backwards compatibility with 32/64-bit versions.