CFileDialog

will1383

Hi All, I'm having a problem creating a custom dialog box. I need to limit the user to only be able to browse the folders below a certain folder. I'm trying to figure out how to trap the "Button Up" message on the toolbar properly so I can check the next folder going up and therefore prevent the user from going up any more directories. The problem is that no matter what I do, even in processing the up Button message and returning TRUE so the default windows doesn't process the message, the message still gets processed and the user is allowed to go up past my limit. I tried capturing the last message after the app gets updated, and then revert back to the limit folder, then signaling the window to update again as well. But that still didn't work. :confused: Any ideas? Thanks! Dan

Heath Stewart

You might try the SHBrowserForFolder function instead. It doesn't provide a wrapper class in MFC that I know of, but it's simple enough to use. You can set the root, limit the types of items that can be selected, and even have files show up (despite the function name containing "browse" and "folder") in newer (albeit not so new) function versions using a simple flag.

-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----

will1383

I'll give that a whirl. Thanks for the suggestion. probably not quite what I'm looking for but I might be able to make it work. I'll keep ya posted. thanks! :-D

will1383

Heath Stewart wrote: You might try the SHBrowserForFolder function instead :-( not exactly what I was looking for. I need the same look/feel as the FileOpen Dialog. Thanks for the hint though. I guess I just need to keep looking. Anyone else have an idea?

Heath Stewart

Okay, then there is several options you can do to really fix the CFileDialog. The following alternative uses MFC's CFileDialog (since that seems to be what you want to use), but you could just as easily use the method that it wraps, GetOpenFileName. First, create an instance of the CFileDialog. When you've done that, get the m_ofn member struct from the instance and perform the following.

OR the Flags member of the OPENFILENAME structure with OFN_ENABLEHOOK. You might also want to OR it with OFN_NODEREFERENCELINKS while you're at it to keep users from making a shortcut to a location outside your limited scope.
Set the lpfnHook to a HOOKPROC callback.

From there, your options are many. In WM_INITDIALOG, you could simply remove the the "Up" button entirely based by getting the toolbar in which its contained (based, perhaps, on the window class for the toolbar which Spy++ can give you, which is ToolbarWindow32, or getting it based on the tooltip or some other identifier) or handling the message generated when you click the up button. Spy++ reports this as either WM_USER+300 (aka 1) or WM_USER+302 (aka 2) (both were posted as 1211 (based on aforementioned aliases). What those mean you'll have to dig-up. All the other messages were mostly painting and mouse messages - nothing that would seem to help. It's surprising that handling the click messages and returning true didn't help. Did you handle WM_LBUTTONUP? That directory change is triggered then and not during WM_LBUTTONDOWN. Just out of curiosity, how did you determine if the "Up" button was being clicked?

-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----