Actually the docs, on my dev machine, state the following:
"The UInt32 type is not CLS-compliant. The CLS-compliant alternative type is
Int64. Int32 can be used when the original value is less than half of
UInt32.MaxValue."
Syntax based on .NET Framework version 1.1.
Documentation version 1.1.1.

Signature
Tim Wilson
.Net Compact Framework MVP
{cf147fdf-893d-4a88-b258-22f68a3dbc6a}
> Hello,
>
[quoted text clipped - 31 lines]
>
> Rick
rt - 10 Jun 2004 18:48 GMT
Hmm,
Thanks Tim. I looked again and you are correct.
Rick
> Actually the docs, on my dev machine, state the following:
> "The UInt32 type is not CLS-compliant. The CLS-compliant alternative type is
[quoted text clipped - 39 lines]
> >
> > Rick
rt - 10 Jun 2004 19:01 GMT
New problem,
Using Int64 code for the default value gets generated. For example the code
generated is
this.bridgeCtrl1.TimeoutConstant = ((long)(30));
Is there a way to keep it from being generated when the value is actually
set to the default value? Also, the PropertyGrid doesn't recognize the value
as being the default. (Show bold text.)
Thanks,
Rick
> Actually the docs, on my dev machine, state the following:
> "The UInt32 type is not CLS-compliant. The CLS-compliant alternative type is
[quoted text clipped - 39 lines]
> >
> > Rick
Tim Wilson - 10 Jun 2004 19:18 GMT
The DefaultValue attribute *should* take care of that for you. Is there a
reason why you chose Int64 over Int32? I would assume from the name of your
property that you are using 30 seconds as the default for a timeout period.
So you might be able to use Int32, which is much more common to use than a
64-bit integer. Just curious.

Signature
Tim Wilson
.Net Compact Framework MVP
{cf147fdf-893d-4a88-b258-22f68a3dbc6a}
> New problem,
>
[quoted text clipped - 59 lines]
> > >
> > > Rick
rt - 11 Jun 2004 02:32 GMT
For this value you are correct, Int32 would work. Most of the other
properties are used to set bits (32 bit field) so UInt32 would be ideal.
Int64 at least makes it so I don't have to deal with the MSB being set.
I fixed the problem by casting the default value as long and that fixed the
problem. That is I changed from [DefaultValue(30)] to
[DefaultValue((long)30)]
Looking at the overloads for DefaultValue casting makes sense.
Thanks,
Rick
> The DefaultValue attribute *should* take care of that for you. Is there a
> reason why you chose Int64 over Int32? I would assume from the name of your
[quoted text clipped - 70 lines]
> > > >
> > > > Rick
Tim Wilson - 11 Jun 2004 02:50 GMT
Yeah, now that you mention that it makes sense that it was being picked up
as an Int32 when you really wanted an Int64. So the default value was
correct but being interpreted into the wrong overload because of the type.
Anyways, glad to hear that things have been worked out now. Tricky though.

Signature
Tim Wilson
.Net Compact Framework MVP
> For this value you are correct, Int32 would work. Most of the other
> properties are used to set bits (32 bit field) so UInt32 would be ideal.
[quoted text clipped - 90 lines]
> > > > >
> > > > > Rick