Office 2010 has a new type of ribbon, the backstage view. This has been implemented in MFC using Codejock Xtreme Toolkit Pro V15.0.1.
The thing is that I feel that the File>Open and File>SaveAs act very strange in Office. They open a modal file open dialog instead of opening an embedded file open dialog in the backstage, which would (IMHO) feel much more natural.
I cannot find a way of doing this in C++ using MFC or Win32. The only thing I found was this question, but that was for Delphi.
So, is it possible to embed the standard Windows File Open dialog as a control in another dialog? Or do I need to implement the entire thing myself?
To the best of my knowledge, The standard Open/Save dialog functionality is exposed through the modal dialog only (through the GetOpenFilename Win32 API).
There is a standard mechanisme to customise the dialog (See Skizz answer) but it remains a modal dialog. One case of advanced customisation was the VB6 Open Project dialog:
The Existing tab contains a file dialog. How did they do it? I mean, how did they manage to put a standard dialog into a page of their 3-tabs property sheet?
It appears that they simply used the standard customization dialog and added a tab control above the standard dir/file controls and listview for other 'tabs' above dir/file controls. These dir/file controls were then hidden by the custom code when a tab other than Existing was clicked. You get it: no real tabs! Just a good old file dialog where the main controls may be hidden in favor of other ones.
So my short answer is: You're pretty much out of luck using the dialog as a child control.
Now, to come back to Office: I believe it's better to keep a modal dialog. It would otherwise be confusing to user: Is the path that I started to type the real path of did I just clicked 'Home' and let the save command unfinished?
I don't know if you can embed a file open dialog into another dialog, but you can certainly extend the existing dialogs:-
Here's one implementation.
And another.
And an MSDN version.
Thanks to David for pointing out the above are a bit out of date, so, after a quick Google, here's a more modern take on extending the file dialogs (and lots of other stuff as well).
Related
My English is not perfect, sorry.
I am using Visual C++ 2019 Community, with MFC.
At CFileDialog class, I wish choose the file encoding: UTF-16 (little/big endian), UTF-8, ANSI, etc, at saving, with or without signature (2 or bytes what signs the encoding, at the begin of the file). This should be contacted to open/save button. In documentation of CFileDialog, I can add only separate buttons, not extending the open/save button like in Visual Studio, LibreOffice, etc. How can I do this? I am beginner with MFC, and desktop programs, but not beginner with C++. Thank you.
In the comments to your question you state:
Yes, I know. But there is no place to write this. Handler of Open menu is built-in part of MFC. At the source code, CFileDialog is not happen. I added handler OnFileOpen(). This has not paramters, empty at now, and the open menu item manages well. So, I do not know to where I type OFN_ALLOWMULTISELCT.
If you look at Technical Note 22 it mentions:
ID_FILE_OPEN Opens an existing document.
Note
You must connect this to your CWinApp-derived class's message map to
enable this functionality.
CWinApp::OnFileOpen has a very simple implementation of calling
CWinApp::DoPromptFileName followed by CWinApp::OpenDocumentFile with
the file or path name of the file to open. The CWinApp implementation
routine DoPromptFileName brings up the standard FileOpen dialog and
fills it with the file extensions obtained from the current document
templates.
One common customization of ID_FILE_OPEN is to customize the FileOpen
dialog or add additional file filters. The recommended way to
customize this is to replace the default implementation with your own
FileOpen dialog, and call CWinApp::OpenDocumentFile with the
document's file or path name. There is no need to call the base class.
As you can see, it states:
The CWinApp implementation
routine DoPromptFileName brings up the standard FileOpen dialog and
fills it with the file extensions obtained from the current document
templates.
But DoPromptFileName seems to be an undocumented function. You can either:
Debug into to MFC source code to see what it does and override it in your own app class,
Continue to roll out your own CWinApp::OnFileOpen override which uses your own CFileDialog.
I suggest you also read up on CFileDialog constructor documentation because it will assist you for basic customization. However, it sounds to me you need to do what #sergiol said in the comments and display your own CFileDialog (using either approach previously described) and add your own combo with your encoding options. Then handle accordingly.
Please note that I have no experience with that level of customization but it should get you going.
I want to create a file open dialog with wxwidgets that uses the "new" style of the Common Item Dialog under Win-Vista and newer. Is there any way to achive this? With the wxFileDlg() I get a dialog as shown on the right side but I'd like to get th left dialog...
both dialogs
The dialogs sample included in wxWidgets shows the example of "new style" file dialog if you use e.g. "Dialogs|File operations|Save dialog" menu item (or just press Ctrl+S) and there is nothing special to do. If this doesn't work for you, check that you're
Not using some ancient version of wxWidgets.
Have correct manifest in your application.
Not using any custom controls in your dialog, as those are only supported in old style version.
I struggled with this today so thought I would post here for the next person who has the same issue. If I were to guess, your code was calling either dialog.Center() or dialog.CenterOnParent(). I've posted a lengthy explanation of why this happens here.
From all my time spent on this today, you have to choose whether you want have the old common control dialog and be able to center it, or use the new common item dialog and have it appear in your windows top-left corner.
The good news is that Visual Studio, Word, Excel, Firefox, Chrome, and many others all use the new dialog and they all open at the top-left of the application window.
I have a ribbon application that designed based on Extensible Application Markup Language (XAML) in c++. I want to change the icon of one button when i click on it.
How can i change the icon?
My application is not MFC, I use Windows API.
You can't change the icon of a button when clicking, at least not in a regular way. The API doesn't support this, I guess for the reason that the UI Ribbon UI concept doesn't intend such a behavior (and you may want to think twice, before breaking an "intended behavior").
Anyway, you could force such a behavior by loading a resource file that refers to the very same XML definition (XML by the way, NOT XAML - we are not in the WPF world here), with the only exception being the source path of the regarding icon referring to something different.
The relevant API call for this is called IUIFramework::LoadUI.
My question is :
what is the main difference between Common File Dialog and Common Item Dialog ?
The MSDN just said that :
Starting with Windows Vista, the Common Item Dialog supersedes the
older Common File Dialog when used to open or save a file.We recommend
that you use the Common Item Dialog API instead of the Common File
Dialog API.
but it has not explained that what is the change log or main difference between them ?
thank for any help.
Common File Dialog was just a custom DialogBog. On the other end, Common Item Dialog is a full COM server.
Microsoft's documentation says :
The Common Item Dialog implementation found in Windows Vista provides several advantages over the implementation provided in earlier versions:
Supports direct use of the Shell namespace through IShellItem instead of using file system paths.
Enables simple customization of the dialog, such as setting the label on the OK button, without requiring a hook procedure.
Supports more extensive customization of the dialog by the addition of a set of data-driven controls that operate without a Win32 dialog template. This customization scheme frees the calling process from UI layout. Since any changes to the dialog design continue to use this data model, the dialog implementation is not tied to the specific current version of the dialog.
Supports caller notification of events within the dialog, such as selection change or file type change. Also enables the calling process to hook certain events in the dialog, such as the parsing.
Introduces new dialog features such as adding caller-specified places to the Places bar.
In the Save dialog, developers can take advantage of new metadata features of the Windows Vista Shell.
Simply it is harder to use from a simple low-level Win32 program.
I have an MFC app that uses AfxMessageBox to display message boxes. The app itself lets an end-user to change the user interface language. On the inside it does so by loading resources using LCIDs (or FindResourceEx API.) My issue is that I can't seem to make AfxMessageBox to take LCID to change the language for OK, Cancel buttons, etc. This also affects File and Folder Open dialog windows.
Any ideas how to do this?
PS. This approach must work under Windows XP and up.
According to this SO article, there are no standard functions for this, there's a link to a CodeProject article "Localizing System MessageBox" with source code for a DLL (it's in c# but seems simple enough to be rewritten in C++) which uses Windows Hook so that you can supply your own text for the MessageBox buttons; there's even a suggestion for sizing buttons to the text in the discussion part of the same article.