the Fiddler's picture

Invalid client area on Vista w/ Aero after changing GameWindow.BorderStyle

Project:The Open Toolkit library
Version:0.9.9-0
Component:Code
Category:bug report
Priority:normal
Assigned:the Fiddler
Status:closed
Description

This issue does not occur on Vista w/ Aero Basic or XP and earlier windows versions.

We need to hook the WM_NCCALCSIZE event, recalculate the client area and inform windows about the change.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Status:open» in progress

This seems to be more involved than I expected. According to a post in msdn, GetWindowRect does not return the expected results on Aero. Moreover, it seems that applications may *not* change border style once they are created, unless they are run with administrator priviledges.

If you have experienced this problem before, how did you solve it? Any ideas how WinForms implement this?

Finally, does anyone know if there is another way to calculate the client rectangle, apart from GetWindowRect/GetClientRect?

the Fiddler's picture

#2

This problem has me stumped - nothing I have tried seems to work.

Even worse, this problem does not occur on Nvidia hardware. I do not think this is a driver issue (Windows.Forms do not display this issue), but absolutely nothing seems to work.

To reiterate, the client rectangle becomes invalid once you change GameWindow.WindowBorder. Only occurs on Vista / W7 when Aero is enabled - but not on Nvidia hardware. Ideas?

AttachmentSize
Screenshot of the issue after changing WindowBorder from Resizable to Fixed61.04 KB
the Fiddler's picture

#3

Ok, more information has surfaced: this also affects WinForms, if you create a context directly on the parent Form. It does not occur if you use a GLControl.

I am writing this off as a quirk of the interaction between the DWM, the Ati OpenGL ICD. I will modify the code to create the GraphicsContext on a docked child window and leave it at that. I'm starting to miss the simplicity of X11 :p

the Fiddler's picture

#4

Version:0.9.1» 0.9.x-dev
Status:in progress» in progress (commit)

I have fixed this issue in gw-next2, by creating and rendering to a docked child window instead of the top-level parent.

Commit pending along with the gw-next2 branch.

the Fiddler's picture

#5

Status:in progress (commit)» fixed

Fixed committed to trunk.

the Fiddler's picture

#6

Version:0.9.x-dev» 0.9.9-0
Status:fixed» closed

Closing issues fixed in 0.9.9-0.