Передача имен в FAR_FIND_DATA
Sten
struct FAR_FIND_DATA
{
...
wchar_t *lpwszFileName;
wchar_t *lpwszAlternateFileName;
};
Раньше вместо нее использовалась структура WIN32_FIND_DATA и имя файла
передавалось в массиве cFileName[MAX_PATH]. Теперь же, очевидно чтобы поддержать имена
файлов и пути длиннее MAX_PATH символов. А теперь в структуре появился
указатель lpwszFileName.
Вопрос, как с этим указателем работать? Кто должен и как освобождать
выделенную память?
Скажем, плагин MultiArc экспортирует вот такую функцию:
int WINAPI EXP_NAME(GetFindData)(HANDLE hPlugin,struct PluginPanelItem **pPanelItem,int *pItemsNumber,int OpMode)
Которая возвращает указатель на большой кусок malloc() памяти в котором
последовательно лежат структурки PluginPanelItem. Каждая из этих
структур имеет мембер PluginPanelItem->FindData->lpwszFileName который
должен куда-нибудь указывать.
В случае, если нет соглашения, что тот кто вызывает функцию,
освобождает память под lpwszFileName определенным образом, в данном
случае можно приписать массив имен файлов к концу этого большого блока.
Но это удовольствие еще то..
Далее, .fmt файлы предоставляют плагину MultiArc внутренее вот такой API:
int WINAPI EXP_NAME(GetArcItem)(struct PluginPanelItem *Item,struct ArcItemInfo *Info)
Здесь тоже надо понять как освобождать память
PluginPanelItem->FindData->lpwszFileName, причем, в отличие от случая
выше, если нет соглашений о том как вызывающая подпрограмма должна
освобождать память, то тут вообще без изменения прототипа API не
обойтись. Никакой класс UnicodeString и подсчет ссылкок тут не
помогут.
Так что хочется надеяться что какие-то соглашения есть. Хотя, данное
архитектурное решение, IMHO, с точки зрения портирования старого кода
(да и само по себе) весьма кривовато - убиться можно пока все везде заработает.
vadim yegor0v
on Wed, 28 Nov 2007 22:29:10 +0300 you wrote:
S> Раньше вместо нее использовалась структура WIN32_FIND_DATA и имя файла
S> передавалось в массиве cFileName[MAX_PATH]. Теперь же, очевидно чтобы поддержать имена
S> файлов и пути длиннее MAX_PATH символов. А теперь в структуре появился
S> указатель lpwszFileName.
S> Вопрос, как с этим указателем работать? Кто должен и как освобождать
S> выделенную память?
вообще-то ранше были такие вот поля в PluginPanelItem:
char *Description;
char *Owner;
char **CustomColumnData;
и ведь как-то с ними работали. хелп не пробовал почитать?
--
wbr,
zg
Sten
там ничего полезного не нашлось. Хотя были упоминания о структуре
FAR_FIND_DATA и макросе _FAR_USE_WIN32_FIND_DATA. Но наизусть я доки
не учил. :)
Судя по исходникам надо делать вот так:
pDest->lpwszFileName = _wcsdup (pSrc->strFileName);
Просто, вдруг это от великой лени сделано. Поэтому на всякий случай я
решил здесь уточнить. Но судя по всему кто-то все же потом делает
free().
В общем, в ZIP архив мне удалось зайти. Правда для этого пришлось все
же переписать под юникод zip.fmt. Слишком великие идеологические
изменения, чтобы старые форматные модули без изменений работали. Так
что первоначальная задумка с сохранением их неизменными не удалась.
Но proof of the concept доказан. MultiArc реально портировать под
юникод. Постараюсь в ближайшее время вычистить код и пару оставшихся
багов и подготовить патч. Останется потом только форматные модули
портировать.
vy> hello, Sten!
vy> on Wed, 28 Nov 2007 22:29:10 +0300 you wrote:
S>> Раньше вместо нее использовалась структура WIN32_FIND_DATA и имя файла
S>> передавалось в массиве cFileName[MAX_PATH]. Теперь же, очевидно чтобы поддержать имена
S>> файлов и пути длиннее MAX_PATH символов. А теперь в структуре появился
S>> указатель lpwszFileName.
S>> Вопрос, как с этим указателем работать? Кто должен и как освобождать
S>> выделенную память?
vy> вообще-то ранше были такие вот поля в PluginPanelItem:
vy> char *Description;
vy> char *Owner;
vy> char **CustomColumnData;
vy> и ведь как-то с ними работали. хелп не пробовал почитать?
vy> --
vy> wbr,
vy> zg
vy> --~--~---------~--~----~------------~-------~--~----~
vadim yegor0v
on Wed, 28 Nov 2007 23:36:51 +0300 you wrote:
S> А что под хэлпом подразумевается - каталог docs?
ну ты ж как бы плагин пишешь, под хелпом подразумевается хелп по
написанию плагинов: http://api.farmanager.com/
S> На первый взгляд там там ничего полезного не нашлось.
ну ты ещё в инструкции на стиральную машину поищи.
S> Судя по исходникам надо делать вот так:
S> pDest->lpwszFileName = _wcsdup (pSrc->strFileName);
можно делать как угодно.
--
wbr,
zg
Alex Yaroslavsky
S> Но proof of the concept доказан. MultiArc реально портировать под
S> юникод. Постараюсь в ближайшее время вычистить код и пару оставшихся
S> багов и подготовить патч. Останется потом только форматные модули
S> портировать.
Что то боязнено мне от тебя такие большие патчи принимать, после
прочтения твоих вопросов. Может лучше поучишь АПЙ и пару своих плагинов
напишешь сначала?
--
Bye, => FAR 1.71 build 2297
Alex. => Windows 5.2 build 3790 Service Pack 2, v.4045
Sten
Ну что ж, не хочешь - не принимай. Если проекту не нужна сторонняя
помощь - это дело проекта.
Желания писать свои плагины после того как проделал достаточно большую
работу, а ее заочно отклонили, как-то не возникает.
AY> Hello, Sten!
S>> Но proof of the concept доказан. MultiArc реально портировать под
S>> юникод. Постараюсь в ближайшее время вычистить код и пару оставшихся
S>> багов и подготовить патч. Останется потом только форматные модули
S>> портировать.
AY> Что то боязнено мне от тебя такие большие патчи принимать, после
AY> прочтения твоих вопросов. Может лучше поучишь АПЙ и пару своих плагинов
AY> напишешь сначала?
AY> --
Bye, =>> FAR 1.71 build 2297
AY> Alex. => Windows 5.2 build 3790 Service Pack 2, v.4045
AY> --~--~---------~--~----~------------~-------~--~----~
Alex Yaroslavsky
судя по твоим вопросам, боязнено мне.
Sten
начал знакомство весьма недавно.
В общем, я патч подготовлю - не пропадать же работе. Ты посмотришь,
покритикуешь.
AY> Отклонить можно тока увидев, может там и всё хорошо, но не видя код и
AY> судя по твоим вопросам, боязнено мне.
AY> On Nov 29, 2007 9:44 AM, Sten <ste...@mail.ru> wrote:
>> Hi Alex,
>>
>> Ну что ж, не хочешь - не принимай. Если проекту не нужна сторонняя
>> помощь - это дело проекта.
>>
>> Желания писать свои плагины после того как проделал достаточно большую
>> работу, а ее заочно отклонили, как-то не возникает.
>>
>> AY> Hello, Sten!
>>
>> S>> Но proof of the concept доказан. MultiArc реально портировать под
>> S>> юникод. Постараюсь в ближайшее время вычистить код и пару оставшихся
>> S>> багов и подготовить патч. Останется потом только форматные модули
>> S>> портировать.
>> AY> Что то боязнено мне от тебя такие большие патчи принимать, после
>> AY> прочтения твоих вопросов. Может лучше поучишь АПЙ и пару своих плагинов
>> AY> напишешь сначала?
>>
>> AY> --
>> Bye, =>> FAR 1.71 build 2297
>> AY> Alex. => Windows 5.2 build 3790 Service Pack 2, v.4045
>>
>>
>>
>> AY> >
>>
AY> --~--~---------~--~----~------------~-------~--~----~
Iouri Kharon
четверг, 29 ноября 2007 г., Вы писали:
S> Не бойся, я профессиональный программист. :)
Этим словом много чего называют :)
S> В общем, я патч подготовлю - не пропадать же работе. Ты посмотришь,
S> покритикуешь.
Ты не понял основной проблемы. Если бы было время "смотреть и критиковать" то
никакой сторонней помощи для 1.8 было бы нафиг не надо (и никакого OS бы не
возникло).
То на что тебе "тонко намёкивал" :) Alex,- после твоих вопросов (сиречь
"стиля подхода к задаче") и "исследований" чего и как делать, возникла ситуация
когда присланный патч придётся "тщательно вычитывать". А в таком варианте - свой
сделать дешевле (быстрее).
Ю.
ste...@mail.ru
Вопросы вполне нормальные - такие, которые бы задал любой здравомыслящий
человек,
разбираясь в проблеме. Наоборот, было бы странно, если бы они не
возникли. Частично
они могли бы решиться путем ознакомления с документацией на API - это
да. Но это еще
не повод клеймить мои патчи, и все остальное.
Впрочем, дело хозяйское.
> --~--~---------~--~----~------------~-------~--~----~
>
vadim yegor0v
on Thu, 29 Nov 2007 14:58:05 +0300 you wrote:
sr> Вопросы вполне нормальные - такие, которые бы задал любой здравомыслящий
sr> человек, разбираясь в проблеме. Наоборот, было бы странно, если бы они
sr> не возникли.
так не возникают же. в доках всё есть.
sr> Частично они могли бы решиться путем ознакомления с документацией на
sr> API - это да. Но это еще не повод клеймить мои патчи, и все
sr> остальное.
ну человек, не читающий документацию - зарождает смутные сомнения.
--
wbr,
zg
ste...@mail.ru
Видишь ли, документация не лежит на SVN вместе с плагинами. Я что
получил, с тем и работаю.
Кроме того, предполагалось, что для "тупово" портирования плагина на
UNICODE обильного знания
теории не потребуется. Тут я ошибся - не ожидал что интерфейсы поменяются.
vadim yegor0v
on Thu, 29 Nov 2007 15:28:33 +0300 you wrote:
sr> Видишь ли, документация не лежит на SVN вместе с плагинами.
это по вашему - что?
http://farmanager.com/svn/trunk/enc/enc_rus/meta/exported_functions/freefinddata.html
sr> Кроме того, предполагалось, что для "тупово" портирования плагина на
sr> UNICODE обильного знания теории не потребуется.
профессиональный программист говоришь?
sr> Тут я ошибся - не ожидал что интерфейсы поменяются.
интерфейсы не особо менялись. к трём указателям, которые были,
добавилось два. идеология не изменилась.
--
wbr,
zg
ste...@mail.ru
> sr> Кроме того, предполагалось, что для "тупово" портирования плагина на
> sr> UNICODE обильного знания теории не потребуется.
> профессиональный программист говоришь?
>
случаев, если
стоит задача переписать код под юникод, оставив неизменным функционал,
то аккуратная
замена в нужных местах типов данных, и исправление ругани компилятора
дают на 99% процентов работоспособный код.
vadim yegor0v
on Thu, 29 Nov 2007 16:07:36 +0300 you wrote:
sr> если стоит задача переписать код под юникод, оставив неизменным
sr> функционал
а причём тут фар?
--
wbr,
zg
ste...@mail.ru
> sr> если стоит задача переписать код под юникод, оставив неизменны
> а причём тут фар?
>
одновременно
активно переколбашивают функционал проекта. Хм.. То не Вам меня упрекать в
непрофессиональности.
vadim yegor0v
on Thu, 29 Nov 2007 17:29:29 +0300 you wrote:
>> а причём тут фар?
sr> А притом, что если разработчики FAR переводят проект на юникод, _и_
sr> одновременно активно переколбашивают функционал проекта.
а где, активное переколбашивание функционала? в апи правятся проблемные
места, о которых уже известно давно, но в версиях до 1.80 они не
трогались по причинам бинарной совместимости со старыми плагинами. в
1.80 такого ограничения нет, и логично исправить самое проблемное сразу,
а не дожидаясь времени, когда уникодный фар обрастёт сотней другой
нативных плагинов и менять что-то будет уже поздно.
sr> То не Вам меня упрекать в непрофессиональности.
во-первых, есть такая поговорка: бревно в моём глазу, не отменяет
соринки в вашем.
во-вторых, неспособность не то что бы найти в документации ответы на
простые вопросы, а найти саму документацию, это да, о профессиональном
уровне уже не говорит. это уже об интеллектуальном говорит многое.
--
wbr,
zg
ste...@mail.ru
> а причём тут фар?
> sr> А притом, что если разработчики FAR переводят проект на юникод, _и_
> sr> одновременно активно переколбашивают функционал проекта.
> а где, активное переколбашивание функционала? в апи правятся проблемные
> места, о которых уже известно давно, но в версиях до 1.80 они не
> трогались по причинам бинарной совместимости со старыми плагинами. в
> 1.80 такого ограничения нет, и логично исправить самое проблемное сразу,
> а не дожидаясь времени, когда уникодный фар обрастёт сотней другой
> нативных плагинов и менять что-то будет уже поздно.
>
>
MultiArc ставил задачу портировать его именно с сохранением функционала, и
без серьезных изменений. О чем с самого начала и заявлял.
> sr> То не Вам меня упрекать в непрофессиональности.
> во-первых, есть такая поговорка: бревно в моём глазу, не отменяет
> соринки в вашем.
> во-вторых, неспособность не то что бы найти в документации ответы на
> простые вопросы, а найти саму документацию, это да, о профессиональном
> уровне уже не говорит. это уже об интеллектуальном говорит многое.
>
>
Интеллектуальном, да. Будем считать что ты высказался, повысил самооценку за
счет незнакомого тебе человека.
Беседа уходит в неконструктивное русло. Не вижу смысла продолжать.
vadim yegor0v
on Thu, 29 Nov 2007 18:06:55 +0300 you wrote:
sr> Не знаю, почему ты об основном движке FAR-а тут вспомнил, а я для плагина
sr> MultiArc ставил задачу портировать его именно с сохранением функционала, и
sr> без серьезных изменений. О чем с самого начала и заявлял.
либо ты не умеешь читать, либо с логикой проблемы. речь шла про фар апи,
которое мультиарк использует. про добавление или какую-то правку самого
мультиарка не связанную с переходом на новое апи мной не было сказано ни
слова.
sr> Беседа уходит в неконструктивное русло. Не вижу смысла продолжать.
она была там изначально.
--
wbr,
zg
Iouri Kharon
четверг, 29 ноября 2007 г., Вы писали:
smr> Не знаю, почему ты об основном движке FAR-а тут вспомнил, а я для плагина
smr> MultiArc ставил задачу портировать его именно с сохранением функционала, и
А нужно ли это кому-то (кроме тебя) ты не забыл поинтересоваться перед тем
как "решать поставленную задачу"? Или, может, хотя бы задал вопрос, "а почему
такой употребимый плагин не сделан, когда всякая ерунда..."?
Или, может, ты за него взялся являясь специалистом в методах паковки и от
глубины знаний всех и всяческих глючков (нарушений спецификаций) в существующих
архиваторах, которые он обязан поддерживать? Или была какая-то другая веская
причина?
smr> без серьезных изменений. О чем с самого начала и заявлял.
А здесь не LJ и даже не фидо. Читать "заявления" мало кому интересно,
а уж реагировать на них... Был бы задан вопрос, на него бы ответили
smr> Беседа уходит в неконструктивное русло. Не вижу смысла продолжать.
Она там с самого начала была. В этом русле
Ю.
Alexander Usikov
> Кроме того, предполагалось, что для "тупово" портирования плагина на
> UNICODE обильного знания теории не потребуется.
Может конечно это никому не нужно, но я считаю что в вашем деле может
пригодиться. Ведь лучше жалеть от сделанного, чем
от не сделанного. Прикладываю скрипт, использование которого в 98% без
единой ошибки переводило все мои старые проекты с ascii в unicode.
--
С уважением,
Alexander mailto:relo...@gmail.com
ste...@mail.ru
> Hi stenri!
> четверг, 29 ноября 2007 г., Вы писали:
>
> smr> Не знаю, почему ты об основном движке FAR-а тут вспомнил, а я для плагина
> smr> MultiArc ставил задачу портировать его именно с сохранением функционала, и
> А нужно ли это кому-то (кроме тебя) ты не забыл поинтересоваться перед тем
> как "решать поставленную задачу"? Или, может, хотя бы задал вопрос, "а почему
> такой употребимый плагин не сделан, когда всякая ерунда..."?
> Или, может, ты за него взялся являясь специалистом в методах паковки и от
> глубины знаний всех и всяческих глючков (нарушений спецификаций) в существующих
> архиваторах, которые он обязан поддерживать? Или была какая-то другая веская
> причина?
>
>
предмет "поюзать",
ибо по понятным причинам предпочитаю Open Source решения (про альфа
версию только говорить не надо).
А архивы он не открывает. Собственно потому и решил доделать. Как я
писал, MultiArc "старый
проверенный плагин". Лично у меня с ним никогда проблем не было, и на
нарушения спецификаций в существующих архиваторах, которые он якобы
должен поддерживать я не наталкивался.
Если MultiArc не устраивает, и в FAR 1.8 никому не нужен - не вопрос.
Развивайте NewArc дальше.
Я делаю то, чего лично мне на данный момент не хватает, ибо мне не
сложно. В этом вся прелесть
Open Source. А вот писать аналог с нуля - уже задача совсем другого
плана. В Mozilla после 4.0 тоже
выкинули весь код, и переписали заново. Где он сейчас?
P.S. Насчет "специалиста в методах паковки" - я диссер по методам
фрактального сжатия изображений
защитил в свое время. Может и не совсем о глюках в современных
архиваторах, но с темой сжатия без
потерь, в том числе, знаком немного.
ste...@mail.ru
Спасибо за скрипт. Идея понятна - автоматизация замены руками char ->
TCHAR и пр.
Но все же, м.. предпочитаю ручками. :) Правя те места, на которые
ругается компилятор.
А то можно такого поназаменять.. Хотя в некоторых случаях - тоже вариант.
В MultiArc основная проблема была не заменить типы, и вызовы функций - а
учесть
специфику изменений в некоторых структурах, доступных плагинам FAR.
Это не автоматизируешь.. :)
--
Станислав
> Здравствуйте, stenri.
>
>
>> Кроме того, предполагалось, что для "тупово" портирования плагина на
>> UNICODE обильного знания теории не потребуется.
>>
> Может конечно это никому не нужно, но я считаю что в вашем деле может
> пригодиться. Ведь лучше жалеть от сделанного, чем
> от не сделанного. Прикладываю скрипт, использование которого в 98% без
> единой ошибки переводило все мои старые проекты с ascii в unicode..
>
>
>
Iouri Kharon
четверг, 29 ноября 2007 г., Вы писали:
smr> P.S. Насчет "специалиста в методах паковки" - я диссер по методам
smr> фрактального сжатия изображений защитил в свое время.
Не спору ради, а информации для - по моему 35летнему опыту работы в области
люди _либо_ могут/умеют/хотят писать статьи/книги/диссертации (вещь, на самом-то
деле вполне нужная. иногда :), _либо_ код. Одновременно - "не встречается в природе".
Поелику математика (даже алгоритмическая) и кодирование требуют строго
противоположного менталитета.
smr> Может и не совсем о глюках в современных архиваторах, но с темой сжатия без
Совсем не. В смысле "и близко не лежало" :)
smr> потерь, в том числе, знаком немного.
Так работая с MA (или его аналогами) задача же не свой "шибко хороший"
архиватор написать, а поддержать кучу плохих существующих. Как они пакуют при
этом вопрос 115й. А вот как _недокументированно_ (а иногда и в нарушение своей
же собственной документации), используют всякие служебные поля в хидерах -
наоборот.
Ю.
WARP ItSelf
> Так работая с MA (или его аналогами) задача же не свой "шибко хороший"
> архиватор написать, а поддержать кучу плохих существующих. Как они пакуют при
> этом вопрос 115й. А вот как _недокументированно_ (а иногда и в нарушение своей
> же собственной документации), используют всякие служебные поля в хидерах -
> наоборот.
Я очень извиняюсь, но право, вам сюда - forum.farmanager.com
ste...@mail.ru
> smr> P.S. Насчет "специалиста в методах паковки" - я диссер по методам
> smr> фрактального сжатия изображений защитил в свое время.
> Не спору ради, а информации для - по моему 35летнему опыту работы в области
> люди _либо_ могут/умеют/хотят писать статьи/книги/диссертации (вещь, на самом-то
> деле вполне нужная. иногда :), _либо_ код. Одновременно - "не встречается в природе".
> Поелику математика (даже алгоритмическая) и кодирование требуют строго
> противоположного менталитета.
>
>
математики требуются
совершенно разные.
Я больше практик. :) Но диссер все же осилил. ;)