I'm working on a themed ownerdraw button using Win32 native.
Following a tutorial and a sample project on another website, I got my button almost perfect(almost without bug), but there's one which left, and I have a issue in fixing it.
Basically, I'm subclassing using SetWindowLongPtr API the window of the button, and from there, when WM_LBUTTONUP is catched, I would need to call DrawThemeBackground for reset the state of the button, OR, just handle again WM_DRAWITEM. The problem is that WM_DRAWITEM is getting called only when my mouse is on the dialog window, which is not really a problem, if there would be a way for advice the main dialog to handle it when I want it. I tried with InvalidateRect, but it is not making WM_DRAWITEM, but WM_CTLCOLORBTN.
So, my question is:
Is there any way for let WM_DRAWITEM being handled even if the mouse is out of the dialog
OR
Is there any way for advice the main dialog that it should handle again WM_DRAWITEM, evne if the mouse is out of the dialog?
Thanks alot for taking your time in replyng me.
Related
It is possible to set application-switching window as a Modal window (see definition)?
I mean, this window appears when I press Alt+Ctrl+Tab button at the same time and allows me navigate between opened applications typing "tab" key.
The problem appears when I push/click outside the window (Application-switching window lost focus and disappears).
Are there any way to avoid this problem in C++ MFC? I have tried calling:
CWnd* appSwitchingWnd = GetTopWindow();
appSwitchingWnd .SetFocus();
But it doesn't works...
I will appreciate any kind of help.
My application can receive a message from another application. If the app is minimized, I want to restore it to the previous state without giving focus to it.
I'm doing it by calling
::ShowWindow(hWnd, SW_SHOWNOACTIVATE);
It works well if the app was minimized using the Minimize button in the title bar, but if the app was minimized by clicking its button in the Windows task bar, then the app will receive focus.
Can this be fixed or worked around?
You could do the following HWND hwndForegroundWindow = GetForegroundWindow() before your ShowWindow function call. Afterwards you can restore the foreground window with SetForegroundWindow(hwndForegroundWindow). It depends on what you mean with focus though, foreground window and focus are something different (For element focus use GetFocus and SetFocus).
I am developing a C++ application displaying an MFC window without a caption (the top window bar), with a CEF control inside it. I would like the user to be able to click any area of the window and drag it as if the caption was being dragged.
The usual solution seems to be simulating a caption click, either by posting WM_NCLBUTTONDOWN with wparam HTCAPTION, or intercepting WM_NCHITTEST and returning HTCAPTION. I tested both solutions - they work great as long as I click a non-CEF area of the window. Clicking a CEF area is detectable in my MFC code, but I am unable to drag the window.
I have a hunch CEF (or chromium inside it) is intercepting some of my NC* messages; or posting their own versions. However, I don't know how to debug it or prevent it.
Does anyone have any suggestions how to fix this, or any alternative solutions?
I'm working on a MFC C++ dialog where I need to respond to right mouse click events for a dialog even if the mouse is hovering over a control.
I could write event handler code for each control to delegate the work to the parent dialog, but I'm hoping there is a more elegant solution?
I'm hoping there is some way to intercept the windows messages, but I'm still figuring that part out. I've tried listening to the WM_COMMAND messages with Spy++ but I didn't see what I needed.
Any suggestions?
You could set up a hook to intercept mouse messages. Take a look at SetWindowsHookEx and WH_MOUSE
I've a popup window which I show with the SW_SHOWNA flag. If I click parts of this window, I catch the click and then close it, the problem is, there are other parts of the window and I don't want to close the window on click on them, but when I click them the window gets activated and gets the focus, that's bad for me, I want this window to stay not activated, and that other window will remind focused.
any ideas?
thanks,
mike.
If you handle WM_HITTEST and WM_NCHITTEST, watch for the points you're interested in, and return HT_NOWHERE for everywhere else, then I think the window shouldn't be activated (I haven't tested this theory).