Galkov, ты был прав... не лечится пока такое...

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

Мне даже интересно стало: что же такого я сверхестественного написал
Три логических действия:
1) разветвление по "константности" индекса
2) в ветке "выражение" опять ветвление:
2.1) если живая одна - генерируем IF
2.2) если больше - CASE

Но когда обсуждение этих банальностей по трудозатратам начинает превышать их создание...
В общем, нет слов - одни мысли

Между прочим парсинг-то не однопроходным получился(примерно полуторапроходный). Поэтому такие штуки возможны стали.

Извини но но наверное у нас разные понятия о новых технологиях.
Например(как потребитель) какой нибудь Dreamwiever считаю более продвинутым чем пакет WEB.
Так как он требует от меня меньше знаний.
Вот эта картинкакнопка была создана за один клик в специализированной программе.


И не требует от меня знания Фотошопа.

Так же пакет Delphi 1 - не требует от меня знания Языка Delphi .
А в пакете WEB те же теги что и в HTML .
Поэтому рассматриваю WEB только как стартовую позицию для чего то более продвинутого.

Устами младенца глаголет истина

Я с ним согласен.

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


no comments...


ошибочное высказывание. Причем полностью. Положим в глаза я не видел эту программу, тогда чтобы сделать кнопку надо:
1) хотя бы догадываться, что в программе есть такой модуль/плагин/визард
2) найти в меню вызов этого модуля/плагина/визарда
3) разобраться с параметрами, задающими отступ бордюра, свет, тени, цвета кнопки, интенсивность освещения, текстуру.
4) для надписи тоже самое...
5) уметь применить к рисунку и уметь сохранить в файл.

Это называется не требует знания

Опять чисто субъективные выводы, не подтветжденные совершенно ничем.

Вячеслав, вообще-то ты просто мешаешь работать.

Есть некоторый объем работы, цель которого тебе непонятна.
Ну и слава богу, флаг тебе в руки - продолжай непонимать, мешать-то зачем ???

Что бы ты меньше беспокоился, скажу сразу:
а) не является нашей целью научить тебя чему-то
б) не является нашей целью облегчить мероприятия по "украсть где-нибудь чего-то готовое"
в) не является нашей целью создание элементов без понимания чего делаешь

Совершенно согласен.
Поэтому и писал


Я имел ввиду работу по шаблонам.

Ничего этого ненадо - это шаблон.
К которому можно применить различные эффекты(одним кликом)
шаблонов 102
Стилей 33
Контуров 22
3D скосов 12
теней 12
Маска 20
Перемножаем 102*33*22*12*12*20= 213269760 - вариантов кнопок
Есть конечно и более продвинутые функции.
Но мне кажется и этого хватит любому.
И всё это делается только кликом и автоматическим применением выбранного стиля к шаблону.
И в интерфейсе всего 8 закладок для выбора стиля.

Два клика + набор слова Вот .

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


А зачем что то подтверждать - попробуй сделать то же самое в Фотошопе за два клика.
Я это всё к тому что Фотошоп - для Художника.
А "моя" прога для Пользователя.

Всё больше ничего не пишу делайте что хотите.

Dilma, давай не будем забывать о деле таки


Ну уж не знаю и как
Давай попробуем по порядку...
Хоть там и отвлечения появятся от конкретной темы: "парсинг Единого_Свойства_События"
В большей степени я буду излагать свое понимание того, что у нас происходит, или должно происходить.

1) Начнем слева от интересующего нас события. А справа этого события стоит тот самый элемент, код которого зело велик для неоднократной инлайн реализации

2) В кодах левого элемента (да хоть бы и StrCat, к примеру) стоит event(onStrCat, s). Начинается работа CG.
Первое, что он делает, это устанавливает, что линк у нас идет к точке doMethod нашего конкретного элемента (код doMethod которого зело велик для неоднократной инлайн реализации)

3) Сейчас отвлечение. Может оказаться, что к этому же методу этого конкретного элемента есть иные обращения посредством HubEx. Или точка doMethod обладает атрибутом DPE и есть обращения точкам нашего же элемента, но с другими индексами.
Суть то одна и та же - неоднократное использование метода...
Так вот, ОЧЕНЬ хотелось бы обратить внимание, что хоть здесь и тоже необходим функциональный вызов, это совершенно отличается от упаковки метода элемента в метод объекта.
Грубо говоря - это два разных разговора.
Этот случай гораздо проще: если мы таки приняли решение о функциональном вызове (как мы должны принять это решение - пока не до конца понятно), то теперь в задачу именно CG входит формирование этого функционального вызова (это языково-зависимый фокус, поэтому видимо через вызов скрипта из какой-то системной библиотеки, или расширять функциональность direct.inc надо) в текущий блок с необходимыми фактическими параметрами, и сформировать в другом блоке (видимо в BLK_MTD_BODY) определение ф-ии с необходимыми формальными параметрами. В качестве тела ф-ии влепить исполнение скрипта для doMethod, фактические параметры которого и есть формальные параметры определяемой ф-ии.

