NUmericUpDown controls in .NET Compact Framework 3.5

[Cory Albrecht]

Hello all,

I took a Visual Studio2005 solution I was working on that used .NET CF
2.0 and converted to a VS2K8 solution using .NET CF 3.5.

On one form I had a NumericUpDown control that had a maximum value of
86400 and it ran just peachy keen.

But with .NET CF 3.5, the this bit from the form's *.Designer.cs file

this.numUpdateDisplayTime.Maximum = new decimal(new int[] {
86400,
0,
0,
0});

throws an ArgumentException.

So I changed the number downwards a few times until I figured out that
the highest number that the control could handle for it's Maximum
property is 32767.

Hello? WTF? It can only handle a 16-bit signed integer? Even though a
number that wouldn't even fit into a 16-but *unsigned* integer was fine
in v2.0?

Anybody else have this problem and know how to get around it?

 

[Chris Tacke, eMVP]

I don't belive it worked in CF 2.0 either. The root of this is that the
underlying native control (which the managed control simply wraps) uses a
16-bit value for the min and max, so the CF control can't really change that
without trying to reimplement the entire control.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

 

[Chris Tacke, eMVP]

It's an OS limitation.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

Cory Albrecht wrote, on 2008-10-28 17:11:

Hello all,

I took a Visual Studio2005 solution I was working on that used .NET CF
2.0 and converted to a VS2K8 solution using .NET CF 3.5.

On one form I had a NumericUpDown control that had a maximum value of
86400 and it ran just peachy keen.

But with .NET CF 3.5, the this bit from the form's *.Designer.cs file

this.numUpdateDisplayTime.Maximum = new decimal(new int[] {
86400,
0,
0,
0});

throws an ArgumentException.

So I changed the number downwards a few times until I figured out that
the highest number that the control could handle for it's Maximum
property is 32767.

Hello? WTF? It can only handle a 16-bit signed integer? Even though a
number that wouldn't even fit into a 16-but *unsigned* integer was fine
in v2.0?

Anybody else have this problem and know how to get around it?

OK, so after further googling I found this page
<http://msdn.microsoft.com/en-us/netframework/bb986636.aspx>.

Apparenly in .NET CF 2.0, while the control supported the UDN_SETRANGE32
message for signed 32-bit integers, it did not support UDN_SETPOS32 or
UDN_GETPOS32, only the 16-bit versions. So while you could set a 32 bit
min or max value and scroll that high, numbers were trucated down to 16
bits and returned inaccurately as negave if they were too large.

I'm not sure whether this is a limitaion of .NET CF alone, or whether it
is a limitation of the underlying WinCE platform.