Редактировалось 3 раз(а), последний 2025-01-09 12:49:42

Dilma, это тебя в гости откатило, оригинально


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

в ближайшие две недели это будет происходить с завидной регулярностью...

Набросал на примере Hint вариант организации менеджеров, о которых я ранее уже говорил(см. аттач). В чем основная идея: поскольку оформление хинта чаще всего общее для всех элементов проекта, то логичнее было бы определять это оформление один раз, т.е. иметь отдельный элемент для данной задачи. Почему удобнее реализовать данный элемент именно в качестве менеджера, а не банальной надстройки над неким общим классом в пространстве проекта(например, как это сделано с KOL.Application)? Основных причин тут две:
1) реализация в качестве надстройки над глобальным классом не позволит создавать индивидульные параметры хинта для контролов
2) в качестве хинта может выступать не только всплывающие окошко, но и вообще что угодно

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

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


заметил такие особенности работы хинта:
- событие onShow(оно же WM_MOUSEHOVER) происходит два раза и с задержкой
- заставить hint показаться на экране и затем исчезнуть через какое-то время так же большая проблема. Такую возможность вообще говоря надо в настройки тоже вынести

(для работы примера нужно последнее обновление среды)

Не понял, у меня в примере у каждого контрола свой хинт, со своими параметрами, или это сказано про менэджер

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

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

------------ Дoбавленo:


Dilma, извини за мою тупость, но в CGTShare.pas с SVN нет propGetLinkedElementInfo

------------ Дoбавленo:


Да, еще хотел спросить -- а для чего два элемента -- hiHintManager и hiUserHintManager, почему нельзя сделать один элемент hiHintManager

MIBII - денейролизатор

А что это такое

Шутка.

nesco, а так никак сделать нельзя?

у тебя в примере были глобальные классы? читай внимательнее.


должна регулироваться от нуля и выше


были проблемы с коммитом...


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

------------ Дoбавленo:



поздно - на SVN этого уже нет.

Еще что касается HintManager организации - в текущем варианте, если св-во Hint определеною, а HintManager нет, то пользователь подсказки над элементом не увидит. Поэтому видимо нужно в SetHintManager отловить ситуацию hm = nil и присвоить менеджеру некий глобальный IHintManager с зашитыми настройками.

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

Не, я просто спросил, почему так. Пусть будет модульная, мне приблизительно понятна ее организация, гляда на пример.

если там не -1 ставить, то проявляется это:



"пусть будет" - это термин, которым лучше характеризовать равнозначные варианты реализации одной и той же задачи. Менеджер от пачки св-тв в элементе отличаются слишком сильно, чтобы так умалять его достоинства. Вот еще один пример вспомнился: есть у формы такое замечательное св-во SavePosName, над которым извратились настолько, что в зависимости от формата записи оно сохраняет настройки в разные места системы и под разными именами. А ведь на самом деле это классическая задача(тривиальная если точнее) в рамках технологии менеджеров. Всего-то надо было создать интерфейс ISaveParams и реализовать как минимум элементы RegistrySettings, InitFileSettings(XMLSettings...). А может еще и UserSettings для сохранения этих параметров вообще где угодно... А потом это св-во перенести из формы в Win.pas. Делов-то.

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


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

nesco, а компилировать "пустую" форму с GroupBox(или с дочерней формой) не пробовал

Да, есть такое.
Вот такого типа строка выдает ошибку

А если компилировать из папки HiAsm?

У меня есть несколько схем, которые не компилируются из другого места, нежели папка HiAsm. Ошибку выдают различные компоненты (в зависимости от схемы), но ошибка одна и таже Identifier not found.