[Mono-winforms-list] What ImageList bugs do we need?
kornelpal at hotmail.com
Sun Oct 23 11:43:16 EDT 2005
Some information about implementing bugs:
In the case of bug 1) am sure that they don't care about it as ImageStream
propery is only used by the designer that sets properties alphabetically and
nobody ever tried to use that property so they did not experience bogus
behavior. If we really need that bug as a feature it means that we will have
to create a private class that behaves as native Windows image list and wrap
it using the same low performance methods (like creating a new Bitmap and
draw image to that bitmap) as MS.NET has as in this case native image list
may have different color depth and size than the managed one that should be
emulated. And native emulation part of ImageList should be thread safe as
Windows image list is that results in performance loss altough managed parts
of MS.NET ImageList are not thread safe so there is no use to have partial
thread safety unless we want to copy bugs cause by thread safety issues. And
if we really need this behavior it requires the rewrite of the core of
ImageList class to a less efficient but bogus version.
And note that for example our ImageList has full alpha channel support that
is an extra feature compared to the very limited alpha channel support of
MS.NET. If we want full MS.NET compatibility we have to drop full alpha
channel support but MWF should be modified to use ICO files as icons instead
of PNG files. And MS.NET has alpha channel support only on Windows XP and
later with comctl32.dll version 6.0 that is only loaded by default in MS.NET
2.0 so if we really want to be fully MS.NET compatible we can't use alpha
channel in icons.
I belive that there are bugs and limitations that should not be copied. For
example Mono runtime accepts 2.0 IL code in 1.x assemblies that is
definitely incompatible with MS.NET.
----- Original Message -----
From: "Peter Dennis Bartok" <peter at novonyx.com>
To: "Kornél Pál" <kornelpal at hotmail.com>;
<mono-winforms-list at lists.ximian.com>
Sent: Sunday, October 23, 2005 4:50 PM
Subject: Re: [Mono-winforms-list] What ImageList bugs do we need?
> I will defer to Jackson to make a call on those particular items, since
> been looking over ImageList more closely than I have.
> As a general rule, however, we want MWF to be compatible, and that
> 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
> 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
> bug), but not in a service pack for 1.1 I think is indicator that MS has
> same thinking, they don't want to break existing apps relying on their
> I think the proper way is to be bug-compatible, and create a unit test
> 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.
> -----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?
>>Now ImageList should be functionally compatible with MS.NET. The only
>>it cannot support is a native image list handle.
>>But MS.NET ImageList seems to be poorly designed and in addition has a lot
>>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
>>ColorDepth that are treated as bugs and MS.NET 2.0 behavior is
>>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
>>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
>>in exceptions in methods that use Count before creating handle. In
>>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
>>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
>>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
>>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
>>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?
>>Mono-winforms-list maillist - Mono-winforms-list at lists.ximian.com
> Mono-winforms-list maillist - Mono-winforms-list at lists.ximian.com
More information about the Mono-winforms-list