The following new k-base entry describes an issue in OE11.5 and 11.6 related to assigning unknown values to .NET properties.
Assigning .NET property to ? does not yield expected result
"Sometimes is passed through as Null, others sets the default value"
Can anybody clarify the circumstances when the unknown value is passed as Null and when as the default value?
Are releases prior to OpenEdge 11.5 impacted as well?
You're right this is not very clear. First of all it only affects 11.6.3, the 11.6.2 hot fix and 11.7, not 11.5. In 11.6 there is no change unless you use "-unknownToNull 1". In 11.7 we have set that as the default and can go back to the original behavior with "-unknownToNull 0".
With the new behavior on, we will ALWAYS pass null as the value for setting a property when you use the Unknown value. We have always done this for parameter passing.
However, what the value gets set to in .NET depends on how the .NET code is implemented, which of course, we usually don't know, and also have no control over. In .NET base types are not "nullable" by default except for "string" which is always nullable. So for a string, the value will always get set to null now. for other base types (e.g., int, decimal), .NET will set the value to the default for that type when it is not nullable. (Before we used to make that conversion, now .NET will do it).
But it is possible in .NET to make base types nullable with certain syntax, for example using this field declaration (note the question mark after "int"):
public int? myInt;
If that is the case, then if you set this variable to the Unknown value, it will be set to null. I suspect that for most of the classes we deal with (or rather you deal with in your apps), you will continue to get the default value since the .NET side will have made no special attempt to make the property nullable. You can tell if it is via reflection if you need to.
You're right this is not very clear. First of all it only affects 11.6.3, the 11.6.2 hot fix and 11.7, not 11.5. In 11.6 there is no change unless you use "-unknownToNull 1". In 11.7 we have set that as the default and can go back to the original behavior with "-unknownToNull 0".
With the new behavior on, we will ALWAYS pass null as the value for setting a property when you use the Unknown value. We have always done this for parameter passing.
However, what the value gets set to in .NET depends on how the .NET code is implemented, which of course, we usually don't know, and also have no control over. In .NET base types are not "nullable" by default except for "string" which is always nullable. So for a string, the value will always get set to null now. for other base types (e.g., int, decimal), .NET will set the value to the default for that type when it is not nullable. (Before we used to make that conversion, now .NET will do it).
But it is possible in .NET to make base types nullable with certain syntax, for example using this field declaration (note the question mark after "int"):
public int? myInt;
If that is the case, then if you set this variable to the Unknown value, it will be set to null. I suspect that for most of the classes we deal with (or rather you deal with in your apps), you will continue to get the default value since the .NET side will have made no special attempt to make the property nullable. You can tell if it is via reflection if you need to.
P.S. I will try and get the kbase entry ammended.
I realize Laura already has this covered, but issues like this are a perfect example of the types of things you could surface in the new Knowledgebase Community group that just launched. The KB Community Manager, Mei Swank, monitors all the activity in that group.
community.progress.com/.../knowledge_base
Thanks
Ed
Thanks Ed. Laura or Mike, any KB related issues, please visit my KB community and report it there or report it directly under article feedback.
Mei
Hi Mike,
We reported this bug.
A workaround for older OE versions, if you have access to the .NET code being called, is to create a method to set a property value. Passing the unknown value to .NET methods always goes through unchanged.
This is of course only useful if you can change the .NET code...