4) Вот и все, в этом простом случае, и принципиальных проблем тут не очень видно.
Кроме одной: все это должен делать CG, и не очень ясен критерий принятия решения FUNCTION.
Это как-то должно зависеть от размера кода ВСЕЙ алгоритмической ветки, а не от типа первого же элемента в этой ветке. Он вообще может быть типа AlwaysInline.
А с другой стороны, всегда (по любому Ex-у) принимать решение Function - тоже глупо. Ведь то же самое относится и к вертикальным связям, что встречается в схемах гораздо чаще.
Ясно, что глупо превращать в функциональный вызов код, который возвращает по вертикали что-то типа Btn_15.Caption, хоть и используется эта точка раз 20...

5) А теперь закончим отвлечение - нет у нас повторных вызовов одной и той же точки.
Тогда CG просто запускает в работу ф-ию doMethod нашего элемента, имея в контексте именно этот конкретный экземпляр. Этот контекст и позволяет нам (CG) далее парсить, к примеру св-ва X, Y и Z.
И все нормально, пока мы не обратили внимание на то, что: а) таких элементов на схеме несколько б) код метода зело велик для неоднократной инлайн реализации
И вот тут, если мы захотим упаковать этот метод в функциональный вызов, начинается тот самый другой разговор. Как отмечал выше, он серьезно отличается от разговора по пп..3,4
Грубо говоря - это два разных разговора, хотя похожие слова и встречаются.

6) У меня нет никаких возражений против формирования функционального вызова с дополнительными аргументами, при фактических параметрах типа "св-во" или "данные потока"
В случае если в нашей схеме не встречаются реализации нашего элемента, когда данные берутся с верхних точек - замены наших макросов X, Y и Z на формальные параметры, или поля объекта, могут оказаться самыми оптимальными.
Здесь конечно есть незакрытый вопрос: каким это макаром формировать тело метода. При запуске ф-ии скрипта мы имеем конкретный контекст - выбранный элемент. В нашем случае не должно быть выбранного элемента, код должен быть одинаковый для всех экземпляров данного класса.

7) У меня есть категорические возражения против подставления в фактические параметры вышеупомянутых функциональных вызовов - результатов работы верхних точек.
Скажем для

Я уже как-то говорил: код метода должен быть настолько мал, насколько это возможно. Если требуются нетривиальные действия - оформлять это методом/процедурой/функцией, а в коде метода оставлять только подготовку параметров и вызов метода/процедуры/функции.
Сам CG должен делать функцию только когда точка используется более одного раза.

А я и не говорил, что не слышал этого

На безрыбье и это тоже, безусловно - Рыба.
Вот только такой подход снимает лишь часть проблем - конкретно для одного элемента
А если это мультик с линками, то начинай эту же самую песню опять с начала
Чего ее откладывать, потом снова начинать, потом может быть снова откладывать...
Петь ее надо с самого начала, и громко
Следовательно, умение самостоятельно принимать решения inline/function нам все-равно необходимо.
Хучь в ухо мочись...

А если сие умение у нас есть на уровне CG - чего заморачиваться с таковым на уровне пользователя 1-го уровня

Тем более, что и в случае "нетривиальных действий" инлайнинг (при однократном использовании)
включил бы дополнительные оптимизационные процессы в целевом компиляторе.

Galkov, все равно не уловил в чем заключается неправильность в пункте 7). Как бы уже сегодня подобная реализация функционирует для контейнеров с Mode=Function. Да обращение к точки может не просто вернуть btn15.width, но и сформировать ко всему прочему некий код. Этот код будет вставлем перед вызовом метода и ничего вроде бы криминального тут нет. Почему вызов btn15.width до фактического вызова метода не верен?

Реализацию принятия решения inline/function на сегодняшнем этапе не представляю себе даже впринципе. Технически это конечно не так сложно, но на практике видится появление как минимум одной проблемы: поскольку Memory(и еще несколько элементов) могут представлять из себя локальные ячейки памяти, то поведение таких элементов и схем с ними станет почти не предсказуемым. Т.е. вот так сразу глядя на схему мы не сможем сказать, где именно начинается область видимости данной ячейки памяти пока не произведем компиляцию и не уточним с какого элемента CG завернул нам все в ф-цию...

[size=-2]------ Добавлено в 17:47
Впрочем начинаю постепенно иначе смотреть на старую идею разделения св-тв элемента на две группы: базовые и, скажем так, системные.

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