Develop Reference

Changing textbox text causes parent windows to resize incorrecly

I've tried looking many places for an answer to an issue I'm having and so far I've found nothing.
What I currently have is a c# windows form with user controls inside it. Some user controls have other controls inside them. What happens when I change the text in a textbox, is its parent windows will no longer resize like they should when changing the window size. i.e. A horizontal scrollbar will appear even though horizontal scrollbars are disabled in that specific window. Its almost as if changing the text changes the parent window's styling.
In case this is too vague, I have a textbox inside a panel with a docking property set to fill. The panel has a padding of 10 in order to allow the textbox to have some white space for aesthetic purposes. This control resides within a parent control (we'll call it parent 1), which in turn resides within another control as well (we'll call it parent 2). So when I change the textbox's text (at all, even adding a space), will then make parent 2 have a horizontal scrollbar flicker and sometimes even remain when resizing the form window manually.

You should make sure that not only the TextBox in the UserControl is docked to fill but also that the user control itself and its parent (and its parent) are Docked correctly or have anchor set so that they resize with the Form.
Do you execute any special code when the user enters a character? (KeyPressed event etc.). If yes you should try disabling the events temporarily to see if they cause the problem.
If you post a sample of your code it would be easier to help. Without this we can only guess, like I tried...

I found out my issue! When using autoScrollBars and double buffering, it caused the horizontal scrollbar to show when it shouldn't have (at least in my case) when resizing the window. The answer was simple, forget the autoScrollBars, and implement my own vertical scroll bar!
I was actually getting some code to post up on here for you guys to look at, but when looking at it, I decided to forget the autoscroll, and lo and behold it worked!
I'm actually curious as to why that is though. My friend heard that .net has some issues with autoScroll but I didn't think it would be to this degree.

How to remove controls from a container without container updating

I have an ordinary Panel control with a bunch of user controls contained within. At the moment, I do the following:
panel.Controls.Clear();
but this has the effect that I see (albeit quickly) each control disappearing individually.
Using SuspendLayout and ResumeLayout does not have any noticeable effect.
Question: Is there a way I can remove ALL controls, and have the container update only when all child controls have been removed?
Edit: the controls I am removing are derived from UserControl, so I have some control over their drawing behaviour. Is there some function I could possibly override in order to prevent the updating as they are removed?

Thank you Hans for your suggestion - yes, it turns out I was leaking controls.
Here's what I ended up doing:
panel.Visible = false;
while (panel.Controls.Count > 0)
{
panel.Controls[0].Dispose();
}
panel.Visible = true;
Basically, I hide the entire panel (which is border-less) before I dispose of each control. Disposing of each control automatically removes said control from the parent container, which is nice. Finally, I make the container visible once more.

What I think you need is Double Buffering.
There are several answers concerning this already on SO like
Winforms Double Buffering,
Enabling Double Buffering
and
How do I enable double-buffering of a control using C# (Windows forms)?
SuspendLayout stops the control redrawing as the children are removed but those actions are still processed in order when you call ResumeLayout. Double Buffering will stop the control painting at all until the offscreen buffer is updated. The update won't happen any quicker but it will be rendered to screen all at once from the buffer. If your machine is very slow you might still get a flicker when the buffer is rendered to the screen, like you would when loading a picture.

OnPaint events order

I developed some components with their own OnPaint-override where I draw them.
I now added a status panel which is designed to overlap topmost with part of my form. I use a alpha-blended color to gray out the underlying controls and display a text on it.
Unfortunately some of my underlying custom controls paint themselves after the status bar and so draw themselves above the status bar. Debugging I found out that first the status bar on paint event was called, later the paint event of the underlying controls.
How can I make sure the proper order is used to paint?
When underlying components draw themselves the components infront of them should always be automatically invalidate so they redraw themselves but that is not happing. I also called SendToFront on the statusbar but that did not helper neither. So I am also asking what is the proper mechanism to maintain the order and how do the core components handle that.
Edit: I also run in this problem: With every run of my OnPaint-event my overlay gets more and more opaque because it draws with alpha=128--red again and again on itself.

To eliminate external factors (like variations between XP, Vista, Win7), you could:
blend the "status panel" graphics onto each control in their OnPaint handlers, so you don't need to mess about with a semi-transparent status window to achieve the desired display.
use one opaque control (essentially the status panel) and render the final image you want into it by compositing the graphics from the individual controls, which would elimimnate any uncertainty over how the rendering process will operate. This would mean that you'd have to add custom click handling, but that's usually a fairly trivial addition - one easy way around this is to put the main "display control" behind a set of invisible controls (the buttons) so that all the click handling can work as normal, but the painting is delegated to a single control.

Stop controls from being painted

I have a User Control that has some WinForm Controls inside. I want to be able to paint those inner controls myself (for scrolling purposes, some of them will remain, others will move).
Even when I override the OnPaint and the OnPaintBackground method, those controls keeps showing on my usercontrol which is completely black now because there is no painting methods on it.
Is there a way I can suppress those controls from been painted and then paint them by myself with the DrawToBitmap method of each control?

Yes. Remove them from (or better yet, never add them to) the UserControl's set of child controls. Simulating interaction with the controls is going to be a PITA, though.
Do you just need the controls to "look" like they're there. Or do they need to actually be there? If its the latter, you would be better off faking the scrolling somehow by just repositioning the controls manually.
Trying to re-invent the windowing system is an exercise in pain. You will be better off if you learn and work within its paradigms.

If you don't need interaction, just set every child control .Visible = false.
Otherwise, have you tried WM_SETREDRAW?

c# Winforms: Refreshing a portion of a GUI (containing 1 or more controls)

I have a Control that can overlay multiple C# user controls in my GUI. This control has a semi-transparent background in order to 'grey-out' portions of the GUI and the class looks somethink like this:
public greyOutControl: UserControl
{
// Usual stuff here
protected overide OnPaint()
{
paintBackround();
base.OnPaint();
}
}
Currently the control sometimes gets caught in a loop and constantly re-draws the background, making the semi-transparent color appear less and less transparent.
My idea to combat this is the following (in broad terms):
1) Determine what controls the greyOutControl is on top of
2) call Refresh() on those controls to update the display
3) continue drawing the greyOutControl.
My question is: How can I determine which controls the greyOutControl overlaps?, or is there a way that I can refresh only the part of the GUI that greyOutControl covers?

Why don't you keep track of your transparent controls and paint them after all the other controls are drawn?. Painting anything at the top of the Z-order shouldn't cause the other controls to be repainted.

I don't see a direct way of finding the overlapping controls. I think you might need to check the whole control tree to find out that. About refreshing, you can use Control.Invalidate(Rectangle) method to specify which part to refresh.

The solution to this problem I found was to programmatically take a screen shot of the area being overlayed and then use that image as the background for the control being overlayed. This then allows you to put the alpha overlay into the image within the OnPaint() method and the control to draw itself correctly.
This does have the disadvantage that the background isn't updated in the overlapping control, but unless there was a number of event handlers watching if something changes and then update the overlayed control I cant see any way around the issue. Sometimes I regret not trying to use WPF!