nesco, После последнего обновления у меня перестали компилироваться все sha где есть панели и дочерние формы.

Мне кажется, что это как-то связано с последними изменениями в среде на предмет менеджеров. Думаю, что Dilma это дело поправит.

Tad, можешь обновить GodeGen, там уже испрален баг.

ну так пример для того и выложен - пробуем, думаем, делаем выводы...


есть у меня подозрение, что подписывание, которое там с некоторых пор присутсвует совершенно лишнее. Ты уверен, что было необходимо? Стандартные OnMouseEnter и OnMouseLeave не работают? Видимо из-за этого все и конфликтует.

Нет не уверен, это чисто экспериментальный вариант.


Точно... надо попытаться именно на них отработать.
------------ Дoбавленo:

Dilma, проверил, события работают нормально, но UseHintMeneger не отрабатывает на главной форме, хотя события выдаются в Win
Сейчас выложу, посмотри
------------ Дoбавленo:

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

Добавил на SVN новую группу элементов - еще одна небольшая демонстрация построения схемы по принципу клиент-сервер. В данном случае сервера это источники данных, а клиенты это менеджеры. Пример их использования:
code_9510.txt

В примере представлены два сервера - DS_StaticData и DS_UserData, а так же два клиента - MListBox и MEnumerator.
DS_StaticData - предоставляет доступ к статическим данным программы
DS_UserData - данные, определяемые пользователем
MListBox - визуальный элемент - список строк - позволяет отображать данные на экране
MEnumerator - не визуальный элемент, позволяет последователь выдать в поток все данные указанного столбца.

Теперь представим дальнейшее развитие этого направления: в качестве источников данных могут выступать менеджеры окон и процессов, файловая система(так же, как в пакете WEB), устройства компьютера, пользователи, таблицы любых баз данных, содержимое файлов(TXT, INI, XML и прочих) и многое многое другое. В качестве клиентов могут выступать: всевозможные графические контролы(списки строк, выпадающие списки, таблицы, меню и т.д.), элементы работы с данными(перечисление, поиск, конвертирование, сохранение и т.д.).
За примерами далеко ходить не надо - в настоящее время у нас в палитре уже есть представители многих слитых в одно целое комбинаций клиента и сервера:
- визуальные элементы со списком строк по умолчанию
- всевозможные енумераторы - EnumProcess, WinEnum, FileSearch...
- методы заполнения данными - ListBox.doAddDir, точки doloadFromXXX, DataGrid ...

Ну и после этого осталось только представить какие схемы и с какой простотой можно собирать имея разделенные по компонентам источники данных и их потребителей... Ну к примеру можно представить себе какую схему придется сейчас городить, если скажем захочется данные из таблицы локальной БД отобразить в ListBox на удаленной машине... А при наличие истоника данных нужной нам БД(Server), компонента умеющего все данные паковать в Stream(client), компонента умеющего все данные доставать из Stream(Server) и наконец компонента умеющего отобразить данные на экране(Client) вся схема сведется к 6-8 элементам и пятеркой связей между ними.

И по моей аналгии -- все остальное невидимый слой

глянем...


да, это очень удачное сравнение! Важно тут то, что дороги - это уровень пользователя, по ним он ездит каждый день туда сюда и обратно, ему интересны пробки на дорогах и их состояние зимой и во время дождя. А коммуникации - это то, что прокладывается кем-то(или самим пользователем в том числе) один раз и как можно подальше и поглубже. Очевидно, что если мы никак на схеме не показываем связь например между TCp_Server и TCP_Client или Mailslot_Server и Mailslot_Client, то и между менеджером и источником данных такой связи можно не показывать ввиду ее малой значимости и очевидности. Впринципе если кого-то это сильно будет огорчать можно всегда от сервера протянуть пунктиром линии, до всех клиентов, которые его используют.

Dilma, на базе аналогии у меня идея родилась, а не возможно ли реализовать визуально второй слой, со своими точками и линками, и сделать переключатель слоев
------------ Дoбавленo:


Вот, вот, я тоже хотел это предложить, и для конструкторов компонентов, видимость только бы помогла

возможно все, но полезность данного предложения я не вижу.

Dilma, а теперь простым языком объясни, что делает пример (code_9510)? Что-то я его совсем не понимаю...
------------ Дoбавленo:

Dilma, а теперь простым языком объясни, что делает пример (code_9510)? Что-то я его совсем не понимаю...

Тяжелова-то разбираться в здоровом коде, что куда пошло наружу. Ну может как-то крестиками с названиями на форме компонента отмечать, что есть такие внутренние точки

верхняя группа - демонстрация работы MListBox, который отображает данные из указаннного источника(можно в качестве DataSource ставить udata и static_data). Выбирая в нем пункты можно посмотреть какие данные поступают в поток.

средняя группа - пример реализации своего источника данных. Все 6 строк заполняются одними и теми же данными с первой колонкой - индексом, и со второй - числом 77

нижняя группа - пример перечисления значений колонки одного из источника данных.

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


речь идет про конструирование схем вообще? Или при визуализацию data_element св-тв?

Dilma, ну ведь ты же сначала сказал



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