[PATCH 1/8] riched20: Stub for ITextRange interface and implement ITextDocument::Range. (resend try 4)

[Sebastian Lackner]

On 11.09.2014 16:39, Jactry Zeng wrote:
> 2014-09-11 22:15 GMT+08:00 Huw Davies <huw at codeweavers.com>:
>>
>>
>> An obvious question is then: what happens to the range object if you
>> release all references to the txtdoc object?  Does the range object
>> still remain functional?
> 
> No, the program will crash when calling a function of ITextRange after
> released all references of txtDoc.
> 
> 

Are you sure? Doesn't this test below show exactly the opposite? It seems to be safe
to release the ITextDocument, and afterwards call an ITextRange function - it will just
return CO_E_RELEASED since the parent object was already released. Or am I misunderstanding
this code?

> +  release_interfaces(&w, &reOle, &txtDoc, NULL);
> +  hres = ITextRange_CanEdit(txtRge, NULL);
> +  ok(hres == CO_E_RELEASED, "ITextRange after ITextDocument destroyed\n");
> +  ITextRange_Release(txtRge);

At my opinion this behaviour is so fundamental in the ITextRange implementation, that I
doubt any app will still work when you replace all that with proper refcounting. To
reproduce the behaviour above (which obviously passes on the wine testbot) it is necessary
to keep track of all ITextRange objects - and the best method for that is using a list,
no matter how "ugly" and unusual it is for interface implementations.

Please note that MS never designed this interface to be threadsafe, there are even big
warnings for developers on MSDN.

Regards,
Sebastian