Develop Reference

c# anchored controls "shakes" while resizing

I have a control on my app that can be resized by the user, it has some button anchored to the top-right side and also a scrollbar.
The problem is that when the control is resized, the controls anchored to the right also changes the position, and only after a few ms the controls goes into the right place. So it looks like the child controls "shakes" while the parent control is resized.
I already tried all kind of things, like using SuspendLayout and ResumeLayout on the parent control, setting double buffering and other styles on each control to true, setting WS_EX_COMPOSITED bit, but nothing seems to make this issue go away.
This issue is present on other apps too, and is pretty annoying.
So is there anyway to fix that on .net?
Maybe making it render everything to a backbuffer, and then when everything is finished render it to screen?

I would create a new event that fires after resize is done, using a little timer magic stopping and starting a timer with an interval about 50ish ms on each resize event you can create this fake ResizeEnd kind of event.
On the first resize event I would stop the drawing of the UI using the dllimport call (dont recall which it was) to stop drawing the contents of your window or control. Then when the resize is done, enable drawing again using the same dllimport call.
The effect would be that it will only redraw itself after resize is done or every 50ms if you pause while resizing.
ResizeEnd: WinForms - action after resize event
SuspendDrawing: How do I suspend painting for a control and its children?

override the below virtual method from namespace using System.Drawing;
protected override Point ScrollToControl(Control activeControl)
{
return AutoScrollPosition;
}
should solve the problem !

UserPaint refreshing in C# winforms

I have a user control which I paint with the UserPaint attribute.
It draws ok, but when some of my control's area goes out of screen and back in again, it does not refresh.
It's like the half that was out is not drawn again.
I override the "OnPaint" method to paint.
How can I fix it? :)

Custom control under modaldialog not repainting when moving dialog

What causes this ? Other controls are shown fine ...
public CustomControl()
{
SetStyle(ControlStyles.ResizeRedraw, true);
SetStyle(ControlStyles.OptimizedDoubleBuffer, true);
SetStyle(ControlStyles.UserPaint, true);
}
The customcontrol is placed in a TableLayoutPanel.
...................
Edit: For clarification:
Suppose you have a window-sized control with a small modal dialog form on top. When you move the dialog window, it's like your painting with the window on the control (the borders are painted on the control). The control doesn't repaint itself like other controls do on the same form, ie montcalendar or other custom controls. I can't seem to find the cause of this ?
Small detail of drawing artifact:

Hard to tell from the snippet. The standard mistake is to draw through Control.CreateGraphics() instead of the OnPaint() method. Won't work, Windows lets the OnPaint method run when parts of the control get uncovered. Which wipes out whatever you drew. Another failure mode is deriving from a control that's a wrapper for a native Window control. UserPaint is not supported for these type of controls, the native Windows code has to do the drawing.
It is clear from the screen shot, note how the text is staggered. That's because the OnPaint() override is using the e.ClipRectangle property to figure out where to draw. That value always changes when you slowly drag a window across your control, it only tells you what part of the control needs to be redrawn. It does not tell you where to draw. That has to be based on the control bounds, routinely the rectangle from (0,0) to (ClientSize.Width, ClientSize.Height).
Only ever use e.ClipRectangle to optimize the drawing. Like skipping an expensive drawing detail when it is outside of the clipping rectangle. It is otherwise a small one, Windows is already quite good at clipping automatically.

Problems with overriding OnPaint and grabbing mouse events in C# UserControl containing other controls

I've made a control which contains few other controls like PictureBox, Label and TextBox. But I'm having two problems:
1. I tried to paint some things on top of my control and when I'm overriding OnPaint, it results that things I try to draw are under controls that my control contains. Areas on which I would like to draw intersect with controls in ways that are not easy to predict. I mean that it includes something drawn on controls inside as well as on base of control. Is there a simple way to draw something on top of all contents of my control? Setting ForeColor to Transparent isn't a solution that would help me much.
2. I have a problem with grabbing mouse click events when I place my control on a form and add click event handling. It only works when I click on an area not occupied by controls inside. I would like the whole control to react to clicks and other actions like it was one consistent control. How can I redirect/handle these clicks to make them work the way I want?
Thanks in advance for any tips
edit:
Thanks for answer, i hoped for something less complexed.
Finally i decided to do it from scratch, painting all necessary things directly on surface of my UserControl, TextBox shows up only when it is necessary. That solved all of my problems with drawing and events.
MTH

1) Overriding a control's OnPaint event allows you to draw onto that control. Whenever that control is painted, your drawing code will be executed. Then, and only then, will the child controls be drawn on top of that control, each of them with their own OnPaint events executing. Each control is its own window (in the sense of the Windows API), and therefore each is responsible for drawing its own surface. This explains why your graphics are being covered up by the child controls, and why they are only visible in the empty spaces where no child controls have been placed.
The upshot is that drawing on top of multiple controls inside a container is not well-supported. There are a couple of hacks you could try to help get around these limitations, but you may well be disappointed.
The first possible hack is to draw your graphics on the container control as you've already done, and then also draw on top of the child controls themselves. You'll need to override each child control's OnPaint event in order for this to work, however, which immediately presents a problem. A TextBox control (along with a ComboBox, ListView, TreeView, and a handful of other controls) doesn't do its drawing in an OnPaint event; it's drawn natively by the operating system. The possible workarounds for this are so potentially painful that you might as well forget about it and change your design.
The second possible hack is to add another control that sits on top of the container control and do your drawing on its surface. Perhaps the easiest way to do this is by creating something like a transparent panel using the WS_EX_TRANSPARENT extended window style:
public class TransparentPanel : Panel
{
protected override CreateParams CreateParams
{
get
{
const int WS_EX_TRANSPARENT = 0x00000020;
CreateParams cp = base.CreateParams;
cp.ExStyle |= WS_EX_TRANSPARENT
return cp;
}
}
protected override void OnPaintBackground(PaintEventArgs e)
{
//Do nothing
}
}
2) Again, it becomes relevant that each child control is its own window and handles its own mouse input events. That's why the control whose MouseClick event you've overridden is only detecting the clicks that occur directly on its surface. The other clicks get passed to the child controls, who just ignore them. Events in WinForms are not bubbled up the control hierarchy.
As before, one possible solution is to handle the MouseClick event (and any others you want) for both the container and child controls. If you decide to go this route, I think I would recommend consolidating your logic into a single routine and simply calling that routine from each control's event handler.
If you're looking for something more comprehensive, you might check out Broadcasting Events through a Control Hierarchy, although I haven't taken the time to read it.
Of course, you could also send the relevant mouse input messages to your parent container control from each child control using the SendMessage API function. But I'll leave that as an exercise for the reader because I feel like you asked a simple question expecting a simple answer.

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!