In Build 1.2.38.0 Application.Context and the need to switch when updating from another thread was removed. This doesn’t seem to have effected any of my application once I had removed all the references except for one location where I need to know if the browser supports notifications. This used to be fine inside my using(UserContext) block but now fails because Application.Browser is null.
I assume that as I now don’t have a context I need to store the browser capabilities instead but thought I would check that this is intended.
Thanks
Nic
Switching to the new Application.Update pattern documented by Frank solved my problem.
I now call like this:
Application.Update(this, () => { if (Application.Browser.Features["notifications"] == true) { //Do something here }} Just thought I would share in case anyone else is stuck in the same way. HTH Nic
Hi Nic,
Thanks. Two additional pointers:
The reason it’s done like this now, with the forced context, is to prevent confusion with calls without a context and calls with the context causing the call to fail silently when the context has not been restored, and the callback actions ensures that the thread context is cleaned up when exiting preventing any possible cross context issue (it’s why originally we had the using pattern).
Best,
Luca
Not intended. If you call .Update() on any control, or the form itself, the context will be restored and Application.Browser will be available.
The context is now restored automatically as soon as any visual property of any control is changed, since all controls carry a reference to the session.
The unforeseen issue is if there is a need to access the static context (Application) before an automatic restore… Don’t have a good solution yet, may have to re-add something like Application.Context and Application.Restore(context). Don’t know yet.