Hi Gabriel,
On 31.01.2020 14:29, Gabriel Ivăncescu wrote:
diff --git a/dlls/vbscript/interp.c b/dlls/vbscript/interp.c index b328674..8ded5cd 100644 --- a/dlls/vbscript/interp.c +++ b/dlls/vbscript/interp.c @@ -112,7 +112,7 @@ static BOOL lookup_global_vars(ScriptDisp *script, const WCHAR *name, ref_t *ref
static HRESULT lookup_identifier(exec_ctx_t *ctx, BSTR name, vbdisp_invoke_type_t invoke_type, ref_t *ref) {
- ScriptDisp *script_obj = ctx->script->script_obj;
- ScriptDisp *script_obj = ctx->code->script_obj;
Does it really use this script instead of global script global context? My guess would be that both should be looked up in this case. A test to clarify that would be nice.
- if (!obj)
- {
/* A persistent script with a dangling context calls these,for some reason, even though it won't be executed. */IActiveScriptSite_OnEnterScript(ctx->site);IActiveScriptSite_OnLeaveScript(ctx->site);return S_OK;- }
Is it just to satisfy a test? I'd suggest to leave it in todo_wine for OnEnterScript/OnLeaveScript. Otherwise, it would deserve a closer look to see if we can solve it more generally and avoid such special case.
return hres;
- /* Fix the dangling pointers to the old script dispatch */
- LIST_FOR_EACH_ENTRY(code, &This->ctx->code_list, vbscode_t, entry)
if(code->script_obj)code->script_obj = This->ctx->script_obj;
That's not pretty. Depending on result of test I mentioned earlier, we may want to simply not store global script context in vbscode_t (and only store named item-based script object).
Thanks,
Jacek