Default Font Issue, related to SaveTo/LoadFromStream?

I am noticing odd but predictable behavior using a TWPRichText component in 5.20.8. I'm wondering if maybe I'm doing something wrong (or I'm missing a procedure call). Here is some background information:

1. An Editor component on a form with a dropdown menu to select between 8 different letters.
2. DropDown's OnChange event saves the currently loaded text using SaveToStream and then loads the newly selected text using LoadFromStream into the same editor component. (i.e. there is only one "editor" component on the form)

Behavior:

Every time the Editor component is loaded from stream, I run the following code.

Editor.DefaultAttr.SetFontName('Arial');
    Editor.DefaultAttr.SetFontSize(10);
    Editor.CPPosition := 0;
    Editor.TextCursor.GetCharAttr;      
    Editor.CurrentCharAttr.GetFontSize(lFontSize);

The second time the editor is loaded with any text, lFontSize becomes 0 and the toolbar is blank. This only happens if the font size happens to be the same size as the default font size. If I make a modification to the font size of the text at CPPosition := 0 to, say, 17, it loads fine every time, not just the first time. If the font size of the text at CPPosition := 0 is the same as Editor.DefaultAttr, CurrentCharAttr.GetFontSize(lFontSize) returns 0!

Right before loading from stream, I am calling Editor.Clear().

Does anybody know if I'm forgetting to call some other procedure? Is there anything else that needs to be reset?

FWIW, I'm still experiencing this abnomality myself, and I'm not sure if Julian thinks it is fixed... see this thread:
[](http://wpcubed.com/forum/viewtopic.php?t=1644)

I'm not even using streams directly, just loading and saving WPRichText to a database using AsString. However, whenever reading from the database, I do move it twice (read it into one hidden WPRichText, do some image link related stuff, and move the result to the visible WPRichText... all using AsString.

I'm sending him an example which illustrates the problem as I see it. It is a simple test:

WPRichText2.AsString := WPRichText1.AsString;
  WPRichText1.AsString := WPRichText2.AsString;

In reading the thread you suggested, I also re-read [](http://wpcubed.com/forum/viewtopic.php?t=1624)

My understanding is that when saving/restoring from LoadFromStream (and other forms), the RTF reader removes redundant font information stored in DefaultAttr after the text is loaded.

Everything works fine if I were to only load one text document and then destroy the Editor component. I see the default font in the toolbar. All is well.

The problem appears to come (in my case) when the user loads a different text into the same Editor component without first destroying it AND the font size at the cursor position happens to be the same size as the DefaultAttr. By loading the text, I mean either by using "AsString" or via "LoadFromStream" (I've tried both...)

In that case, the font size does not appear to be read from DefaultAttr (via CurrAttr). It just returns "0" to the toolbar, which is not a valid font size in the toolbar that I have (just 8 through 72).

Even if "0" were a valid font size, it is not accurate because when I type in the Editor at that point, I'm writing in a font size which matches the DefaultAttr, not "0".

Is this a known issue or is this a coding issue?

hi,

The problem appears to come (in my case) when the user loads a different text into the same Editor component without first destroying it AND the font size at the cursor position happens to be the same size as the DefaultAttr. By loading the text, I mean either by using "AsString" or via "LoadFromStream" (I've tried both...)

In that case, the font size does not appear to be read from DefaultAttr (via CurrAttr). It just returns "0" to the toolbar, which is not a valid font size in the toolbar that I have (just 8 through 72).

Did you try

DefaultAttr.Clear
and
writingAttr.Clear ?

Then the editor would be in the same state.

If a font is undefined the WritingAttr.GetFont function (and others) will return FALSE, the value 0 signals this case but is a work around to simulate wptools 4.

Julian

Try it with the simple example I emailed you back on Aug 31. It doesn't appear to make any difference when used with AsString. Either that, or I tested your suggestion incorrectly.