Horrible bug in VS.net 2003 - please confirm

[Michael Bray]

Please, someone verify that this isn't just my system with this error...
The problem is that VS.net can't properly store large 'long' values for
control properties.. I'm guessing the threshold is actually if they are
larger than an int.MaxValue.

Steps to reproduce:

1. Create a Windows Control Library project
2. Create a new control
3. Add a 'protected long' member
4. Add a 'public long' get/set accessor for the member (make the get
return the value, and the set assign the value to the member)
5. Create a Windows Forms project (then build the solution)
6. Add the control to the form
7. Set the property on the control to a large long value
8. Run (ok everything works fine)
9. When you view the properties of the control, the value isn't preserved
properly.

The large long value I use is 632890064081923187. This is actually the
DateTime.UtcNow.Ticks value for my system. Although I am writing the
control to be used with DateTime's, I also want to be able to use it for
any long value, not just DateTimes. I say this because I have a feeling
that this problem doesn't manifest itself if I use DateTimes.

You can kind of see what might be happening in the InitializeComponent
class of the windows form... on my system it generates the code:

this.control1.LongValue = ((long)(632890064081923187));

Now I'm not 100% sure, but it seems to me that the numeric value might be
being interpreted as an int before it gets cast to a long.

FYI I haven't tried this with VS 2005, but it doesn't matter because I need
to use VS 2003.

Can anyone confirm that this isn't just my system? Does anyone know of a
fix for this?

Thanks!

-mdb

[Thomas T. Veldhouse]

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

>
this.control1.LongValue = ((long)(632890064081923187));

What about:

this.control1.LongValue = 632890064081923187L;
--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1

[Michael Bray]

Trivial and ineffective. I don't want to have to set this in my
constructor or something... and making this change in the
InitializeComponent will only be overwritten when I make any changes.
Maybe even when I recompile. Remember the code I'm talking about is the
auto-generated code made by VS.net.

-mdb

"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in
news:rJ******************************@giganews.com :

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

>>
this.control1.LongValue = ((long)(632890064081923187));

What about:

this.control1.LongValue = 632890064081923187L;

[Thomas T. Veldhouse]

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

Trivial and ineffective. I don't want to have to set this in my
constructor or something... and making this change in the
InitializeComponent will only be overwritten when I make any changes.
Maybe even when I recompile. Remember the code I'm talking about is the
auto-generated code made by VS.net.

What? I am indicating your syntax was wrong:

use:

this.control1.LongValue = 632890064081923187L;

instead of:

this.control1.LongValue = ((long)(632890064081923187));

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1

[Thomas T. Veldhouse]

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

Trivial and ineffective. I don't want to have to set this in my
constructor or something... and making this change in the
InitializeComponent will only be overwritten when I make any changes.
Maybe even when I recompile. Remember the code I'm talking about is the
auto-generated code made by VS.net.

Ignore my last post, I didn't realize your long value is actually your system
clock ticks.

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1

[Michael Bray]

I'll ignore it, but not because it's system clock ticks. I'll ignore it
because I didn't write that code - it is auto-generated by VS.net. :)

-mdb

"Thomas T. Veldhouse" <ve*****@yahoo.comwrote in
news:L6******************************@giganews.com :

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

>Trivial and ineffective. I don't want to have to set this in my
constructor or something... and making this change in the
InitializeComponent will only be overwritten when I make any changes.
Maybe even when I recompile. Remember the code I'm talking about is
the auto-generated code made by VS.net.

Ignore my last post, I didn't realize your long value is actually your
system clock ticks.

[Bruce Wood]

Michael Bray wrote:

Please, someone verify that this isn't just my system with this error...
The problem is that VS.net can't properly store large 'long' values for
control properties.. I'm guessing the threshold is actually if they are
larger than an int.MaxValue.

<snip>

You can kind of see what might be happening in the InitializeComponent
class of the windows form... on my system it generates the code:

this.control1.LongValue = ((long)(632890064081923187));

Now I'm not 100% sure, but it seems to me that the numeric value might be
being interpreted as an int before it gets cast to a long.

Always test before posting! <Evil grin>

I tried exactly what you suggested, and my VS2003 Designer generates
exactly the same code.

However, I also dropped a TextBox on my UserControl and had it display
the contents of the private field; the text box showed
632890064081923187, exactly as it should have.

I'll leave it to someone who understands the dark interior workings of
C# to explain why the above code results in a long literal, not an int
literal. Nonetheless, it appears to cause no problems: everything works
out the way you would expect (expect at the macro level, that is).

[Thomas T. Veldhouse]

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

I'll ignore it, but not because it's system clock ticks. I'll ignore it
because I didn't write that code - it is auto-generated by VS.net. :)

In which case I would report it and indicate its "horribleness" when you do
;-)

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1

[Michael Bray]

"Bruce Wood" <br*******@canada.comwrote in
news:11**********************@m79g2000cwm.googlegr oups.com:

Always test before posting! <Evil grin>

I tried exactly what you suggested, and my VS2003 Designer generates
exactly the same code.

However, I also dropped a TextBox on my UserControl and had it display
the contents of the private field; the text box showed
632890064081923187, exactly as it should have.

I'll leave it to someone who understands the dark interior workings of
C# to explain why the above code results in a long literal, not an int
literal. Nonetheless, it appears to cause no problems: everything
works out the way you would expect (expect at the macro level, that
is).

Oh man I've been testing for hours... I see the problem every time. Let
me give more details...

On my usercontrol, I paint the value in the OnPaint. Sometimes, even
though the 'bad' value shows up in the designer where the control is on the
form, when I run the form it shows the correct value.

