I recently had the need to write a version of the Windows NumericUpDown control which could highlight whether a value was mandatory. It needed to do this by changing the back colour of the control. I thought this would be simple enough, but in trying to do so, I find that it has a wierd side-effect of not quite drawing all the control.
Using the code below, I am seeing this:
When I drop a control on a Windows form, and change the BackColor property (ie. to Blue), the whole of the control's number part changes colour. If, alternatively, I change my "IsMandatory" property, not quite all of the back colour changes (it leaves a border). So, if I change the BackColor to Blue, and then set IsMandatory to True, I get a LightBlue control (the mandatory colour) with a Blue border.
I cannot see why that should be, given that they both use the same code.
Ideas or explanations greatfully received.
public partial class MyNumericUpDown : NumericUpDown
{
private Boolean _isMandatory = false;
private Color _mandatoryBackColor = Color.LightBlue;
private Color _backColor = Color.FromKnownColor(KnownColor.Window);
[DefaultValue(typeof(Color), "Window"), Description("Overridden property")]
override public Color BackColor
{
get { return _backColor; }
set
{
_backColor = value;
MyResetColors();
}
}
[DefaultValue(typeof(Color), "LightBlue"), Category("Appearance")]
public Color MandatoryBackColor
{
get {return _mandatoryBackColor;}
set
{
_mandatoryBackColor = value;
MyResetColors();
}
}
[DefaultValue(false), Category("Behavior")]
public Boolean IsMandatory
{
get { return _isMandatory; }
set
{
_isMandatory = value;
MyResetColors();
}
}
private void MyResetColors()
{
base.BackColor = (this.IsMandatory ? this.MandatoryBackColor : this.BackColor);
}
}
Interesting question, it demonstrates how overriding virtual members can have unexpected side-effects. The core problem is your BackColor property getter, it always returns the _backColor property value, even if you forced it to a different value with IsMandatory. That property getter is also used by Winforms when it needs to draw the control background. So you'll return Blue which explains why you see blue in your screenshot.
But oddly it still works for the text portion of the control. That's because NumericUpdown is made up of multiple controls. You've got a ContainerControl that sets the outer bounds and is the base class, you are overriding its BackColor property. But inside of it are two other controls, a TextBox that displays the text and a Control that displays the up/down buttons. Your BackColor property override does not override their BackColor properties. So the textbox portion will draw with the color you assigned to Base.BackColor
To fix this, you are going to have to stop fibbing about the BackColor. With the extra constraint that you need to make sure that this still works at design time so that the actual BackColor gets serialized and not the MandatoryColor:
[DefaultValue(typeof(Color), "Window"), Description("Overridden property")]
override public Color BackColor {
get {
return base.BackColor;
}
set {
_backColor = value;
MyResetColors();
}
}
private void MyResetColors() {
base.BackColor = this.IsMandatory && !DesignMode ? this.MandatoryBackColor : _backColor;
}
The above method did not work out for me. My workaround was:
private void smartRefresh()
{
if (oldBackColor != BackColor) {
oldBackColor = BackColor;
Hide();
Application.DoEvents();
Show();
Application.DoEvents();
}
}
With a private member oldBackColor.
Now it always shows correctly but does not flicker.
Addendum: I think some part of the Control doesn't get painted at all (I consider it a bug) as the "mispainted" bos around it is not uniformly colored an somtimes traces of the window that was there before can be seen.
Windows does not properly/completely repaint the NumericUpDown control when it is disabled.
See this post: NumericUpDown background colour change for disabled element
Enabling / disabling the control after it is displayed is a work-around.
Related
I have a TreeView control, which contains multiple elements, nodes. Is there a way to change the selected item's foreground color or background color (by default blue background with white foreground is applied to the selected element) based on some condition. In my case, I will retrieve an object and check its 'NeedSync' property. If it's value is true, I'd want the element to
have, for example, a green background. If it's false, I'd like the background to be red.
I looked at other similar threads, but the requirement there are to change the color of the unselected elements using the treeview's _DrawItem method. In WPF this should be possible by changing the controls style and specifying triggers.
What about here, in windows forms?
EDIT: I only have to change the font color or the backcolor of the selected element, everything else should stay the same. Is there a way to get the default style source code for the selected node? Implementing the drawNode method removes the collapsable icon, margins, some other things.
As said in the comments, you will need to change the DrawMode property to OwnerDrawText and then have something like this in the DrawNode event:
private void treeView1_DrawNode(object sender, DrawTreeNodeEventArgs e)
{
Brush foreColour;
Brush backColour;
if (e.Node.IsSelected)
{
if (e.Node.Text == "Node1")
{
// Special highlight colouring
foreColour = Brushes.Yellow;
backColour = Brushes.Red;
}
else
{
// Default highlight colouring
foreColour = SystemBrushes.HighlightText;
backColour = SystemBrushes.Highlight;
}
}
else {
if (e.Node.Text == "Node1")
{
// Special colouring
foreColour = Brushes.Red;
backColour = Brushes.Yellow;
}
else
{
// Default colouring
foreColour = SystemBrushes.WindowText;
backColour = SystemBrushes.Window;
}
}
e.Graphics.FillRectangle(backColour, e.Bounds);
e.Graphics.DrawString(e.Node.Text, treeView1.Font, foreColour, e.Bounds);
}
(I don't know what criteria you want to use, so I added e.Node.Text == "Node1" as an example.)
NB: You may want to add additional (but similar) logic to fade the colours if the treeview loses focus.
I have a UserControl that hosts a DataGridView component with a header and one data row.
I'm having an issue trying to notify the DataGridView when its container changes certain visual properties in the designer.
I override the BackColor property of the base UserControl to set the BackColor of the data row in the grid. The goal is that when I set the BackColor of the UserControl’s container it will trickle down to the Grid.
If I explicitly set the UserControl’s BackColor property, the design and runtime DataGridControl follows correctly.
If I just change the BackColor in the container what I have works at runtime, but is intermittent at design time.
Dropping the control on the container the data row BackColor follows the container color.
Changing the container’s BackColor doesn’t call the UserControl’s property setter to change the data row in the designer.
Changing the container does change other custom components I have created using label on a TableLayoutPanel. I don't set all labels to match the container so it must be using the property setter to get it right. They if I put a MessageBox.Show("Setter Called"); in the property setter it doesn't always happen. in either the working or my target non-working control.
When I run the project the executable does change the row to match. As a bonus the designer color changes right after the executable is displayed and it remains the matching color even after I end the program.
I also tried the ParentChanged event on the UserControl but it only gets called when the program runs or I add or delete the control from the form. Just like the other properties. Never from changing the container in the IDE.
Using the Load event made the code work at RunTime.
Current code:
public JobPanel()
{
InitializeComponent();
this.BorderStyle = System.Windows.Forms.BorderStyle.FixedSingle;
dataGridView1.RowCount = 1;
dataGridView1.BorderStyle = System.Windows.Forms.BorderStyle.None;
}
[BrowsableAttribute(true)]
public override Color BackColor { get { return base.BackColor; } set { SetBackColor(value); } }
private void SetBackColor(Color value)
{
if (BackColor != value) { //Makes no difference if we remove this test
base.BackColor = value;
if (dataGridView1 != null) {
dataGridView1.Rows[0].DefaultCellStyle.BackColor = BackColor;
dataGridView1.Rows[0].DefaultCellStyle.SelectionBackColor = BackColor;
}
}
}
private void JobPanel_Load(object sender, EventArgs e)
{
dataGridView1.DefaultCellStyle.BackColor = base.BackColor;
dataGridView1.DefaultCellStyle.ForeColor = base.ForeColor;
}
I've been working on developing a custom control which will be used in our CRM frontend. The control itself is nothing special, it simply wraps two labels, text edits, and a button into a single control. (The control is only acting as a wrapper, a bit long winded, but unfortunately our only option due to various restrictions)
I though it would be nice to give the control a Font and ForeColor property, that would change the Font and Color of the labels. Changing the font size means that the relative position of the text boxes be changed to keep everything in line. No problem.
I encapsulated the layout logic in an UpdateLayout method, which is called on the set accessor of the Font property and everything works beautifully at design time, however, at runtime, the Font of the labels is correct, but the layout of the text boxes and button are still in the default positions, hence, the labels overlap.
What am I missing in for updating the position of controls at the init stage in runtime? I've tried calling the UpdateLayout() method from both Initialize and the constructor of the control, alas to no avail.
Am i missing something obvious here?
EDIT:
As requested, I whipped up a quick test. My test control looks like so (Not including Designer code):
public partial class TestControl : UserControl
{
private Font _font;
[Browsable(true)]
public override Font Font
{
get
{
return this._font ?? SystemFonts.DefaultFont;
}
set
{
this._font = value;
this.DoLayout();
}
}
private void DoLayout()
{
this.label1.Font = this._font;
this.Size = new Size(label1.Width + textBox1.Width + 10,
label1.Height >= textBox1.Height ? label1.Height : textBox1.Height);
this.textBox1.Location = new Point(label1.Location.X + 5 + label1.Width, 1);
this.Update();
}
public TestControl()
{
InitializeComponent();
}
protected override void OnLayout(LayoutEventArgs e)
{
base.OnLayout(e);
DoLayout();
}
}
That works great at design time, but runtime, less so...
EDIT2:
So the above code doesn't entirely reflect the problem accurately, however, I have tried Jogy's suggestion of overriding the OnLayout method, and lo and behold, it works!
I'm relatively new to Custom Controls, so a rookie mistake on my part. This will definitely be committed to the long term memory.
Override OnLayout() method and call your UpdateLayout() there.
Thanks for supplying the code, I would provide the properties by reusing already available controls.
public override Font Font
{
get { return this.label1.Font; }
set
{
this.label1.Font = value;
// Additional code to update related controls.
}
}
Also be aware that the declaration of
private Font _font;
Delivers a non-initialized variable, and by using it in the "Do_Layout" might use a null value. Maybe change it to the following when using your code.
this.label1.Font = this.Font;
When I add my UserControls to a FlowLayoutPanel, they display properly. When I change the Dock or Anchor properties on the UserControls before adding them, they are still added but do not render.
According to "How to: Anchor and Dock Child Controls" this should be possible.
I can tell that the controls are added (despite not drawing) because adding enough of them causes a vertical scrollbar to appear.
Setting the "Dock" property of the UserControls to "Left" or "None" will cause them to render, but none of the other options.
Setting the "Anchor" property on the UserControls to anything but Top | Left does not render.
Setting the dock before or after adding the control makes no difference (Add, Dock vs. Dock, Add).
The FlowLayoutPanel is itself is docked (Fill), has FlowDirection set to TopDown, has WrapContents set to false, has AutoScroll set to true, and is otherwise default.
I am using .NET 3.5.
In answer to a comment, the two commented lines are the locations I tried to change the dock. The second spot definitely makes more sense, but I tried the other because it couldn't hurt.
public void CreateObjectControl( object o )
{
ObjectControl oc = new ObjectControl();
oc.MyObject = o;
//This was a spot I mentioned:
//oc.Dock = DockStyle.Fill;
ObjectDictionary.Add( o, oc );
flowLayoutPanel1.Controls.Add( oc );
//This is the other spot I mentioned:
oc.Dock = DockStyle.Fill;
}
try using SuspendLayout and Resumelayout function for the controls before making any amendments which need rendering for proper viewing.
You could see the code from Designer.cs for that particular control
Syntax
control.SuspendLayout();
{Your code for designer amendments}
control.resumeaLayout();
I think I may have found a workaround (read: dirty trick) ... this answer helped to point me in the right direction. Here's an excerpt from the MS article that you also linked to:
For vertical flow directions, the FlowLayoutPanel control calculates the width of an implied column from the widest child control in the column. All other controls in this column with Anchor or Dock properties are aligned or stretched to fit this implied column.
The behavior works in a similar way for horizontal flow directions. The FlowLayoutPanel control calculates the height of an implied row from the tallest child control in the row, and all docked or anchored child controls in this row are aligned or sized to fit the implied row.
This page does not specifically mention that you can't Dock/Anchor the tallest/widest control. But as this control defines the layout behaviour of the FlowLayoutPanel, and thus influences the way all other sibling controls are displayed, it is well possible that Dock and Anchor don't work properly for that 'master control'. Even though I can't find any official documentation regarding that, I believe it to be the case.
So, which options do we have? At runtime, we could add a panel control of height 0 and width of the FlowLayoutPanel client area before you add your usercontrol. You can even set that panel's visibility to false. Subscribing to some Resize/Layout events of the FlowLayoutPanel to keep that panel's size will to the trick. But this does not play nicely at design time. The events won't fire and thus you can't really design the surface the way you want it to look.
I'd prefer a solution that "just works" at design time as well. So, here's an attempt at an "invisible" control that I put together, to fix the controls resizing to zero width if no other control is present. Dropping this as first control onto the FlowLayoutPanel at design time seems to provide the desired effect, and any control subsequently placed on the FlowLayoutPanel is anchorable to the right without shrinking to zero width. The only problem is that, once this invisible control is there, it seems I can't remove it anymore via the IDE. It probably needs some special treatment using a ControlDesigner to achieve that. It can still be removed in the form's designer code though.
This control, once placed onto the FlowLayoutPanel, will listen for resize events of it's parent control, and resize itself according to the ClientSize of the parent control. Use with caution, as this may contain pitfalls that didn't occur to me during the few hours I played with this. For example, I didn't try placing controls that were wider than the FlowLayoutPanel's client area.
As a side note, what will still fail is trying to anchor to the bottom, but that wasn't part of the question ;-)
using System;
using System.Collections;
using System.ComponentModel;
using System.ComponentModel.Design;
using System.Drawing;
using System.Windows.Forms;
namespace ControlTest
{
public sealed class InvisibleControl : Control
{
public InvisibleControl()
{
TabStop = false;
}
#region public interface
// Reduce the temptation ...
public new AnchorStyles Anchor
{
get { return base.Anchor; }
set { base.Anchor = AnchorStyles.None; }
}
public new DockStyle Dock
{
get { return base.Dock; }
set { base.Dock = DockStyle.None; }
}
// We don't ever want to move away from (0,0)
public new Point Location
{
get { return base.Location; }
set { base.Location = Point.Empty; }
}
// Horizontal or vertical orientation?
private Orientation _orientation = Orientation.Horizontal;
[DefaultValue(typeof(Orientation), "Horizontal")]
public Orientation Orientation
{
get { return _orientation; }
set
{
if (_orientation == value) return;
_orientation = value;
ChangeSize();
}
}
#endregion
#region overrides of default behaviour
// We don't want any margin around us
protected override Padding DefaultMargin => Padding.Empty;
// Clean up parent references
protected override void Dispose(bool disposing)
{
if (disposing)
SetParent(null);
base.Dispose(disposing);
}
// This seems to be needed for IDE support, as OnParentChanged does not seem
// to fire if the control is dropped onto a surface for the first time
protected override void OnHandleCreated(EventArgs e)
{
base.OnHandleCreated(e);
ChangeSize();
}
// Make sure we don't inadvertantly paint anything
protected override void OnPaint(PaintEventArgs e) { }
protected override void OnPaintBackground(PaintEventArgs pevent) { }
// If the parent changes, we need to:
// A) Unsubscribe from the previous parent's Resize event, if applicable
// B) Subscribe to the new parent's Resize event
// C) Resize our control according to the new parent dimensions
protected override void OnParentChanged(EventArgs e)
{
base.OnParentChanged(e);
// Perform A+B
SetParent(Parent);
// Perform C
ChangeSize();
}
// We don't really want to be resized, so deal with it
protected override void OnResize(EventArgs e)
{
base.OnResize(e);
ChangeSize();
}
#endregion
#region private stuff
// Make this a default handler signature with optional params, so that this can
// directly subscribe to the parent resize event, but also be called without parameters
private void ChangeSize(object sender = null, EventArgs e = null)
{
Rectangle client = Parent?.ClientRectangle ?? new Rectangle(0, 0, 10, 10);
Size proposedSize = _orientation == Orientation.Horizontal
? new Size(client.Width, 0)
: new Size(0, client.Height);
if (!Size.Equals(proposedSize)) Size = proposedSize;
}
// Handles reparenting
private Control boundParent;
private void SetParent(Control parent)
{
if (boundParent != null)
boundParent.Resize -= ChangeSize;
boundParent = parent;
if (boundParent != null)
boundParent.Resize += ChangeSize;
}
#endregion
}
}
I've got a StatusStrip with a single ToolStripStatusLabel, Spring=true and a background color for notifications.
The problem is that there's an ugly gray square on the right side of the status strip. After fiddling for a while, I realized this is the sizing grip (I had is set to SizingGrip=false, GripStyle=Hidden). Yet even with it hidden, it still hogs the space. I can't get any content on the status strip to extend all the way to the right.
How would you work around this? Note I can't just set the backcolor of the StatusStrip because the Status Label changes colors and has some fading effects.
The StatusStrip.Padding property is borked, it returns the wrong value for Padding.Right if the sizing grip is disabled. You can fix it in your form constructor, like this:
public Form1() {
InitializeComponent();
statusStrip1.Padding = new Padding(statusStrip1.Padding.Left,
statusStrip1.Padding.Top, statusStrip1.Padding.Left, statusStrip1.Padding.Bottom);
}
Using the Left property to specify Right is the fix. Don't bother submitting this bug to Connect, they won't fix it.
Have a look at this blog entry on MSDN. The question was about changing the size of the sizing grip manually, and I think using the ToolStrip Renderer as suggested could work for you also.
The problem I have so far, is that it removes the background color on a status label in the StatusStrip, so it's not a solution yet, but it's a start.
public MyForm()
{
InitializeComponent();
statusStrip1.Renderer = new MyRenderer();
}
private class MyRenderer : ToolStripProfessionalRenderer
{
protected override void OnRenderStatusStripSizingGrip(ToolStripRenderEventArgs e)
{
// don't draw at all
}
}
I had following problem: when I set tsslSeparator.Spring = true, my right label disappeared immediately after tsslSeparator lost focus. The issue appeared when sizing grip was enabled. When it was disabled, everything worked just fine.
The solution was to set right margin for right label to something different than 0.
tsslLogging.Margin = new Padding(0, 3, 2, 2); // this is necessary for right alignment of status bar label
Hope this helps somebody.
If Microsoft isn't interesting in fixing it, it seems like a proper fix should handle all orientations, and ideally fix all Status Strips (see my answer to Get All Children for definition of GetAllChildren)
public static StatusStrip FixPadding(this StatusStrip ss) {
if (!ss.SizingGrip) {
var fixpad = ss.Padding;
if (ss.Orientation == Orientation.Horizontal) {
if (ss.RightToLeft == RightToLeft.No)
fixpad.Right = fixpad.Left;
else
fixpad.Left = fixpad.Right;
}
else
fixpad.Bottom = fixpad.Top;
ss.Padding = fixpad;
}
return ss;
}
public static void FixStatusStripPadding(this Form f) {
foreach (var ss in f.GetAllChildren().OfType<StatusStrip>())
ss.FixPadding();
}