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?
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.
On Mac there is a window flag/call: WindowTitleHidden + [nativeWindow setTitlebarAppearsTransparent:YES]
which basically makes the title bar to be "embedded" inside the window itself instead of creating a frame that "holds" the window. Like this:
Notice how the minimize, maximize and close buttons are on the same row as the app's widgets.
Is there something similar for Windows?
Like this:
Code: https://github.com/alexandernst/TrueFramelessWindow
AFAIK, you must draw them yourself and then reply to the WM_NCHITTEST mesage that Windows sends to your form to query where the mouse is positioned. That way you can tell Windows that the mouse is located over a, say, maximize button, although Windows itself didn't draw one there.
The painting can be done with the help of VisualStyleRenderer or ControlPaint.
I hope these questions will point you further:
Winforms: Add a close "x" button in a UserControl
Winforms - WM_NCHITEST message for click on control
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'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.
I noticed Firefox 4, Opera and Chrome, and IE 7/8 put buttons and controls in the title/caption bar, how is this done?
Thanks
http://img199.imageshack.us/img199/3307/slayerf.png
alt text http://img199.imageshack.us/img199/3307/slayerf.png
What they probably do is turn the caption bar off entirely (by excluding the WS_CAPTION window style), add a glass area to the top of the window, and then draw their own controls.
See http://msdn.microsoft.com/en-us/magazine/cc163435.aspx for more on glass.
Probably they simply handle the WM_NCPAINT message and draw part of the non-client area (which includes the borders and the caption bar) by themselves; they will also handle WM_NCLBUTTONDOWN, WM_NCHITTEST and other WM_NC* messages to emulate the behavior of a button on the caption bar.
Or at least, this was the way it was commonly done before Aero; I don't know how much it changed this kind of things.
Yes, you can do that.. you have use window hooks, insert your dll in remote process and run the function of dll remotely. here is full fledged article dealing with it :-
http://www.codeproject.com/KB/threads/winspy.aspx