**This is a question about Iczelion's syntax highlighting algo in his Tut 35. If it needs to be moved to the Main section so be it.**

; Get the visible text into buffer
lea eax,buffer
mov txtrange.lpstrText,eax
invoke SendMessage,hWnd,EM_GETTEXTRANGE,0,addr txtrange
mov esi,eax ; esi == size of the text
.if esi>0
mov BufferSize,eax
; Search for comments first
push edi
push ebx
lea edi,buffer
mov edx,edi ; used as the reference point
mov ecx,esi
mov al,";"
repne scasb
je NextSkip
jmp NoMoreHit
dec edi
inc ecx
mov pString,edi
mov ebx,edi
sub ebx,edx
add ebx,FirstChar
mov txtrange.chrg.cpMin,ebx
; search the end of line or the end of buffer
push eax
mov al,0Dh
repne scasb
pop eax
.if ecx>0
mov byte ptr [edi-1],0
mov ebx,edi
sub ebx,edx
add ebx,FirstChar
mov txtrange.chrg.cpMax,ebx
; Now we must search the range for the tabs
mov edi,pString
mov esi,txtrange.chrg.cpMax
sub esi,txtrange.chrg.cpMin ; esi contains the length of the buffer
mov eax,esi
push edi
.while eax>0
.if byte ptr [edi]==9
mov byte ptr [edi],0
inc edi
dec eax
pop edi
.while esi>0
.if byte ptr [edi]!=0
invoke lstrlen,edi
push eax
mov ecx,edi
lea edx,buffer
sub ecx,edx
add ecx,FirstChar
.if RichEditVersion==3
invoke SendMessage,hWnd,EM_POSFROMCHAR,addr rect,ecx
invoke SendMessage,hWnd,EM_POSFROMCHAR,ecx,0
mov ecx,eax
and ecx,0FFFFh
mov rect.left,ecx
shr eax,16
mov rect.top,eax
invoke DrawText,hdc,edi,-1,addr rect,0
pop eax
add edi,eax
sub esi,eax
inc edi
dec esi
mov ecx,txtrange.chrg.cpMax
sub ecx,txtrange.chrg.cpMin
invoke RtlZeroMemory,pString,ecx
.if ecx>0
jmp ScanMore
pop ebx
pop edi
; Now that the comments are out of our way, Get rid of the separators
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
dec ecx
inc esi

This is a really odd problem that I'm having with this. I noticed it only because I happened to have a comment with an ampersand followed with text like "&blahblah". What happens is weird. The ampersand will have an underline colored with the comment color, and as you type more text (even with spaces in between....anything but a tab) the text gets colored but the same text is also printed slightly offset to the left non-colored.
(I've attached a zip with a bmp of it which will explain what I'm talking about a bit better.)

Above is Iczelion's unedited code. I've removed all of the separator checks except for the space, end-of-line char, and comma just in case the problem was with something after the comment-finding algo. It's kind of funky. You can type ";" followed by multiple ampersands with the following effects:
1) first ampersand results in it being underlined with the underline having the comment color and the ampersand having the default text color.
2) second ampersand is default text color and the first is comment color with no underlines
3) third ampersand is default text color, second is default text color with comment colored underline, and first ampersand is comment colored with no underline
4) fourth is default color as is the third, but the second and first are comment colored with no underlines.

I apologize for the long post. What's so special about the ampersand character that it should cause these quirky problems? I'm not sure how well I explained the problem but if anyone needs clarification just ask.

Posted on 2002-10-22 18:54:52 by Will
Previewing lost the attachment. Here it is.
Posted on 2002-10-22 18:55:47 by Will
This is easy to fix.
The reason is the DrawText - Api which interprets the "&" char as prefix to underline the following char.

int DrawText(
HDC hDC, // handle to device context
LPCTSTR lpString, // pointer to string to draw
int nCount, // string length, in characters
LPRECT lpRect, // pointer to struct with formatting dimensions
UINT uFormat // text-drawing flags <-- !!!!

--> DT_NOPREFIX Turns off processing of prefix characters. Normally, DrawText interprets the mnemonic-prefix character & as a directive to underscore the character that follows, and the mnemonic-prefix characters && as a directive to print a single &. By specifying DT_NOPREFIX, this processing is turned off.
Posted on 2002-11-04 08:23:56 by Rennsemmel
Thanks. It's funny though, because I looked at the DrawText api but somehow I completely missed that.
Posted on 2002-11-04 10:44:39 by Will