Wiki Link: [discussion:123]
Call Hierarchy 
Tags: Call Hierarchy, C#, Visual Basic

Coordinator
Mar 6 2008 at 9:14 AM
Edited Mar 6 2008 at 9:14 AM
Please enter your comments on the Call Hieararchy feature here.

Mar 7 2008 at 3:49 AM
Edited Mar 7 2008 at 7:42 AM
I really see a lot of value in this feature. I don't know how it should pan out, but it makes sense to me to have accessibility to both options presented. For example, when debugging, you can highlight a variable and follow through its inheritance all of the fields associated with an object. Sometimes that gets irritating to use with large objects. With larger objects, I always opt for the quickwatch so that i can drill down without worrying about the mouse focus making the fields disappear.

This seems to be a similar scenario where it might be nice to have the quick popup for a brief reference, but larger call hierarchies could be brought up in a dialog and explored further if need be.

Just my .02.

Mar 7 2008 at 3:49 AM
Edited Mar 7 2008 at 3:50 AM
/edit

It double posted my entry.

Mar 7 2008 at 7:25 AM
One more post, What if we've got control structure in the celler method like this:
if (someCon)
methodA();
else
methodB();

and what if we look in hierarchy of recursion, factorial for example?

Coordinator
Mar 7 2008 at 8:44 AM
Brian. Thanks for providing some feedback. I'll watch out for that double posting. Hopefully it won't happen regularly.

- Charlie

Mar 7 2008 at 10:16 AM
This feature is great!, however, personally I think It woud be better if it's represent in the form of chart, just like WorkFlow.That will give more considerable understanding the code path.

Mar 7 2008 at 11:40 AM
I know it will be a useful feature - because it's been useful in other IDEs :) (Seriously, I have no problem whatsoever with the VS team implementing good features from other IDEs - especially if the VS implementation ends up being the best available!)

The sample presentation shown seems okay - and I particularly like the preview area, and the fact that both the callers and callees are displayed at the same time.

The idea of an "inline" view is a nice one, but a couple of comments about the more in-depth view:

1) Please don't make it a dialog - make it a window which can be docked like Find Results etc. It's often useful to look at all call references, making changes to them as you go. A dialog would get in the way of the flow here.

2) Please allow a shortcut key to invoke the in-depth call hierarchy as well. I'd personally suggest CtrlAltH for the sake of familiarity for those who already use the feature in other environments...

3) Implement a splitter between the preview and the trees

