Related
Let's say you've just set some text in a spellcheck-enabled rich edit control, and the text has some spelling errors. A split second will go by, spellcheck will kick in, and then the misspelled text will get underlined. But guess what: the rich edit control will actually send an EN_CHANGE notification just for the underlining event (this is assuming you've registered for notifications by doing SendMessage(hwnd, EM_SETEVENTMASK, 0, (LPARAM)ENM_CHANGE)).
Is there a workaround to not get this type of behavior? I've got a dialog with some spellcheck-enabled rich edit controls. And I also want to know when an edit event has taken place, so I know when to enable the "Save" button. Getting an EN_CHANGE notification merely for the spellcheck underlining event is thus a problem.
One option I've considered is disabling EN_CHANGE notifications entirely, and then triggering them on my own in a subclassed rich edit control. For example, when there's a WM_CHAR, it would send the EN_CHANGE notification explicitly, etc. But that seems like a problem, because there are many types of events that should trigger changes, like deletes, copy/pastes, etc., and I'd probably not capture all of them correctly.
Another option I've considered is enabling and disabling EN_CHANGE notifications dynamically. For example, enabling them only when there's focus, and disabling when focus is killed. But that also seems problematic, because a rich edit might already have focus when its text is set. Then the spellcheck underline would occur, and the undesirable EN_CHANGE notification would be sent.
I suppose a timer could be used, too, but I think that would be highly error-prone.
Does anybody have any other ideas?
Here's a reproducible example. Simply run it, and it'll say something changed:
#include <Windows.h>
#include <atlbase.h>
#include <atlwin.h>
#include <atltypes.h>
#include <Richedit.h>
class CMyWindow :
public CWindowImpl<CMyWindow, CWindow, CWinTraits<WS_VISIBLE>>
{
public:
CMyWindow()
{
}
BEGIN_MSG_MAP(CMyWindow)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
COMMAND_CODE_HANDLER(EN_CHANGE, OnChange)
END_MSG_MAP()
private:
LRESULT OnCreate(UINT, WPARAM, LPARAM, BOOL& bHandled)
{
bHandled = FALSE;
LoadLibrary(L"Msftedit.dll");
CRect rc;
GetClientRect(&rc);
m_wndRichEdit.Create(MSFTEDIT_CLASS, m_hWnd, &rc,
NULL, WS_VISIBLE | WS_CHILD | WS_BORDER);
INT iLangOpts = m_wndRichEdit.SendMessage(EM_GETLANGOPTIONS, NULL, NULL);
iLangOpts |= IMF_SPELLCHECKING;
m_wndRichEdit.SendMessage(EM_SETLANGOPTIONS, NULL, (LPARAM)iLangOpts);
m_wndRichEdit.SetWindowText(L"sdflajlf adlfjldsfklj dfsl");
m_wndRichEdit.SendMessage(EM_SETEVENTMASK, 0, (LPARAM)ENM_CHANGE);
return 0;
}
LRESULT OnChange(WORD, WORD, HWND, BOOL&)
{
MessageBox(L"changed", NULL, NULL);
return 0;
}
private:
CWindow m_wndRichEdit;
};
int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
{
CMyWindow wnd;
CRect rc(0, 0, 200, 200);
wnd.Create(NULL, &rc);
MSG msg;
while (GetMessage(&msg, nullptr, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return (int)msg.wParam;
}
Also, it appears that using EM_SETMODIFY and EM_GETMODIFY don't help. I guess the spellcheck underlining results in a EM_SETMODIFY, so checking that flag in the handler is of no avail.
because documentation about CHANGENOTIFY ( must contains information that is associated with an EN_CHANGE notification code, but not..) is wrong - only research exist.
in my test i view that EN_CHANGE related to Spellcheck received only when rich edit handle WM_TIMER message. so solution is next - subclass richedit and remember (save in class member variable) - when it inside WM_TIMER. than, when we handle EN_CHANGE - check are richedit inside WM_TIMER.
partial POC code. i special show more complex case - if several (more than one) child richedit`s exist in frame or dialog winndow
#include <richedit.h>
class RichFrame : public ZFrameMultiWnd
{
enum { richIdBase = 0x1234 };
bool _bInTimer[2] = {};
public:
protected:
private:
static LRESULT WINAPI SubclassProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
if ((uIdSubclass -= richIdBase) >= _countof(_bInTimer))
{
__debugbreak();
}
bool bTimerMessage = uMsg == WM_TIMER;
if (bTimerMessage)
{
reinterpret_cast<RichFrame*>(dwRefData)->_bInTimer[uIdSubclass] = TRUE;
}
lParam = DefSubclassProc(hWnd, uMsg, wParam, lParam);
if (bTimerMessage)
{
reinterpret_cast<RichFrame*>(dwRefData)->_bInTimer[uIdSubclass] = false;
}
return lParam;
}
virtual BOOL CreateClient(HWND hWndParent, int nWidth, int nHeight, PVOID /*lpCreateParams*/)
{
UINT cy = nHeight / _countof(_bInTimer), y = 0;
UINT id = richIdBase;
ULONG n = _countof(_bInTimer);
do
{
if (HWND hwnd = CreateWindowExW(0, MSFTEDIT_CLASS, 0, WS_CHILD|ES_MULTILINE|WS_VISIBLE|WS_BORDER,
0, y, nWidth, cy, hWndParent, (HMENU)id, 0, 0))
{
SendMessage(hwnd, EM_SETLANGOPTIONS, 0,
SendMessage(hwnd, EM_GETLANGOPTIONS, 0, 0) | IMF_SPELLCHECKING);
SetWindowText(hwnd, L"sdflajlf adlfjldsfklj d");
SendMessage(hwnd, EM_SETEVENTMASK, 0, ENM_CHANGE);
if (SetWindowSubclass(hwnd, SubclassProc, id, reinterpret_cast<ULONG_PTR>(this)))
{
continue;
}
}
return FALSE;
} while (y += cy, id++, --n);
return TRUE;
}
virtual LRESULT WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_COMMAND:
if (EN_CHANGE == HIWORD(wParam))
{
if ((wParam = LOWORD(wParam) - richIdBase) >= _countof(_bInTimer))
{
__debugbreak();
}
DbgPrint("EN_CHANGE<%x> = %x\n", wParam, _bInTimer[wParam]);
}
break;
case WM_DESTROY:
{
UINT id = richIdBase;
ULONG n = _countof(_bInTimer);
do
{
RemoveWindowSubclass(GetDlgItem(hwnd, id), SubclassProc, id);
} while (id++, --n);
}
break;
case WM_NCDESTROY:
PostQuitMessage(0);
break;
}
return __super::WindowProc(hwnd, uMsg, wParam, lParam);
}
};
Use EM_CANUNDO (maybe also EM_CANREDO) to verify that contents has changed. I hope that spellchecker does't add any undo information.
I recently tried to work around this without subclassing but it was only somewhat successful.
My alternative workaround consists of marking the entire document as CFE_PROTECTED. In the EN_PROTECTED handler ENPROTECTED::msg is WM_NULL when coming from the spell checker and you can set a flag telling yourself to ignore the next EN_CHANGE. To allow actual spelling corrections from the context menu you also need to keep track of menus.
This feels rather fragile but so does tracking WM_TIMER.
I'm having trouble detecting a hover over a static Win32 control.
This is not a duplicate issue because this looks for multiple static controls instead of just looking for a single known handle to a static control at compile time.
While this can be done in seconds in another language, I'm growing a little frustrated after trying things out for some hours. I hope to get an answer here.
First, I created a class called Label. I create a static control window within it. I'll refer to static as label for now on.
// Create the label's handle.
m_handle = CreateWindowEx(NULL, "static", m_text.c_str(),
WS_CHILD | SS_LEFT | SS_NOTIFY, m_x, m_y, m_width, m_height,
m_parentWindow, (HMENU)(UINT_PTR)m_id, m_hInstance, NULL);
if (m_handle == NULL)
return false;
When the mouse hovers over this label, the following method should be called:
void Label::invokeOnMouseHover()
{
if (m_onMouseOver)
m_onMouseOver();
}
This will call my method:
void lblName_onMouseOver()
{
MessageBox::show("Hovering!", "My Console",
MessageBoxButtons::Ok, MessageBoxIcon::Information);
}
This is how I create it from the top level:
Label lblName("This is a label.", 0, 0);
lblName.setVisible(true);
lblName.OnMouseOver(lblName_onMouseOver);
frm.add(lblName);
Admit it, this thin layer is beautiful.
While my callbacks are working fine for my Button and Checkbox controls, I noticed that statics are a little different.
So, let's go down a few levels:
This is in the main window's procedure:
case WM_MOUSEMOVE:
{
int xPos = LOWORD(lParam);
int yPos = HIWORD(lParam);
frm.setMousePos(xPos, yPos);
// Get the static's id
int id = // ?? Which static control id is it out of several?
// Obtain the control associated with the id.
X3D::Windows::Control *ctrl = frm.getControls().find(id)->second;
if (ctrl == NULL)
return 0;
// Check if this is a X3D Label control.
if (typeid(*ctrl) == typeid(X3D::Windows::Label))
{
Label *lbl = dynamic_cast<X3D::Windows::Label*>(ctrl);
int xPos = GET_X_LPARAM(lParam);
int yPos = GET_Y_LPARAM(lParam);
if (xPos >= lbl->getX() &&
yPos >= lbl->getY() &&
(xPos < (lbl->getX() + lbl->getWidth())) &&
(yPos < (lbl->getY() + lbl->getHeight())))
{
if (lbl != NULL)
lbl->invokeOnMouseHover();
}
}
}
break;
What I'm trying to do here is detect what label id was detected, and then call Label::invokeOnMouseOver().
Even though I Understand I need to use TRACKMOUSEEVENT at some point, its field member 'HWND' requires the label's handle. But I can't easily say which handle it will be because the collection may contain one or several labels.
Overall, I'm looking for suggestions on how to either restructure this or see if there's an easy solution here. My guess is I'm overthinking this.
Thanks.
Update:
Here is a code update after reading the first answer with the first solution. While this solves the hover issue, I don't see the label's text on execution.
case WM_MOUSEMOVE:
{
int xPos = LOWORD(lParam);
int yPos = HIWORD(lParam);
// Get the mouse position
frm.setMousePos(xPos, yPos);
// Check for labels
X3D::Windows::Control *ctrl = (X3D::Windows::Control*)GetWindowLongPtr(hWnd, GWLP_USERDATA);
if (ctrl)
{
// Check if this is a X3D Label control.
Label *lbl = dynamic_cast<X3D::Windows::Label*>(ctrl);
if (lbl)
lbl->invokeOnMouseHover();
return CallWindowProc(lbl->getOldProc(), hWnd, msg, wParam, lParam);
}
}
break;
And the control creation:
// Create the label's handle.
m_handle = CreateWindowEx(NULL, TEXT("static"), m_text.c_str(),
WS_CHILD | SS_LEFT | SS_NOTIFY, m_x, m_y, m_width, m_height,
m_parentWindow, (HMENU)(UINT_PTR)m_id, m_hInstance, NULL);
if (!m_handle)
return false;
SetWindowLongPtr(m_handle, GWLP_USERDATA, (LONG_PTR)(X3D::Windows::Control*)this);
m_oldProc = (WNDPROC)SetWindowLongPtr(m_handle, GWLP_WNDPROC, (LONG_PTR)&wndProc);
If it's a paint issue, this is what I have in WndProc.
case WM_PAINT:
{
hDC = BeginPaint(hWnd, &ps);
EndPaint(hWnd, &ps);
return 0;
}
break;
Update #2:
The alternative solution fixed the issue.
If anyone has trouble with unresolved external symbols with SetWindowSubclass() in the future, remember to add the following to your project or just #pragma it:
#pragma comment(lib, "comctl32.lib")
The only identifying info that WM_MOUSEMOVE gives you is the HWND that the mouse is moving over (or the HWND that has captured the mouse). The reported X/Y coordinates are relative to that HWND. That is the HWND that you are looking for, so you don't need to hunt for it, the message gives it to you.
If you need access to an HWND's control ID, you can use GetDlgCtrlID() for that. But note that every HWND has its own window procedure, so control IDs are typically only useful for notification messages, like WM_COMMAND and WM_NOTIFY, which are sent to a control's parent window (and even then, such notifications also carry the child's HWND as well).
When the mouse moves over a particular HWND, WM_MOUSEMOVE is posted to the message procedure of that HWND only (or to the HWND that has captured the mouse). It sounds like you are expecting it to be posted to the control's parent window instead, and that is simply not the case. That is why your WM_MOUSEMOVE handler is not being called. You are handling the message at the wrong level. You need to be prepared to handle messages on a per-control basis instead, using the control's own message procedure.
It would be more efficient to store your Control object's this pointer inside its associated HWND itself, via SetWindowLongPtr(GWLP_USERDATA), SetWindowSubClass(), or SetProp(), and then your message handlers can access the Control* pointer of the message's reported HWND when needed, for example:
// Create the label's handle.
m_handle = CreateWindowEx(NULL, TEXT("static"), m_text.c_str(),
WS_CHILD | SS_LEFT | SS_NOTIFY, m_x, m_y, m_width, m_height,
m_parentWindow, (HMENU)(UINT_PTR)m_id, m_hInstance, NULL);
if (!m_handle)
return false;
SetWindowLongPtr(m_handle, GWLP_USERDATA, (LONG_PTR)(X3D::Windows::Control*)this);
m_oldproc = (WNDPROC) SetWindowLongPtr(m_handle, GWL_WNDPROC, (LONG_PTR)&MyWndProc);
...
LRESULT CALLBACK MyWndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
case WM_MOUSEMOVE:
{
...
X3D::Windows::Control *ctrl = (X3D::Windows::Control*) GetWindowLongPtr(hWnd, GWLP_USERDATA);
if (ctrl)
{
// Check if this is a X3D Label control.
Label *lbl = dynamic_cast<X3D::Windows::Label*>(ctrl);
if (lbl)
lbl->invokeOnMouseHover();
}
break;
}
...
}
return CallWindowProc(m_oldproc, hWnd, uMsg, wParam, lParam);
}
Alternatively:
// Create the label's handle.
m_handle = CreateWindowEx(NULL, TEXT("static"), m_text.c_str(),
WS_CHILD | SS_LEFT | SS_NOTIFY, m_x, m_y, m_width, m_height,
m_parentWindow, (HMENU)(UINT_PTR)m_id, m_hInstance, NULL);
if (!m_handle)
return false;
SetWindowSubclass(m_handle, &MySubclassProc, 1, (DWORD_PTR)(X3D::Windows::Control*)this);
...
LRESULT CALLBACK MySubclassProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
switch (uMsg)
{
case WM_NCDESTROY:
RemoveWindowSubclass(hWnd, &MySubclassProc, uIdSubclass);
break;
case WM_MOUSEMOVE:
{
X3D::Windows::Control *ctrl = (X3D::Windows::Control*) dwRefData;
// Check if this is a X3D Label control.
Label *lbl = dynamic_cast<X3D::Windows::Label*>(ctrl);
if (lbl)
lbl->invokeOnMouseHover();
break;
}
...
}
return DefSubclassProc(hWnd, uMsg, wParam, lParam);
}
This post doesn't answer the question you asked but you should read it. It is important, and it is posted in a spirit of helpfulness after my rather acid comment above. I hope you find it so.
This class library is going to run into trouble. Code like this (using a dynamic_cast):
case WM_MOUSEMOVE:
{
X3D::Windows::Control *ctrl = (X3D::Windows::Control*) dwRefData;
// Check if this is a X3D Label control.
Label *lbl = dynamic_cast<X3D::Windows::Label*>(ctrl);
if (lbl)
lbl->invokeOnMouseHover();
break;
}
Is almost always wrong.
Why? Well, suppose you want to hover over some other kind of control? What are you going to do now? And these guys are just going to multiply like rabbits, so don't do that.
Instead, for a message that the library understands (such as this one), declare a corresponding virtual method in the base class that derived classes can override if they're interested in processing that message. Then you have the basis of a solid design (and this is pretty basic stuff).
So, in this case you would have:
class Control // Base class
{
...
virtual void onMouseHover (...) { }
...
};
And then:
class Label : public Control // Derived class
{
...
virtual void onMouseHover (...) override { ... }
...
};
Now for my second point: you are going to find that, particularly for dialogs, your application is going to want to handle a lot of messages that the base class doesn't understand (or care about).
How are you going to do this? Are you going to add code to the base class for each new message that your application (or for that matter specific types of control implemented in the class library) becomes interested in? That is not a very attractive prospect.
Now MFC handles this with something it calls a message map, which is essentially a table of message ID's and their corresponding command handlers which you can associate with (in your case) any object ultimately derived from Control and I recommend you do something similar.
But thanks to the magic of the STL, you can do better. I have something like this in my class library (my base class is actually called Window, as I would suggest yours should be):
typedef INT_PTR (Window::*MESSAGE_HANDLER)
(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam);
// Register a message handler
void Window::RegisterMessageHandler (UINT uMsg, MESSAGE_HANDLER handler);
And what RegisterMessageHandler() actually does is to add handler to a std::unordered_map associated with the Window object using uMsg as a key. Then, when that message subsequently comes in, it can be dispatched to the right handler without the base class knowing anything about the meaning of the message whatsoever, and that's what you're going to need.
So, you might declare the following in class Control (code untested, written in Notepad):
class Control // Base class
{
...
std::unordered_map <UINT, MESSAGE_HANDLER> m_message_map;
...
};
And then RegisterMessageHandler() might look like this:
void Window::RegisterMessageHandler (UINT uMsg, MESSAGE_HANDLER handler)
{
m_message_map.emplace (uMsg, handler);
}
And MySubclassProc() might look like this:
LRESULT CALLBACK MySubclassProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
X3D::Windows::Control *ctrl = (X3D::Windows::Control*) dwRefData;
auto handler ctrl->m_message_map.find (uMsg);
if (handler != ctrl->m_message_map.end ())
return handler.second (hWnd, uMsg, wParam, lParam);
...
}
My own class library is actually more sophisticated than this (I started with something simple but then embellished it over time) but that's the basic idea. You might have to master a few C++ skills to pull this off but trust me, if you implement something like this you'll be very glad you did, down the line.
It definetly works, but in a strange way.
I'm replacing RichEdit control's procedure with
WNDPROC g_OrigREditText =
(WNDPROC)SetWindowLongPtr( g_hwnd_RichEdit, GWLP_WNDPROC, (LONG_PTR)REditWndProc);
Then, I SendMessage to RichEdit control using EM_REPLACESEL msg, and the text appears in the RichEdit control as it should. But when I replace standard procedure with my own, and process EM_REPLACESEL in mine own procedure, then the following scenario happens. Here's the code:
LRESULT CALLBACK REditWndProc( HWND hwnd, UINT msg, WPARAM wp, LPARAM lp )
{
switch( msg )
{
case EM_REPLACESEL:
{
int sdfsdf = 0;
CallWindowProc( (WNDPROC)g_OrigREditText, hwnd, msg, wp, lp );
break;
}
default:
return DefWindowProc( hwnd, msg, wp, lp);
break;
}
return 0;
}
Ok, I send an EM_REPLACESEL message to the RichEdit as usual and it works well, cos I catch operation pointer in "case EM_REPLACESEL" block.
Then CallWindowProc should do its job by passing parameters to the next procedure in the chain, but instead nothing happens, the text doesn't appear in a RichEdit control. Looks like something prevent the message to be passed to old procedure, but! if I replace g_OrigREditText with REditWndProc, then I catch the same UINT msg again, so it definetely pass parameters further, like it should.
So what's wrong with CallWindowProc or with my code, where should I dig to fix the problem?
The whole thing is called "subclassing" and this can be useful .
usually there are more events that occurs in relating with one message so change your code to this
LRESULT CALLBACK REditWndProc( HWND hwnd, UINT msg, WPARAM wp, LPARAM lp )
{
if( msg == EM_REPLACESEL)
{
// whatever you want
return TRUE;// comment this
// if you want to give it to the original proc.
}
return CallWindowProc( g_OrigREditText, hwnd, msg, wp, lp );
}
I have a main window in a process that is not owned by the program I'm creating. I'm using a Windows Hook to inject a DLL into this process for the purpose of adding a child window to this main window.
My end goal was to create a WS_EX_LAYERED window that allows me to create an internal colored border but allow the center portion to be transparent and allow mouse clicks through. This part works perfectly.
WNDCLASS wndClass = {};
wndClass.style = CS_HREDRAW | CS_VREDRAW;
wndClass.lpfnWndProc = OverlayProc;
wndClass.hInstance = g_TargetInstance;
wndClass.hbrBackground = (HBRUSH)CreateSolidBrush(RGB(0, 255, 255));
wndClass.lpszClassName = "OVERLAY";
RegisterClass(&wndClass);
g_Window = CreateWindowEx(WS_EX_LAYERED | WS_EX_TRANSPARENT, "OVERLAY", nullptr,
WS_CHILDWINDOW, rect.left, rect.top, rect.right+1, rect.bottom+1, data->hwnd, nullptr, g_TargetInstance, nullptr);
SetLayeredWindowAttributes(g_Window, RGB(0, 255, 255), 0, LWA_COLORKEY);
ShowWindow(g_Window, SW_SHOW);
UpdateWindow(g_Window);
The 2nd part to this is a I wanted to conditionally block all mouse input to the parent window. I couldn't do this with the transparent portion of the WS_EX_LAYERED window so I tried creating a 2nd transparent STATIC control as a child of the main window but this doesn't block mouse input either.
I'm also sending simulated mouse clicks to the parent window through calls to PostMessage, passing WM_LBUTTONDOWN and WM_LBUTTONUP. How could I block all mouse input to the parent window via a transparent window?
It appears this is not possible to do with a simple transparent window drawn over sibling controls. What I ended up doing was using SetWindowHookEx to add a WH_GETMESSAGE hook into the process from which I use to replace the main window's WndProc function and intercept mouse messages. I tag my simulated mouse messages with a specific value in the wParam argument so the proc will now it was simulated and removes that value, passing it along to the parent window.
If it does not detect my "tag" value in the click message, it will swallow the mouse message and not pass it along to the original WndProc function.
Injected WndProc replacement
LRESULT CALLBACK WndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
switch (uMsg)
{
case WM_LBUTTONDOWN:
wParam -= 11141008;
if (wParam != MK_LBUTTON && !g_Paused)
return 0;
break;
case WM_LBUTTONUP:
wParam -= 11141008;
if (wParam != 0 && !g_Paused)
return 0;
break;
case WM_MOUSEHOVER:
case WM_MOUSEMOVE:
if (!g_Paused)
return 0;
}
return DefSubclassProc(hWnd, uMsg, wParam, lParam);
}
Snippet from Windows Hook function
//...
switch (data->message)
{
case (WM_USER + 1):
{
g_Paused = FALSE;
//...
SetWindowSubclass(data->hwnd, WndProc, 1, 0);
break;
}
case (WM_USER + 2):
{
RemoveWindowSubclass(data->hwnd, WndProc, 1);
//...
break;
}
}
//...
The code inside the window hook function is used to subclass the main process window and inject my own WndProc function which in turn processes mouse input the way I want.
This is the code used to "simulate" mouse clicks without physically clicking in the window. Note the added value to wParam to identify this click as simulated and not generated by the user.
void Window::LeftClick(DWORD x, DWORD y, DWORD delayMillis)
{
LPARAM lparam = MAKELPARAM(x, y);
lock_guard<mutex> lock(this->m_ClickMutex);
PostMessage(this->m_Window, WM_LBUTTONDOWN, 11141008 + MK_LBUTTON, lparam);
this_thread::sleep_for(std::chrono::milliseconds(delayMillis));
PostMessage(this->m_Window, WM_LBUTTONUP, 11141008, lparam);
}
Also, just for the person in the comments who was ridiculing my choice of the word simulated and the added criticism for using PostMessage to simulate keyboard input, here is my keyboard input test method which (for my purposes) works flawlessly and very reliably
void GameWindow::KeyPress(UINT vkCode) const
{
UINT scanCode = MapVirtualKey(vkCode, MAPVK_VK_TO_VSC);
LPARAM lparam1 = MAKELPARAM(1, scanCode);
LPARAM lparam2 = MAKELPARAM(1, 0xC000 | scanCode);
PostMessage(this->m_Window, WM_KEYDOWN, vkCode, lparam1);
this_thread::sleep_for(chrono::milliseconds(25));
PostMessage(this->m_Window, WM_KEYUP, vkCode, lparam2);
}
I'm trying to fix SHBrowseForFolder dialog, as it doesn't react on folder renaming (BFFM_SELCHANGED isn't being sent and there is no way to determine is the path now correct or not). I googled a solution, which said like I have to subclass dlg's wndproc and catch TVN_ENDLABELEDIT to send BFFM_SELCHANGED myself.
Here is how I set new wndproc when I get BFFM_INITIALIZED:
for (HWND hChild = GetWindow(hWnd, GW_CHILD); hChild != 0; hChild = GetWindow(hChild, GW_HWNDNEXT)) {
szClassName[256];
GetClassName(hChild, szClassName, sizeof(szClassName));
if (!stricmp(szClassName, "SHBROWSEFORFOLDER SHELLNAMESPACE CONTROL")) {
oldWndProc = reinterpret_cast<WNDPROC>(SetWindowLongPtr(hChild, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(_SubclassWndProc)));
break;
}
}
Here is _SubclassWndProc:
static LRESULT _SubclassWndProc(HWND hWnd, UINT uMsg, WPARAM lParam, LPARAM lpData) {
switch (uMsg) {
case WM_NOTIFY:
switch (((LPNMHDR)lParam)->code) {
case TVN_ENDLABELEDIT:
break;
}
break;
}
return CallWindowProc(oldWndProc, hWnd, uMsg, lParam, lpData);
}
It works only if I comment WM_NOTIFY block. Even an access to lParam breaks dialog (it contains corrupted treee with empty labels). If I call oldWndProc before switch, then it works, but in WM_NOTIFY case lParam obviously doesn't contain a pointer to NMHDR, it contains a small integer value like 1,2,100 etc.
Edit: The question can be shortened to "Why does WM_NOTIFY come without a pointer to NMHDR?"
The error was due to my negligence: I copied wndproc signature from some example, which has agrument names confused. The lParam usually comes last and has a type LPARAM. So I was trying to cast arg usually called wParam, which contains a control id not LPNMHDR.