Just wanted to thank you for your example. I have been working on a method to bypass the right click popup menu in the CFileDialog. This has been a problem in restricted netwrok configurations. If the popup menu is allowed to become active, the operator has the ability to delete, reanme or cause other havoc in the system.
Thanks Again, it is a great example of the windows dialog we have all come to know and use...
I found some features are not implemented compare with standard file dialog box:
1) Multiple file selection
2) Right mouse click
3) File deletion
4) New item will never show when the dialog box is still opening
5) Refreshing the list(F5)
Implementing those features will sure make the program even better.
Xiaolong has definitely done a fantastic job at replacing the standard File Open dialog and for all the reasons he states - I've long thought of writing something similar because of the restrictions with the standard Microsoft offering (inability to use with Property Pages & Form Views etc).
Two small criticisms though. Firstly there are very few comments, over and above the standard ones generated by Visual C++. This is a great shame because some parts of the program are heavily recursive and aren't very easy to follow. Second problem is that whenever any change is made to the List Control view (such as displaying a new directory) every single drive on your system gets re-read for no apparent reason. It's quite easy to stop this once you understand the program but it can be very irritating at first. Apart from those minor points though, brilliant!
Your code is pretty usefull. I fand some bugs that I fixed in order to use it in a small application. All of them were in CFileDlg.
In OnInitDialog(), you have to use ScreenToClient() with the different RCs you fetch with GetWindowRect(). Otherwise if you have a new dialog , everything will displaced.
In Traverse(), do not forget to initialize
LPCITEMIDLIST pidlInsideCopy = NULL;
LPITEMIDLIST pidlInside = NULL;
and to test their value:
if (pidlInside == NULL)
Sometimes, the test:
if (!SUCCEEDED(pEnumIDList->Next(1, &pidlInside,&lFetched)) || lFetched != 1)
works, even if pidlInside is set to NULL, and it makes the application crash due to: CopyItemID(pidlInside).
A next step in this work could be to modify Traverse() so that it does not test the floppy (pFolder->GetAttributesOf(1, &pidlInsideCopy, &ul);) each time you change of directory.
To make a more reusable class code, it would be a good idea
to put all strings in the resources, in other languages
there is no "Desktop" or "Folder" --"Escritorio" and
"Carpeta" in Spanish.
But your class has been very useful for me,
I just working on a file selection class on a Wizard.
Definitly needs improvement. Especially the fake combobox. For one the correct icons are not displayed. Also
it would be easier to use a ComboBoxEx control. The correct icons are also not displayed in the report view
either. It would be better to use the system imagelist. It would also be better to use
GetLogicalDriveStrings() to get all the available drives rather trying to switch to each one. Like I said
I found a bug in the CLookInBox::DrawItem(LPDRAWITEMSTRUCT lp) member function. if lp->itemID is
negative ( this is possible see the doc on DRAWITEMSTRUCT structure ) the program crashes, ( very frequently
on my dual processor NT Box ) and asserts in CObArray.
Here is a fix that works:
UINT id = lp->itemID;
if ( (int)id >= m_aryItemInfo.GetSize() ) ) return;
int id = lp->itemID;
if ( ( id < 0 ) || ( id >= m_aryItemInfo.GetSize() ) return;