RadioButton, пропускающий поток

Вверх ↑

Форумы Делаем компонентыRadioButton, пропускающий поток ← Ctrl1 2 3 4 5 6 789 10Ctrl →

Этот топик читают: Гость

Ответов: 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

Администрация

Ответов: 15295

Рейтинг: 1519

#107: 2008-06-11 11:54:35 ЛС | профиль | цитата

Galkov писал(а):

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

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

Galkov писал(а):

Вопрос про диалоги остается

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


#hws
func dialog_event(owner, value)
  msgbox('Элемент с именем ' + owner.name + ' вызвал событие со значением: ' + value)
end

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#108: 2008-06-11 12:11:10 ЛС | профиль | цитата

Dilma писал(а):

но RTCG - он и на половину не дописан еще

Типа я не видел

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

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

карма: 9

Ответов: 2125

Рейтинг: 159

#109: 2008-06-11 14:43:21 ЛС | профиль | цитата

Galkov писал(а):

Из твоих предложений не понял, чем это поле лучше чем MainClass

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

Dilma писал(а):

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

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

карма: 1

Ответов: 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

Администрация

Ответов: 15295

Рейтинг: 1519

#111: 2008-06-11 15:40:06 ЛС | профиль | цитата

Galkov писал(а):

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

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

Синтаксис естественно лучше полностью повторить по FTCG за исключением разве что работы с секциями и множеством языков. В таком случае можно будет часть пакетов перенести без особых изменений

карма: 27

https://hiasm.com

Ответов: 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

Администрация

Ответов: 15295

Рейтинг: 1519

#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

карма: 27

https://hiasm.com

Ответов: 9906

Рейтинг: 351

#114: 2008-06-11 17:44:12 ЛС | профиль | цитата

Ага.
Начинаю потихоничку.

карма: 9

Администрация

Ответов: 15295

Рейтинг: 1519

#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*

тут уж от реализации скрипта зависит

карма: 27

https://hiasm.com

Ответов: 2125

Рейтинг: 159

#116: 2008-06-11 20:06:00 ЛС | профиль | цитата

Dilma писал(а):

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

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

Dilma писал(а):

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

QtScript?

карма: 1

Ответов: 9906

Рейтинг: 351

#117: 2008-06-12 11:23:16 ЛС | профиль | цитата

Есть предложение, для обсуждения технических вопросов про RTCG перейти сюда
А здесь продолжить интерфейсные соображения, например - в картинках

Глядишь, и придумаем фишку, чтобы коллега Tad смог таки сделать на HiAsm себе персональную версию компонента RadioButton и не домогался о включении ее в дистрибутив

Я уже перешел...

карма: 9

Ответов: 16884

Рейтинг: 1239

#118: 2008-06-13 09:33:23 ЛС | профиль | цитата

Если бы

Galkov писал(а):

коллега Tad смог таки сделать на HiAsm себе персональную версию компонента RadioButton и не домогался о включении ее в дистрибутив

и не прозвучало

Dilma писал(а):

Большая просьба не сбрасывать все гениальные идеи на плечи одного элемента. У конфигов есть св-во Inherit, у классов в Delphi есть врожденное наследие( TChild = class(TParent) ), а у палитры элементов есть вложенные группы. Пожалейте новичков...

то продолжал бы "наш бронепоезд стоять на запасном пути"

карма: 25

Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!

Ответов: 16884

Рейтинг: 1239

#119: 2009-09-05 13:12:46 ЛС | профиль | цитата

Рисую схему в которой десятка два CheckBox-ов и не меньше RadioButton-ов, причем и у тех и других есть экземпляры с Selected = True.
Самая подходящая схема от Dilma http://www.hiasm.com/xf//getfile/9188 , но ставить кучу IndexToChannel как то не охота.
Все остальные предложенные варианты схем требуют "предварительного импульса инициализации". Читай - добавочные компоненты.
Вернулся к "нештатному (предложенному мной в начале темы) RadioButton -у и CheckBox-у, пропускающему поток" и никакой головной боли и лишних элементов.

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

карма: 25

Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!

Ответов: 80

Рейтинг: -5

#120: 2009-09-06 11:46:56 ЛС | профиль | цитата

Ребята, да это ведь один из похожих элементов реле и действительно радиокнопка!!!!
Ведь что делает радиокнопка? переключает, а тут, просто говорит я включена(выключена).
Получается, что это просто механизм с одним контактом замыкание размыкание и теперь надо еще придумать к ней механику переключения!!!???

Более того не просто пропускающий поток но и переключающий поток, то есть группа контактов.

карма: 0

Форумы Делаем компонентыRadioButton, пропускающий поток ← Ctrl1 2 3 4 5 6 789 10Ctrl →


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