Windows Form Appbar Desktop Resizing

Question

Okay. Just when you think you've figured it all out, you haven't.

I have coded and tested a functional appbar class. When I use a simple Windows Form to extend and test the class, it works without issue in both XP (SP 3, 32 bit) and Windows 7 (64 bit). Other windows are accessible, and they all maximize appropriately. However, when I take my "complex" Windows Form (i.e. it is an application) and derive it from the appbar class, the desktop seems to "kick" it out. By this I mean that everything sizes appropriately initially, but then the desktop resizes itself back to its former size. Sometimes this happens rather quickly after putting the form into appbar mode, other times it happens when I click outside the form (to open a browser, for instance), and other times it happens when the form calls a MessageBox. I have put all of the Forms functions in a background worker thinking that may be the issue, but the result is the same. I've posted three images below. The first one shows the application as its initial WinForm. The second shows the appbar "functioning." The last shows the appbar not "functioning." If you're having issues seeing the problem, pay attention to the Recycle Bin. Any ideas?

enter image description here

Edit: I found these calls via logging. They appear to fire off each time the desktop resizes to "normal." Now I'm trying to see if there is or is not a similar pattern in the "simple" version.

msg=0x6 (WM_ACTIVATE) hwnd=0x1e03ea wparam=0x0 lparam=0x0 result=0x0
msg=0x1c (WM_ACTIVATEAPP) hwnd=0x1e03ea wparam=0x0 lparam=0x1a90 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x2f lparam=0x9fe048 result=0x0
msg=0x1a (WM_WININICHANGE) hwnd=0x1e03ea wparam=0x18 lparam=0x9fe038 result=0x0

In reference to the four messages above, I've narrowed it down to the bottom two. In the simple form, these only fire when the appbar is undocked. Would have been nice to find these about four hours ago, lol. — Tebc
This just got more confusing. FYI, here's the hierarchy: Form -> AppBar -> Application. This is the same in both the working and non working versions. I noticed that in the working version, WININICHANGE never shows because the appbarHandle variable equals the hWnd parameter of the call. However, in the non functioning version, this isn't true. Here, the Application handle is what is being sent. Alas, I corrected this by setting the appbarHandle variable to protected internal (opposed to private) and assigning it in the Application constructor, but the issue continues. Grrr. Still searching... — Tebc
On a side note, if you're going to mark this down please tell me why. I'm rather new here, so such information would be constructive. Thanks. — Tebc
Here's what I discovered. The Application originally derived from Form (as the AppBar class was still being written). When the base class was changed, something in the Application.Designer.cs apparently didn't like the change. I created a new "Application" to test this theory, and it functions as it should. Not sure what would cause the derived class and the base class to have separate handles, but this is what appears to have solved it. — Tebc

Tebc Tebc · Accepted Answer · 2012-12-13T14:24:29

So this was one wild goose chase. In the event my last comment sounded absurd, it was. While I am still not 100% certain as to this theory (someone please prove/disprove at your leisure), the two different handles came from (1) instantiation of the Form and (2) the actual handle when the Form is loaded. I presume the API follows the same concept of QUERY_POS and SET_POS, that being it initially checks for and assigns a valid handle. Then, prior to the Form being shown, it double checks the handle value.

Long story short, one line of code to verify the handle value in the Load event solved the entire problem.

EDIT: Better yet, the HandleCreated event is irreplaceable.

Windows Form Appbar Desktop Resizing

1 Answers