Win32 API. Урок 35. RichEdit Control: подстветка синтаксиса — Архив WASM.RU

Все статьи

Win32 API. Урок 35. RichEdit Control: подстветка синтаксиса — Архив WASM.RU

  Вначале я хочу вас предупредить, что это сложная тема, не подходящая для начинающего. Это последний туториал из серии о RichEdit.

  Скачайте пример.

ТЕОРИЯ

  Подсветка синтаксиса - это предмет жарких дискуссий между создателями текстовых редакторов. Лучший метод (на мой взгляд) - это создать собственный edit control. Именно этот метод применяется во многих коммерческих приложений. Тем не менее для тех из нас, у кого нет времени на создание подобного контрола, лучшим вариантом будет приспособить существующий контрол к нашим нуждам.

  Давайте посмотрим, как может нам помочь RichEdit в реализации цветовой подсветки. Я должен сказать, что следующий метод "неверен": я всего лишь продемонстрирую ловушку, в которую угодили многие. RichEdit предоставляет сообщение EM_SETCHARFORMAT, которое позволяет вам менять цвет текста. На первый взгляд это именно то, что нам нужно (я знаю, потому что я стал одной из жертв этого подхода). Тем не менее, более детальное исследование покажет вам, что у данного сообщения есть несколько недостатков:

  EM_SETCHARFORMAT работает либо со всем текстом сразу, либо только с тем, который сейчас выделен. Если вам потребуется изменить цвет определенного слова, вам сначала придется выделить его.

  EM_SETCHARFORMAT очень медленна.

  У нее есть проблемы с позицией курсора в контроле RichEdit.

  Из всего вышеизложенного вы можете сделать вывод, что использование EM_SETCHARFORMAT - неправильный выбор. Я покажу вам "относительно верный" выбор.

  Мой метод заключает только в том, чтобы подсвечивать только видимую часть текста. В этом случае скорость подсветки не будет зависеть от размера файла. Вне зависимости от того, как велик файл, только маленькая его часть видна на экране.

  Как это сделать? Ответ прост:

  Субклассируйте контрол RichEdit и обрабатывайте сообщение WM_PAINT внутри вашей оконной процедуры.

  Когда она встречает сообщение WM_PAINT, вызывается оригинальная оконная функция, которая обновляет экран как обычно.

  После этого мы перерисовываем слова, которые нужно отобразить другим цветом.

  Конечно, этот путь не так прост: есть несколько вещей, которые нужно пофиксить, но вышеизложенный метод работает достаточно хорошо. Скорость отображения на экране более чем удовлетворительна.

  Теперь давайте сконцентрируемся на деталях. Процедура сабклассинга проста и не требует внимательного рассмотрения. Действительно сложная часть - это когда мы находим быстрый способ поиска слов, которые нужно подсветить. Это усложняется тем, что не надо подсвечивать слова внутри комментариев.

  Метод, который я использовал, возможно, не самый лучший, но он работает хорошо. Я уверен, что вы сможете найти более быстрый путь. Как бы то ни было, вот он:

  Я создал массив на 256 двойных слов, заполненный нулями. Каждый dword соответствует возможному ASCII-символу. Я назвал массив ASMSyntaxArray. Например, 21-ый элемент представляет собой 20h (пробел). Я использовал массив для быстрого просмотра таблицы: например, если у меня есть слово "include", я извлекаю первый символ из слова и смотрю значение соответствующего элемента. Если оно равно 0, я знаю, что среди слов, которые нужно подсвечивать, нет таких, которые бы начинались с "i". Если элемент не равен нулю, он содержит указатель на структуру WORDINFO, в которой находится информацию о слове, которое должно быть подсвечено.

  Я читаю слова, которые нужно подсвечивать, и создаю структуру WORDINFO для каждого из них.

WORDINFO struct
   WordLen dd ?  ; длина слова: используется для быстрого сравнения
   pszWord dd ?  ; указатель на слово
   pColor dd ?   ; указатель на dword, содержащий цвет, которым 
                 ; нужно подсвечивать слово
   NextLink dd ? ; указатель на следующую структуру WORDINFO
