On 06.02.2020 16:55, Gabriel Ivăncescu wrote:
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?
You could probably just use "testCall" there as a test script. Before reinitializing script, you can make sure that it's exposed by a new named item in in global scope and use SET_EXPECT(testCall)/CHECK_CALLED(testCall).
And for ref-counting named items, it could also use a bit more testing. My guess would be that we should store named item string (not reference) inside vbscode_t and lookup named items when the code is actually executed. It means that if host adds a new named item with the same name before reinitializing engine, the new named item will be used. Experimenting could show if that guess is right.
Thanks,
Jacek