I have a problem similar to this one: How can I execute code after my form starts?
But the solution there won't work for me because I am not running a form, I'm running a single custom control, which is a tray icon that monitors things. (Similar to the Icon Dropbox has, where that is the only interface the user has with the program)
What should I do to run code when the control is created? (which has to be after the message pump starts)
I think you're looking for the Application.Idle event.
Occurs when the application finishes
processing and is about to enter the
idle state.
E.g.
Application.Idle += delegate { Console.WriteLine(Application.MessageLoop); };
// Output: true
Application.Run();
First option would be to post a windows message to yourself. That way it will not be dispatched until your thread starts pumping messages. A second option is to hook into the Application.Idle event which is fired when the message queue is empty. Your third option would be to set and run a Timer for a small duration and hook into the Tick event for when it expires. Fourth and the last for now is to fire a delegate asynchronously as they use the message queue as the mechanism for being fired.
Related
I'm using the WinEvents API for listening to an object focus, my problem is that I need to run some callback after the window focus was finished already (i.e. after the window has become the foreground window).
It seems that when listening to EVENT_OBJECT_FOCUS or EVENT_SYSTEM_FOREGROUND the event is triggered before the focus happens. I am looking for something that simulates an EVENT_OBJECT_FOCUSED kind of event. My current workaround is to wait 100 milliseconds before running the action which works but feels very patchy.
My BackgroundWorker's RunWorkerCompletedEventHandler invokes a function in my main thread, which shows a MessageBox dialog. I tested what happens if I invoke the BW periodically (with a Timer) and I don't understand why this causes me to get multiple message boxes over time. I mean, shouldn't the GUI thread be blocked during the call to my RunWorkerCompletedEventHandler function?
Whenever I close a dialog, the rest of the function gets executed as normal, for every dialog box.
If I replace the MessageBox.Show with a Thread.Sleep, then I don't have this problem. The function calls all get executed one after the other. No second invocation happens during the sleep, like it does with the MessageBox-es.
Why is this unexpected behavior happening for a MessageBox and can I change it to block the thread properly?
Displaying a message box (or closing one) is not an activity that requires continuous use of the UI thread. The UI thread is used to create new UI that represents the message box but it then goes back into (a version of) the message loop wherein it waits for new work to do.
This is why e.g. the message box can be responsive, be moved around the screen, etc, because the UI thread is free to react to the required events.
C# windows application's GUI halt on re-sizing application and i have to kill the process from task Manager.
I have search for the issue and got a link that point me to background invoker and other point me to userpreferencechange events.
I have check the userpreferencechange event and its fired but don't know how to handle this issue in this event.
The problem is most likely in one of these four:
OnSizeChanged() method
OnResize() method,
SizeChanged event handler, or
ReSize event handler.
They all get fired whenever your gui get's resized. I suspect that in one of these event handlers/methods you have some code that tries to do something fancy that either results in an exception, recursion or an infinite loop.
But, without you providing more detailed code, this is, of course, merely an educated guess.
I use VS2010 and C# to build a desktop application. This application has one form with a huge task which takes a lot of time to complete. When this form is initialized it works perfectly, except it shows “Not Responding” on the title bar, like the picture shows:
After completing all tasks, it shows the desired output. Why is this message shown, and how do I prevent it?
You need to use a BackgroundWorker so that the time consuming task will run in a separate thread asynchronously. That will allow Windows multitasking to make the UI responsive. You should use a wait cursor or some other visual indicator to let the user know that your application is busy.
From MSDN MSDN BackgroundWorker
The BackgroundWorker class allows you to run an operation on a separate, dedicated thread. Time-consuming operations like downloads and database transactions can cause your user interface (UI) to seem as though it has stopped responding while they are running. When you want a responsive UI and you are faced with long delays associated with such operations, the BackgroundWorker class provides a convenient solution.
To execute a time-consuming operation in the background, create a BackgroundWorker and listen for events that report the progress of your operation and signal when your operation is finished. You can create the BackgroundWorker programmatically or you can drag it onto your form from the Components tab of the Toolbox. If you create the BackgroundWorker in the Windows Forms Designer, it will appear in the Component Tray, and its properties will be displayed in the Properties window.
To set up for a background operation, add an event handler for the DoWork event. Call your time-consuming operation in this event handler. To start the operation, call RunWorkerAsync. To receive notifications of progress updates, handle the ProgressChanged event. To receive a notification when the operation is completed, handle the RunWorkerCompleted event.
You need to run your huge task on a background thread so as not to lock up the UI (main) thread.
I want to show a BalloonTip in the Application.Idle event of my program, but for some reason the Application.Idle event only fires after I mouse over the NotifyIcon. What gives?
Are you sure that Application.Idle is not getting fired? Simple way would be to log into the file whenever code enters the event and see if this happening.
Also understand that this event may not be suitable for your needs - it happens when message pump becomes empty (typically no keyboard/mouse input) - so as such you would probably receive this event too frequently (see this SO thread to understand more). In this case, I suspect that windows is suppressing the balloon tip perhaps because it is being shown too frequently.
As such, you can code to show the tip only if it has not been shown say in last 2-3 seconds. You may want to look at different implementations of Idle detection to suit your requirements - have a look at:
http://ellisweb.net/2008/02/detecting-application-idle-state-in-windows-forms/
http://blog.opennetcf.com/ctacke/2009/05/19/DetectingApplicationIdle.aspx
http://www.codeproject.com/KB/miscctrl/Application_Idle.aspx