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).
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))
In building my current (first) Windows Phone app it requires me to create a Windows Runtime Component to achieve the functionality I require. In order for this setup to work and not duplicate a lot of code from my PCLs into the task class itself, I wanted to use the MMVMCross IOC that I am already using throughout the application.
Unfortunately, the Background Task (IBackgroundTask) is executed in an entirely different process. Trying to utilize the IOC via Mvx.Resolve throws a NullReferenceException. I cannot figure out how to initialize the IOC as the standard "setup.cs" method does not work in the Runtime Component.
I do not need the entire MVVMCross stack for this -- just the IOC.
Thank you.
I finally figured it out. I have to re-register on the background task, but to initialize you would call the basic initialize method on the simple IOC container:
Cirrious.CrossCore.IoC.MvxSimpleIoCContainer.Initialize();
Plugins were a problem, as the standard plugin mechanism is not available, but you can manually register the interfaces such as this:
Mvx.LazyConstructAndRegisterSingleton<IMvxFileStore>(() => new MvxWindowsCommonBlockingFileStore());
Of course, you can still register your other types and interfaces as you normally would.
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
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.