Comment obtenir la taille (gratuite, totale) du lecteur de téléphone à l'aide de l'API Nokia?

Question

Je souhaite connaître la taille du lecteur de téléphone. J'utilise "Nokia-PC-Connectivity", et en ce qui concerne l'API de système de fichiers que j'ai trouvée dans la fonction CONADifinition appelée CONA_Folder_Info, mais cette fonction ne prend pas en charge FreeSize et Total Size, mais CONA_Folder.Info2 et son instance prennent en charge ces derniers. variables.

Mais quand j'ai utilisé CONA_Folder.Info2 comme suit:

CONADefinitions.CONAPI_FOLDER_INFO2 FolderInfo;
int iResult = 0;// Allocate memory for buffer
IntPtr Buffer = Marshal.AllocHGlobal(Marshal.SizeOf(typeof(CONADefinitions.CONAPI_FOLDER_INFO2)));                      
iResult = CONAFileSystem.CONAFindNextFolder(hFindHandle, Buffer);
while (iResult == PCCSErrors.CONA_OK )
{
  FolderInfo = (CONADefinitions.CONAPI_FOLDER_INFO2)Marshal.PtrToStructure(Buffer,    typeof(CONADefinitions.CONAPI_FOLDER_INFO2));
  if (FolderInfo.pstrName[0].ToString() != "C" && level == 0) 
  {
  }

Je reçois cette exception:

  

FatalExecutionEngineError a été détecté.   Message: Le moteur d'exécution a rencontré un   erreur fatale. L'adresse de l'erreur   était à 0x7a0ba769, sur le thread 0x1278.   Le code d'erreur est 0xc0000005. Ce   erreur peut être un bug dans le CLR ou dans   les parties dangereuses ou non vérifiables   de code d'utilisateur. Sources communes de cette   bug inclure les erreurs de marshaling utilisateur pour   COM-interop ou PInvoke, ce qui peut   corrompre la pile.

Remarque: j'utilise la la plate-forme logicielle S60 . Le langage d’application est C #.

Pour plus d'explications, n'hésitez pas à me demander.

Answer 1

Il est correct que vous obteniez l'exception lorsque vous essayez de convertir les données du tampon en un type de structure différent de celui créé à l'origine par CONAFileSystem.CONAFindNextFolder.

Vous essayez de forcer une structure de données de type CONADefinitions.CONAPI_FOLDER_INFO dans une structure de type CONADefinitions.CONAPI_FOLDER_INFO2. Ils ont presque certainement des longueurs différentes, etc. Il est donc très peu probable que cette méthode fonctionne.

Fort de son expérience en développement C ++ sur le système d'exploitation Symbian, le modèle utilisé par Nokia est celui qui a développé une version plus récente de l'API et créé une nouvelle version de la structure CONADefinitions.CONAPI_FOLDER_INFO (c'est-à-dire CONADefinitions.CONAPI_FOLDER_INFO2).

En supposant que cela soit correct, il existe 3 probabilités:
1) Il existe un paramètre enum à la première fonction qui spécifie quelle version de la structure en sortie doit être créée.
2) Une nouvelle fonction renvoie la nouvelle structure, par exemple. CONAFileSystem.CONAFindFirstFolder2, CONAFileSystem.CONAFindNextFolder2
3) Nokia a développé la nouvelle version en interne, mais ne l’a pas encore publiée.

Answer 2

Je ne connais rien de l'API Nokia, mais en général, je vois ce qui suit:

1. Les API de recherche ont généralement une recherche FindFirst, suivie des itérations de FindNext puis de FindClose. Je vous vois appeler FindNext avec hFindHandle, mais je ne le vois pas être initialisé nulle part (ce qui se produit généralement dans un appel FindFirst). Si la valeur est zéro, cela pourrait certainement donner une violation d'accès.
2. Sans plus de votre boucle while (), cela ressemble à une boucle sans fin - je suppose que vous avez un autre FindNext quelque part?
3. Souvent, les appels de recherche nécessitent une initialisation de la structure entrante, comme pour définir un membre de longueur. Consultez la documentation de votre API pour savoir si cela est nécessaire ici.
4. Je ne vous vois pas libérer votre variable Buffer ni fermer le handle de recherche (en supposant que celle-ci soit valide).