I have a form and a button. When you press the button, i want it to load my second form. On the second form is a webbrowser which loads a site.
Thing is, the second form takes a few seconds to load. So i need to implement something to tell the end user, hang on.. We are trying to load something.
The best and simple way would be to update the button clicked text value to: Loading...
I had code to change the text on the button, then load the form.. Thing is, the label would not change but would change AFTER the second form loaded! <-- I did my research and found out its cause im doing single threading?
If i place Application.DoEvents() after my label change then it works, but i also searched its overkill and shouldnt be used? What would be a efficient and effective way to update my label without hogging a lot of resources?
My code:
label1.Text = "Loading..."
Application.DoEvents() 'Without this, label only changes AFTER form completes loading
secondform.Show()
me.hide()
I think normal practice is to have an Hourglass pointer during times when a program is executing something.
Also, you can have your 'web window' load hidden (visible = false) and have it appear once the page is loaded inside the web control.
Just a thought.
Related
I am trying to put an animated loading gif on a form during a long subroutine execution (specifically, sub being fired on a form's button click event), and it turns out to be surprisingly difficult in MS Access.
I already have my gif animation put on the form, linked to ActiveX Web Browser control (call it loadingGif in example below). It turns out, that doing simply:
Private Sub someButton_Click()
loadingGif.Visible = True
'... hard stuff here ...
loadingGif.Visible = False
End Sub
fails because screen doesn't get refreshed during subroutine execution, and so the user never sees the loadingGif control. Is there any way to make it visible during single subroutine execution?
Also:
I know it is possible to create an animated modal pop-up form instead, but that's not the idea
I already also use Hourglass, but icon on a form seems much more appealing
What is the difference between form.Close() and form.Hide() in desktop application.
i know Form_Close event will not be fired in form.Hide() method what about other differences.
Is anyone faster?
form.Close() unloads the form from memory and makes it available to be garbage collected; you can no longer interact with the form in code.
form.Hide() just hides the form, but you can still interact with it in your code.
So it is not really a question of which one is faster, but rather "are you really done using this form or not"?
Hide makes the form invisible to the user. Close actually closes it and calls dispose on it.
From: http://msdn.microsoft.com/en-us/library/system.windows.forms.form.close(v=vs.110).aspx
"When a form is closed, all resources created within the object are closed and the form is disposed. "
Hide only hides the form from the screen. Close is of course closes the form. If you want to get rid of the form that you don't want to use anymore then you should use Close. Hide and Close are different things.
Ditto the above... Typically the way you open the form determines which to use. If you use .Show() the calling code continues while the form is loaded and shown. If you use ShowDialog() then calling code stops while the form is loaded and shown. When you Hide the called form the calling code resumes to the next statement.
Here is a sample of the second case:
Dim frm As New frmSearch2
frm.inFormName = "frmFacility"
frm.ShowDialog(Me)
If frm.outPrimaryKey.Length > 0 Then
frmMain.Open_Form("frmFacility", frm.outPrimaryKey)
End If
frm.Close
frm = Nothing
outPrimaryKey is a form level Public variable. You can also address any of the controls on the form.
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 an application that searches in a database for some information.
Since the database is quite big, it sometimes takes a lot of time before the application returns the results to the interface.
I want to add some sort of spinning wheel to inform the user that the application is still searching the database and did not freeze. Once the results are returned, the wheel should disappear.
Any idea how to do this or is there a good tutorial explaining how to do this?
Have you considered changing the mouse pointer to the hourglass as this would be extremely simple to implement:
Me.Cursor = Cursors.WaitCursor
...Do your DB calls here...
Me.Cursor = Cursors.Default
However, I would agree that display a 'spinning wheel' is probably a little more user friendly and definately a lot more obvious. So, first get hold of an animated gif that suits your needs. Then create a form that has a picture box containing the image.
Once you have that you can show the form to the user and in the background do the DB work, once this has completed close the form.
Another alternative would be to use a rolling progress bar instead, so when it reaches 100% it cycles around again and keeps going until you close it.
EDIT:
One thing that I forgot to mention is that you will have to handle exception conditions. Lets say you set the cursor to wait, then an error occurs. The exception may bypass the code that resets everything. This leaves the user with a changed cursor and no means of changing it.
When I have done this kind of thing I have typically created a disposable WaitCursor class and then used something like this:
Using myWaitCursor As WaitCursor = New WaitCursor
...do something...
End Using
In the Dispose of the WaitCursor class you set the cursor back to default. The same would apply if you went down the route of using a form with an image or progress bar.
Find an animated gif of such a spinner, like this one. Put it in a PictureBox, set its Visible property to True when you start the job. Beware that you'll have to run the query in a worker thread to keep the animation alive and the user interface responsive. The BackgroundWorker class is good for that.
You could use the Environments Default wait cursor, which for Vista/7 is a circle with the outside spinning, or the XP tumbling hourglass.
You could launch your DB access on a BackgroundWorker and show an animated control such as a Marquee progress bar, or you could show a custom animation to show Busy status.
I have a DataGridView control in my Windows Forms Application.
I am adding rows to the grid using a background thread. I change the form's cursor to Waitcursor when the process starts and back to Default when it ends. This works well for the form, but not for the grid. When the form's cursor is changed back to default, the grid's cursor does not change, although the cursor over the rest of the form does.
Does this have anything to do with the fact that I am updating the grid from a background thread? (The cursor is being changed from the UI thread directly).
Edit: The background process raises an event, the handler checks the InvokeRequired property of the grid and decides if it needs to "Invoke" the method again from the main thread. So, in effect the actual UI update happens from the appropriate thread. I am not sure if this means that I am "using a background thread" or not. :|
I've had some problems doing single thread updating of my datagrids, where the datagrid did not reset to normal cursor after i've had waitcursor to true.
What I did was right after i went
this.UseWaitCursor = false;
I added
DatagridviewFoo.Cursor = this.Cursor;
Maybe it's just the same problem for you
I've had this problem as well. It was difficult to track down the cause, let alone a solution.
This issue only ever happened when I had a dialog box over the DGV control and the mouse clicked on a button to close the box such that when the box closed, the mouse was over a (resizable) column border. If the cursor ended up over a cell, the problem didn't arise. If I had to guess, I'd say the grid was seeing a column resize event as soon as the dialog box closed which wasn't properly handled.
Using Cursor.Current = Cursors.Default fixed my issue (without the need to explicitly reset the control's cursor). But maybe be aware that Application.UseWaitCursor = False didn't work even with the explicit control cursor reset.
I had a similar problem, but neither of the posted solutions worked for me. Mine was not caused by clicking a button above a movable column separator. It just randomly happened after opening and closing a dialog box. I'm pretty sure it came down to timing because .Net/Windows has issues when it comes to setting cursors and actually having them take effect. To try to overcome that, the library we use for showing and hiding the wait cursor calls - ack! - Application.DoEvents. I set a breakpoint in OnCursorChanged and saw that the cursor was sometimes actually getting set on a latter call to Application.DoEvents (used to keep the UI responsive while waiting for the file system to release a write lock on a file). So I guess sometimes the default cursor was getting turned back on before the call to set the wait cursor had fully taken effect. Anyway, my brute-force approach is to call
Cursor = Cursors.Default;
in my override of OnCellEnter (which always happens after the grid gets refreshed following the dialog box being closed). I'm not particularly proud of this, but it seems to work.