Visual C++ Team Blog

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

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?

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?"

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.

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?

@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

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;

}

@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.

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.

@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.

[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.

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.

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.

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.

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.

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.

@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.

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.