mexHID provide string names for report types and errors

[GoogleCodeExporter]

As of r375, mexHID uses integers to represent HID report types (input, output, 
feature) and function status/errors.

Report types should be specified as meaningful names, as opposed to arbitrary 
integers.  Or, there should be a facility to resolve a number by its meaningful 
name.  This could be part of the mexHID mex function or an addition to the 
mexHIDUsage class.

The mexHID mex function should continue to use integers for status and error 
returns.  But it should also have a facility to lookup a meaningful string 
status/error description.  This should be a basic part of the interface, in 
mexHID.h/.c.  It should accept any mxArray as input, including a status/error 
scalar or a data array, so that any value returned from mexHID can be verified. 
 It might have the form

[isSuccessful, description] = mexHID('validate', mx);

Since 'validate' would not know which mexHID sub-function had returned mx, it 
would be worth checking that there are no ambiguous cases.  For example, is the 
scalar -1 ever a valid return, or an array of non-negatives ever invalid?

Original issue reported on code.google.com by Benjamin.Heasly on 22 Sep 2010 at 6:18

[GoogleCodeExporter]

Original comment by Benjamin.Heasly on 23 Sep 2010 at 5:46

• Changed state: Accepted
• Added labels: Priority-High

[GoogleCodeExporter]

As of r388, I've added utilities for getting access to internally used values.

getReportStructTemplate returns a struct with the expected field names for 
reading and writing report data.

getNameForReportType and getReportTypeForName exchange between enumerated 
integers and human-readable strings for HID report types.

getDescriptionOfReturnValue returns a human-readable string for any mxArray.  
If it's a non-positive numeric scalar, matches it to one of the enumerated 
return values.  Otherwise gives a vague description, for example, "looks like 
data".

I didn't add any concept of validation or "isSuccessful", and I'm not planning 
to, after all.

Original comment by Benjamin.Heasly on 24 Sep 2010 at 11:30

• Changed state: Fixed