I am searching for a nice way how to close an WinRT app after fatal error.
This should be used only in last chance error handlers TaskScheduler.UnobserveTaskExcption and App.UnhandledException where I obviously failed to handle it correctly on right places. Should never happen, but...
Desired behaviour: Application should then show 'Sorry' message, log the exception and after user clicks Ok button, app should be closed.
I searched for solutions and lot of results points me, that WinRT must not be closed programmatically. Eg. here programatically close win8 app .
When I call Exit method, app is closed, but afterwards exceptions are thrown, like could not do this and that because app is closing...etc.. Makes me kind of nervous.
How would you solve my problem? It has no sence to keep the app running after unhandled exception, and let it crash by setting Handled = false is not good solution as well I thing. Beside this UnobservedExceptions does not trigger crash. I heard that apps with crashes will be removed from store.
Thx for your ideas!
Referring to the application lifecycle provided by Microsoft, the app should terminate without any warning and return the user to the Start screen.
http://msdn.microsoft.com/en-us/library/windows/apps/hh464925.aspx#app_crash
You should not be closing apps which target the Windows Runtime at all. The app lifecycle management system built-in takes into account many factors including usage statistics and current system resources and will almost certainly make better decisions about when to close apps than you will.
Related
Since yesterday afternoon, I have not succeeded in using Folium to generate maps, even the most basic display function can not be completed, the network connection is normal, it is likely that there is a problem with the call of js.
I tried switching the network environment and trying to change computers, but it didn't work.
Failed to load resource: net::ERR_CERT_DATE_INVALID
leaflet.awesome-markers.js:17 Uncaught ReferenceError: L is not defined
at leaflet.awesome-markers.js:17
at leaflet.awesome-markers.js:122
leaflet.css:1 Failed to load resource: net::ERR_CERT_DATE_INVALID
map.html:39 Uncaught ReferenceError: L is not defined
at map.html:39
#This is the code for the most basic function I've tried.
import folium
m = folium.Map(location=[29.488869,106.571034],
zoom_start=16,
control_scale=True,
width='50%')
m.save('map.html')
I hope to generate map pages
I dont think there is any problem in your jupyter notebook/Python IDLE. Check with your browser. If you’ve determined that the ERR_CERT_DATE_INVALID is caused by an issue on your computer, try these steps to resolve it:
First things first, check the Date and Time set on your computer, if
these are wrong it probably explains how you got the
ERR_CERT_DATE_INVALID error.
Sometimes fixing this error is as simple as shutting down your
browser and then restarting it. Other times a system reboot may work.
However, there are a couple of instances where you’ll need to do a
little more work to set things straight.
Check your connection, if you’re connected to public WiFi or some
other public network there’s a chance that your browser is right and
you don’t actually have a secure connection. If that’s the case, stop
browsing and resume when you’re on a more secure setup.
Scan your computer with a trusted antivirus software, you may have
malware of some sort that is causing the issue. Unfortunately we
can’t provide you with info on how to fix every last piece of
malware, but if your antivirus can’t, someone on the internet
probably knows.
Disable any third-party plugins you have running on Chrome. Sometimes
these can cause unwanted problems.
Clear your browser cache on Chrome. Click the menu icon, open History
and select “clear browsing data.”
Delete and then re-install Chrome. Sometimes this helps.
There are a few other crazy fixes like bringing down your firewall or
modifying network settings. However I would not suggest this one since your PC then become susceptible to virus.
I am getting a lot of crashes in failure report on my Dev Center account like:
XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_TargetStateChanged,_timeout_modifier_type_=_None,_server_task_currentState_=_NavigatingTo,_tar
MISSING_DUMP_EM_WATCHDOG_TIMEOUT_DEADA444_XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_TargetStateChanged,_timeout_modifier_type_=_None,_server_task_currentState_=_NavigatingTo,_tar
EM_WATCHDOG_TIMEOUT_DEADA444_XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_TargetStateChanged,_timeout_modifier_type_=_None,_server_task_currentState_=_Showing,_targetSt
MISSING_DUMP_EM_WATCHDOG_TIMEOUT_DEADA444_XXXXXXX!{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}
_Timeout_expired:_event_type_=_SystemKeyPressed,_timeout_modifier_type_=_None,_server_task_currentState_=_Active,_targetState
I'm not able to fix them in my app because in Failure Log there is no stacktrace for them and this kind of crashes are not catched by Application Insights.
The EM_WATCHDOG_TIMEOUT_DEADA444 error is a big mystery to everyone.
a lot of developers have them in the dashboard and they are not reproducable, and and they suddenly came when the Dashboard got a mayor update.
The error occurs in all kind of apps; with c++ runtime components and without, in background thread and in apps that do not use background threads at all....
Finally; there is not way to get the stacktrace and there is no way to catch it yourself because UnhandledException event doesn't get hit.
Meanwhile I'm ignoring the error, up until MSFT gives a proper explanation in the dashboard what this error means.
PS: if someone magically knows to solve/get more info out of this exceptions; I would love to hear about it.
I have a personal WinRT app I'm working on, and when the app is suspended, I would like to have it relaunch itself with different launch parameters.
I know you can kind of already do this with toast notifications, but I would like to know if it's possible to do without any user interactions.
Thanks!
Wow. I never thought of this before. Your only hope would have been to re-launch your application during the suspending event using protocol activation. But what happens is it is not re-launched, it is reactivated while in the suspending state and the activation is denied. You can't delay the re-activation either because all thread schedules are suspended once the app is terminated, too. I tried this in a test app just now and I'm right.
There's also no option with somehow triggering a background task. Though the ApplicationTrigger is coming with Windows 10, the rule still remains that a background task cannot invoke any UI. So, you can't use a background task.
Then I thought about file activation. Then I realized that file activation is identical to protocol activation and the result would be the same, too.
Yes, the idea of using a timed toast or scheduled reminder would sort of work. It would certainly require the user to tap the toast, and if toast were disabled, or the user didn't tap them (they are transient), you are left not running and nothing going to start you.
There is one more thing you can do. Since there isn't a WinRT solution here, remember there's almost always a Win32 solution. There is nothing wrong with a Win32 in-memory app listening for your app to be terminated and starting it again (like by using protocol activation). Your problem is solved unless you are running this on an ARM device - hopefully not.
I talk about protocol activation here:
http://blog.jerrynixon.com/2012/10/walkthrough-using-windows-8-custom.html
Best of luck!
I have a RAP application which we deploy into a Tomcat instance. The application does some additional stuff during it's first startup.
Currently when the first user opens the webpage in a Browser, it takes quite a while until the application is ready because of this one-time initialization work.
This is bad for usability as the first user needs to wait a long time until this startup-work is done.
Is there a way to trigger or simulate a first session after the Tomcat is started so we can warmup the application and the first user receives feedback quickly?
I tried to do some simple URL-requests via URLConnection to simulate a browser, but it seems the protocol to trigger a new session is non-trivial.
I also tried to use HtmlUnit to request the page with JavaScript enabled, this works to some degree, but HtmlUnit is quite heavy for this simple step.
So is there an official API or at least some sort of workaround that allows me to pre-start and initialize the application?
Unless this initialization requires a UI session (i.e. a user), the configure method of your ApplicationConfiguration could be a suitable place. However, at this point, the ApplicationContext has not been completely set up, so it could be too early. Also, if your application is based on the workbench and extension points, you won't have an ApplicationConfiguration of your own.
Would you mind opening a bug report (http://eclipse.org/rap/bugs) and describe your use case? I think we should provide some kind of hook for applications to setup and clean up, e.g. an ApplicationContextListener?
We are using the google-api-client gem in our Ruby on Rails project to access the Google Drive API methods and everything has been working great. However, we are sometimes receiving the following error response from the API when calling the drive.files.update or drive.files.insert methods:
{"code"=>500, "message"=>"Unable to read application configuration information"}
This error is not documented in the list of possible errors from the SDK, so I am not sure how I should go about it. Could you please help?
Thank you!
If this error is transient, the best way is to have a retry strategy when that happens (simply retry the request 2 or 3 times before giving up).
It seems like some concurrency issue on the Drive side where a request to read your application's configuration times out. By experience with Google APIs - and web APIs in general - I can tell you that, even though the team will try to fix/improve these (btw I will repport the bug so they can investigate) errors like that will always happen once in a while even with a very low occurrence as concurrency, timeout and reliability issues on distributed, web-scale systems are extremely hard to resolve. The best to have fail-proof code on your side is to retry a few times on every single 500 and 503 errors from external web APIs.
If you really have time on your hands you could even implement an exponential backoff strategy where the time between each of your retries increases each time as described in our documentation.