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