False versus 'ApiFalse' (wishlist)

[Trevor Lane]

Hi,

Many functions will return zero for success and non zero for fail.
the reasoning is that if it succeeded then that is all you need to
know. If it failed there may be more than one reason. returning a
failed code of '1' for one reason '2' for another. It is all there
to make programming easier although sometimes it doesn't seem it.

It is all very messy and inconsistent though I have to agree.

regards
Trevor


------------------

[Lance Edmonds]

As in my examples, ISTRUE and ISFALSE can take their arguments in parentheses, so it is not really "inconsistent"
eg,

FUNCTION = ISTRUE(x)

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Egbert Zijlema]

Lance,

I've considered to write those functions. Actually, I did. It is as simple as your own examples, indeed.
There is one syntax-difference, however, compared to PB's ISTRUE / ISFALSE: the param the function is going to verify has to be passed between parenthesis, which is not the case with PB's native functions.
E.g.: "IF ISFALSE param" versus "IF ISAPITRUE(param)". Which would be an odd inconsistency.

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/

[Eric Pearson]

I agree with Lance... I'd say that roughly 50% of the API functions that I use return zero when they fail. The most common example is any function that returns a handle. Most of them return zero (NULL) when they fail, but some (like CreateFile) return %INVALID_HANDLE_VALUE.

Adding to Microsoft's mess, not all API functions set GetLastError when they fail. So there's really no way for an APIFALSE function to work in all cases.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Lance Edmonds]

Would it not just be easier to get Microsoft to be consistent in the way the API functions return Success/Failure? This is the real problem, since there is no hard and fast rule about what realy does indicate failure. If PB added these functions, it "may" make it easier for programmers to make incorrect assumptions about API success/failure based on the wrong use of such keywords.

So, why not just create a couple of functions yourself? (as long as the additional overhead is not a worry to you!):

FUNCTION ISAPIFALSE(BYVAL x AS LONG) AS LONG
  FUNCTION = ISTRUE(x)
END FUNCTION
FUNCTION ISAPITRUE(BYVAL x AS LONG) AS LONG
  FUNCTION = ISFALSE(x)
END FUNCTION

That said, I'll certainly still be passing your idea along to R&D...

Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Egbert Zijlema]

Hi, fellow programmers!

Many API functions, for instance registry functions, return zero on success. In other words: they return %FALSE while their effect is true. For example the following 3 calls are actually the same:
IF ApiFunc(params) <> %ERROR_SUCCESS
IF ApiFunc(params)
IF ISTRUE ApiFunc(params)
Your application has to exit a FUNCTION or SUB here, because of the fact the API call failed (although it returns a non-zero value). Especially the latter, explicitely using ISTRUE, sounds very odd. When a function returns true each normal person would think that the function was Okay. So not programmers. They are expected to know that true sometimes means false, vice versa.

In brief: what about 2 new functions in the next edition of PB compilers: ISAPIFALSE / ISAPITRUE, being the opposite of PB's normal ISFALSE / ISTRUE.

------------------
mailto:[email protected][email protected]</A>
www.basicguru.com/zijlema/



[This message has been edited by Egbert Zijlema (edited January 28, 2001).]