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... :dazzled:
QuoteFindNextString 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
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.
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... :badgrin:
PS: richedit v. 1 i'm using...
well, anyway, any idea about how i may be able to work around this issue? :redface:
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
You are aware that RichEdit lines do not end with CrLf?
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:
end of line character's are being declared using another fancy WM, using another fancy structure or what, i meant ::)
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).
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... :eusa_boohoo:
(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.)
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:
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.
@ 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...
@ 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?
i've tested it... it's still the same 'sh*t'... any ideas on that?! :icon_eek:
It is said here:http://msdn.microsoft.com/en-us/library/windows/desktop/bb787873(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/desktop/bb787873(v=vs.85).aspx)
Quote
The following table shows which DLL corresponds with which version of Rich ...
However, Riched20.dll is compatible with Windows 95 and may be installed by
I don't see your need for the riched32.dll,perhaps i am blind.Finding a computer with less than win95 seems to me impossible.
10x, mate, note taken... gonna check it out soon and report some results :t
PS: ahem, so how should i define these 'new' richedits inside the .rc?! :icon_eek:
i mean the line with the definition... what should i put instead of "RICHEDIT"? richedit20 or what? :)
Try RichEdit20A and RichEdit20W.
yep RICHEDIT20A works fine... the app's still exposing the same strange behaviour though... :dazzled:
The richedit20 is perfectly stable.There is only one trap in which you can fall.
One or two functions don't put a zero at the end of what they write.
Personnally, i have solved the problem,I don't used them.
After verify and corrected this if necessary,If your problem still exist,it is elsewhere than in the richedit.
Use a debugger to find it.
Here a dangerous one:
Quote
INVOKE SendMessage,Hredit,EM_GETLINE ,lignedebut, addr phrase
remark from the help file:
Quote
Remarks
Edit controls: The copied line does not contain a terminating null character.
used the returned number of char copied to put the zero yourself.
Psycho,
If and when you want to test the actual rich edit content, you actually select the entire content, write it to a memory buffer THEN write it to disk. If you use the STREAMOUT based method, it changes the line terminator to a CR-LF pair.
Particularly if you are using a richedit 2 or later you need to see what is in the control to be able to select pieces of text and write it to disk. If you directly save a buffer, it DOES NOT alter the line terminator.
As I mentioned from at least Win2000 upwards, richedit 1 is emulated by the later DLL and is not entirely consistent with the earlier Win9x versions, mainly because the later versions also handle UNICODE. Unless you are writing code for Win95OEM, there is little reason to use the earlier version as the emulation is buggy. The later richedit 2/3 performs better, is faster and can do more, just for example multilevel undo/redo but also be warned that if you select this style, its internally different to other styles and makes a mess of the last line's line terminator. This in turn messes up line reporting on the last line which is where an editor is often used while composing text.
If I did not need drag and drop and multilevel undo/redo I would use a normal edit control as they are easier to use and far more consistent.
thank you, guys, i'll keep these considerations in mind, when i return to this project 8)
P.S.: @hutch: i don't really need that fancy stuff inside that project...