Вообще-то когда я начинал делать эту штуку, была идея выделять жирным локальные переменные и параметры методов. Однако поработав с такой подсветкой пару дней над реальным проектом оказалось что куда удобнее если выделять жирным поля и только поля, т.к. куда важнее использование и уж тем более изменение полей классов (особенно в многопоточной программе, и уж тем более статических), нежели обращение к параметрам методов или переменным в них объявленным.
[hi_octane]highlight_fields_with_bold.zip
прошу тщательно проверить, так как это моя первая попытка сделать что-то полезное, и либо включить в проект, либо указать на косяки и загоны.
Одна из мелких проблем — если интеграция уже установлена, то студия в упор не хочет брать в расчёт дополнительные шрифты и цвета сверх того что она уже когда-то взяла для диалога Fonts And Colors. Получается, что подсветка в редакторе появляется, но настраивать негде и только после сброса среды все шрифты становятся доступными для настройки. В хелпе к SDK был путь в реестре где студия сохраняет настройки цветов, но почему-то даже изменённых настроек немерла я там не нашёл. Может кто-нибудь знает, как сбросить _только_ настройки немерла для диалога Fonts And Colors? Тогда можно было бы проверять, изменился ли встроенный список цветов, и чистить старые настройки в реестре если изменился, заставляя студию подтягивать новые.
У меня создалось впечатление что моя подсветка добавила тормозов, особенно при скроллинге. Воспроизводится?
Если да, то может кто-нить подскажет как из ScanLexer'a получить доступ к текущему элементу Typedtree (конкретно, проверить является ли идентификатор FieldBuilder'ом)? Сейчас я это делаю через Project.FindObject, но сильно подозреваю что это самый медленный путь.
Закинул патченную версию коллеге, он открыл здоровенный проект и в нём здоровенный файл, и оказалось что действительно существенно тормозит. Проблема именно в Project.FindObject который, очевидно, недостаточно быстр. Соотвественно насущный вопрос — как из ScanLexer.GetToken() получить доступ к текущему элементу Typedtree (конкретно, проверить является ли идентификатор FieldBuilder'ом)? Пока сам не найду ответ или не подскажут, патч не используйте и уж тем более в репозиторий не коммитте.
P.S. Шикарно я тут нафлудил. Думаю до понедельника ещё постов 5 успею накидать сам себе по теме, пока все отдыхают
Здравствуйте, hi_octane, Вы писали:
_>Закинул патченную версию коллеге, он открыл здоровенный проект и в нём здоровенный файл, и оказалось что действительно существенно тормозит. Проблема именно в Project.FindObject который, очевидно, недостаточно быстр. Соотвественно насущный вопрос — как из ScanLexer.GetToken() получить доступ к текущему элементу Typedtree (конкретно, проверить является ли идентификатор FieldBuilder'ом)? Пока сам не найду ответ или не подскажут, патч не используйте и уж тем более в репозиторий не коммитте.
_>P.S. Шикарно я тут нафлудил. Думаю до понедельника ещё постов 5 успею накидать сам себе по теме, пока все отдыхают
У тебя ссылка битая на файл. Поправь. А по теме — попробуй мой
патчик. Если понравится и не будет тормозить ( у меня не тормозит), можно будет допилить и в репозиторий.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
СТ>У тебя ссылка битая на файл. Поправь.
Да вроде проверил с разных мест -- рабочая ссылка...
СТ>А по теме — попробуй мой патчик. Если понравится и не будет тормозить ( у меня не тормозит), можно будет допилить и в репозиторий.
Не тормозит, но и раскрашивает не совсем верно. Например в ситуации field1.field2 — field2 оказывается раскрашенным неверно, что только путает
Так что вопрос про замену Project.FindObject остаётся открытым.
Здравствуйте, hi_octane, Вы писали:
СТ>>У тебя ссылка битая на файл. Поправь.
_>Да вроде проверил с разных мест -- рабочая ссылка...
СТ>>А по теме — попробуй мой патчик. Если понравится и не будет тормозить ( у меня не тормозит), можно будет допилить и в репозиторий.
_>Не тормозит, но и раскрашивает не совсем верно. Например в ситуации field1.field2 — field2 оказывается раскрашенным неверно, что только путает Так что вопрос про замену Project.FindObject остаётся открытым.
Это я вчера починил, но там всплыли глюки, которые я весь вечер борол. Так что буду еще думать.
Зато этот патчик может пригодиться для раскрашивания полей текущего класса.
