I am porting a regular C++ app to metro in C++ using WRL. I have an existing thread pool and that some point I need to update the UI from one of these threads.
Touching directly the UI objects gives the expected RPC_E_WRONG_THREAD so I need somehow to execute in the right thread. Looking in MSDN I discovered that the metro dispatcher (CoreDispatcher) has a RunAsync method.
Larry Osterman sort-of answers the question of how to use it here:
Run code on UI thread in WinRT
But what is not clear is if I can do that from a non-winrt thread, that is from a thread which has not called RoInitialize.
I guess to be more precise I fear that the dispatcher might belong to an STA and I would need to somehow marshal the interface so it would be safe to call from my other thread.
Note that the main() function of my app following the msdn samples calls RoInitialize(RO_INIT_MULTITHREADED).
You should be ok calling CoreDispatcher::RunAsync from a non UI thread. But there are a couple of caveats:
1) You need to be in a metro style app (this should go without saying). The reason is that the application object creates an MTA that lives for the life of the application. There's this nifty feature of COM called the implicit MTA - if the MTA exists in your process any threads are considered to be a part of that MTA even if they've not called CoInitialize.
That means that when you access CoreDispatcher::RunAsync, even if you need to proxy objects, the MTA is active so the marshaling should succeed.
Note that there is a period of time during app startup where it's possible that the application object hasn't yet been created - you should refrain from doing anything until your application's code has been executed.
2) You need to capture the CoreDispatcher object on the UI thread you want to use. This is made easier by the fact that the Xaml infrastructure already captures the dispatcher in DependencyObject. So if you already have a Xaml UI element, you can just call .Dispatcher.RunAsync().
PS: The UI thread is on an ASTA (application STA, a new kind of apartment added in Win8) but the dispatcher is thread agile. Note that while the dispatcher is agile, the CoreWindow should not be considered agile.
Related
In my project it is necessary to display a lot of data at once in the mainwindow of my application.
Now I am not quite sure how to implement any parallelization into qt since qt does not allow modification from any other thread than the "main thread" to change ui elements.
Currently I do have only one for loop in my setup function and this creates my QGroupBox object on demand. I already tried to take the work load to other cores, but pickle was not able to process my mainwindow. My other experiment was to start a thread which generates all my QGroupBox for me and send this object via signal back to the "main thread". Also not successful, since addWidget failed because the object was created in another thread with another parent apparently. This confuses me, than the thread has the parent instance of the "main thread" or am I wrong here?
The language I am talking about is VB.
I'm struggling with this problem for over three weeks, and still a solution is not in sight.
The problem is the following:
I have got an intense calculation running in a sub procedure, while modifying the GUI a lot in the process. After a short period of time, the application freezes and is "not responding". After the calculation is finished, everything suddenly snaps to the point I have modified it. Nothing special about that.
But if I now try to start the sub with a thread, so the application doesn't freeze anymore, I can't access the GUI, because "it isn't created by the thread itself".
How do I get around this??
More concretely: How do I access information about the GUI (especially width and height of a PictureBox) and modify the GUI (especially setting a BackgroundPicture in a PictureBox)?
Any help is appreciated. Thank you!
You need to read up on how to use the Dispatcher (MSDN Threading Model)
If only one thread can modify the UI, how do background threads interact with the user? A background thread can ask the UI thread to perform an operation on its behalf. It does this by registering a work item with the Dispatcher of the UI thread. The Dispatcher class provides two methods for registering work items: Invoke and BeginInvoke. Both methods schedule a delegate for execution. Invoke is a synchronous call – that is, it doesn’t return until the UI thread actually finishes executing the delegate. BeginInvoke is asynchronous and returns immediately.
Small snippit of code from example in msdn article link:
startStopButton.Dispatcher
.BeginInvoke(DispatcherPriority.Normal,
New NextPrimeDelegate(AddressOf CheckNextNumber))
I'm implementing a C++ library that wraps a COM library (IMAPI) to more easily provide the functionality throughout our applications.
It contains wrapper classes for the various interfaces of IMAPI. These are instantiated in the GUI thread of a client application to get information about the drives and their current medium. However, these objects also have functions to e.g. write data to a medium, which is a blocking function call.
Usually I would simply put this blocking function call onto another thread and execute it asynchronous to avoid blocking the GUI. However, since the COM objects were created in the GUI thread, which is initialized with COINIT_APARTMENTTHREADED (STA), this is not possible.
How do I best handle this in my shared library so that its clients do not have to worry about these details? Is the best thing to do to create a thread that belongs to my library that is initialized with COINIT_MULTITHREADED and is responsible for the creation of the COM objects?
are there any objects when running wxWidget's common dialogs on a separate thread? I'm developing a browser plugin and so I need to put lengthy operations outside the main browser thread.
I did a small test and it seems to work but a warning appears:
....\src\msw\dirdlg.cpp(333): 'CoCreateInstance(CLSID_FileOpenDialog)' failed with error 0x800401f0 (coInitialize has not been called.).
Does that mean I have to call wxApp::Initialize(...) or some other functions?
Thanks,
Christian
You just need to call CoInitialize() in each thread where you are using COM. So before creating common dialog objects just call CoInitialize() (one per thread) and in the end of thread call CoUninitialize().
For main thread wxWidgets does this internally. For other threads you'll need to call these functions manually. It is generally not related to GUI but related to COM objects which wxWidgets uses internally.
Yes, there are 'objections'
Important notes for multithreaded applications
When writing a multi-threaded application, it is strongly recommended
that no secondary threads call GUI functions.
http://docs.wxwidgets.org/trunk/overview_thread.html
Can someone explain the threading model in windows metro?
I really get confusion about this.
I know that the WWAHost.exe creates the first MTA (main thread?)
and we also have a UI thread(STA?) and some worker thread(STAorMTA?)
and only the main thread can update to UI thread.
So when user touch a button , and then what happened?
sry, my english is bad.
There's a little about it in the CoreApplication class text:
The system creates this object as a singleton when it runs the app. It
is run as an Application Single-Threaded Apartment (ASTA). Threads
created from the app singleton, such as the view provider (seen in the
sample below), should be attributed as Multi-Threaded Apartment
(MTAThread).