Call Hierarchy

re: Call Hierarchy

rtanabe — Fri, 12 Jun 2009 03:52:09 GMT

Please, code snippets for VC++ (like C#, VB)

re: Call Hierarchy

fabio — Fri, 12 Jun 2009 11:07:30 GMT

Nice improvements, I would like to copy and paste also from the left pane (the tree). Will it be possible?

re: Call Hierarchy

Sam Martin — Fri, 12 Jun 2009 12:15:35 GMT

Thanks. Sounds very nice.

However, the primary reason I don't use the existing call browser in 2005/8 is because its too slow in practice.

In comparison I can trigger a "find in files.." search in a few key presses that effectively gives me the same information but much faster, albeit in an unorganised list.

Incidentally, the same performance issue applies to other features such as a the class browser.

Is the team addressing the performance issues in VS?

re: Call Hierarchy

Joe — Fri, 12 Jun 2009 17:30:31 GMT

May I suggest using different icons for the "Call from" and "Call to" nodes in your tree, just to make them stand out better?

Although, like Sam, I never use it the existing feature. I mostly need to know who is calling a functions, and for that I just do a quick "Find in files..." on my large C++ project.

re: Call Hierarchy

CMC — Fri, 12 Jun 2009 18:02:38 GMT

Is there any chance that the underlying data can be exposed to enable something like "Give me a list of functions that aren't called from anywhere?"

re: Call Hierarchy

Raman Sharma [msft] — Fri, 12 Jun 2009 19:59:40 GMT

Thanks for your comments.

@fabio: copy/paste of the tree from left pane right now is not possible. Individual nodes however can be copied and pasted. I can see the value in copying the tree and then pasting it in a text-tree format. We can certainly consider it for future.

@Sam:

@Joe: "Find in Files" is a grep of the text in files and will give you a lot of extraneous results (i.e. things that are not function calls or things that are not exactly what you specified). Results from Call Hierarchy are effectively verified with the compiler for accuracy. For example, if you do a "Calls To" for Start in MyClass::Start, it will never return result for YourClass::Start. Doing this will off course require extra computation and hence the slowdown. But, rest assured we have done work in this release to improve the performance and you will see the results soon. And yes, we do have plans for different icons for "Calls To" and "Calls From"

@CMC: Very interesting. If this type of a problem is to be solved in the design-time space (IDE, IntelliSense, Navigation, Browsing etc.), I can see it becoming a huge performance issue. Imagine what you need to do: Identify all functions inside your code, perform a "Calls To" for all the functions, and then list those for which "Calls To" returns zero results. That's why, I guess this kind of information is better found through analysis of the binaries etc.

re: Call Hierarchy

Phil — Fri, 12 Jun 2009 23:43:52 GMT

I would like a graphical view that shows each function as a node with calls being edges on a graph. It would be cool to see the whole graph at once to visualize the program's call structure.

re: Call Hierarchy

Olivier Hamel — Sun, 14 Jun 2009 00:59:59 GMT

I second that suggestion, a graphical view would indeed be useful.

re: Call Hierarchy

Royal — Mon, 15 Jun 2009 06:54:21 GMT

A few things that would be nice would be the ability to regain control of the UI when doing remote debugging, or have it allow you to use the editor when the remote debugger disconnects (like if you are debugging in windbg on the kernel and are reviewing the code in VS while debugging the usermode code as well). Or if a network issue comes up that VS doesnt just lock up, or even lag on a remote network issue, that you can still do something.

Also, is there a reason it has to chew up > 128Megs just to be a intelligent text editor? or even runaway up to a gig+ after extended usage (>6-8 hours of dev time?). Or perhaps when debugging GDI+ objects that it can really eat up memory?

How about the ability to move code from VS 2005 to VS 2008 and still have the same STL functions work? or even have the SHBrowseForFolder function work when called twice (works with VS2005 compiled code, but in VS2008 random crashes, and just nutty). It completely destabilized the code that was rock solid, and all that was done was move from 2005 to 2008. When it crashed, it was always inside of either the STL call function, or an internal call function (6-7 calls deep outside of our code). Obviously we had to go back to 2005 where we are now and its completely stable, but because the random crashes just made it unusable in 2008.

Oh, and using STL file calls are still limited to 2GB (size_t/signed integer), so doing file IO using fstream on larger objects isnt realistic unless you want to redefine that. Minor item, but still an annoyance, 2GB+ files are quite realistic these days.

How about an option to allow the toolbar stay collapsed when moused over (as autohide is very nice, but is a nuisance when you hit that right side line of code and mouse over accidentially). Yes, could easily disble autohide, but having the toolbar on that side is actually quite useful for DB connects as well as the tool objects themselves.

The #1 reason I use VS as my preferred editor is because I can get to things fast, look up objects and cross reference quickly. But the newer versions scare me quite a bit because moving up to new platforms seems to have quite a bit of pain, especially when using the same documented calls. Back in VC6 -> VS.net it was understandable, but now?

re: Call Hierarchy

SvenC — Mon, 15 Jun 2009 09:47:29 GMT

@Royal,

what is your SHBrowseForFolder code? This is a windows function, so the VS version cannot make the difference here. There must be some fault in how you call or use it.

re: Call Hierarchy

Sam Martin — Mon, 15 Jun 2009 14:47:25 GMT

@Raman Sharma

Thanks very much for your feedback.

I understand a find in files isn't accurate. However it is accurate enough in practice. It actually serves to underline my point: Ultimately this tool is meant to speed up my development. A search, even with false positives is faster - and therefore more suitable - than an accurate tool that is slow. Performance really is critical.

I think CMC makes a good point. This is functionality I would be interested in. Incidentally, it's also something I can get a draft version from with some crude parsing (unreferenced functions typically only have two entries - the .h and .cpp). The implementation you propose would indeed be very slow. Are there not faster implementations that would produce useful data?

Thanks,

Sam

re: Call Hierarchy

John Marduk — Mon, 15 Jun 2009 18:44:30 GMT

Who cares about new features when you folks can't even get intellisense working? What about refactoring & syntax formatting?

re: Call Hierarchy

Royal — Mon, 15 Jun 2009 19:45:19 GMT

Pretty simple clean cut code, and in 2005 works great. in 2008 unpredictable crashing.

BROWSEINFO m_brinfo; (in the .h of CFolderDialog as its a skinned holder)

CFolderDialog::CFolderDialog(CWnd* pWnd)

{

bCoInitSucceeded = (CoInitialize(NULL) == S_OK);

}

CFolderDialog::~CFolderDialog()

{

if (bCoInitSucceeded) { CoUninitialize (); }

}

LRESULT CStatusMsgDlg::PopPathDialog(WPARAM wParam, LPARAM lParam)

{

CFolderDialog dlg(this);

PWCHAR pwcPath = (PWCHAR) wParam;

(void) dlg.BrowseForFolder(L"Please Select the installation Path", BIF_NEWDIALOGSTYLE | BIF_VALIDATE, pwcPath, TRUE);

SetEvent((HANDLE) lParam); // set the event to allow the app to continue

return 0;

}

LPCITEMIDLIST CFolderDialog::BrowseForFolder(LPCTSTR title, UINT flags, LPWSTR csRoot, BOOL /*bFilter*/)

{

m_brinfo.lpszTitle = title;

m_brinfo.ulFlags = flags;

m_brinfo.lpfn = CallbackProc;

m_brinfo.lParam = (LPARAM)this;

m_sSelFolder = csRoot;

LPCITEMIDLIST pidl = SHBrowseForFolder(&m_brinfo); // do it (Crash happens in this call 2008)

return pidl;

}

int CALLBACK CFolderDialog::CallbackProc(HWND hwnd, UINT msg, LPARAM lp, LPARAM lpData)

{

CFolderDialog* pDlg = (CFolderDialog*)lpData;

ASSERT(pDlg);

if (pDlg != NULL) {

if (pDlg->m_hWnd!=hwnd) { pDlg->m_hWnd = hwnd; };

return pDlg->OnMessage(msg, lp);

}

return 0;

}

int CFolderDialog::OnMessage(UINT msg, LPARAM lp)

{

switch (msg) {

case BFFM_INITIALIZED:

OnInitialized();

return 0;

case BFFM_SELCHANGED:

OnSelChanged((LPCITEMIDLIST)lp);

return 0;

case BFFM_VALIDATEFAILED:

return OnValidateFailed((LPCTSTR)lp);

default:

TRACE(L"***Warning: unknown message %d in CFolderDialog::OnMessage\n");

}

return 0;

}

re: Call Hierarchy

Royal — Mon, 15 Jun 2009 19:48:20 GMT

"intellisense" -- what would be great is at least the ability to purge and reset intellisense so that it can work again when it dies instead of having to get out, delete the ncb and get back in.

I find it dies on me quite a bit, and the deeper my code subclasses and inherits the worse it gets.

re: Call Hierarchy

SvenC — Mon, 15 Jun 2009 20:46:14 GMT

@Royal,

read about CoInitialize here: you need to call CoUninitialize for CoInit == S_FALSE as well. So bCoInitSucceeded = SUCCEEDED(CoInitialize(NULL)) would be better. But: when you read the remarks section I would count it "dangerous" to call it in the middle of a program as you cannot make sure that if your thread is the first CoInit caller that it will be the last CoUninit caller as well - in fact you call CoUninit as soon as you destructor runs. If you control the exe as well you should CoInit somewhere early during app startup and CoUninit before it ends. When using COM in your own threads call CoInit at the beginning of your thread proc and CoUninit at its end - be sure to have Released all COM pointers used in that thread before calling CoUninit.

You do not free the returned PIDL which you should with CoTaskMemFree if != NULL.

You might likely have a multithread issue. I guess you do some multithread stuff due to your call to SetEvent.

So I guess there are still some places where crashes could be caused by your code rather than by VC9. Just because your code runs compiled with VC8 does not say that it is correct.

re: Call Hierarchy

S. Colcord — Mon, 15 Jun 2009 21:14:19 GMT

@Raman:

How does the Call Hierarchy handle dynamically-bound function calls (either through function pointers or virtual functions)?

While it can't statically identify a dynamic call, it seems like it could at least list everywhere that there's a potential vtable match, or where the address of the function (or its virtual signature) is taken. If the call hierarchy doesn't include potential dynamic calls, I'll still have to do a file text search to make sure not to miss them.

Also, if the function is exported from a DLL, is that noted? It seems like it would be worth emphasizing that this function signature may have external callers.

re: Call Hierarchy

Royal — Mon, 15 Jun 2009 21:43:02 GMT

I do Coinit at app start up and end. As this class is instantiated with the new thread created, I CoInit with the new thread at creation of the class object and remove at the thread's termination at the class object teardown. That said, when I remove the Coinit/uninit as I do it at thread startup as well as freeing up the returned PIDL. compile with VS2008, I get the same crash result in the same place internal to that call.

The application is heavily multithreaded, but the path to this code is not at all. That said, there are specific reasons to using the SetEvent. This function is an 'up front' decision before a majority of the multithreading kicks in.

I free my pidl with the documentation's method:

CComQIPtr<IMalloc> iMalloc; // shell's IMalloc

HRESULT hr = SHGetMalloc(&iMalloc);

ASSERT(SUCCEEDED(hr));

iMalloc->Free((void*)pidl);

Unless using CoTaskMemFree is better?

However this is what scares me: "So I guess there are still some places where crashes could be caused by your code rather than by VC9. Just because your code runs compiled with VC8 does not say that it is correct."

In one way its good, but in another, its bad because you almost have to go through a complete comprehensive code review when going from VC8 to VC9 because the output will be unpredictable. This may sound trivial, but when scouring over 50k of code, that can take quite a bit of time, even for a single developer.

Its kind of funny, but in the windows drivers writing world, you really do not deal with much of this, which is why many of them chuckle at what many deal with in the win32 side.

Its always easy to shrug it off to the developer and say poor practice, but when a product works 100% stable in its environment, then you upgrade to the next environment on functions you do not control and they change their behaviour, it tends to scare and prevent many from changing it. Many developers do not have the luxury of doing a full review of their own code to ensure compatibility with a new version of the development environment just to gain some new tools and shortcuts.

Some more pragma warnings or documented areas of where things may have changed would make life a lot easier, and increase confidence because nothing is worse than chasing down a bug in code that has worked forever, and suddenly stops working when you link it against a newer external library that you did not write.

Developers want to use the latest and greatest, especially if it makes their lives easier and increases productivity, but in the end we code to make applications, not code to use the development environment.

re: Call Hierarchy

Royal — Mon, 15 Jun 2009 21:44:24 GMT

And one last thing. Thank you for responding. It may not seem appreciative from many at times, but even the smallest amounts of feedback go a long way. I'm sure you may remember what it was like on the other side of the fence before your days there.

re: Call Hierarchy

SvenC — Mon, 15 Jun 2009 22:48:19 GMT

@Royal: But you are not saving the return value of dlg.BrowseForFolder, which is the PIDL, so you cannot free it.

Another problem I see: you do not assign a buffer to m_brinfo.pszDisplayName. That is an out buffer, which should have space for at least MAX_PATH TCHARs. Could it be that this member points to garbage and hence SHBrowseForFolder fails randomly.

VS Project, C++ and Editor team blogs

Kirill Osenkov — Mon, 15 Jun 2009 22:56:33 GMT

This is just a quick announcement about some Visual Studio team blogs that might be really worth checking

re: Call Hierarchy

Stephan T. Lavavej [MSFT] — Mon, 15 Jun 2009 23:07:52 GMT

[Royal]

> Oh, and using STL file calls are still limited to 2GB

This should be fixed in VC10 Beta 1. Please try it out, and file a Connect bug if our fix was incomplete.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 00:06:45 GMT

It wasnt m_brinfo.pszDisplayName. I initialized it, and it was filling it with info, but same result.

Now that I've decided to put hour into it and really check everything, I can tell you the crashing bug occurs when you change the path a second time.

It is an update bug while drawing / updating the edit box portion of the dialog control invoked by SHBrowseForFolder. Each time it can be a little different, but basically the first couple times its run, it accesses a NULL window handle in the CWnd class for the editbox of the selection dialog. Other times, it fails to get the handle to the device context to determine the text extent GetOutputTextExtent.

Easily reproduced by simply changing the path in the lower box the second time. First time always works and is clean.

I do custom skinning on my objects, so I'm very familiar with how this works because its an interesting experience for any win32 coder doing UI work. That said, this one I do not do, its straight win32 stuff because I didnt want to write a custom path browser.

@Stephan - I'll check it out on my old versioned code as I had to rewrite all of my STL file IO calls from 15 classes, but I still have the old code that should still work fine in SVN.

re: Call Hierarchy

SvenC — Tue, 16 Jun 2009 00:24:36 GMT

Hi Royal,

not sure if I understood. Did you find the bug and solved it or did you describe what you think is the bug in SHBrowseForFolder? If the latter, I do not know what SHBrowseForFolder has to do with a CWnd? shlwapi.dll (where SHBFF lives in) does not use MFC where CWnd belongs to.

What do you mean by "changing the path in the lower box the second time"? How and where do you change a path? And how does that cause a crash? You might need to show some more code.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 01:15:29 GMT

It is not solved, I found the bug.

SHBrowseForFolder says in the docs: This function displays a dialog box that allows a user to select a folder.

So that means it creates a dialog box, which last time I checked CDialog derives from the CWnd class. That would be how it relates to CWnd.

If you put BIF_USENEWUI (which according to the docs is BIF_EDITBOX | BIF_NEWDIALOGSTYLE) and as a result BIF_EDITBOX by definition is: Include an edit control in the browse dialog box that allows the user to type the name of an item.

So thats how I get the editbox which when you type anything in there will call its native functions, thus the crash, which is completely inside of that function's call since it is created and managed by SHBrowseForFolder. I do not override any of its drawing controls or even try to.

Crash is: Unhandled exception at 0x77a39d80: 0xc0000005 - Access violation reading location 0x43790eec

Which is in shdocvw.dll with module space:

shdocvw.dll C:\WINDOWS\SysWOW64\shdocvw.dll N/A N/A No symbols loaded. 64 6.00.3790.4134 (srv03_sp2_gdr.070817-0047) 8/18/2007 11:54 AM 77980000-77AF3000 [4436] BRWC_DEBUG.exe: Native

which this time was something different, but last 2 times it went to HDC and HWND.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 02:05:01 GMT

As for it not using MFC, a small inspection reports that it is comprised of a window, 4 static controls, 1 edit, 3 buttons, a scrollbar and a SysTreeView32. So MFC does not apply here, but it is indeed a window and it only crashes when you make a change in the Edit control owned by that window created by that call.

This is actually getting off topic, which is why things break from VS2005 to VS2008 without a source code change.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 02:30:08 GMT

On a final note before I go and write one from scratch. The issue happens when you select the path and replace it by typing / replace.

So lets say the editbox has C:\Program files\Stuff

and you highlight C:\program files

Then press the letter R (as if to change to R:\stuff)

It will crash right after pressing the letter R.

If you click in the editbox and type the path in (without selecting or highlighting any text) it works perfect every time.

re: Call Hierarchy

SvenC — Tue, 16 Jun 2009 09:15:33 GMT

Do you do m_brinfo.pszDisplayName = "some path"? That is not correct as the compiler could assign read only memory. Use TCHAR path[MAX_PATH]; lstrcpy(path, "some path"); m_brinfo.pszDisplayName = &path[0];

Also make sure that you set all members of m_brinfo correctly whenever you call SHBFF, not only on the first call.

I count this on topic if it shows that you relied on faulty code or undefined behaviour.

But you are right that it is OT here. We could continue in a newsgroup like microsoft.public.vc.language if you want.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 09:50:15 GMT

All parms are always set the same way.

m_brinfo.pszDisplayName = new WCHAR[MAX_PATH];

ZeroMemory(m_brinfo.pszDisplayName, sizeof(WCHAR)*MAX_PATH);

pszDisplayName receives the display name of the folder that I select. If I were to at least see a BFFM_SELCHANGED message hit that would be better, but we dont even get that far

But remember, it only happens if I select the text and hit a key to replace it. From what i've seen on the crashes, it is trying to get the textextent to redraw it back into the control (since you would use textextent to determine the width of text so you can draw it inside of your control's space correctly), but somehow gets lost and either cant find the window, device context, or object. When it screwed up on the DC at the extent call, it had the correct number of chars and info to the caller.

