IC7K писал(а):если разработчик лучше знает как надо, то почему бы ему не сделать готовый шаблон? к чему эти разговоры?
Весь смысл данного раздела как раз в том, что разработчик(и) этой конкретной программы советуются с другими, в том числе тоже разработчиками, в том числе и такими, для которых разработка ПО - не хобби, а профессия. Поэтому понятие "лучше знает" здесь неприменимо, а применим опыт, чаще всего личный.
Тема о плагинах вообще - тому подтверждение.
Ради интереса сходите туда и поглядите насчёт того, когда и кем впервые озвучена идея полного исключения гуя из плагинов. В своё время я с этим так жёстко наелся, что исключения из этого правила до сих пор помню, хотя с того проекта минуло уже больше 10 лет. Там было сильное "связывание" между компонентами системы, и в итоге при отсутствии ошибок (с точки зрения ТЗ) в среднем раз в полгода команда из десятка кодеров просто переписывала с нуля интерфейс взаимодействия хоста и его "клиентов". Минимум четырежды. Но там у народа было дофига времени на такие дела, чего не скажешь о здешних разработчиках.
А сейчас мне тут этим пенять - это даже не смешно, это явный признак того, что оппонент даже не захотел попробовать разобраться.
А разбираться есть в чём. Дело в том, что в соответствии с концепцией взаимодействия хоста-плагина для любого плагина, хост понятия не имеет, что там плагин напридумывал делать, какие у него настройки, какие иконки надо рисовать, и т.п. В свою очередь плагин не имеет права ничего заранее предполагать по поводу взаимодействия хоста и юзера (например, юзер отключил хинты), а также конкретной реализации хоста за пределами утверждённого интерфейса взаимодействия (может хост будет не на экране рисовать самолётики, а в виде таблицы их выдавать рядом со своими данными GPS). В этом смысле если в новой версии Delphi пропадёт Canvas, то не должна возникать необходимость переписывания плагинов. Если коротко - плагин знает ЧТО рисовать, а хост - КАК рисовать. Любые отходы от этого правила - потенциальная задница с необходимостью переписывания кода хоста и плагина.
В этом смысле предложенный ранее список
function GetLonLat: TDoublePoint;
function GetBitmapSize: TPoint;
function GetFixedInBitmap: TPoint;
function GetPictureBits: PColor32;
function GetHintText: WideString;
function GetInfoHTML: WideString;
это и есть обобщённый ответ от плагина хосту на вопрос, что именно надо рисовать.
А так как инициатором рисования (точнее в общем случае - обновления информации) одного конретного элемента может быть как плагин, так и хост, то совершенно очевидна необходимость выделения рисования в отдельную процедуру с возможностью её прямого вызова.
Следующий тезис до банального прост. Так как итератор по сути абстрактен, для его реализации через интерфейс элемента потребуется либо прямое приведение типов интерфейсов фактически через тот же указатель, либо наследование интерфейсов (всё же язык-то используется строго типизированный). Первый способ идиотичен своей избыточностью. Второй идиотичен своей избыточностью вдвойне, кроме того совершенно не факт, что любые 2 интерфейса одного объекта могут быть получены на стороне хоста друг из друга через QueryInterface, полагаться на это нельзя. Но что самое плохое - оба способа очевидно не из разряда "написал и забыл".
Вот и выходит, что вариантов-то сделать просто и железобетонно - не так уж и много. К написанному могу добавить только, что внутри плагина вызов Show(obj) оборачивается в примитив синхронизации (например, критическую секцию или мьютекс или ещё какой изврат в соответствии с потребностью, так как в соответствии с предпосылкой, данные у нас валятся из стороннего источника в отдельном потоке или даже нескольких потоках) и перенаправляется в хост, при этом Obj уже "разыменовывается" и в процедуру ShowMePlease отдаётся живой реальный интерфейс объекта. Раньше чем в этот момент он (рисовабельный интерфейс конкретного рисовабельного элемента) вообще не требуется. В итоге мухи отделены от котлет, данные от отображения, а итератор как дедушка Ленин вечно живой.
