Вверх ↑
Этот топик читают: Гость
Разработчик
Ответов: 25681
Рейтинг: 2087
#61: 2008-06-07 17:19:03 ЛС | профиль | цитата
Dilma писал(а):
убрать onPaint из WinControl и вписать его там, где он нужен

Но ведь так раньше и было, в *.ini вписывали то, что работало. Но в таком случае теряется весь смысл наследования свойств и методов. Чтобы определить, что работает или не работает надо будет подключить все мыслимые точки и проверить их работоспособность. Я же предлагал, просто это дело оптимизиовать.
карма: 20

0
Ответов: 16884
Рейтинг: 1237
#62: 2008-06-07 23:12:54 ЛС | профиль | цитата
nesco писал(а):
в *.ini вписывали то, что работало
а теперь будем со знаком "-" вписывать то что не работает ...
карма: 24
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Администрация
Ответов: 15294
Рейтинг: 1515
#63: 2008-06-07 23:30:50 ЛС | профиль | цитата
мне кажется господа писатели не совсем понимают основные принцыпы ООП, часть которых была воплощена в возможности множественно наследования конфигурационных файлов. Когда непонимание сопровождается пространными выводами, а не уточняющими вопросами, то обсуждать тут как бы особо и нечего...
карма: 26
0
Ответов: 9906
Рейтинг: 351
#64: 2008-06-08 21:57:49 ЛС | профиль | цитата
Уважаемые коллеги, мне представляется, что не том вы говорите.
И уж точно - не в том стиле.

У меня есть совершенно конкретное предложение: давайте поговорим на тему, которую можно назвать "спецификация языка программирования HIASM"
Естественно, давайте говорить не с чистого листа, а опираться на то, что мы сегодня имеем
Придумывать необходимые интерфейсные решения совместно.

Ну есть у меня какие-то соображения на этот предмет...
Но они не являются законченными, например из-за того, что сомневаюсь что именно так (как именно мне приперло в голову) будет понятно всем.
"Будет понятно" - именно в том смысле, что будут помогать думать над алгоритмом, а не создавать дополнительные заморочки для пользователя
Вот так я предлагаю...
Причем, наш разговор должен быть именно интерфейсным
Никакого отношения к конкретному пакету, какому-то компилятору, какой-то библиотеке
Хотелось бы, что бы результатом нашего рассуждения была фраза такого типа: "Вот такую задачу программисту на HiAsm удобней решать именно так: <описание>"

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



Скажем, я попробую начать
Ну давайте посмотрим, чего может программист на HiAsm, а чего не может...
То, что он может показано в папках Example... И как-то мне хочется это назвать линейным программированием
Как только я пытаюсь структурировать данные, начинаются непонятки и заморочки

Не моя фраза, но не вызывающая ни малейших сомнений: 90% успеха работы программиста, это правильно созданные типы данных
Что такое структура данных в HiAsm
Да просто мультик, в котором мы помещаем эти данные: Memory, MemoryStream, Bitmap, да и другие мультики...
И можем нарисовать кучу необходимых методов.
Пока все в порядке.
А теперь давайте вспомним, что такие данные формируются не всегда, чтобы использовать это дело в одном экземпляре
Что мы можем использовать в нескольких экземплярах
Правильно, элемент.
И чего получается, в конкретной задаче мы формируем конкретный именно для этой задачи класс данных, и вынуждены запускать ECreator, помещать его в палитру элементов
Не слишком ли много суеты для простейшего действия
И что, для следующего проекта перестраивать палитру элементов в HiAsm

Дальше, совершенно типовым случаем является наличие в полях данных указателей на другие объекты. Собственно, сами по себе указатели никому не нужны, нужна необходимость вызывать некоторые методы этих объектов...
Как и у нас мультик - нафиг он тебе нужен, если ты не подаешь события на его точки

Получается что у нас должно быть два совершенно разных типа некого "линка": новый экземпляр того же класса, что и в оригинале, и указатель на некий конкретный экземпляр
А мы что имеем...
Имеющийся у нас линк обладает теми же самыми св-вами что и оригинал, а это характерно как раз для указателя
У нас графически отличаются линки от оригинала, что было бы совершенно логично именно для указателей - если это разные объекты одного класса, то они по жизни совершенно равноправны. Разве можно сказать про несколько элеменов MemoryStream, что один из них оригинал, а остальные - линки на него...
Но линк у нас это совсем не указатель, это именно новый экземпляр класса объекта-оригинала. По крайней мере в пакете Дельфи
Так сделано давно...
Так получилось....
И "так" будет и дальше получаться, если мы не определимся до построения, чего строить-то хотим: самолет или подводную лодку

