In my VS add-in, I need to handle key presses (presumably via PreTranslateAccelerator()) before Visual Studio does. Unfortunately, after digging in Shell.Interop, I can't find the location where I would be able to handle them. Can anyone help?
In my project, I use IOleCommandTarget interface to intercept key press in visual studio. There is a method named "QueryStatus" after you implement the IOleCommandTarget. I think you can use this method to handle keypress before visual studio does. You can also decide whether transfer msg chain to VS. I found this article that may help you.http://www.ngedit.com/a_intercept_keys_visual_studio_text_editor.html
Related
Can I create an extension for Visual Studio that runs in the background as soon as the user opens the Visual Studio IDE? For example, I am building an extension that gets the current active file address in Visual Studio (with C#), but I would like this extension to always run in the background without having to be activated by the user clicking a button or pressing some key combination.
Is this possible, and if so, what is the best way of doing it?
Any help would be greatly appreciated! Regards, Erfan
Since you tagged your question with visual-studio-2010 I assume you are working on an "Add-in" rather than a "VSPackage Extensions".
In this case, you can use the OnConnection event handler.
If you are working on a VSPackage Extensions, you can use the attribute ProvideAutoLoad.
Just search for these, you will find sufficient information. Both ways are also described shortly here under "How can I run my add-in code in a VSPackage?"
For Extension add following attribute to Package class, this will load the extension when a solution is not open in visual studio. I have tested this with VS 2015 and 2017.
[ProvideAutoLoad(UIContextGuids80.NoSolution)]
For VS 2010 and higher the recommended extensibility approach is a package (VS 2015 won't allow add-ins).
To get the package loaded when Visual Studio is loaded see HOWTO: Autoload a Visual Studio package.
Once loaded, your package may be interested in two different kind of selection change events:
To get notified when the selection in the Solution Explorer changes, get the IVsMonitorSelection interface and call the AdviseSelectionEvents/UnadviseSelectionEvents and provide a class that implements the IVsSelectionEvents interface.
To get notified when the active window changes (which can be a document window or a toolwindow), implement the IVsWindowFrameNotify interface.
I want to write an Editor extension for Visual Studio 2010.
In my extension I want to get information about the Class, method which is at the current caret position.
For example, if I am in an Event Handler and I have some code that shows a MessageBox using MessageBox.show(…) and the caret is at .Show,
I want to query VS Services to get a response which tell me that I the caret is at Show method of MessageBox class which is in System.Windows.Froms.dll version 4.0.40319 etc.
Is it possible?
There is no way to do this with the current APIs in Visual Studio 2010. This is why we're building the Roslyn APIs so you could. When you install the CTP, we setup a Roslyn instance that replaces the standard language services with the Roslyn ones, and you can ask your question directly to it.
If you don't want to be dependent upon running in the Roslyn instance (which I assume is the case), then it gets a bit trickier. You can invoke the parsers to understand you're on a call named MessageBox.Show, but to get the semantics you'd have build up a Compilation making sure you get all the project references and source files right. That's a far trickier proposition, so depending on your scenario you might want to "cheat" as much as possible.
Disclosure: I'm on the Roslyn team.
I want to extend the extension manager in Visual Studio 2010. I'd rather know if that is at all possible before I get into it, but am unable to find anything about it.
All the extensibility options I've read about mention nothing about being able to actually change the function of an existing VS2010 tool like the extension manager.
I'd appreciate any relevant links.
There are no supported interfaces for extending the Extension Manager in Visual Studio 2010.
What specifically did you have in mind though? Perhaps there's some other way you can accomplish what you're trying to do...
I'm writing a Visual Studio add-in using C/C++. I am not familiar with the COM architecture. In fact I'm learning Windows programming.
I can see an OnDisconnect() call back into my add-in. I tried returning S_FALSE, but that does not seem to stop the add-in from being unloaded.
So my questions is, is it possible to make an add-in that cannot be unloaded (either through the Tools menu or programatically), and if yes, will some magic return value from OnDisconnect() do the job, or some other trick is required?
I also saw another question that asks exactly the opposite. From the answer, it seems that the DLL still resides in the memory when an add-in is unloaded. So maybe there is a way to reload the add-in as soon as it is unloaded?
I don't know of any way to do this. If you really need functionalty that cannot be unloaded while VS is running, you should write a package instead of an add-in.
I would like to control options on the debugger without using the debugging GUI's, preferably from inside the code being debugged. I would think that would be quite difficult, but maybe my debugged code can request a service from independent code that will communicate with the debugger.
This relates to another question of mine on controlling when to break on exceptions.
You can write Visual Studio macros that can do anything the GUI can, but they can get rather involved. See the MSDN documentation on Automation and Extensibility for Visual Studio
Doing this from the code being debugged would be tricky, you would definitely need some new form of communication with VS, maybe a custom add-in. I don't think an independent service would fundamentally help here. The biggest problem is that your code will stop running when the debugger breaks.
I know that you can do it with WinDBG and OutputDebugString, but for Visual Studio, I think you have to spool off another process, pipe commands to that, and have that manipulate the Debugger API.