+1  A: 

A very interesting problem!

Does your problem parent (UC-A) override any of the methods around sizing or client areas?

Or has UC-A got a negative value for the bottom value of Padding or Margin ?

Is there anything else docked at the bottom edge of UC-A? Perhaps, something that has a negative size?

Or, does UC-A set the constraints of its child controls? If the minimum height of the panel is forced too large, you would get this result.

Hope this is helpful! If not, is there any chance you post the source to UC-A ?

Bevan
A: 

@Bevan

Thanks for the insightful question, unfortunately...

Does your problem parent (UC-A) override any of the methods around sizing or client areas?

Nope.

Or has UC-A got a negative value for the bottom value of Padding or Margin ?

No again.

Is there anything else docked at the bottom edge of UC-A? Perhaps, something that has a negative size?

No. :-(

Or, does UC-A set the constraints of its child controls? If the minimum height of the panel is forced too large, you would get this result.

Nope. UC-1 (child) does not impose any control size restrictions. UC-A (parent) imposes no restrictions on UC-1 or itself.

Peter
A: 

Assuming the parent control in question is not a standard .NET framework type, but a custom one, I'd guess that it is mixing up client and screen co-ordinates somewhere in it's logic. But that's just a guess.

Jeff Yates
+1  A: 

I was having the exact same problem and found your post while searching for a possible solution. Although I'm pretty sure that this is a bug in winforms, I found a bit of a workaround. Just put everything in your user control inside a panel, dock the panel to full, and do your anchoring inside the panel. This seems to alleviate the problem, although my button does tend up to show up at a slightly different size than it should in the parent control. Very weird. I compensated by making the button smaller in the designer, and it stretches wider by a few pixels in the parent control for some unknown reason. Hope this helps.