If I'm executing a script function through my own context (that I've had a chance to set user data on) and the script calls an app-registered function, I can use asGetActiveContext() to get at my context, get the user-data off of that, and through that get to my application instance which 'wraps a script (module)'.

If a script's global scope calls an app-registered function, it looks like asGetActiveContext() is returning the context which is implicitly created by the module during the Build() / CallInit() codepath. So there's no user data on this context. I could set a user data on the script module, but there's no asGetActiveModule() and if I get at the script engine via asGetActiveContext() and want to do the module lookup by name, I have no way to know which name to use (if I've got multiple modules in existence).

What is the suggested way to get at some kind of user data for the correct script module through an application-registered C++ function when it's called from a script's global scope?

Thank you.

UPDATE: Could/should there be a GetModule() on asIScriptContext?

UPDATE2: Should I SetUserData() on the script-engine before module->Build() and clear it after.. so that during the 'initialize global variables' stage I can get at the module off the script engine (which I can get off the context)?

Thanks for the quick response!

I'm actually already using context pooling and the callbacks, but I don't think this helps me. When the engine requests a context from me, I have no way to know what script module is running.. so there's nothing (at that time) that I could put into the user data of the script context which, when I access the script context via the app-registered C++ function, would tell me what script module is running.

What script function would I be dealing with when the script calls in the global scope (initializing global variables)? Would it be a dummy function, but I'd still be able to get the module from it?