What's going on with this exception?

I get reports of an exception that I’m struggling to understand what it’s trying to tell me: https://beaconapp.cc/reportaproblem.php?exception=dc0a43238ef331913c0b6264bc5d2213244bfc42&build=39&action=view

And the entire code for the method in question:

Private Sub TriggerFinished() RaiseEvent Finished End Sub

If it was inside the event handler, shouldn’t the stack trace point me inside the event?

I’m using Xojo.Core.Timer.CallLater(1, AddressOf TriggerFinished) to trigger an event from inside a thread.

My gut says the issue is inside the event implementation, and the stack trace is just Xojo being dense.

How are you handling the Finished event? From that report it looks like there may be an issue with the event. And, what exception is being raised if you add a trap in the UnhandledExecetion handler of App?

[quote=413923:@Thom McGrath]I get reports of an exception that I’m struggling to understand what it’s trying to tell me: https://beaconapp.cc/reportaproblem.php?exception=dc0a43238ef331913c0b6264bc5d2213244bfc42&build=39&action=view

And the entire code for the method in question:

Private Sub TriggerFinished() RaiseEvent Finished End Sub

If it was inside the event handler, shouldn’t the stack trace point me inside the event?

I’m using Xojo.Core.Timer.CallLater(1, AddressOf TriggerFinished) to trigger an event from inside a thread.

My gut says the issue is inside the event implementation, and the stack trace is just Xojo being dense.[/quote]
Looks like the control you ran CallLater from became Nil.

CallLater was called from a thread. It’s very possible the thread ended before the callback, but shouldn’t AddressOf (as opposed to WeakAddressOf) hold a reference until CallLater is finished?

It holds a reference to the Control, but if that control is on a Window then the event code is held by the Window itself instead of the control. If the Window gets “closed”, then while the Window and the Control still “exist” but everything else is gone.

Could you share how you came to that based on the limited info in Thom’s crash data?

Hmm. It gives me areas to poke at, but I don’t think that’s what is going on here. The trace suggests this is an instance of the thread that exists outside of any particular window. If it were part of a window, I would expect to see the wrapper class code on the thread.

That’s what I saw, as well (I’m doing a lot of thread experiments right now).

I’ve got an idea. The method attached to the Finished event with AddHandler may have become nil. So the stack gets inside TriggerFinished, but causes an exception there because the Finished event is literally nil at that point. It’s plausible, though I’m using AddressOf with AddHandler here too, specifically for this reason. And the object owning the method shouldn’t be going out of scope either. So I’m not certain.

And of course, I can’t reproduce it.