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?
Related
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 am curious about when the class side initialize messages are sent in Smalltalk (Pharo and Squeak particularly). Is there any specified order? Is it at least safe to assume all other classes packaged with it have already been loaded and compiled, or does the system eagerly initialize (send initialize before even finishing loading and compiling the other classes)?
The class-side initialize is never sent by the system. During development you do it manually (which is why many of these methods have a "self initialize" comment.
When exporting code of a class into a changeset, the exporter puts a send of initialize at the very end, so it gets executed when the class is loaded into another system.
This behavior is mimicked by Monticello. When loading a class for the first time, or when the code of the initialize method was changed, it is executed. That is because conceptually MC builds a changeset on-the-fly containing the difference of what is in the image already and what the package to be loaded contains. If that diff includes a class-side initialize method, it will be executed when loading that package version.
As you asked about loading and compiling, I'm assuming you mean when loading code...
When loading a package or changeset, class-side #initialize methods are called after all code is installed (1). While you can not count on a specific order, you can assume that all classes and methods from that package are loaded.
As Bert pointed out, if you were not loading but implementing class-side #initialize, you'd have to send the message yourself.
One way to know for sure, is to test it yourself. Smalltalk systems make this kind of thing a little more approachable than many other systems. Just define a your own MyTestClass, and then implement your own class side (that's important) initialize message so that you can discover for yourself when it fires, how often it fires, etc.
initialize
Transcript show: 'i have been INITIALIZED!!! Muwahahahah!!!'
Make sure it works by opening a Transcript and running
MyTestClass initialize
from a Workspace. Now you can play with filing it out and back in, Monticello loading, whatever and when it runs.
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.
I have a solution with several Projects in it. There is a Windows App project (called ImportClient), and a Class Library (Import.Library). The Import.Library has functions to perform data imports (I have other applications in the solution that also need to call it). But the interactive application, I want to be able to pass in some form controls, and have it update the GUI. No problem. But, I also want to execute a DoEvents() so that the loop execution doesn't hang other interaction to the app.
So, ImportClient has a reference to Import.Library. But I can't add a reference to ImportClient to the Import.Library, because the compiler complains about circular reference, etc. I don't know how else to define the My.Application object of ImportClient as a parameter to the data function in ImportLibrary.
(I realize this is a dumb question - problem is, for this project I have a tight timeline, and haven't learned how to do the BackgroundWorker process. If you think I could pick it up quickly, I'm open to some hints about how to update the progress bar on the GUI, and how to pause / cancel the background task.)
Application.DoEvents is a static method, you don't need an instance of Application to call it, so why not simply add a reference to System.Windows.Forms to access it?
I'd thoroughly recommend finding the time to learn about threading and asynchronous operations, Application.DoEvents is not the silver bullet for keeping your UI smooth...