В общем пишу маленький плагин.
По сути первый.
Появилась необходимость загрузки настроек из ini-файла. Предполагается, что он должен лежать в той же папке, что и сам плагин.
А вот как корректно узнать путь к этой папке из самого плагина, что-то не пойму.
Спасибо.
Добавлено спустя 2 часа 17 минут:
Извиняюсь. Поторопился. Разобрался.
Найти путь к папке плагина
Модераторы: d-view, Моторокер, Avada, CaptainFlint, Nik
Решение, думаю, привести будет не лишним, т.к. кому-нибудь ещё это тоже может понадобиться.
Вообще, по умолчанию лучше хранить настройки в файлах конфигурации, которые предлагает сам тотал при инициализации плагина (листер-плагинам он сообщается в поле DefaultIniName структуры, передаваемой в функцию ListSetDefaultParams).
Но т.к. многие предпочитают хранить настройики плагинов в папках самих плагинов, опционально можно хранить их там (я в своих плагинах использую файлы конфигурации в папках плагинов, если эти файлы существуют).
Общий способ получения пути к папке любого модуля лежит через получение пути к самому модулю с помощью функции GetModuleFileName, но если для экзешника достаточно передать туда NULL (0), для DLL надо передавать туда hinstDLL, который передаётся в функцию DllMain.
Вообще, по умолчанию лучше хранить настройки в файлах конфигурации, которые предлагает сам тотал при инициализации плагина (листер-плагинам он сообщается в поле DefaultIniName структуры, передаваемой в функцию ListSetDefaultParams).
Но т.к. многие предпочитают хранить настройики плагинов в папках самих плагинов, опционально можно хранить их там (я в своих плагинах использую файлы конфигурации в папках плагинов, если эти файлы существуют).
Общий способ получения пути к папке любого модуля лежит через получение пути к самому модулю с помощью функции GetModuleFileName, но если для экзешника достаточно передать туда NULL (0), для DLL надо передавать туда hinstDLL, который передаётся в функцию DllMain.
Ну если я китаец, который установил TC в папку c:\users\用戶名\...MVV писал(а):...он сообщается в поле DefaultIniName структуры, передаваемой...
что в этом случае вернёт ТС через этот аргумент?
Снова представим, что я китаец.MVV писал(а):...через получение пути к самому модулю с помощью функции GetModuleFileName ...
Получаем UTF-16 путь через GetModuleFileNameW.
А вот дальше то что?
Использовать функцию GetPrivateProfileStringW? Но тогда нужно ini-файл перекодировать в UTF-16.
Китайцы не жаловались на "отвал" плагинов?
-
CaptainFlint
- Сообщения: 6239
- Зарегистрирован: Вт дек 14, 2004 22:34
- Контактная информация:
У китайца, скорее всего, выбрана китайская локаль. Так что там вернётся та же строка в соответствующей кодировке. Гораздо интереснее, что будет, если китаец установит Тотал в папку C:\Программы\… Но таких китайцев, я подозреваю, очень немного.remittor писал(а):Ну если я китаец, который установил TC в папку c:\users\用戶名\...
что в этом случае вернёт ТС через этот аргумент?
Хотя да, с точки зрения Тотала это недоработка. С другой стороны, нет необходимости пользоваться именно ListSetDefaultParams. Есть ещё переменная COMMANDER_INI, из которой можно вычленить каталог расположения INI-файлов.
Ну, во-первых, лично я ничего плохого в UTF-16 в INI-файлах не вижу. Во-вторых, если уж мы все из себя интернациональные, то в любом случае будет глупо ограничиваться поддержкой Юникода исключительно в путях, а содержимое INI при этом держать в кодировке ANSI. А если нам потом понадобится туда какой-то путь записать? Или какую-то другую строку, потенциально содержащую международные символы? Лучше озаботиться этим заранее, чем потом патчить плагин и переконвертировать существующие INI у пользователей.remittor писал(а):Снова представим, что я китаец.
Получаем UTF-16 путь через GetModuleFileNameW.
А вот дальше то что?
Использовать функцию GetPrivateProfileStringW? Но тогда нужно ini-файл перекодировать в UTF-16.
А на самом деле, даже SetPrivateProfileStringW по умолчанию создаёт INI в кодировке ANSI (по крайней мере, у меня получилось именно так), и для Юникода нужно заранее озаботиться созданием этого файла в нужной кодировке.
Почему же, ё-моё, ты нигде не пишешь "ё"?
Что недоработка, согласен, для юникодных версий плагинов следовало сделать эти поля структуры юникодными, или хотя бы считать, что там UTF-8 (но для UTF-8 строки всё равно надо больше места, чем MAX_PATH байт).
Все версии функций для работы с INI прекрасно определяют кодировку файла (ANSI или Unicode) и при необходимости перекодируют данные, т.е. функция GetPrivateProfileStringA так же спокойно читает файл в Unicode, как и функция GetPrivateProfileStringW читает файл в ANSI, то же самое касается и функций записи, как заметил CaptainFlint. Другое дело, что для получения действительно юникодных строк (т.е. строк, содержащих символы, отсутствующие в системной кодовой странице) необходима комбинация файла в Unicode и юникодных версий функций.
Мне кажется, в крайнем случае стоит пытаться использовать конфигурационный файл в папке плагина, а если его там нет - в той же папке, где лежит wincmd.ini (читать %COMMANDER_INI%). Это будет явно лучше, чем хранить настройки в реестре.
Все версии функций для работы с INI прекрасно определяют кодировку файла (ANSI или Unicode) и при необходимости перекодируют данные, т.е. функция GetPrivateProfileStringA так же спокойно читает файл в Unicode, как и функция GetPrivateProfileStringW читает файл в ANSI, то же самое касается и функций записи, как заметил CaptainFlint. Другое дело, что для получения действительно юникодных строк (т.е. строк, содержащих символы, отсутствующие в системной кодовой странице) необходима комбинация файла в Unicode и юникодных версий функций.
Мне кажется, в крайнем случае стоит пытаться использовать конфигурационный файл в папке плагина, а если его там нет - в той же папке, где лежит wincmd.ini (читать %COMMANDER_INI%). Это будет явно лучше, чем хранить настройки в реестре.