Yet Another Code Site

TaeRichEdit Component Bugs
Open Beta Information

This page lists all of the known problems with the TaeRichEdit Component.  So far, the bug list is surprisingly short given the size of the component code.  Also listed below are usage notes, bug work-arounds, and new features and tools.  You should check this page for the most current information about the TaeRichEdit Component.


November 28, 1999 (1.0.0.1)

Bug:  After printing once, TTaePrintDialog Pages is disabled (grayed out) even though the document is more than one page long.
Status:  Fixed in version 1.2 (01-09-00).

Bug:  After printing, preview headers and footers are not displayed in the correct font.
Status:  Fixed in version 1.2 (01-09-00).


January 9, 2000 (1.0.0.2)

Bug:  Pete Fraser reports that the IDE inserts incorrect template for the OnProtectChange event.  IDE inserts "void __fastcall TForm1::TaeRichEdit1ProtectChange(TObject *Sender, int NumObjects, int NumChars, bool &SaveClipboard) {}".  The correct template is "void __fastcall TForm1::TaeRichEdit1ProtectChange(TObject *Sender, int StartPos, int EndPos, bool &AllowChange) {}".
Status:  Problem confirmed.  Note that signature is correct -- the parameter names are simply misleading.  Still researching but, so far, this looks like an IDE bug.
Work-around:  Ignore the parameter names or change them to match the declaration.

Bug:  Richard Farley reports that the WordWrap property is declared twice when VCL_COMPATIBLE is #define'd as true.
Status:  Still under review.  Warning: This will probably be "fixed" by removing the VCL_COMPATIBLE compile option.

Bug:  Richard Farley reports that, after setting the Transparent property to true in the IDE, setting it back to false had no effect.  He noted that he had not tested the run-time effect.
Status:  Still under review.


January 24, 2000 (1.0.0.3)

Bug:  Hopefully, this last of the major bugs is fixed.  I failed to include the "PACKAGE" modifier on quite a few class declarations.  Many thanks to Stefan Hoffmeister for solving this one.
Status:  Fixed.

Note:  The distribution has been restructured to move the demonstration application to a separate subdirectory.

Note:  Be sure to install the component files on the same drive that BCB is installed on.

Note:  A printer driver must be installed and set as the default printer.  The component will throw exceptions if a default printer is not installed.

Note:  If you are able to build the component but get a mysterious "device attached to the system is not functioning" error when installing the package, substitute "false" for the SHGetPathFromIDList() call used in TaeUtility.cpp.  I have some vague recollection of a known problem with some versions of Win9x that do not properly export this function (Win95 B has been reported so far).  If this solves the problem, please let me know so that I can better solve this.

Note:  The TaeAdjLineBrks.cpp module is recompiled/assembled on every project make even though it has not been changed.  This is normal.


January 28, 2000 (1.0.0.4)

Note:  Added a TaePageSetupDialog component.  This component allows users to specify page margins using the standard Windows Page Setup Dialog.  There is not yet any documentation for this component.  See the demonstration application for an example of how to use the component.

Note:  Moved the TTaePreviewForm files to a separate subdirectory (.\Extras) since it is not, strictly speaking, part of the component.


February 2, 2000 (1.0.0.5)

New:  Added new OnProtectEvent and OnLinkEvent handlers. You should look first at the related OnProtectChange and OnUrlClick events but, if you need full access to the Windows EN_PROTECTED or EN_LINK message information that accompanies these messages, these events provide that information.  None of the documentation reflects this change yet.  Anyway, thanks to Pete Fraser for asking questions that led to the idea.

Bug:  Code using SelText generates a compile-time error.
Status:  Confirmed and fixed.

New:  The component now contains a RichEditVersion property which identifies the Rich Edit DLL as version 1.x, 2.x, or 3.x.  This is primarily useful in distinguishing between versions 2.x and 3.x.