4) Perhaps allow a more vertical orientation with the preview beneath the trees for those who wish to work that way. (I wouldn't use it myself, but others might. Worth considering at least.)

As for removing Find All References - no, they serve slightly different purposes. For one thing, I wouldn't expect Call Hierarchy to work for fields - but I'd like Find All References expanded to allow "show writes to field" and "show reads from field".

Hope that helps.

Mar 7 2008 at 12:20 PM
I implemented a third way to do similar think in the tool NDepend I develop (http://www.NDepend.com). I call it Transitive Closure of callers / callees.
Basically, there is a 'SQL like' language to query the code structure, there is a dependency matrix to see flow (direct or transitive) and there is the possibility to generate boxes & arrows diagrams.

Here is a blog post where I explain how to use these 3 features conjointly to browse code flow:
http://codebetter.com/blogs/patricksmacchia/archive/2007/12/02/dconstructing-software.aspx

I hope we can talk about this at the MVP Summit.



Mar 7 2008 at 12:28 PM
This should work when the source code for the methods are not part of the solution, provided the dlls have debug info. You can use something like refactor if needed to work out the code flow without the source code.

Often I have to work on code bases that are built by a lot of different solution files, it is very hard to work out what is going on, as basic things like “go to definition” does not work. However the debugger can find the source code regardless of the solution that builds it, so way can’t the rest of the tools?

Mar 7 2008 at 1:17 PM


CharlieCalvert wrote:
Please enter your comments on the Call Hieararchy feature here.


I think it is a cool feature - and integration with a sequence diagram would be a welcome addition. One challenge however is that a static analysis of a call stack/hierarchy is going to be problematic when you program to an interface. In this case, the call hierarchy you see will be abruptly cut short. Or are some plans of call hierarchies being calculated based on runtime execution analysis of the application?

-krish

Mar 7 2008 at 2:39 PM
I agree with Jon with regard to making it a "dialog". It shouldn't be modal and should be dock-able. His other 3 points are also good advice.

I also agree with Krish, a sequence diagram view of the call hierarchy would be very useful.

Mar 7 2008 at 3:06 PM
Call hierarchy is also related to the profiler. The profiler has a calltree view and a hotpath feature.

Mar 7 2008 at 11:28 PM
I think this will be a fabulous addition to Visual Studio. Yet another thing that I won't have to fire up Reflector for :)

Overall I like the design as it has been presented, and I also agree with all of the comments made so far about suggestions and improvements, particularly making it a floating window instead of a dialog.

I guess this hasn't really served much of a purpose except as a big +1 to everything.

One minor suggestion: if the inline view will be implemented similarly to Quick Watch, please make it easier to use. Currently it is very frustrating to use the Quick Watch window, as I have be extremely precise with my mouse movements in order make the window do what I want without it suddenly disappearing. For that matter, if you wanted to fix Quick Watch while you are at it, that would be great :)

Mar 8 2008 at 12:54 AM
Edited Mar 8 2008 at 12:56 AM
I also request that this feature is not implemented as a dialog, but as a dockable window. Also this should make the preview obsolete.
I don't want to have a seperate window to see the code, because in the editor I can also take advantage of all the other code navigation features.

The window should have a "center at current method" button, to quickly "reactivate" the window for the current method.

If you do make it a dockable window, single click should do either nothing or open the treenode. Double click is good enough to jump to the code. It is consistent with most of the other vs windows (afair) and developers are used to double clicking a lot anyway.

I also believe that I can live without the "Quick Understanding" mode, if I have a dockable window. But I can't be sure without trying it for some time first.

Instead of having two treeviews with a splitter bar, I find it easier to have a single TreeBar with "Calls From" and "Calls To" roots, similar to the quick mode. It is faster too temporarily collapse one of the two roots to give the other subtree more space, than to drag a splitter arround.

For me personally I think this feature will mainly be a way to navigate or to get only a shallow understanding of the calls happening. If you want developers to get a broader picture, a workflow like view would be a useful addition (i.e. graph with nodes representing the methods and edges representing the call) IME. Such a graph however can not replace the docked window for "quick and dirty" navigation.

I don't have an opinion yet on how to integrate this with other features in visual studio. It is true that the object browser could use some better navigation features. To be honest I use object browser almost never, because it didn't have a feature yet that I can't get easier with other features in VS (+Resharper). Instead of listing of listing only the base types of a class in the object browser tree, you could however add some more childs like "used by" or "methods" (with call hierachy embedded). Especially the "used by" is a very nice feature, if you know it from Reflector.

Thanks for listening! I hope you like my feedback.

Eagerly waiting for the next one,
Thomas Krause

edit: Moved unrelated paragraph to charlies blog.

Mar 8 2008 at 11:53 PM
I've used similar features provided by plugins to VS and I'd like to point out a few things they do better than what's been described.

1) As other have pointed out, it's MUCH better to have this as a dockable window rather than a modal dialog. This goes for everything in VS...modal dialogs are so 1990's.
2) 'Live Sync' is very useful if you're implementation is fast enough to handle it. This means that while moving the cursor in the editor it would sync the tree view with whatever symbol the cursor is over. The dock window should have a toggle button to turn this on/off. And while its off, you should have a keyboard shortcut.

This sounds like a welcome feature, but I'm a little disappointed that it is limited to just caller/callee of methods. Here are a few features I'd like to see that I currently either use .net reflector for, or that I dont have any tools for.
1) for properties & fields, it should be able to tell me who assigns/reads it
2) for events it should be able to tell me who adds/removes/invokes it.
3) for types it should be able to tell me who instanciates it, returns it, takes it as a parameter, other types that hold references to it, who derives from it, who it derives from, etc
4) for methods it should be able to tell me who calls it, who it calls, types it depends on.
5) for methods that implement interfaces it should tell me (seperately) who does the things in 4) on the interface method
6) for methods that overload base type methods it should tell me (seperately) who does the things in 4) on a base type.

On a side note, I love these future focus articles. Keep them up!

-Brandon Furtwangler

Mar 9 2008 at 7:34 AM
Here are some suggestions and comments with regards to Call Heirarchy.

1) I think it's a really good thing to have, but visually I think it should be a zoomable graph-like view, and agreeably it should be a dockable window to show live updates.
2) Another way if showing within the same .cs file, you can do a "display calls relationship" kind of arrows within the code page itself, or something. It's still vague, and maybe I can mock it up when I have the time.

I do wish that VS would implement more visualization of code information/structure using the power of WPF. But that's another story.

Coordinator
Mar 9 2008 at 8:35 PM
I wanted to take just a moment to thank everyone for their comments so far. The key people who design this feature have been actively following this discussion. They also expressed their gratitude for your comments. They have confirmed that getting feedback while they are still in the design process is invaluable.

