[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