Lifetime of objects provided in async callbacks in win32 #5139
-
I'm adapting the win32 loader to a kotlin native binding and I'm wondering if I missed some documentation somewhere or if I'm just not understanding something fundamental about com. I'm trying to convert the nested callbacks to a coroutine style and I didn't have much trouble getting a continuation into the invoke handler of methods like CreateCoreWebView2Environment(). After the handler returns S_OK, it appears that the object is invalid or destroyed. I thought it might just have been a garbage collection thing so I call env.AddRef() within the callback, but it doesn't matter, the object appears to stop existing once the callback concludes. Is that just how com works or is webview loader just cleaning up when the callback ends and it's just not documented anywhere? If so, does it do that after every callback? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
I apologize, I took another look at my code and I was calling AddRef on the handler object vtable and not the parameter passed to the handler. That was the problem, when I incremented the AddRef on the object passed to the handler, it continued living and functioning outside the callback. Sorry for the trouble. |
Beta Was this translation helpful? Give feedback.
I apologize, I took another look at my code and I was calling AddRef on the handler object vtable and not the parameter passed to the handler. That was the problem, when I incremented the AddRef on the object passed to the handler, it continued living and functioning outside the callback. Sorry for the trouble.