I have be careful not to make promises, but my conversations with the team all seem to confirm that it is very likely that this will be a dockable window and not a modal dialog. Thank you for your feedback on that point, it has been helpful.

Please continue to submit feedback and to let us know what you think about this feature. Your intelligent and thoughful feedback is greatly appreciated.

- Charlie

Mar 11 2008 at 5:46 PM
The plugin to Reflector which does this groups the callee/callers by dll. this is often useful but would be nice as a real time configurable setting
It also works nicely with types (incorporating the Exposed By and Instantiated By which is very useful when you don't want to bother about which particular constructor is being used and just know it got created...

I would second everything Brandon wrote in his second section, Live sync is less important to me (dockable is definitely the way to go)

Mar 11 2008 at 9:46 PM
Edited Mar 11 2008 at 9:49 PM
I want to add strong agreement for both dockable and a sequence diagram view. As per viewing this as a sequence diagram I would go a step furthur and allow the sequence diagram view to be integrated and steppable during debugging. This sequence diagram would allow drill down to the code level and show what code has been executed and what code has not been executed. The current method that is being debugged highlighted on the sequence diagram. You should then be able to right click on a method or class within the sequence diagram and view code, set break points on object contructor etc..

Thank You for getting customers involved early. I think it is awesome!!


Mar 12 2008 at 12:32 PM
Firstly, I really like the idea.

A couple of posts have commented on some of the complexities that may come in more complex code. When a call hierachy is complicated by polymorphism it would be nice to have the call hierarchy show the various method implementations/overrides available across all types that are in the containing or referenced assemblies. Perhaps this could be achieved by having the subnodes of such methods consist of a list of types that could potentially provide that method at runtime. I think the complexities of OO programming need to be dealt with, because they can be things that make a call hierarchy harder to understand.

Delegates and events would complicate matters further. As a compromise, it would be good to have the ability (should you come to the raising of an event or calling of a delegate) to be able to fall back on "Find All References" by right clicking on the item in the hierarchy? This would be a useful feature generally.

The post focuses on methods, but I hope it would be equally applicable to properties and constructors. Could be very useful for understanding constructor chains.

Definitely keep "Find All References".

Mar 17 2008 at 12:46 PM
A couple of other people have mentioned this, so I'm just addding another vote here... I use the call graph in Reflector a lot, and a common cause of frustration is hitting virtual dispatch points such as interface methods and virtual functions. I know this will be a big issue in my own code because I make frequent use of interfaces to enable separation for simple unit testing.

Also, I'd like to cast another vote on the "Not modal" front.

If you implement this, please ensure we can have multiple call trees open at once. (Reflector gets this right. Last time I tried it, Eclipse gets this wrong.)

Mar 18 2008 at 3:57 PM

{quote}
IanG wrote:
A couple of other people have mentioned this, so I'm just addding another vote here... I use the call graph in Reflector a lot, and a common cause of frustration is hitting virtual dispatch points such as interface methods and virtual functions. I know this will be a big issue in my own code because I make frequent use of interfaces to enable separation for simple unit testing.

Also, I'd like to cast another vote on the "Not modal" front.

If you implement this, please ensure we can have multiple call trees open at once. (Reflector gets this right. Last time I tried it, Eclipse gets this wrong.)
{quote}Ian, comparing to Reflector's Analyze/Depends On, would you say there should be one window for all graphs or one window per graph? I think one-for-all would simplify the work needed to implement this feature and provide a consistent dockable window.

Mar 18 2008 at 6:57 PM

{quote}
IanG wrote:
A couple of other people have mentioned this, so I'm just addding another vote here... I use the call graph in Reflector a lot, and a common cause of frustration is hitting virtual dispatch points such as interface methods and virtual functions. I know this will be a big issue in my own code because I make frequent use of interfaces to enable separation for simple unit testing.

Also, I'd like to cast another vote on the "Not modal" front.

If you implement this, please ensure we can have multiple call trees open at once. (Reflector gets this right. Last time I tried it, Eclipse gets this wrong.)
{quote}Ian, comparing to Reflector's Analyze/Depends On, would you say there should be one window for all graphs or one window per graph? I think one-for-all would simplify the work needed to implement this feature and provide a consistent dockable window.

Mar 18 2008 at 8:39 PM
Replying to PeterRitchie - I don't particularly care. I'm used to a single window that holds all the graphs, so I'd be happy with that, certainly.

Mar 19 2008 at 10:23 PM
This is a cool idea, but I anticpate our call stacks to be too complex for the stacked trees. I also don't really see the point of the preview, although perhaps I will change my mind. My initial thought is to leave the preview and put the treeviews into tabs, but our monitors are wide enough that perhaps we dont' need it and could just use resizers. Although if you could make that a little view of the editor window with three tabs and the abillity to make a new vertical tab group that woud be extremely cool.

I don't want this modal. I want to be able to leave it on an adjacent monitor.

I do NOT want this to replace Find All References as that sticks around and I use it to navigate many minutes after the search. I also still want my Shift F2/Ctl Shift F2 navigation.

I agree with others: Multiple windows open simultaneously.

If a window becomes out of date becuase of a code change, I'm cool with it just going funky (like darkening) and then I'll manually refresh it. I could see challenges around keeping multiple windows in sync with changing code. I do want it to know when its out of date, I don't care if it stays perfectly in sync.

Mar 25 2008 at 6:26 PM
2. I like this feature a great deal. I know you said keep it focused on Call Hierarchy, but here are some other ideas. I think it would be very nice if you could tie this feature in with testing or team foundation. I think you could have a some kind cyclomatic complexity report that helps you identify problem areas. In fact, with a feature like this, one could (perhaps) easily tell if a given unit test provides branch coverage, or full path coverage (and maybe throw up a warning at compile time). I think earlier posts about conditionals and recursive logic are essentially asking how you would deal with this. "Solving" that "problem" could be used to extend other non-IDE features and products.

3. Following the crowd here...I would mostly like to see the feature dockable. Mouseover features like Quick Watch don't give you that instant gratification you're looking for at times, and can be slightly frustrating when you can't quite hover over what you're trying to hover over. I'd like to see it dockable, but it's probably better to make it configurable so that it could be either.

4. This feature should live side by side with Find All References. I noticed that this feature basically displays links to other methods. Find All References displays links to a file and a line number. To me, though similar, these are two different things. Not to mention the fact that Find All References seems to be uni-directional...and this new feature would be bi-directional. As a user, I may not want to see everything that a given method calls, I just want to find the methods that still use a given method. While both are good for debugging and code analysis (though the new feature might be better at both of these)...if it were me, Find All References would be used more heavily/easily for code refactoring.

5. I like the way it's displayed now. I don't quite like the verbiage "Calls To" and "Calls From"...I was thinking something with "Invoke ___" might sound a bit more consistent with some of the .NET stuff...but that doesn't really matter and it doesn't really read any better (in my mind).

Mar 25 2008 at 7:53 PM
Edited Mar 25 2008 at 7:53 PM
This reminds me of the Depends On/Used By feature in Reflector's analyzer. So I have to like it! I never have been a fan of Object Browser. I'm in the dockable modeless camp, too, especially if I can reduce the overhead of the IDE by closing that window.

The Dynamic Help window in VS2005 was a good example of what I'm talking about. Whenever I had the Dynamic Help window open, the IDE was sluggish. Closing the window ostensibly stopped the associated background process that built the help content for the current editor context. It may still be this way in VS2008 but I long ago learned to live without the feature, to be honest.

Similarly, if the analysis required to build the call hierarchy tree is expensive, I'd like to invoke it only when necessary or be able to disable it by hiding the modeless window that displays the hierarchy.

Thanks,

-- Kevin

Mar 29 2008 at 9:23 PM
This seems like a nice new feature in VS, but please don't remove the Find All References command. It is very useful during refactoring.

Apr 1 2008 at 12:16 PM
The other day i was looking for a feature i at that time called a Call hieraki. My problem was i had a bug but the call site was not in the call stack. Im using a dependency injection framework and during an instantiation the code fails at this time the Call stack shows the call to the DI framework but the actual instantiation is external code even tho it's not external its just calll through reflection. Fair enough the call stack is as it is, it's 100% correct but the information i need in that situation and that would be needed in similiar situations is not available. A call hieraki would make a lot of things easier writting code and a call hieraki at runn time, eliminating external code when it's actually not external code would be a great help when debuging

Apr 1 2008 at 1:38 PM
Edited Apr 1 2008 at 1:56 PM
I would like to see a tool like this help me determine whether I have set the right access modifiers for my methods so:

a) I would really like to see an indication on the Calls To pane a little icon telling me whether the callers were in my class, in a super-class, in a derived class, in an external class in the same namespace or in a class in another namespace all together.

