This is being trapped at App.UnhandledException event.
The following error has occurred at APP: 0_ has occurred.
Error type: NilObjectException
Stack information:
WebTimer.!InvokeCallLaterWithValue%%v
_CallLaterTimer.Event_Action%%o<_CallLaterTimer>
ConsoleApplication.DoEvents%%o<ConsoleApplication>i8
WebApplication.Event_Run%i8%o<WebApplication>A1s
ConsoleApplication._CallFunctionWithExceptionHandling%%o<ConsoleApplication>p
REALbasic._RuntimeRun
_Main
XojoMain
I do make a call to WebTimer.CallLater and Iām am passing the method address as a WeakRef.
When you use WeakAddressOf, the object containing the method is not retained for you. So if you schedule a call with CallLater, and the referenced object goes out of scope before the trigger time, youāll get this exception.
AddressOf will retain the object, but comes with its own side effects of course, such as keeping an object alive that you might expect to have been destroyed.
A good way to get into trouble is using AddressOf on a window method, then closing the window. It will start its closing sequence, but wonāt actually destroy until the timer is fired, leaving your controls pointing to nil when it does.
No, Iām not saying the method being called is triggering the exception. The object hosting the method is nil, so the framework has to fire a nil object exception. Your method isnāt even getting called. Itās the equivalent of calling Nil.DoAThing().
Yeah Iāve come to the same conclusion. One thing I really donāt like is how CancelCallLater works. What exactly is it cancelling? If I do the following, what happens? What should happen?
Please note: Iām using WebTimer.CallLater, not Timer.CallLater
Tim - this method is called > 10,000 times per day and prior to it being invoked by WebTimer.CallLater, itās never thrown an error prior. Based on this I think Thomās on the right track?
Thom - So Iām guessing this must happen because the session has gone away?
ā
Why Iām doing this:
The method in question loads a WebDataSource object.
Users would semi-regularly (lets say 50 times a day) run into issues where the WebListBox which uses the WebDataSource never loads. (it just sits there in itās loading state showing the value of the āProcessingMessageā property)
Introducing a short delay (150ms) from the client side (which is what WebTimer.CallLater does, correct?) āfixesā the WebListbox-is-stuck-in-processing issue
As mentioned above, this methods is called thousands of times per day and so farā¦ Iāve only seen the unhandled exception I pasted in my original post, twice in three days.
I would like to trap the error BEFORE App.UnhandledException is raise if possible, but it sounds like that might be hard and/or impossible.
Oops - And I meant to say, if thereās a better way to fix the underlying issue (WebListBox using a datasource occasionally getting "stuck in processing), Iād love to hear about it!
Ah. I misinterpreted what Tim was saying as that the NOE was in the method being invoked.
And it sounds like you donāt have an alternative solution for my āroot issueā? (WebListbox with a WebDataSource being āstuck foreverā in itās processing state)
Since this issue is extremely rare, Iāll probably manage how itās logged in App.UnhandledException and wait to see if @Ricardo_Cruz or anyone else has some insights into the āroot issueā.
The first thing Xojo needs to do is give us a way to determine if a weak delegate is still valid. Thereās currently no way to do that. MBS has a few methods, but theyāre not absolutely reliable because Xojo can change things about memory usage.
Once they have that, I agree they should use it to just ignore CallLater invocations that are no longer valid.
From my perspective, I am using CallLater with WeakAddressOf because I understand the object may be destroyed between now and when the Timer fires. Thatās the point of using a WeakRef. I want the Timer to catch the exception that is raised when trying to invoke the method, just as I would catch it if I were doing it.
I see the spirit of the CallLater method with WeakAddressOf as being āplease invoke this after X delay if it still exists.ā I would never want that to raise an exception Iād have to catch in App.UnhandledException (and could only identify via the stack). And if I wanted to keep track of the state of these calls and cancel all the delayed calls before destroying the object then I wouldnāt need a WeakRef in the first place.
(from Travis Hicks on issue # 65787)
pretty well sums up my thinking/expectations when I decided to pass a WeakRef to WebTimer.CallLater
But I now understand, this isnāt how things work today. ĀÆ\(ć)/ĀÆ
I hadnāt had the opportunity to respond to the update about your āroot issueā
No! WebTimer only retains and restores a Session context. You have to set a WebTimerās Location property to Browser for it to be browser-side. Iām not seeing a way to do that with WebTimer.CallLater.
Though, should you switch to a design-time WebTimer you could do this with the inspector AND take advantage of the framework handling ādisconnectingā everything to avoid these NOEs.
Do you have a ticket regarding this WebDataSource never loading issue? I use WebDataSources to back several WebListboxes in TPLM and have never seen this issue. I wonder if itās related to the DBMS though, youāre using MySQL or MariaDB right?
It does but CallLater is shared. Youāre not calling it on any specific instance, so there is no location set. WebTimer.CallLater doesnāt actually use a WebTimer at all. Iām pretty confident itās an alias for Timer.CallLater.
Editā¦ why does WebTimer.CallLater even exist? Itās not like Timer.CallLater isnāt available to web projects.
