[PATCH resend 02/13] msscript.ocx: Add IScriptModuleCollection stub implementation.

Gabriel Ivăncescu gabrielopcode at gmail.com
Mon Jun 1 10:24:40 CDT 2020


On 01/06/2020 17:54, Jacek Caban wrote:
> On 01.06.2020 14:17, Gabriel Ivăncescu wrote:
>> On 29/05/2020 19:53, Jacek Caban wrote:
>>> On 26.05.2020 14:41, Gabriel Ivăncescu wrote:
>>>> diff --git a/dlls/msscript.ocx/msscript.c 
>>>> b/dlls/msscript.ocx/msscript.c
>>>> index 6d098cd..7a18a84 100644
>>>> --- a/dlls/msscript.ocx/msscript.c
>>>> +++ b/dlls/msscript.ocx/msscript.c
>>>> @@ -106,6 +106,9 @@ struct ScriptControl {
>>>>       IAdviseSink *view_sink;
>>>>       DWORD view_sink_flags;
>>>> +    /* modules */
>>>> +    IScriptModuleCollection IScriptModuleCollection_iface;
>>>> +
>>>>       ScriptHost *host;
>>>>   };
>>>
>>>
>>> It looks like it could be a separated object (which could potentially 
>>> help with your references problem).
>>>
>>>
>>> Jacek
>>>
>>
>> It makes no difference if it's a separate object in this case. The 
>> module collection is tied to the control: updating the control (via 
>> put_Language for example) will also update an existing module 
>> collection, not just newly obtained ones, as tests show.
> 
> 
> It may make a difference, depending on implementation details. The 
> potentially problematic part of your solution is that collection shares 
> reference counter with control instead of having a separated ref count. 
> It means that collection keeps the whole control alive (which may or may 
> not be desired, it should be testable).
> 

Yes but it already is the case that the module collection keeps the 
control alive, and is only really closed when the collection is closed.

To answer the other message since it's related: It's the same with 
non-detached modules. I did have tests for that, although not for the 
collection (I'll add that now).



More information about the wine-devel mailing list