b) I would like to see a similar indication on the Calls From pane showing the access modifiers for the target methods.

c) I would also like to see on both cases whether the callers / callees were static methods.

A couple of questions:

1) How will you deal with polymorphism? In other words, with this:

class A { public virtual void m() {} }
class B : A { public override void m() {} }
class C { public void main() { B b = new b(); A a = b; a.m(); b.m(); }

- do you show b's m method called once or twice?

2) Will you spot recursion?

Cheers

Richard

Apr 2 2008 at 9:25 AM
I can't see a lot of use for the Preview feature on the in-depth view. The ability to goto definition would suffice and I really want to go directly to the source code anyway. Maybe you could consider a separate dockable window that shows all the methods that the current method calls / is called from. A treeview with different icons that indicate whether the method is a property, accessibility etc would be useful.

This design time IDE feature would be useful, however, a runtime evaluation of the call path would be even better. In the VB days I created an addin that wrote debug output statements for each methods entry and exit points with a flag indicating entry, exit and error conditions. I saved this to a file and then loaded into another application that parsed the calls into a treeview hierachy. The results were extremely useful. I could see code incorrectly getting initialised twice and identify which methods were called the most + the timespan cost and hence should contain the bulk of the optimisation method. Often a caching strategy becomes obvious. It's not uncommon in a real world application for a utility function to be called many thousands of times with the same arguments and return value.