Note:  The "Extras" folder now includes a "Tools" subfolder.  I plan to put useful tools here.  Currently, there is only one "tool" here -- a sample program that searches for Rich Edit DLLs and returns version information for DLLs that are found.  This tool may be useful for customer support.


February 11, 2000 (1.0.0.6)

New:  Added properties to TTaeRichEdit simplify support for OLE drag and drop  (OLE support is still rather incomplete -- I am still looking for volunteers.)  I have not tested extensively -- I do know that the component now allows dragging text to/from/within the control.  See the OleAllowTextDrag and OleAcceptDrop properties.

Changed:  Revised the RichEditVersion and RichEditVersionInfo properties that return information about the currently loaded Rich Edit DLL.  The RichEditVersion and RichEditVersionInfo properties should no longer cause GPF's on Windows NT.

New:  Added ProtectEvent and LinkEvent events.  These events provide access to all of the information that Windows has available in underlying WinAPI notification messages are sent.  This would be useful if, for example, you needed to react to mouse move messages while the mouse was over link text.  This change may affect the way that the OnProtectChange and OnUrlClick events work, so please see the code if you are using these events.

Bug:  There was a rather obscure VCL bug that affected some (but not all) versions of the Rich Edit control when more than ~64KB of text was loaded in the control and using Lines->Append() and Insert().
Status: Solved.  The changes are in TTaeRichEditStrings::GetCount() if you care to look at them.  Note that the fix is enabled only when compiling for Rich Edit 2.0+.  The Rich Edit 1.0 behavior is unchanged.

Note:  There may be a problem with the way that the component determines long file names on some platforms.  So far, I believe that the problem is limited to Win95B installations.  The problem has to do with certain versions of Windows not properly exporting SHGetPathFromIDList(), SHGetPathFromIDListA(), or SHGetPathFromIDListw() from shell.dll.)  The fix is to rewrite the Get:LongFileName() function in TaeUtility.cpp to build the long filename differently or, for now, simply return the "filename" parameter unchanged.


February 19, 2000 (1.0.0.7)

New:  Added classes for Microsoft RTF converter support.  These were in the early beta versions and removed. Now they are back.

New:  A partially complete help file is now available as a separate download on the TaeRichEdit Component Information page.

New:  Added FindWordBreak(), FindWord(), and SelectWord() methods. Added application demonstrating using these methods for basic syntax highlighting.

Bug:  Found problems with garbage left in the DemoApp1 program makefile. Caused link problems looking for PageSetupDlg and components.lib.
Status:  Fixed.


May 22, 2000 (1.0.0.8)

Changed:  I used an ugly hack in TaeRichEdit.cpp to allow the component to access certain VCL code declared as "private."  With Stefan Hostmeister's help, I have eliminated most, but not all, of the code that required the hack.

New:  Added a #define to work around the Windows API SHGetPathFromIDList() shell export bug.  See the TaeCompileOpts.h file for an explanation of the problem and the #define that you can change.  So far, I think this bug applies to Win95B only.  Please let me know if you find out differently.

Bug:  Although not reported, I found what I think was a rather obvious bug in the new TTaeRichEdit::GetTextRange() method.  I must have been asleep when I wrote that code.
Status:  Fixed but largely untested.

Bug:  I also found obvious bugs in the TTaeRichEdit::Print() method.  Apparently, I was asleep when writing that code, too.
Status:  Fixed but largely untested.

New:  Added two new methods for OLE support.  The first is TTaeRichEdit::InsertBitmap() which allows you to programmatically insert a bitmap into the control.  The second, TTaeRichEdit::InsertContainerObject() allows you to programmatically insert the contents of a TOleContainer into the control.  Be warned that I am not an OLE expert and, therefore, both of these will require some thorough testing.  If you use them, please give me some feedback.

Note:  The following problem seems to come up from time to time:  If a program that uses the TaeRichEdit Component is run on a machine which has no printers installed or which has no "default" printer, the VCL will throw an exception.  Strangely, the exception may indicate that it was caused by something that has nothing to do with the component nor anything clearly related to a printer problem.

