We apparently haven't heard of the Law of Demeter:
We apparently haven't heard of the Law of Demeter:
function VarToInt(rs : ADSRecordSet; FieldName : string; ReturnValue : integer = -1) : integer;
begin
// As there is no official VarToInt function I decided to make one up. It vaguely
// follows the VarToStr logic which says that if the value on the table is NULL we
// return an emtpy string. In this case if the value on the table is NULL we return
// the requested return value (or -1 if not requested) else we return the value
if VarIsNull(rs.Fields[FieldName].Value) then
result:= ReturnValue
else
result:= rs.Fields[FieldName].Value;
end; // VarToInt
function VarToInt(rs : ADSRecordSet; FieldName : string; ReturnValue : integer = -1) : integer;
begin
// As there is no official VarToInt function I decided to make one up. It vaguely
// follows the VarToStr logic which says that if the value on the table is NULL we
// return an emtpy string. In this case if the value on the table is NULL we return
// the requested return value (or -1 if not requested) else we return the value
if VarIsNull(rs.Fields[FieldName].Value) then
result:= ReturnValue
else
result:= rs.Fields[FieldName].Value;
end; // VarToInt
And now that I think about it, what the heck do you need a VarToInt for anyway? Just assign the thing!
ReplyDelete... I suppose you have to worry about NULL.....
ReplyDeleteI can see a variant version of StrToIntDef, but yeah seems a bit overkill this one.
ReplyDeletelore of demented what?
ReplyDeleteI think this function is less about LoD violation than about knowing what properties a TField has (IsNull and AsInteger anyone?)
ReplyDeleteI can't understand why function with name "VarToInt" have RecordSet and FieldName in parameter list instead of Variant. Looking for another VarToxxx function accepting DBGrid :)
ReplyDeleteDeveloper apparently hasn't heard of local variables, otherwise it's fine.
ReplyDelete