Highlighting find wrong

When you do Ctrl+F to bring up the Find box, do a search up for a string, type in something in the input box (but don't hit enter), and do another find up, it'll match the wrong line.

Example; I did a search for room_is_dark. Screenshot:
http://img.photobucket.com/albums/v123/rebirthseph/mc_bug.jpg

As you can tell, it's a few lines off. That's because I entered "f" into the input box after the first search and before the second one.

Oh and I blanked out IPs from that screenshot, it's nothing related to the bug.

I can't reproduce that. It always seems to find the right thing. What version of MUSHclient are you using?

Using 3.70, and I've seen it happen in other versions. It seems that it isn't as simple as typing something into the input box. It has something to do with the client receiving more lines during the search. Find Next while text arriving at the client seems to be the problem.

Still can't reproduce it. Can you clarify:

• Is it on a Find (Ctrl+F) or Find Next (Shift+Ctrl+F)?
  
• Does it happen if text arrives when the Find dialog box is open, or if text happens to arrive after a Find but before a Find Next?
  
• Are you searching forwards or backwards?

I use Ctrl+F first, which gives the right highlight. Then I use Ctrl+Shift+F next, which has highlighted incorrectly. I'm searching Up, so I guess backwards. I think text arrives while the "Finding: room_is_dark" with Ctrl+Shift+F box is there. I've been able to reproduce this a few times, not every attempt but it must be something to do with arriving text while the search is happening.

I'm trying, but still can't reproduce. This is what I am doing:

• Have 2 copies of the client going, so I can send tells from character in one copy, to the character in the other, thus forcing things to arrive when I want.
  
• Do a "find" backwards of something
  
• Send a tell to myself to make the window scroll
  
• Do a "find next"

However, the correct text is highlighted.

How long is the "Finding: ..." text box being displayed for? During that time, if text arrives that causes the offset I believe. As you can tell in the screenshot, I have quite a long output and so searching takes a few seconds at least.

Still can't reproduce it. I used a script to put 200,000 lines of junk into the output window, and a timer to insert new lines every 0.2 seconds, plus another instance of the client to send messages to me every 0.2 seconds, and it always reliably found the text I wanted.

I did find a problem that the progress bar was not being updated correctly, because it was being updated with a 16-bit number rather than a 32-bit number, but that is simply a display issue in the progress dialog box.

Funny, I almost can't keep away from it. I was just doing a search again, and it happened again. Worse this time, it was 10 lines off. Try to make sure your search takes at least 10 seconds, and that some text is arriving.

10 seconds? Right! I have 200,000 lines of text in my window and it only takes 1 second to search it.

Anyway, the good news is I can in fact reproduce it by having a timer fire every 0.1 second, whilst searching backwards those 200,000 lines. Now to find out why...

I've had MC open for 6 days, so that probably is why it takes 10 seconds. If I search the whole output once, then do it again right after, the second search is immediate.

I think I have found it. There were two possible places that the buffer could get larger during a search, and this was particularly bad when searching backwards, because that threw out what it thought was the "current line".

• Text arriving while you were working out what to type into the Find dialog box
  
• Text arriving during the actual search

I had allowed for the first one, which was actually likely to be the longer delay in most cases (you might leave the dialog box open for a minute or more).

However text arriving during a lengthy search seems to throw out the count as well. My tests so far seem to indicate the problem is fixed.

I've just upgraded, and I'll let you know in a few days if I can still reproduce it. I assume it's fine though. Thanks.