’ Function Calls
.getCellRangeByName(Update_Status_Date_Cell).setValue(Date)
.getCellRangeByName(Update_Status_Time_Cell).setFormula(Time)
.getCellRangeByName(Update_Status_Cell).setString(Status_Message)
.getCellByPosition(Column, Row).getType()
’ Direct property access
.getCellRangeByName(Update_Status_Date_Cell).Value = Date
.getCellRangeByName(Update_Status_Time_Cell).Formula = Time
.getCellRangeByName(Update_Status_Cell).String = Status_Message
.getCellByPosition(Column, Row).Type
For consistency.
There is some syntactic sugar available in Basic, allowing to use the get/setFoo as a simple Foo property. Using these, you do not see a difference between properties available through XPropertySet with its get/setPropertyValue, and (pseudo)properties available as the own get/set pairs. The binding does the required introspection for you, checking all possible ways to obtain or set the “thing” that you name as a property.
But other language bindings (like Java or C++) may not have these convenience methods. For them, it will be necessary to explicitly use the exact UNO call. There, one will have to call setFoo(x), not Foo = x.
And so, calling these setFoo explicitly in Basic code have a downside of being less clear, but an upside allowing to port this Basic code to other languages easier. It may be not that important, given that it won’t be an effortless task either way, but I prefer more verbose and explicit, closer-to-UNO API way. By the way, the “less clear” is also subjective, with the “property” way hiding the direct connection to UNO, which may be less clear in someone’s view.
Another (possibly less important) consideration may be, that using the explicit syntax puts less load on introspection, and might be slightly more performant.
