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

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

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

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


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

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