I have an UWP that starts a background task that got fired every 15 Minutes.
On the MainPage of the UI the Complete Event for that task is set and called.
I played a bit to see how events where handled if the application goes to the background or even got suspended.
I came to the expression that all events got queued and are processed when the application leaves the suspended state.
This is not what I had in mind. I need an option to only process an event once and ignore all other events raised during the suspend of the UI.
The work I have to process during the OnComplete event is quite time consuming so it is very ineffective to call that multiple times and the result would not change either.
One option would be to set the last run time of the event and ignore calls inside a given timespan, but is there no default way to handle these inside the event system?
I took the MS example for background tasks um UWP. In this example application you can register a task and when the task got called it counts from 0 to 100 in steps of then and displays the percentage on the main windows. It is quite an easy example an can be downloaded from github (https://github.com/Microsoft/Windows-universal-samples).
The example uses the OnProcess event but it makes no difference.
What I done
1) Start the Application
2) Register Background Task
3) Run the Task though Visual Studio Process Location Toolbar
4) While the task is running set the Application to Suspended via the Process Location Toolbar
5) Wait a bit and that Resume the Application
6) With a breakpoint in the OnProcess Method of the example I could see now that this method is know called several times (Once for each Raise Event Call in the Background Task.
What I want is that if the Application Resumes the EventMethod will only processed once for all RaiseEvents that are waiting to be processed
Related
I want to have logic that triggers right before my UWP process is exited or gracefully killed. Is there anything that may accomplish what I wish to do? Or is this impossible in the UWP environment?
I know there exists a trigger for "onSuspending", but I do not want to trigger on that, I want to trigger when the process is exited or gracefully killed. I am aware of the "confirmAppClose" capability and "CloseRequested", but based on research, that seems to only be applicable for the "X" close button. I have a background task with no UI so there is not "X" button visible to trigger it. I am aware of "CoreApplication.Exiting" event but it seems like that won't work either based on what I've read.
I have to say that currently, there is no other ways for UWP to handle the app close request than the CloseRequested event. So it is impossible to get notified when the app is forcibly closed. As you've already known, the CloseRequested event only works when user click the "X" Button.
We have a very critical process that needs to be monitored. If it crashes for some reason the admin needs immediate notification. We have tried different scenario's but none work for their own reasons:
VBScript SELECT * FROM Win32_Process WHERE Name LIKE '%IPRUN%'
This doesn't work because the process doesn't exit on crash it goes a WER window. So when you hit close in WER window only then the process exits (i.e. disappears from the task manager) so until the process doesn't disappear this code is useless.
EventViewer: The application produces Start and Close events but does not for crashed events (for reasons understood) as application thread has exited abnormally, and might be its handled in an unusal way
Is there any other way of monitoring this?
When I debug my program, which consists of looping over thousands of entries in vectors multiple times, it simply freezes the program but does not provide any error messages whatsoever. Does Visual Studio have some sort of auto-time out that I am experiencing?
Check may be your program is going into infinite loop Or doing some heavy task that makes your UI unresponsive(if you have windows form). Since you are debugging this program then why dont you set breakpoint in code and check where your program is causing issue.
And yes there is no time out for Visual Studio,But for program window.This is known as Hang Status.
When an application (or more accurately, a thread) creates a window on the desktop, it enters into an implicit contract with the Desktop Window Manager (DWM) to process window messages in a timely fashion. The DWM posts messages (keyboard/mouse input and messages from other windows, as well as itself) into the thread-specific message queue. The thread retrieves and dispatches those messages via its message queue. If the thread does not service the queue by calling GetMessage(), messages are not processed, and the window hangs: it can neither redraw nor can it accept input from the user. The operating system detects this state by attaching a timer to pending messages in the message queue. If a message has not been retrieved within 5 seconds, the DWM declares the window to be hung. You can query this particular window state via the IsHungAppWindow() API.
Detection is only the first step. At this point, the user still cannot even terminate the application - clicking the X (Close) button would result in a WM_CLOSE message, which would be stuck in the message queue just like any other message. The Desktop Window Manager assists by seamlessly hiding and then replacing the hung window with a 'ghost' copy displaying a bitmap of the original window's previous client area (and adding "Not Responding" to the title bar). As long as the original window's thread does not retrieve messages, the DWM manages both windows simultaneously, but allows the user to interact only with the ghost copy. Using this ghost window, the user can only move, minimize, and - most importantly - close the unresponsive application, but not change its internal state.
A nice article is written in this following link.
How program window works
I have a windows 8 store app and a Background task is also associated with it. Everything working fine. And my question is, is there any possibility to close my app from BackgroundTask Run method ?
thanks for suggestions.
No, You can't do that instantly!
But you could save a file in your app's local storage -or settings- and let the foreground app check for this file every 10 minutes -whatever- and close the app in a specific condition ..
Your background task can be hosted in its own dedicated process or it can be hosted in the same process as your UI. In a separate process your foreground app can open and close without impacting your background process. In the shared process when your foreground app closes, so does the background task. This is not true in reverse, the shared process model does not allow a closing background task to close the foreground app. Too bad, huh?
Technically, it is not recommend that a foreground application close itself. But, hey, that API is there for something, right? When the background task shares the process with the foreground app then it can communicate directly between them with shared memory. This would introduce method 1 for communicating from your background task to your foreground app - probably by using a static event.
If that's not what you want, and you need separate processes, then your options are a bit more tricky.
Here's the best option:
You set a special setting (let's say it's ApplicationData.LocalSettings.Values["DataFromBackground"] = "PleaseExit") and then call the ApplicationData.SignalDataChanged method from the background task which will raise the ApplicationData.DataChanged event handled by the foreground app. How much lag will there be? I am not sure, but there will be some, so be ready for that.
Be sure an remember to set DataFromBackground back to some empty value, including calling Value.Remove() so you don't mistakenly process it again. That being said, you should also poll for that value when your application launches (or resumes) in case your background task wrote it while the event could not be heard.
This is probably the easiest way to implement communication.
Make sense? I speak more on this in my Ignite session on the topic.
Best of luck!
I am doing a REALBasic project. I want to make code run after the window has loaded automatically.
If I put the code in the Open event handler, the code runs when the window opens, but the window doesn't appear until the code has finished executing.
So I would like to have the Window open and be on the screen, and then the code run automatically without having to click anything.
Is this possible?
Thanks.
Place your code in a Timer with its Mode set to ModeSingle and a short Period (say 10 milliseconds). The Timer will fire once the GUI finishes loading.
Or you can put your code in a thread and start the thread in the Window.Open event. That way if the code takes a while your entire application doesn't 'freeze' on you.
More info on threads in Real Studio at http://docs.realsoftware.com/index.php/Thread
One word of caution though with Threads. Directly updating GUI controls can be a bad thing - especially with Cocoa built applications.