But then, if I change some things around in the control, such as the
location or size of the control, then the value sticks to the bad value and
that's what I see when I run the form.

The critical part for me is that after I've dropped the control on the
form, and then I run the program (and the control paints the correct
value), when I look at the value in the designer next, it has the 'bad'
value. Did you look at the designer value or just the value in the
textBox? Did you play with the control at all? I would guess that if you
play for a bit then it will show.

I'll even make a video of it happening and I can show you... I'll post code
even. I'll make another post when they are ready.

-mdb

[Michael Bray]

Michael Bray <mbray@makeDIntoDot_ctiusaDcomwrote in
news:Xn****************************@207.46.248.16:

I'll even make a video of it happening and I can show you... I'll post
code even. I'll make another post when they are ready.

OK... I made a screen-cap movie of what's happening. You can download the
movie (22MB) and the source code (a few K) with the following links:

http://users.ctinet.net/mbray/BadControlMovie.zip
http://users.ctinet.net/mbray/DumbTest.zip

Extract DumbTest.zip to a directory, and open the solution file in DumbTest
subFolder. Use the movie to see exactly what I am doing.

-mdb

[Thomas T. Veldhouse]

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

Michael Bray <mbray@makeDIntoDot_ctiusaDcomwrote in
news:Xn****************************@207.46.248.16:

>I'll even make a video of it happening and I can show you... I'll post
code even. I'll make another post when they are ready.

OK... I made a screen-cap movie of what's happening. You can download the
movie (22MB) and the source code (a few K) with the following links:

http://users.ctinet.net/mbray/BadControlMovie.zip
http://users.ctinet.net/mbray/DumbTest.zip

Extract DumbTest.zip to a directory, and open the solution file in DumbTest
subFolder. Use the movie to see exactly what I am doing.

Your movie was too big to download. However, I was able to download your code
and set the value [via the properties panel] to 632890064081923187. That
number is beyond the range of a Int32 variable and within the range of a Int64
variable, signed in both cases. long is an Int64 (signed) for all intents and
purposes. It worked just fine .... every time. It is mysterious to me why it
is not casting too an int first though, as it really should be without the
literal declaration of the L.

In short, I didn't see any issues at all.

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1

[Michael Bray]

OK I just tried this on a colleagues machine, and I see the exact same
problem. It can't be just me. Maybe it is our particular version of
VS.NET 2003?

-mdb

"Bruce Wood" <br*******@canada.comwrote in
news:11**********************@m79g2000cwm.googlegr oups.com:

>
Michael Bray wrote:

>Please, someone verify that this isn't just my system with this
error... The problem is that VS.net can't properly store large 'long'
values for control properties.. I'm guessing the threshold is
actually if they are larger than an int.MaxValue.

[Thomas T. Veldhouse]

Michael Bray <mbray@makedintodot_ctiusadcomwrote:

OK I just tried this on a colleagues machine, and I see the exact same
problem. It can't be just me. Maybe it is our particular version of
VS.NET 2003?

MDE 2003: Version 7.1.3088
..NET Framework: Version 1.1.4322 SP1

-mdb

"Bruce Wood" <br*******@canada.comwrote in
news:11**********************@m79g2000cwm.googlegr oups.com:

>>
Michael Bray wrote:

>>Please, someone verify that this isn't just my system with this
error... The problem is that VS.net can't properly store large 'long'
values for control properties.. I'm guessing the threshold is
actually if they are larger than an int.MaxValue.

--
Thomas T. Veldhouse
Key Fingerprint: 2DB9 813F F510 82C2 E1AE 34D0 D69D 1EDC D5EC AED1

[Michael Bray]

MDE 2003: Version 7.1.3088

.NET Framework: Version 1.1.4322 SP1

Nope I've got the same.... OK I guess I'll just open a case w/ Microsoft.

Thanks for checking...

-mdb

[rogers.terry]

Looks like a bug to me.
It happens on my copy of VS2003.

There's actually no difference between
long value = (long)632890064081923187;
and
long value = 632890064081923187L;
The compiler will recognise the first pattern and treat it as a long
literal.

(Hence doing it the other way round:
int value = (int) (632890064081923187L)
is a compiler error even though it looks like a valid, if unchecked,
cast from long to int).

The designer probably chose to do it that way as it works with all
primitive types (there isn't a literal syntax for all types AFAIK).

The problem seems to occour when the designer reloads the file, e.g.
when you compile.
i.e. when it's reading back the designer generated code (it does this
so it can update to any changes you may have made in the designer
generated code by hand - and when it's only got that code to work from
such as when you first open the file). It reads the value back wrong,
probably treating the code "(long)632890064081923187" literally as a
cast from an int literal to a long value. It then puts this bad value
into the property sheet, but doesn't change the code at that point. The
next time you save however the bad value will get written out as it
rewrites the designer generated code.

Doesn't seem to happen with VS 2005 though.

Terry
Michael Bray wrote:

Michael Bray <mbray@makeDIntoDot_ctiusaDcomwrote in
news:Xn****************************@207.46.248.16:

I'll even make a video of it happening and I can show you... I'll post
code even. I'll make another post when they are ready.

OK... I made a screen-cap movie of what's happening. You can download the
movie (22MB) and the source code (a few K) with the following links:

http://users.ctinet.net/mbray/BadControlMovie.zip
http://users.ctinet.net/mbray/DumbTest.zip

Extract DumbTest.zip to a directory, and open the solution file in DumbTest
subFolder. Use the movie to see exactly what I am doing.

-mdb