Button Click Event Fires When Disabled

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

While testing one of our applications, I found some interesting behavior with
the Button click event using .NET 2.0.

Let's say we have a windows form with a button on it. When the user clicks
on the button, the button disables itself (to prevent the user from clicking
again), does some process that takes some time to complete, and then enables
the button again.

The behavior I'm seeing is when a user clicks on the button, the button does
disable. And while the button is still disabled, if the user clicks on the
button again many times, the clicks "get queued up" and when the process
finishes the button enables and then very quickly disables itself and start
the process again.

Depending on how many times you click and how fast, the process will repeat
itself several times. I don't think this should be happening. The MSDN
documentation says that when a control is disabled, the events should also be
disabled. So why would a click event be firing when a button is disabled?

I created a small test program that re-creates the issue. It's a form with
a button, a status strip and a counter. The button simulates some long
process and increments the counter and updates the status strip. If you
click on the button many times when it is disabled, the click events get
queued up and the button "get's clicked" again several times after the first
process is over.

namespace CSharpTestWinApp
{
public partial class Form1 : Form
{
private int m_counter;

public Form1()
{
InitializeComponent();

this.m_counter = 0;
this.m_statusLabel.Text = this.m_counter.ToString();
}

private void button1_Click(object sender, EventArgs e)
{
try
{
this.button1.Enabled = false;
this.m_counter++;
this.m_statusLabel.Text = this.m_counter.ToString();
Application.DoEvents();
System.Threading.Thread.Sleep(5000);
}
finally
{
this.button1.Enabled = true;
}
}

private void button2_Click(object sender, EventArgs e)
{
this.m_counter = 0;
this.m_statusLabel.Text = this.m_counter.ToString();
}
}
}
 
I should also note that this behavior also happens in .NET 1.1. Anybody have
any ideas why this is happening? I don't think it should.
 
DoEvents was only used in this example. The actual program writes data to a
USB Device and does not call DoEvents(). You'll still see the issue even if
DoEvents is not present.

Thanks!
 
The behavior you're seeing is because the thread is blocked (which you
should never do to a UI thread, by the way), but its gathers events in
its message pump, which is basically a queue. I'm pretty sure that's
by design; its happened in every windows application I can remember.
 
Hi Rmacias,

Thank you for posting.

I performed a test based on your sample code and reproduced the problem you
said. I also had a try commenting out the code "this.button1.Enabled=true"
in the finally block in the button1's Click event handler. In this case, no
matter how many time I clicked on the button1 when it's disabled, the
subsequent clicks weren't processed.

When UI thread is busy in doing something and some other events occur, for
example, the user clicks on a button or resizes the form, these windows
messages will be queued up in its message pump. When the UI thread finishes
the previous work, the messages in the message pump will be handled one by
one. At this time, if the condition is not met, the message will be
discarded. For example, there's a button click message in the message pump.
When the message is going to be handled, if the button is disabled now,
this message will be discarded.

In your sample code, every time the UI thread finishes executing the
button1's Click event handler, the button1 is enabled again. Thus, the
subsequent button's click messages in the message pump will be handled one
by one.

For you scenario, I recommend you to use BackgroundWorker to do the
time-consuming work. BackgroundWork uses a separate thread to do the
time-consuming work. After you start the BackgroundWorker in the UI thread,
the UI thread returns immediately. When the BackgroundWorker begins to
work, you may disable the button1. And after the BackgroundWorker finishes
the work, you may enable the button1 again.

The following is a sample code using BackgroundWorker.

namespace CSharpTestWinApp
{
public partial class Form1 : Form
{
private int m_counter;

public Form1()
{
InitializeComponent();

this.m_counter = 0;
this.m_statusLabel.Text = this.m_counter.ToString();

this.backgroundWorker1.DoWork += new
DoWorkEventHandler(backgroundWorker1_DoWork);

this.backgroundWorker1.RunWorkerCompleted += new
RunWorkerCompletedEventHandler(backgroundWorker1_RunWorkerCompleted);
}

void backgroundWorker1_RunWorkerCompleted(object sender,
RunWorkerCompletedEventArgs e)
{
this.m_statusLabel.Text = this.m_counter.ToString();
this.button1.Enabled = true;
}

void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
this.m_counter++;
System.Threading.Thread.Sleep(5000);

}

private void button1_Click(object sender, EventArgs e)
{
this.backgroundWorker1.RunWorkerAsync();
this.button1.Enabled = false;
}

private void button2_Click(object sender, EventArgs e)
{
this.m_counter = 0;
this.m_statusLabel.Text = this.m_counter.ToString();
}
}
}

For more information on how to use BackgroundWorker, you may refer to the
following link.

http://msdn2.microsoft.com/en-us/library/ms233672(d=ide).aspx

Hope this helps.
If you have anything unclear, please feel free to let me know.


Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thank you Linda and Andy for your insights. I'll try your recommendations.
It is much appreciated.

Thanks!
 
Back
Top