WORDINFO ends

  Как вы можете видеть, я использовал длину слова для убыстрения процесса сравнивания. Если первый символ слова совпадает, мы можем сравнить его длину с доступными словами. Каждый dword в ASMSyntaxArray содержит указатель на начало ассоциированного с ним массива WORDINFO. Например dword, который представляет символ "i", будет содержать указатель на связанный список слов, которые начинаются с "i". Поле pColor указывает на слово, содержащее цвет, которым будет подсвечиваться слово. pszWord указывает на слово, которое будет подсвечиваться, преобразованное к нижнему регистру.

  Память для связанного списка занимается из кучи программы по умолчанию, поэтому очищать ее легко и быстро: никакой чистки не требуется вообще.

  Список слов сохраняется в файле под названием "wordfile.txt", я получаю к нему доступ через API-функцию GetPrivateProfileString. Есть десять различных подсветок символов, начинающиеся с C1 до C10. Массив цветов называется ASMColorArray. Поле pColor каждой структуры WORDINFO указывает на один из элементов ASMColorArray. Поэтому можно легко изменять подсветку синтаксиса на лету: вам всего лишь нужно изменить dword в ASMColorArray и все слова, которые используют этот цвет, будут использовать новое значение.

ПРИМЕР

Здесь исходник. Возмите его из архива ;)

АНАЛИЗ

  Первое действие, совершаемое до вызова WinMain, это вызов FillHiliteInfo. Эта функция считывает содержимое wordfile.txt и обрабатывает его.

  FillHiliteInfo proc uses edi
     LOCAL buffer[1024]:BYTE
     LOCAL pTemp:DWORD
     LOCAL BlockSize:DWORD
     invoke RtlZeroMemory,addr ASMSyntaxArray,sizeof ASMSyntaxArray

  Initialize ASMSyntaxArray to zero.
     invoke GetModuleFileName,hInstance,addr buffer,sizeof buffer
     invoke lstrlen,addr buffer
     mov ecx,eax
     dec ecx
     lea edi,buffer
     add edi,ecx
     std
     mov al,"\"
     repne scasb
     cld
     inc edi
     mov byte ptr [edi],0
     invoke lstrcat,addr buffer,addr WordFileName

  Создаем путь до wordfile.txt: я предполагаю, что он всегда находится в той же папке, что и сама программа.

     invoke GetFileAttributes,addr buffer
     .if eax!=-1

  Я использую этот метод как быстрый путь для проверки, существует ли файл.

mov BlockSize,1024*10
invoke HeapAlloc,hMainHeap,0,BlockSize
mov pTemp,eax

  Резервируем блок памяти, чтобы сохранять слова. По умолчанию - 10 килобайт. Память занимаем из кучи по умолчанию.

@@:
  invoke GetPrivateProfileString,addr ASMSection,
         addr C1Key,addr ZeroString,pTemp,
         BlockSize,addr buffer
  .if eax!=0

  Я использовал GetPrivateProfileString, чтобы получить содержимое каждого ключевого слова в wordfile.txt, начиная с C1 и до C10.

inc eax
.if eax==BlockSize ; the buffer is too small
 add BlockSize,1024*10
 invoke HeapReAlloc,hMainHeap,0,pTemp,BlockSize
 mov pTemp,eax
jmp @B
.endif

  Проверяем, достаточно ли велик блок памяти. Если это не так, мы увеличиваем размер на 10k, пока он не окажется достаточно велик.

mov edx,offset ASMColorArray
invoke ParseBuffer,hMainHeap,
       pTemp,eax,edx,addr ASMSyntaxArray

  Передаем слова, хэндл на блок памяти, размер данных, считанных из wordfile.txt, адрес dword с цветом, который будет использоваться для подсветки слов и адреса ASMSyntaxArray.

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

 ParseBuffer proc uses edi esi hHeap:DWORD,
                  pBuffer:DWORD, nSize:DWORD, 
                  ArrayOffset:DWORD,pArray:DWORD
  LOCAL buffer[128]:BYTE
  LOCAL InProgress:DWORD
  mov InProgress,FALSE

  InProgress - это флаг, который я использовал, чтобы суметь определить, начался ли процесс сканирования. Если значение равно FALSE, vs

