pin_ptr un vide natif * aide

Question

La configuration

J'ai une API PDF qui a une fonction native qui est définie ci-dessous.

typdef void* PDF_DOCUMENT;
unsigned long PDF_GetMetaText(PDF_DOCUMENT document,
                              const char tag, 
                              void* buffer, 
                              unsigned long bufferlen)

//Calling it "natively" in C++/CLI function to get the PDF Creator tag
WCHAR result[32];
void* pdoc = PDF_LoadDoc("C:\test.pdf");
int numChars = PDF_GetMetaText(pdoc, "Creator", result, 32);
PDF_CloseDoc(pdoc);

si j'appelle le code ci-dessus dans mon C ++ / CLI fonction enveloppe, elle retourne la chaîne correcte mais jette un AccessViolationException quand je l'appelle PDF_CloseDoc. WOOPS. J'ai oublié de pin_ptr le pointeur du document.

Le problème

Quand je pin_ptr pdoc, je peux appeler avec succès ces fonctions natives, mais le tampon ne contient plus ma chaîne lors du retour PDF_GetMetaText.

String^ Wrapper::GetCreator(String^ filename)
{
   WCHAR buffer[32];
   void *pdoc = PDF_LoadDoc(SystemStringToCStr(filename));
   pin_ptr<void*> p = &pdoc; //added
   int numPages = PDF_GetMetaText(p, "Creator", buffer, 32);
   PDF_CloseDocument(p); //doesnt crash, but at this line buffer is an empty string

   return gcnew String(buffer);
}

J'ai aussi essayé tampon épingler [0], mais qui provoque une exception accessviolation à GetMetaText.

La question

Je ne peux pas dire ce qui se passe dans GetMetaText, donc je ne suis pas sûr de ce qui happing à pdoc. Toute suggestion au code ci-dessus?

Answer 1

Cela ne fait aucun sens. Vous ne pouvez épingler des objets gérés, la valeur de retour de PDF_LoadDoc () ne vous regarde pas comme un objet géré à moi. Même chose pour résultat , il est pas un array<WCHAR> géré, juste un tableau C vanilles qui obtient alloué sur le cadre de la pile. Malheureusement, pin_ptr <> ne se plaint pas à ce sujet.

Résultat tableau ne pouvait se « vide » si le code est piétinant le cadre de la pile. Que vous pouvez diagnostiquer en mettant un point d'arrêt de données sur le premier élément. FWIW, SystemStringToCStr () ressemble à un candidat. Cela ne peut pas fonctionner sans relâcher le tampon pour la part de la chaîne native. Un autre candidat est les déclarations de fonctions API PDF. Faites attention à la valeur du registre ESP et assurez-vous qu'il ne change pas. Si elle le fait, la pile est d'obtenir déséquilibrés parce que vous ne disposez pas de la convention d'appel appropriée. Ce qui est généralement __stdcall pour les exportations DLL.