On 2/1/2021 9:36 AM, Nikolay Sivov wrote:
> This seems to be correct in assumption that document output is treated
> separately. Quick testing shows that it's using some internal interface
> that the document object implements. It might be used to lock/unlock
> document while writer is populating it.

Ok, sorry to change the topic / scope but do you think it would be
better to write a custom class that implements IXMLDOMDocument (and
IDispatch) and pass that to the mxwriter instead of instantiating a
DOMDocument?  That is, do it like test_saxreader.

I think that's better because then we could gain some visibility into
what interfaces the Microsoft msxml queries for, and how it locks and
unlocks the document.

I'll do it that way in the next version, and use call_entry /
call_sequence structs like the saxreader tests.

So to improve the tests I think it
> would be interesting to see if written nodes appear right away on SAX
> calls, and if modifying methods of IXMLDOMDocument are indeed disabled
> during this process. Another case that's not tested is writing to non-empty
> document. Also you can remove the part that uses attributes, I don't think
> it's valuable.
>

Also, by checking that the correct call sequences are invoked by
mxwriter, the nodes would appear right away by virtue of a correct wine
DOMDocument implementation.  (If they don't, that's a domdoc.c patch).

Should I commit a short test that's correct, or try to get the whole
thing right in one go?