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?