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
Related
I have a custom ribbon and one of the buttons on it (image and label for the button) are supposed to change based on what happens in one of the forms (so, essentially, it's supposed to change when values in a table change and making changes in the form is the trigger for the change).
On the CLOSE button of the form I have the following code:
sbRefreshRibbon
MyRibbon.Invalidate
and here is what the procedure does, so the MyRibbon.Invalidate part is probably redundant:
Public Sub sbRefreshRibbon()
On Error GoTo RestartApp
MyRibbon.Invalidate
On Error GoTo 0
Exit Sub
RestartApp:
MsgBox "Please restart Application for Ribbon changes to take effect", _
vbCritical, "Ribbon Refresh Failed"
End Sub
In any case, sometimes, when clicking CLOSE I get the "Please restart Application for Ribbon changes to take effect" error. After restarting, all is well, the label is correct and so is the image
but, how can I make the label and image change without errors and restarts?
There is no need to call the Invalidate method of the IRibbonUI interface multiple times. You need to left a single call as soon as your form is closed.
Also you may consider using the InvalidateControl method of the IRibbonUI interface instead. It allows invalidating the cached value for a single control (not the whole custom UI) on the Ribbon user interface.
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.
I have a custom ribbon in Visio that displays correctly, except when I click to expand a SplitButton. When I expand the SplitButton, it calls the GetImage callback for my ribbon, and loads the bmp file using LoadPicture, but does not actually display in Visio. The next time I expand the SplitButton everything is fine.
Is there something I need to do in the callback to prompt the ribbon to display correctly when using a SplitButton?
We currently use a class that implements IRibbonExtensibility with callbacks for GetImage and OnAction, and they work fine for normal buttons, but we get this behavior only with SplitButton usage.
This is what I see the first time I click the drop down:
It is not clear what code is used for the custom Ribbon UI.
The getImage callback should have the following signature:
C#: IPictureDisp GetImage(IRibbonControl control)
VBA: Sub GetImage(control As IRibbonControl, ByRef image)
C++: HRESULT GetImage([in] IRibbonControl *pControl, [out, retval] IPictureDisp ** ppdispImage)
Visual Basic: Function GetImage(control as IRibbonControl) as IPictureDisp
Make sure that you return the IPictureDisp instance which points to the image you loaded. See Chapter 11: Creating Dynamic Ribbon Customizations (2 of 2) for a sample code.
The issue came down to the use of the DoEvents statement, which was added to our stack trace code in our codebase. Every time we enter a routine we push the routine name onto a call stack and then pop it on exit, but this routine also had added the DoEvents statement to help break out of any loops during development.
It would seem that, since we add the ribbon via a Document Created/Opened event, executing DoEvents must be causing Visio to not correctly process the ribbon loading callbacks. Removing the DoEvents statement fixed the problem.
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'm developing a WinForms app in VB.NET, that handles sets of style data, and when the user clicks on another set's label, it prompts through a dialog "You are leaving this style preset to edit another one. keep changes on this one? [Yes] [No]"
But, I'm facing the problem that, when the user clicks either option, and the dialog closes, everything has to be refreshed, and loading the form again seems a good option.
I've tried putting a public sub on a module, that does this:
Public Sub CloseOpenStyleDlg()
KeepOrDiscardPrompt.Close()
StylesDlg.Close()
StylesDlg.ShowDialog()
End Sub
But as soon as that sub is called from the prompt, it crashes the application. (doesn't show an error in debug, simply crashes) How should I, from a given dialog, close the dialog, it's parent, and re-open it's parent? (which triggers all the Dialog_Load() code of the parent)
Thanks in advance! :)
You need to instantiate the dialog again. If I take your code for example:
Public Sub CloseOpenStyleDlg()
KeepOrDiscardPrompt.Close()
StylesDlg.Close()
StylesDlg = new StylesDlg()
StylesDlg.ShowDialog()
End Sub
When a form is closed, all resources created within the object are closed and the form is disposed.
If you want to reuse the Window instance use StylesDialog.Hide() function instead.