let's say I've got a handler of the wm_paste message in a CEdit descendant:
LRESULT CMyEdit::OnPaste(WPARAM wParam, LPARAM lParam)
{
//do some processing
return 0;
}
and let's say that in some cases I want to trigger the default behaviour for paste
from this method. How do I do it? CEdit::OnPaste does not exist...
Cheers
Call CWnd::DefWindowProc, passing it WM_PASTE, wParam and lParam.
Typically the OnXxx handlers in base classes consist of a single line that calls DefWindowProc -- if CEdit::OnPaste existed, that's what it would do.
You can also simply call CWnd::Default. This function, which is defined in wincore.cpp, uses _afxThreadState.GetData() to obtain the information on the message that is currently being processed and then calls CWnd::DefWindowProc.
I mention that because if you used the ON_WM_PASTE() macro in the message map and thus have no parameters to the OnPaste function then the solution mentioned by Tim Robinson will not work since there are no wParam and lParam parameters to pass to CWnd::DefWindowProc.
Related
I am implementing logic to handle global mouse clicks and I stuck at moment where I need to get data from LowLevelMouseProc. Currently, I am setting global variable at point when I am creating instance of MyClass and I able to access it from LowLevelMouseProc, but I suppose that isn't right approach.
Setting hook:
g_myClass = this;
SetWindowsHookEx(WH_MOUSE_LL, MyClass::MouseHookProc, LoadLibraryA("user32.dll"), 0);
LowLevelMouseProc:
LRESULT CALLBACK MyClass::MouseHookProc(int nCode, WPARAM wParam, LPARAM lParam) {
MOUSEHOOKSTRUCT * pMouseStruct = (MOUSEHOOKSTRUCT *)lParam;
g_myClass.onClick(wParam, pMouseStruct->pt.x, pMouseStruct->pt.y); //isn't good
}
The low level mouse hook offers no mechanism by which you can retrieve an instance pointer. Using a global variable is often the best option.
If you cannot make your program work that way you will need to use a thunk. That technique has been discussed in many places and a web search will provide more detail. For instance a cursory search on my part yielded this: http://zabkat.com/blog/hook-callback-thunk-x64.htm
I had to rewrite a custom file dialog (derived from MFC's CFileDialog) to WTL's CFileDialog. I have a bit of a problem to retrieve data when I don't have access to the dialog object itself. Imagine the following.
I have a member in the class
static WNDPROC m_wndProc;
I initialize it in the following static member fnct.
void CMyFileDialog::OnInitDone(LPOFNOTIFY lpon)
{
m_wndProc = (WNDPROC)::SetWindowLong(thisHWND, GWL_WNDPROC, reinterpret_cast<long>
(&CMyFileDialog::WndProcSelect));
}
The handle comes into the callback method with no problem and I can "connect" to it with CWindow
LRESULT CALLBACK CMyFileDialog::WndProcSelect(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
// ...
CWindow callerWnd(hwnd);
}
And here, I don't know the real methodology to convert the CWindow to my CMyFileDialog. As I think, this CWindow class is just connected somehow to the handle itself, but does not the same object as it was created before. So for example, if I have a CString or other members in my CMyFileDialog, it won't access its state, because it was created in another object.
I think you are doing something wrong here. You have access to the message map without having to modify the WndProc (that is something that the CFileDialogImpl will have already done).
See for example http://www.codeproject.com/Articles/12999/WTL-for-MFC-Programmers-Part-IX-GDI-Classes-Common#usingcfiledialog, where they simply
BEGIN_MSG_MAP(CMyFileDialog)
CHAIN_MSG_MAP(CFileDialogImpl<CMyFileDialog>)
END_MSG_MAP()
You could always use SetWindowLongPtr with your "this" pointer, then it would be fairly easy to extract the pointer to your CMyFileDialog.
I'm trying to limit the access of the users of my program to the keyboard. To do that I've defined a low level keyboard hook:
LRESULT CALLBACK lowLevelKeyboardProc(int key, WPARAM wParam, LPARAM lParam)
{
KBDLLHOOKSTRUCT* pkbhs = (KBDLLHOOKSTRUCT*)lParam;
switch (key)
{
case HC_ACTION:
....
and hooked it:
m_hHook = SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)lowLevelKeyboardProc, 0, 0);
I need the users to be able to use only the alphanumeric chars, ~, #, # ... only the chars that can be in a password (printable chars).
What would be the easiest way to differentiate between those chars and all the others using the low level keyboard hook parameters: int key, WPARAM wParam, LPARAM lParam ?
The program is written in c++ and compiled in VC2010.
All help is appreciated!
Before actually answering your question, I have a couple of questions for you:
Why would you want to do this globally, using a global low-level keyboard hook?
Although sometimes they are the only way to solve a problem, using a global hook like this is generally strongly discouraged for many reasons. There are many better ways of preventing a user from entering invalid or unacceptable data. For example, I would just disable the keys you don't want for a particular control or set of controls (e.g. all textboxes). That way, the user can still use keyboard shortcuts and other non-alphanumeric keys to interact with your application, which is critical for accessibility reasons. Remember that a global hook will affect all of the other threads running on the machine, not just your app—that is probably not what you want.
Even if you do decide to use a global hook, are you sure that you really need to disable all of the non-alphanumeric keys? What about Backspace and Delete? Shouldn't the user be able to delete things? And what about Tab? Enter? And what about modifier keys, like Shift, Ctrl, and Alt: are those allowed?
Please seriously reconsider whether you really need a low-level hook before continuing forward with this design. If you need help on devising another solution, please ask a new question, describing what you want to accomplish (e.g., I want to prevent users from entering any non-alphanumeric characters in a textbox control; here is the code I use to create my textbox…).
But if you insist on ignoring my advice, the solution is rather simple: investigate the members of the KBDLLHOOKSTRUCT structure that is passed to the hook procedure. The vkCode member gives you the virtual key code of the key that was pressed. Chances are, that is all the information you need. But just in case it's not, the hardware scan code of the key is also provided in the scanCode member.
Unfortunately, the code that you currently have is wrong. The first parameter to the hook callback procedure is indeed an int, but it is not a key code. Rather, it is a code that signals how the hook procedure should process the message. Use it like this:
LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam)
{
// If nCode is greater than or equal to HC_ACTION, process the message.
if (nCode >= HC_ACTION)
{
KBDLLHOOKSTRUCT* pkbhs = reinterpret_cast<KBDLLHOOKSTRUCT*>(lParam);
// Handle the keys as you wish here.
//
// Remember that pkbhs->vkCode gives you the virtual key code
// of the key that was pressed.
//
// To prevent a particular key from being processed, you should
// return a non-zero value (e.g. 1) immediately.
}
// Pass the message on.
return CallNextHookEx(m_hHook, nCode, wParam, lParam);
}
And when you install the hook, there is absolutely no need to cast the function pointer. Pointless casts like this just hide potential compile-time errors, leading to a crash at runtime. Write it simply:
m_hHook = SetWindowsHookEx(WH_KEYBOARD_LL, lowLevelKeyboardProc, 0, 0);
I don't quite understand how this works. So I've made my dialog box.. or boxes. And I don't know how to make them appear in my code. Right now I'm trying to just get them to pop up right when I start my program so I can get a basic understanding of how this works.
switch (message)
{
case WM_CREATE:
HINSTANCE hInstance = ((LPCREATESTRUCT) lParam)->hInstance;
CreateDialog(hInstance, "Whatever", hwnd, ABOUT_DIALOG);
That gives me an error in CreateDialog saying a parameter of type int is incompatible with DLGPROC. I'm assuming that I need to declare my dialog box somewhere?
And If I had a button on my very first start up window, how would I know that the user pressed the button? I'm going to once again assume and say that I need to catch it somewhere in the WM_COMMAND command?
The final parameter, the thing that you pass ABOUT_DIALOG to, needs to be a DLGPROC. That is a function of this form:
INT_PTR CALLBACK DialogProc(
HWND hwndDlg,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
);
The compiler is telling you that ABOUT_DIALOG is not a function of that form. In fact the compiler tells you that ABOUT_DIALOG is an int which is definitely not the right thing!
To get it up and running with a default do-nothing dialog procedure implement it like this:
INT_PTR CALLBACK DialogProc(
HWND hwndDlg,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
)
{
return FALSE;
}
The documentation says this:
Typically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
So by returning FALSE we are asking for default processing.
Once you have the dialog up and running, you can then fill out the dialog procedure with any functionality that you need.
I want to subclass RichEdit in my program (here is c++ code: http://dumpz.org/46182/). _native_log is a hwnd of richedit. At first all works fine and LogWindow::wndProc callback called normal, but if i set some text in RichEdit or click on them LogWindow::wndProc stops work (there no any further calls of it). Is there any thoughts what's i do wrong?
void LogWindow::replaceNativeLog(HWND native_log_handle) {
_native_log = native_log_handle;
SendMessage(_native_log, EM_GETOLEINTERFACE, 0, (LPARAM) &_rich_edit_ole);
_old_wnd_proc = (WNDPROC) SetWindowLongPtr(_native_log, GWLP_WNDPROC, (LONG) &wndProc);
}
LRESULT LogWindow::wndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) {
switch (Msg) {
case EM_STREAMIN:
break;
case WM_SETTEXT:
break;
};
return CallWindowProc(_old_wnd_proc, _native_log, Msg, wParam, lParam);
}
Starting with Common Controls version 6 the procedure of subclassing windows has been revised to eliminate the issues with previous versions. In particular it is no longer a problem if a control is subclassed more than once.
A comparison between subclassing pre-v6 Common Controls and the v6 way of doing things can be found at "Subclassing Controls". Instead of calling SetWindowLongPtr to replace the window procedure there is SetWindowSubclass which in addition to replacing the window procedure does all the internal bookkeeping. A consequence of the redesign is that you do not have to store a pointer to the previous window procedure either; if you need to call into the original window procedure there is DefSubclassProc at your disposal.
This of course will only help if all competing clients trying to subclass the a control all agree on using the v6 style subclassing.
Finally, I found the problem. I actually develop a plugin for Miranda IM, and there was another function trying to subclass richedit i want. So there is a kind of conflict between my and that functions. Thanks all for trying to help.