I am trying to update a selected record using this code when closing the form:
interestsTableAdapter.Update(newCityCollectionDataSet);
The record is NOT updating doing this. I use the same code to update datagridviews but I do it while it is validating. Is there a better way to do this with FORMS as opposed to controls?
Why this isn't working could depend on when you're trying to save your record. There's a big difference between executing code before your form's closing and while your form's closing.
Typically, failures while the form's closing (in handlers of a Form's FormClosed event) are caused by the application exiting before the handler gets a chance to do its job.
On the other hand, handlers of a Form's FormClosing event are invoked before the form even starts to close, and can even keep it from closing. These handlers are almost always waited for, as long as the form is the application's "main" or "startup" form (and not a child of it).
Without seeing more code than what you've provided, I'm afraid it's all I can do to advise you to execute your code before the form closes (via its FormClosing event), rather than while it's closing (via its FormClosed event).
Related
I have a form app with two Forms. In the second form I have in the right corner the x button. How I can make when I make click on this button to close the app, not just hide the Form2 window?
First you need to catch the event. To do that, set an event handler on the child form's FormClosing event.
Then there are several options:
"Brute force" termination using Process.Kill().
This will terminate the process without letting any cleanup code to run. It has an effect like ending a process through the task manager. You can get the current process with Process.GetCurrentProcess. Use like this:
Process.GetCurrentProcess().Kill();
"Gentle" termination by way of closing all windows using Application.Exit().
This will close all message pumps and windows, but will do so while allowing normal cleanup code to run. It does not however guarantee the process will be terminated, for example if a forgound thread is still active after message loops are done. Use like this:
Application.Exit();
Communicate intentions to the main thread.
This is a design solution, not a "line of code" you put somewhere. The idea is that the 2 classes (of the 2 forms) have some communication mechanism (via message, events or whatever you see fit and probably already use), and the child form notifies the parent form the user wants the exit the application. Then it's up to the main form to cleanup everything, close all forms (itself and others), and exit the process normally. This is the cleanest and preferred method, but requires a proper design and more code.
If you are using form the simplest is using
this.Close(); or Application.Exit();
Which Event is occurred before Form Load event??
Because I have a timer control for which I have written timer.start() method in form load event and current time is displayed in Label Control.
Timer starts when the form Loads but it takes few seconds to show the time, so is there any other way to show the time fast?
Have a function called ShowTheTime. Call it in form load. Also start your timer in form load. Your timer handler also calls ShowTheTime.
Am I missing something here? It seems kind-of trivial.
You're probably using the Timer from the Forms namespace. That component is tightly coupled to the UI. You should take a look at the Threading.Timer class which is not tied to the UI. You will have complete control over it and can start it from the Form's constructor (or even earlier, before the form is created.)
This is a very old article but the concepts in it still hold. (Compares the different Timer classes.) Basically an abbreviated version of the previous article.
I'm currently working on an application that uses a Windows Form GUI. The main work of the application will be performed on an additional thread - but it is possible that it will be dependent on the state of the form.
Because of this, before I create the thread I must make sure that the form is completely loaded. Also, I need to make sure the thread is terminated before the form begins closing.
Possible solutions for this problem might be overriding the OnShown and OnFormClosing methods.
Does the OnShow method really gets called only after ALL of the assets of the form have been loaded? And what about the OnFormClosing - can I be sure that any code executed in this method will be performed before the form begins close / dispose?
I suggest you read through the WinForms event ordering as posted on MSDN:
http://msdn.microsoft.com/en-us/library/86faxx0d.aspx
Windows Forms events can be tricky, and the order they fire unreliable. For example, the 'Shown' event is meant to fire once and once only, when the Form is first displayed, but just yesterday I found a way to completely prevent that event from firing by manipulating Form.Visible flags at the right time.
So, you need to be quite specific about your needs. For example - when you say 'completely loaded', what do you mean? Controls created, form visible, Form constructor finished executing?
Likewise, the FormClosing event might be circumvented by an unhandled exception in your main aUI thread, which results in the Form being removed without the event firing.
I suggest never assuming anything around these events. Make your worker thread capable of dealing with the Form state being unavailable, or not ready. Without knowing your exact requirements, it's hard to be more specific.
Have you tried to use InitializeComponent on the constructor of your main WinForm and use OnLoad (called whenever everything is loaded)?
I have an application that runs continuously, it creates and destroys classes some of which have events like mouse click events and the like...
First question is what is the proper way to unsubscribe? If the subscribe looks like this:
Panel1.MouseClick += new MouseEventHandler(Action_MouseClick);
is it proper to unsubscribe like this:
Panel1.MouseClick -= new MouseEventHandler(Action_MouseClick);
OR is it ok to do this:
Panel1.MouseClick -= Action_MouseClick;
or is either way ok?
My other question is is If I use the Microsoft Visual C# studio to create the events through the designer, does it automatically unsubscribe as part of the 'Dispose' method? Or do I still need to put the unsubscribe method in the code?
Either way of unsubscribing will have the same effect, and both are correct.
As for your other question .. if you use the designer to create events for controls on a form, when the form is disposed the source of the events no longer exists, so they won't be called. I guess I'm saying it isn't necessary to detach those events.
My other question is is If I use the
Microsoft Visual C# studio to create
the events through the designer, does
it automatically unsubscribe as part
of the 'Dispose' method? Or do I still
need to put the unsubscribe method in
the code?
From memory: no, it won't generate the un-subscribe code.
You can double check this yourself by opening the classname.designer.cs file and examining the generated Dispose method.
The designer code won't automatically unsubscribe, but the subscriptions should not keep the controls alive as long as the form and all of its controls are no longer accessible from the application code. Lingering event handlers are mainly a problem when the subscriber and event producer have different lifetimes, which generally shouldn't be the case for a Form and its controls.
If you create/remove controls dynamically, you will probably want to manage the events, though it's not strictly necessary if the removed controls are no longer referenced and the removed controls stop firing events.
I am having a form in my application Form1. A thread is running in this form. When i am showing the next form Form2, I am hiding this form and aborting the thread.
When I am showing the parent form again , i need to restart the thread again.which event
in the main form I can write thread restart code?
While the VisibleChanged or Activated events may do this, I have to wonder why you don't just do it explicitly - it's your code that will be showing the form again, isn't it? Why not just create a new thread as part of the code that gets executed at that point?
As a side note, if you really are aborting the thread (with Thread.Abort) it would be worth moving to a more graceful shutdown procedure, setting a flag which the thread checks periodically. Hard aborts of threads are prone to leaving the application in an unknown state.