#include <vcclr.h>
String ^ const path = "c:\\path\\name";
String ^ const filename = "filename.ext";
String ^ filepath = System::IO::Path::Combine(path, filename);
pin_ptr<const wchar_t> string_pointer = PtrToStringChars(filepath);
конвертирование данных
Народ, помогите конвертировать данные :)
из String^ в LPCWSTR. требуется в следующем контексте:
String^ CurrentPath = Environment::CurrentDirectory;
LPCWSTR szFile = конвертировать CurrentPath + название файла;
помогите кто че знает, найти нигде не могу.
если тоже затруднение, то может подскажите как подругому получить текущую директорию для функций API. заранее спасибо
С++, API, Visual Studio 2008
из String^ в LPCWSTR. требуется в следующем контексте:
String^ CurrentPath = Environment::CurrentDirectory;
LPCWSTR szFile = конвертировать CurrentPath + название файла;
помогите кто че знает, найти нигде не могу.
если тоже затруднение, то может подскажите как подругому получить текущую директорию для функций API. заранее спасибо
С++, API, Visual Studio 2008
Цитата: PIOK3AK
Народ, помогите конвертировать данные :)
из String^ в LPCWSTR. требуется в следующем контексте:
String^ CurrentPath = Environment::CurrentDirectory;
LPCWSTR szFile = конвертировать CurrentPath + название файла;
помогите кто че знает, найти нигде не могу.
если тоже затруднение, то может подскажите как подругому получить текущую директорию для функций API. заранее спасибо
С++, API, Visual Studio 2008
из String^ в LPCWSTR. требуется в следующем контексте:
String^ CurrentPath = Environment::CurrentDirectory;
LPCWSTR szFile = конвертировать CurrentPath + название файла;
помогите кто че знает, найти нигде не могу.
если тоже затруднение, то может подскажите как подругому получить текущую директорию для функций API. заранее спасибо
С++, API, Visual Studio 2008
да и к тому же смысл в дотНет использовать винапи? все необходимые операции в вышеупомянутом уже реализованы в своих библиотеках классов!
а если уж на то пошло воспользоваться винапишными GetCurrentDirectory и SetCurrentDirectori ни как(мог ошибиться в названии функции, редко ими пользуюсь, так что посмотри в мздн)?
использую WinAPI в дотнет, так как многое делается проще через АПИ, при помощи API я захват видео написал (к примеру), там везде указатели на unmanage type, поэтому требовался перевод некоторых фундаментальных типов.
курент патх очень удобно было использовать. к тому же заинтересовал перевод по типам.
Апишными геткурент и т.д. попробовал. разобрался.
Der Meister, спасибо за интересный способ, немного не то, но можно использовать.
дошел до вот этого (может попроще будет) без использования курентдиректори при открытии файла:
LPCWSTR szFile = (LPCWSTR) (Marshal::StringToCoTaskMemAuto(openFileDialog1->FileName)).ToInt32();
подобный способ через Marshal можно использовать для других переводов.
курент патх очень удобно было использовать. к тому же заинтересовал перевод по типам.
Апишными геткурент и т.д. попробовал. разобрался.
Der Meister, спасибо за интересный способ, немного не то, но можно использовать.
дошел до вот этого (может попроще будет) без использования курентдиректори при открытии файла:
LPCWSTR szFile = (LPCWSTR) (Marshal::StringToCoTaskMemAuto(openFileDialog1->FileName)).ToInt32();
подобный способ через Marshal можно использовать для других переводов.
Цитата: PIOK3AK
многое делается проще через АПИ
Позволю несогласиться с этим утверждением. Иначе ООП был бы ненужен. Но, не спорю, что в контексте вашей задачи видеозахвата WinAPI вполне подходит в качестве инструмента.
Цитата: PIOK3AK
LPCWSTR szFile = (LPCWSTR) (Marshal::StringToCoTaskMemAuto(openFileDialog1->FileName)).ToInt32();
подобный способ через Marshal можно использовать для других переводов.
подобный способ через Marshal можно использовать для других переводов.
Не самый быстрый способ - он приводит к копированию строки в отдельную область памяти + некрасивое приведение типов (число к указателю). Потом еще нужно париться об освобождении её методом FreeCoTaskMem. pin_prt< T > всеж удобнее - он только поднимает бит "неперемещаемости" CLR объекта и автоматически его сбрасывает.
hardcase, спасибо за разъяснения, пару вещей правда не понял
1)о выводе памяти я подумал, но но разве уборщик мусора за этим не следит?
2)"некрасивое приведение типов" - ?
3)"он приводит к копированию строки в отдельную область памяти" - так ведь это и надо для типа LPCWSTR, или я ошибаюсь?
Pin_ptr - даёт возможность получить unmanaged pointer на кусок managed памяти, разве Маршализация этого не дает? или дает как-то подругому?
просвещайте, я только учусь.:D
почитал про pin_ptr, стал использовать их.
[COLOR="DarkOrange"]еще может другая задача, как обратить типы назад (LPCWSTR -> String^)?[/COLOR]
да, и спасибо что спокойно реагируете на одни и возможно теже вопросы :)) из месяца в месяц, значит тема животрепещущая, а уделено этому вопросу мало внимания в книгах и понятным языком не разъяснено в МСДН.
1)о выводе памяти я подумал, но но разве уборщик мусора за этим не следит?
2)"некрасивое приведение типов" - ?
3)"он приводит к копированию строки в отдельную область памяти" - так ведь это и надо для типа LPCWSTR, или я ошибаюсь?
Pin_ptr - даёт возможность получить unmanaged pointer на кусок managed памяти, разве Маршализация этого не дает? или дает как-то подругому?
просвещайте, я только учусь.:D
почитал про pin_ptr, стал использовать их.
[COLOR="DarkOrange"]еще может другая задача, как обратить типы назад (LPCWSTR -> String^)?[/COLOR]
да, и спасибо что спокойно реагируете на одни и возможно теже вопросы :)) из месяца в месяц, значит тема животрепещущая, а уделено этому вопросу мало внимания в книгах и понятным языком не разъяснено в МСДН.
Цитата: PIOK3AK
1)о выводе памяти я подумал, но но разве уборщик мусора за этим не следит?
StringToCoTaskMemAuto выделяет память в неуправляемой куче, а она живет по стандартным законам: выделил память - вернул память.
Цитата: PIOK3AK
2)"некрасивое приведение типов" - ?
Не очень здорово приводить IntPtr в System.Int32 - такой "указатель" не будет работать на x64 системах. IntPtr обычно используется в явном виде при передачи указателей неуправляемому коду.
Цитата: PIOK3AK
3)"он приводит к копированию строки в отдельную область памяти" - так ведь это и надо для типа LPCWSTR, или я ошибаюсь?
Для типа это совершенно не обязательно. Это зависит от логики работы с этой строкой, например, StringToCoTaskMemAuto может быть полезен в случаях с асинхронным взаимодействием, когда реальный доступ к данным (строке) будет происходить в неуправляемом коде значительно позже фактического вызова (неуправляемая нитка стартовала к примеру). Для синхронных вызовов использовать pin_ptr значительно проще, в C# его аналогом является конструкция fixed. pin_ptr получает фактический указатель на объект в управляемой куче. Так как GC может перемещать объекты в памяти, pin_ptr обеспечивает временную фиксацию объекта в куче, тем самым указатель будет корректным на протяжении всей жизни экземпляра pin_ptr.
Цитата: PIOK3AK
[COLOR=DarkOrange]еще может другая задача, как обратить типы назад (LPCWSTR -> String^)?[/COLOR]
Значение LPCWSTR привести к указателю на wchar_t, далее его передать в конструктор System.String. Как вариант - скормить указатель Marshal::PtrToStringAuto или Marshal::PtrToStringUni.
Цитата: PIOK3AK
этому вопросу мало внимания в книгах и понятным языком не разъяснено в МСДН.
Тут лучше Рихтера читать.
все, спасибо, все понятно, проглотил :)))