[PATCH v2] ole32/tests: Improve tests for OLE's default object handler.

[Huw Davies]

On Wed, May 09, 2018 at 02:28:42PM -0500, Sergio Gómez Del Real wrote:
> On 08/05/18 03:07, Huw Davies wrote:
> >I don't think you want a global dfhandle_unk, especially as you
> >shutdown the server at the end of test_running_object().
> >
> >Please check that the other global variables are necessary.
>
> I fail to see why using a global IUnknown for the client would be a problem;
> the dfhandler_unk is used to refer to the object created by
> OleCreateDefaultHandler (the default handler object). When the client make
> calls through that interface, should the default handler need to defer to
> the local object, it would do the appropriate interface marshaling and the
> call would end in the interfaces' functions in the server instance, which
> would receive marshaled copies from the COM library. But in any case, the
> server doesn't (and shouldn't) know about this dfhandler_unk, which is used
> only by the client to interface with the default object handler.
> 
> The global variables are there merely as a convenience; the client has
> access to the pointer to the default handler object (dfhandler_unk), while
> the server uses the test_class pointer to the local object, which it creates
> in create_testclass(), but I don't see the conflict, as the server is
> receiving in its interface functions internal marshaled versions from OLE,
> not the client's dfhandler_unk. I think the separation is correct, as both
> control different objects (default handler object vs local server object).
> Maybe I am missing something.
> 
> As for the other globals, they are there also for mere convenience; not
> necessary to have them globals, for sure.

While you may think globals are convenient they can become very
inconvenient when it comes to understanding the code.  If the globals
are beening accessed by a lot of functions, then sure they're fine (in
tests).  In the case of dfhandler_unk, why not create it locally in
test_running_object()?  You can recreate it in other test functions as
needed - one of the points about the default handler is that it
shouldn't be too expensive to create.  If you really want to keep it
alive across different test functions (remembering that this will make
its state much harder to follow) then pass it as a parameter to those
functions.

Huw.