Does anyone need .NET Framework Nullable type support in TestStand?

[Manooch_H]

Is anyone currently using or planning on using the Nullable generic type and is it something you'd like to be able to use directly from the .NET adapter in TestStand?

Although TestStand 2010 now supports generic types, it does not support Nullable. Nullable does not behave like a regular generic because it has special boxing and unboxing behaviors that are intrinsic to the Common Language Runtime. It is however used by some APIs that come with the .NET Framework, such as WPF.

See the following for more information:
http://msdn.microsoft.com/en-us/library/b3h38hb0%28v=VS.80%29.aspx

If you are using or plan on using Nullable and would like to be able to use it directly from the .NET adapter in TestStand please let us know.

[Josh_W]

Manooch,

Yes, I would like to see Nullable<T> implemented directly in the .NET adapter.

For those that don't know, you can create a nullable value type by using the "?" symbol after the type name (i.e. int? or Guid?).

The reason I would like to see this is that we have a custom value type that we use for storing a value along with its units. But often, this is an optional property of a class (i.e. in the case of a low limit without a high limit). We do this to save space when storing or transmitting data, to make it easy to check if the property is not set by just comparing (prop != null), and because we display it in our GUIs, which are built using WPF.

As another example, we have a property that is a Guid that is not required to be set.  If we use the basic Guid struct, then we have to assign a value to it; so to check that it is not used, we have to check (prop != new Guid()).  I find this much more inelegant than when using the Guid? type and checking (prop != null). Also, as a nullable type, if we display it in a WPF control through databinding, it automatically displays an empty string if it is null (as opposed to showing a Guid of all zeros if we used the non-nullable type).

Just my 2¢.

[dug9000]

You can do:

prop != Guid.Empty;

instead of

prop != new Guid();

to make things more efficient.

But I agree it's valid that nullable types are still generally useful in some cases.

-Doug

[pwaszkewitz]

It's definitely useful. We would recently have needed it in LabView actually, but the need will also arise in TestStand.

We have .NET components here for database access which use a nullable type to express that a database field may actually be empty, in contrast to containing a 0 or an empty string.

Regards

Peter

[JHE]

Nullable types are used with LINQ to SQL with tables that allows null, so that is a big yes 🙂