2010-06-29 9 views
3

Dans mon composant COM j'ai besoin de traduire toutes les erreurs dans les valeurs HRESULT les plus appropriées possibles. Actuellement, si j'appelle une méthode d'interface RPC (j'appelle un stub généré par MIDL qui à son tour appelle NdrClientCall2()) et l'appel échoue, je renvoie E_FAIL ce qui n'est pas très pratique.Comment traduire RPC_STATUS en HRESULT?

Il y a ce qu'on appelle facility in HRESULT. Puis-je l'utiliser?

J'ai essayé de faire ce qui suit:

HRESULT RpcStatusToHresult(RPC_STATUS status) 
{ 
    if(status <= 0) { 
     return status; 
    } 
    return (status & 0x0000FFFF) | (FACILITY_RPC << 16) | 0x80000000; 
} 

Est-ce que cela se traduit correctement RPC_STATUS à HRESULT significatifs s?

Répondre

3

Votre RpcStatusToHresult (statut) est équivalent à MAKE_HRESULT (1, FACILITY_RPC, statut). HRESULT_FROM_WIN32 (status) est équivalent à MAKE_HRESULT (1, FACILITY_WIN32, status). J'ai, comme vous, supposé que le premier serait correct, mais en pratique, au moins en ce qui concerne l'obtention d'un message d'erreur correct de FormatMessage(), ce dernier est ce qui fonctionne réellement.

2

FWIW, qui ressemble le même que HRESULT_FROM_WIN32

+0

Dans quel contexte l'utilisez-vous? Pour le mode utilisateur, vous devriez avoir 'HRESULT_FROM_WIN32', mais pour le mode noyau, la disposition des deux devrait être fondamentalement identique à' NTSTATUS' qui à son tour a une disposition identique à 'HRESULT'. Cependant, je pense qu'il n'y a pratiquement aucun moyen pour nous, les gens normaux, d'utiliser la version en mode noyau, donc la solution de sam ira bien. – 0xC0000022L

+1

Oh, et il y a quelques exceptions RPC qui ne seront pas mappées correctement avec cette macro FYI. C'est la raison pour laquelle je comprends pourquoi l'équipe Windows RPC n'a pas de HRESULT_FROM_RPCSTATUS(), ce qui signifie qu'elle ne produira pas toujours des résultats corrects, donc ils n'en fournissent pas dans le SDK quelque part. –