Question

I have a WPF app which snaps to screen edges (I just set the .Top or .Left of the window if you’re within 20 pixels of the screen edge), but I recently added some code provided by the WPF SDK Team to ‘mess’ with the window chrome, and although it’s working great (screenshot), it’s causing the ‘snapto’ to move the window unexpectedly (e.g.: it jumps to the left when it should be snapping straight down to the bottom)

I’ve narrowed it down to their handling of the WM_NCCALCSIZE … which is really odd because they basically don’t do anything, they just say they handle it, and return 0.

According to the documentation of WM_NCCALCSIZE, this should just result in the whole window being treated as client (having no non-client edge), but somehow it also means that whenever my snap-to code moves the window down to the bottom of the screen, it also moves left about 134 pixels … (moving to the other edges has similar side effects) and as long as I hold the mouse to drag it, it flickers back and forth from where it’s supposed to be. If I comment the WM_NCCALCSIZE handling out, the snap-to works the way it should (but the form doesn’t look right).

I’ve tried everything I can thing of in the WM_NCCALCSIZE handler, but I can’t stop it from jumping left … and of course, WM_NCCALCSIZE only gets called when the window size changes, so I don’t understand how it causes this in the first place!

P.S. If you want to actually see the code, it’s already on CodePlex, in two files, look for _HandleNCCalcSize and OnWindowLocationChanged

Answer 1

The reason this happens is that handling the WM_NCCALCSIZE changes the overall size of the window … but if you’re moving the window, changing your position during WM_MOVE or WM_WINDOWPOSCHANGED (which corresponds to the WPF WindowPositionChanged event) causes another WM_NCCALCSIZE message …

Making changes during WM_NCCALCSIZE (even just asserting that you handled the message) causes another call to WM_MOVE … which puts you into a loop where the "FROM" part of the positionchanged message stays the same (making the window "jump" from where it started to the position you adjust it to during WM_MOVE over and over as it changes back after WM_NCCALCSIZE).

The Correct Way

What you have to do is to obey Raymond Chen and handle WM_WINDOWPOSCHANGING instead. It happens before these other messages, and that way they do not interfere with each other!