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.
Related
My app is Win32; I'm using VS 2015. I have a dialog box that contains a listbox. I set the listbox to be dynamically resized, but it does not change when the dialog is resized.
Here are the listbox' attributes:
The listbox is owner-drawn:
This is the default size of the dialog:
This is what the dialog looks like when I stretch in Test mode in the Resource Workshop Dialog Editor. Notice the inside listbox expands too, exactly as hoped:
However, when it's actually running, stretching the dialog does not increase the size of the listbox:
Why is this not working? Is there some additional voodoo I have to invoke to get it to actually work? Does this only work in MFC? What is the Win32 equivalent of CWnd::ExecuteDlgInit?
Note: I have already looked at https://msdn.microsoft.com/en-us/library/mt270148.aspx and http://mariusbancila.ro/blog/2015/07/27/dynamic-dialog-layout-for-mfc-in-visual-c-2015/, wherein I did not find an answer.
Does this only work in MFC?
Indeed, this only works when using MFC1.
What is the Win32 equivalent of CWnd::ExecuteDlgInit?
MFC is a library built on top of the Windows API. The windowing system in the Windows API does not provide any sort of layout management. If you want to see the Windows API equivalent, it's literally what is implemented in MFC.
So, why is this supported in the graphical resource editor then? Because that is where the layout information is generated. It's ultimately placed into a custom resource of type AFX_DIALOG_LAYOUT, where MFC picks it up to do its magic. If you aren't using MFC, that resource is simply ignored.
That's not to say that - in theory - you wouldn't be able to implement your own solution that reads the generated resource. As long as you can find documentation for the custom resource used by MFC. I didn't, but a look into the MFC source revealed, that it's pretty simple (a version WORD, followed by pairs of WORDs for horizontal and vertical move and size settings).
1 Or a library that understands the implementation details, such as the WTL.
This functionality is also supported in Windows Template Library!
https://sourceforge.net/p/wtl/git/ci/master/tree/Include/atlframe.h
If you have a look at the CDynamicDialogLayout class you can see how it works, and if you are using WTL you can even use the functionality yourself.
For the record, I was looking for the solution to this as well, when I resized a control on my dialog all of the dynamic resizing stopped working, although it worked fine in the Test Mode.
To fix it, in the the second link you posted there's a section on adding a function:
void CMFCDynLayoutDemoDlg::SetupDynamicLayout()
Where you re-setup the Dynamic Layout manager
Once I did this, it started working in the live version for me.
Very similar answer is in this post too:
Recalculate dynamic layout properties
I am trying to replace all Windows Common (Open/Save) filedialog calls with my own custom dialog. From what I read so far, I could do this with a hook on the calls either by writing my own or by using libraries like detours or easyhook. But someone told me recently that such an approach is only possible pre-Vista, because of the change in sessions architecture and it is impossible to do such a switch in Win 7/8. Now, I am not a guy who likes the word 'impossible' :) So if you have any advice on the matter, any at all, please do tell and I will appreciate your kindness.
For what I what to do, my application will be run by the user, it will reside in the tray, and when the user calls for Open/Save dialog from any application, it should replace the default common dialog with a custom dialog.
The newer style Common Item dialogs are implemented as standard COM objects, so you could just implement your own DLL that exposes the same COM interfaces (IFileOpenDialog, IFileSaveDialog, etc) and then override the default registrations in the Registry with your own. That way, every app that uses the dialogs will load your DLL instead of Microsoft's.
I have a WIN32/C++ app and I want to create child windows in it that cannot be dragged out of the parent window. I want these windows to be owner-drawn, if it matters anyway. Should be simple enough; I'm looking for some basic guidance and tips regarding the subject.
It seems that you want to make an MDI app. This is much easier using a higher level framework such as MFC, WinForms, VCL etc., but can, of course, be done with plain Win32.
The MSDN documentation can be found here: Multiple Document Interface.
What you are looking for is called Multiple Document Interface (MDI).
I am writing a C++ application and I have a Login Box that's shown in a regular Dialog Box Frame. I see that some people can SKIN the entire dialog box and makes it look really nice. I was wondering if anyone can give me some pointers as to how to do that.
I'd need more details to give you a good answer.
The answer very much depends on which OS you're using and how you're programming your GUI (for example on Windows - plain Win32, MFC, ATL, Qt, Windows Forms, WPF etc etc).
If you're just using the Windows API here's a link to get you started.
http://www.codeproject.com/KB/dialog/skinstyle.aspx
Beware: custom skinning dialog boxes can be a very large task if you want to customise the look of every control as you end up writing very complicated custom controls.
Alternatively do you just want to make sure that your dialogs appear with Windows XP visual style rather than pre-XP style? This will require changes to your application to use the new common controls and visual style. Note that this changes the behaviour of some Windows APIs and can potentially have side effects (see ISOLATION_AWARE_ENABLED).
I'm trying to call the OpenThemeData (see msdn OpenThemeData) function but I couldn't determine what are the acceptable Class names to be passed in by the pszClassList parameter.
HTHEME OpenThemeData(
HWND hwnd,
LPCWSTR pszClassList
);
Could anybody tell me what are the acceptable class names that I can pass into that parameter?
Thanks!
The article Parts and States on MSDN contains a table which shows the control classes, parts, and states. The values in the table are defined in Vsstyle.h and Vssym32.h.
Here is a quick reference:
BUTTON, CLOCK, COMBOBOX, COMMUNICATIONS, CONTROLPANEL, DATEPICKER, DRAGDROP,
EDIT, EXPLORERBAR, FLYOUT, GLOBALS, HEADER, LISTBOX, LISTVIEW, MENU, MENUBAND,
NAVIGATION, PAGE, PROGRESS, REBAR, SCROLLBAR, SEARCHEDITBOX, SPIN, STARTPANEL,
STATUS, TAB, TASKBAND, TASKBAR, TASKDIALOG, TEXTSTYLE, TOOLBAR, TOOLTIP,
TRACKBAR, TRAYNOTIFY, TREEVIEW, WINDOW
The answer to the question Windows Visual Themes: Gallery of Parts and States? provides a "Parts and States Explorer" application where you can browse and test most of the styles.
I know this is an old question, but I want to give an updated answer (2018) for those who come here from Google.
The accepted answer of DavidK says to look into the file "AeroStyle.xml" where the themes are defined. This file was part of the Windows 7 SDK, but has been removed from the Windows 10 SDK, so the accepted answer is not useful anymore.
The answer of splash links to the MSDN where the list of theme names, parts and states is highly incompetlete and not updated.
The themes are drawn by UxTheme.dll which reads the images and colors, etc. from the file aero.msstyles in the folder C:\Windows\Resources\Themes\Aero on Windows 10.
To see the classes inside the XYZ.msstyles file use msstyles.Editor:
https://github.com/nptr/msstyleEditor
Several themes can only be obtained if you pass the correct window handle. There seems to be an automatic mechanism which detects the type of control from a window handle. If you pass the handle of the wrong window you may get another theme handle than expected or even NULL.
Microsoft internally has changed all their code to use OpenThemeDataForDpi() instead of OpenThemeData() because each monitor on Windows 10 may have a different resolution.
The problem that we have here is a severe lack of documentation in the MSDN and a lack of an API function to enumerate all availabe themes. Shame on Microsoft (once more).
You can look in "AeroStyle.xml" as a previous poster noted, which gives an exact list for Vista/Aero. However, if you want to play safe (and you probably do) the class names should, in general, be Windows class names of Windows common controls. For example, push buttons and check boxes use the class name "Button", the edit control "Edit", etc. I generally pick the class name of the control that's closest to whatever custom element I'm working on is, and use the theme data for that. That way you'll get code that works with XP, Vista and (hopefully) Windows 7, regardless of what the user's selected theme actually is.
However, unless you use raw Win32 a lot, you probably don't do much control creation directly using the class name. The class names are rather liberally sprinkled throughout MSDN. A good place to start is usually the "CommCtrl.h" file from the Platform SDK, which has a lot of them, and they're always described in the MSDN help on the individual common controls. You can also often learn them by looking at how dialogs are defined in .rc files by opening them in a text editor: these contain the class name for the controls.
Class names depend on the theme. For example, as the documentation for OpenThemeData states:
Class names for the Aero theme are
defined in AeroStyle.xml, which is
found in the Include folder of the
Microsoft Windows Software Development
Kit (SDK).
It has nothing to do with Aero, which even doesn't exits on XP !
See the source code of OpenThemeData()..