Опрос по реализации системы команд в программе

[Sharfik]

Т.е. для вызовы функций ты пишешь нечто вроде такого: 1234567879^. Или ты пишешь название функции, а компилятор за тебя подставляет адрес?

Функция ищется программой по имени, это да и возвращается ее адрес средствами предусмотренными в языке. Но компилятор ничего не может подставлять, потому что он это все выполняется уже в скомпилированной программе.

[zub]

>>Т.е. для вызовы функций ты пишешь нечто вроде такого: 1234567879^. Или ты пишешь название функции, а компилятор за тебя подставляет адрес?
Автор имеет ввиду динамическую линковку, не статическую. Вы говорите про статическую

[Дож]

отображение название->функция

Это отображение возникает при экспорте функций из DLL. Причем совместимо с проверкой компилятора. Мне непонятно зачем нужно реализовывать этот простой механизм таким странным способом.

Чтобы плагин B при получении функции a плагина A использовал предусмотренный программой механизм, а не самостоятельно перебирал системные хендлеры динамических библиотек и искал системным вызовом GetProcAddress функцию a.

[stanilar]

Автор имеет ввиду динамическую линковку, не статическую.

Спасибо, вот теперь все понял. Наверно праздники сказались.

Но все равно, думаю что общепринято оборачивать вызовы в плагинах в привычный вид функций. Хоть при статической, хоть при динамической линковке. Звено алгоритма с поиском функции по имени выглядит лишним. Даже просто потому, что есть стандартная функция GetProcAddress, которая тоже ищет по имени.

Если не утраивают интерфейсы, то есть объекты:

Код: Выделить всё

  TPluginVersion01 = class
  private
    FFunction : TFunction;
  public
    function InPlugin: integer;
    constructor Create(aHandle : TLibraryHandle);
  end;
....

constructor TPluginVersion01.Create(aHandle : TLibraryHandle);
begin
  FFunction := GetProcAddress(aHandle, 'InPlugin');
end;

function TPluginVersion01.InPlugin: integer;
begin
  Result := FFunction;
end;



[zub]

>>Хоть при статической, хоть при динамической линковке. Звено алгоритма с поиском функции по имени выглядит лишним.
На этапе компиляции неизвестно какие функции появятся в программе при подключении плагина в рантайме, поэтому хотябы раз поскать по имени придется. но каждый раз при обращении к этим функциям искать конечно не надо.

>>Если не утраивают интерфейсы, то есть объекты:
Завернуть это дело можно как душе угодно, суть не меняется

[stanilar]

хотя бы раз поискать по имени придется

Придется, хоть через GetProcAddress, хоть через OwnerApplication.Command. Ну и зачем нужен OwnerApplication.Command (да еще с такими проблемами в передаче параметров), если уже есть стандартный GetProcAddress?

[Дож]

хотя бы раз поискать по имени придется

Придется, хоть через GetProcAddress, хоть через OwnerApplication.Command. Ну и зачем нужен OwnerApplication.Command (да еще с такими проблемами в передаче параметров), если уже есть стандартный GetProcAddress?

Сравните код:

Код: Выделить всё

OwnerApplication.Command('a');


и

Код: Выделить всё

Func := nil;
for I := 0 to High(OwnerApplication.Plugins) do begin
  Func := TFunc(GetProcAddress(OwnerApplication.Plugins[I].Handle, 'a'));
  if Func <> nil then
    Break;
end;
if Func <> nil then
  Func;


Ответ на Ваш вопрос «зачем»: чтобы плагин не сам перебирал плагины, а был единый функционал в программе.

[Sharfik]

Придется, хоть через GetProcAddress, хоть через OwnerApplication.Command. Ну и зачем нужен OwnerApplication.Command (да еще с такими проблемами в передаче параметров), если уже есть стандартный GetProcAddress?

Открой Excel, Word если есть, комбинация клавиш если не путаю Alt+F11 для вызова VBA. Так вот, там в коде всегда доступны комбинации вида "Application.ThisWorkbook....".
Плагинам, доступ к списку загруженных плагинов нужно давать с ограничениями, только на ту информацию, которая им может понадобится. Иначе из библиотеки в библиотеку будет лезть лишний код, не факт что правильный. Спрашивается, как его одновременно везде исправить, если не реализовав в самой платформе. Политика плагинов в моем случае такова, что плагин2 имеет право работать с плагином1, получать доступ к его таблицам, командам, инструментам и т.п., но не имеет права изменять и настраивать чужой плагин. Это работа самой программы(он имеет право общаться, но устанавливать правила игры не должен).

да еще с такими проблемами в передаче параметров

Какими проблемами? Я спросил какой вариант удобнее с точки зрения не только моей. Но проблем в реализации тут нет. Все решается в три процедуры стандартных. Одна из которых выдает пронумерованный распарсенный список параметров команды введенной. Проблема, это когда недоработка Lazarus мешает реализовать нужный алгоритм.

[zub]

