How to prevent value changed events from firing on form initialization in .NET?

Question

Consider a simple .NET form with a couple of radio buttons and a checkbox.

Each of the radio buttons has a CheckedChanged handler setup that performs some action bas

Answer 1

Maybe for some functionality you can use the click event instead of the check changed event.

Answer 2

1. Don't set checked on a control that really does much in designer.
2. The global flag and conditional exits where needed.
3. Try..Catch the sore spots to ignore a meaningless exception.

(Using VS 2017) It appears to me that it is an annoyance but not a bug. It is consistent with the model in use. The event is fired by normal operation of code, but code I did not write (but can access where fools fear to tread) and where there appears to be no (decent) place earlier in the normal flow to anticipate it.

The cleanest answer seems to be not to check radio button or checkbox controls in the designer at all if they trigger any significant code. Instead these controls should be changed by code (e.g. checked = true) in the Load event (for example) AFTER all the initialization is done.

There is no loss of flexibility here since both are fixed before the build, only in different places. The event handlers will handle it exactly as if a user had clicked the control in the natural flow of a well designed GUI application. (This reminds me of the ancient RPG proverb "Don't buck the cycle". (Anyone here remember RPG? I, not part of IBM-oriented team, never used it but had interesting discussions with some who did. ) Pre-checking controls hits the wrong part of the VS cycle.)

If for any reason that will not work, the next best thing is the kludge suggested elsewhere of a single status boolean initialized false and set true at the appropriate time with conditional exits in the necessary places to prevent them from crashing until then. It will get the job done, but it's ugly. Better than failure.

Another thing I tried before I decided that designer level pre-set checks were the problem and there was a very acceptable alternative was to put the danger spots in a Try..Catch to be able to ignore the exception. Also a kludge.

Answer 3

One thing I've found that works is adding the events manually after you load the form.

To do this you can simply go into the generated form code found in the designer file of that form, and pull out the lines that add the event. It would look something like this:

this.controlName.CheckedChanged += new System.EventHandler(this.controlName_CheckedChanged);

Then put all of these calls into a method that you call after the InitializeComponent call in your form's constructor.

Answer 4

Yet another way:

Private Sub dgvGroups_CellValueChanged(sender As System.Object, e As System.Windows.Forms.DataGridViewCellEventArgs) Handles dgvGroups.CellValueChanged

    If Me.Visible = False Then Exit Sub ' Sub gets called on form load which causes problems

    wksGroups.Cells(e.RowIndex + 1, 1) = dgvGroups.Item(e.ColumnIndex, e.RowIndex).Value
    wksGroups.Cells(1, 5) = dgvGroups.RowCount