The documentation for WM_NOTIFY is easy enough to find, however I'm finding a fair amount of sample code and articles that refer to WM_REFLECT_NOTIFY, for which I can't find any documentation.
What is WM_REFLECT_NOTIFY, where can I find the documentation for it and how is this message different from WM_NOTIFY?
Example references:
Flickering in listview with ownerdraw and virtualmode
ListViewSubItem.Bounds almost works
WM_REFLECT_NOTIFY is referred to as having value of 0x204E, that is 0x2000 + WM_NOTIFY. Typical use of message reflection is to send back notification to its origin so that supposedly subclassed control could handle notification itself.
Hence the knowledge you are possibly missing and looking documentation for is that the control sends WM_NOTIFY to its parent in a regular way. And the parent does SendMessage with the same message parameters back to the control using message number 0x2000 + original Msg. The meaning of the parameters wParam, lParam is supposed to be the same of original message (WM_NOTIFY in your case).
The constant 0x2000 might possibly vary from framework to framework or be otherwise private agreement between controls and hosting windows.
MFC and ActiveX controls, for instance, reflect WM_NOTIFY messages making them OCM_NOTIFY messages, where (olectl.h):
#define OCM_NOTIFY (OCM__BASE + WM_NOTIFY)
#define OCM__BASE (WM_USER+0x1c00)
and finally (winuser.h):
#define WM_USER 0x0400
That is, the OCM_NOTIFY is 0x204E, just as your WM_REFLECT_NOTIFY. The MSDN docs on those from here: Reflected Window Message IDs.
Related
I was experimenting on a simple window to gain insights into the creation process. And I noticed some strange messages. Some was received by WinProc exclusively, others only appeared in message loop (GetMessage), DispatchMessage probably filtered them (0x60)? Some was passed to DefWindowProc by the loop (like 0x31F).
I suspect that Unique WMs you can see in the bottom might be from some random processes or Windows. And WM_TIMER is not passed to DefWindowProc because Dispatch calls it's callback, instead.
But what are this strange undocumented Windows-area messages? It's hightly unlikely that it can be from some random process, as I didn't disable UIPI for them via filters. I still get them in Admin mode, so it's either some rouge Admin program, or more likely OS itself.
I know that Registered WMs are from 4t Tray Minimiser program I use, but when I unload it, the undocumented ones still come in.
As you can see, 0x60 is very often repeated on window focus changes... Also, what could that WM_TIMER be?
EDIT:
Question is reduced and optimized in response to community's comments. The deleted part of the question will be posted as separate question.
QUESTION:
Is there any WM_SOMETHING or NM_SOMETHING message in Win32 API that can inform me about user changing the locale?
You see, I could use that message/notification to change my program's locale to the current locale.
Something like this pseudo-code:
case WM_SOMETHING: // in my main window procedure
_wsetlocale( LC_ALL, L"" );
Also, if there is such message, and I process it as in the pseudo-code above, will it adjust only main window's locale or will it also set locale for child dialog boxes and controls?.
MY EFFORTS TO SOLVE THIS:
After browsing through Internet, the only thing I found was WM_INPUTLANGCHANGE, WM_SETTINGCHANGE and WM_INPUTLANGCHANGEREQUEST messages, but I have never used them and do not know if they can solve my problem.
Thank you.
Best regards.
Windows sends a WM_SETTINGCHANGE message, with the wParam set to 0, and the lParam set to a character string containing the value intl. This is described in the documentation for WM_SETTINGCHANGE under the Parameters section:
wParam
...
When the system sends this message as a result of a change in locale settings, this parameter is zero.
lParam
...
When the system sends this message as a result of a change in locale settings, this parameter points to the string "intl".
Your application will need to respond to the message and make any necessary changes yourself in child dialogs and controls.
I cannot find this info anywhere, including in the official Windows API documentation. It is sent to the subclassing procedure when the control loses focus. It is not defined in winuser.h.
It is sent like this:
0x02D - WM_DELETEITEM
0x167 - ???
0x202 - WM_LBUTTONUP
My compiler is MinGW, system Windows XP SP3.
0x167 is in the range of messages that is reserved for system use. Messages in this range that are not explicitly defined in the SDK are private for the system's internal use. This is stated as much in the documentation:
#define WM_USER 0x0400
.
0 through WM_USER –1
Messages reserved for use by the system.
Message numbers in the first range (0 through WM_USER –1) are defined by the system. Values in this range that are not explicitly defined are reserved by the system.
The 0x167 message respond for selecting text in combo edit control
Context: I have a piece of code that knows the value of a waveOut handle (HWAVEOUT). However the code did not create the handle, thus the WAVEFORMATEX that was passed to waveOutOpen when creating the handle is unknown.
I want to find out the contents of that WAVEFORMATEX struct that was passed to the waveOutOpen call.
Some more details where this is used: The code runs in a hook function that's invoked instead of waveOutWrite. Thus the code knows the handle value, but does not know the details of the handle creation.
Just so that people do not need to look it up:
The signature of waveOutOpen is
MMRESULT waveOutOpen(
LPHWAVEOUT phwo,
UINT uDeviceID,
LPWAVEFORMATEX pwfx,
DWORD dwCallback,
DWORD dwInstance,
DWORD fdwOpen
);
The signature of waveOutWrite is:
MMRESULT waveOutWrite(
HWAVEOUT hwo,
LPWAVEHDR pwh,
UINT cbwh
);
Note: I am also hooking waveOutOpen, but it could already be called before I have a hook.
You can't get this information from the wave API. You'll have to get it from whoever opened the wave device.
You can get the playback rate using waveOutGetPlaybackRate(), and knowing that, you could (in theory) know cell size by timing how long it takes to play a buffer of known size. (0 is always silence) But 8 bit stereo will end up taking the same amount of time to play back as 16 bit mono. same with float/32 bit mono and 16 bit stereo.
I'd say that 99% of the time 16 bit stereo will the the right answer, but when you guess wrong, the result sounds really bad (and loud!) so guessing may not be a good idea.
You can also use waveOutMessage() to send custom messages to the wave driver. It's possible that there is some custom_query_wave_format message, but there is no message like that defined in the standard. It's assumed that whoever opened the wave device will keep track of what format (s)he opened it with.
You access the pwfx item of the waveOutOpen struct just as you would access any other struct.
myWaveOutOpen.pwfx.wFormatTag
Or the equivalent format in your language.
Your question is hard to understand. I'm not sure what you want...?
I have customer that uses older, custom built ERP application for which they don't have source code and company that developed it does not exist any more. Application is developed in 2000 and it's built with Delphi. Since last executable is from 2003, it could be D6 or D7.
On one important form there are some fields where customer would like to display additional data from other databases and asked me if it's possible to "duct tape" data over existing form.
First idea I got is to build application that will:
browse list of windows target application creates and find controls on form
attach "some" event when to get notified when target form is displayed
attach "some" event when to get notified when field on target form is changed
display additional information in small window overlaying target form
Are there any examples on how to do something like this. I searched google with variations of this question title, but without success.
Note - rewriting of ERP application is not planned.
About language - I can do it with C# or Delphi.
I'm going to answer this from a purely C & Win32 point of view, because I don't know Delphi or its libraries. Converting this to C# can be accomplished via p/invoke, but some parts may/will need to be unmanaged.
First off, no guarantees. If the target application is doing windows-less controls (if there isn't an HWND under every on-screen control) you're pretty much out of luck. This isn't all that uncommon, so yeah...
Step 1, register a window hook listening for new windows created by the target process*:
//dllHMod is an HMODULE that refers to the DLL containing ShellHookProc
HHOOK hook = SetWindowsHookEx(WH_SHELL, ShellHookProc, dllHMod, 0);
// error handling, stashing hook away for unregistering later, etc...
LRESULT CALLBACK ShellHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if(nCode < 0) return CallNextHookEx(NULL, nCode, wParam, lParam);
if(nCode == HSHELL_WINDOWCREATED)
{
WindowCreate((HWND)wParam);
}
return 0;
}
WindowCreated(HWND) should stash the HWND away if the correct process (determined via GetWindowThreadProcessId) owns it. At this point, you'll be able to get every top-level window owned by the target process. Note that registering a global hook carries a notable performance penalty, not that it really matters in your case but you should expect it.
Now for the fun part. There's no reliable way to tell when a window is fully constructed, or when its done rendering (there are ways to tell when it STARTS rendering, but that doesn't really help). My advice, guess. Just throw some arbitrary wait in there and then try and enumerate all the child windows.
To enumerate child windows (if you know enough about the target window, there are better ways to do this; but I'm assuming a search is easiest):
//targetHWND is an HWND of one of the top-level windows you've found
EnumChildWindows(targetHWND, ChildWindowCallback, NULL);
//more code...
BOOL ChildWindowCallback(HWND window, LPARAM ignored)
{
if(IsTargetWindow(window)) { /* Do something */ }
return TRUE;
}
Implementing IsTargetWindow is another tricky part. Hopefully you'll find some reliable test for doing so (like checking the class name, window name, style, something; look at GetWindowInfo).
Once you have the window you want to monitor, you can use SetWindowLongPtr and GWLP_WNDPROC to watch all messages it receives. This will require code injection (and thus unmanaged code) and is awfully low level. I'd advise against it if you could possibly avoid it, but lacking the source...
I think this answers is a decent starting point, but once again this is going to be incredibly painful if its even possible at all. Good luck.
*Alternatively, if you know that the target app doesn't create windows except at startup (or at detectable/predictable points in time) you can use EnumWindows.