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.
I wanna ask if someone can provide me a c++ code in which I can hide/show the pointer of the mouse when pressing a specific key..
I found several codes written for only TURBO C++, none of which can be compiled and run using dev c++ or even visual c++..
I tried running the codes I found in Dev C++ but I only get lots of errors and incompatibilities..
I also found several articles that says I can use the function ShowCursor but it just wouldn't work..
In fact hiding the cursor can turn out to be quite a task, depending on what you want to achive. If you're programming a GUI-application using the WinAPI it is pretty easy.
Just calling ShowCursor(false); once might turn out not to work in some cases though, since the ShowCursor function only "sets an internal display counter". The cursor is displayed until this counter is smaller than 0 (see msdn on it). You could try something like this:
while(ShowCursor(false)>=0);
to ensure the counter gets below 0.
This will however only hide the cursor inside your applications window, if you're using newer Windows versions like Windows 7. Hiding the cursor all over the system could turn out to be a lot more difficult.
If you are programming a console application ShowCursor won't show any effect as far as I've tested it. Using the following code:
while(ShowCursor(false)>=0);
std::cout<<ShowCursor(false)<<std::endl;
std::cout<<ShowCursor(true)<<std::endl;
we can see, that the counter definitely is below 0, but still the cursor is displayed. I haven't come up with a solution to this so far.
If you look at the documentation for the SetCursor function, setting the cursor to a NULL handle (e.g SetCursor(NULL)) will remove the cursor from the screen.
The title pretty much says it all. I've created a window with namedWindow() and filled it with a matrix. I then assign it to a HWND using cvGetWindowHandle() so that I can use the Windows function SetWindowPos(). Using this I'm supposed to be able to set the flags HWND_TOPMOST, SWP_NOMOVE and SWP_NOSIZE in order to keep it above all other windows even when I click on a window behind it.
I've either misread something here and got the wrong idea or I believe that the problem might be the fact that I have upgraded to Windows 8 and they have deprecated this function or something. Is there another way to go about this?
I don't have a setup to try this in c++, but I wanted to do something similar in python so I ended up using a python win32 library. With a combination of the following calls (I assume you can find them for win32 in c++), I always managed to get the screen on top. But it didn't stay there. I had to bring it up when I wanted it.
win32gui.SetForegroundWindow(hwnd) # I use just this. apparently it can trigger permission error but I never had a problem with it
win32gui.SetFocus(hwnd) # apparently doesn't trigger error without permission like setforegroundwindow
win32gui.BringWindowToTop(hwnd) # not sure if this helps any
win32gui.SetActiveWindow(hwnd) #not sure if this helps any
I have a problem with unicode filenames appearing as question marks in my edit boxes.
When I paste unicode characters in an edit box, for example Arabic or Thai, they show correctly, but after I run this code, they become question marks. How come?
WCHAR buf[100];
GetWindowTextW(hWndEditBox, buf, 100);
SetWindowTextW(hWndEditBox, buf);
Another thing - the project is ANSI (we have code that can't be ported so the entire project stays ANSI), i.e. _UNICODE macro is undefined, but I explicitly use the Unicode versions of the filenames.
The GetWindowText function actually sends a WM_GETTEXT message to the window (hWndEditBox). Since you're using the *A functions rather than the *W function (specifically CreateWindowExA in this case, I think) your message loop will be converting from wide characters to multi-byte characters using some locale.
Your only solution here seems to be changing the entire window setup - if your code that requires ANSI is not related to UI this should be possible. Alternatively, you may be able to replace the edit box with rich edit boxes, that provide extra messages (such as streaming, for example).
You may want to check whether it is the GetWindowTextW call or the SetWindowTextW call that is doing the bad conversion - if GetWindowTextW works correctly you may be able to convert to multibyte using the correct locale before you set it.
Finally, you can try adjusting the thread's code page before reading the text, though this may cause all sorts of other issues. The usual advice is to use Unicode.
Sources: GetWindowText and this comment from Raymond Chen on his blog.
A useful answer to address SetWindowTextW()is given in https://stackoverflow.com/a/11515400/1190077 :
intercept the resulting WM_SETTEXT message and re-route it to DefWindowProcW() instead of DefWindowProc().
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()..