Is this a bug in Rich Textbox control or my OS?

I've got a serious problem that I need to fix.  I apparently have a "bug" in my operating system or VB runtime files, which causes the Richtextbox RTF control to insert extra Carriage Returns (hex OD) in front of certain CR/LF occurrences.

The "notepad replacement" app that I developed in VB6 is not useful as long as this bug is present on this computer.

I'm running windows 2000, and have developed a small test application to duplicate this.  The bug does NOT happen when I copy the executable to any other systems running winXP, win98, or win2k.  Only happens on my one particular win2k system.

It exhibits the same faulty behavior whether compiled in VB5 or VB6.  The bug also happens when I migrated this project into Visual studio.NET 2002 with the migration wizard.  However when creating a new VB.NET project with the RTF control, the bug does NOT happen.

My test app duplicates this with a particular file, which is about 6K in size, and has been verified with a hex editor to contain no consecutive Carriage Returns (all Carriage return characters are followed by linefeed characters).  Each time the F3 button is pushed, my app advances the memory cursor and displays the ascii value via the following function
[code]
Asc(Mid(RichTextBox1.Text, RichTextBox1.SelStart, 1))
[/code]
At the end of my particular file is a CR/LF, and my program displays decimal values 13,13,10 which is CR/CR/LF. (extra carriage return added)

The reason I have to use a special file to duplicate this is because this bug apparently only happens when a CR/LF combination happens at a particular boundary in memory.  If I insert or remove any characters before the location of the CR/LF bug, then the bug does NOT happen and I see a single CR/LF.  

The bug also happens when I boot into safe mode (with no loaded drivers I know of), and with different versions of the richtx32.ocx control.  To give an idea of infrequently the bug occurs, a large text file of about 150Kb with about 4000 lines (CR/LFs) results in only THREE inserted carriage returns, so apparently the vast majority of those carriage returns do not fall on the appropriate memory boundaries to make the bug happen.  However it has completely killed the usefulness of the app for its intended purpose.

but I have removed VB6 and loaded VB5, but the bug still happens as before. This is a corporate work computer that runs many many apps with no problem, so reloading the OS is not an option at this point.

What else can I check to fix this?
airplaysAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Anthony PerkinsCommented:
Check out this article from MSDN:
BUG: Text That Contains a Single LF or CR in RichTextBox Becomes CR/LF on Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;284948

Anthony
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
airplaysAuthor Commented:
Problems solved... due to that article!!!!  :-)

I should mention that my win2k was already up to SP3 which the article said should have fixed the problem... but I went ahead and attempted (and failed) to upgrade to SP4.  When the upgrade hit a snag, the bug disappeared, so I made a copy of the new RICHED20.DLL before backing out and reverting to my old backed up version.  Then I had to boot into safe mode to recopy the new version of RICHED20.DLL, and that fixed the problem!

For anyone interested, here are the file details of my bad and good versions of RICHED20.DLL:
FILESIZE: they both had the same filesize (but different checksums): 431,888
the bad control was dated July 22, 2002 v 3.0  (file version 5.30.23.1209)
the GOOD control was dated June 19, 2003 (file version 5.30.23.1215)

Anthony, I'm just curious, had you heard of that bug before, or was that just a lucky search result on MSDN?   Thanks for the help!
0
Anthony PerkinsCommented:
>>I'm just curious, had you heard of that bug before, or was that just a lucky search result on MSDN?<<
Lucky search, but I suspect that 75% of problems can be solved by doing a bit of research in MSDN.

Anthony
0
Anthony PerkinsCommented:
On the other hand, "lucky" may not be the way I would describe it.  I searched for "richtextbox and carriage" and I found three articles. I pasted the relevant one.  So you can see not a lot of luck involved or for that matter a lot of rocket science either.

Anthony
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.