nesco, Вариантов много, но сколько раз нужно пробежать глазами по чужой схеме, чтобы проследить куда идет сигнал от выбранного RadioButton - а ? А тут сразу и все видно. Правда озадачил меня своим Где хочешь

Hub нужен только, когда входные данные одни и теже (данный конкретный случай) , а можно подавать и разные. А у тебя без IndexToChanel не проживешь и разные данные передать тоже проблема.

Так что как ни крути все-же ТРИ
------------ Дoбавленo:

P/S/ а как запросто выбираются MathStr для математики или маски .
Все. Аргументацию закончил.

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

nesco, спать надо ночью

Я имел в виду вот что:

А утром - просыпаться, между прочим....

Удивительно, что столь продвинутое сообщество никак не въедет, что речь идет просто об отсутствии некоторых интерфейсных возможностей среды
Без которых профессиональное программирование крайне затруднительно, несмотря на потенциальные возможности технологии FTCG

В данном конкретном случае, невозможность определить такой мультик + чтобы линки на него были все-таки элементами, а не обладали одинаковым Caption
Т.е., parent-ом в данной внутренней схеме должен являться RadioButton, его иконка должна являться внешней, все его св-ва и точки должны быть автоматически наследованы.
За исключением "перекрытых", каковая возможность (и для св-в - тоже!) должна быть безусловно предоставлена, и именно средой

Ну куда можно серьезно продвинуться без технологии наследования (и не только без этого) - не пойму.
А Вы, вместо этого, обсуждаете блага "мультипроцессинга"...

iarspider, а вот это я писАл, да

видимо предлагается оставить попытки что-то улучшить с учетом имеющихся средств и ждать у моря погоды. Не уверен, что так можно далеко продвинуться...


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

Если конкретно, без "видимо", то: делается утверждение что имеющихся интерфейсных средств совершенно недостаточно для серьезной работы.
В данном конкретном случае - для создания своего варианта интерфейса.
Хотя бы по той причине, что конкретному пользователю именно такой интерфейс элемента позволяет лучше думать над алгоритмом.
Без диспутов, чья точка зрения лучше.

Про ждать: если вспоминать про одинаковость св-в у линков, которые фактически являются разными экземплярами одного класса, тогда действительно: именно у моря, и именно - погоды.



Мне представляется, что ООП в интерфейсе - это двигатель прогресса.
ООП в кодогенерации - его тормоз.
И это два совершенно разных разговора.
Здесь речь, вроде, шла именно об интерфейсе: способе изложения своих мыслей (алгоритма) для искусственного интеллекта (кодогенератора, компилятора...)
Фактическое содержание моего предыдущего поста: недостаточно этих способов.
Меня легко переубедить, между прочим: изложите способ рисования схемы для какого нибудь CodeGen
Совершенно не надуманная, не самая банальная задача. И более адекватный путь для "портирования" куда ни то...
И думается мне, что если мы умеем решать аналогичные задачи в виде схемы, то сможем привлечь в свои ряды профессиональных программистов (если отработаем эффективность кодирования). Если нет - и эффективность не поможет...

Да, и еще мне казалось, среде с претензией на дружественный интерфейс следует таки руководствоваться принципами "двигателя прогресса"
Пока казалось... Может поменялось чего...

Galkov, предлагаемые интерфейсные решения это уйма работы и последующей отладки. И это без учето того, что на данный момент совершенно невозможно представить как интерфейсно будет выглядеть наследование элементов изменяющих скажем число точек на ребрах. То, что предлагается нужно еще доводить и доводить и потому ждать реализацию в ближайшее время можно считать бессмысленным занятием. Кому отсутсвие этих фишек мешает двигаться вверх и вперед пусть садится за клавиатуру и набивает спецификацию поведения всех типов элементов и всех типов св-тв у них при интерфейсном наследование в среде. Ну и конечно же приписать туда поведение кодов элементов на базе пакетов ООП(Delphi, PocketPC) и FTCG.

Без диспутов - берем и делаем.

Эти все вопросы поднимались (вернее - пытались) неоднократно.
И они все требуют обсуждения (не настолько просты, чтобы все было понятно и очевидно "с листа").
И результат был ВСЕГДА один - молчание без диспутов.

Точно мне все это одному надо. Да меня вообще, завтра может машина задавит
Побазлали "как бы можно сделать" динамическое количество RadioButton-ов, и успокоились.
Никто (из читающих форум, конечно) не забыл этих попыток реализации "существующими средствами"

Предлагается еще раз сработать на корзину, я правильно понял



Предлагаемый путь делать "как получится" приведет к еще большей (правда - потом) работе по выходу из тупиков
В результате может получиться не самолет, а подводная лодка.
И на ней даже можно будет двигаться по степям Украины... Особо продвинутым пользователям...

"Предлагаемые интерфейсные решения" - это постановка задачи для этапа Созидания Супер Кодо-Генерации.
У нас пока - наоборот
К примеру, должен ли пользователь понимать линки в схеме только как Run Time, или ему следует быть настолько продвинутым, что по контексту угадывать что это конкретно - Design Time ?
Ответ на этот вопрос - постановка задачи, вообще-то.

Кстати говоря, с интересом посмотрел бы, как в пакете QT пройдут данные типа Array через элемент типа GetIndexData....