It doesnt happen before or after, its precisely in the same place doing that 1 method. I can delete the text, I can add to it, i can maneuver around it, but if I highlight it and replace with a key, it crashes. No extra messages, last WM to the control is VKEY press itself.

re: Call Hierarchy

SvenC — Tue, 16 Jun 2009 10:27:24 GMT

I created a Win32 app with the VS2008 wizard. Added a menu and in the WndProc for that menu command I added:

BROWSEINFO brinfo;

ZeroMemory(&brinfo, sizeof(brinfo));

brinfo.hwndOwner = hWnd;

brinfo.lpszTitle = _T("Test SHBFF");

brinfo.pszDisplayName = new TCHAR[MAX_PATH];

brinfo.pszDisplayName[0] = 0;

brinfo.ulFlags = BIF_USENEWUI | BIF_VALIDATE;

PIDLIST_ABSOLUTE pidl = SHBrowseForFolder(&brinfo);

MessageBox(hWnd, brinfo.pszDisplayName, _T("show SHBFF"), MB_OK);

delete [] brinfo.pszDisplayName;

CoTaskMemFree(pidl);

I can call that menu command as often as I want, I can select the edit box text in any ways and press a key without any error no matter how often it is called.

Try it for yourself, it is done in 5 minutes and you see that SHBFF has no problems.

