Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#106: 2008-06-11 11:22:52 ЛС | профиль | цитата
tsdima писал(а):
Galkov, это-ж вроде бы твоя идея и была

И в чем же проблема тогда....
Давайте договариваться про API, и не жалко выходные потратить на соотв. dll-ку
Ну RTCG - так RTCG.... Нам татарам: что наступать - бежать, что отступать - тоже бежать...

tsdima писал(а):
А насчёт интерфейсов, наверно можно обойтись и меньшими изменениями

Помню - такие варианты мы проговаривали...
Если забыть про наследование, то да - без изменений в среде вроде бы, как бы, можно бы и обойтись...
Хотя фишка с data_element мне представляется перспективной - она позволяет (теоретически) создавать нечто похожее на линки, но в разных интерпретациях. Скажем концепцию: схема (внутри мультика) - это всегда лишь определение класса, снаружи - она не значит ничего, а реальные экземпляры - элементы с таким св-ом, которые вовнуть как бы залазить и не позволяют. Типа - инкапсулировано насмерь

tsdima писал(а):
делаем у TEditMulti поле FCaller, которое будет устанавливать на себя

Из твоих предложений не понял, чем это поле лучше чем MainClass
Но дело в том, что "там где надо" должно относиться индивидуально к каждой точке...
И в этом варианте, второе, аналогичное по смыслу поле может помочь: работаем по FCaller, если там пусто - работаем по MainClass
Но это - техника дела....



Чего-то мне кажется, что для большего взаимопонимания пора переходит на графические картинки............
Ну ладно, вот давай я нарисую как бы мог выглядеть код для TTreeNode и некоторых его наследников.
Там добра с переопределением виртуалов (делегатов - по вашему), их использования в методах родителя, указания на класс отличный от самого себя (во первых, это таки какие ни какие, а - наследники; во-вторых,мне кажется, что указание на массив указателей на таких же как ты - не то же самое, что указание на своих братьев) - хватает, вроде по полной программе.
И мы продолжим обсуждение, нужны ли изменения в интерфейсе...
Ну может, правда, не сегодня.... В репе почесать надо будет...


------------ Дoбавленo:

Dilma писал(а):
тип data_element можно бы было на 100% реализовать в одних скриптах, не залезая в среду

Ну и славненько
И чего мы тогда друг-другу голову морочим
В смысле: а чего БЫ

Вопрос про диалоги остается (среда накопила список классов - типа такого)
карма: 9

0
Администрация
Ответов: 15293
Рейтинг: 1515
#107: 2008-06-11 11:54:35 ЛС | профиль | цитата
Galkov писал(а):
Ну и славненько
И чего мы тогда друг-другу голову морочим
В смысле: а чего БЫ

ну так не только интерфейса, но RTCG - он и на половину не дописан еще. Можно конечно и javascript приделать, но уж очень не хочется(все таки в голове сидит мыслишка о плавном переходе на иные платформы)...

Galkov писал(а):
Вопрос про диалоги остается

диалоги тоже можно заскриптовать. Делаем схемы в пакете Modules и исполняемую часть к ней на все том же RTCG примерно в таком виде:

#hws
func dialog_event(owner, value)
msgbox('Элемент с именем ' + owner.name + ' вызвал событие со значением: ' + value)
end
карма: 26
0
Ответов: 9906
Рейтинг: 351
#108: 2008-06-11 12:11:10 ЛС | профиль | цитата
Dilma писал(а):
но RTCG - он и на половину не дописан еще

Типа я не видел Давай я займусь.
У нас на работе тоже практики в основном: пока у меня была запарка, они сидели меня ждали, в место того чтобы мне фронт для будущей работы подготовить. Это я к тому, что месяц - я почти вольная пцица

