Initializing a combobox to a blank value might be harder than you think

Combobox troubles again today. No matter how hard I tried to have Comboboxes in my dialog form to initially display blank (SelectedIndex = -1), as soon as the dialog was displayed, the combos would always show the first item in the List that populated it. Despite being set to -1 explicitly. It was driving me nuts.

When created at runtime using a List as DataSource, getting this (empty combos) might be harder than you think

The situation: I had a dialog form that should have a variable number of comboboxes on it, determined at runtime. So the form had an Init method where I dynamically added the comboboxes, and set its DataSource to a List of items (directly, no BindingSource). The form also has a LoadData method, that sets the SelectedIndex of each combo to the actual value from the data, or to -1 of it was unknown or uninitialized at that time. This was to be able to make the combo appear blank instead of preselecting the first item, which was undesired. The caller of the dialog executes Init(), LoadData() and finally ShowDialog().

I was expecting a blank combobox, but it showed the first item in the list preselected. I triple checked that the SelectedIndex was correctly set to -1 at the end of LoadData(), but as soon as the form was displayed, it was 0. What the *** happened there in between and “who” was secretly setting my property!? Lees meer over dit bericht

Advertenties

Keeping a modeless window accessible from a modal (dialog) window

In a C# WinForms application I was working on, users were effectively working with two more or less independent windows: one they worked in, and another that showed documents and other info they need to do that work. The problem was that when they were in a dialog, for example one to assist in creating a new object, the window holding the documents with info on the object was not accessible because the dialog is modal.

You can have the dialog take ownership of the document window, but that means also it will always be on top of it, which would be inconvenient.

So I borrowed a trick from my Delphi days that I found here. You only need to do a small Windows API call from your code. I added this code to utility class called FormsUtil, but you could of course put it anywhere that’s convenient to you.


[DllImport("user32.dll")]
private static extern bool EnableWindow(IntPtr hwnd, bool bEnable);

public static bool EnableWindow (Form form, bool enable) {
    return EnableWindow(form.Handle, enable);
}

This allows you to, in the dialog form, attach an event handler to the Shown event:

private void NewObjectForm_Shown(object sender, EventArgs e) {
    if (this.Modal) {
        var viewer = GetReferenceToDocumentViewerForm();
        FormsUtil.EnableWindow(viewer, true);
    }
}

Now the document viewer window is accessible from the “new object” dialog.

Tip: be careful if you ever choose to use EnableWindow(formX, false). It will disable that form completely, including not being able to close it.