Perhaps this is more of a profiling suggestion. I can get very ugly where all method calls are logged so the ability to mark methods for inclusion would be a big plus. Maybe we add attributes to a method to indicate it's inclusion.


Apr 2 2008 at 5:31 PM
Very useful feature!
I think it would also be needed an easy way to quickly switch between two methods in the in-depth view.

e.g.: Method1 is called by Method2.
I see that Method1 is called by Method2 in the tree of callers of Method1 because Method1 is parent of Method2, and i can also easily find that, say, Method3 is calling Method2. Ok, but to complete my analysis now i need to know which other methods get called inside Method2. In order to see it i have to set the focus of the call hierarchy from Method1 to Method2. Maybe a right click over a method name could do the trick.

Consider also using a graph view instead of a tree view: this way every possible connection could be represented at once. This view would manage recursiveness as well, in a more intuitive way than a tree can do.

Apr 5 2008 at 10:28 AM
Sounds like a great feature; however, I think there will be some difficult scenarios to consider or it's usefulness will be limited. Some background: I'm an architect on a reasonably sized .NET project that is both a framework / API and a commercial application built upon the framework. This framework is very interface driven, and implementations are provided via configuration at run-time and obtained using either a service container or DI. Unless you have access to all the run-time types (at design-time) for a given application, you will not know where to go when you hit a call to IMyInterface.MyMethod(). In our framework, this would happen quite frequently. It goes without saying that there is a general push to design applications in a loosely coupled manner, using DI and/or IoC, so I don't think it is something you'll want to overlook.

We have tools to do this type of analysis at run-time and you could do this statically too, provided there is some way to configure this feature (per solution). By configure, I mean the ability to specify / loosly reference all the run-time assemblies, so your feature would be able to explore possible call paths based on who implements IMyInterface...

I don't want to even think about the decorator pattern :)

Just another 0.02¢

Cheers,

Stuart

Apr 9 2008 at 3:04 PM
This is a brilliant feature. It would be nice if not only being able to follow code execution paths, but then select a path and initiate a unit test. Sometimes the information will require database/file/web service pulls that direct the code calls and I can see issues with this feature. That brings me to my second point and sort what scarnie posted, we should have the ability to teach this tool for certain scenarios.

Lets say we have the an execution chain that requires input from a dynamic source to an unknown object call. We should be able to use this tool like runtime and then tell it "If" information that will allow the tool to create links in the chain based on what we tell it to assume.

Will to tool support calls that go to web services in the same projects? How about dealing with reflection?

Also what about dealing with exporting of information. I saw a post earlier on exporting into visio etc. This feature could be very useful for large scale projects or team projects. Primarily if reference's can be taken and used to help model how different members of a team use each other's code.

To further this along, why not have the tool go a bit further possibly into another tool and allow editing? I know this may sound like a stretch but it's fairly useful much like the design editor for Grid in asp.net. When looking down the call path being able to select an object, click edit and then: either open the window where the code is and highlight (link to), open an edit window that allows simple quick adds (like add node/method), or other ideas in a similar fashion.

Often its the path that takes the most time to develop and not the logic in the method. So if the tool take visibility, exportability, team sharing, and simple code editing that would make it very useful. So instead of the tool just looking things up, why not make it a fully fledged way of dealing with code?

Thanks for all the hard work!

