Type Mismatches in Method Calls

See Also

In method calls, whenever you pass a text-like value (a string) or an object-like value as a parameter for a method or as a value for a property, you need to make sure that the value is of the expected type.

If there is a type mismatch, USoft Developer implicitly attempts to convert the value to the expected type. If this is not successful, a type mismatch occurs. The Object Activator warns you about type mismatches.

Implicit conversion is especially important for interface elements holding data (base column fields and non-database fields). Here, implicit conversion to the current value is always attempted. This makes it very easy to read or write on-screen values from , or into these fields.

Example 1

query.status('SOLD')

query.status.value('SOLD')

Both these method calls can be used to write SOLD into an on-screen STATUS field. Strictly, SOLD is a string value and the STATUS field is an object, but because of implicit conversion even the first method call will be successful and no type mismatch will occur. All that the object can do is to accept the string as its (new) current value.

Example 2

query.status(currentStatus())

where "currentStatus" is a user-defined property of type String. For the same reason as in example 1, no type mismatch is raised here.

Example 3

query.status(query.old_status())

Here the status field is set to the same value as another field. This time, strictly, no conversion should take place because a string is not expected and also not passed, but the effect is still that the current old status value is pasted into the status field. This is because the "query.status" object is READ ONLY, but its Value property is not. Therefore the method call is implicitly interpreted as a string value assignment, which is the intended behavior.