I have issue:
One thread raises event that is listened from main thread.
Main thread in eventHandler raises
message dialog like this:
MessageDialog md = new MessageDialog (parent_window, flags, msgtype, btntype, msg);
md.Run ();
md.Destroy();
However application crashes on md.Run(); (if i raise messageDialog using gtk.application.invoke() there is no crash but there is also no modality in dialog.)
GTK objects can only be accessed safely from the main thread. If you subscribe to an event from the main thread, that does not mean that the event will be raised from the main thread. Events are raised on the thread that raises them.
What you need to do is to use Application.Invoke to safely queue a delegate on the main thread's mainloop, and access the GUI objects from that delegate. You can do this in the event handler, or you could even use a delegate to dispatch the event onto the main thread, so that event handlers would not have to do so - it's just a question of how you want to define your internal API.
Note that although Application.Invoke runs the delegate asynchronously, this does not affect the modality of the dialog. The thing that affects the modality of the dialog is whether you include the DialogFlags.Modal flag in the flags parameters.
Related
I have a notification which can be posted on a background thread. This notification eventually leads to calling setTitle:forSegmentAtIndex:, which is UISegmentedControl, part of the UIKit.
Should it be assumed that I need to wrap this setTitle:forSegmentAtIndex: call with a async call to main thread, or will some lower lying Cocoa code automatically dispatch anything like setTitle:forSegmentAtIndex: to the main thread?
Always dispatch code that modifies a UI control to the main queue. Always.
I have a window which runs from a thread, let's call it MainThread, and a background thread which performs other non-graphical tasks.
Sometimes the background thread will call the MessageBox.Show(...) method (which is modal and stops the background thread). Before this call, I would like to suspend the MainThread and resume it after so that my MainWindow's controls are disabled while the messageBox is shown.
So my questions are:
How do I access the mainThread from the backgroundThread?
How do I suspend/resume it (Considering Thread.suspend is depricated)?
Instead of suspending the main thread, you could use Control.Invoke (Windows Forms) or Dispatcher.Invoke (WPF) to actually show the message box on the main thread, but call it from your background thread.
In addition to providing the behavior you wish, this would also have that advantage of allowing you to parent your message box to the proper Window, which would give the proper modal message box behavior.
I'm reading data from a serial port, but the DataReceived event of SerialPort is handled on it's own thread. I want to handle this on the main thread, but simply declaring an event and raising it still results in it being processed on the SerialPort thread. I'm assuming I need to declare a delegate I can call, but I don't see how that would work.
For example, I want to call Sub HandleDataReceived() on the main thread from the DataReceived thread, having HandleDataReceived() run on the main thread. How would I do this?
If the main thread is a UI thread, you can use its SynchronizationContext or call Control.BeginInvoke.
When I start a 2nd background thread and pause the main thread, will my First Responder still be in action? For example I have an overwriting method called -flagsChanged and was wondering if it would still be active if the main thread is offline.
Thanks,
Kevin
Don’t pause the main thread since the main thread is responsible for handling events and your application UI will become irresponsive. If the main thread is paused, it won’t handle events, hence it won’t dispatch key events to the first responder.
If you think you need to pause the main thread, you probably need to redesign your program so that the behaviour that requires sleeping (if it does require sleeping) is offset to a secondary thread. If you need to update the user interface from a secondary thread, you should use -performSelectorOnMainThread:withObject:waitUntilDone:.
I have a BackgroundWorker object that I instantiated to perform a DB process on a background thread ansynchronously. I have event handlers for DoWork and RunWorkerCompleted.
I can tell that the BackgroundWorker is disposing of itself because I added a MessageBox into the Disposed event handler.
My question is this:
Is it necessary to detach the event handlers to ensure that the memory is cleaned up and that there are not memory leaks?
If an event publisher is being garbage collected, then there's no need to unsubscribe. You only need to unsubscribe from events if the event subscriber (the target of the handler delegate) needs to become eligible for garbage collection before the publisher does.