Printable View
[Sunday, March 20, 2005 2:25 AM]
In doing some folder creation + copy local files + delete local files it
seems that a positive value of SB ERRORCODE indicates success. Is there a
single value of SB ERRORCODE that indicates an error, and doe any value GT
0 always mean no error?
--
Best regards,
Mark
[Sunday, March 20, 2005 4:31 PM]
Mark,
Very good question! It depends on the used Windows API. At the moment we
are documenting all the return values. The return value list will be
available by the end of this week!
Friedrich
--
Friedrich Linder
CEO, Lindersoft
www.lindersoft.com
1.954.252.3910
[Sunday, March 20, 2005 6:08 PM]
>Mark,
>
>Very good question! It depends on the used Windows API. At the moment we
>are documenting all the return values. The return value list will be
>available by the end of this week!
Friedrich,
I had a feeling you'd say that. :}
This reasoning may not make sense for SB, and that's fine, but have a go at
this. Following through in SB on the behavior of various
APIs/Clarion/whatever inconsistencies in function call status return values
adds complexity, perhaps unnecessarily.
For example, rather than,
AnythingAtAll()
if ( SB ERRORCODE = 0 )
cool!
end
We have to know in advance that a successful CopyLocalFile() is 0, or 1, etc.
And we have to know that for everything we are likely to do with SB.
So we wind up with,
SomeThing()
if ( SB ERRORCODE > 0 )
cool!
end
SomeOtherThing()
if ( SB ERRORCODE = 0 )
cool!
end
YetAnotherThing()
if ( SB ERRORCODE < 0 )
cool!
end
Which seems prone to error, and (at least for me) requires re-reading the
docs to refresh the memory on the return state of various calls.
Would it enhance usability if the behavior of SB ERRORCODE was consistent
for every action, returning only a single success value, or a failure value?
If so, would it be worth the effort to use another variable that contained
the actual API call's status value?
That would allow for the most straightforward use of everything that uses the
API, and still allow for the cases where there can be multiple
success/failure values. If we need to code for those, they're available. If
we simply want success or failure (I'm guessing the most frequent case), then
we have a consistent interface to it.
JAT.
--
Best regards,
Mark
[Monday, March 21, 2005 4:26 PM]
Mark,
Yes, I also see this "problem".
I'll try to make it consistent for every script item (I am checking all
return codes now).
1. If a function succeeds, the return value is nonzero.
2. If a function fails, the return value is zero.
Thanks,
Friedrich
--
Friedrich Linder
CEO, Lindersoft
www.lindersoft.com
1.954.252.3910
[Monday, March 21, 2005 4:37 PM]
Friedrich,
Is that reversed? I expect succeeding functions to return 0, at least in
the Boolean sense. Which means a zero for success, or a failure code.
Otherwise you could return codes that indicate degrees of success or
failure, in which case you should not use Boolean logic, but test for
specific return values.
RetVal = SomeFunction()
IF RetVal = S_OK
!It worked
END
--
Russ Eggen
www.radfusion.com
[Monday, March 21, 2005 5:22 PM]
Russ,
Yes, I also expect succeeding functions to return 0. The problem is that
most Windows API return 0 if the function fails and nonzero if the function
succeeds.
For example:
CopyFile API
http://msdn.microsoft.com/library/de...e/copyfile.asp
Delete File API
http://msdn.microsoft.com/library/de...e/copyfile.asp
At the moment SB5 returns the Windows API return code if an installer
function calls into a Windows API. But our own functions (not based on
Windows APIs) return 0 if the function succeeds, so we are not consistent
:-(
Friedrich
--
Friedrich Linder
CEO, Lindersoft
www.lindersoft.com
1.954.252.3910
[Monday, March 21, 2005 5:57 PM]
Understood. Documenting all return values is the only way to get it
"standard". Pick a side and the other is going to complain. :(
--
Russ Eggen
www.radfusion.com
[Monday, March 21, 2005 6:39 PM]
FWIW, the Armadillo DLL functions also return nonzero on success, zero on
failure.
Jane
[Monday, March 21, 2005 5:58 PM]
>Mark,
>
>Yes, I also see this "problem".
>
>I'll try to make it consistent for every script item (I am checking all
>return codes now).
>
>1. If a function succeeds, the return value is nonzero.
>2. If a function fails, the return value is zero.
Friedrich,
Thanks. The consistency will make scripts a good bit more readable.
--
Best regards,
Mark