DefaultAttr font size and the toolbar

If the font size of some text is equal to whatever you set the DefaultAttr font size to, the WPToolBar font size shows as blank when the text cursor is placed on that text.

For example, if you set some text to a font size of 12 when the DefaultAttr is set to 11, then placing the cursor on that text the toolbar font size works fine. Without changing anything else, set the DefaultAttr font size to 12, and reload the text. Now when you place the text on that size 12 text, the toolbar shows a font size of nothing.

WPTools 5.19 and earlier, D7, WinXP

Eric

Please read here to know why this is so:
[](http://wpcubed.com/forum/viewtopic.php?t=1624)

In fact the font is really not defined in that text - it is using the default font.

OK, I think I understand, but couldn't the toolbar be made so that when the font size is undefined for some text that it show the DefaultAttr font size (or whatever the font size being used in that case) on the toolbar rather than just a blank? Then I won't have to explain to my customers as to why the font size is blank even though they set it to something. Maybe make it yet another option? 😃

I don't understand how this is not a bug.

Why would the toolbar not be able to retrieve the font size at the caret position?

In the procedure TWPCustomRichText.DoUpdateCharAttr; the following line is commented:

//was: FToolBar.UpdateSelection(wptSize, '', Round(CurrAttr.Size));

Now this does retrieve the correct font size at the position of the caret so why was this left out?

Edit: nevermind, i got it. The font size wouldn't show correct when selecting text. I'm now trying to write something to work around this problem.

Edit 2: i've made a workaround that checks the fontsize for the entire selection using TParagraph.FontSizeAtPosition. If different font sizes are found then it shows a "blank" on the toolbar. Otherwise it shows the font size used in my selection. If there is no selection it returns the fontsize at the position of the caret. Something similar would seem like a good addition to WPTools.

The newer releases actually calculate the FontName, FontSize and Colors (in CurrAttr) from the default/inherited attribute.

This is done using code such as:

function TWPSetModeControl.GetSize: Single;
begin
  Result := 0;
  if Cursor.IsSelected then
    Cursor.SelectedTextAttr.GetFontSize(Result)
  else Cursor.WritingTextAttr.GetFontSize(Result);
{$IFNDEF DONT_REPORT_DEFAULT_ATTR}
  if (Result = 0) and (Cursor.active_paragraph <> nil) and
    (Cursor.active_paragraph.ABaseStyle <> nil) then
    Result := Cursor.active_paragraph.ABaseStyle.AGetDef(
      WPAT_CharFontSize, 0) / 100;
  if Result = 0 then
    FRichText.DefaultAttr.GetFontSize(Result);
  if Result = 0 then Result := DefaultFontSize;
{$ENDIF}
end;

symbol DONT_REPORT_DEFAULT_ATTR is usually NOT defined.

I'm sorry Julian, but i have updated to the newest release and it hasn't changed anything here. I probably need to be more specific.

The problem can be reproduced the following way:

Add 2 WpRichtext components on a form.
Add a WPToolbar for WPRichText2

Now in runtime copy the text from WPRichText1 to WPRichtext2 using:
WPRichText2.asString := WPRichText1.AsString;

If you now put the caret anywhere in WPRichText2 you will see that the fontsize in the toolbar is listed as blank.

Also when i have two different fonts in 1 selection it lists the default fontname on the toolbar, it would make more sense to show a blank here.

Sorry Julian, but I am getting a bit frustrated in that I am constantly asked the question as to why the font size in the toolbar is blank!!

It is blank because the font size is the default font size, but a user has to select some text before it will show them what the heck font size is.

The main problem is that a user wants to set some text the same size as some other text, but they don't know what that size is. So I get the call and have to tell them to select some of it, then you will see what the size is... and that is followed by an apology from me that I can't fix it.

Please find a way to show the current font size on the toolbar even when it is using the default size.

Thanks,
Eric

WPTools 5.20.6
Delphi 7

Have to say this is causing me some issues with service calls as well.

Hi,

In unit WPCtrRich.pas under procedure TWPCustomRichText.DoUpdateCharAttr; there should be this code:

{$IFNDEF NOTOOLBAR}  if (FToolBar <> nil) then  begin    if IsSelected then    begin        if not SelectedTextAttr.GetFontName(fnt) then           fnt := '  ';        FToolBar.UpdateSelection(wptName, fnt, 0);    end else FToolBar.UpdateSelection(wptName, CurrAttr.FontName, 0);    str := CurrAttr.StyleName;    FToolBar.UpdateSelection(wptTyp, str, 0);    FToolBar.UpdateSelection(wptStyleNames, str, 0);    FToolBar.UpdateSel;      //was: FToolBar.UpdateSelection(wptSize, '', Round(CurrAttr.Size));    if IsSelected then      b := Memo.Cursor.SelectedTextAttr.GetFontSize(s)    else b := Memo.Cursor.WritingTextAttr.GetFontSize(s);    if b then         FToolBar.UpdateSelection(wptSize, '', Round(s))    else FToolBar.UpdateSelection(wptSize, '', -1);    FToolBar.UpdateSelection(wptColor, '', CurrAttr.Color);    FToolBar.UpdateSelection(wptBKColor, '', CurrAttr.BKColor);  end;  {$ENDIF}

It is comparable to the code used for TBX which indeed uses the default font if none is found. The edit will be empty if different fonts are used in a selection.

action code:

if Edit.IsSelected then
              begin
                if not Edit.SelectedTextAttr.GetFontName(fnt) then
                  TTBXComboBoxItem(FAttachedControl).Text := ''
                else TTBXComboBoxItem(FAttachedControl).Text := fnt;
              end else TTBXComboBoxItem(FAttachedControl).Text := edit.CurrAttr.FontName;

Julian

This has been an issue with QA for us.

Will fix be included in future releases of WPTools 5?

Hi,

Will fix be included in future releases of WPTools 5?

Yes, it has been copied from current V5.20.8

Julian

Julian,

I see that code in WPCTRRich, but "b" is false, so the font size shows blank. Sometimes I see that section of code trigger twice, b is true at first but then it gets called again, and b is then false.

I'm still using 5.20.6 (for various reasons), but unless there is some subtle differences in the code posted in your reply is different than what is in 5.20.6, there is a bug somewhere.