>>"Application.ThisWorkbook....".
Ты путаешь внутренний скриптовый язык и плагины. Это разные вещи.
Кстати, недумал заюзать паскальскрипт? Я думал, даже вроде неплохо плучалось... но у меня всё на object`ах, а паскальскрипт их не поддерживает((

>>Хотя я и проблемы с формами обошел. Есть косяк только с такими вещами как всплывающие подсказки и popupmenu.
Даже не буду спрашивать как)) Сейчас их НЕ ОБОЙТИ, просто при некотором стечении обстоятельств оно работает, в общем случае так делать нельзя

>>Какими проблемами? Я спросил какой вариант удобнее с точки зрения не только моей. Но проблем в реализации тут нет.
Как какими? ты можешь чтото передать, но проконтролировать что передано неможешь никак. Тут выше был имхо самый удобный вариант

Код: Выделить всё

GlobalCall('a', [1, GlobalCall('b', []), 'test']);

контроль типов передаваемых параметров не реализовать ни со стороны вызовающей процедуры, ни со стороны приемающей

[Sharfik]

Ты путаешь внутренний скриптовый язык и плагины. Это разные вещи.

А чем отличается плагин от скрипта выполненного в виде отдельного файла?) Ничем, кроме используемой платформы разработки и его обрабатывающего компилятора.
Интерфейс предоставляемый Офисом, Автокадом что для написания в VBA, что для работы через COM, один. Но я не об этом, а о наследовании и объектной модели приложения говорил, на примере экселя, которая удобна давая доступ к определенным вещам документа или программы в соответствии с иерархией.

С паскальскриптом разбираться времени нет. Он возможно понадобится если запросы к бд внутренней и отчеты буду развивать, а пока не до него.

[zub]

>>А чем отличается плагин от скрипта выполненного в виде отдельного файла?)
я не про это. я про то что наличие полноценного скриптового языка внутри программы гораздо приятней чем просто возможность добавления какогото функционала. Одно дело иметь контроль параметров передаваемых в "команду", другое просто передать ей набор указателей неизвестно на что.
Application.ThisWorkbook.OpenFile(123) - не прокатит, т.к. контроль типов скрипта не пустит интегер вместо строки с путем к файлу
а
GlobalCall('a',['хз что', GlobalCall('b', ['хз откуда']), 123]); - пркатит и на стадии компиляции и на стадии выполнения, а и б обломаются гдето внутри себя при попытке доступа к хз чему.

Можно придумывать хоть что, но плагин это лишь средство наращивания функционала (кстати ничто не мешает из плагина добавлять и новые функции к скрипту, если он есть конечно), но никак не замена скриптовых языков и именно скрипт поможет легко и непринужденно увязать плагины между собой
Так что от

Код: Выделить всё

OwnerApplication.Command('a');

в рамках этого топика
до

Код: Выделить всё

Application.ThisWorkbook....

в офисах и автокадах
как до китая пешком

[stanilar]

доступ к списку загруженных плагинов нужно давать с ограничениями, только на ту информацию, которая им может понадобится

Ты слишком усложняешь задачу. Для этапа разработки уж точно. Контроль прав можно прикрутить дополнительным параметром в вызове процедуры. Т.е. плагин будет просто запрашивать у программы пароль, и передавать его в качестве параметра при вызове.

А чем отличается плагин от скрипта выполненного в виде отдельного файла?

Большей независимостью от версии программы.

Добавлено спустя 10 минут 56 секунд:

а был единый функционал в программе.

Если процедура будет вызываться один раз за все время работы плагина, то проблем нет. А вот если будет интенсивное взаимодействие, то надо делать экспорт.

[Дож]

а был единый функционал в программе.

Если процедура будет вызываться один раз за все время работы плагина, то проблем нет. А вот если будет интенсивное взаимодействие, то надо делать экспорт.

Я привёл выше фрагмент кода в 8 строк, который нужно будет написать в каждом плагине. Не видите в этом проблемы? Ок, Ваше право.

[Sharfik]

Ты слишком усложняешь задачу. Для этапа разработки уж точно. Контроль прав можно прикрутить дополнительным параметром в вызове процедуры. Т.е. плагин будет просто запрашивать у программы пароль, и передавать его в качестве параметра при вызове.

Честно говоря, у меня мозги в клубок свернулись при словах " Контроль прав можно прикрутить дополнительным параметром в вызове процедуры". Что за мазахизм? Какой нафиг пароль. Плагин при старте всей платформы должен проверить есть ли пользователя лицензия на его использование, к примеру. Или соответствует ли версия API нужной ему и дальше начать работать и не передавать мусор в своих вызовах, либо оставив сообщение где то, передать платформе чтобы с ним работать не надо. А в твоем варианте, каждый левый плагин написанный Васей, будет прогонять весь массив залитых в программу плагинов и на каждом вызове процедуры, у проблемного плагина либо ошибка будет вылетать у пользователя, либо я по твоей милости все процедуры плагинов должен оснастить проверкой лицензии. Т.е. при грамотном выполнении защиты, у меня алгоритм шифрования ключа будет выполняться N^10 степени раз.

Большей независимостью от версии программы.

Независимость тут не причем. Скрипт имеет один единственный плюс - его можно исправлять и корректировать во время работы программы, без применения компилятора. Если функциональная часть программы не предусматривает настройки со стороны пользователя, изменение им скрипта, то алгоритм должен компилироваться. И лазить в него не нужно. Это будет быстрее выполняться. Если программа бесплатная, то проблем с перекомпиляцией под новую версию API не будет, если программа платная, то условия разработки платного софта не предусматривают за 5р. здравомыслящими людьми поддержки плагином всех версий платформ. Если конечно они не питаются святым духом.

Ты слишком усложняешь задачу. Для этапа разработки уж точно.

Слово "проектирование" знакомо?

[stanilar]

в твоем варианте, каждый левый плагин написанный Васей, будет прогонять весь массив залитых в программу плагинов и на каждом вызове процедуры, у проблемного плагина либо ошибка будет вылетать у пользователя

Собственно, именно так сейчас происходит в твоем варианте. Ведь OwnerApplication.Command ищет команду, чтоб ее выполнить, а не возвращает указатель.