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

[Gabriel Ivăncescu]

Hi Jacek,

On 05/02/2020 22:54, Jacek Caban wrote:
> Hi Gabriel,
> 
> On 05.02.2020 18:38, Gabriel Ivăncescu wrote:
>> Sorry for the noise, but another idea just dawned on me.
>>
>> What if we ref count the named_item_t itself, and store it from 
>> vbscode_t instead. Then, we set the item->script_obj to NULL when it 
>> has to be recreated (for persistent code). This shouldn't affect 
>> external users that hold ScriptDisp, since it's only referenced from 
>> vbscode_t.
>>
>> Of course we still unlink the named item from the list when script is 
>> uninitialized, since that's what tests show.
>>
>> This approach should, I think, fix all corner cases, even with 
>> multiple script dispatches referring to same named item.
>>
>> Thoughts?
>>
> 
> Shouldn't we just ignore SCRIPTTEXT_ISPERSISTENT flag when it's executed 
> in context of named item? Your tests seem to indicate that such code 
> does not survive releasing script. Is there any way they could affect a 
> reinitialized script engine?
> 
> 
> Thanks,
> 
> Jacek
> 
> 

So, I've added a lot more tests as suggested (using arrays/loops to make 
it easier to extend), which revealed some interesting quirks that I'll fix.

Now, referring to this part: it seems the code is indeed persistent, so 
we can't clear the flag, even though it's not "accessible". Hence why it 
probably sent the OnEnterScript/OnLeaveScript in the first place. With 
my refcounting named_item_t idea, this should be done without special 
cases for those callbacks and actually re-execute it properly.

I used a hacky test to verify that the script with persistent "code 
context" does get re-executed even with a dangling context -- I used a 
busy loop like the following:

w = DateAdd("s", 5, Now())
Do Until (Now() > w)
Loop

And printed a trace() when script was uninitialized. It then waited 
another 5 seconds when it was restarted, proving that the dangling 
context code was executed again.

Now, I know that sort of hack is unacceptable for a wine test. Do you 
have some idea of how to test for side effects, or should I just let it 
be? (I can't use visibleItem because it dies when script is 
uninitialized, and even if you re-add it Windows will fail when 
restarting the script).

After all, the named_item_t refcounting code will still fix the 
OnEnterScript/OnLeaveScript tests, so technically we do have a minor 
test for it. Will that be enough?

Thanks,
Gabriel