I used UpdateLayeredWindow to draw a window which use png as background. But this window contain some self-draw buttons which would change when user hover/click these buttons and then the window should change.
Now the problem is when should I call UpdateLayeredWindow. Shoud I call UpdateLayeredWindow after the user changed the button apperance, that is when user hover the mouse above the buttons or clicked the buttons?
When need to update the layeredwindow, call UpdateLayeredWindow, but be really careful with this.
Call it too frequently do cause performance problem, its not WM_PAINT which could combine to one if there is too much in the message queue. UpdateLayeredWindow do not...
Related
I have a main window which allows to display a child modal dialog. That dialog window is created based on the resource file using DialogBox function. It contains a few controls and a horizontal splitter which are repositioned/resized when handling WM_SIZE and WM_MOUSEMOVE messages. I use BeginDeferWindowPos, DeferWindowPos and EndDeferWindowPos functions. It looks like that everything is repainted correctly. Should I also call InvalidateRect after EndDeferWindowPos ? Is there any scenario where it may be necessary ? I don't handle WM_PAINT message.
The documentation for the DeferWindowPos function would strongly suggest that, so long as you don't have the SWP_NOREDRAW bit set in the uFlags argument, you do not need to call InvalidateRect after you have called EndDeferWindowPos:
SWP_NOREDRAW 0x0008 Does not redraw changes. If this flag is set,
no repainting of any kind occurs. This applies to the client area, the
nonclient area (including the title bar and scroll bars), and any part
of the parent window uncovered as a result of the window being moved.
When this flag is set, the application must explicitly invalidate or
redraw any parts of the window and parent window that need redrawing.
I've been trying with windowDidMove and windowWillMove (NSWindowDelegate) but I think I need something between these two...
Is there any other way to detect when I move my window in cocoa?
I mean - I want to trigger a function if I drag a window to the bottom of the screen, but I want this function to be run even if I didn't yet release the window?
The middle ground you are seeking is handling the mouse events yourself and implementing the window dragging. If you do this you determine how dragging works; so you can constrain the window to an area of the screen, trigger events when the window reaches a screen edge, etc.
You'll need to do some reading, you could start with Apple's Handling Mouse Events.
If you have problems once you've done the reading, written some code, etc. ask a new question, showing your code, and explain the problem you've hit. Somebody will probably help you out.
HTH
Windows sends several messages when a window is resized:
WM_GETMINMAXINFO
WM_ENTERSIZEMOVE
WM_EXITSIZEMOVE
WM_NCCALCSIZE
WM_SIZING
WM_SIZE
WM_WINDOWPOSCHANGING
WM_WINDOWPOSCHANGED
and possibly more.
If I would like to re-position the children when my window is resized, where and how should I do so?
I'm looking for the "best" method -- i.e. the method with the fewest gotcha's and the least flicker.
My current method is to perform all the repositioning inside WM_NCCALCSIZE, using DeferWindowPos.
However, I've also tried handling it inside WM_WINDOWPOSCHANGED... but no matter where I handle it, it seems like there is always at least one "moment" when the window is painted in an in-between state, where the window's size has changed, but its contents have yet to be resized.
Another effect I would also like to avoid: moving a child after it has already moved. I don't want the user to see a control sliding down and then back up because of my change -- it should have as few transient effects as possible.
Am I doing this correctly? Is there a better place I can lay out the window's children?
You should re-position the window in the WM_SIZE message, because that is the last one that the window recieves before complete it's task...To re-position the window you can use MoveWindow
I've created a window with a custom chrome by:
Handling WM_NCHITTEST and returning the appropriate values for the window caption and borders,
Swallowing WM_NCPAINT (and WM_NCUAHDRAWCAPTION, WM_NCUAHDRAWFRAME),
Handling WM_SETTEXT, WM_SETICON and WM_NCACTIVATE with DefWindowProc by temporarily removing WM_VISIBLE,
Handling WM_WINDOWPOSCHANGED to apply a window region for rounded corners.
Moving/Resizing is handled fine by Windows. I added WS_THICKFRAME to the window styles to enable Aero Snap functionality. But now when the window is maximized it is positioned at (-5,-5) and my custom titlebar is cut off (this doesn't happen without WS_THICKFRAME).
What is the proper way to fix that? What influences that position? It seems to be unrelated to values returned for WM_NCHITTEST.
Late answer, but it seems like noone else has answered.
You can check when the window is maximized and account for the margin when the window is maximized. You may want to handle WM_NCCALCSIZE rather than WM_NCPAINT to make the entire window appear as client area, rather than painting the non-client area.
This describes one approach to implementing custom chrome (I was the author):
http://blogs.msdn.com/b/wpfsdk/archive/2008/09/08/custom-window-chrome-in-wpf.aspx
Hope that helps,
I am making an image picker that will display an n by n grid of selectable button when the picker is popped up. This grid of buttons will be contained within an NSWindow but I would like for the window to be close automatically if the user clicks off the screen. Is there a flag that can be set so that when the window looses focus it will be closed automatically?
There are two notifications that you may be interested in: NSWindowDidResignKeyNotification and NSWindowDidResignMainNotification. You can simply register for the one you're interested in in awakeFromNib (or windowDidLoad if you have a custom controller) and then close or hide the window as appropriate when you receive the notifications.
I won't delve too much into whether or not this is a good idea from UI standpoint. But, it might be a better idea to have either an overlay view or a panel for the functionality you describe.
You might check out NSPanel. It's an NSWindow subclass that will hide itself when the app is in the background, and that behavior sounds very similar to what you are looking for.