lea esi,buffer
mov edi,pBuffer
invoke CharLower,edi

  esi указывает на наш буфер, который будет содержать слово, взятое нами из списка слов. edi указывает на строку-список слов. Чтобы упростить поиск, мы приводим все символы к нижнему регистру.

     mov ecx,nSize
  SearchLoop:
     or ecx,ecx
     jz Finished
     cmp byte ptr [edi]," "
     je EndOfWord
     cmp byte ptr [edi],9   ; tab
     je EndOfWord

  Сканируем весь список слов в буфере, ориентируясь по пробелам, по которым определяем конец или начало слова.

     mov InProgress,TRUE
     mov al,byte ptr [edi]
     mov byte ptr [esi],al
     inc esi
  SkipIt:
     inc edi
     dec ecx
     jmp SearchLoop

  Если оказывается, что байт не является пробелом, то мы копируем его в буфер, где создается слово, а затем продолжаем поиск.

  EndOfWord:
     cmp InProgress,TRUE
     je WordFound
     jmp SkipIt

  Если пробел был найден, то мы проверяем значение в InProgress. Если значение равно TRUE, мы можем предположить, что был достигнут конец слова и мы можем поместить то, что у нас получилось в наш буфер (на который указывает esi) в структуру WORDINFO. Если значение равно FALSE, мы продолжамем сканирование дальше.

  WordFound:
     mov byte ptr [esi],0
     push ecx
     invoke HeapAlloc,hHeap,HEAP_ZERO_MEMORY,sizeof WORDINFO

  Если был достигнут конец слова, мы прибавляем 0 к буферу, чтобы сделать из слова строку формата ASCIIZ. Затем мы занимаем для этого слова блок памяти из кучи размером в WORDINFO.

     push esi
     mov esi,eax
     assume esi:ptr WORDINFO
     invoke lstrlen,addr buffer
     mov [esi].WordLen,eax

  Мы получаем длину слова в нашем буфере и сохраняем ее в поле WordLen структуры WORDINFO, чтобы использовать в дальнейшем при быстром сравнении.

     push ArrayOffset
     pop [esi].pColor

  Сохраняем адрес dword'а, который содержит цвет для подсветки слова, в поле pColor.

     inc eax
     invoke HeapAlloc,hHeap,HEAP_ZERO_MEMORY,eax
     mov [esi].pszWord,eax
     mov edx,eax
     invoke lstrcpy,edx,addr buffer

  Занимает блок памяти из кучи, чтобы сохранить само слово. В настоящее время структура WORDINFO готова для вставки в соответствующий связанный список.

     mov eax,pArray
     movzx edx,byte ptr [buffer]
     shl edx,2    ; multiply by 4
     add eax,edx

  pArray содержит адрес ASMSyntaxArray. Нам нужно перейти к dword'у, у которого тот же индекс, что и у значения первого символа слова. Поэтому мы помещаем первый символ в edx, а затем умножаем edx на 4 (так как каждый элемент в ASMSyntaxArray равен 4 байтам), а затем добавляем получившееся смещение к адресу ASMSyntaxArray. Теперь адрес нужного dword'а находится в eax.

     .if dword ptr [eax]==0
        mov dword ptr [eax],esi
     .else
        push dword ptr [eax]
        pop [esi].NextLink
        mov dword ptr [eax],esi
     .endif

  Проверяем значение dword'а. Если оно равно 0, это означает, что в настоящее время ключевых слов, которые начинаются с этого символа, нет. Затем мы помещаем адрес текущей структуры WORDINFO в этот dword.

  Если значение dword'а не равно 0, это означает, что есть по крайней мере одно ключевое слово, которое начинается с этого символа. Затем мы вставляем эту структуру WORDINFO в голову связанного списка и обновляем его поле NextLink, чтобы оно указывало на структуру WORDINFO.

     pop esi
     pop ecx
     lea esi,buffer
     mov InProgress,FALSE
     jmp SkipIt

  После того как операция завершена, мы начинаем следующую цикл сканирования, пока не будет достигнуть конец буфера.

invoke SendMessage,hwndRichEdit,EM_SETTYPOGRAPHYOPTIONS,
       TO_SIMPLELINEBREAK,TO_SIMPLELINEBREAK
invoke SendMessage,hwndRichEdit,EM_GETTYPOGRAPHYOPTIONS,1,1
.if eax==0       ; means this message is not processed
  mov RichEditVersion,2
.else
 mov RichEditVersion,3
 invoke SendMessage,hwndRichEdit,EM_SETEDITSTYLE,
        SES_EMULATESYSEDIT,SES_EMULATESYSEDIT
