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
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?
The Debug API reports DLL load events through a LOAD_DLL_DEBUG_INFO event. One of the structure's data members optionally holds the DLL's file name (lpImageName).
The character encoding of this field is described as:
If fUnicode is a nonzero value, the name string is Unicode; otherwise, it is ANSI.
Unicode presumably means UTF-16. Though it's unclear which codepage to use to interpret the ANSI encoding. There are multiple potential contenders (e.g. the originating process' default codepage, the system's codepage, the receiving process' default codepage, the receiving thread's current codepage, etc.).
Which codepage is it?
initially the debug event comes in the form DBGUI_WAIT_STATE_CHANGE
if use WaitForDebugEvent[Ex] api - it internally convert DBGUI_WAIT_STATE_CHANGE to DEBUG_EVENT by using DbgUiConvertStateChangeStructure[Ex]
when section (file mapping in win32 terms) created with SEC_IMAGE mapped in process, which is being debugged, the DbgLoadDllStateChange message send to debugger. DbgUiConvertStateChangeStructure[Ex] convert it to LOAD_DLL_DEBUG_INFO
note that original DBGKM_LOAD_DLL not containing any info about are in ansi or unicode was NamePointer. this is "unknown". the DbgUiConvertStateChangeStructure[Ex] always hard-code fUnicode = TRUE. this string, if exist, always in unicode.
This member is strictly optional. Debuggers must be prepared to handle
the case where lpImageName is NULL or *lpImageName (in the address
space of the process being debugged) is NULL. Specifically, the system
will never provide an image name for a create process event, and it
will not likely pass an image name for the first DLL event. The system
will also never provide this information in the case of debugging
events that originate from a call to the DebugActiveProcess function.
note, that lpImageName is pointer to pointer of a string (WCHAR** lpImageName can be say). in current implementation - this is always point to NT_TIB.ArbitraryUserPointer (not containing value of ArbitraryUserPointer but address of ArbitraryUserPointer)
formally can say lpImageName = &ptib->ArbitraryUserPointer where NT_TIB* ptib.
so lpImageName by self never 0, but *lpImageName (of course in target process address space) can be 0. when LdrLoadDll (or LoadLibrary) load dll, before map image section (call to ZwMapViewOfSection) set ArbitraryUserPointer to unicode string passed to LdrLoadDll as is. and restore original value of ArbitraryUserPointer after this. in case image name for a create process event, and image name for the first DLL (ntdll) here (in ArbitraryUserPointer 0) also it of course not valid when we receive debug events latter (case of DebugActiveProcess). so use lpImageName not reliable.
also interesing that in case load and unload image section (this is not always mean dll load/unload) (dwProcessId, dwThreadId) not of process/thread in which the debugging event occurred, but process/thread which call ZwMapViewOfSection or ZwUnmapViewOfSection. this is in general case different things, because possible map/unmap section in another process. however this is rarely case, but many debuggers (including windbg and from msvc) wrong handle this case and hung on it
I have an application which is multilingual, and I have to convert the VK scan codes to the appropriate character as specified by the current keyboard layout provided that they are mapped to some character representation and not just an action, state or other meta use. How would I accomplish this, such that it is portable across different Windows using different languages?
I could write a mapping function for the VK scan codes, but in the WinUser.h file, I'm reading stuff like:
#define VK_OEM_4 0xDB // '[{' for US
#define VK_OEM_5 0xDC // '\|' for US
#define VK_OEM_6 0xDD // ']}' for US
#define VK_OEM_7 0xDE // ''"' for US
Which indicates that if the keyboard isn't US, this could be different. There must be a function that I can call to do the appropriate mapping through the keyboard driver or something, right?
The reliable solution is to process WM_CHAR messages. Separating character input from keystrokes provide the mapping for you, and supports not only built-in Windows keyboard layouts but also IMEs, speech APIs, handwriting and other third party input methods. MapVirtualKey, ToUnicode and related functions rely on internal state in the Windows kernel with respect to deadkeys and so cannot be guaranteed to always return the correct character(s).
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.
I am currently trying to figure out how sms classes are correctly represented in SMPP. However I am by now completely confused by the standard and it's documentation.
In normal sms we have
Class0: Flash sms, which are shown on the display
Class1: Normal Sms to be stored on the sim or internally in the device
Looking at the SMPP spec, I first find the parameter data_coding in the submit_sm operation, which is used to set the DCS sent via MAP. As far as I understand this, if we want to explicitly set the message class we need to set the first four bits of this parameter to ones, then two bits indicating the coding and then another two bits indicating the message class. So for Class1 Sms, we would set 1111xx01. Is this correct so far?
If we try to set this DCS, however currently we also set the data coding to "8-Bit data". It seems, several phones are not able to understand this. Is this specified anywhere, and can we just change this, or is a special coding needed when sending other message classes.
More confusion arises, when we try to use the SMPPv3.4 recommended way of setting the Message class. Since 3.4 there is an optional parameter in the submit_sm operation, called dest_addr_subunit. According to the standard this parameter should be set to 0 for unknown, 1 for MS-Display, 2 for Mobile equipment, etc. If I look at this, it seems the parameters are shifted by one compared to GSM message classes. Class0 is encoded as 1, Class1 is encoded as 2 and so on. Is this correct or is there any more complicated mapping behind this?
Also, if we set dest_addr_subunit, do we still have to set DCS as well, or can we just leave this parameter at it's default value?
I recommend to read 3GPP TS 23.038 specification with detailed DCS (Data Coding Scheme) description.
In case of DCS bits 7654 are 00xx, you should check DCS for bit 4 value.
bit 4 == 0 - no message class for this message (bits 1 and 0 are reserved)
bit 4 == 1 - bits 1 and 0 contains message class
So you should set data_coding SMPP parameter in accordance to 3GPP TS 23.038 specification to handle message_class properly.
By default GSM SMS message has no message_class and this is not the same as message_class = 1.