One of the things that I provide in my add-ins is that modal windows are 1) resizable and 2) with memory (that is, remembering the last size used by the user). I am passionate about user interface usability and I hate modal windows that are not resizable in today’s big screens, such as the Tools, Options window of Visual Studio. I know this is so because of historical reasons (MFC stuff or similar), but after 8 years and five Visual Studio releases (including a new WPF-based shell) you are still forced to scroll, despite you may have a big display… some new stuff like the windows related to data sources are resizable (they are implemented in .NET where resizing is more easy). I also hate the windows that are resizable, but the programmer didn’t take the extra step to persist the size when the window is closed, so the user must resize it each time that the window is opened…

Anyway, I have special code for all that stuff that resizes and centers the window before is shown, and while doing some testing with VS 2010 I noticed that something was wrong when the VS 2010 IDE was maximized because the window(s) of my add-in didn’t show centered. Finally I isolated the bug and it happens that DTE.MainWindow.Width property of the new WPF-based VS 2010 shell can return a wrong result if you maximize the IDE window by hand.

Here it is the acknowledged bug:

DTE.MainWindow.Width or DTE.MainWindow.Height don’t return correct size when IDE maximized by hand
https://connect.microsoft.com/VisualStudio/feedback/details/536703/dte-mainwindow-width-or-dte-mainwindow-height-dont-return-correct-size-when-ide-maximized-by-hand

Interestingly, it works fine if you resize the main window by code (and not by hand), so tricky and subtle are the bugs introduced by the new WPF-based shell.

Since I didn’t have any hope of getting this kind of bugs fixed for the RTM, I was able to workaround the problem in the add-in.