I wonder why you know all the details of the implementation of SHBFF like getting the textextent or trying to get to a window or device context? I guess you are doing something wrong in the callback function or by hooking, subclassing or some fancy stuff.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 18:40:44 GMT

In this case, there was nothing fancy. No hooking, subclassing, or anything. Just a straight call. Like I mentioned before, I didnt want to have to write one.

I'm a little surprised you would ask about the details of textextent and controls. If you have ever built an editbox control with or without multiline, its the basic '101' fundamental of accomplishing it.

re: Call Hierarchy

SvenC — Tue, 16 Jun 2009 18:50:45 GMT

But how could you possibly know any details of the implementation of SHBFF? It handles its dialog all on its own and the implementation is hidden in shlwapi. I do not understand how you could know which part of that shlwapi code causes your crash - nobody of us has source code for that.

I used SHBFF before without errors and my test app did show no errors. I am still absolutely sure that the crash is caused by code external to SHBFF - most likely your code except you have installed an app which hooks into windows standard controls.

re: Call Hierarchy

Raman Sharma [msft] — Tue, 16 Jun 2009 20:59:42 GMT

@ S. Colcord:

Admittedly the support for dynamically-bound function calls is not as efficient as it should have been. For virtual functions, we list the calls based on type of the pointer rather than the object. And the calls using function pointers are not listed. This is one of the areas we had much discussion about while designing the feature. Hopefully we will improve it in future.

