View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001764 | Wishes | Plugins API | public | 2011-05-08 15:28 | 2013-02-03 00:34 |
Reporter | Maximus | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Product Version | 3.0 | ||||
Summary | 0001764: Добавить флагов в PLUGIN_FLAGS | ||||
Description | При написании враппера возникла "неприятность". Загрузчик "старых" плагинов должен экспортить все возможные функции (например ProcessDialogEventW, ProcessEditorEventW, ProcessEditorInputW, и т.п.) т.к. плодить кучу загрузчиков с разным набором экспортируемых функций под разные плагины смысла мало... Но что получается, Фар при наступлении события (например открытие диалога) начинает загружать вообще все плагины, экспортирующие данную функцию (в моем случае, все плагины, работающие через Wrapper). Хотя реально, "старый" плагин эту функцию не экспортирует. Хотелось бы иметь возможность сказать фару в GetPluginInfoW что на самом деле плагину не интересны некоторые события (например флагами PKF_SKIPDIALOGEVENTS, PKF_SKIPEDITOREVENTS, PKF_SKIPVIEWEREVENTS). PS. На самом деле, может возникнуть ситуация, когда юзер через настройку плагина (если он такое позволит) захочет "отключить" функциональность обработки событий, чтобы исключить лишние загрузки dll-ек. | ||||
Tags | No tags attached. | ||||
Build | |||||
|
А если так? Plugin.hpp: typedef unsigned __int64 PLUGINEXPORTS; static const PLUGINEXPORTS E_NONE = 0 E_ANALYSE = 0x1ULL, E_CLOSEPANEL = 0x2ULL, E_COMPARE = 0x4ULL, ... E_ALL = 0xffffffffffffffffULL; struct GlobalInfo { size_t StructSize; struct VersionInfo MinFarVersion; struct VersionInfo Version; GUID Guid; const wchar_t *Title; const wchar_t *Description; const wchar_t *Author; PLUGINEXPORTS Exports; }; PluginW.hpp: bool HasSetStartupInfo() { return (Exports&E_SETSTARTUPINFO) && (pSetStartupInfoW!=nullptr); } |
|
с этим есть проблемы 1. По большому счёту это должно быть динамичным - т.е. плагин может убрать/добавить "экспорт" во время работы. Т.е. лучше всего убрать все экспорты и ввести HandlerControl(RegisterHandler, ProcessEventHandler, function_pointer). 2. Чё делать с кэшом плагинов, ибо такое как бы уже и не за кэшируешь? |
|
Если PLUGINEXPORTS - было бы удобнее (наверное) сделать отрицания, типа E_NO_COMPARE. Ну, или E_ALL = 0. В смысле, чтобы разработчику не беспокоиться дополнительно о включении флагов. Но это не принципиально. HandlerControl(RegisterHandler, ProcessEventHandler, function_pointer) кажется в самый раз, более удачный вариант. Например, в "универсальном" плагине conemu мне приходится в DllMain переопределять экспорт ExitFARW, ибо в тройке параметры поменялись. Только, если в плагине есть экспорт, то он не обязан звать HandlerControl для регистрации? На счет "не за кэшируешь" - а почему собственно? Подмена экспортов в SetStartupInfoW - в самый раз. То есть при загрузке плагина фар зовет списком GetProcAddress и сразу SetStartupInfoW. После этого у фара будет "рабочий" набор экспортов плагина. Его можно кешировать. Все, набор экспортов уже "просто так" не поменяется. Это возможно только после действий пользователя (например открытие диалога настроек плагина). Так фар может сразу кешировать новый набор? Кстати, еще вариант. Плагин может экспортировать FARPROC GetProcAddress(LPCSTR asFuncName); Ее можно звать сразу, без SetStartupInfoW. Хотя не, плагин может отдавать разные экспорты, в зависимости от версии фара. А ее корректнее всего получать в SetStartupInfoW |