[PATCH 4/5] vbscript: Implement separate script dispatch objects for each named item.

[Jacek Caban]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200203/87a9f205/attachment.htm>