I need to display an error message on rejecting a drop in my application.
I tried this in the OnDrop() but then the source application hangs until my message box is dismissed.
How can I do that?
You can always call PostMessage with a private message in the WM_APP range and in the message handler show the error.
That way you show the error after the drag and drop operation is really over and there is no danger of messing up anything.
You're right. But all the data I need to report in the message box is in the OnDrop.
If you need data you can copy it in the OnDrop, store it in some temporary location, then in the WM_APP range message pass the index to the data in temporary location. The handler for the WM_APP message can clean up the temporary data after showing the message box.
Related
I am working on a MFC C++ application. I was working on a dialog that has SystemMenu property set to FALSE, so it does not have the ability to maximize. I want to handle the double-click message on the title bar. How can I do that?
EDIT:
I hope this time it will be clear for everybody. I have a dialog that does not have system menu (and system buttons or icon). When the user double-clicks the titlebar of that dialog, I want the program to call function x();.
Technically, you would have to handle WM_NCLBUTTONDBLCLK and check if the double click occurred in the caption area of the window, possibly by sending it WM_NCHITTEST and testing that the return value is HTCAPTION.
(Update: As JohnCz rightfully points out, sending WM_NCHITTESTis not actually necessary, since WM_NCLBUTTONDBLCLK already carries its result in wParam.)
Then you would only have to send WM_SYSCOMMAND with SC_MAXIMIZE in wParam to the window to maximize it.
In practice, however, it will not achieve much if your dialog box is not ready to handle size changes and layout its controls accordingly. This feature did not come out of the box in MFC last time I checked.
I think there is some kind of confusion here:
Frédéric Hamidi
You are correct, handling WM_NCLBUTTONDBLCLK message is the right way to go, however it is no necessary to call HitTest, since WM_NCLBUTTONDBLCLK message delivers hit information that MFC framework translates in the WM_NCLBUTTONDBLCLK handler.
Victor,
What is exactly that you are trying to achieve by handling WM_NCLBUTTONDBLCLK message?
Maybe there is some other way to fulfill your requirement once you make it clear to us.
The fact that you do not have system menu, does not prevent your app from receiving non-client area messages.
I want to change the default behaviour of a combobox (c++, win32 api). I make the combobox drop down when something is entered in its edit control I want to avoid the default behaviour that the combobox searches for the first match in the list, selects it, and enters the selected string into the edit control. Can I suppress this behaviour by catching the respective (LB_SETCURSEL etc.) messages out of the message queue myself with GetMessage()?
Does anyone habe a different idea of how to do it?
Greets
Michbeck
You likely want to implement Window subclassing. This allows you to insert your own WndProc function into the combobox control that gets called before the control's own WndProc is called. You can filter out (and drop) window messages you don't want the control to get.
I'm not booted into my windows partition right now to run Spy++ on a combobox to see what messages it actually receives. My guess is that you want to filter out WM_CHAR from being received by the combobox.
I'm trying to retrieve the title of a window when my hook procedure receive an HCBT_ACTIVATE message.
The problem is that when this message is received for the first time the window seems not to have the caption already set. I think I should maybe add some kind of delay to the call to GetWindowText?
(After the window is created and, for example, I receive a HCBT_MOVESIZE or HCBT_DESTROYWND message I can get the correct title)
You should set the hook with SetWindowHookEx, using WH_CALLWNDPROCRET to receive the WM_CREATE notification after the message has been processed.
I've got a relatively simple Window class. I've created a window, associated my this, etc etc. Now later, I've thrown an exception to indicate a problem. When I call MessageBox to pop up the error, the program crashes, because it's attempting to call my Window Proc. Now, I mean, admittedly, I failed SRP here and just writing a brief self-owning HWND class will solve this problem, as the window wasn't cleaned up properly. However, I'm really mystified as to why it's trying to process Window messages in my MessageBox call- the owner parameter is nullptr. Any suggestions?
Edit: If I call DestroyWindow appropriately, then now the message box just doesn't show up, although the app doesn't crash. It only works if I manually remove this from the window, so that if the proc were called it would forward to DefWindowProc, and then DestroyWindow. I mean, I thought that if you called MessageBox without an owner, then it would just work, regardless of what you had done to other windows in the system.
What is happening here is that there are still messages for the dud window in the queue when you show the message box. The message box runs a modal window message pump and dispatches the troublesome messages. Remember that all windows created from the same thread share a single message queue.
I have no idea how to fix your problem but that's what's going on.
By the way, passing a null owner isn't a great idea as it will result in your message box not being minimised when your main app is minimised, for example.
Just wondering where is best to put functionality in an MFC application that is triggered when the whole window is resized. I was thinking mainfrm but I couldn't seem to capture any OnSize messages...
Can someone tell me what I am doing wrong?
Can someone tell me what I am doing wrong?
You didn't include any interesting details, so here are a few guesses (because of course the mainframe normally gets sent WM_SIZE messages...):
You didn't set up your message handler properly. Perhaps you forgot the message map entry?
You have an existing handler in place for WM_WINDOWPOSCHANGED that fails to call the default window procedure, thereby preventing WM_SIZE messages from being sent.
I am guessing that you are using the Multiple Document Interface ( MDI ) application type. In this case, you should capture the WM_SIZE message in each of your views - the classes you have derived from CView.