Is it possible to restrict a file dialog(open/save) to a specific folder is winapi?
OPENFILENAME fileDialogSettings;
...
fileDialogSettings.lpstrInitialDir = "Some path";
...
if(GetOpenFileName(&fileDialogSettings))
{
}
I want to have "Some path" as root path in the dialog and to restrict navigation to this folder and it's sub folders only. May I use lpfnHook for this?
If you're targeting Vista+ only, you can make use of the IFileDialogEvents::OnFolderChanging method to block the change altogether.
For older versions of Windows, the OpenFileDialog allows you to specify a hook procedure in which you can pick up on the CDN_FOLDERCHANGE notification.
While I can't see any message to disallow the change, you may be able to post a message to tell it to go "back", or just disable the "OK" button.
Another option is to handle CDN_FILEOK notification and refuse paths outside your required directory.
See this MSDN article for more details about the hook procedure.
This question also talks about changing the directory in an open dialog.
Look into OFN_NOCHANGEDIR flag, although the documentation says this:
Restores the current directory to its original value if the user
changed the directory while searching for files.
This flag is ineffective for GetOpenFileName.
Edit: Reading your question again, I guess you don't want the user to navigate up from that directory, not sure if this is possible with GetOpenFileName, you might have to create your own dialog with a directory list view and restrict them that way.
Related
My task is to program change sorting parameter of files and folders in my operating system.
In the article on the MSDN:
under
Modifying the Windows Explorer Toolbar
indicated
In addition to modifying the Windows Explorer menu bar, you can also add buttons to the toolbar. And an example code.
But example of this modifying the Windows Explorer menu bar is not there, the only thing is there it's button adding example.
An alternative article has an example of opening it, so my question is: is it even possible, and if it is, how to do it?
The folder sort settings are saved to:
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
The entries look like:
You would need to loop through all of these registry entries and change the 'Sort' key. This would only affect folders which have already been accessed.
If you want to see how these lists are parsed, run ShellBagsView while running ProcMon and log all the interactions with the registry.
To do it, not programatically you can follow these instructions:
https://superuser.com/a/1481763/1043059
In my app I open a report using HTML file as such:
//pStrPath is file:///C:/Users/appts/AppData/Local/Temp/Report_View.htm
ShellExecute(hParentWnd, L"", pStrPath, NULL, NULL, SW_SHOW);
On my development machine it opens up in a web browser, but when I just tested it on a new installation of Windows 10, it showed this dialog instead:
So how can I prevent it from being shown and go with "keep using this app" option from the get-go? Otherwise it may be very confusing for my users.
PS. Note that Edge is installed and can open .htm files if I double-click them.
Referring to Launching Applications (ShellExecute, ShellExecuteEx, SHELLEXECUTEINFO) we note the text
Object Verbs
The verbs available for an object are essentially the items that you find on an object's shortcut menu. To find which verbs are available, look in the registry under HKEY_CLASSES_ROOT\CLSID{object_clsid}\Shell\verb
Commonly available verbs include:
edit - Launches an editor and opens the document for editing.
find - Initiates a search starting from the specified directory.
open - Launches an application. If this file is not an executable
file, its associated application is launched.
print - Prints the document file.
properties - Displays the object's properties.
Given that a double-click is the generally equivalent to selecting "open" in the object's shortcut menu, if we supply the function with the open verb, we can expect the behaviour to mirror that of a user's double-click. - Please see Ken's comment below
As such, we can expect the following code to achieve the desired result.
//pStrPath is file:///C:/Users/appts/AppData/Local/Temp/Report_View.htm
ShellExecute(hParentWnd, L"open", pStrPath, NULL, NULL, SW_SHOW);
If you are trying to open the default program FROM a 32 bit program in 64 bit Windows the ShellExecute and ShellExecuteEX may display the "How do you want to open this file?" dialog box each time. This is due to the way that the default program registered itself in Windows I think.
I could reproduce this error on Windows 11 fresh install where the Photos is set to the Default Program for .jpg files.
In my case, I found that if I use the ShellExecuteExW function and pass the extension into the .lpClass of SHELLEXECUTEINFOW Type that it works.
It should also work with the ShellExecuteExA function
Make sure it's not an exe, reg, bat file, or a URL you are trying to open. It has to be a document type of file.
Use the .lpClass to pass the extension like ".jpg"
Add the SEE_MASK_CLASSNAME As Long = &H1 to the .fMask parameter you are passing in like .fMask = YourMaskValue Or SEE_MASK_CLASSNAME
The reason I think this works is it bypasses any redirection and reads directly from the HKEY_CLASSES_ROOT.jpg
I am trying to wrap my head around Microsoft's shell extension context menu handler example.
Its implementation only shows a context menu on a .cpp file right-click. I want to try to extend it to allow it to show the context menu whenever a folder, drive, or empty space is right-clicked in Explorer as well.
So far I was only able to modify it to register right-clicks for all file types, not just .cpp files by specifying * when registering it:
hr = RegisterShellExtContextMenuHandler(L"*",
CLSID_FileContextMenuExt,
L"CppShellExtContextMenuHandler.FileContextMenuExt");
I must be missing something else because it won't pop up for folders. I have tried this suggestion but it did not work.
How can I extend this sample to also have it work for folders? Am I missing something from the registry?
Edit: Thanks to Igor's suggestion, I got it to work for folders and drives, but it does not show up when you right-click the desktop or when you right click blank space in a folder, and I did register for Directory\Background and DesktopBackground. Why is this?
Using CFileDialog as a file open, I need to allow the user to only select a file that is displayed in the dialog list area, such as by clicking on it. We don't want the user to be able to type in a name in the File Name control. The OPENFILENAME (OFN) struct has several different flags (http://msdn.microsoft.com/en-US/library/ms646839%28v=vs.80%29.aspx), but I don't see one that prevents the user from typing in a filename.
The closest thing I saw was OFN_FILEMUSTEXIST, but that only specifies that the file exists; it still allows the user to type in a name.
Is there any way to do this without inheriting a new class?
MORE INFO
We need to prevent them from typing in a filename because they could open an inappropriate one. With the lpszFilter parameter, we filter the filenames so it only displays files with ABC in the filename (not the extension). So if they typed in a filename, they could enter something like myCoolFileDEF.ext. If the file exists, it will go ahead and let them open it (the dialog will close w/o an error message) even though they were only supposed to open files with ABC in the filename.
Since you are using MFC, just inherit a CFileDialog and disable the file name edit control and combobox. I don't see the point of using CFileDialog AND writing another OFNHookProc callback, though you could start from GetOpenFileName if you want to.
As a previous answer notes, you could root around in the dialog for the filename control and disable it. This is not without penalty though - if you turn on the CFileDialog hook callback logic, you get the "old style" file dialog on Vista and above, not the "new style" one. The "new style" file dialog is a lot more restrictive in what can be customized, and, as far as I know, doesn't provide a supported way to get at the filename control.
Reading your question, my first instinct is that you're over-designing your solution: if you supply a filter then the user has to go to quite a lot of trouble to select the wrong sort of file, and most users won't do that. If they do, it's possible that the user knows better than your program. If it were me, I would just use a filter, then after the file dialog has closed, check the returned filename - if it doesn't match the required pattern, I'd put up a message dialog to ask if the user if they're really sure, and open the file anyway if they insist that they are.
I would like to add an edit box (or is it a combo box?) for entering a file-path using Visual C Win32 so that it offers auto-complete - the same as when you type in Windows Explorer's address bar.
Is there a common control or property I'm missing that allows me to do that?
You can use the standard edit control and call SHAutoComplete. Like this:
SHAutoComplete(editWnd, SHACF_DEFAULT);
The system will do the rest for you.
There is no Common Control for that. What you can do, however, is use a standard Edit control and attach the IAutoComplete interface to it, which can be configured to use the file system (amongst other things) as a source for getting string values from. The easiest way to do that is to call the SHAutoComplete function.