Nikolay Sivov wrote:
> Andrew Eikum wrote:
>> ---
>> dlls/gdiplus/gdiplus_private.h | 3 +
>> dlls/gdiplus/graphics.c | 154
>> ++++++++++++++++++++++++++++++++++++++--
>> include/gdiplusflat.h | 1 +
>> 3 files changed, 152 insertions(+), 6 deletions(-)
>>> This looks wrong for me cause I don't think you could pass container
> id created with one Graphics to
> Graphics.EndContainer() of another. I've just checked it and it
> doesn't return any error code,
> but generated container ids aren't the same when you call
> BeginContainer() for e.g. two objects
> as sequent steps. It looks like on native these value are module
> unique, some kind of handle table needed.
> This kills the first problem I described - passing strange value to
> another Graphics.
>> Also note that Save()/Restore() functionality uses the same stack with
> container calls (at least msdn tells us that),
> for that Save/Restore we already have a test:
> ---
> static void test_save_restore(void)
> ....
> /* The same state value should never be returned twice. */
> todo_wine
> check_no_duplicates(state_log);
> ....
> ---
>> It clearly says that no duplicates allowed, even after multiple object
> deletion - it checks for values returned
> during the whole test.
I agree that the behavior of the container IDs doesn't match native.
However, do we really care to duplicate that behavior? I can't see any
documentation in MSDN that says container IDs must be unique across
either graphics objects or within a single graphics object.
I can't imagine any application depending on the uniqueness of container
IDs; if they try to pass a container for graphics1 to graphics2, nothing
happens, so there's no behavior to depend on. Ditto for invalid or
already-used containers. The only scenario I can think of where the
uniqueness of container IDs would be a dependency would be an
application error calling EndContainer() with invalid values. I don't
know if it's worth the effort of making a handle table and whatnot to
work around an application glitch that might not even exist.
So, I would argue against the validity of the test you quote. Why
should the same value not be returned twice?
Andrew