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.
Related
What is the real order of events in a Windows Forms application?
What I mean is, when I put code in the Form_Shown event, I expect that code only to run after the form has been Shown:
verb (used with object), showed, shown or showed, showing. 1. to cause
or allow to be seen... - http://dictionary.reference.com/browse/shown
But the Form_Shown event is a little misleading. If I do some heavy stuff inside that event, it seems as though the code gets executed before the Form has finished been shown. Let's say that I have a MainMenu, a small Toolbar and a TextBox on a form.
I want to do some heavy stuff (nevermind threads and workers for now...), so the last event I can use I would think would be Form_Shown. So I put my heavy code in there, but when the Form begins to display, I end up waiting ~ 5 - 6 seconds for the Toolbar and stuff to display (which ends up happening after my heavy code does its thing.
Which leads me to believe that I'm subscribing to the wrong event. I don't want the Form_Shown event at all. What I really need is:
Form_WhenALLTheThingsHaveShownEventHandler event.
So, how can I know _when all the things (controls) have been fully loaded and displayed?
The Shown event is in fact the last event related to initialization that is raised. However, note that the actual rendering (drawing on-screen) of UI objects in Windows (and on other platforms) is deferred. The creation of a UI object merely allocates all the necessary resources and "invalidates" the visual area of the object. The platform then later schedules the rendering event (in unmanaged Windows, this is WM_PAINT, in the Winforms API this would be the Paint event for a Control instance).
The rendering event cannot be dispatched until the UI object's thread is available, and if you have long-running code in the Shown event, that will keep the UI object's thread unavailable for the duration of your code. I.e. nothing gets drawn until your code completes.
There are other events that you could use to more reliably detect when things have "settled down". For example, the Application.Idle event tells you when the main application thread is about to enter the idle state. Alternatively, you could just subscribe to the form's Paint event. In either case, you would want to use BeginInvoke() to dispatch your long-running code, so that you don't block the handling of those events.
Now, all that said: you really should not be performing any long-running work in the UI thread, period. Using either of the above events doesn't solve the underlying problem; it simply delays the problem until after the initial rendering of your UI. The UI will still remain blocked while your long-running work is executing, and frankly the user may actually find it preferable for there to be no UI at all, than for there to be something that looks like they can interact with but which they can't (i.e. is unresponsive to their input).
In the latest version of .NET, there are some very nice mechanisms available for shifting long-running work to background threads, so that the UI can remain responsive. See Task and the async and await keywords in C#. You could instead use the older BackgroundWorker object to accomplish the same, if you prefer.
There is a form. On the form there is a pictureBox docked on all form's surface.
When app starts, for a second a form with white surface is displayed, then
the picture is shown.
how can i get rid of that 1s white form?
Sounds like you are doing something time consuming in form_Shown event. Call Form's Refresh() method as the first thing in form shown -event and it will first draw the form, then do the time consuming things
You have not stated when you are loading the picturebox with your image. But I would try making your picturebox visible at the end of your Form_Load event or in your Form_Shown event.
Sounds more like a threading problem to me. I guess that your UI thread is doing too much work and cannot update the UI often enough.
Do all of the following:
Make sure loading and processing any data (including the images) is NOT located in the constructors.
Move that code into the appropriate FormLoad() event handler methods.
Implement loading of the images so that it runs a separate thread.
You can find some advice in this MSDN article: Give Your .NET-based Application a Fast and Responsive UI with Multiple Threads
If you are working in a .NET 4.x version, you can also use the Task Parallel Library to make working with multiple threads easier.
The upcoming .NET 4.5 also offers the even more comfortable await and asyc keywords: Asynchronous Programming with Async and Await.
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 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).
I am building a WinForms application reading from a socket data and charting lines.
I am using System.Windows.Forms.Timer to trigger each second the event that
gets data from a queue filled by a socket
redraws lines on the chart
My Question is about the Timer object: I have one Timer object for each WinForm having a chart to redraws; so suppose I have 20 chart, I will have 20 forms with a total of 20 Timers.
Is this a good approach? I decided this based on the following(please correct me if I am wrong )
Forms.Timer instance doesn't create a Thread on my application, but just triggers the event on receiving a WM_TIMER event from the message pump of the Form.
it lives in the same thread of the GUI so I can directly access each element of my forms without worrying too much.
Are too much timers a good approach or could I have drawback?
Thanks
AFG
This is a good approach, although you might want to reuse the timers instead of making a separate timer for each form.
For example, you could make a static Timer object and add a Tick handler in the form constructor. Remember to unsubscribe from the event when the form closes (in Dispose or OnClose), or your forms will never die.
maybe better approach is to use a worker thread to receive data and use event fired from that worker thread to notify the UI to redraw itself.
Why not redraw the line straight away when the data is received by the socket?