2009-11-20 2 views
0

J'ai une classe MFC dérivée de CStdioFile déclarée comme suitHowto Traquer la corruption variables

// Datafile.h 
class CDataFile : public CStdioFile 
{ 
public: 
CDataFile(void); 
~CDataFile(void); 

int OpenFile(LPCWSTR FileName); 
} 

Après ma fonction OpenFile est appelée la variable FileName est corrompu.

int CDataFile::OpenFile(LPCWSTR FileName) 
    { 

m_OpenFlags = CFile::modeNoTruncate | CFile::modeReadWrite; 

// Before open. FileName = "c:\afile.txt" 

    if (!Open(FileName, m_OpenFlags, NULL)) 

     { 
      return GetLastError(); 
     } 

//After open. FileName = ""ﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮﻮވĚᗸ÷ᘸ÷㼠碞­" 

// other stuff 
} 

} 

Mais si je change le FileName

WCHAR FileName[] = _T("c:\\afile.txt"); 

Avant d'ouvrir le fichier la variable Nom du fichier reste intacte. J'ai déjà vu ce comportement avec le MFC/Winapi et j'ai toujours travaillé autour de ça en utilisant des tableaux de caractères au lieu de LPCWSTR ou CString. Pourquoi cela arrive-t-il? et quel est le meilleur moyen de localiser des problèmes comme celui-ci avec le débogueur VS. La corruption semble se produire ici dans le fichier MFC Filecore.cpp

if (!CFile::Open(lpszFileName, (nOpenFlags & ~typeText), pException)) 
    return FALSE; 
+1

Le (http://msdn.microsoft.com/en-us/library/hwbccf8z.aspx) indique qu'il a besoin LPCTSTR pas LPCWSTR (char normal par chaîne large). Peut-être que c'est le problème? –

+0

Je ne pense pas "typedef LPCWSTR LPCTSTR;" – Canacourse

Répondre

2

Jetez un oeil à l'aide d'un data breakpoint (également connu sous le nom d'un point d'arrêt du matériel.) Vous pouvez casser lorsque la mémoire est modifiée.