Come ottenere le dimensioni (gratuite, totali) del telefono utilizzando l'API Nokia?

Question

Voglio ottenere le dimensioni dell'unità del telefono. Sto usando " Nokia-PC-Connectivity "., E rispetto all'API del file system ho trovato sulla funzione CONADifinition chiamata CONA_Folder_Info ma questa funzione non supporta FreeSize e Total Size ma c'è CONA_Folder.Info2 e la sua istanza supporta questi variabili.

Ma quando ho usato CONA_Folder.Info2 come segue:

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) 
  {
  }

Ottengo questa eccezione:

  

È stato rilevato FatalExecutionEngineError   Messaggio: il runtime ha rilevato a   errore fatale. L'indirizzo dell'errore   era a 0x7a0ba769, sul thread 0x1278.   Il codice di errore è 0xc0000005. Questo   l'errore può essere un bug nel CLR o in   le porzioni non sicure o non verificabili   del codice utente. Fonti comuni di questo   bug include errori di marshalling dell'utente per   Interoperabilità COM o PInvoke, che può   corrotto lo stack.

Nota: utilizzo la piattaforma software S60 . Il linguaggio dell'applicazione è C #.

Per ulteriori spiegazioni, chiedimi.

Answer 1

È corretto ottenere l'eccezione quando si tenta di convertire i dati nel buffer in un tipo di struttura diverso da quello originariamente creato da CONAFileSystem.CONAFindNextFolder.

Stai tentando di forzare una struttura di dati di tipo CONADefinitions.CONAPI_FOLDER_INFO in una struttura di tipo CONADefinitions.CONAPI_FOLDER_INFO2. Hanno quasi certamente lunghezze diverse e così via, quindi è estremamente improbabile che questo metodo funzioni mai.

Dall'esperienza con lo sviluppo di C ++ sul sistema operativo Symbian, il modello che Nokia utilizzerà probabilmente qui è quello in cui hanno successivamente sviluppato una versione più recente dell'API e quindi hanno creato una versione più recente della struttura CONADefinitions.CONAPI_FOLDER_INFO (ovvero CONADefinitions.CONAPI_FOLDER_INFO2).

Supponendo che ciò sia corretto, ci sono 3 probabilità:
1) Esiste un parametro enum per la prima funzione che specifica quale versione della struttura di output deve essere creata.
2) Esiste una nuova funzione che restituisce la nuova struttura, ad es. CONAFileSystem.CONAFindFirstFolder2, CONAFileSystem.CONAFindNextFolder2
3) Nokia ha sviluppato internamente la nuova versione ma non l'ha ancora rilasciata pubblicamente.

Answer 2

Non so nulla dell'API Nokia, ma in generale vedo quanto segue:

1. Le API Trova di solito hanno un FindFirst, seguito dalle iterazioni di FindNext e quindi da FindClose. Vedo che chiami FindNext con hFindHandle, ma non vedo che venga inizializzato da nessuna parte (cosa che di solito accade in una chiamata FindFirst). Se questo è zero, ciò potrebbe certamente dare una violazione di accesso.
2. Senza più del tuo ciclo while () sembra un ciclo infinito - suppongo che tu abbia un altro FindNext da qualche parte?
3. Spesso Trova le chiamate richiedono che l'inizializzazione della struttura in entrata venga eseguita, come l'impostazione di un membro lunghezza. Controlla i tuoi documenti API per vedere se è richiesto qui.
4. Non ti vedo liberare la variabile Buffer o chiudere l'handle find (supponendo che sia valido).