Test failure in embeddedobj on some Windows systems

[Ilmari Lauhakangas]

This failure was first observed in September this year and now another 
new dev is facing it:

C:/cygwin/home/Client/lode/dev/core/test/source/xmltesttools.cxx(174) : 
error : Assertion
Test name: testSaveOnThread::TestBody
equality assertion failed
- Expected: 0.1665in
- Actual  : 1.9685in
- In <>, attribute 'visible-area-width' of '//style:graphic-properties' 
incorrect value.

Miklos's comments from September:

"I meant that in case we get RPC_E_WRONG_THREAD at
embeddedobj/source/msole/olecomponent.cxx:1018, then we know how to work
things around. It looks like the failing scenario doesn't get this error
code, but fails in a different way, so the visible area (asserted in the
testcase) is wrong exactly the way it was wrong for everyone before
d5cd62164d32273a25913c93aa04be9f7f3a4073."

"Getting RPC_E_WRONG_THREAD on the first try is expected,
what's unexpected is that the 2nd try doesn't work the way the test
wants it."

I asked Hossein how the new dev could continue debugging the issue and 
he looked into it a bit:

"as I understand from the code, the checks does not happen when the DPI 
is not 96, in which I think most of the today's displays are not.

embeddedobj/qa/cppunit/msole.cxx:98

CPPUNIT_TEST_FIXTURE(Test, testSaveOnThread)
{
     // Given an embedded object which hosts mspaint data:
     if (Application::GetDefaultDevice()->GetDPIX() != 96)
     {
         return;
     }
.
.
.
}

I changed the code to bypass this condition, and then I saw the test 
failing as I expected, as it is tailored to 96 dpi only. On my machine, 
it failed with 0.0555in instead of 0.1665in.

I also wasn't faced with RPC_E_WRONG_THREAD value of `hr`, but it was 
shown as `S_OK`, passing SUCCEEDED().

Previously, when I wanted to debug multiple values in CppunitTests, I 
usually dumped them into a temporary file. I think this idea can be used 
to dump specific values to a set of files, each for a thread. 
Alternatively, one can switch between threads in the Visual Studio 
debugger by using the appropriate window, that can be enabled from the 
debug menu. But, it is not always easy to debug a multi-threaded 
application."

If someone has ideas on how to figure this out, let me know.

Ilmari