Здравствуйте, VladD2, Вы писали:
J>>Для вложенных подхинтов больше никак и не сделаешь, потому что их может быть очень много, засовывать их в исходную строку вряд-ли захочется, да и пустая трата ресурсов это. VD>У нас есть два типа вложенных хинтов: VD>1. Полноценая ссылка на другое определение.
Это всмысле подхинт? То-есть при наведении на какой-то текст в хинте появляется ещё один хинт. Для таких хинтов текст запрашивается через делегат из вне.
VD>2. Простий текстовый хинт. VD>Примером второго типа являютсэ хинты для типов параметров. VD>Их будет очень неудобно оформлять полноценными хинтами. VD>Мне нужно чтобы я мог задать весь текст хинта (с простыми подхинтами) за один прием.
Такая функциональность предусмотрена тоже. Но в таком хинте может быть только плоский текст.
J>>А, вот оно зачем. Ну у меня просто хинт показывается внизу целевого прямоугольника. VD>Область может быть довольно большой, так что хинт будет висеть где-то внизу экрана. VD>Это одна из проблем текущей риализации. Сейчас я пытаюсь обойти ее путем задавания в качестве области одного токена.
Хм... Ну видимо тогда придется дать возможность задать точку показа хинта.
Здравствуйте, VladD2, Вы писали:
VD>Я до еонца недели (в лучшем случае до пятницы) на GPRS-е, так что качать ничего не могу. VD>Так что доводи до ума и тогда посмотрим.
Оно уже устарело .
Я уже почти доделал, осталось:
1. Узнать, как получить целевой прямоугольник для показа вложенных хинтов, вопрос есть в dotnet.gui
Ещё осталась проблема: когда владелец хинта теряет фокус — хинт надо прятать, но в текущей реализации владельца нет, думаю это редкая ситуация — можно забить.
Ну и когда студия будет на WPF и появится WPF-контролл-владелец-хинта — можно будет выкинуть кучу интеропа и костылей.
не понял сути вопроса.
J>Ещё осталась проблема: когда владелец хинта теряет фокус — хинт надо прятать, но в текущей реализации владельца нет, думаю это редкая ситуация — можно забить.
Эта проблема так же легко решается с помощю таймера.
Надо запросить окно владельца и по таймеру проверять в фокусе ли оно.
J>Ну и когда студия будет на WPF и появится WPF-контролл-владелец-хинта — можно будет выкинуть кучу интеропа и костылей.
Возможн... а возможно гимору прибавится.
В прочем, возможно они просто сделают стандартные хинты тоже WPF-ыми.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну в WPF есть специальные классы для представления текста и документов вообще. С помощью них и визуализируется текст подсказки. Но для того чтобы показывать вложенные хинты при наведении на определенные Span'ы нужно как-то узнавать их местоположение на экране, но так как эти элементы рисованием себя не занимаются, то никаких средств для узнавания их размера/положения в них соответственно нет. Вот собственно проблема в том, что я не знаю как получить размер и местоположение Span'а, представляющего область с хинтом, чтобы узнать целевой прямоугольник для хинта.
J>>Ещё осталась проблема: когда владелец хинта теряет фокус — хинт надо прятать, но в текущей реализации владельца нет, думаю это редкая ситуация — можно забить. VD>Эта проблема так же легко решается с помощю таймера. VD>Надо запросить окно владельца и по таймеру проверять в фокусе ли оно.
Нет уже желания этим заниматься.
VD>В прочем, возможно они просто сделают стандартные хинты тоже WPF-ыми.
Здравствуйте, Andir, Вы писали:
A>Тоже скачал, посмотрел. A>У меня на увеличенном DPI hint показывается гораздо ниже окна.
Тоже известный баг, там у меня device-пиксели и wpf-пиксели не конвертируются друг в друга, а просто присваиваются без конвертации. Нужно разбираться, как осуществлять конвертирование.
Здравствуйте, jenyavb, Вы писали:
J>...Span'ы нужно как-то узнавать их местоположение на экране, но так как эти элементы рисованием себя не занимаются, то никаких средств для узнавания их размера/положения в них соответственно нет. Вот собственно проблема в том, что я не знаю как получить размер и местоположение Span'а, представляющего область с хинтом, чтобы узнать целевой прямоугольник для хинта.
В WPF я не спец. Могу только предположить, что возможно нужно сложить в них (или их) другой элемент, у которого можно узнать размеры и местоположение.
VD>>Надо запросить окно владельца и по таймеру проверять в фокусе ли оно.
J>Нет уже желания этим заниматься.
Так дела не делаются.
И вообще, на мой взгляд, внашей профессии самое интересное — преодолевать трудности. Точнее, удовольствие возникающее после преодоления, этих самых, трудностей.
VD>>В прочем, возможно они просто сделают стандартные хинты тоже WPF-ыми.
J>На стандартные хинты мышь не наведешь.
Дык, они свои напишут. Вреламе 2010-й студии я уже видел нечто подобное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
J>>...Span'ы нужно как-то узнавать их местоположение на экране, но так как эти элементы рисованием себя не занимаются, то никаких средств для узнавания их размера/положения в них соответственно нет. Вот собственно проблема в том, что я не знаю как получить размер и местоположение Span'а, представляющего область с хинтом, чтобы узнать целевой прямоугольник для хинта. VD>В WPF я не спец. Могу только предположить, что возможно нужно сложить в них (или их) другой элемент, у которого можно узнать размеры и местоположение.
Ну в крайнем случае придется использовать такой вариант...
VD>>>Надо запросить окно владельца и по таймеру проверять в фокусе ли оно. J>>Нет уже желания этим заниматься. VD>Так дела не делаются. VD>И вообще, на мой взгляд, внашей профессии самое интересное — преодолевать трудности. Точнее, удовольствие возникающее после преодоления, этих самых, трудностей.
У меня оно возникает, только когда решение получлось красивым, а не лишь-бы работало.
VD>>>В прочем, возможно они просто сделают стандартные хинты тоже WPF-ыми. J>>На стандартные хинты мышь не наведешь. VD>Дык, они свои напишут. Вреламе 2010-й студии я уже видел нечто подобное.
Ага, теперь показывается как надо.
Теперь ещё:
Windows 7 — в таскбаре видно два окна (ну может это так и надо?),
Получилось какими-то манипуляциями добиться того, что Hint перестал исчезать.
Здравствуйте, Andir, Вы писали:
A>Windows 7 — в таскбаре видно два окна (ну может это так и надо?),
Забыл поставить ShowInTaskbar = false для окна-костыльчика. Дело в том, что для того чтобы конвертировать девайс-пиксели в wpf-писекли и обратно нежен Visual, который отображается на экране, вот это окошко для этих целей и существует.
A>Получилось какими-то манипуляциями добиться того, что Hint перестал исчезать.
Здравствуйте, jenyavb, Вы писали:
J>Поправил баг, вот последняя версия.
А почему он, собственно, не исчезает?
А ещё, если хинт переместить (наводим мышь на слона, перемещаем форму, опять наводим), то субхинт на месте остаётся. По мне, так лучше, чтоб субхинт вообще исчезал.
Re[3]: Небольшой фикс
От:
Аноним
Дата:
29.08.09 20:34
Оценка:
Здравствуйте, jenyavb, Вы писали:
J>Поправил баг, вот последняя версия.
Насколько я понял, простого способа вывести на экран символы "<" та ">" нету (а они могут и понадобиться).
Re[3]: Небольшой фикс
От:
Аноним
Дата:
29.08.09 20:41
Оценка:
Здравствуйте, jenyavb, Вы писали:
J>Поправил баг, вот последняя версия.
Но в целом приятный контрол. А нельзя как-то уголки скруглить на один пиксел, как в Шарпдевелопе?
Здравствуйте, Аноним, Вы писали:
А>А почему он, собственно, не исчезает?
Должен исчезать. Видимо это баг. У меня не воспроизводится.
А>А ещё, если хинт переместить (наводим мышь на слона, перемещаем форму, опять наводим), то субхинт на месте остаётся. По мне, так лучше, чтоб субхинт вообще исчезал.
А как удается перемещать форму, так чтобы хинт не скрывался?
.
Там надо импортировать GetModuleHandle. Но я уверен, должно сработать.
