Click random Contacts and eventually a SessionNotAvailableException occurs. Ive seen it occur after clicking three contacts, but usually it takes more clicks.
The error occurs in the RecordContainerNewEmbed method of XanaduPortalContainer. Its being called downstream from a Timer. The first line of the method, we call “Dim theSession As New WebSessionContext( Xan.UserSession )” to get access to the session.
Expected Result:
To not crash with a SessionNotAvailableException after calling “Dim theSession As New WebSessionContext( Xan.UserSession )”
Actual Result:
A crash ending in a SessionNotAvailableException
Workarounds:
Don’t use a Timer to call method that need access to the Session.
WebSessionContexts are tricky. They point to the right place right when you instantiate them and will continue to do so until they don’t. But looking at your code, I have a sneaking suspicion that you’re doing this to yourself.
Session contexts can change if:
A thread context change occurs. That is, the app yields the current thread to allow another thread time to do some processing.
Another WebThreadContext gets created. In your case, this could happen if you had two or more users selecting contacts or even a single user clicking too quickly.
Save yourself a headache and refactor this code to run in a WebThread as they stay connected to the thread from which they were instantiated and don’t need a WebSessionContext to do what you’re trying to do.
The limitation of UI access with threads is specific to Desktop.
However, Web really waits to update the UI until the event is over. So for instance manipulation a label content from inside a loop as is possible in desktop, would simply not work in Web. So use of a timers remains handy.
I wouldn’t do that. People would then ask for it to be acceptable on Desktop.
Best practice would be to avoid UI stuff in a thread of any kind, it will help you keep your structure similar between web and desktop without a whole bunch of refactoring.
[quote=295852:@Tim Parnell]I wouldn’t do that. People would then ask for it to be acceptable on Desktop.
Best practice would be to avoid UI stuff in a thread of any kind, it will help you keep your structure similar between web and desktop without a whole bunch of refactoring.[/quote]
I see what you mean, but It states in the Thread docs very clearly that you CANNOT do any UI stuff and goes as far to show how to do it with a Timer. Right now the assumption in reading the docs that the WebThread is similar to Thread. If Thread and WebThread are different, it should be stated, in my opinion.
WebThreads aren’t magical - they DONT actually directly manipulate the UI
They change the DATA that will eventually be sent to the browser that then draws the UI
This is why they APPEAR to be able to change the UI in a thread
Well, Tim, avoiding UI update in Web from threads seems a bit extreme to me. There are reasons why it is possible in Web that do not exist in Desktop, and it would be a shame not to take advantage of Web specificities.
It would not hurt anyway. File a feature request. My experience is that Paul is very quick implementing good suggestions.
To avoid people to demand UI access in desktop thread, though, it would be profitable to have a phrase to that effect in the WebThread page, to stress the differences between platforms.