Вот я и обращаюсь, уважаемые коллеги, давайте таки определимся, чего мы хотим

Ну и, получивши звание теоретика, я приведу пример из конкретной практической схемы...
Могу и выложить (хоть и большая), проблем нет. Но для затравки - на словах
У меня есть некий программатор.
У него есть разные табы: FUSE, FLASH, EEPROM, LOCK, Test
На вкладках FLASH и EEPROM тот кусок который выполняет чтение из камня - ну совершенно одинаковые, даже координаты визуальных контроллов совпадают
За исключением одного (в смысле - двух разных) мультика, у которого одна левая точка - doRead, и три правых - onSend, onResult, onStop
Точки-то одинаковые, а работают по разному - даже разным количеством выходных событий плюются, в ответ на входное

Как было бы делать совершенно правильно: вместо этого отличающего мультика установить некий указатель на объект. Ну предположим, что сам объект в этом гипотетическом элементе-указателе мы принимаем через некую системную точку ##obj
Тогда получилась бы одна схема, которая реализована в двух экземплярах, и эти оба экземпляра подключены к точке ##handle статического
мультика.
Каждый к своему, естественно.

Вот есть такая совершенно практическая потребность...
Повторю вопрос, коллеги: "Как должен поступать программист HiAsm, встретивши такое "
высказывайтесь
карма: 9

0
Ответов: 3655
Рейтинг: 69
#65: 2008-06-08 23:20:39 ЛС | профиль | цитата
Galkov,
Немножко не понял.
Мультики одинаковые или всё же различаются?
Входные данные одинаковые или нет?
карма: 0

0
Разработчик
Ответов: 25681
Рейтинг: 2087
#66: 2008-06-08 23:29:01 ЛС | профиль | цитата
Вячеслав, это, похоже, совсем другая концепция
карма: 20

0
Ответов: 9906
Рейтинг: 351
#67: 2008-06-09 00:04:09 ЛС | профиль | цитата
Ну хорошо, вот схема.
Ничего не правил - рабочий вариант. Только два красных ромбика добавил
Кусочки схемы начинающиеся с панели <Диалог READ> в табах FLASH и EEPROM - совершенно одинаковы
Кроме мультиков под ромбиками

Дык чего хочу: чтобы схем было не ДВЕ, а одна
карма: 9

0
файлы: 1prog_2a.rar [18.9KB] [206]
Ответов: 3655
Рейтинг: 69
#68: 2008-06-09 01:10:20 ЛС | профиль | цитата
nesco писал(а):
это, похоже, совсем другая концепция

Ну не знаю другая или нет но, я тоже так хочу,а может в QT это реализуемо.
Galkov писал(а):
Ну хорошо, вот схема.

Ну вот всё сразу стало понятно
Чё то отлично вижу как это сделать в делфи ,а как
в HiAsm не врубаюсь.
Это выходит что у нас нет такой элементарщины.

карма: 0

0
Ответов: 9906
Рейтинг: 351
#69: 2008-06-09 12:45:11 ЛС | профиль | цитата
Видишь ли, Вячеслав, таки не спроста я хотел поговорить именно интерфейсно
Без ссылок на конкретный пакет.
Мне кажется такая логика была бы более правильной: если мы решили для себя <в таких случаях Хиасмист должен поступать так: .....>, и если какой-то пакет не поддерживает такого решения - то это есть проблема именно этого пакета, не все на нем можно сделать оказывается, и это явление временное.
Но, пока я чаще слышу другое несколько... Не удивлюсь, если окажется что GetIndexData - это есть некое недоразумение, и его следует ликвидировать из всех пакетов... Вот, почти это и сказано:
Dilma писал(а):
А я бы с интересом посмотрел, что есть элемент GetIndexData в интерпретации пакета QT... Впрочем если кто-то захочет поупражнятся в искустве чесания левой ногой правое ухе, то ему придется написать весьма объемную реализацию кода для поддержки всего того, что может придти через нижнюю и верхние точки элемента - и массивы в том числе. Напомню на всякий случай: GetIndexData - это древняя затычка для пакетов на базе чистого ООП, который позволял реализовать в схеме выражаясь на языке ЯВУ - индексные массивы с вариантным типом данных. В пакетах на базе FTCG у нас для этого есть более удобные и главное оптимальные средства.

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

