airplays
asked on
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,
[/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?
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,
[/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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>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
Lucky search, but I suspect that 75% of problems can be solved by doing a bit of research in MSDN.
Anthony
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
Anthony
ASKER
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!