.endif

  После того, как контрол RichEdit создан, нам нужно определить его версию. Этот шаг необходим, так как поведение EM_POSFROMCHAR отличается в зависимости от версии RichEdit, а EM_POSFROMCHAR жизненно важна для нашей процедуры подсветки. Я никого не видел документированного способа определения версии RichEdit, поэтому я пошел окольным путем. Я устанавливаю опцию, которая свойственная версии 3.0 и немедленно возвращает его значение. Если я могу получить значение, я предполагаю, что версия этого контрола 3.0.

  Если вы используете контрол RichEdit версии 3.0, вы можете заметить, что обновление цвета фонт на больших файлах занимает довольно много времени. Похоже, что эта проблема существует только в версии 3.0. Я нашел способ обойти это, заставив конрол эмулировать поведение контрола edit, послав сообщение EM_SETEDITSTYLE.

  После того, как мы получили информацию о версии контрола, мы переходим к сабклассированию контрола RichEdit. Сейчас мы рассмотрим новую процедуру для обработки сообщений.

  NewRichEditProc proc hWnd:DWORD, uMsg:DWORD, 
                  wParam:DWORD, lParam:DWORD
     .......
     .......
     .if uMsg==WM_PAINT
        push edi
        push esi
        invoke HideCaret,hWnd
        invoke CallWindowProc,OldWndProc,hWnd,
               uMsg,wParam,lParam
        push eax

  Мы обрабатываем сообщение WM_PAINT. Во-первых, мы прячем курсор, чтобы избежать уродливых артефактов после подсветки. Затем мы передаем сообщение оригинальной процедуре richedit, чтобы оно обновило окно. Когда CallWindowProc возвращает управление, текс обновляется согласно его обычному цвету/бэкграунду. Теперь мы можем сделать подсветку синтаксиса.

mov edi,offset ASMSyntaxArray
invoke GetDC,hWnd
mov hdc,eax
invoke SetBkMode,hdc,TRANSPARENT

  Сохраняем адрес ASMSyntaxArray в edi. Затем мы получаем хэндл контекста устройства и делаем бэкграунд текста прозрачными, чтобы при выводе нами текста использовался текущий бэкграундный цвет.

invoke SendMessage,hWnd,EM_GETRECT,0,addr rect
invoke SendMessage,hWnd,EM_CHARFROMPOS,0,addr rect
invoke SendMessage,hWnd,EM_LINEFROMCHAR,eax,0
invoke SendMessage,hWnd,EM_LINEINDEX,eax,0

  Мы хотим получить видимый текст, поэтому сначала нам требуется узнать размеры области, которую необходимо форматировать, послав ему EM_GETRECT. Затем мы получаем индес ближайшего к левому верхнему углу символа с помощью сообщения EM_CHARFROMPOS. Как только мы получаем индекс первого символа, мы начинаем делать цветовую подсветку, начиная с этой позиции. Но эффект может быть не так хорош, как если бы начали с первого символа линии, в которой находится символ. Вот почему мне нужно было получить номер линии, в которой находится первый видимый символ, с помощью сообщения EM_LINEFROMCHAR. Чтобы получить первый символ этой линии, я посылаю сообщение EM_LINEINDEX.

mov txtrange.chrg.cpMin,eax
mov FirstChar,eax
invoke SendMessage,hWnd,EM_CHARFROMPOS,0,addr rect.right
mov txtrange.chrg.cpMax,eax

  Как только мы получили индекс первого символа, сохраняем его на будущее в переменной FirstChar. Затем мы получаем последний видимый символ, посылая ему EM_CHARFROMPOS, передавая нижний правый угол форматируемой области в lParam.

        push rect.left
        pop RealRect.left
        push rect.top
        pop RealRect.top
        push rect.right
        pop RealRect.right
        push rect.bottom
        pop RealRect.bottom
        invoke CreateRectRgn,RealRect.left,RealRect.top,
               RealRect.right,RealRect.bottom
        mov hRgn,eax
        invoke SelectObject,hdc,hRgn
        mov hOldRgn,eax

  Во время подсветки синтаксиса, я заметил один побочный эффект этого метода: если у контрола richedit'а есть отступ (который вы можете указать, послав сообщение EM_SETMARGINS контролу RichEdit), DrawText пишет поверх него. Поэтому мне требуется создать функцией CreateRectRgn ограничительный регион, в который будут выводиться результат выполнения функций GDI.

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

