TRichView.com

Michael,

It took me a few minutes, but I figured out what you were doing with that first fix. I've implemented something similar in my own code now. That fixes an obscure bug I've heard from users occassionally. Good catch!

I never noticed the second bug because of how I use the procedure.

I'll see about updating the code in my original post with the first fix.

Thanks!

-David

DavidRM wrote:I never noticed the second bug because of how I use the procedure.

Yeah, I've used this method in very specific way. The key trouble of this code in In some situations it's gonna set startItemNo to zero (or to a value nearby the beginning of text), and the search'll be going from the start of the text.
It's a big trouble, then we're making the search from the cycle (for example, to mark all entries of text). What will happen, if we implement this procedure?
As you see, this part gonna be implemented, if stufFromStart isn't set. But the trouble is that StartItemNo will be the first visible item in RV. This means that actually it gonna always find the similiar first item of the text, not the sequence. If we should implement smth like this And if at least one entry of searching text exists - it exactly stucks in this part of this code - searching routine will always find the first entry every time program calls SearchTextUnicode procedure. In my case I solved this by getting current caret position - and this helped me to solve endless cycling bug.
Anyway, the contributed code is great, thanks a lot
- Michael