Actually am trying to get the font used in a windows form control which is running from the other application by using WM_GETFONT with SENDMESSAGE function but am ending always with 0 even if the font of the control is not System font. Plz.... help me out.
Thanks in advance....!
Each control decides what font or fonts it uses. Controls intended to be used inside a dialog box should support WM_SETFONT and WM_GETFONT since that is how the dialog manager sets the dialog font. For all other controls, support for these messages is optional. Windows Forms controls do not appear in dialog boxes (they appear on Forms) so there is no reason to expect them to support WM_SETFONT or WM_GETFONT. If you know that you have a Windows Forms control, then you can use the appropriate Windows Forms methods and properties to get the font.
Related
I have an idea for a text formatting tool that would be a useful within a number applications.
Is it possible to create an application that would popup when triggered by a hot key or icon click (trigger method not too important) and then give the user options to reformat the text in the active text box of whatever application is active.
I suspect there might be some standard winapi way to do this that would work on many applications but would not work on apps that are using proprietary text box widgets. Is this the case ?
I have a program which was created in VS2008 with MFC.
Now I've modified it to make it "Per Monitor DPI-Aware", and it's almost done. I've modified the manifest and handled the WM_DPICHANGE message. But there's still one problem:
I used CFileDialog class to show Open/Save dialogs, and used SHBrowseForFolder function to show folder selection dialog. But all these dialogs are NOT "Per Monitor DPI-Aware", they won't adjust their UI when you move them between monitors with different DPI settings.
I use spy++ to monitor messages of these dialogs, I find they can receive WM_DPICHANGED message but they just don't handle it.
And I've tested the open file dialog in notepad.exe on Windows 10, it worked perfectly.
Does anyone know how can I make these dialogs "Per Monitor DPI-Aware"?
--------EDIT--------
There're two more problems:
When I move a window to a monitor with different DPI, the window resize itself, but the height of it's title bar and title font-size are not changed.
The checkbox controls' box size is not changed either.
I feel these problems may have some kind of connections, but I can't figure it out.
--------SAD NEWS--------
I compiled microsoft's "DPI Tutorial Sample" with VS2013, and it has the same problem.
https://code.msdn.microsoft.com/DPI-Tutorial-sample-64134744
The titlebar (caption bar) can be scaled by calling EnableNonClientDpiScaling which is available on versions of Windows >= the Windows 10 Anniversary Update (1607).
If you want to DPI scale an older dialog that doesn't support per-monitor DPI scaling you can use SetThreadDpiAwarenessContext (with DPI_AWARENESS_CONTEXT_SYSTEM_AWARE or DPI_AWARENESS_CONTEXT_UNAWARE) to have the top-level windows of the dialog scaled by Windows. The dialog might be blurry but it will at least be sized correctly (also only available on >= 1607 builds of Windows 10). The usage pattern is to call this API before opening the dialog and then restore the previous DPI context immediately after calling the API.
According to MSDN the window that processes WM_DPICHANGED message should return 0. However, any MFC window or control you send WM_DPICHANGED will return 0, since thay call the default window procedure for the unknown messages.
Therefore, judging if some window does process WM_DPICHANGED message by testing its LRESULT return value against zero is not accurate.
The window's title bar of a per-monitor DPI aware application doesn't scale when moving across different DPI monitors as documented on MSDN. Unfortunately, non-client area of the window never adjust the DPI.
Calculator and other per-monitor DPI aware Windows native apps have custom title bar drawing, as described here.
I simply created a Windows Forms application in Visual Studio using the template and launched it. I want to receive text input without using a standard text box. When the form is active, I'm able to change the input language. But I cannot change IME mode. E.g. when the input language is Japanese, the IME mode icon in the tray becomes a circle with a cross in it. When I hover the mouse over, the tooltip says "IME disabled". Any ideas? Thanks in advance.
A lot of applications on Windows show plain message boxes just with "Yes"/"No" or "OK"/"Cancel" buttons. Often it gets worse on non-English Windows' that the text is in English, but the buttons are labeled in the Windows' language.
Is there no simple API to show a message box with own button labels, e.g. "Delete" or "Keep"?
There is indeed such a Win32 function. It is TaskDialogIndirect. Note that it was introduced in Vista and so if you are still attempting to support XP, then you would need to provide a fall back option for that platform.
Like DavidHeffernan said, you should use TaskDialogIndirect(), as it natively supports custom buttons. It is only available on Vista and later, though.
On XP and earlier, you can customize the button captions on a standard MessageBox() (or really, any customization you want) by using SetWindowsHookEx() to install a thread-local WH_CBT hook, or use SetWinEventHook(), to obtain the dialog's HWND when it is created, then you can manipulate the dialog however you want. You can use GetDlgItem() to get the HWND of the individual buttons (and can thus use standard API functions/messages with them), and/or use GetDlgItemText() to change their captions. The CtrlID of each button is the same value that MessageBox() returns when that button is clicked.
This Projct on Codeproject provides a pretty good drop in replacement for MessageBox, that allows to replace buttons labels among other features.
It is basically a rewritten MessageBox function that is a superset of the standard Windows MessageBox function. Full source code is provided so you can adapt is easily to your needs if needed.
And it's pure Win32, no MFC is involved here.
I want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.