Надеюсь все еще актуально Тут новая версия.
Основные изменения коснулись парсера.
Доступные тэги:
1. <b>,<u>,<i> — стили
2. <pre> — сохранение форматирования
3. <lb/> — перенос строки
4. <code> — блок текста со шрифтом Courier New
4. <span hint=""> — блок текста с опциональным подхинтом
5. <keyword> — блок текста синего цвета
6. <ref hint="" handler=""> — ссылка
Также реализована фича с автолейаутом параметров методов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, capgoat, Вы писали:
C>>Действительно, тестовый проект старый. C>>Вот подправил.
VD>На первый взгляд очень хорошо!
VD>Что нужно сделать чтобы добавить отступы (мерджинг) по краям (чтобы текст не "прилипал" к краям)? VD>И как изменить размер шрифта используемый по умолчанию, а так же в режиме code/pre? А то шрифт несколько размытый получается и мелковатый.
Отступ можно наглядно контроллировать свойством Padding в Border элементе xaml файла.
Добавил тэг <font size, face, color>. Нужные блоки соответственно оборачиваем этим тэгом. Файл
Здравствуйте, jenyavb, Вы писали:
J>Багрепорты — только с Exception'ами и вылетами. Логика ещё не доделана, я и сам всё знаю.
При старте:
System.ComponentModel.Win32Exception was unhandled
Message="Невозможно установить нелокальный обработчик без дескриптора модуля"
Source="AdvancedHints"
ErrorCode=-2147467259
NativeErrorCode=1428
StackTrace:
at AdvancedHints.HookManager.EnsureSubscribedToGlobalMouseEvents() in D:\Projects\AdvancedHints\Hooks\HookManager.Callbacks.cs:line 211
at AdvancedHints.HookManager.add_MouseMove(MouseEventHandler value) in D:\Projects\AdvancedHints\Hooks\HookManager.cs:line 25
at AdvancedHints.AdvancedHint..ctor(Action`1 linkClickedNotifyer, Func`2 subHintGetter, IDictionary`2 styles) in D:\Projects\AdvancedHints\AdvancedHint.cs:line 44
at AdvancedHints.TestForm..ctor() in D:\Projects\AdvancedHints\TestForm.cs:line 17
at AdvancedHints.Program.Main() in D:\Projects\AdvancedHints\Program.cs:line 13
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, gloomy rocker, Вы писали:
GR>Здравствуйте, jenyavb, Вы писали:
J>>"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
GR>А может передавать в этот хинт XAML-разметку? Это почти как HTML только для WPF-движка. Кодбихайнд там скорее всего не нужен будет, а создать UIElement из XAML — очень просто.
XAML — это ИМХО больше чем нужно... Тогда можно будет любую разметку туда загнать... А нужно наоборот ограничить.
Для более красивого отображения хинтов в VS-интеграции нужен контрол который бы позволял бы вывести хинт с подсветкой участков текста и активными участками текста.
Это должно быть что-то вроде HTML-я (но сильно упрощенного) в котором можно было бы декоративно задать:
1. Штифтовое оформление (цвет, жарность, италик).
2. Задать подхинты (т.е. некоторые области текста, например, те что описывают типы) должны при наведении так же отображать хинты.
3. Задать активные области. При нажатии на такую область должно вызваться событие на которое, например, можно перейти к описанию метода.
4. Хитн должен вести себя похоже на другие хинты: масштабировать размеры под экран и точку в которой отображается хинт; скрываться если курсор ушел из области текста для которой хинт задан и т.п.
Нужно это для того, чтобы сделать хинты в редакторе более понятными и удобными.
Мне кажется, что лучше всего было бы реализовать это дело на базе WPF, так как броузер для таких задач может оказаться громоздким и тормозным. Хотя... надо пробовать.
Может кто-нибудь возьмется за эту задачу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется, что лучше всего было бы реализовать это дело на базе WPF, так как броузер для таких задач может оказаться громоздким и тормозным. Хотя... надо пробовать.
На WPF можно реализовать довольно просто. Там даже есть базовый примитив Popup. Вывод содержимого — можно сделать через документы или обычные контроллы.
Связываться с браузером не советую — корявый он жутко...
Здравствуйте, jenyavb, Вы писали:
J>На WPF можно реализовать довольно просто. Там даже есть базовый примитив Popup. Вывод содержимого — можно сделать через документы или обычные контроллы. J>Связываться с браузером не советую — корявый он жутко...
Мне хотелось бы не тратить времени на это "просто". Я с WPF не знаком и времени у меня очень мало. Задача интересная и не сложная, так что возможно найдутся те кто ею захотят заняться.
Мне же нужен метод в который я задам размеченый текст и координаты области в которой нужно отобразить хинт, а чтобы все остальное делал этот контрол.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Мне хотелось бы не тратить времени на это "просто". Я с WPF не знаком и времени у меня очень мало. Задача интересная и не сложная, так что возможно найдутся те кто ею захотят заняться.
Ну, я бы мог попробовать...
VD>Мне же нужен метод в который я задам размеченый текст и координаты области в которой нужно отобразить хинт, а чтобы все остальное делал этот контрол.
"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
Здравствуйте, jenyavb, Вы писали:
J>"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
Если знаешь паскаль в jvcl есть конторол ThtLabel кажись там используеться разметка как Влад описал.
Я тоже попробую сделать, взяв за основу реализацию из jvcl.
Здравствуйте, jenyavb, Вы писали:
J>Ну, я бы мог попробовать...
Давай.
J>"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
Самое важно — это удобство использования контрола другими. Так что тут упрощать не надо. Можно взять самый примитивный синтаксис, но он должен быть. За основу можно взять ХМЛ. Тогда разбирать ничего не прийдется. Достаточно будет скормить его тому же XElement из linq2xml и получить ту самую объектную модель. Желательно, чтобы формат выглядело примерно так:
Описание метода <bold>RunErrorOccured</bold>.
</code>
Где:
<code> — определяет, что данная часть хинта должна выводиться моноширинным шрифтом (например, Courier).
<ref> — предопределенный тег который приводит к отображению ссылки с всплывающей подсказкой.
<hint> — предопределенный тег который приводит к отображению всплывающей подсказкой.
<keyword> — стиль который можно заранее настроить (добавить). В нем нужно иметь возможность задавать bold, italic и цвет. В данном случае синий цвет.
<bold> — стиль который можно заранее настроить. В данном случае он должен делать выделенный им текст жирным.
В результате на экране должен появиться примерно следующий текст:
internal RunErrorOccured(
loc : Location,
msg : string) : void
Описание метода RunErrorOccured.
Где Location является ссылкой отображающей хинт, RunErrorOccured ссылкой без хинта, а для string отображается только хинт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Denom, Вы писали:
D>Если знаешь паскаль в jvcl есть конторол ThtLabel кажись там используеться разметка как Влад описал. D>Я тоже попробую сделать, взяв за основу реализацию из jvcl.
Думаю, что написать такой хинт с использованием WPF будет намного проще и при этом результата будет иметь более привлекательный вид.
Еще проще (наверно) сделать это дело на базе WebBrouserControl. При этом вообще можно обойтись трасформацией ХМЛ-я в ХТМЛ. Но при этом не уверен, что будет хороший отклик. Все же форматирование ХТМЛ-я занимает время, а хинт нужно показать максимально быстро после появления информации. В прочем, возможно это и не критично.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Думаю, что написать такой хинт с использованием WPF будет намного проще и при этом результата будет иметь более привлекательный вид. VD>Еще проще (наверно) сделать это дело на базе WebBrouserControl. При этом вообще можно обойтись трасформацией ХМЛ-я в ХТМЛ. Но при этом не уверен, что будет хороший отклик. Все же форматирование ХТМЛ-я занимает время, а хинт нужно показать максимально быстро после появления информации. В прочем, возможно это и не критично.
Браузер — вешь убогая. Я даже сомневаюсь что там удастся прехватить наведение/клик на активные области...
Здравствуйте, jenyavb, Вы писали:
J>А на каком языке? Гуй вы вроде на шарпе пишете?
На шарпе или немерле. Главное, чтобы никаких лишних зависимостей не было.
Если делать на WPF, то конечно шарп предпочтительнее, так как для него есть WPF-дизайнеры.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jenyavb, Вы писали:
J>"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
А может передавать в этот хинт XAML-разметку? Это почти как HTML только для WPF-движка. Кодбихайнд там скорее всего не нужен будет, а создать UIElement из XAML — очень просто.
Здравствуйте, VladD2, Вы писали:
J>>"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
VD>Самое важно — это удобство использования контрола другими. Так что тут упрощать не надо. Можно взять самый примитивный синтаксис, но он должен быть. За основу можно взять ХМЛ. Тогда разбирать ничего не прийдется. Достаточно будет скормить его тому же XElement из linq2xml и получить ту самую объектную модель.
Не так все просто с XML. Нужно как-то проверять корректность, этого XLM. Нужно вводить тег "абзац", потому как в XLM переносы строки не учитываются, да и через линк их не получишь. Необходим так-же элемент-корень. Так-что ИМХО нафиг такие сложности... Да и идеологии WPF это не соответствует.
Еще проблема есть в автоматическом скрытии хинта. Для этого нужно иметь элемент-родитель, которому принадлежит хинт, которого в случае со студией нет. А без родителя позицию курсора в WPF вроде как и не получишь.
Ещё нужно подумать, удобен ли будет этот хинт пользователю. Ведь если уводить курсор вниз, в область хинта, хинт исчезать не будет, как это обычно происходит.
Здравствуйте, jenyavb, Вы писали:
J>Не так все просто с XML. Нужно как-то проверять корректность, этого XLM.
Дык его то как раз проверить элементарно. На то есть и схемы и API. Читаешь себе теги... понял, что за тег — ОК, не понял — исключение.
J>Нужно вводить тег "абзац", потому как в XLM переносы строки не учитываются, да и через линк их не получишь.
Естественно. Но в этом нет никаких проблем. Сделать аналог тега P в ХТМЛ-е не проблема.
J>Необходим так-же элемент-корень.
Это что, проблема? Кореть можно или добавлять по ходу дела, или требовать изначально.
J>Так-что ИМХО нафиг такие сложности... Да и идеологии WPF это не соответствует.
WPF не соответствует? В WPF как раз основной формат преставления именно ХМЛ.
J>Еще проблема есть в автоматическом скрытии хинта.
Это не проблема, а часть функционала который нужно реализовать.
Как раз родитель не нужен. Ну, или надо брать родителя как у всплывающего окна комбобокса. Иначе будет много проблем.
Хинту фокус вообще не нужен.
Скрывать же его очень просто. Надо при открытии хинта запускать таймер и на каждое срабатывание хинта проверять где курсор мыши. Если он в области переданной при открытии хинта или внутри хинта, то ничего не делать, иначе закрывать хинт. Плюс хинт нужно закрывать при нажатии любой клавиши или при переключении фокуса. Вот с этим нужно немного повозиться. Там возможно прийдется сабкласить окна. Это не сложно, но надо иметь некоторый опыт.
J> Для этого нужно иметь элемент-родитель, которому принадлежит хинт, которого в случае со студией нет. А без родителя позицию курсора в WPF вроде как и не получишь.
Это не родитель, а владелец. Окно к которому принадлежит хинт есть. Это окно редактора.
J>Ещё нужно подумать, удобен ли будет этот хинт пользователю. Ведь если уводить курсор вниз, в область хинта, хинт исчезать не будет, как это обычно происходит.
Ну, дык если бы всего этого не надо было, то я бы и сам за 10 минут на коленке все слабал. Птому я и предложил кому-то взяться за эту задачу. Задача не сложная и полностью автономная. Все проблемы которые возникнут можно решить здесь или в дотнетном форуме. А опыт очень даже полезный. Да и контрол полезен многим будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gloomy rocker, Вы писали:
GR>А может передавать в этот хинт XAML-разметку? Это почти как HTML только для WPF-движка.
Вопрос только насколько быстро? Не будет тормозить при этом вывод хинта?
GR>Кодбихайнд там скорее всего не нужен будет, а создать UIElement из XAML — очень просто.
Нам нужна реакция на события (переход по ссылке). Но ее лучше делать во внешнем коде.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>WPF не соответствует? В WPF как раз основной формат преставления именно ХМЛ.
XAML — всего-лишь язык разметки. Формат представления — дерево UI. Идея в том, что контрол выполняет лишь определенную функцию, а его представление можно менять как угодно и в него загонять любой возможный контент. Но это можно решить, вынеся xml-разметку в статический хелпер.
J>>Еще проблема есть в автоматическом скрытии хинта. VD>Это не проблема, а часть функционала который нужно реализовать.
Одно другому не мешает .
VD>Как раз родитель не нужен. Ну, или надо брать родителя как у всплывающего окна комбобокса. Иначе будет много проблем.
Не понял, это ты про Win32? Я на WPF вроде делаю...
VD>Хинту фокус вообще не нужен.
Ясень пень. В WPF есть примитив Popup, который такую функциональность дает.
VD>Скрывать же его очень просто. Надо при открытии хинта запускать таймер и на каждое срабатывание хинта проверять где курсор мыши. Если он в области переданной при открытии хинта или внутри хинта, то ничего не делать, иначе закрывать хинт. Плюс хинт нужно закрывать при нажатии любой клавиши или при переключении фокуса. Вот с этим нужно немного повозиться. Там возможно прийдется сабкласить окна. Это не сложно, но надо иметь некоторый опыт.
Опять ты про Win32? В WPF я не знаю, как получить абсолютное положение курсора на экране, может кто подскажет?
J>> Для этого нужно иметь элемент-родитель, которому принадлежит хинт, которого в случае со студией нет. А без родителя позицию курсора в WPF вроде как и не получишь. VD>Это не родитель, а владелец. Окно к которому принадлежит хинт есть. Это окно редактора.
Здравствуйте, jenyavb, Вы писали:
J>XAML — всего-лишь язык разметки. Формат представления — дерево UI. Идея в том, что контрол выполняет лишь определенную функцию, а его представление можно менять как угодно и в него загонять любой возможный контент. Но это можно решить, вынеся xml-разметку в статический хелпер.
Не понимаю в чем сложност. Задача фактически вылевается в трансформацию хмл.
J>Не понял, это ты про Win32? Я на WPF вроде делаю...
WPF не в вакууме живет. В итоге он будет хоститься в некотором окне Windows.
J>Опять ты про Win32? В WPF я не знаю, как получить абсолютное положение курсора на экране, может кто подскажет?
Этот вопрос лучше задать в форуме .Net GUI.
Но я уверен, что можно просто пользоваться API WinForms, который является надстройкой над Win API.
J>Нужно, чтобы это был WFP'шный UIElement.
Вовсе нет! Нам нужно окно-владелец для окна в котором бубет хоститься WPF-контрол.
Так что это могут быть обычные окна Windows.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
GR>>А может передавать в этот хинт XAML-разметку? Это почти как HTML только для WPF-движка. VD>Вопрос только насколько быстро? Не будет тормозить при этом вывод хинта?
Здесь поможет только эксперимент.
GR>>Кодбихайнд там скорее всего не нужен будет, а создать UIElement из XAML — очень просто. VD>Нам нужна реакция на события (переход по ссылке). Но ее лучше делать во внешнем коде.
В WPF вроде как можно декларативно делать привязку к командам, правда я сам этого не делал, т.к. пишу под SilverLight (урезанный WPF).
То есть реализовать команду можно в коде, а привязку к ней сделать в XAML. Только вот не думаю, что удобно будет эти привязки во входном XAML задавать.
Реально XAML — разметка графа объектов. Так вот можно определить свою иерархию объектов, которые описывают хинт, а конкретный хинт описывать не XML-ем, а XAML-ом, т.к. есть стандартный способ преобразовать XAML в реальный граф объектов. Сам XAML наверно можно будет генерить StringTemplate-ом.
Например если имеется XAML
Здравствуйте, VladD2, Вы писали:
VD>Не понимаю в чем сложност. Задача фактически вылевается в трансформацию хмл.
Только сейчас понял, что код вида
<p>test <bold>test</bold> test</p>
не корректен для XML и спроецировать его через LINQ2XLM не получится...
Видимо придется писать свой мини-парсер?
J>>Не понял, это ты про Win32? Я на WPF вроде делаю... VD>WPF не в вакууме живет. В итоге он будет хоститься в некотором окне Windows.
Думаю окно владелец в WPF не понадобится...
J>>Нужно, чтобы это был WFP'шный UIElement. VD>Вовсе нет! Нам нужно окно-владелец для окна в котором бубет хоститься WPF-контрол. VD>Так что это могут быть обычные окна Windows.
Это не контрол, а окно, так что хостить его не надо.
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, gloomy rocker, Вы писали:
GR>>Здравствуйте, jenyavb, Вы писали:
J>>>"что-то вроде HTML-я (но сильно упрощенного)" — не думаю, что это хороший способ задания текста, нужен будет парсер этого синтаксиса, да и генерировать текст из кода будет сложнее. Проще создавать какое-либо дерево с форматированным текстом.
GR>>А может передавать в этот хинт XAML-разметку? Это почти как HTML только для WPF-движка. Кодбихайнд там скорее всего не нужен будет, а создать UIElement из XAML — очень просто.
J>XAML — это ИМХО больше чем нужно... Тогда можно будет любую разметку туда загнать... А нужно наоборот ограничить.
Согласен, но вариант с XML и HTML — это еще больше, чем нужно.
Здравствуйте, gloomy rocker, Вы писали:
J>>XAML — это ИМХО больше чем нужно... Тогда можно будет любую разметку туда загнать... А нужно наоборот ограничить. GR>Согласен, но вариант с XML и HTML — это еще больше, чем нужно.
Если есть способ ограничить XAML лишь своими элементами, то можно и попробовать... Потому как с XML есть проблема
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, gloomy rocker, Вы писали:
J>>>XAML — это ИМХО больше чем нужно... Тогда можно будет любую разметку туда загнать... А нужно наоборот ограничить. GR>>Согласен, но вариант с XML и HTML — это еще больше, чем нужно.
J>Если есть способ ограничить XAML лишь своими элементами, то можно и попробовать... Потому как с XML есть проблема
. Так-же нужно подумать, как обрабатывать нажатия на ссылки.
Если ограничения в рантайме будет достаточно, то этого вполне можно добиться, определив свою иерархию объектов. По сути XAML — это средство определения графа объектов, что собственно и нужно. А из каких объектов будет состоять этот граф — нам решать.
То есть если есть метод:
public static NemerleHint ParseXaml(string xaml)
{
...
}
То ошибка будет либо при загрузке XAML в случае, если будет передан кривой XAML, либо при приведении object к NemerleHint, если передан правильный XAML, но описывающий не NemerleHint.
Если же нужна проверка в компайлтайме, то XML/HTML/XAML — вообще тупиковый вариант.
Здравствуйте, gloomy rocker, Вы писали:
GR>Если ограничения в рантайме будет достаточно, то этого вполне можно добиться, определив свою иерархию объектов. По сути XAML — это средство определения графа объектов, что собственно и нужно. А из каких объектов будет состоять этот граф — нам решать.
Так, а как собственно парсить Xaml? То-есть какие классы/методы для этого использовать?
GR>Если же нужна проверка в компайлтайме, то XML/HTML/XAML — вообще тупиковый вариант.
Здравствуйте, jenyavb, Вы писали:
J>Так, а как собственно парсить Xaml? То-есть какие классы/методы для этого использовать?
Для этого есть класс XamlReader
Т.е. для парсинга XAML нужно сделать что-то типа такого:
public class NemerleHint
{
public static NemerleHint Parse(string hintXaml)
{
using(var sr = new StringReader(hintXaml))
using(var xr = new XmlTextReader(sr))
return (NemerleHint)XamlReader.Load(xr);
}
}
Еще есть перегруженный метод Load, который принимает аргумент типа ParserContext. Возможно, придется с ним поколдовать...
GR>>Если же нужна проверка в компайлтайме, то XML/HTML/XAML — вообще тупиковый вариант. J>Достаточно и в рантайме....
Ок. Тогда либо XamlReader.Load ругнется, к стати вполне культурно и понятно, либо приведение типа object к NemerleHint.
Здравствуйте, VladD2, Вы писали:
J>>Только сейчас понял, что код вида J>>
J>><p>test<bold>test</bold> test</p>
J>>
J>>не корректен для XML и спроецировать его через LINQ2XLM не получится... J>>Видимо придется писать свой мини-парсер? VD>С чего ты это сзвзял? Это совершенно корректный XML.
Хм... Может я чего-то не знаю, но как же вытаскивать линком выделенные жирным подстроки? Заворочивать их в ещё один вид тегов?
VD>Кстати, тег болд должен быть определяемый, а не фиксированный.
Я понимаю. Там все теги, кроме p, ref и hint — получается определяемые.
Здравствуйте, jenyavb, Вы писали:
J>Хм... Может я чего-то не знаю, но как же вытаскивать линком выделенные жирным подстроки? Заворочивать их в ещё один вид тегов?
А что там делать то?
Грузишь XML через XElement и разбираешь if-ами что получилось.
Для этой задачи XSLT за глаза хватило бы.
Задача ведь на трансформивание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А что там делать то? VD>Грузишь XML через XElement и разбираешь if-ами что получилось. VD>Для этой задачи XSLT за глаза хватило бы. VD>Задача ведь на трансформивание.
Ещё раз повторяю:
<p>test1 <bold>test2</bold> test3</p>
В таком коде подстроки "test1 " и " test3" не являются xml-элементами, поэтому через XElement.Elements() они не вытащатся, а просто пропустятся.
Ещё хотел спросить, нужно ли реализовывать задержку перед показом тултипа или это будет делаться из вне?
Здравствуйте, jenyavb, Вы писали:
J>Ещё раз повторяю: J>
J><p>test1 <bold>test2</bold> test3</p>
J>
J>В таком коде подстроки "test1 " и " test3" не являются xml-элементами, поэтому через XElement.Elements() они не вытащатся, а просто пропустятся.
Ты лучше бы не теоретизировал, а попробовал бы:
using System;
using System.Xml.Linq;
class Program
{
static void Main()
{
var str = "<p>test1 <bold>test2</bold> test3</p>";
var xml = XElement.Parse(str);
Console.WriteLine("Parsed XML: " + xml);
foreach (var node in xml.DescendantNodes())
Console.WriteLine("Node type: {0,7} Value: '{1}'", node.NodeType, node);
}
}
Elements() возвращает только XElement-ы, т.е. теги. Но кроме XElement-ов есть еще и текстовые ветки (и куча других).
J>Ещё хотел спросить, нужно ли реализовывать задержку перед показом тултипа или это будет делаться из вне?
Задержек никаких не надо. Надо сосредоточиться на автоматическом закрытии по таймеру и на выравнивании размеров под текст и доступный объем места на экране.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jenyavb, Вы писали:
J>Хм... Может я чего-то не знаю, но как же вытаскивать линком выделенные жирным подстроки? Заворочивать их в ещё один вид тегов?
Здравствуйте, VladD2, Вы писали:
VD>Ты лучше бы не теоретизировал, а попробовал бы: VD>Elements() возвращает только XElement-ы, т.е. теги. Но кроме XElement-ов есть еще и текстовые ветки (и куча других).
уже подсказали.
J>>Ещё хотел спросить, нужно ли реализовывать задержку перед показом тултипа или это будет делаться из вне? VD>Задержек никаких не надо. Надо сосредоточиться на автоматическом закрытии по таймеру и на выравнивании размеров под текст и доступный объем места на экране.
Здравствуйте, jenyavb, Вы писали:
VD>>Еще нужен тег <code> или <pre> который бы выводил текст моноширинным шрифтом.
J>А почему для него отдельный тег? Его ведь тоже стилем можно сделать.
Можно, если стили будут поддерживать дополнение. Тег <code> должен задавать только шнифт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
AddStileTag() — позволяет задать теги стилей.
Show() — позволяет показать хинт на экране.
activeArea — это область экрана при выходе из которой нужно автоматически скрывать хинт. Естесвтенно, что если курсор вошел в хинт, то хинт скрывать не надо.
showAt — это координата где нужно отображать хинт. X задает смешение от верха экрана где должна находиться верхняя граница хинта. Y задает горизонтальную точку относительно которой нужно выравнивать хинт. Если хинт влезает в окно, то он должен начинаться н с координаты Y. Если он выходит за пределы окна, то хинт может сдвигаться влево, вплоть до левого края окна.
text — текст хинта размеченый тегами.
action — делегат который должен вызываться в случае если пользователь нажал на активную область. В единственный строковый параметр делегата должна передоваться строка заданная в теге ref (чтобы можно было понять что за ссылка нажата.
Если Show вызван в то время когда открыт хинт, то хинт не мерцая должен изменить свое содержание. Это нужно, чтобы можно было организовать нечто вроде гипертекстовой навигации. Скажем нажал я в хинте описывающем метод на нектороый тип и в хинте должено отобразиться описание этого типа.
Кстати, логично было бы предусмотреть маленькую кнопку (в углу хинта) навигации назад (так чтобы она была видна если задан некий флаг).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, мне нужен класс с приблизительно следующим описанием:
VD>enum ThreeState VD>{ VD> | NoDefined VD> | Set VD> | Unset VD>}
VD>
class AdvancedHint
{
public AdvancedHint(
Action<string> linkClickedNotifyer,
Func<string, string> subHintGetter,
IDictionary<string, Func<Span>> styles)
public void Show(Rectangle targetRect, string hintText)
public void Hide()
}
linkClickedNotifyer — делегат, для оповещения о клике на ссылку
subHintGetter — делегат, получающий содержимое вложенного хинта. есть еще простые хинты с указанием текста по месту, но без форматирования.
styles — словарь, с делегатами-фабриками Span'ов — текстовых элементов WPF (это и есть кастом-теги)
showAt у меня нет, ибо позиция курсора и так известна.
VD>Если Show вызван в то время когда открыт хинт, то хинт не мерцая должен изменить свое содержание. Это нужно, чтобы можно было организовать нечто вроде гипертекстовой навигации. Скажем нажал я в хинте описывающем метод на нектороый тип и в хинте должено отобразиться описание этого типа. VD>Кстати, логично было бы предусмотреть маленькую кнопку (в углу хинта) навигации назад (так чтобы она была видна если задан некий флаг).
Здравствуйте, VladD2, Вы писали:
VD>Кстати, логично было бы предусмотреть маленькую кнопку (в углу хинта) навигации назад (так чтобы она была видна если задан некий флаг).
Здравствуйте, jenyavb, Вы писали:
J>subHintGetter — делегат, получающий содержимое вложенного хинта. есть еще простые хинты с указанием текста по месту, но без форматирования.
Какое-то переусложнение. Это же еще и использовать придется .
J>showAt у меня нет, ибо позиция курсора и так известна.
Курсора мыши? Но хинты то должны показываться относительно кода, а не относительно курстора. Иначе не ясно будет к чему они относятся.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jenyavb, Вы писали:
J>А при ёё нажатии что, делегат вызывать?
Одно из двух. Или просто вызваться некое событие. Или должен открываться предыдущий хинт (если мы не закрывая один хинт открыли еще один на событие нажатия мыши).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
J>>subHintGetter — делегат, получающий содержимое вложенного хинта. есть еще простые хинты с указанием текста по месту, но без форматирования. VD>Какое-то переусложнение. Это же еще и использовать придется .
Для вложенных подхинтов больше никак и не сделаешь, потому что их может быть очень много, засовывать их в исходную строку вряд-ли захочется, да и пустая трата ресурсов это.
J>>showAt у меня нет, ибо позиция курсора и так известна. VD>Курсора мыши? Но хинты то должны показываться относительно кода, а не относительно курстора. Иначе не ясно будет к чему они относятся.
А, вот оно зачем. Ну у меня просто хинт показывается внизу целевого прямоугольника.
Что сложного то? Кстати каждый параметр может быть null. Примерно так юзается:
var hint = new AdvancedHint(
linkId => Console.WriteLine(linkId),
hintId => GenerateHint(hintId),
new Dictionary
{
{ "bold", ()=> new Bold() },
{ "pre", ()=> new Run { FontFamily = "Courier New" } }
));
hint.Show(boundRect, "bla-bla-bla");
Параметр с текстом хинта из метода Show пришлось убрать, поскольку Show нужно вызывать при движении по нужной области, чтобы когда мышь остановится он сработал, а постоянный парсинг — дело не дешевое.
J>Параметр с текстом хинта из метода Show пришлось убрать, поскольку Show нужно вызывать при движении по нужной области, чтобы когда мышь остановится он сработал, а постоянный парсинг — дело не дешевое.
Хотя нет, это не верно. Ведь если пользователь сделал клик в целевой обласи, то хинт не должен больше появляться снова, пока курсор не выйдет из обласи и зайдет туда вновь, значит эту логику нужно убрать в хинт, сигнатура Show останется как есть, но вызывать его нужно только при входе курсора в целевую область.
Y>System.ComponentModel.Win32Exception was unhandled
Y> Message="Невозможно установить нелокальный обработчик без дескриптора модуля"
Y> Source="AdvancedHints"
Y> ErrorCode=-2147467259
Y> NativeErrorCode=1428
Y> StackTrace:
Y> at AdvancedHints.HookManager.EnsureSubscribedToGlobalMouseEvents() in D:\Projects\AdvancedHints\Hooks\HookManager.Callbacks.cs:line 211
Y> at AdvancedHints.HookManager.add_MouseMove(MouseEventHandler value) in D:\Projects\AdvancedHints\Hooks\HookManager.cs:line 25
Y> at AdvancedHints.AdvancedHint..ctor(Action`1 linkClickedNotifyer, Func`2 subHintGetter, IDictionary`2 styles) in D:\Projects\AdvancedHints\AdvancedHint.cs:line 44
Y> at AdvancedHints.TestForm..ctor() in D:\Projects\AdvancedHints\TestForm.cs:line 17
Y> at AdvancedHints.Program.Main() in D:\Projects\AdvancedHints\Program.cs:line 13
Y> at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
Y> at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
Y> at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
Y> at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
Y> at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
Y> at System.Threading.ThreadHelper.ThreadStart()
Y> InnerException:
Да, тут проблема есть. Для WinAPI функции SetWindowHook нужно указать хэндл текущего модуля. Где его взять — я так и не разобрался. Ещё не помешало бы указать туда ID потока. Сейчас туда просто передатся IntPtr.Zero и 0, соответственно. Кто разбирается в WinAPI — помогите, плиз.
Здравствуйте, jenyavb, Вы писали:
J>Да, тут проблема есть. Для WinAPI функции SetWindowHook нужно указать хэндл текущего модуля. Где его взять — я так и не разобрался. Ещё не помешало бы указать туда ID потока. Сейчас туда просто передатся IntPtr.Zero и 0, соответственно. Кто разбирается в WinAPI — помогите, плиз.
Так-с, поглядел код, а зачем ты вообще WinAPI используешь, неужели в .NET нет аналогов поставить хуки на MouseClick, MouseDown итд? То же самое кстати с клавиатурой.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
J>>Да, тут проблема есть. Для WinAPI функции SetWindowHook нужно указать хэндл текущего модуля. Где его взять — я так и не разобрался. Ещё не помешало бы указать туда ID потока. Сейчас туда просто передатся IntPtr.Zero и 0, соответственно. Кто разбирается в WinAPI — помогите, плиз. Y>Так-с, поглядел код, а зачем ты вообще WinAPI используешь, неужели в .NET нет аналогов поставить хуки на MouseClick, MouseDown итд? То же самое кстати с клавиатурой.
Здравствуйте, yumi, Вы писали:
Y>Так-с, поглядел код, а зачем ты вообще WinAPI используешь, неужели в .NET нет аналогов поставить хуки на MouseClick, MouseDown итд? То же самое кстати с клавиатурой.
Да, я кажется понял тебя, я вижу 2 пути, первое — принимать указатель на основную форму и подписаться на его события MouseXXX в своем AdvancedHint. Второй путь:
Здравствуйте, jenyavb, Вы писали:
J>Здравствуйте, yumi, Вы писали:
J>>>Да, тут проблема есть. Для WinAPI функции SetWindowHook нужно указать хэндл текущего модуля. Где его взять — я так и не разобрался. Ещё не помешало бы указать туда ID потока. Сейчас туда просто передатся IntPtr.Zero и 0, соответственно. Кто разбирается в WinAPI — помогите, плиз. Y>>Так-с, поглядел код, а зачем ты вообще WinAPI используешь, неужели в .NET нет аналогов поставить хуки на MouseClick, MouseDown итд? То же самое кстати с клавиатурой.
J>Да вроде нет.
Посмотри http://support.microsoft.com/kb/318804, может поможет. Кстати, увидел случайно, KeyboardHookStruct лучше назвать KeyboardLLHookStruct, т.к. по структуре оно вроде low level.
И да, я тут чуть поэкспериментировал. Если убрать _LL и передать Id треда, перестает падать, но в этом случае, нужно в обработчике MouseHookProc, нужно обрабатывать структуру MouseHookStruct, вместо MouseLLHookStruct. Только я не знаю, подойдет ли тебе обычный обработчик, а не low level.
Здравствуйте, yumi, Вы писали:
Y>Посмотри http://support.microsoft.com/kb/318804, может поможет. Кстати, увидел случайно, KeyboardHookStruct лучше назвать KeyboardLLHookStruct, т.к. по структуре оно вроде low level.
Её вообще нужно назвать, как она в WinAPI называется.
Y>И да, я тут чуть поэкспериментировал. Если убрать _LL и передать Id треда, перестает падать, но в этом случае, нужно в обработчике MouseHookProc, нужно обрабатывать структуру MouseHookStruct, вместо MouseLLHookStruct. Только я не знаю, подойдет ли тебе обычный обработчик, а не low level.
Судя по вот этому — Keyboard/MouseHookStruct передается только при low lewel хуке, а HookStruct не делятся на обычные и LL. Вобщем я —
Здравствуйте, jenyavb, Вы писали:
J>Для вложенных подхинтов больше никак и не сделаешь, потому что их может быть очень много, засовывать их в исходную строку вряд-ли захочется, да и пустая трата ресурсов это.
У нас есть два типа вложенных хинтов:
1. Полноценая ссылка на другое определение.
2. Простий текстовый хинт.
Примером второго типа являютсэ хинты для типов параметров.
Их будет очень неудобно оформлять полноценными хинтами.
Мне нужно чтобы я мог задать весь текст хинта (с простыми подхинтами) за один прием.
J>А, вот оно зачем. Ну у меня просто хинт показывается внизу целевого прямоугольника.
Область может быть довольно большой, так что хинт будет висеть где-то внизу экрана.
Это одна из проблем текущей риализации. Сейчас я пытаюсьобойти еепутем задавания в качестве области одного токена.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, jenyavb, Вы писали:
J>Решил выложить посмотреть то, что уже сделано. J>Это ещё не окончательный вариант, некоторых фич ещё нет. Окончательный сделаю через 1-3 дня...
J>AdvancedHints.zip
J>Багрепорты — только с Exception'ами и вылетами. Логика ещё не доделана, я и сам всё знаю.
Я до еонца недели (в лучшем случае до пятницы) на GPRS-е, так что качать ничего не могу.
Так что доводи до ума и тогда посмотрим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>Поправил баг, вот последняя версия.
Но в целом приятный контрол. А нельзя как-то уголки скруглить на один пиксел, как в Шарпдевелопе?
Здравствуйте, Аноним, Вы писали:
А>А почему он, собственно, не исчезает?
Должен исчезать. Видимо это баг. У меня не воспроизводится.
А>А ещё, если хинт переместить (наводим мышь на слона, перемещаем форму, опять наводим), то субхинт на месте остаётся. По мне, так лучше, чтоб субхинт вообще исчезал.
А как удается перемещать форму, так чтобы хинт не скрывался?
А>>Но в целом приятный контрол. А нельзя как-то уголки скруглить на один пиксел, как в Шарпдевелопе? J>Попробую, если с Popup'ом проблем не будет, то можно конечно. Хотя незнаю нужно-ли, в студии то все квадратное.
Попробовал. Как я и думал — уродский попап не дает этого сделать. Фон у него черный, по этому по углам в случае скругления Border'а с подсказкой остается чернота. А свойства для визуальной настройки Popup'а просто ничего не делают.
Re: Кто может написать контрол - крутой хинт?
От:
Аноним
Дата:
30.08.09 20:13
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Есть задачка...
VD>Может кто-нибудь возьмется за эту задачу?
Ну я тоже решил попробовать написать этот хинт. Вот что из этого получилось, авось кому-нибудь пригодится.
Здравствуйте, Аноним, Вы писали:
VD>>Может кто-нибудь возьмется за эту задачу? А>Ну я тоже решил попробовать написать этот хинт. А>Вот что из этого получилось, авось кому-нибудь пригодится.
Класс!
Однако тут тоже присутствует проблема с увеличенным DPI — хинт появляется гораздо ниже кнопки (и вложенный хинт тоже).
Здравствуйте, Andir, Вы писали:
A>Класс! A>Однако тут тоже присутствует проблема с увеличенным DPI — хинт появляется гораздо ниже кнопки (и вложенный хинт тоже).
Да и после клика на кнопку хинт уже не должен появляться.
ещё одна реализация появилась. Как теперь быть, что будешь выбирать?
Re[3]: Кто может написать контрол - крутой хинт?
От:
Аноним
Дата:
31.08.09 17:22
Оценка:
J>Твоя реализация вроде хорошая. Но почему не сказал, что делаешь? Зачем одну и ту же работу два раза делать?
Да я поначалу и не думал доводить ее до ума, так хотел лишний раз потренкиться, благо задача попалась довольно интересная.
VD>Интересно. Но сразу столкнулся с проблемой. Попытался обернуть описание метода тегом <pre> и получил исключение: VD> ...
VD>ЗЫ
VD>Лучше класть файлы на наш сервер. Это можно сделать в профайле или в ветке "Мой RSDN\Файлы".
А такое не поддерживается, стили задаются только внутри основных тэгов text, keуword, ref.
Если есть интерес, могу дорабатывать контрол под требования.
Только не помешало бы более подробное ТЗ, несколько типичных примеров использования, более точное описание формата входного текста.
В частности, есть непонятки с переносом текста, нужен ли для него отдельный тэг?
Здравствуйте, Аноним, Вы писали:
А>А такое не поддерживается, стили задаются только внутри основных тэгов text, keуword, ref. А>Если есть интерес, могу дорабатывать контрол под требования.
Вопрос к анониму (кстати, неплохо было бы материализоваться ) и к jenyavb...
Не могли бы вы (каждый) произвести ревизию кода "конкурирующей фирмы" (с) Ося Бендер и выявить более интересные решения?
Как итог, было бы оптимально, получить один проект, но более гибкий, устойчивый и простой в реализации.
А>Только не помешало бы более подробное ТЗ, несколько типичных примеров использования, более точное описание формата входного текста.
Собственно использование планируется в интеграции Nemerle с VS (это, думаю, очевидно).
Отсюда и использование:
1. Вывод подсказок к членам классов и сслкам на них (методам, свойствам, полям и событиям).
2. Вывод подсказок к типам и ссылкам на них.
3. Вывод подсказок к различным участкам кода.
4. Вывод сообщений компилятора. В них так же встречаются описания (сигнатуры) методов и других элементов языка.
Загляни в редактор кода. Вот что-то подобное хотелось бы видеть в хинте. Наша задача — это в наиболее удобной форме дать информацию о коде. Скажем если у нас есть вызов функции:
func(x, y)
и пользователь подвел мышь к "func", то нам нужно вывести хинт описывающий:
1. Сигнатуру метода. В этой сигнатуре типы должны представляться односложными идентификаторами (без точек внутри), и каждый тип должен быть под-хинтом/ссылко показывающим полное имя типа (с указанием пространства имен и всех внешних типов), а ссылка долна позволять перейти к определению этого типа (или открыть некий более развернутый хинт.
2. Описание взятое из XML-документации (т.е. просто текст описывающий функцию, ее параметры и ее возвращаемое значение).
3. Список сообщений об ошибках, если таковые есть). Сообщения об ошибках могут быть иерархическими и так же могут содержать сингатуры методов (и т.п.) которые так же имеет смысл представлять в сжатом виде и встроенными под-подсказками.
А>В частности, есть непонятки с переносом текста, нужен ли для него отдельный тэг?
Мне кажется было бы удобнее использовать обычный конец строки (т.е. сочетание символов "\r\n", или отдельно "\n" или "\r"). А вот тег для выравнивания возможно был бы уместен. В прочем, для того чтобы ответить на этот вопрос нужно по-использовать ихнт на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ещё одна реализация появилась. Как теперь быть, что будешь выбирать?
Я видел.
Пока детально ни твой, ни его хинт не смотрел.
Вообще, хорошо было бы, если бы вы произвели код-ревью проектов друг-друга и подумали как создать один общий проект использующий хорошие идеи из обоих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В некоторых тегах (например, в теге code), некоторые символы должны интерпретироваться как "мягкие" концы строк и как символы "табличного выравнивания". В примере выше символом мягкого конца
строки должна служить запятая, а символом табличного выравнивания двоеточие.
Реализация хинта должна попытаться втиснуть содержимое такого тега в область хинта. Если это удается, то никаких дополнительных действий производить не надо. Если — нет, то нужно добавить концы строк полсе каждой запятой и по табуляции перед каждым двоеточием.
В итоге код в хинте должен выглядить следующим образом:
Здравствуйте, capgoat, Вы писали:
C>Надеюсь все еще актуально
Да, очень.
Открыл, попробовал...
1. Путь к проекту в солюшене и ссылке (в тестовом проекте) прописан не верно.
2. При прпытке открыть хинт вылетает исключение — NotSupportedException("text"), короче в хинте есть теги "text", но их парсинг не реализован.
C>Тут новая версия. C>Основные изменения коснулись парсера.
C>Также реализована фича с автолейаутом параметров методов.
Можно подробнее?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>1. Путь к проекту в солюшене и ссылке (в тестовом проекте) прописан не верно. VD>2. При прпытке открыть хинт вылетает исключение — NotSupportedException("text"), короче в хинте есть теги "text", но их парсинг не реализован.
Судя по всему ты прислал не ту версию тестового проекта. Кроме тега "text", еще происходит вылет на теге "hint".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, VladD2, Вы писали:
VD>>1. Путь к проекту в солюшене и ссылке (в тестовом проекте) прописан не верно. VD>>2. При прпытке открыть хинт вылетает исключение — NotSupportedException("text"), короче в хинте есть теги "text", но их парсинг не реализован.
VD>Судя по всему ты прислал не ту версию тестового проекта. Кроме тега "text", еще происходит вылет на теге "hint".
Действительно, тестовый проект старый. Вот подправил.
А автолейаут, вкратце, работает так: задаем спец. ширину контрола (WrapWidth), если при построении контрола ширина превысит WrapWidth,
происходит новое пересторение, при к-м параметры методов располагаются вертикально.
Здравствуйте, capgoat, Вы писали:
C>Вот подправил. C>А автолейаут, вкратце, работает так: задаем спец. ширину контрола (WrapWidth), если при построении контрола ширина превысит WrapWidth, C>происходит новое пересторение, при к-м параметры методов располагаются вертикально.
Хорошо бы примерчик.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, capgoat, Вы писали:
C>Действительно, тестовый проект старый. C>Вот подправил.
На первый взгляд очень хорошо!
Что нужно сделать чтобы добавить отступы (мерджинг) по краям (чтобы текст не "прилипал" к краям)?
И как изменить размер шрифта используемый по умолчанию, а так же в режиме code/pre? А то шрифт несколько размытый получается и мелковатый.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здорово, но нужно именно дефолтный шрифт менять.
VD>А то во вложенных хинтах шрифт слишком млекий. Не задавать же и для них шрифты явно каждый раз?
Ok, добавлю свойства FontFamily, FontSize, еще какие пожелания?
VD>1. Как распознаются параметры?
По шаблону регексом (см. ParamParser). Или нужно более подробное описание?
VD>2. Заменил шрифт на боле большой (чтобы все перенеслось): VD>
Здравствуйте, capgoat, Вы писали:
VD>>А то во вложенных хинтах шрифт слишком млекий. Не задавать же и для них шрифты явно каждый раз?
C>Ok, добавлю свойства FontFamily, FontSize, еще какие пожелания?
Сделвай два набора свойств:
ProportionalFontFamily
ProportionalFontSize
и:
FixedFontFamily
FixedFontSize
Первое для обычных тегов, второе для code и pre.
VD>>1. Как распознаются параметры?
C>По шаблону регексом (см. ParamParser). Или нужно более подробное описание?
Можно задавать его тегами. Это не сложно.
Все равно остальне теги придется генерировать.
Что-то вроде:
C>Тут пробел перед msg сохранился, подумаю как это поправить.
Лучше просто задавать параметры отдельными тегами. Одни плюс будут. И тебе проще, и формат стандартный, и если что изменить отображение не сложно, и регекспы не нужны (меньше ошибок, выше скорость).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Очень мутно. Совершенно не понято что тварится и зачем. Очень много императившины, хотя она там совсем не к месту.
Сдается мне, что все можно сделать во много раз проще и безопаснее.
Можно описать логику происходящего при парсинге? Что пытаешся получить? Как? Зачем?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.