RichEdit line scroll issue...

[PsYcHoCoDe]

This is an algo, that does "Find Next" in a rich edit box, and it has to select the found string inside the richedit box and SCROLL DOWN to the found occurence of it... however, it strangely scrolls down some MORE lines than it SHOULD actually do? is someone able to tell how's that possible?! it scrolls +2 lines on first iteration, on each next scrolls more and more extra lines... 

FindNextString PROC
LOCAL currChar:CHARRANGE
LOCAL fdText:FINDTEXT
LOCAL scrLines:DWORD
LOCAL lenSz:DWORD
;int 3
    lea edi, currChar
    xor eax, eax
    mov ecx, sizeof currChar/04h
    rep stosd ; zero initializing the CHARRANGE Structure...
   
    invoke szLen, addr srchString
    mov lenSz, eax ; length of searched string
   
    invoke SendDlgItemMessage, hWnd, ID_CTEXT, EM_EXGETSEL, 0, addr currChar ; getting current sel. info
    lea ebx, fdText
ASSUME EBX:PTR FINDTEXT
    mov eax, currChar.cpMin
    add eax, lenSz ; skip searching through the current selection...
    mov [ebx].chrg.cpMin, eax
    mov eax, -1
    mov [ebx].chrg.cpMax, eax ; search until the end of data buffer
    lea eax, srchString
    mov [ebx].lpstrText, eax ; addr of searched string...
    invoke SendDlgItemMessage, hWnd, ID_CTEXT, EM_FINDTEXT, FR_DOWN, addr fdText
    cmp eax, 0FFFFFFFFh
    jz @not_found
    mov [ebx].chrg.cpMin, eax ; our newly found position...
    mov [ebx].chrg.cpMax, eax
    mov eax, lenSz
    add [ebx].chrg.cpMax, eax ; calculating selection to mark up...
    invoke SendDlgItemMessage, hWnd, ID_CTEXT, EM_EXSETSEL, 0, addr [ebx].chrg ; setting selection

    invoke SendDlgItemMessage, hWnd, ID_CTEXT, EM_EXLINEFROMCHAR, 0, [ebx].chrg.cpMin
    mov scrLines, eax ; get line count to our found string
   
    invoke SendDlgItemMessage, hWnd, ID_CTEXT, EM_LINESCROLL, 0, scrLines ; scrolling the richedit to there...
ASSUME EBX:PTR NOTHING
    ret
@not_found:
    xor eax, eax
    ret
FindNextString ENDP

[hutch--]

Without grinding through the code, it sounds like you are not calculating the current location properly.

I should have added that rich edit controls are a bit "patchy" in how they perform, you have to tweak each riched version to get it reliable. With search where you set the selection to the next text that is found, you normally don't set the scrolling as well.

[PsYcHoCoDe]

for calculating the line i just use EM_EXLINEFROMCHAR message based on the beggining char of the newly found string (the same that get's EM_EXSETSEL and setsel in the mean time works perfectly 'exact')... i don't calculate in this case which line it is, using custom own algo, that's why i'm not sure how to explain this effect to me  ::)

i mean: since i'm using 'their 'proper' way' to do that, it should just work... @least i hoped so... 

PS: richedit v. 1 i'm using...

[PsYcHoCoDe]

well, anyway, any idea about how i may be able to work around this issue?  :redface:

[PsYcHoCoDe]

if i attach the precompiled binaries with a sample set of data, that exhibits this odd behaviour, would it work for you guys to have a closer look at it?

Attachment: precompiled binaries with an the code of the procedure the same as posted in start of the thread, but int 3 brekpoint is uncommented... sample data to test is the .dec file inside, the problem issue is inside the "Find Next"s code, archive's password: 1234

[jj2007]

You are aware that RichEdit lines do not end with CrLf?

[PsYcHoCoDe]

i know this would sound totally tragic, but never actually though about that... in the field of richedit controls, i'm a total newbie... and so, what's the deal if a line ain't terminated with CR,LF?! :redface:

[PsYcHoCoDe]

end of line character's are being declared using another fancy WM, using another fancy structure or what, i meant  ::)

[jj2007]

Well, I haven't seen the home-brewn algo that counts your lines, but the CR thing might be a source of errors. For example, it makes a difference if you use EM_GETTEXTRANGE or EM_GETTEXTEX. The latter has some interesting flags...

Not to mention EM_STREAMOUT, which yields CRLF but is broken (as in "BROKEN", "ROTTEN", "FAULTY", "BUGGY" etc - it forgets occasionally some bytes; same for EM_GETSELTEXT).

[PsYcHoCoDe]

i do not actually even intend to use streamin/out at all, about the home brew algo - it's just a simple len-scan trash (slow, but in the current situation i don't really care too much about that), that count's CR,LF on it's way to the end point, since i replace CR,LF's, originally found in the input data BEFORE they get actually WM_SETTEXT inside the richedit controls... the CL pairs r replacements of CR,LF pairs, originally found and reformatted... but i don't use that algo in the Find Next function - i use there the code i pasted @start of topic, using window messages... and i do insert these CR,LF pairs to terminate the 32 bytes long lines so that they look actually right in the output  (just for the sake of formatting, i reformat the data BEFORE actually putting it inside the control) ::)

P.S: just tried to explicitly disable eventual additional endline formatting by setting EM_FMTLINES to FALSE on init stage for the control... result's still the same... 
(Sets a flag that determines whether a multiline edit control includes soft line-break characters. A soft line break consists of two carriage returns and a line feed and is inserted at the end of a line that is broken because of wordwrapping.)

[PsYcHoCoDe]

it changes lines for the first two occurences in the test data sample, i've attached, sets one line AFTER @ the 3rd occurence (test string: jabi) and more than 30+ lines for the 4th occurence...   :icon_eek:

[hutch--]

Psycho,

The test of the rich edit content as against what is saved is to select the contents then write it to disk. Then open it in a HEX editor to see what you have got. In a richedit 2/3 you only have ASCII 13, not the 13,10 pair. I forget what the old win9x version of richedit uses but be aware that the richedit 2/3 emulation of richedit 1 is a bit buggy.

[PsYcHoCoDe]

@ hutch : i just checked that (select all contents of richedit -> copy -> paste inside HxD editor), looks as it doesn't append anything additional to format the lines... except my own formatting for 32 bytes len of line...

[PsYcHoCoDe]

@ hutch -> wait a sec... just got it... if it uses only one byte termination, that means my line would actually be considered 33 bytes long, not 32... right?

[PsYcHoCoDe]

i've tested it... it's still the same 'sh*t'... any ideas on that?!  :icon_eek: