How can I create my own HRESULT? For which scope I can use?

--
kind regards/chenyu

HRESULT code (bit-value) mapping is under control of Windows.
So your HRESULT must follow the rule.  Also the HRESULT has
an interesting side-effect.  If the client app is written in VB or
using "smart-pointer" of C++, a negative HRESULT can throw
an exception (_com_error object in C++, or ON ERROR GOTO
support in VB).  This feature is very helpful for most apps.
So you need continue to follow the HRESULT rule and also
better to add your own error-reporting property as need.

makoto

Andre

Thank you for your help.
--
kind regards/chenyu

Using methods that return HRESULTs are fundamental to well-written
components and are essential to the debugging process. Microsoft? Visual
Basic? automatically defines each method with an HRESULT as a return. In
Microsoft Visual C++?, you must explicitly return an HRESULT.

For additional information on HRESULTs, see Structure of COM Error Codes in
the COM documentation in the Platform SDK."

You should use MAKE_HRESULT like this:
const HRESULT ERROR_NUMBER =
    MAKE_HRESULT (SEVERITY_ERROR, FACILITY_ITF, YourCustomErrCodeHere);

You define your error codes in a certain range (so as not to conflict with
existing Windows codes.)  I can't remember what the range is.

You can also use the ErrorInfo object to convey additional information about
the error.  From the MSDN:
"ErrorInfo objects are often called COM exceptions because they allow an
object to pass (or throw) rich error information to its caller, even across
apartment boundaries. The value of this generic error object is that it
supplements an HRESULT, extending the type of error information that you can
return to a caller. Each ErrorInfo object returns a contextual description,
the source of the error, and the interface identifier of the method that
originated the error. You can also include pointers to an entry in a help
file."

The author of your book hopefully meant that you shouldn't define a different HRESULT if one is already available (such as E_OUTOFMEMORY. for instance). However, you're free to customize any HRESULT you want with a facility code of FACILITY_ITF (all other facility codes are off-limits). HRESULTS are interface-specific so the identical HRESULT can potentially have two different meanings if returned by one interface vs another. A good way of doing this is to put them in your IDL file like so:

library YOURLib
{
    importlib("stdole32.tlb");
    importlib("stdole2.tlb");
    [
        helpstring("YourAppName error codes"),
        v1_enum
    ]
    enum YourAppNameErrors
    {
        ///////////////////////////////////////////////////////////////////////////
        // Note that the third arg (status code) MUST start at 0x200 (minimum)
        // since COM itself uses FACILITY_ITF codes in the range 0x0000 to 0x01ff.
        // This prevents possible collisions.
        ///////////////////////////////////////////////////////////////////////////
        E_DUPLICATE_FLD = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF, 0x200),
        E_FLD_TOO_LARGE = MAKE_HRESULT(SEVERITY_ERROR, FACILITY_ITF, 0x201),
        // etc.
    };

// ...

1) Successful HRESULTS are part of the COM interface contract and can't be added to in future releases
2) Failed HRESULTS are not part of the COM interface contract and can be added to in future releases. Clients should always respond to unknown failure codes as if they were E_UNEXPECTED (a handler for this should always be present)
3) Some clients including VB and scripting clients can't access HRESULTS

Also check out IErrorInfo and cousins for a more elaborate way of handling errors.