Скажем, в пакете Дельфи я могу придумать "читы" выполняющие обе задачи (рекурсию, и указатели на объект)
  • мультику добавлю св-во Name
  • если хочу создать один из "эдаких своих линков" устанавливаю просто пустой мультик, и делаю ему имя оригинала. EditMulti делаю одинаковыми - да хоть бы и прямым копированием
  • В CodeGen добавлю персональную обработку такой ситуации
  • Ответственность за то, что компиляция пройдет успешно (что имена методов будут не левые, к примеру) уже будет лежать на пользователе, т.е.. определенная продвинутость уже потребуется...
    Да легко И все будет работать (у теоретиков такое тоже случается). А вот правильно ли так поступать ...................



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

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

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1515
    #70: 2008-06-09 14:03:16 ЛС | профиль | цитата
    Galkov писал(а):
    Дальше, совершенно типовым случаем является наличие в полях данных указателей на другие объекты.

    это уже сделано. См. ECreator в последних обновлениях.

    На счет обсуждения поведения элементов в HiAsm чисто на интерфейсном уровне: не готов участвовать в подобной беседе, пока не уверуюсь в том, что возможно оптимально строить схемы по абсолютно идентичной логике для любого компилятора, языка, ОС, среды, кодогенератора и проч. Либо мы обрезаем функционал пакета, либо наоборот - перегружаем его кодом, обеспечивающим совместимость. Если принять эти допущения, то да - говорить в таком духе действительно имеет смысл.
    карма: 26
    0
    Разработчик
    Ответов: 25681
    Рейтинг: 2087
    #71: 2008-06-09 14:38:39 ЛС | профиль | цитата
    Dilma писал(а):
    См. ECreator в последних обновлениях

    А можно поинтересоваться -- в каком пункте это реализовано и как
    карма: 20

    0
    Ответов: 9906
    Рейтинг: 351
    #72: 2008-06-09 14:51:14 ЛС | профиль | цитата
    Dilma писал(а):
    это уже сделано. См. ECreator в последних обновлениях

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

    Мне казалось, что "объект-указатель" должен подвергаться другой кодогенерации, нежели просто линк или мультик...
    Плохо понимаю, как это можно сделать без изменения (правильнее - добавления) в CGT-API
    Ну нет их....
    Да и речь вроде не шла об добавлении некого (персонального для данного проекта) класса в палитру элементов - как с людьми-то общаться после такого, не будут они ничего себе добавлять из-за того, что у меня эдакая задача

    И самое главное, мне и постановочная часть совсем не кажется законченной.
    Собственно, я ждал каверзных вопросов от коллеги tsdima, который такие вещи сечет на раз
    Все это (указатель на объект) похоже на ##hselect для чужого экземпляра.

    Тут надо дополнительно решить два вопроса:
  • кого можно hselect, а кого нельзя. А для этого надо разобраться аккуратненько с тем, что есть наследование, как это выглядит в интерфейсе, и какое CGT-Api для этого требуется.
  • где будут происходить ответные события: на точках оригинала, или на точках "указателя". Мне представляется, что обе возможности крайне необходимы, разрешать это надо на уровне интерфейса для каждой точки, и готов аргументировать конкретными примерами... Но конечно это достойно глубокого обсуждения с коллегами - у них тоже примеры могут найтись.
    Ну как бы я не виноват, что этот вопрос более сложный, чем кажется на первый взгляд.
    Что здесь смешивается все сразу: наследование, объекто-указание, множественность экземпляров одного класса...
    Я просто правду рассказываю, что это НАДО...

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

    0
    Ответов: 3655
    Рейтинг: 69
    #73: 2008-06-09 15:28:32 ЛС | профиль | цитата
    Ну интерфейсно типа для всех одинаково, я вижу как:
    В компонентах иметь такое свойство.
    И специализированный мультик для данного вида схем.
    карма: 0

    0
    Ответов: 9906
    Рейтинг: 351
    #74: 2008-06-09 15:44:57 ЛС | профиль | цитата
    Вячеслав писал(а):
    Ну интерфейсно типа для всех одинаково, я вижу как:

    Ну ты типа - сказанул
    По всякому к твоему "вижу" - надо видео какое-то
    карма: 9

    0
    Ответов: 16884
    Рейтинг: 1237
    #75: 2008-06-09 15:53:34 ЛС | профиль | цитата
    Dilma писал(а):
    См. ECreator в последних обновлениях.
    nesco,Если работаешь в англ. интерфейсе, то лучше не запускать.
    карма: 24
    Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
    0
    Сообщение
    ...
    Прикрепленные файлы
    (файлы не залиты)