Hi,
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?
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.
TIA
Molly
Sounds like a bug to me. I would suggest you contact TS and send them an example.
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.
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.
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.*.
DEFINE VARIABLE oTest AS CLASS Test NO-UNDO.
DEFINE VARIABLE oTest2 AS CLASS Test NO-UNDO.
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
VIEW-AS ALERT-BOX INFO BUTTONS OK.
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.
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...