Making the Code Definition Window Editable

I'd like to get your feedback on a design change that we are implementing for the Beta 2 release of VS 2005.  In Beta 1, we introduced the Code Definition Window for the C#, J# and VC languages.  The current view is a read-only view of the definition of the current symbol that is selected in the Editor, Object Browser or Class View. 

In the Beta release there were several known issues with the read-only model which can be fixed by making the Code Definition Window editable.  This change would mean that the Code Definition Window would behave as an editor on the file where the definition is located.  If the file itself is read-only or is under source control, we would respect the same options that apply in the Text Editor.  If the user makes a change to a file in the Code Definition Window and it is open in the editor, the editor will be updated simulataneously. 

The difficult part is when the code definition window tries to navigate away from a file that has been modified but isn't open in an editor.  What is this expected behaviour? Should we save the changes, should we open the document or should we not allow the Code Definition Window to navigate to the next file.  My goal is to make users aware of what happens in this situation without constantly annoying them.  My proposal is that we would show a message box when this occurs that says something like:

The file in the code definition window has not been saved.  Do you wish to save these changes or open the file in an Editor?
[Open in Editor] [Save Changes] [Discard Changes]
[x] Always perform the selected action.

My hope is that users will always want modified files to be opened for editing and they will select to always perform that action. 

I'd really appreciate your feedback on this proposed change.


Comments (13)

  1. drebin says:

    I’m just some regular jerk off the street, but that window didn’t really do what I thought.

    I guess I was hoping that, that window would be like JUST that chunk of code for the definition – because as I would type, I’d see that window scroll and it takes my eyes a minute to find the actual code. And having the code in question be the VERY top line is… "uncomfortable" I guess the word is? Because my first reaction is to scroll up a bit and see if there is anything above it.. that’s sort of a human nature thing.

    Or – it would be cool if that window didn’t "autonavigate" and I could use it kind of the way the "splitter" in the current code window works.. where I want to look at one thing, and type in something in a different place..

    Point is, that window makes things a little confusing for me – I’m not sure what the point was. But I will say, it is continues to be read-only, it should be greyed out a bit or transparent or something, because the "Read-Only" at the top didn’t catch my eye right away.

    But what you proposed, if it’s not read-only, sounds fine.. But for me, I didn’t find much value in this feature – sorry.

  2. Why wouldn’t you just always auto-open any file in editor as soon as its loaded into the code def window? That way this will never be an issue.

  3. Drebin: I don’t want to distract from Sean’s post, so I was wondering if you’d do me a favor.

    On there’s a contact link. Could you go there and contact me. I’d like to talk to you more about your issues with the code definition window and how you’d like to see it working. Thanks!

  4. AndrewSeven says:

    I like the auto open of the actual code file, but I would suggest only doing it when the code is edited.

    One issue I have with the "Always perform the selected action" is that I don’t always know the current state of the option and I never know when I am helping annother dev.

    Instead of always waiting for the user to do something, the title bar could communicate its state/beehavior using it’s caption: ReadOnly | Editable | Auto Checkout on Edit | Must checkout to edit.

    I would think that it would show only the code of the definition, not just be annother editor for the whole class.

  5. Josh says:

    Do not make the Code Definition Window editable. That would be too confusing… why not just have split windows at that point?

    Keep the CDW focused on what it was meant to do – provide definition of your code in context.

    I do like Cyrus’s suggestions for enhancement (stack based navigation). If you want to edit the code in the definition window, allow the user to easily pop that section into your editor – don’t edit in the sub-window.

  6. I also like Cyrus’s idea. But you’ve already got forward and back buttons. They’re the ones that are aliased to ctrl-minus and ctrl-plus in VS 2003. If you go back to your last location in the edit window, the CDV will show its definition, which should be the last item that it displayed.

    Also, I’d put the file name somewhere in the CDV. And I don’t like those little tiny + and – signs for expand and contract outline. And I would highlight the part of the code that’s actually the definition. Something fairly subtle though, perhaps a bold font.

  7. David: I like your suggestion, and we’re playing around with different ideas. Personally I think adding a slight highlight to the background color might work pretty well to show off the definition.

  8. Alex says:

    I really didlike message boxes for things like this, perhaps something less intrusive, such as opening the edited document into the main editing pane as soon as the definition window tries to navigate away on an edited document. A animated flyout might make that process clearer. Though I imagine that quite a few people would like the definition’s window to create tabs for new code views.

    Thinking about multiple views on one view does anybody else find the output window dropdown irritating?

  9. Alex says:

    If only you could edit blog comments – ‘didlike’ should actually read ‘don’t like’.

    Also I don’t think I was very clear on what I mean by the Output window dropdown being irritating. Basicallly I often use external tools in VS that use the output window (think FXCop, permcalc etc…), but it’s irritating to have to go through the dropdown everytime I build or refactor something, as I can’t see what outputs are available at a glance. I’d like to be able to view all availabe outputs and easily close those that are no longer relevant.

  10. Daniel Moth says:

    Instead of considering enhancements to the Code Definitions Window, why not offer the feature to VB as well?

  11. Sean Laberee says:

    The reason that we have been investigating making the window editable is that we have a set of bugs that are more efficiently fixed by making the window editable.

    If you want the CDW for VB, you should log a suggestion on MSDN Product Feedback. It is unlikely that the VB team will have time to add this for Whidbey but the feedback will help them prioritize this for the next release.



Skip to main content