Assigning .NET property to ? does not yield expected result

Posted by Lieven De Foor on 04-Jul-2016 09:24


Documentation says the following about .NET null and ABL unknown value:

In general, ABL maps the Unknown value (?) to the .NET null value. Thus, if you pass the
Unknown value (?) as a .NET method parameter or assign it to a .NET data member or property,
ABL converts it to null. However, where .NET defines a default value for a data type, setting a
.NET data item to the Unknown value (?) actually sets the data item to the default value
specified for the data type. This means that if you set a .NET data type that has a default value to
the Unknown value (?), retrieving the value of that data type returns its default value, not the
Unknown value (?) that you assigned.

However when we assign a property of type string in a .NET class to ? from ABL, the .NET side receives an empty string ("")

Since the default value of string is null, we did not expect that.

Same goes for nullable int (int?).

If we get it from the ABL code without assigning it a value (not from ABL and not from .NET) we get the default value: null/?

If we assign it from ABL with the value ?, and get it back we get 0.

Again, not expected since the default value of int? is null.

Is this a bug?

All Replies

Posted by Phillip Molly Malone on 04-Jul-2016 19:32

Hi Lieven,
Can you give an example of the behavior your seeing? Just want to make sure we are on the same page while investigating this.

Posted by Simon L. Prinsloo on 05-Jul-2016 01:06

Sounds like a bug to me. I would suggest you contact TS and send them an example.

Posted by Matt Gilarde on 05-Jul-2016 03:45

The code which converts an ABL character string value to a .NET string explicitly converts the unknown value to String.Empty. Please log an issue with Tech Support. We may not be able to change the behavior at this point due to backward compatibility concerns but we can try to determine why the conversion was done this way.

Posted by Simon L. Prinsloo on 05-Jul-2016 04:42

How will we then assign a NULL to a System.String? In many cases these are distinctly different, as an empty string may be a valid value that had been supplied/retrieved, as opposed to a NULL,  that may indicate the absence of a value, which could be a problem.

Posted by tpavlovic on 05-Jul-2016 05:20

11.6.2 on Win32

There is indeed something weird. This my test:

using System;

namespace TestLib


    public class Test


        public int? Int { get; set; }

        public string String { get; set; }

        public DateTime? DateTime { get; set; }


        public int? Int2;

        public string String2;

        public DateTime? DateTime2;


        public Test()




        public Test(int? _int, string _string, DateTime? _dateTime, int? _int2, string _string2, DateTime? _dateTime2)


            Int = _int;

            String = _string;

            DateTime = _dateTime;


            Int2 = _int2;

            String2 = _string2;

            DateTime2 = _dateTime2;




// ****

USING TestLib.*.


ASSIGN oTest = NEW Test()
       oTest:Int = ?
       oTest:String = ?
       oTest:DateTime = ?
       oTest:Int2 = ?
       oTest:String2 = ?
       oTest:DateTime2 = ?

       oTest2 = NEW Test(?, ?, ?, ?, ?, ?)

MESSAGE oTest:Int oTest:String oTest:DateTime oTest:Int2 oTest:String2 oTest:DateTime2 SKIP
        oTest2:Int oTest2:String oTest2:DateTime oTest2:Int2 oTest2:String2 oTest2:DateTime2

And the result is:

0 01/01/001 00:00:00,000 0 01/01/001 00:00:00,000
? ? ? ? ? ?

Assigning properties/fields is obviously wrong.


Posted by Lieven De Foor on 06-Jul-2016 02:12

Hi Matt,

A case is logged.

It would be a shame if this wouldn't get fixed because code could depend on the wrong behavior.

Wouldn't it make sense to fix this and if needed add a startup parameter to get back the old behavior?

We really need to be able to tell the difference between "not set" (null, ?) and empty string,0, 01/01/0001...

This thread is closed