Apr 10 2008 at 1:31 PM
I consider this a very very useful feature.

And I also vote for extending this (or some other IntelliSense) feature for inspecting possible exception thrown along the call hierarchy (stack). It will be great to know what to excect and (optionally) catch.

Apr 11 2008 at 11:33 AM
Hi,

Are there plans to support commonly used DI/IoC Containers with this feature. So, will it find calls wired up by configuration instead of static binding?

Martin

Apr 21 2008 at 11:56 AM
This feature would save me a lot of roundtrips to Reflector http://www.aisto.com/roeder/dotnet/.

I'd like to suggest an addition but i'm not entirely sure how to phrase it correcly:
"Collapse call-hierarchy": take a code path and collapse it to a single operation.

Apr 22 2008 at 3:28 PM

lercher wrote:
Are there plans to support commonly used DI/IoC Containers with this feature. So, will it find calls wired up by configuration instead of static binding?


I thought I'd read a reply but it's gone now. I remember had some statements about the difficulties.

A suggestion: What about learning the concrete implementations at runtime? With (or without) a little help of the IoC container framework the debugger could keep track of the implementating type of an interface method so a "Goto Recorded Implementation" command on an interface call would go to the implementor. IMHO this would be a 80/20 solution suitable for all the "staticly" wired up dependencies but saves 80% of searching time.

Martin

Apr 23 2008 at 10:27 AM
What about having a feature which generates unit test cases for selected methods? I am not sure though if such feature exists today. May be the feature will instantiate class object where method is written, initializes the argument objects with default values and call the method with possible assert statements. Developer can quickly change the arguments values appropraitely and execute unit tests.

Apr 23 2008 at 10:28 AM
What about having a feature which generates unit test cases for selected methods? I am not sure though if such feature exists today. May be the feature will instantiate class object where method is written, initializes the argument objects with default values and call the method with possible assert statements. Developer can quickly change the arguments values appropraitely and execute unit tests.

Apr 23 2008 at 6:18 PM
Edited Apr 23 2008 at 6:20 PM
I think some of the latest comments are inventing a new feature--one which I would love to see. That is a "recordable call tree." Have a record button in a dockable window, or on the toolbar that runs from one breakpoint to another (or a special recorder startpoint/endpoint) and records the call tree. That would give you a more in-depth view of what is going on. Recorded trees could then be viewed at design-time and would allow you to quickly navigate to the method callers and callees (like clicking an item in the Find All References window).

This would save me hours of single stepping through some gnarly code that shouldn't be single stepped through! I still have nightmares of trying to debug some serialization code I wrote that used an xmlreader and a output memory stream. I have a fast new laptop, but it screetched to a halt every time I tried to single step to the next line. it even crashed my machine a number of times.

If I could instead set a record startpoint and end point and let it rip--life would be far simpler!

(Note: sorry to deviate from the main topic)

Apr 25 2008 at 7:51 AM
This is a great feature; hasn't VC++ had something similar for a while? The ability to explore a call tree and refocus at any time is really handy.

As for DI/IoC, couldn't the tool bring up compatible types within the current assemblies and let us provide a assumptions? At least for the simpler cases (where there's only one real implementation plus a unit test implementation) it'd take care of things nicely. I'd even think that you could somehow provide an annotation for analysis right in the source code?

Speaking of annotating assumptions, does this feature mean we're not going to see a more in-depth analysis features in VS next? For instance, a call hierarchy that only shows possible calls along with possible variable values?

May 9 2008 at 3:08 PM
I think that dependencies in general are not exactly obvious at times to spot in .net because of things like delegates or even using other peoples precompiled code through assembly references.

something like this would really help understabd what is being called in more detail.

I like the idea of being able to point ata method and saying "create test plan" or similar then crawling the heirarchy during testing and debugging in a tree like fashion.

Some time will have to be taken on how things are resolved with loose coupling of objects like delegates and with other planned improvements including dynamic referencing this could be a real tricky feature to implement !!

May 10 2008 at 6:45 PM
I'd change the wording slightly.

Instead of "Calls To", I'd use "Is Called By"
Instead of "Calls From", I'd use "Calls"

Just an idea to make it a slightly more intuitive. To me, anyway. =)

May 11 2008 at 11:19 PM
Excellent idea! Hopefully you can take it a step further and visualize delegate calls (separate threads) as well!

Jun 6 2008 at 7:18 PM
This looks really useful. One suggestion: I think the "called by" window's hierarchy is backwards: in the called by window, the parent node is the callee (the method you are inspected) and the child nodes are the callers. This is the opposite of how the "calls to" window works, and I think a little confusing.

