Is there any way to test if an event linked to a control is triggered by the program, rather than by user action?
I have a scroll bar which fires events when the user moves it. I want to be able to move the scroll bar programmatically elsewhere in the code without sending these events. i.e. events should only fire when the user interacts with the control, not when I move the control via code.
I also have radio buttons and numeric up/down controls I'd like to b able to do this with.
Thanks
There maybe better ways to do this but a quick way would be to use a boolean variable that you set when you are programmatically scrolling and unset it when you're done. Then in your event check that before executing the logic.
If IsProgramaticScrolling = False Then
' Do whatever it's supposed to do when your program isn't
' scrolling via code.
End If
Related
I'm using Visual Basic 2008 (VB.NET) and I have an old control which have some buttons on it. These buttons can not be pressed without actual click and the control have no event or API for that. The control is something like the picture below which has multiple objects and buttons as a single control which controls inside the control can be changed dynamically according to some conditions but at a fixed place and this is why I think simulating a click that I said is the best way in my opinion:(The actual control is completely different that the picture below. It's only a sample)
I can click on the button by doing these steps:
Collecting all controls positions on my form
Moving the control in order to put the button exactly at the left top of the form
MyControl.Left = -43
MyControl.Top = -6
Moving form exactly to the center of the screen
Me.Location = New Point(Screen.PrimaryScreen.WorkingArea.Width / 2 - 1, Screen.PrimaryScreen.WorkingArea.Height / 2 - 1)
Simulating a click action at the center of the screen
Moving back controls to their positions that I got in the first step
It can be done that way but it's not reliable and it might not be user friendly for my program customers.
I want to ask if there are any better method to do that like simulating a click event on a position on the form itself (so I don't have to move controls and do other steps)?
Of course I feel I must tell you that simulating a mouse click in order to programmatically click a button is not a very good idea. Many things can go wrong with this method (The form could move, making your mouse click on the wrong location; Form could be minimized, or another form could be on top of it, etc)
That said, it is possible, so take a look at this article that contains the code to simulate a mouse click.
http://www.developerfusion.com/code/276/simulating-mouse-events/
Once again, please consider doing this a different way. Iterate through the controls in the user control until you find the button you want and use button.performclick. Or you can call the function that the button.click event calls yourself, if it is public
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 form in a vb.net windows form application called PolicyRefreshStatus.vb that has a ProgressBar control on it. From the main form called EditPolicy.vb I need to show PolicyRefreshStatus.vb over top of EditPolicy.vb - but the way things are wired I'm controlling the the ProgressBar and it's steps from logic inside EditPolicy.vb.
If I display the PolicyRefreshStatus.vb bar using the .show() method things work fine. The problem is if the user clicks back on the main form then PolicyRefreshStatus.vb losses focus. If I show PolicyRefreshStatus.vb as a modal form using .ShowDialog() then execution halts in EditPolicy.vb after the .ShowDialog() statement.
so for example in the code:
mPolicyRefreshStatus = New PolicyRefreshStatus
mPolicyRefreshStatus.pbMax = mPolicy.ClaimsUpdateMax
mPolicyRefreshStatus.ShowDialog()
mPolicy.UpdateFromFIS()
The line mPolicy.UpdateFromFIS() never executes because it's waiting for the PolicyRefreshStatus form to close.
How can I show PolicyRefreshStatus in a modal form but let execution continue in EditPolicy.vb?
You've got a couple of related options.
This first is to pass the unit of work to the progress bar in the form of a delegate or a class implementing an Interface. Something like this (not checked for correctness, just a rough example):
mPolicyRefreshStatus = New PolicyRefreshStatus
mPolicyRefreshStatus.pbMax = mPolicy.ClaimsUpdateMax
mPolicyRefreshStatus.UnitOfWork = AddressOf(mPolicy.UpdateFromFIS())
mPolicyRefreshStatus.ShowDialog()
Then within the progress form you can call back to the routine that actually does the work.
Another approach is to define events on your ProgressForm and then the owning/launching object can handle those events to do the work in. With this option you can create a fairly detailed set of events to be able to handle incremental work or cancels, but the concept is the same, youu are calling back from the progress form into launcher to perform the actual business logic.
You cannot show the form modally and let your routine continue. You must show the form Non-modally and then do your other stuff, closing the form when you've finished. Maybe a loop until the task has finished?
Using Show() with a parent form parameter will give you better usability. More like a tool window.
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.
All,
I have a TabControl in an application that started behaving strangely. Some background...
This program was converted from VB6 to VB .NET 2008, and used to refer to forms using their class names. In other words, I might have a form class called frmFoo. In the code for the program you might see:
frmFoo.Show()
or
frmFoo.UserDefinedProperty = True
During some recent changes, I created variables to represent instances of my forms much like these:
Public MyForm as frmFoo
MyForm = New frmFoo
MyForm.Show()
In doing so, I also removed code from the form's Load event handler and put it in the form's constructor.
When the form loads, or when a document is loaded and should influence the TabControl's selected index, something like the following will not necessarily fire the SelectedIndexChanged event.
MyForm.tbsForm.SelectedIndex = ValueReadFromFile
...or...
MyForm.tbsForm.Tabs(ValueReadFromFile).Select
Sorry to be so wordy, but there's more. If I open the form and look at the TabControl to verify that it's been set properly, everything works like it's supposed to. The misbehaving TabControl is contained within another TabControl, so I have to click the parent TabControl to see it. If I can see it, and run a test, the test always works. If I can't see it, and run a test, the first test I run will not fire the event. ...paging Dr. Heisenberg...
It's almost as if the control has to be initialized first by changing the value or making it visible onscreen...I'm totally lost on this one. It's the most unusual behavior I've ever seen. And everything worked perfectly before I began using variables to represent forms and placed the Load event code into the form constructors.
Can anyone help, or at least put me out of my misery?
SH
-------------------------------------------------------------- Edit #2
I just performed a test after having attempted to eliminate some of the variability in the behavior. But I wanted to confirm the previously-stated behavior.
I opened the program and read a file. This file contained a value that should have triggered the event handler. Without making the control visible, I can change the SelectedIndex property of the tab control without the event firing.
I closed the program down again, and reopened it. This time, selected the parent tab that allowed the child tab (the one whose event I'm concerned with) to become visible. I then selected a different tab in the parent control, meaning that the child control was no longer visible. When I opened the same file as before, it fired the event.
I'm tempted to implement a flag that confirms that the control has been repainted or whether the parent tab has been displayed. I may have to fire the event in code if the flag isn't set.
I want to reiterate that everything worked when the program referred to the forms by their class names and much of the arrangement of controls on the forms was done in the load event. Now the program creates variables and the arrangement of the controls is done in the form's constructor. I'm sure this has something to do with the problem I'm having, but I can't understand how. Any wisdom to share?
MyForm.tbsForm.SelectedIndexChanged = ValueReadFromFile
doesn't make a lot of sense. Is tha trying to assign a handler to the SelectedIndexChanged event? or is ValueReadFromFile the name of the tab?
What you're saying is that you have two tab controls, say, A and B. Tab control B is contained within a tab of A, and unless A has the tab page selected that contains the tab control B, the SelectedIndexChanged event of B will not fire if you change its tab programatically?
In which different ways have you tried to select a tab within the child tab control, and when is this code being executed?