Galkov, к сожалению не очень понятны разговоры в терминах самолетов и подводных лодок, и тем более нет представления о геологии степей украины, чтобы рассуждать на тему того, будет там что-то двигаться или нет... У нас все гораздо проще: есть видение реализации чего-то - оно делается. Если сделано криво и неправильно - бросается начатое и делается заного. Во всяком случае благодаря этому на каждом следующем этапе можно с уверенностью говорить о том, почему иначе будет хуже. Поэтому в 10 раз могу повторить: не понимаю я и не вижу у себя перед глазами того, как и с какого бока, да и с какими возможностями нужно реализовывать то, что предлагается в постах выше. Поэтому и говорить со своей стороны считаю не о чем.

На счет "Супер Кодо-Генерации" - до FTCG не было никакой Кодо-Генерации вообще и какая бы "глупая" реализация у этого подхода не была она позволила появится пакету WEB и форуму сделанному на нем. Небольшие правки для заточки под типизированные языки - и мы имеем полноценный пакет QT, в котором собираются программы, не уступающие стандартному пакету, а в чем-то даже превосходящие его.

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


Да правильно. К сожалению на 100 теоретиков приходится 1 практик(если не меньше). Поэтому если заниматься только рассуждениями, а не предлагат готовые решения, то боюсь большая их часть действительно уйдет в корзину. Ну или будет реализована очень нескоро.


А я бы с интересом посмотрел, что есть элемент GetIndexData в интерпретации пакета QT... Впрочем если кто-то захочет поупражнятся в искустве чесания левой ногой правое ухе, то ему придется написать весьма объемную реализацию кода для поддержки всего того, что может придти через нижнюю и верхние точки элемента - и массивы в том числе. Напомню на всякий случай: GetIndexData - это древняя затычка для пакетов на базе чистого ООП, который позволял реализовать в схеме выражаясь на языке ЯВУ - индексные массивы с вариантным типом данных. В пакетах на базе FTCG у нас для этого есть более удобные и главное оптимальные средства.

Dilma, читай форум, все-таки.
Даже для практика - это не самое бесполезное занятие.
А абсолютно "готовые решения" появляются в результате обсуждений. И уж точно, с участием того, кто может воплотить эти решения
И НЕ появляются, если в ответ - гробовая тишина.
И на форуме найдется с десяток эдаких "обсуждений" ((это утверждение))
Если этот форум читать, конечно же.


Установка GetIndexData (к примеру) в схему - это способ изложения мыслей разработчика
И никакая интерпретация пакета не должна влиять на это.
Наоборот - должно. Хотя, убедить в этом - надежды не имею.


Собственно, другого я и не ожидал, ибо ответы твои, Dilma, мне известны заранее с вероятностью эдак % на 90...
Разговор-то начинал, с целью получить мнение других коллег о состоянии интерфейса и его перспективах
Ну и получил: отсутствие ответов таки тоже - ОТВЕТ.

Все это очень даже интересно, но как это все реализовать, здесь и сейчас, оставив совместимость со всем что было до этого

nesco, "очень даже интересно" - увлекает безусловно
Но не показывает твоего ответа на абсолютно конкретный вопрос...

Что же фактически предлагал Tad
Сотворить банального наследника для RadioButton
Ну и пару строк в реализации метода...
И этот конкретный вопрос звучал так: имеет право тот самый пресловутый "Tad" сделать это же самое методами схемотехники, и пользоваться этим элементом ровно так же, как и штатными элементами

Вот я, к примеру, свое мнение высказал совершенно однозначно:

обязан иметь это право (и сразу же тема этого топика, как и некоторых других - закрыта)

если это право будет вдруг противоречить некой концепции некого пакета, то менять надо ту концепцию

чтобы не противоречила, интерфейс пользователя надо делать ДО создания таких концепций, а не наоборот, по принципу: вот чего получилось

---

Конечно у меня и еще есть немного про интерфейс, который должен быть ДО
Тезисно, примерно так:

Наследование - механизм создания своих элементов.

Инкапсуляция (сокрытие) св-в и методов - фактическое реализация представления различных интерфейсов одного объекта

Рекурсия - это линки (динамическое создание объекта своего класса) вверх.

Указатель на объект (на интерфейс объекта). Может быть, назначение (select) "чужого" мультика в динамический контейнер.

Пользовательское формирование проекта - определение классов в этом/другом файле, и т.п..
А более подробно, не очень имеет смысл.
Получено подтверждение - пойдет в корзину.
Да и устал я уже, в одиночку-то...

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

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

Galkov, еще раз теперь уже на конкретном примере покажу способ движения вперед, который вроде бы всех нас устраивает: это действия г-на nesco. Он дорабатывает стандартный пакет сам по себе, иногда обращается за советом. Если что-то вдруг им делается не так, как хотелось бы это выносится на обсуждение и принимается решение - быстро и просто. Пусть даже приходится откатываться, но это уже дело 3-4х минут. Ну и самое главное - пользователь может "пощупать" то, о чем тут говорится. Кроме nesco, я уже не раз приводил не безизвестные ники evgig, AVC и других, чьи идеи были внесены в HiAsm только благодаря четкой, ясной и полной концепции, разработанной ими, по которой оставалось только набить код. Если же очень хочется разводить печатную демогогию, то боюсь это не сюда.

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

И если это не получается понять и осознать, то предлагаю хотя бы не выяснять в сотый раз почему нет ответов - и не будет. Либо работаем в таком ключе, либо ищем занятия более для себя подходящие. Предлагаю на этом закончить и заняться далее конкретными делами без излишних философствований.

Про чтение, и глухое молчание в ответ:

И чего тут было непонятного....
Эта реакция, типовая, между прочим. Тоже, по некоторому опыту