Jun 12 2008 at 12:21 PM
This sounds like a great feature, but how will it work in these two situations?

Inheritance

Will I pick up the right calls if I write;

IAnimal mutt = new Dog();
mutt.Eat(food);

Will I see a call to Dog.Eat() or IAnimal.Eat(), or both?

Delegates and Functional Programming

If I write

List<Owner> GetOwners(List<IAnimal> animals)
{
var owners = animals.ConvertAll(animal => animal.GetOwner());
}

will the 'called by' list of IAnimal.GetOwner() include this GetOwners() method?

Jun 15 2008 at 9:27 PM
Would be great to be able to find a possible execution path between two methods.

Another useful feature that's implemented in Reflector is the ability to see where a particular variable is instantiated/accessed/modified.

Jun 16 2008 at 12:08 PM
As I had not get enough time to read all comments, maybe my ideas are already mentioned, sorry then.

I think thos is a great new feature with much more capabilities than shown in the post. maybe you could also implement some sort of loop detector which also analsyses the decission paths which lead to the loop and marks it in the "dependency" tree.

-- MethodA() ----------
+-- MethodB() | loop (xyz>23)
| -- MethodC() <-

not a really good example for my idea, but I think you understand what I mean.
Also, if a method raises a event (in any kind of way) the therefore called event handlers should also be shown.

And please, do not use a seperate window, integrate it as dockable tool window.



Jun 18 2008 at 1:08 PM
Regarding the >>Understand the impact of making changes to their code.
from "What is a Call Hierarchy?"

Extending the "recordable call tree" idea.
Save one flow, changing the code and compare the saved flow with the new one.

Jul 12 2008 at 11:44 AM
In addition to drill down hierarchy view, it would be great to see a aggregate list that shows list of all methods in"Call To" and "Called From" tree in a list view. It will be even better if I can have this aggregate list sortable/groupable/filterable by class name or namespace. The UI in this case can lead to "Call Tree Explorer" of short where right pan is a list view and left pan a tree view. This is very useful to figure out how many methods depends on a given method. This is often raised question when someone wants to make a change but don't have clear idea of dependencies.

One more thing you can do is to give some sort of visual indication of coupling between calling method and callee. For example, if method M1 calls M2 and passes its local variables as parameters to M2 then M1 and M2 have strong coupling.

Finally, it would be great to include part of this feature as automated intellisense instead of always manually invoked. For example, when I add a parameter to method M1, you can immediately popup a list of methods that call M1 and now requires change (may be in same fashion as intellisense or in a separate pan).

Jul 22 2008 at 6:19 PM
I just wanted to chime in with the previous idea of having the hierarchy displayed in a separate docked panel. Taking this further it would be nice to have an intelligent window that displays relevant information depending on what is selected or the pointer is over. Kind of like the current floating panels for method signatures etc. but off to the side and with context actions and information. Being away from the mouse pointer would help prevent clutter and also give room for many more choices of actions and information. The context menus should be kept for the really important and simple to display stuff.

In terms of representation I like the idea of something graphical to allow quick jumps along the hierarchy, but also some sort of forward/back buttons (like Internet Explorer) for retracing your route along.

Jul 22 2008 at 7:45 PM


LaughingJohn wrote:
I just wanted to chime in with the previous idea of having the hierarchy displayed in a separate docked panel. Taking this further it would be nice to have an intelligent window that displays relevant information depending on what is selected or the pointer is over. Kind of like the current floating panels for method signatures etc. but off to the side and with context actions and information. Being away from the mouse pointer would help prevent clutter and also give room for many more choices of actions and information. The context menus should be kept for the really important and simple to display stuff.

In terms of representation I like the idea of something graphical to allow quick jumps along the hierarchy, but also some sort of forward/back buttons (like Internet Explorer) for retracing your route along.

That's starting to sound a little like Dynamic Help--which is now not on by default because of too many complaints about how it affected performance. I would imagine adding context actions to relavent information (assuming Dynamic Help already does the "relevant information" part) would make it even slower.

What sort of actions would you expect to be able to perform in this "intelligent window"?

Sep 26 2008 at 8:08 PM
Sounds great; my only hope/suggestion at this point is that Microsoft follows through on their promise of parity between first-class supported languages and has this feature available for C++ development as well. Can you confirm that before I get too excited about this new feature?

Sep 30 2008 at 3:50 PM
Great News I have been missing this feature badly in VS (i also occasionally use eclipse),