mov ecx,BufferSize
lea esi,buffer
.while ecx>0
 mov al,byte ptr [esi]
 .if al==" " || al==0Dh || al=="/" || al=="," || al=="|" || \
     al=="+" || al=="-" || al=="*" || al=="&" || al=="<" \ 
     || al==">" || al=="=" || al=="(" || al==")" || al=="{" \
     || al=="}" || al=="[" || al=="]" || al=="^" || al==":" \
     || al==9
  mov byte ptr [esi],0
.endif
dec ecx
inc esi
.endw

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

lea esi,buffer
mov ecx,BufferSize
.while ecx>0
 mov al,byte ptr [esi]
.if al!=0

  Ищем в буфере первый символ, не равный NULL, т.е. первый символ слова.

push ecx
invoke lstrlen,esi
push eax
mov edx,eax

  Получаем длину слова и помещаем его в edx.

movzx eax,byte ptr [esi]
.if al>="A" && al<="Z"
   sub al,"A"
   add al,"a"
.endif

  Конвертируем символ в нижний регистр (если он в верхнем).

shl eax,2
add eax,edi     ; edi содержит указатель на массив указателей 
                ; на структуры WORDINFO
.if dword ptr [eax]!=0

  После этого мы переходим к соответствующему dword'у в ASMSyntaxArray и проверяем равно ли его значение 0. Если это так, мы можем перейти к следующему слову.

mov eax,dword ptr [eax]
assume eax:ptr WORDINFO
.while eax!=0
    .if edx==[eax].WordLen

  Если значение dword'а не равно нулю, он указывает на связанный список структур WORDINFO. Мы делаем пробег по связанному списку, сравнивая длину слова в нашем буфере с длиной слова в структуре WORDINFO. Это быстрый тест, проводимый до полноценного сравнения слов, что должно сохранить несколько тактов.

pushad
invoke lstrcmpi,[eax].pszWord,esi
.if eax==0

  Если длины обоих слов равны, мы переходим к сравнению слов с помощью lstrcmpi.

popad
mov ecx,esi
lea edx,buffer
sub ecx,edx
add ecx,FirstChar

  Мы создаем индекс символа из адресов первого символа совпадающего слова в буфере. Сначала мы получаем его относительное смещение из стартового адреса буфера, а затем добавляем индекс символа первого видимого символа к нему.

pushad
.if RichEditVersion==3
   invoke SendMessage,hWnd,EM_POSFROMCHAR,addr rect,ecx
.else
  invoke SendMessage,hWnd,EM_POSFROMCHAR,ecx,0
  mov ecx,eax
  and ecx,0FFFFh
  mov rect.left,ecx
  shr eax,16
  mov rect.top,eax
.endif
popad

  Узнав индекс первого символа слова, которое должно быть подсвечено, мы переходим к получению его координат с помощью сообщения EM_POSFROMCHAR. Тем не менее это сообщение интерпретируется различным образом в RichEdit 2.0 или 3.0. В RichEdit 2.0 wParam содержит индес символа, а lParam не используется. Сообщение возвращается в eax. В RichEdit 3.0 wParam - это указатель на структуру POINT, которая будет заполнена координатой, а lParam содержит индекс символа.

  Как вы можете видеть, передача неверных аргументов EM_POSFROMCHAR может привести к непредсказуемым результатам. Вот почему я должен определить версию RichEdit.

mov edx,[eax].pColor
invoke SetTextColor,hdc,dword ptr [edx]
invoke DrawText,hdc,esi,-1,addr rect,0

  Как только мы получили координату, с которой надо начинать, мы устанавливаем цвет текста, который указан в структуре WORDINFO.

  В заключение я хочу сказать, что этот метод можно улучшить различными способами. Например я получаю весь текст, который начинается от первой до последней видимой линии. Если линии очень длинные, качество может пострадать из-за обработки невидимых слов. Вы можете оптимизировать это, получая видимый текст полинейно. Также можно улучшить алгоритм поиска. Поймите меня правильно: подсветка синтаксиса, используемая в этом примере, быстрая, но она может быть быстрее. :)

2002-2013 (c) wasm.ru