re: Call Hierarchy

Royal — Tue, 16 Jun 2009 22:39:20 GMT

@SvenC - I've already told you that there is no hooking or anything fancy, but you are just in utter disbelief.

I dont see a [msft] tag behind your name, so I'm going to write off your lack of basic debugging knowledge, and how basic windows control work internally.

If you are with MS, then its quite shameful the elitist type of responses provided that its simply impossible the code could never have an issue.

I dont need to know how SHBFF works because working with an edit control is always done the same basic way. In rough steps, you take your text, you measure it against the font (TextExtent) and compensate for largefont sizing, then clip off what will not fit, Draw it into the area. Pretty simple. And I also do not need source to use a checked build of the OS and look at assembly calls if I really want to dig into an issue.

But I've wasted enough time on this and with you. Do your research into how controls work and how you actually draw them. I'm now remembering why I do not give detailed feedback because it is only met with arrogance and without any interest if there could possibly be a problem. My resolve, and im sure many other developers, is to simply not use the newer products and write the controls that I need for my market if the ones provided have any issues.

Best wishes.

re: Call Hierarchy

SvenC — Tue, 16 Jun 2009 22:52:44 GMT

@Royal, I'm not working for MS just with MS technology. I'm sorry that you are not willing to understand that SHBFF has no bug. It is used in many, many apps which do not crash by calling it. Sorry if I sounded arrogant - I only wanted to help you find the real cause of the problem. Good luck to get your code straight.

re: Call Hierarchy

Ben Voigt [C++ MVP] — Sun, 28 Jun 2009 05:22:45 GMT

This feature needs to go beyond just functions. Just like the browser has "Goto Declaration" and "Next Reference/Prev Reference" for variables, you should be able to use this tree for them as well.

Take a look at Lutz Roeder's .NET Reflector (now maintained by Red Gate Software) and the Analyze option it provides.

And I definitely think that identification of dead code should be done at design time, but I also agree that you can use the compiler instead of source code parsing (i.e. no need for the analysis to work with code that doesn't compile, which is the difference between Intellisense and the browser database created by the compiler). It should use the browser database, not run against the binary, because the type information is important as already noted with indirect calls.