Только сразу скажу - парсить "рекурсивно сверху" - не хочется. Приделаю коды Flex+Bison - быстрее них никто вроде не работает (они работают как конечный автомат и рекурсиями не увлекаются... но "стек" конечно же имеют)
Может не так быстро как ты...
Но разве это главное, такое решение позволит как-то более адекватно планировать и твои мысли, и наши...
Главное, что он раз - и сделается...


карма: 9

0
Ответов: 2125
Рейтинг: 159
#109: 2008-06-11 14:43:21 ЛС | профиль | цитата
Galkov писал(а):
Из твоих предложений не понял, чем это поле лучше чем MainClass

Тут надо сравнивать не с MainClass, а с FParent (см. исходник EditMultiEx, что используется в onEvent и _Data). А трогать FParent не надо, чтобы знать откуда себя удалять

Dilma писал(а):
Можно конечно и javascript приделать, но уж очень не хочется

Хочется, чтобы своя версия скрипта была столь-же самодостаточна и расширяема.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#110: 2008-06-11 15:39:11 ЛС | профиль | цитата
tsdima писал(а):
Тут надо сравнивать не с MainClass, а с FParent

Точно - давненько я не брал в руки шашек
------------ Дoбавленo:

BTW: меня терзают смутные сомнения....

Что если бы EditMultiEx мы делали не полем в "новом классе", а его предком, и, если бы массив в мультике мы хранили не в KOL.TList, а именно как array of THIEditMultiEx - то имели бы штатный локинг, в т.ч. и в элементах-поинтерах....

Надо бы прошерстить System.pas на этот предмет, и разобраться, наконец-то, их знаменитым RTTI
карма: 9

0
Администрация
Ответов: 15293
Рейтинг: 1515
#111: 2008-06-11 15:40:06 ЛС | профиль | цитата
Galkov писал(а):
Только сразу скажу - парсить "рекурсивно сверху" - не хочется. Приделаю коды Flex+Bison - быстрее них никто вроде не работает (они работают как конечный автомат и рекурсиями не увлекаются... но "стек" конечно же имеют)
Может не так быстро как ты...

главное не время разбора, а время работы промежуточного кода, получаемого после построения дерева программы. В сущности как и на чем делать - не важно. Получившийся продукт должен удовлетворять таким требованиям:
1) сборка только FREE компилятором
2) переносим между платформами

