Hi,

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.

Kornél

----- Original Message -----
From: "Peter Dennis Bartok" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>;
<[email protected]>
Sent: Sunday, October 23, 2005 4:50 PM
Subject: Re: [Mono-winforms-list] What ImageList bugs do we need?


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" <[EMAIL PROTECTED]>
To: <[email protected]>
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  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-winforms-list



_______________________________________________
Mono-winforms-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-winforms-list


_______________________________________________
Mono-winforms-list maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-winforms-list

Reply via email to