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)?

Before 2.29.0 you could set the engine property asEP_INIT_GLOBAL_VARS_AFTER_BUILD to permit manually initializing the global variables with ResetGlobalVars and pass a pre-initialized context.

But, with 2.29.0, I now recommend using the context callbacks. Whenever the engine needs a context to execute a script function, i.e. to initialize a global variable, or call the script class destructor from the garbage collector, it will request a context from the callback registered by the application. The application can then create the context and initialize it with whatever user data it needs. When the engine is done with the context it will return the context to the application. This is also perfect for pooling contexts.

There is also a new method RequestContext on the engine that can be used by the application to obtain a context from the same context callbacks. This is for example used by the add-ons.

No, there shouldn't be a GetModule on the asIScriptContext. A context doesn't belong to a specific module. It is quite possible the context is used to execute functions that do not belong to any module at all, or that the script execution span multiple modules (through imported functions, shared entities, etc).

If you want to know which module a function that is being execute belongs to then you can get the function from from the context with GetFunction, then use GetModule on the function.

Regards,

Andreas

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.

Ah, that's true.

Then if getting the module from the script function doesn't work for you, then there is only one other way, which is to do what you suggested in your UPDATE2 above.

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?

It's a special function for initializing the global variable, and yes you'll be able to get the module from it in the same way.