Hello,
I have reviewed the whole forum, but had no luck in finding an answer.
I have a custom editor that I developed, which hosts the core editor and extends it. It is associated with the "*" extension, so it works great with all text files. I can configure the editor as the "default editor", and when I open a file or double-click it on the solution, the environment launches my editor. Great!
The problem areas are debugging and going to errors in the output window.
When stepping through the code, debugging works great within my editor. It even jumps to other Doc/Views of modules opened in my editor. But if the debugger needs to open a new module, it uses the default standard editor instead of mine :(
The second area is worse. When compiling, if I double click on an error in the output window, or press F4 to get to the next error, the environment opens the module in the standard editor - EVEN IF the document is already open with my editor!
I will be very grateful for any help.
I'm using unmanaged C++, the project is large and almost finished, and this is the last blocking wall I've stumbled upon. I hope there is some clean & nice solution, else I will have to resort to some ugly message hook or subclassing the output window which I'd much rather not :(
TIA,
J
PS: I will be porting to VS 2005 some time in the future, so pointers for how to do it there can be of some use even if I need to do "the dirty thing" with VS 2003 :(

How to make VS.NET 2003 open .cpp with my custom editor
Davidmanchester
i'm not realy sure about this, since i'm both new to VSIP and i'm developing my extension for VS 2005, so it might be diffrent in VS 2003.
and it's in C# as well.
any way there is a method called ::MapLogicalView(ref Guid rguidLogicalView, out string pbstrPhysicalView) on the editor factory, which asks if your editor supports a specific logical view (a logical view being a code editor, debug editor, designer, etc..)
what you need to do, is return S_OK from this method when rguidLogicalView is equal to the GUID for the logical debug editor.
in the manegd framework its stored in VSConstants.LOGVIEWID_Debugging , i'm sure you can easily find the constant or define that holds the GUID in the unmanged framwork.
if (VSConstants.LOGVIEWID_Debugging == rguidLogicalView)
return VSConstants.S_OK;
hope this helps.
uszaty1973
"pszPhysicalView
[in] String to identify the physical view type for the editor. Some editor factories can support creating multiple physical view types. For example, it is possible for a single editor factory to support creating a graphical designer view (LOGVIEWID_Designer) as well as a textual code view (LOGVIEWID_Code). The editor factory must register information in the system registry for the mapping between logical and physical view types under the
LogicalViewMapregistry subkey."So, the environment's open function first checks in the registry, and if the logview is there, then the factory is called, else, it isn't. Makes sense.
That is, I had to add some entries in my package's registry LogicalViewMap. I copied the values from the "Source Code (Text) Editor" key, which if looked up in vsshell.h, are:
LOGVIEWID_Debugging
LOGVIEWID_Code
LOGVIEWID_TextView
And off we go! It is working like a breeze! and I'm incredibly happy!!
Lasse Steenberg
When I double click on a file in the project/solution window, my factory's MapLogicalView() gets called, I return S_OK, and then my editor is opened. That's great.
But when I double click on a compiler error in the output window, my MapLogicalView() doesn't even get called. Same happens when I step through the code or Right-click in the assembly window and choose "Go to source".
I'm starting to think that the behavior is hardwired in the output window and the debugger. They don't seem to call the project to try to open the document. Or, they call the project and the project has some kind of hardwiring different from what is done when double-clicking a file.
I haven't found any SetDefaultEdFactoryGUID() anywhere - actually, my editor is already set as default (by the user, which is the proper way to do it).
I have to solve this, so I'm starting to prepare a list of possible ways to do it. In increasing level of nastiness:
- Provide a hotkey for the user to map in order to do the switch from the std editor to the custom editor. The most cumbersome for the user, but no too-dirty stuff.
- Hook WindowEvents.OnWindowCreated(), check whether it's one file our custom editor is interested on, if so, use IVsUIShellOpenDocument::OpenSpecificEditor() or something similar. Will probably have to do with some delay via a WM_TIMER or so, so that we won't interfere too much. The problem is that the standard editor would be short-circuited out and would not be usable any more :(
- Subclass the Output window, get the double clicks, and handle them ourselves - getting the line under the cursor would be difficult, but possible - or we can hook to the system and see what window gets opened/brought on top. I would also have to supply alternate implementations of GoToNextError/GoToPrevError for the user to map to his/her shortcut keys.
Debugging is not so bad, as if the document is already open with my editor, that window is used - so keeping everything open makes it usable. But the Output window stuff is the worst.
Thanks for your help and leading me down an interesting research path, if unfruitful.