Feeds:
Posts
Comments

Archive for the ‘Windows Forms’ Category

The Winforms DateTimePicker has this odd behavior. If you set focus to either the day or the year, then when you tab out of the control and tab back in, focus is not restored to the month as it is by default (even if you reset or change the DateTime value for the control). There is no elegant way to resolve this as the control does not expose those inner controls in any way. You could send mouse/keyboard clicks to change focus, but it’s way simpler to use this arguably ugly hack. The code below will force the control to recreate itself and thus we reset focus to its default state.

var format = dateTimePicker1.Format;
dateTimePicker1.Format = DateTimePickerFormat.Custom;
dateTimePicker1.Format = format;

The trick is to force the control to internally reset itself by changing the Format and then setting it back to what it was. The code above assumes that it is something other than Custom.

Read Full Post »

This one comes up in the forums at least once a week. The scenario is where someone shows a form, closes it while retaining the handle, and then tries to show it again by calling Show or ShowDialog on the closed form. This throws an exception that says the object has been disposed.

Here’s my standard answer. You cannot re-show a form once it’s closed because the underlying window is destroyed. You can hide the form and then re-show it as required thereby reusing the same form instance.

Alternatively, for modal dialogs, instantiate a local form variable and call ShowDialog on that. So each time it’s a new form. And this way you don’t need to keep the form in memory all the time, specially if it’s an options dialog that’s rarely brought up.

Read Full Post »

The DesignMode property does not always return the correct value, specially for nested controls or for child controls instantiated in their parent control’s constructors. One workaround is to check for LicenseManager.UsageMode and see if it’s equal to LicenseUsageMode.Runtime, but even that won’t work all the time. It will always return Runtime from event handlers and worker threads, so a more guaranteed approach is to see if the current process-name is devenv. Of course that’s a slightly heavier call so we should still check for LicenseManager.UsageMode first, and only check the process-name if we have to.

bool isDesignMode = LicenseManager.UsageMode == LicenseUsageMode.Designtime
  || Process.GetCurrentProcess().ProcessName.ToLowerInvariant().Contains("devenv");

Read Full Post »

This one was simple to resolve but it did halt my progress for about 5-6 minutes recently. I had a form (actually a user control) that had a control on it added at design time docked to the right. During run time I was adding a new WinForms control that I had set to DockStyle.Fill. Imagine my surprise when the dynamically added control filled the entire user control instead of adhering to the expected docking behavior. Turns out the control that fills the rest of the space always needs to be the first control that’s on the form or user control. When doing it dynamically, you need to call ControlCollection.SetChildIndex. Here’s a sample code snippet :

private void MainForm_Load(object sender, EventArgs e)
{
    TextBox textBox = new TextBox() { Multiline = true, Dock = DockStyle.Fill };
    this.Controls.Add(textBox);
    this.Controls.SetChildIndex(textBox, 0); // move it to the 0th position
}

Read Full Post »

Follow

Get every new post delivered to your Inbox.