Мысли по сабжу.
HI !!!
После некоторого опыта практического применения забжа возникли некоторые мысли привеленные ниже.
1. TfsScript
1.1. Директива Uses. Жестко берет текст модуля из файла с именем идентичным с именем модуля, что мне кажется совсем уж не гибко.
Оптимально было бы у TfsScript добавить событие типа:
OnIncludeUnit(const Name: string; var Text: TStrings)А откуда брать текст подключаемого юнита пусть решает пользующий компонент, не сам компонент.
1.2. function AddClass
По умолчания данная функция автоматически регистрирует все published свойства импортируемого класса. Но на практике часто бывает, что все published свойства регистрировать как раз и не нужно (типа BiDiMode и т.д.).
Неплохо бы былобы к примеру нечто подобное:
function AddClass(AClass: TClass; const Ancestor: string; AutoReqPublishedProperty: Boolean = True) И соответсвенно function AddPublishedProperty(const Name: string)И можно будет ручками указать, что именно нужно импортить.
2. TfsSyntaxMemo
2.1. Неплохо было бы автоматическое извлечение Keywords для TfsSyntaxMemo из схемы
языка, а не из констант (PasKeywords, CppKeywords и т.д.).
2.2. Диалог TfsSynMemoSearch достаточно нестандартен с (мелкие кнопки, одним словом некрасиво как то, нестандартно) полем ввода искомого значения. Может просто заменить на стандартный InputBox или сделать более
стандартно ? (мелочь но все же..)
2.3. Replace Text
2.4. PopupMenu у TfsSyntaxMemo.
Можно ли вынести значение Caption у Item'ов в константы (или другая более
гибкая альтернатива), а то жесткое m.Caption := 'Copy' не всегда удобно.
2.5. Горизонтальная полоса прокрутки.
Спасибо за внимание.
Best Regard.
После некоторого опыта практического применения забжа возникли некоторые мысли привеленные ниже.
1. TfsScript
1.1. Директива Uses. Жестко берет текст модуля из файла с именем идентичным с именем модуля, что мне кажется совсем уж не гибко.
Оптимально было бы у TfsScript добавить событие типа:
OnIncludeUnit(const Name: string; var Text: TStrings)А откуда брать текст подключаемого юнита пусть решает пользующий компонент, не сам компонент.
1.2. function AddClass
По умолчания данная функция автоматически регистрирует все published свойства импортируемого класса. Но на практике часто бывает, что все published свойства регистрировать как раз и не нужно (типа BiDiMode и т.д.).
Неплохо бы былобы к примеру нечто подобное:
function AddClass(AClass: TClass; const Ancestor: string; AutoReqPublishedProperty: Boolean = True) И соответсвенно function AddPublishedProperty(const Name: string)И можно будет ручками указать, что именно нужно импортить.
2. TfsSyntaxMemo
2.1. Неплохо было бы автоматическое извлечение Keywords для TfsSyntaxMemo из схемы
языка, а не из констант (PasKeywords, CppKeywords и т.д.).
2.2. Диалог TfsSynMemoSearch достаточно нестандартен с (мелкие кнопки, одним словом некрасиво как то, нестандартно) полем ввода искомого значения. Может просто заменить на стандартный InputBox или сделать более
стандартно ? (мелочь но все же..)
2.3. Replace Text
2.4. PopupMenu у TfsSyntaxMemo.
Можно ли вынести значение Caption у Item'ов в константы (или другая более
гибкая альтернатива), а то жесткое m.Caption := 'Copy' не всегда удобно.
2.5. Горизонтальная полоса прокрутки.
Спасибо за внимание.
Best Regard.
Комментарии
1.2. лишние проперти никогда не помешают. Помешать может то, когда их не хватает.
2. SyntaxMemo - это бонусный компонент, если нужно что-то посерьезнее, советую взять SynMemo (из JEDI VCL, кажется).
>>>1.1. а мне кажется - нормально, не хуже чем в Delphi
И не лучше... Еще раз повторюсь, что это не гибко, очень не гибко. У нас допустим предполагается хранение юнитов в базе, да я думаю у большинства будет альтернативный мененеджмент юнитов.
>>>1.2. лишние проперти никогда не помешают. Помешать может то, когда их не хватает.
Не буду рассуждать про засорении области имен и т.д. но есть такие случаи, и возможность их ручной установки должна быть!!
>>>2. SyntaxMemo - это бонусный компонент
Это понятно, но ведь если приложить немного усилий в плане его доработки то в большинстве случаев отпадет нужда в сторонних компонентах, что сделает продукт более конкурентно способным, да и целостность пакета тоже…
Или авторы придерживаются позиции как в том анекдоте про "после сборки обработать напильником"??
Спасибо за внимание.
1.1 Преимущество скриптов в том, что их можно менять динамически, то есть скажем при выгрузке модулей из БД на конкретного клиента, загрузчик может прекрасно модифицировать код этих модулей, прописывая в uses пути и т.п.
Для скриптов в IL code это не годится. Но можно использовать скрипты совместно - в исходниках и псевдокоде, вызывая одни из других, хотя это в общем трюки.
А вот возможность для конечного пользователя поключать к скриптам DLL/BPL было бы здорово. В Genidaque (одна из реализаций VBasic для SCADA-систем) это оказалось для меня просто спасением.
Чем порадуют разработчики на этот счет?
В моей программе, использующей JvInterpreter (ранее RAI2), именно так и делается. Код, правда используется один и тот же для всех пользователей,
скрипты хранятся на сервере БД, а смысл использования скриптов в том, чтобы обеспечить собственную настройку системы для каждой конкретной организации.
2. Раз уж пошла такая пьянка... Не хватает обработчика, возвращающего и устанавливающего значение идентификатора (в том же jvInterpreter - OnGetValue, OnSetValue). Если скрипт работает, например, в контексте какого-то набора данных (поля которого заранее неизвестны), то зачем мне писать каждый раз DataSet := ..., если я могу просто писать Cost := ...
Поэтому я до сих пор использую <я уже сказал что>, несмотря на все его недостатки.
Поэтому оно и такое медленное...
Ну да ладно, не буду придираться к словам...
Хочу подчеркнуть, что не пытаюсь продвигать конкурирующий продукт на форуме FastScript. Я слежу за развитием вашего движка с момента выхода первой версии и перейду на него сразу же, как только будут реализованы необходимые мне функции. Использование форм в подключаемых модулях - тоже очень важная возможность. И было бы еще неплохо и дизайнер форм.
>> скрипт из БД и загружает его в интерпритатор.
С загрузчиком ясно. Но опять-таки: используемые модули приходится выгружать в файлы? Я пытаюсь поддержать совет разработчикам добавить возможность получения текста модуля (и формы) из источника, определяемого пользователем.
>> ... может быть даже эффективнее делать обновления при помощи пакетов.
Что имеется в виду?
Как правило, модули выгружаются в файлы. Но это необязательно. Скрипт (исходный текст) помещается в свойство TfsScript.Lines: TStrings, поэтому можно его загружать хоть из файла, хоть из БД, хоть динамически генерировать - примерно так: Текст скрипта можно перед помещением в TfsScript.Lines как угодно модифицировать: склеивать, резать и т.п. Полезным можеть быть применение скриптов-шаблонов и ф-ций форматирования Formatxxx. Наибольшая гибкость достигается, когда операции выборки, модификации и загрузки скриптов выполняются также скриптами, а не приложением. Можно также вызывать скрипт из скрипта, для этого нужно сделать соответствующую "обертку" TfsScript.
Пакеты - см. Delphi Help "About packages". Вкратце, применение пакетов позволяет вносить изменения и расширять функциональность проекта без его перекомпиляции.
Ну это понятно, что текст скрипта надо присвоить свойству Lines, и его можно брать откуда угодно. И вызов другого скрипта можно сделать (у меня это давно уже работает).
Проблема в обращении к объектам (функциям, переменным), объявленным в подключенных с помощью 'uses' модулях.
Я так понял, что текст этого модуля берется интерпретатором только из файла с именем, соответствующим имени модуля.
В самом деле, вещь очень полезная.
Планируется ли когда-нибудь?
Ну еще и дизайнер, объект инспектор и т.д. и т.п.
Ну ребята, вы даете.
Да все это неплохо бы иметь. На 1й случай хотя бы механизм считывания формы, сконструированной в Delphi из *.dfm. У меня это работает в полуручном варианте, примерно так:
1.загружается форма из *.dfm (в файле имя класса заменено на TForm).
2.по именам находятся нужные компоненты.
3.им назначаются обработчики.
Как сделать иначе без правки исходников, я пока не вижу.
А что скажут разработчики?
А купить готовые компоненты не пробовали? Есть масса сторонних разработок.
Дизайнеров форм и ObjectInspector существует множество...
Вот несколько:
Dream Collection (Комерч.)
http://www.dream-com.com/
Достаточно мощный и навароченный пакет (но можно и покупать по отдельности).
RAlib (Бесплатна, вошла в состав JEDI VCL)
http://search.msn.com/results.aspx?srch=105&FORM=AS5&q=RAlib
P.S.: В конце можно пошарить по торри:
http://www.torry.net/quicksearchd.php?SID=...igner&Title=Yes
А другого бесплатного ничего нет. Если покупать каждую компоненту - недолго и разориться, поэтому в последнее время предпочитаю бесплатные.
(хотя, возможно, это мои личные проблемы)
(Хотя с мой точки зрения проще купить готовое...
P.S.:
Как то давненько конторка DevExpress проводила конкурс среди програмистов, конкурсным задание было как раз написание дизайнера....
(http://www.dxrussia.ru/conkurs.php)
Можно посмотреть варианты решений задания (http://www.aqa.com.ru/results.asp) и попытаться написать самому.
За пример можно всять например это:
http://www.aqa.com.ru/files/12.zip
http://www.aqa.com.ru/files/35.zip