[Mono-winforms-list] What ImageList bugs do we need?

[Peter Dennis Bartok]

Kornel,

I will defer to Jackson to make a call on those particular items, since he's 
been looking over ImageList more closely than I have.
As a general rule, however, we want MWF to be compatible, and that includes 
compatibility to bugs. You never know what broken behaviour an existing 
application relies on. (Despite what another response to your message 
suggested, that applications are ported, the idea of MWF is that no porting 
is required, that the app can be used unchanged on Mono)
The fact that MS fixed something for 2.0 (which shows they are aware of the 
bug), but not in a service pack for 1.1 I think is indicator that MS has the 
same thinking, they don't want to break existing apps relying on their buggy 
behaviour.
I think the proper way is to be bug-compatible, and create a unit test that 
tests for the buggy behaviour. Once MS decides to fix it, the tests will 
indicate it being fixed when run on MS, and we can adjust accordingly.

Cheers,
  Peter

-----Original Message-----
From: "Kornél Pál" <kornelpal at hotmail.com>
To: <mono-winforms-list at lists.ximian.com>
Date: 22 October, 2005 19:08
Subject: [Mono-winforms-list] What ImageList bugs do we need?


>Hi,
>
>Now ImageList should be functionally compatible with MS.NET. The only thing
>it cannot support is a native image list handle.
>
>But MS.NET ImageList seems to be poorly designed and in addition has a lot
>of bugs.
>
>There are three bugs that are so critical that I have corrected them:
>
>1) MS.NET 1.x shares the same HIMAGELIST between ImageLists that were
>initialized from the same ImageListStreamer and doesn't update ImageSize 
>and
>ColorDepth that are treated as bugs and MS.NET 2.0 behavior is implemented.
>
>2) MS.NET 2.0 initializes TransparentColor to Color.Transparent in
>constructors but ResetTransparentColor and ShouldSerializeTransparentColor
>default to Color.LightGray that is treated as a bug.
>
>3) MS.NET 2.0 does not clear keys when handle is destroyed that is treated
>as a bug.
>
>And there are some other bug that I implemented as feature:
>
>4) Image strips are counted as a single item in the return value of Add and
>AddStrip until handle is created.
>
>5) When ImageSize was changed after adding image strips Count will return
>invalid values based on old ImageSize but when creating handle either
>ArgumentException will be thrown or image strip will be added according to
>the new ImageSize. This can result in image count difference that can 
>result
>in exceptions in methods that use Count before creating handle. In addition
>this can result in the loss of sync with keys. When doing the same after
>handle was created there are no problems as handle will be recreated after
>changing ImageSize that results in the loss of images added previously.
>
>6) When last IndexOfKey was successful and the same key was assigned to an
>image with a lower index than the last result and the key of the last 
>result
>equals to key argument the last result is returned.
>
>And ImageList has some other poorly designed methods that aren't bugs but
>their behavior is documented as comments in source code.
>
>Bug 1) can causes defective behavior particulary because thread safety
>issues.
>Bug 2) prevents Color.LightGray from being used as TransparentColor.
>Bug 3) makes keys useless after handle recreation.
>Bug 4) makes return value of Add methods useless.
>Bug 5) makes ImageSize changing incompatible with image strips and can 
>cause
>very defective behavior when using image strips.
>Bug 6) makes IndexOfKey behavior inconsistent.
>
>All the above bugs can cause extreme ImageList behavior but who know 
>whether
>some people are assume this behavior.
>
>My questions is that do we need any of these bugs as features? And do you
>mind if I correct bugs 4-6?
>
>Kornél
>
>_______________________________________________
>Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
>http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>
>