Как получить размер (бесплатный, общий) телефонного диска с помощью Nokia API? - PullRequest
Новая
       16

Как получить размер (бесплатный, общий) телефонного диска с помощью Nokia API?

4 голосов
/ 03 января 2009

Я хочу узнать размер телефонного диска. Я использую «Nokia-PC-Connectivity». В отношении API файловой системы я обнаружил в функции CONADifinition CONA_Folder_Info, но эта функция не поддерживает FreeSize и Total Size, но есть CONA_Folder.Info2 и его экземпляр поддерживает эти переменные. .

Но когда я использовал CONA_Folder.Info2 следующим образом: 

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

Я получаю это исключение:

Обнаружена FatalExecutionEngineError Сообщение: среда выполнения обнаружила фатальная ошибка. Адрес ошибки был в 0x7a0ba769, в потоке 0x1278. Код ошибки 0xc0000005. это ошибка может быть ошибкой в ​​CLR или в небезопасные или не проверяемые части кода пользователя. Общие источники этого ошибка включает ошибки маршалинга пользователя для COM-взаимодействие или PInvoke, которые могут повредить стек.

Примечание: я использую программную платформу S60 . Язык приложения - C #.

Для более подробных объяснений, пожалуйста, спросите меня.

Ответы [ 2 ]

1 голос
/ 04 августа 2009

Правильно, что вы получаете исключение при попытке преобразовать данные в буфере в структуру другого типа, чем была изначально создана CONAFileSystem.CONAFindNextFolder.

Вы пытаетесь форсировать структуру данных типа CONADefinitions.CONAPI_FOLDER_INFO в структуру типа CONADefinitions.CONAPI_FOLDER_INFO2. Они почти наверняка имеют разную длину и т. Д., Поэтому крайне маловероятно, что этот метод когда-либо сработает.

Из опыта разработки C ++ для операционной системы Symbian, модель, которую Nokia, вероятно, будет использовать здесь, - это модель, в которой они впоследствии разработали более новую версию API и поэтому создали новую версию структуры CONADefinitions.CONAPI_FOLDER_INFO (т.е. CONADefinitions.CONAPI_FOLDER_INFO2).

Предполагая, что это правильно, есть 3 вероятности:
1) В первой функции есть параметр enum, который указывает, какая версия структуры вывода должна быть создана.
2) Существует новая функция, которая возвращает новую структуру, например, CONAFileSystem.CONAFindFirstFolder2, CONAFileSystem.CONAFindNextFolder2
3) Nokia разработала новую версию внутри страны, но еще не выпустила ее публично.

0 голосов
/ 03 января 2009

Я ничего не знаю об API Nokia, но в целом вижу следующее:

  1. API поиска обычно имеют FindFirst, за которым следуют итерации FindNext и затем FindClose. Я вижу, как вы вызываете FindNext с помощью hFindHandle, но я не вижу, чтобы он где-либо инициализировался (что обычно происходит при вызове FindFirst). Если это ноль, это, безусловно, может привести к нарушению доступа.
  2. Без большого количества вашего цикла while () это выглядит как бесконечный цикл - я полагаю, у вас есть еще где-нибудь FindNext?
  3. Часто вызовы Find требуют, чтобы во входящей структуре была выполнена некоторая инициализация - например, задание элемента длины. Проверьте документацию по API, чтобы узнать, требуется ли это здесь.
  4. Я не вижу, чтобы вы освобождали переменную Buffer или закрывали дескриптор поиска (при условии, что он действителен).
...