Синтаксис естественно лучше полностью повторить по FTCG за исключением разве что работы с секциями и множеством языков. В таком случае можно будет часть пакетов перенести без особых изменений
карма: 26
0
Ответов: 9906
Рейтинг: 351
#112: 2008-06-11 16:09:47 ЛС | профиль | цитата
Dilma, дык все именно так и есть:
  • Flex+Bison - гнутые продукты. Результат их работы - исходники на C (C++). И, естественно, заточка под gcc - максимальная
  • Время: по оценкам экспертов (скажем, проболтался один из авторов CocoR - тоже компилятор компиляторов, но именно "рекурсия сверху" и для Дельфи) выигрыш именно на парсинге - 3-5 раз.
  • Ситаксис - ну конечно, тем более что всякие добавления/исправления/расширения делаются потом за 6 секунд. В make прописывается соответствие для запуска этих чудо-инструментов...
    Собственно, изложи API, пусть даже приблизительно, и желаемый результат оформления (имя dll-ки, или еще чего, мысли же у тебя не сегодня сформировались) - и поехали
    Перед тестированием - все состыкуем....
    И будет нам всем счастие
    А то элемент DataToFileEx у меня давно готов... Даже выкладывал где-то...

    ------------ Дoбавленo:

    Время парсинга, наверное, должно влиять на открытие больших проектов...
    Хотя это не самое важное конечно...
    Приятней, когда коллеги лучше понимают исходник... В эти тулзы по началу въезжать не очень просто...
    Nix-овые традиции интуитивно понятного интерфейса делают свое, конечно, но - к хорошему быстро привыкаешь
  • карма: 9

    0
    Администрация
    Ответов: 15293
    Рейтинг: 1515
    #113: 2008-06-11 17:43:41 ЛС | профиль | цитата
    С синтаксисом все просто: недавно добавил последние правки и теперь он полностью описан тут HiAsm\Пакеты\Структура пакета HiAsm\FTCG\Описание синтаксиса. С той лишь разницей, что объекты _arr, sys, block и lng должны быть действительно объектами и обладать такими возможностями:
    
    #hws
    fvar(s)
    s = block
    s.select( BLK_BODY )

    а то в FTCG они только именуются объектами и таковыми не являются даже близко. Это все нужно для того, чтобы сделать более удобный и красивый интерфейс cgt, который бы возвращал именно объекты(схема, елемент, св-во, точка и т.д.), а не их id.

    Оформление:
    обязательное наличие процедуры загрузки и выгрузки
    
    #cpp
    int initScript(char *fileName, int data); // <- возвращает некий id объекта скрипта, fileName - текст скрипта, data - некие данные
    void freeScript(int id);

    точка выполнения методов скрипта
    
    #cpp
    TValue *run(int id, char *entryPoint, TValues *args);
    // после отработки функции скрипта значение возвращается в типе TValue
    // id - то, что вернулось после initScript
    // entryPoint - тут все ясно
    // args массив аргументов

    регистрация внешних методов
    
    #cpp
    int regFunc(int id, TFunc *func);
    // возвращает код ошибки
    // func указатель на функцию

    регистрация внешних переменных
    
    #cpp
    int regVariable(int id, TArg *var);
    // var - определяет тип и область памяти внешней переменной

    регистрация внешних объектов
    (тут надо еще подумать каким интерфейсом это лучше организовать. Как раз объекты lng, block и sys должны быть реализованы через него и не являтся частью синтаксиса скрипта)
    примерный вариант такой:
    
    #cpp
    int regObject(int id, TFuncList *methods, TArgs *fields, char *name);

    где:
    
    #cpp
    typedef struct {
    char *name;
    int type;
    void *value;
    } TArg;

    typedef struct {
    int count;
    TArg arg[];
    } TArgs;

    typedef struct {
    int type;
    void *value;
    } TValue;

    typedef struct {
    int count;
    TValue arg[];
    } TValues;

    typedef TValue*(TFuncProc) (int data, TValues *args);

    typedef struct {
    char *name;
    TFuncProc *proc;
    TArgs *args;
    } TFunc;

    typedef struct {
    int count;
    TFunc *procs[];
    } TFuncList;

    typedef struct {
    int count;
    TFunc *procs[];
    } TFieldList;

    ------------ Дoбавленo:

    в будущем наверно имело бы смысл приделать и пользовательские типы, чтобы скажем делать такое:
    
    #hws
    func test()
    fvar(s)
    s = new TStringList()
    s.add("hello world")
    s.add("second string")
    trace(s.text)
    end

    с описанным выше интерфейсом это можно сделать и так, если все объекты хранить на стороне "клиента" и регить их в скрипте через regObject:
    
    #hws
    func test()
    fvar(s)
    s = makeObject('TStringList')
    s.add("hello world")
    s.add("second string")
    trace(s.text)
    end

    карма: 26
    0
    Ответов: 9906
    Рейтинг: 351
    #114: 2008-06-11 17:44:12 ЛС | профиль | цитата
    Ага.
    Начинаю потихоничку.
    карма: 9

    0
    Администрация
    Ответов: 15293
    Рейтинг: 1515
    #115: 2008-06-11 17:55:30 ЛС | профиль | цитата
    на счет имени dll - никаких dll быть не должно. Данный инструмент будет в идеале входить в состав:
    - HiAsm как движок:
    --- design-скриптов элементов
    --- обрботчиков событий пользовательских диалогов(таких как ECreator скажем)
    - кодогенераторов, основанных на потоковом методе
    - ну и возможно пакетов(в QT полностью, в Delphi как некая внешняя dll)
    ------------ Дoбавленo:

    типы примерно такие:
    0) NULL
    1) int
    2) char *
    3) float
    4) object

    не знаю как лучше делать передачу массивов, указателей на методы и т.д. - возможно в рамках типа object, а может выделять отдельные позиции
    5) int[]
    6) *char[]
    7) float[]
    8) object[]
    9) proc*

    тут уж от реализации скрипта зависит
    карма: 26
    0
    Ответов: 2125
    Рейтинг: 159
    #116: 2008-06-11 20:06:00 ЛС | профиль | цитата
    Dilma писал(а):
    регистрация внешних объектов
    (тут надо еще подумать каким интерфейсом это лучше организовать

    Регистрацию внешних методов и переменных, по-моему, можно сделать как регистрацию глобального объекта (объект без имени).
    К чему нам излишнее разнообразие. И потом, всё уже давно придумано: VARIANT, IDispatch, IActiveScript, ...
    Может не мудрить с интерфейсами, а взять готовое, или по крайней мере сделать аналогично?
    ------------ Дoбавленo:

    Dilma писал(а):
    все таки в голове сидит мыслишка о плавном переходе на иные платформы

    QtScript?
    карма: 1

    0
    Ответов: 9906
    Рейтинг: 351
    #117: 2008-06-12 11:23:16 ЛС | профиль | цитата
    Есть предложение, для обсуждения технических вопросов про RTCG перейти сюда
    А здесь продолжить интерфейсные соображения, например - в картинках
    Глядишь, и придумаем фишку, чтобы коллега Tad смог таки сделать на HiAsm себе персональную версию компонента RadioButton и не домогался о включении ее в дистрибутив

    Я уже перешел...
    карма: 9

    0
    Ответов: 16884
    Рейтинг: 1237
    #118: 2008-06-13 09:33:23 ЛС | профиль | цитата
    Если бы
    Galkov писал(а):
    коллега Tad смог таки сделать на HiAsm себе персональную версию компонента RadioButton и не домогался о включении ее в дистрибутив
    и не прозвучало
    Dilma писал(а):
    Большая просьба не сбрасывать все гениальные идеи на плечи одного элемента. У конфигов есть св-во Inherit, у классов в Delphi есть врожденное наследие( TChild = class(TParent) ), а у палитры элементов есть вложенные группы. Пожалейте новичков...
    то продолжал бы "наш бронепоезд стоять на запасном пути"
    карма: 24
    Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
    0
    Ответов: 16884
    Рейтинг: 1237
    #119: 2009-09-05 13:12:46 ЛС | профиль | цитата
    Рисую схему в которой десятка два CheckBox-ов и не меньше RadioButton-ов, причем и у тех и других есть экземпляры с Selected = True.
    Самая подходящая схема от Dilma http://www.hiasm.com/xf//getfile/9188 , но ставить кучу IndexToChannel как то не охота.
    Все остальные предложенные варианты схем требуют "предварительного импульса инициализации". Читай - добавочные компоненты.
    Вернулся к "нештатному (предложенному мной в начале темы) RadioButton -у и CheckBox-у, пропускающему поток" и никакой головной боли и лишних элементов.

    Может обсудим эту тему ещё раз

    карма: 24
    Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
    0
    Ответов: 80
    Рейтинг: -5
    #120: 2009-09-06 11:46:56 ЛС | профиль | цитата
    Ребята, да это ведь один из похожих элементов реле и действительно радиокнопка!!!!
    Ведь что делает радиокнопка? переключает, а тут, просто говорит я включена(выключена).
    Получается, что это просто механизм с одним контактом замыкание размыкание и теперь надо еще придумать к ней механику переключения!!!???
    Более того не просто пропускающий поток но и переключающий поток, то есть группа контактов.

    карма: 0

    0
    Сообщение
    ...
    Прикрепленные файлы
    (файлы не залиты)