My application is based on serial communication.
It has main dialog window, from this we can select three options pump,crind and kiosk.
When i choose any one say pump, then small dialog is called (CommonResponse)with progress bar and getting time of pump from command files.This small window is on separate thread created as worker thred.
Now i want this small window with progress bar is on main thread but in background serial communication should be going on......How to do and steps for doing this?
One option for doing this is instead of progress bar, serial communication is on separate thread.But it is very time consuming process now because all things are ready only this part we want to change....
Thank you in advnce!!!
Just pass a handle to your main thread window to the background thread.
Use PostMessaage to send a private message that informs the main thread about the progress. The main thread can decode it and set the embedded progress bar to the value you want and need.
Related
I have a C++ application on Mac OS X. The app runs an event processing with the glfw library on the main thread and reads input and execute commands on a background C++ std::thread.
I am observing a frustrating phenomenon that I cannot explain so far.
If I make a call to a long running function on the background thread, initially that thread is using 100% of a core. But, after it has used a few seconds of CPU (10 seems to be the magic threshold), it gets throttled down to 25%.
If I start a computation run on a thread in the background before starting the glfw event processing loop (the event processing is essentially stuck waiting for events, as I don't even open a window), then it can use 100% for as long as it wants.
My biggest problem is that I have no idea what could be causing this nor how to figure it out. I've tested retrieving the pthread sched_param and changing the sched_priority from what seems to be default 31 to various values between 20 and 60 and it does not help.
I have identified one more condition for the phenomenon to happen:
The background thread has to have read from the terminal. It happens when I run the following background thread and enter a line for the computation to take place:
std::thread cmd([argc, argv, &scriptingRunner] {
for (std::string line; std::getline(std::cin, line); ) {
longComputation();
}
Perhaps App Nap is throttling your application to save energy. To check, open the Activity Monitor program and right-click on the header of the processes table to bring up the context menu, and click on "App Nap" in the context menu to enable the App Nap column; then look at your process in the table and see if its value in the App Nap column switches to "Yes" when the fault occurs.
If you want to disable app nap for your app, see the code listed in the question here.
I have a library that needs to call the main windows thread in UWP when it receives a message from a communication channel (let say, a message indicating a check box should be checked). The library saves a copy of the SynchronizationContext when it starts up, so it can Post back to it when the data comes in, but the trouble is, I'm not guaranteed that the caller of this library is on the main thread when it's initialized.
Is there some simple, guaranteed way to obtain the Main Window Thread (that is, the Windows' SynchronizationContext) so I don't need to rely on the caller to make sure the contexts aren't switch?
Trying to push something onto "the main window thread" will fail eventually when you pick the wrong window / thread. A better design is to have the library expose an event and then any consumer (including the main window) can listen to that event and do the appropriate thread marshalling (if any) for itself.
If you absolutely must get "the main window" then CoreApplication.MainView.CoreWindow will do it.
The application I drag and drop items onto the main form which contains a tablelayoutpanel which displays custom user controls about the items dragged in.
The usercontols subscribe to data and have events that run in the backround and are interdependent on the surrounding controls in the panel.
I need to create 2 threads, one the main thread that will display the forms, and then another worker thread that will process all the data from the events from the controls.
The events are part of the controls themselves and need to be subscribed separately for each one.
The problem I am having is how can I create the control and put them in the form in one thread, but have the events handled in the other?
What I am trying now is first to create the GUI with the needed controls inserted. Then I start the worker thread which creates a reference array of the table controls and then have this thread subscribe to the events from the controls separately. This should at no point interact with the main form. And the main form would have a timer and periodically update data to the screen.
Examples I have found and have used are threads launching another form or application or simple worker threads which exit after finishing, which I need a stable background thread that works off the existing gui contents, but is not limited by the display?
Thank you.
Would someone please answer my question?
Does the C++ program (written using visual studio) create a separate thread for handling mouse events? Would you please describe it concisely?
Thanks
In Windows, each thread that creates a window, and some that don't create any, receive a message queue (and remember that any application has at least one -the main- thread).
This queue is a OS structure that contains any message directed to any windows created by this thread; that includes window handling messages, timers, mouse events directed to any of these windows, keyboard events when any of these windows has the keyboard focus, system events, etc...
It is the responsibility of any thread that has a message queue to pump these messages periodically. This is usually done in what is called the main loop of the thread.
This main loop, in its simplest form is:
MSG msg;
while (GetMessage(&msg, 0, 0, 0))
DispatchMessage(&msg);
But it is usually much more convoluted, depending on the complexities of the program.
These two functions:
GetMessage(&msg) removes one message from the queue and puts it in msg. The 0s mean: do not filter.
DispatchMessage(&msg) handles the message, probably calling the callback function relevant to this particular message. With Window messages (mouse and keyboard included) this usually means to locate the window class and then call the window function from within.
So, answering your question: mouse messages are handled in the same thread that created the window that receives them. And it processes them one by one.
No, the mouse events are submitted to the main UI thread/Message loop, along with keyboard and any other peripherals (and system events, and messages from other processes, etc.)
if you want to create a keyboard and mouse hook in Visual C++ 2005 Check this..
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3d9bb875-8e79-4c1e-b2ef-b24503e6abbd/how-to-create-a-keyboard-and-mouse-hook-in-visual-c-2005?forum=windowssdk
There are 2 forms.
Form2 isn't auto-created.
Form2:=TForm2.Create(Application);
Form2.Show;
If to do Sleep(10000); inside any forms then another one will be frozen. How to prevent this behavior?
My problem: a big text file (3 Mb) is continuously assigned (Lines.Assign) into a text editor, so a form is frozen.
Can I use another unfrozen form (not modal) to show a progress bar (a style is pbstMarquee)?
All GUI code should be run from the main thread, and it looks like you are following that rule.
If you call Sleep then the calling thread will not execute code until the timeout elapses. If you call Sleep from the main thread, then the message queue will not be pumped until the timeout elapses. Hence the entire app appears frozen.
Why does calling Sleep from one form affect another form? Because all GUI components are served from the single message queue of the main thread. Once you stop pumping that queue, all GUI components stop receiving queued messages like WM_PAINT, WM_KEYDOWN etc.
As I understand it your problem is that your application appears hung when you are loading a 3MB text file into an edit control. That size of file doesn't sound very large to me and one obvious solution would be to find an edit control that performs the load better. For example I'm pretty sure that Notepad, Notepad++ etc. do not take steps like showing progress when loading such files. I rather suspect that those apps don't pump the queue when loading files but you just don't notice because of the short time taken.
What you don't want to happen is for you to pump your queue to keep your GUI responsive and in turn allow the user to start loading another file whilst the first one is still loading. You need to disable your UI whilst processing a load operation. A modal progress dialog is one way to do that.
If you can't switch to a better performing control, you could show a modal progress dialog and use a background thread like this. The background thread would have load the file in small chunks, say into a string list. After each chunk of the file was ready it would then call Synchronize and get the main thread to add the contents of the string list to the edit control, and then clear the string list. The thread would then continue and load the next chunk. Adding to the edit control in small chunks would allow you to keep the message queue serviced.
You could show progress in a status bar rather than a modal dialog which would be less intrusive. But just remember to disable any UI that would cause re-entrant execution.
Better load your file in a separate thread. Or you will have to create your second form in a plain WinAPI, because VCL doesn't support multithreading.