Close Topic Options

Hi akyprian,

I did not want to offend you in any way, I'm sorry if my statement sounded that way for you. You did a great job and it was just a question to understand whats going on.

Regards, Phoenix

@Trodon:Thanks

@Phoenix:English is NOT my native language. I was not offended AT ALL. Your comment was correct and your observation completely TRUE. Do not accuse yourself for anything. You posted what you 've faced and this is more than welcome. Never hesitate to post any criticism, otherwise HiEditor won't become better. As an aside, I had already increased the filenames buffer to 65536 bytes BEFORE seeing this reply. You 'll have it in the next version.

@all: Feedback/criticism has always been my best friend


Cheers,

Antonis

Sorry Antonis, serious bug found. It's the find/replace function.

What I had was a long HTML file where I wanted to replace all the … entities with "..." instead. Some of them were consecutive. So I did a find/replace-all and got 744 replacements. I ended up at the end of the file (rather than where I was when I'd started the search/replace, which probably should be better, a minor bug...) but serendipitously, because there I saw the line:
"blah blah blah .............……..........." etc.

I double-checked the spelling, but it was definite, these should have been replaced but weren't. I then did another find/replace-all straight away, and got another 115 replacements. But there was still one of the buggers left on that last line! So I did another find/replace-all and got another 3, which fixed the last of them.

So either something in the string (the & or the semicolon) or the fact that they were right next to each other is causing the find/replace to skip over some incorrectly. Is it also breaking the find too?

Don't say sorry, I say thanks. If you could upload the HTML file and post the options set on the find dialog that would help me to find the bug easier.

Thanks once again for the report,

Antonis

Well, I thought that was pretty specific information to reproduce this bug, actually... But I'm not going to upload a 254MB file full of private info, so I've snipped this together:

Just do a Find/Replace All to replace the entity "…" with "...". You'll see that only every OTHER of the consecutive entities are found and replaced, and the others on further passes. The filesize clearly makes no difference, it's either not resetting the offset correctly after each find, or the & or semicolon in the search string are throwing it.

I'd also say that in trying to cut that file down, trying to do a mass selection (holding the cursor down as you drag down and below the window to allow it to scroll so you select a very large block of text) in that 250MB file was HIDEOUSLY slow, worryingly so for software that I am sure is otherwise well stripped-down. I have the SysInternals Process Explorer running in the taskbar and while scrolling it fills the activity graph with 100% red rather than the usual 100% green on full CPU utilisation. From the helpfile, if it helps pinpoint the problem:

For comparison, I tried the same 250+MB text file in both WordPad and Hutch's QEditor and the same large block select positively zipped through the file at high speed from start to finish in both. I can only assume that however you're drawing/updating the window is the bottleneck. In fact, it is so slow that while doing the drag and select, you can see the last line at the bottom of the window repeating as you scroll before being overwritten with the new line.

For reference, I'm using a 2.4GHz Northwood P4 with 512MB memory (and a 1GB swapfile) on a mainboard with embedded Intel graphics at the moment, but the fact that the other two word processors aren't affected by those limitations means that the problem is in HiEditor's scroll/screen handling.

Attached File ( Number of downloads: 18 )
 Login or Register to download