<div dir="ltr"><div><div>Keeping it simple by using the easiest way would be better I think. Besides the callback functions all behave the same regardless of the object it was called on, according to the tests.<br><br></div>Cheers,<br></div>Aaryaman<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 7:34 PM, Henri Verbeet <span dir="ltr"><<a href="mailto:hverbeet@gmail.com" target="_blank">hverbeet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 20 April 2016 at 16:00, Aaryaman Vasishta <<a href="mailto:jem456.vasishta@gmail.com">jem456.vasishta@gmail.com</a>> wrote:<br>
> Sorry for the late reply, I was sick for the last couple of days.<br>
><br>
> On Tue, Apr 19, 2016 at 6:05 PM, Henri Verbeet <<a href="mailto:hverbeet@gmail.com">hverbeet@gmail.com</a>> wrote:<br>
>><br>
>> On 18 April 2016 at 19:00, Aaryaman Vasishta <<a href="mailto:jem456.vasishta@gmail.com">jem456.vasishta@gmail.com</a>><br>
>> wrote:<br>
>> > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c<br>
>> > index a8f9c40..2b0174d 100644<br>
>> > --- a/dlls/d3drm/tests/d3drm.c<br>
>> > +++ b/dlls/d3drm/tests/d3drm.c<br>
>> > @@ -1269,7 +1269,8 @@ static void test_destroy_callback(unsigned int<br>
>> > test_idx, REFCLSID clsid, REFIID<br>
>> >      context.test_idx = test_idx;<br>
>> >      context.obj = obj;<br>
>> ><br>
>> > -    hr = IDirect3DRMObject_AddDestroyCallback(obj, NULL, &context);<br>
>> > +    if ((hr = IDirect3DRMObject_AddDestroyCallback(obj, NULL,<br>
>> > &context)) != D3DRMERR_BADVALUE)<br>
>> > +        return;<br>
>> I don't think we want that. Doing this means we won't notice when the<br>
>> function starts returning the wrong value, and the following tests get<br>
>> effectively disabled too in that case.<br>
>><br>
> I do agree, but what should we do when a new object is implemented? If it's<br>
> okay to extend CreateObject to include the new interface as well as<br>
> implement Add/Delete destroy callbacks in the same patch, then there's no<br>
> problem going with this. I had intended to keep the return statement in case<br>
> a new object was added into CreateObject, but the destroy callback functions<br>
> for that object weren't implemented.<br>
</div></div>The easiest way would be to just send the patch that implements those<br>
first. The slightly more complicated way would be to add another todo<br>
flag.<br>
</blockquote></div><br></div>