Note: This blog appeared in http://citrixblogger.org and is being reposted here for a larger audience Citrix
[
for the initial development of mobile pack XenApp, some choices were made for status / error codes. This sense everything during this time, but some issues have come since that requires attention. Nothing serious, but a bit more of an indication that things should be better explained
- Most CMPRESULT XAMA back API
- CMPRESULT is a signed 32-bit number
- CMPRESULT is directly related to CMP_ERROR_ID
- CMP_ERROR_ID is an enumeration in the cmpenum.h file included with the SDK
- CMP_RESULT_ID Each entry uses STATUS_CODE macro to build the status code (error code)
- the macro takes two parameters: the component of iD, and the error number
- both numbers are 16 bits each and combine to form the 32-bit status code (the component id is the big word and the error number is at least).
- When the error number (low word) is zero, it is considered a successful operation. Having a non zero status code could mean that he was successful. It is necessary to mask the high word to determine success.
The pattern is similar to the way Microsoft has documented its Windows API return codes. The major difference is that the code between Windows API and XAMA do not match. In other words, the status codes for XAMA can not be used against Windows status code.
Although there was some overlap between Windows and XAMA, there were several areas that had XAMA status codes. It was necessary to use our own status codes. This is a good strategy to support as many different receivers as possible. Since our status codes are well known codes limit, all our server and receiver code can be separated from the platform, they are executed. MRVC channel exchanges these codes and it would not have to leave it open to unlimited error code pattern. That's probably a little too much detail.
One objective of this position is to include a document for the current API StatusCodes XAMA
This PDF includes all outstanding status codes with hexadecimal values and brief description. Based on a few different events inside and outside Citrix, it became clear that the mapping of the hexadecimal code to an error message is very valuable. Until it is more automated, this table should help to find a match.
The most common errors are related to me 0x1008 and 0x002C. These result in CMP_ERROR_GVCH_NOT_CONNECTED_STATE (0x1008) and CMP_ERROR_CLIENT_DRIVE_UNAVAILABLE (0x002C).
GVCH means Generic Virtual Channel. This error simply means there is no connection to the mobile device using MRVC (Mobile Virtual Channel Receiver). There are a number of probable causes :.
- The mobile receiver version does not support XAMP / XAMA with MRVC
- The session is currently offline
- The rover could support MRVC disabled. (Currently not a problem, but could be in the future)
As for CMP_ERROR_CLIENT_DRIVE_UNAVAILABLE, the most common reason is that the receiver has Android client drive mapping (CDM) off. It is necessary to modify Android receiver parameters for all read access or full SD card. This error should not occur if there is an attempt to take a picture with the API and the CDM is not enabled on both sides. As the default value to enable CDM Receiver off on Android, which is why this error happened so often.
We are currently updating the documentation to better explain the status codes and include the hex values. This update of the online documentation should come in the following weeks, if not sooner.
0 Komentar