My 2c worth it should be implemented as an ordinary tree view such as the solution explorer, have a toolbutton that switches the direction of the tree. Synchronise the editor with the selected method and have a right-click option 'show in call heirarchy'

It is a great way to explore your codebase, debug and refactor.

Oct 16 2008 at 1:03 PM
Will this call history be integrated with MEF? and how about tracking the dynamic method calls?

Late bound methods ... will they be tracked?

Nov 18 2008 at 1:08 AM
Looks like a great feature.
I would love it if the call hierarchy could be automatically shown out to the right in the editor window. Since I have a widescreen monitor (and I think most computers do these days), the editor window tends to leave a lot of unused space on the right.
I can imagine several ways this might work. You could have a semi-transparent list down from each line showing the call tree that that line spawns, and for method headers you could use the space to the right to show the call trees that call the method. When you hover your mouse over these they would become links to go to the methods (equivalent of Go To Definition). They should autolayout, follow the associated code when scrolling, and automatically move out of the way when editing.
If you don't do this directly, it would be very cool to enable someone to do it from the outside using the wpf editor integration.
I've been itching to do something useful with the right half of my monitor for a while and I think this would be one of the coolest things.

May 11 2009 at 5:18 PM

In reply to your Furture Focus posting on Call Hierarchy:

> How would you like to see us integrate the Call Hierarchy into the Call View, Object Browser, or other parts of the IDE.

I definitely have a integration suggestion I do not yet see discussed in this thread.

It has been my practice the last 16 years to represent the call hierarchy within the (released) source code comments in method headers, for methods (many or most of them) having at most several callers and up to some maximum depth, like several levels above. This way, the comment addresses the second of these most important questions to the reader: What is to occur? How did I get here? What special considerations should I have in mind? I have found my code maintainability substantially enhanced by having the call hierarchy in the comments, though the presence there would be enhanced by tool support to keep the hierarchy current as the code evolves. Like my internal documentation, my preference is to embed this information in the code comments where it is significantly more likely to be referenced than if a tool action is required in order to view it, and where it will be included and appropriately placed in print outs of the code.

As mentioned, I am well aware approaches to include the call history in the code comments will have limitations and not be workable for all cases. My point is rather the frequent cases where it is quite viable, and greatly promotes readability / maintainability. An imperfect approach that would be often usable, would be extremely helpful. Of course, a condensed representation would be the greatest help in this usage. For example, in my hand notation of the call hierarchy, I use where practicable a (nestable of course) comma delimited list of callers to a common child level. This is the type of thing however where discussion of representation could be paralyzing to delivery of the feature: just have the designer pick a reasonable representation appropriate for use within code comments and run with it. I do think if you agree with the basic feature, an additional comment type such as "called by" would be appropriate.

Thank you for your consideration and discussion toward supporting call hierarchy within source comments, and for all your fabulous work (I get 10 times more done now thanks to your great tools, and I am looking forward to another 10x boost from you in the foreseeable future).


Mar 28 2012 at 8:01 AM
My opinions about this feature are as following:
1. I agree with the idea that the Call Hierarchy should be displayed in a dockable window. This feature just provides a reference, a quick lookup or review while we are programming. So please don't block the programming progress by a modal window. :)
2. In my thought, this feature will consume a lot of CPU usage when it starts to collect information to build the Call Hierarchy tree. So please let us, developers, decide when this feature starts working. You should place a check button on the toolbar of the window named Automatic so that when this button is checked, the feature will automatically rebuild the Call Hierarchy tree or we will manually click a button called Rebuild (or Refresh or something like that) to rebuild the Call Hierarchy tree after we made changes to our source code. I really don't want to see the Visual Studio hang or not responding every time we add new calls to another method because of the automatic rebuild process of Call Hierarchy tree. Let us decide based on our project, automatic for small, manual for large projects.
3. I agree with the idea that we would see a sequence diagram or a workflow diagram as an additional view option of Call Hierarchy. View in tree, I agree. View in diagrams, why not? Visuals are always easier to understand than lines of code (or a tree of codes also). Do you agree with me?
4. Visual Studio is extensible. This feature should be also extensible. That means, we should make it extensible so that any other DI or IoC framework vendor can make an integration or extension in Visual Studio to help their user see the workflow of a program developed using their product, a DI/IoC framework. Each framework has a different implementation and that is a secret, of course. So it's up to them, the framework vendors, to decide how much they share the information of workflow in their framework to their users, us, the developers.
I'm looking forward to using this brand new feature in the upcoming versions of Visual Studio. And please give my thanks to Visual Studio Development Team who is implementing this useful idea.


Updating...
Page view tracker