Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Windows Forms / Design Time / June 2004

Tip: Looking for answers? Try searching our database.

System.UInt32, DefaultValue CLS compliant problems

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
rt - 10 Jun 2004 17:15 GMT
Hello,

I've written a component that has public properties of type System.UInt32.
When the component is added to a project (component tray) the following is
produced in the code (Form for which the component was dropped):

// TODO: Code generation for 'this.bridgelCtrl1.TimeoutConstant' failed
because of Exception 'Invalid Primitive Type: System.UInt32. Only CLS
compliant primitive types can be used. Consider using
CodeObjectCreateExpression.'.

This is the declaration for one of the properties in the component class:

public class ...
{
   [Category("Timeouts")]
   [Description("Connection timeout.")]
   [DefaultValue(30)]
   public System.UInt32 TimeoutConstant
   {
       get
       {
           return ...;
       }
       set
       {
           ...;
       }
}

According to the documentation System.UInt32 is CLS compliant. Any ideas?

Thanks,

Rick
Tim Wilson - 10 Jun 2004 17:34 GMT
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

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.