What is the difference between Button.performclick() vs Call Button_Click(sender, e)? When should I use which one (if it matters in the first place)?
PerformClick is a method by which the control will raise the click event where as Button_Click(sender, e) is the event's method event handler. Both will probably do what are wanting to do.
Personally, I would suggest using the neither and instead wrap the code in the Click event into a sub, then calling the Sub in the Click event and calling the Sub in in lieu of the PerformClick.
Call exists mainly for compatibility when updating older VB6-era code to VB.Net. There's no good reason to use it in VB.Net.
That said, I almost never use performClick(). If I need to manually call the button click code from elsewhere I tend to either just write Button_Click(sender, e) (no Call) or, even better, create a new method to host the button click code, so both the button click event and my other code will call this new method instead.
Related
Say I've got the following sub that simply adds passed items to a ListView control:
Private Sub AddListItem(ByVal item As ListViewItem)
UIList.Items.Add(item)
End Sub
And I use that from a BackgroundWorker thread, like so:
UIList.BeginInvoke(Sub() AddListItem(lvItem))
Well quite by accident I've just discovered that it doesn't seem to matter which control is used to call the Invoke\BeginInvoke method, or even if I omit a control altogether and just call the method directly – which I assume just uses Me.<Method> behind the scenes – it doesn't seem to matter. The code still works.
So, is using the affected control to call the method just a way to make following the code easier? What, if any, are the other advantages? And are there certain pitfalls one needs to be aware of when using a different control?
Using ILSpy and digging down the Control.Invoke method, an excerpt is
...
UnsafeNativeMethods.PostMessage(
new HandleRef(this, this.Handle),
Control.threadCallbackMessage,
IntPtr.Zero,
IntPtr.Zero);
...
In addition, MSDN states:
The Invoke method searches up the control's parent chain until it
finds a control or form that has a window handle if the current
control's underlying window handle does not exist yet. If no
appropriate handle can be found, the Invoke method will throw an
exception. Exceptions that are raised during the call will be
propagated back to the caller.
So usually it shouldn't matter which control you post to.
Personally, I use the "nearest" control I can get to call the Invoke method.
I'm working in a windows application. using VB.NET 1.1
I have an empty form, and I want to generate my design in load session (not in form_load event! but in my form's constructor)
So I know I must generate my components in constructor, but I don't know how to generate button events. I mean I haven't any button in design mode, and these are generating in run-time mode. so how I set button events in this session?
And if you have a better solution for run-time design generation, give it to me. thanks ;)
A few things.
You may add controls at practically any point. It can be in the constructor, the Load, in response to another event, or when a custom method is called.
You can wire up events by using AddHandler myButton.Click, AddressOf Button_Click. You'll have to define the Button_Click event handlder and it will need to have the appropriate signature, which for a button click is (sender as object, e as EventArgs).
When in doubt, temporarily add a real control to you form and go to the hidden designer code (MyForm.vDesigner.vb) and see what is generated as a sample. Copy that code and move it into the main populating code. Then delete the control.
Good luck!
I just want to connect two arbitrary controls, so that if one is clicked, the other should act as though it's clicked - is this even remotely possible? it seems like it SHOULD be so easy, but the internet seems dry, unless I just don't know how to ask the question properly... I see a way to "click" a button control, but what if the target is not a button? - I don't know the name of any function that might be triggered by this control's click event, so I can't call it directly. I would guess there is some way of using Windows APIs, but I can't find anything that's nice, simple VB
Example
I click a Label control on the form. I want to handle that click event, run one line of code, then simulate a click event on an associated RadioButton control
Is this possible? How?
If you must, call (System.Windows.Forms.Controls.)Control.InvokeOnClick
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.invokeonclick%28v=vs.71%29.aspx
or even RadioButton.PerformClick
http://msdn.microsoft.com/en-us/library/system.windows.forms.radiobutton.performclick.aspx
A better way would be to create a common Subroutine that would be called on click of either controls. This way clicking on controls will execute their own code which can differ, and some common code as well.
This is how you accomplish executing the same code regardless of which control event was fired.
Private Sub ClickMe()
'code to execute
End Sub
Private Sub label1_Click(...) ...
ClickMe()
End Sub
Private Sub rb_checked(...) ...
ClickMe()
End Sub
I have a vb.net based windows application, where when "GO" button is clicked a bunch of data is loaded into DB. So in my application as soon as "GO" button is clicked I want to just disable it and would like to enable it back when the uploading has completed.
Now in my specific method for btnGo_Click() I have:
btnGo.Enabled = False
as first line and
btnGo.Enabled = True
as last line in the same method.
But I fail to understand why the "GO" though appears as being disabled still allows click when processing is going on. Also if I remove the last line, it gets disabled permanently and doesn't allow the click event.
Kindly suggest what am I doing wrong?
Edit (Dated: 25th Jan 2012): I made changes as suggested by our collegues, but I am facing a new issue here. I am facing an issue where the textbox gets updated but not always. I have updated my textbox in "_ProgressChanged" event of the background worker thread. In my case if there is 10 records uploaded. Then there are 10 lines of updates that are expected in the texbox. But only few lines are shown in the textbox. Is it the repaint issue again? Kindly suggest...Because all other things are done as per your suggestion
You're not doing anything wrong. The problem is that the UI doesn't get updated until the code inside of your event handler method finishes executing. Then, the button is disabled and immediately enabled in rapid sequence.
That explains why if you forget to reenable the button control at the end of the event handler method, it is still disabled—because you told it to disable the button in the first line of the method.
This is a classic case of why you should never perform long-running computational tasks inside of an event handler method, because it blocks the UI from being updated. The computation actually needs to happen on a separate thread. But don't try to create the thread manually, and definitely don't try to update your UI from a separate thread. Instead, use the BackgroundWorker component to handle all of this for you automatically. The linked MSDN documentation has a great sample on how to use it.
Disable the button before starting the BackgroundWorker, and then re-enable it in its Completed event, signaling the completion of your database load.
Since you're trying to execute a function that can take some time, I'd advise you to make use of threading. In .NET there's a BackgroundWorker component which is excellent for performing tasks asynchronous.
On button click, invoke the BackgroundWorker like this:
if not bgwWorker.IsBusy then
btnGo.enabled = false
bgwWorker.RunWorkerAsync()
end if
And use the completed event to enable the button again:
Private Sub bgwWorker_DoWork(ByVal sender As System.Object, _
ByVal e As System.ComponentModel.DoWorkEventArgs) _
Handles bgwWorker.DoWork
' Do your things
End Sub
Private Sub bgwWorker_RunWorkerCompleted(ByVal sender As System.Object, _
ByVal e As System.ComponentModel.RunWorkerCompletedEventArgs) _
Handles bgwWorker.RunWorkerCompleted
' Called when the BackgroundWorker is completed.
btnGo.enabled = true
End Sub
In the example above, I've used bgwWorker as the instance of a BackgroundWorker.
The button click event is handled as soon as the UI thread has idle time.
After you disable your button, the UI thread is keept busy by your code. At the end of your method, you re-enable the button, and after that you exit the method and allow for idle time.
As a consequence, the button will already be enabled at the point in time where the click event is handled, so your click is "recognized".
The solution is, as others already suggested, to use a Backgroundworker.
Dont try to use doEvents() as a solution (never do), since this would be prone to introduce other subtle problems. That said, you can prove the above explanation with some experimental doEvents in your code. You will see that the click is discarded if a doEvents is performed before the button gets re-enabled. On the other hand, performing a doEvents directly after the button.disable (to "update the GUI") will not help if it is executed before the click.
If your btnGo_Click() is ran inside main thread, UI could not be updated correctly inside a time-consuming task.
The best way you can do what you need is running your method in a BackgroundWorker.
I just tried disabling a button, Updateing the form, Sleeping, and enabling it again. It still performed the click (A click that was done while it "slept" with the button disabled) after it was enabled.
I guess forms "remember" clicks.
(EDIT: I did this in C#.)
It's usually not a good idea to manage the state of a submit button. Instead, perform validation on submit.
I would like to add 2 enhancements to the answer generally described here which is to 'do the work in another thread'.
Ensure button.enable=true always gets called
1.a. You should use a try block in button_click . If there is an error in launching the thread, CATCH should re-enable the button.
1.b. The task complete call back should also ensure the button is enabled using try/catch/finally
1.c The task timeout should also re-enable the button
A common error based on exactly the situation described here is rapid-clicker-person clicks the button twice in rapid succession.
This is possible because its possible, even if unlikely, that 2 click messages get queued and processed before the button is disabled. You can not assume the events happen synchronously.
IMHO a best practice is to use a static variable. Initialize it to 0. Set it to one as the very first statement and set it to 0 following the guidelines in POINT 1.
The second statement in button click should simply RETURN/EXIT if the value > 0
If you are using a worker thread, the static variable may have to be located in that code. I would not advise making it a form level variable.
I had a slightly different issue not being able to call click.
I have a routine that turns the UI on/off based on a validation routine.
i will say that I disagree w/ the suggestion to do validation in the submit. The button should not be enabled if we are able to tell the form is invalid.
My issue was that I was calling the validation from several places. One of the calls was the CustomCellDraw event of a grid which was firing very frequently.
So while it appeared that I was simply disabling/enabling the button a few times, I really was doing this almost continually.
I was able to trouble shoot by placing a label on the form and kind of doing a console.log thing. I immediately realized button.Enabled was flickering, which led me down the correct trouble shooting path.
I realize this addresses a different root cause than op described. But it does address the problem the op describes.
When using Visual Studio (though ideally this can apply to the generic case) and double click on a button I've created, the event handler code that is auto generated uses the following signature:
Protected Sub btnSubmitRequest_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnSubmitRequest.Click
End Sub
Is it best practice to leave the name of this method as is, or should it be renamed to something a little more descriptive, such as SubmitNewEmployeeRequest?
Create another method called SubmitNewEmployeeRequest. In btnSubmitRequest_Click, call SubmitNewEmployeeRequest. That is the most logical separation of duties.
Also, if you change the name of the button in the IDE before creating the handlers, the handlers get better default names. The name of your button would currently be btnSubmitRequest, you could change it to be more specific as btnSubmitNewEmployeeRequest and then generate the handler.
You should name your controls, and keep the naming consistent between the control and handlers.
I would generally name them within the context of usage, that is if your in the
Employee Request form, then the button need only be named SubmitRequest.
Do Stuff to Directory components form, then the button should probably be more descriptive like SubmitNewEmployeeRequest.
Well, personally I leave it so that I can see quickly that it is an event handler, specifically a click event handler. However I would be inclined to just have one line of code there that calls (in this case, your) SubmitNewEmployeeRequest because this may also be called from some context menu as well, or fired in response to some other event.