I am investigating ways to trap this within the component code.  However, I suspect that it may be a bit harder than it seems and I have no "misconfigured" systems on which to test.  For now, be aware that this is the first thing that you should ask a user reporting problems after installation.  You should consider adding defensive code within your program or providing a diagnostic tool that checks for installed printers.

New:  A few programmers have been kind enough to share their code.  Look in the "Extras\User Contributed" folder for the code.  Be sure to read the ReadMe.rtf file in that folder before trying to use any of this code.  Thanks to those that shared.

May 25, 2000 (1.0.0.8)

New:  Ported the component and demonstration projects to Borland C++ Builder 5.  It is functionally identical to the BCB4 version.  See the "BCB5 ReadMe.rtf" document in the distribution file for notes on changes, instructions for installation, and tips on upgrading existing projects.


June 7, 2000 (1.0.0.9)

Bug:  Several users have struggled with problems using the component with certain HP printers.  I was finally able to reproduce the problem -- or at least, produce a problem.  If you have encountered GPF problems using the DemoApp1 demonstration program, this version should fix the problem.
Status:  Fixed (I hope).  Please let me know if you find further problems.

Changed:  Added code to the BCB4 version of the component to bring the BCB4 and BCB5 code base together.  The component source code is now identical for both versions.  In fact, all of the distribution code is now identical except for the project files which are still unique to the BCB version.

Changed:  Removed an unnecessary #include from the TaeAdjLineBrks.cpp file.  It should now compile more quickly.


June 14, 2000 (pending)

Bugs:  Bojan Resnik reported several problems with the component.  The bad news is that the problems have been present for most -- perhaps all -- releases.  The good news is that Bojan took the time to report them so there is a really good chance that they will be fixed very soon.

Bojan reported the following problems:

Status:  Reported, not fixed.


September 9, 2000 (incremental fixes not yet in full release)

Bugs:  Henry Seltzer reported problems using the component with certain printers.  Notably, users experienced GPFs when clicking OK from the TaeRichEdit Component's TTaePrintDialog dialog when using certain HP DeskJet printers.

Status:  I have posted a set of fixes for this problem and addressed some of Bojan Resnik's concerns (above) about STL compatibility.  The download also includes fixes for problems not previously reported.  The changes are not yet fully incorporated into the component beta distribution code but are available on the TaeRichEdit Component Information page as a set of replacement *.cpp & *.h files.


*** The TaeRichEdit Component's Features Were Frozen With The 1.0.0.8 Release ***

What does that mean?  First, I will, of course, continue to fix any bugs that are reported.  Next, I plan to remove the rather lame attempts at compatibility with the Rich Edit 1.0 DLL and, by reference, with the VCL TRichEdit component.  The RE 1.0/TRichEdit compatibility was incomplete anyway and, based on the kinds of questions and comments that I receive, I believe that this will not affect many of you.  However, if you see this as a problem, please say so now.

Next, I have spent a lot of time adding new functionality.  This takes much more time than you might think.  While I plan to add many more features, I really need to finish the help files and improve the sample applications.  And, although I thought that I made clear that the component requires an installed and defined default printer, apparently this was not as clear as it should have been.  So, I need to add defensive code to the component....

Finally, I have ported the component to BCB5.  This leads me to the following question:  Should I continue to support BCB4?  This is a tough call and I would appreciate your comments.  Keep in mind that I have limited resources, so think of it this way:  Would you rather that I continue to support BCB4 or would you prefer that I add new features and support only BCB5?  Now is your chance to influence the direction that this project takes.  As they say, "speak now or forever hold your peace."

Home | Top Of Page | Code | Papers | FAQs | Links | Search | Feedback

Page updated September 9, 2000

Copyright © 1999, 2000 Thin Air Enterprises and Robert Dunn.  All rights reserved.