locked
How to support going to line from output pane in custom editor RRS feed

  • Question

  • I have a custom editor that hosts the core editor.  Another part of my package writes messages to the output pane in the format such that they will be treated as warnings/errors (http://blogs.msdn.com/b/msbuild/archive/2006/11/03/msbuild-visual-studio-aware-error-messages-and-message-formats.aspx).

    If a document is open in my editor and I double-click on one of these lines in the output window, I would get a message that says "The document '[file name]' is already open.  Do you want to close it?"  If I click No, nothing would happen.  If I click Yes, my editor is closed and the document is re-opened in the standard error.

    I found that this was because I needed to register my editor to specify that it provides LOGVIEWID_TextView logical view and return S_OK for this logical view in the editor factory MapLogicalView implementation.

    However now when I double-click the messages in the output window, nothing happens and a message in the status bar says "The system can not find the file specified."  What else am I missing?

    Monday, August 1, 2011 4:31 PM

Answers

  • It seems we want whatever comes back from your VSFPROPID_DocView (which is your EditorPane in your example you sent) to implement IVsCodeWindow.  I implemented it on your sample and just thunked all calls through to the internal CodeWindow property you already had and it all appears to work now.

    Ryan

    Thursday, September 1, 2011 11:41 PM

All replies

  • Hello ,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Thank you for your understanding and support.

    Yi


    Yi Feng Li [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, August 2, 2011 2:24 PM
  • Hi Yi, any news on this issue?  Thanks.

    Tuesday, August 30, 2011 5:16 PM
  • It looks like the navigation code will end up calling IVsUIShellOpenDocument::OpenDocumentViaProject passing in LOGVIEWID_TextView.  That in turn will enumerate all the open document windows to see if the document is already open.  It does this via getting the VSFPROPID_DocCookie from each frame, asking the running document table if the file name it is looking for matches this frame's file name.  If so it then retrieves the VSFROPID_guidEditorType and calls MapLogicalView on that trying to map from that to LOGVIEWID_TextView (if necessary).  If that succeeds it then gets the VSFPROPID_pszPhysicalView and compares it to the physical view string returned from the call to MapLogicalView.  If that succeeds then it considers that frame to be the document it needs to navigate to.  If this fails for all open windows it will then open the document via the owning project (or the misc files project if the file doesn't belong to any project in the solution).  It does this by calling IVsProject::OpenItem passing in the LOGVIEWID_Text.

    It seems like if your file is already open the most likely failure point is the mismatch between VSFPROPID_pszPhysicalView and the string you return from MapLogicalView.  Otherwise it seems that the call to OpenItem is failing.  When it complains it can't find the file does it show any information about what file it is looking for?  Perhaps it has misparsed the line from the output window?  I assume it is in the 'standard' format?

    Ryan

    Tuesday, August 30, 2011 7:51 PM
  • Hi Ryan, thank you for your detailed response, it's interesting to see what the steps are behind the scenes.  I tried to verify each step, here's what I did:
    I opened my document and then got the cookie and path from the RDT.  I then got VSFPROPID_DocCookie and VSFPROPID_pszMkDocument from the document's frame and compared the values to what was in the RDT, they were the same.
    Next I checked VSFPROPID_guidEditorType on my frame, it was the guid for my editor factory.  My editor factory returns null for pbstrPhysicalView when the logical view is LOGVIEWID_Primary or LOGVIEWID_TextView.  I checked VSFPROPID_pszPhysicalView on my frame, it was null.
    I set a breakpoint in MapLogicalView and double-clicked on the line in the output window, the breakpoint in MapLogicalView was not hit.  In Visual Studio 2010, I get a message that says "The document '[path]' is already open.  Do you want to close it?"  If I click No, I get the same prompt again.  In this second prompt, if I click No again nothing happens, if I click Yes my editor is closed and the document is re-opened in the core editor.  If I click Yes in the original prompt, same behavior, it's closed and re-opened in the core editor.
    If I follow the same steps in Visual Studio 2008, I do not get the prompt, instead if keeps my editor open but also opens the document in the core editor, so the document is opened twice.  What's interesting though is that the blue glyph in the editor trough showing the output window message is shown in both editors.  The output window message is in the standard format.
    Any other ideas?  Is there possibly an interface that I'm missing on the window pane implementation for my editor?
    Wednesday, August 31, 2011 4:01 PM
  • If it is not calling MapLogicalView it seems one of two things are happening

    1:  It doesn't think the filename from the output window line and the file name associated with the already opened fram match.

    2:  It is not finding your editor factory when it tries tolocate it using the GUID from VSFPROPID_guidEditorType.


    Since you said the guidEditorType IS your editor factory I don't think 2 is the problem.  That leaves #1.  It tries to determine this by calling an internal method on the running document table called FilenameMatches passing in your doc cookie and the line from the output window.  When you are creating your info in the RDT you aren't passing in RDT_CaseSensitive are you?  If so it may be a problem with the casing between the info in the RDT and the line from the output window.  If not...I don't know why this would fail.

    Instead of me trying to continue guessing it may be easiest if you could zip up a complete repro that I could (easily) apply to 2010 and repro the problem so I could debug into what step of the process was failing to recognize the already opened document as being a valid 'target' of the navigation.

    Ryan

    Wednesday, August 31, 2011 5:31 PM
  • Ok thanks, I will work on a repro.

    One thing I did notice is that I accidentally had my [ProvideEditorLogicalView] attribute (specifically for EnvDTE.Constants.vsViewKindTextView) commented out on my package.  Once I uncommented that I did start getting MapLogicalView calls (twice actually).  I no longer get the "The document '[path]' is already open.  Do you want to close it?" messages, now I instead get "The system can not find the file specified" in the status bar.

    "When you are creating your info in the RDT you aren't passing in RDT_CaseSensitive are you?"
    I'm not sure what you mean by this, where would I explicitly create my info in the RDT?  It seems the info ends up in the RDT some other way.  Maybe this is related to what I'm missing?
    Wednesday, August 31, 2011 9:28 PM
  • Hi Ryan, I have a repro project but I'm not seeing a way to attach or upload via the forums.  What would be the best way to get the project to you?  Thanks.
    Thursday, September 1, 2011 8:40 PM
  • You can mail it to me (rmolden AT <company name here>.com), with company name here obviously replaced with Microsoft (trying to avoid spam harvesting bots :)). 

    Include the zipped project and any instructions I would need (like open project in VS, F5 to run, then open specific document type or use Open With Specific Editor to choose editor 'X' (where X is your editor), and then cause some output window lines (say from a build errors?) and try to navigate to them from the output window).

    Ryan

    Thursday, September 1, 2011 9:00 PM
  • Just emailed the zipped project and instructions.  Thanks!
    Thursday, September 1, 2011 9:17 PM
  • It seems we want whatever comes back from your VSFPROPID_DocView (which is your EditorPane in your example you sent) to implement IVsCodeWindow.  I implemented it on your sample and just thunked all calls through to the internal CodeWindow property you already had and it all appears to work now.

    Ryan

    Thursday, September 1, 2011 11:41 PM
  • That did the trick, thanks a lot!
    Friday, September 2, 2011 4:22 PM