I'd like to know if there is a possible way to handle a closing application in Visual Studio 2008 without using the dispose event handler.
If my application crashes or if I close it while it is running:
Private Sub Foo_Disposed(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Disposed
Is not called.
This result in a serious problem, because I'm currently working on multiple Excel files and they remain open after the application crashes or I close it while it's running.
Is there a way to handle this kind of closing application event?
In a normal situation when your application is simply closing you can subscribe to the MyApplication.Shutdown event and close your excel documents in there.
Subscribing to the event can be done through these steps:
Right-click your project in the Solution Explorer and press Properties.
Go to the Application pane and press View Application Events.
In the file that was opened, either write the event handler on your own or let VS do it by first selecting (MyApplication Events) in the left combo box above the text editor, then selecting Shutdown in the right combo box.
Now you should have an event handler that looks something like the one below. Just go ahead and do your cleanup in there:
Private Sub MyApplication_Shutdown(sender As Object, e As System.EventArgs) Handles Me.Shutdown
'Do your cleanup here...
End Sub
For application crashes caused by CLR exceptions you can use the AppDomain.UnhandledException event, but for more serious crashes there isn't very much you can do.
A workaround would be to create another application which monitors your main app. When the other app senses that your main application's process has been terminated, it will close the excel documents. The tricky part with this solution is passing the information necessary for the other app to close the documents.
Is there a simple way to catch all exceptions in your VB.NET applications? I'm interested in making it so that instead of my users seeing a runtime error, they just are told that an error occurred and to contact tech support, then the relevant error information is logged so our support team can look at it afterwards.
You can use the OnUnhandledException application event to catch (almost) every exception that wasn't handled by the code.
On the Project Properties window (double-click project file on the solution explorer or Project Menu -> [Project name] properties), the Application page has a "View Application Events" button that creates a new file in your project.
In that file there are some events that are fired at application level; one of those is the UnhandledException. Whatever you put there will be executed instead of the classic JIT dialog. The UnhandledExceptionEventArgs object has an Exception property with the unhandled exception object, and a ExitApplication property that decides if the application should exit or continue executing.
Namespace My
' The following events are available for MyApplication:
'
' Startup: Raised when the application starts, before the startup form is created.
' Shutdown: Raised after all application forms are closed. This event is not raised if the application terminates abnormally.
' UnhandledException: Raised if the application encounters an unhandled exception.
' StartupNextInstance: Raised when launching a single-instance application and the application is already active.
' NetworkAvailabilityChanged: Raised when the network connection is connected or disconnected.
Partial Friend Class MyApplication
Private Sub MyApplication_UnhandledException(sender As Object, e As Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) Handles Me.UnhandledException
MessageBox.Show(e.Exception.ToString) '<-- the exception object
e.ExitApplication = True '<-- True if you want the application to close; false to continue - if it can
End Sub
End Class
End Namespace
Note that there are still some "über-exceptions" that can't be caught even with this method (out of memory for example), but this way you can log what exceptions are not being correctly handled on your code, or what scenarios are actualy happening that weren't considered at the beggining.
More info here
As a side note: don't rely too much on this event. This has to be for extremely exceptional cases, as what is caught here should be treated ASAP in the corresponding class/module/method. This is a helpful tool for debugging and test cases but having too much exceptions being handled by this event would be a sign of something wrong in your code.
It depends on what environment your application is running in. If you are using WPF or WinForms, you would launch your application using a main method instead of directly launching a form or page. Your main method should then wrap the calls to instantiate the UI in a try catch block.
So, for a WinForms Application, you could do something like this:
Sub Main
Try
Dim MainUI As New Form1
MainUI.Show()
Application.Run
Catch ex As Exception
'Do that fancy exception processing
End Try
End Sub
You can do something similar with WPF. But, WPF also supports an event model where you are notified of exceptions, very similar to the one that ASP.Net uses.
You will never be able to catch the StackOverflowException.
All the others for sure yes. I'm not familiar with VB, but it is easy to achieve in C#. For VB, I think the generic exeption handler could be
Try
...
Catch e As Exception
...
End Try
Of course this has to wrap all your code. You can find more for examples here.
If you have forms application, it is not practical to have the handler around Application.Run() as the only event handler. Keep it there, but add also two others:
When inside the form, and exception occurs, you want to keep execution in that context – keep the form open etc. For this purpose, use ThreadExceptionEventHandler.
And also, for case when application is irrepairably crashing on some problem, add handler to Dispatcher.UnhandledException event. It is last thing executed before the application ends. You can log the exception to disk for later investigation etc. Very useful.
Let's see some good resource how they are applied.
So I have a Visual Basic application created in Visual Studio 2013 and I am trying to find a way to gracefully handle unhandled exceptions. I have graceful failing covered pretty well in the application but want to plan for something I missed.
So, that said. Is there a way to not show a user an unhandled exception directly but rather trigger a function or class that will display a friendly message to the user and write the technical stuff to an error log?
UI frameworks typically have a default handler in their main event loop which raises an event if an exception is thrown inside the loop, but the details vary depending on the framework. If your application is WPF-based, unhandled exceptions on the UI thread will raise Application.DispatcherUnhandledException. If it is WinForms-based, unhandled exceptions on the UI thread will raise Application.ThreadException.
The .Net runtime will raise AppDomain.UnhandledException on exceptions that aren't handled anywhere on the call stack (such as from worker threads).
Assuming Winforms, try this:
On the 'Application' tab of the Project Properties window, click the 'View Application Events' button towards the bottom.
Within the partial class that's generated for you, create a sub like this:
Private Sub MyApplication_UnhandledException(ByVal sender As Object, ByVal e As Microsoft.VisualBasic.ApplicationServices.UnhandledExceptionEventArgs) Handles Me.UnhandledException
...
end sub
I'll leave the friendly message and logging to you.
I have a timer that each time displays a message box saying "Hello." I also have the code configured so whenever the window loses focus, it should stop the timer that keeps the boxes coming. However, they keep coming.
I have tried a similar thing in a similar program with way too long of code to post here, but what it did was it paused the first time, stop the timer, and when the timer was stopped again, it didn't work correctly. There was also some other code there that had a random element, that displayed a different prompt when a certain number was generated, but once it was generated, it kept using that same different prompt every time.
Is this a error of not enough time to process all the code and it "overlaps" some? I can delay the timer without that much different effects, but I think that my [lower end] CPU that it is running this program on, that with 1.6 GHz that it could handle a timer with a few message boxes. Though, VS is running at the same time, but I shouldn't have to export my code and close VS everytime that I need to test it.
If the problem is not enough time, is there a way that I can prevent my program from "multithreading" or whatever it is doing? It seems like a weird problem, but computers are very weird too. :P
Edit:
By "Focus" I mean the selected window that is the most apparent. For example, my browser is now "focused." I have been informed that the correct term is "selected." I must have been using the wrong type of event trigger... :P
It doesn't generate a lost-focus event because the form doesn't have the focus in the first place. A control on the form always gets the focus, like a Button or TextBox. You could use the Deactivate event instead.
Or just not display the message box when the Tick event fires again. Roughly:
Private ShowingMsgBox As Boolean
Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles Timer1.Tick
'' Do stuff
''
If Not ShowingMsgBox Then
ShowingMsgBox = True
MsgBox("yada")
ShowingMsgBox = False
End If
End Sub
The underlying reason for this behavior is that MsgBox pumps a message loop. It keeps normal Windows messages getting delivered, like WM_PAINT that keeps the windows painted. And WM_TIMER, the one that generates the Tick event. The only kind of messages that it blocks are input events, mouse and keyboard messages. Otherwise the reason that Application.DoEvents() is so very dangerous. It does the same thing as MsgBox() does, without disabling input.
Create a new project with a Timer (Timer1) and write this code:
Private Sub Timer1_Tick(sender As System.Object, e As System.EventArgs) Handles Timer1.Tick
If (Me.Focused) Then
MessageBox.Show("Hello")
End If
End Sub
If you put the mouse over your form, you would see that a message box will popup after the given Interval is over. If you don't click on the accept button and keep the mouse on the form, you would see that no further messages appear: Me.Focus is False. If you click on the accept button, the messages would start poping up; you don't even need to select the form (the focus is transferred automatically from the MessageBox to the Form).
Summary: the MessageBox does make the Form to lose the focus, although it is a kind of a "tricky" lost as far as will automatically come back after clicking on the accept button.
UPDATE: the proposed configuration does trigger a LostFocus event of the form:
Private Sub Form1_LostFocus(sender As Object, e As System.EventArgs) Handles Me.LostFocus
MsgBox("lost")
End Sub
Unlikely the other answers/comments, what I understood from your question is that you want to know the reason and if this is a normal behaviour, rather than getting a working solution to make the form to lose the focus (you are not even describing the exact conditions under which you want this to happen).
I fear that there is something obviously wrong with my code, but I have come across a situation where the Form.Load event is not firing when I create and show my form.
The form is not subclassed (as I've seen some problems with that in some searches), and I am not getting any errors thrown when I step through the code in the debugger.
I have a break point set on the IDE-created form load function (which does have the Handles MyBase.Load signature suffix) but the breakpoint is never reached and the form does display and work.
The form is passed three arguments in the constructor but the IntializeComponent() function is called before anything else is done.
Code:
Public Sub New(ByVal argA As Object, ByVal argB As Object, ByVal mode As FormMode)
' This call is required by the Windows Form Designer.
InitializeComponent()
' Other code here,
' No errors generated
'
End Sub
The form load function is as follows, (but this is never actually executed as the event is not fired).
Code:
Private Sub frmInstrumentEditor_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
If Not argA Is Nothing Then ' argA set in constructor
' Operations using argA
End If
End Sub
I might add I am using some databinding with some controls and the argA object, but if this was producing an error I thought I would have seen this (I have CLR Execpetions settings set to Thown in the debugger > exceptions window)
Any ideas why this might be occurring?
I just had a similar issue (it was in Shown event, not Load, but the root cause is the same). The reason was hidden deep in one of the ancestors - there was an unhandled NullReferenceException thrown and this exception was somehow "muted".
I found it after extensive debugging with F11.
But... when writing this answer I found this post on SO
Just add Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException) in your Main() method.
If you're using a 64-bit machine, it provides you with the solution (it worked in my case, too).
I had a similar problem. On opening the form for the first time, the load event would not be tiggered but on opening it the second time, all would be well. The problem tuned out to be one of my text boxes which was bound to a field that I had deleted from the database (sql server - I was using datasets, tableadaptors and bindingsources in a fairly standard way).
Make sure that all the controls on your form that are databound have fields that exist in the dataset and that the dataset is an accurate reflection of the underlying database table (the easiest was to do this last bit is to use the "Configure data source with wizzard" button on the data sources window (menu -data - show data sources) and remove the table. Then use it again to add the table back- this should make sure all the data matches.
Hope this helps.
OK I had the SAME problem (I think) and the clues here helped. It was databinding (sort of)
I had properties of some controls bound to settings and when I delete these settings the form load event stopped running. Removed the bindings and now it is running again.
Here is another idea.
What happens if you set all exception types (not just for the CLR) to be thrown instead of user-unhandled. Does the application break anywhere at all?
Also, just to double check, you are in debug mode right?
The problem you are experiencing may be caused by the application needing to fully load the form before you can do the "other code." This could be due to the other code dealing with objects on the form that haven't finished loading. You could use a timer that gets enabled in the load function to execute the other code. This way you don't have any timing issues and you can first load the form, and then a split second later, run the code you want from the timer.
Is your windows form inheriting from a base page? If so, the base page probably also has a Form Load event handler. In that base page Form Load event handler you will probably find an exception that is being thrown. So it is exiting the base page form load event handler and not firing the form load event handler in your inherited windows form.
I had a similar issue, the problem was a mistake in the databinding. Omit the code for databinding and give it a try. I think the load event handler will be hit. Then see what's wrong with the databinding part.
Had the same problem. Checked my data bindings, everything looked ok. Got to thinking, even though form was closed, maybe .NET wasn't sure (old days, sometimes forms were only hidden and not really closed).
I added the event handler FormClosed and put a single line in it:
Private Sub frmScheduleInquiry_FormClosed(sender As Object, e As System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed
Me.Dispose()
End Sub
Problem solved!
Solved....
Have spent 4 hours and finally got clues from this answers.
in my case i was having couple of TextBox control on the form bound to a BindingSource with respective column, i still have that bindingsource on the form but what was happened that i deleted one column from underlying database table so on the form there is still one TextBox exist pointing to that column with bindingsource, in fact there is no column like that because i deleted !..... this lead Form.load event was not firing ........finally fixed..
thanks to all of you ..
I had the exact same problem just happen to me. Turns out I had added some ApplicationsSettings properties to a form TextBox control, but later wanted to delete them. I thought I had cleared everything out, but obviously I didn't - and this was what caused the Form_Load() (and maybe other events as well) to not fire. Deleting and then re-adding the offending TextBox did the trick.
Hope this helps
Matt is probably right about this one. Have you tried adjusting your code like this:
Private Sub frmInstrumentEditor_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
If Not argA Is Nothing Then ' argA set in constructor
' Operations using argA
Else
MessageBox.Show("argA has not been set")
End If
End Sub
If the messagebox appears it means that the event is fired before your argument is initialized. It would also account for the 'strange' behaviour concerning closing/opening the form.
Have you tried running the argA operations in the 'Shown' event?
Not sure if this will help, but I just ran into this issue because somebody mistakenly deleted the Handles Me.Load. I see you show MyBase.Load try changing it to Me.Load.
I had a similar issue. It turned out that I was not using the Show method on the form - instead using a user32.dll ShowWindow call. This means the form still appeared, but the Load event was never fired because the dotNet Show method was never called.
I know that this is an old post, but I thought that if someone was searching this issue, that my fix to this problem might help.
I was having this same problem as stated in the originally posted question, but I didn't have any data bound fields on the form. I found that the problem was in the fact that I was using the CurrentDeployment.CurrentVersion method and it was causing the silent problem. I set the application from debug mode to release and the problem still existed. Through trial and error I remarked out the defining method Dim xVersion As Version = ApplicationDeployment.CurrentDeployment.CurrentVersion
and presto... its now working as usual.
I ended up changing the orginal code the code below.
Dim xVersion As Version = ApplicationDeployment.CurrentDeployment.CurrentVersion
sysVersion = String.Format("{0}.{1}{2}.{3}", xVersion.Major, xVersion.Minor, xVersion.Build, xVersion.Revision)
New code
#If (DEBUG) Then
sysVersion = "[Debug mode]"
#Else
Dim xVersion As Version = ApplicationDeployment.CurrentDeployment.CurrentVersion
sysVersion = String.Format("{0}.{1}{2}.{3}", xVersion.Major, xVersion.Minor, xVersion.Build, xVersion.Revision)
#End If
I hope this helps someone.
Happy Coding...
Same problem, I rewrote the designer and that fixed it. The designer was loading then crashing (silently of course), and form_load was not firing due to that.
Had same issue, but cause was totally different.
Form was being shown using form.Show() instead of form.ShowDialog()
I experienced this symptom when building and running a .NET 4.0 WinForms application which loaded a series of older assemblies (.NET 2.0; .NET 1.1).
In the past I had seen this cause a mixed-mode assembly exception. In this particular case, the main Form loaded without exception and without executing any of its Form Load code.
The solution, in my case, was to set useLegacyV2RuntimeActivationPolicy="true" in the App.config document.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
Make sure your "Solution Configuration" box at the top of your IDE is showing "Debug".
I found that if it showed "Release" the "Load" method was not captured by the debugger.
In my case, the main form had WindowState: Maximized set in the designer. This was causing the window to be drawn on screen prior to the Load event firing.