Bound Labels may loose font settings (AC14.33)

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #62565
    HeDiBo
    Participant

    A problem reoccurred: bound labels loose their font settings overnight.
    Without changing anything, bound labels may loose their font settings, returning to their default of 8 pt Tahoma.

    Don’t know when it happens, it also does not happen to all bound labels, no pattern found.

    When setting the font to its valid value, the font setting stays valid. Meaning I have to check hundreds of forms for this problem 😭

    #62767
    Support
    Keymaster

    Can you give me one such form, where font data is lost after opening?
    I will check why it may be happened.

    #62772
    HeDiBo
    Participant

    I already corrected them all.
    I think this may have been a much older issue. I remember that on some point, bound labels would not always save their font properties when the IDE was closed. In that case, looking at them now, may still show the old issue.
    As soon as I see this occurring again, I’ll save the dfm for your inspection.

    • This reply was modified 5 years, 1 month ago by HeDiBo.
    #63136
    HeDiBo
    Participant

    I have more info now. It’s a bit devastating I’m afraid.
    Enclosed is a picture of a Tframe at design time.
    Look at the controls sDBText2 and sDBText3. They have bound labels (“Ronde” and “Zitting”). And sure enough they have an Italic font.
    I changed something in the frame, thereby manually editing the dfm text. I ran the project. These controls still looked OK. But looking at the dfm file, these bound labels have lost their font info!!
    As you can see from the last history file, they were OK!

    I’ve only just seen that the bound labels have ParentFont=True as the default. Still it is disturbing to see all the wrong font info. In normal fonts, when ParentFont is True, the font info is copied from the parent.

    This must be the root of the problem, I think. When you change something in the font info, ParentFont becomes False and suddenly the labels have the wrong formatting.

    • This reply was modified 5 years ago by HeDiBo.
    • This reply was modified 5 years ago by HeDiBo.
    Attachments:
    You must be logged in to view attached files.
    #63156
    Support
    Keymaster

    Thank you for files, I will check it soon.

    #63170
    HeDiBo
    Participant

    Thank you for files, I will check it soon.

    The files are really superfluous, since the problem is already found: the ParentFont property in the bound label is True by default. So, the font properties should be copied from the parent. It is not, apparently.
    That is no problem as long as you don’t change anything in the font properties. However as soon as you change such a property, the rest of the font properties are wrong, because they were not copied.

    #63202
    Support
    Keymaster

    So, do you mean this behavior is correct?

    #63203
    HeDiBo
    Participant

    No, it’s wrong. When the Bound Label is created in the IDE it should copy the parent’s font properties, because ParentFont being True is the default.
    Also, every time the ParentFont property is changed to True, the font properties of the parent should be copied.
    This is true for any Control with a ParentFont property, so it should be done in the Boumd Label too.

    #63204
    Support
    Keymaster

    font properties of the parent should be copied

    What you mean? Font of control (if ParentFont is True) is always depended from parent font.
    If parent is changed then other font used. Old font of control (which should be copied) is not used.

    PS. Font is keept only if ParentFont is changed to False before changing of parent control.

    • This reply was modified 5 years ago by Support.
    • This reply was modified 5 years ago by Support.
    #63260
    HeDiBo
    Participant

    This is how it should work:
    – Make a new VCL project.
    – Drop a TEdit control on the form (notice ParentFont property is True)
    – Change the font properties of the Form. Notice that the font of the TEdit changes too: not only in the visible control but also in its font properties.
    – Change one of the font properties of the TEdit. ParentFont turns to False.
    – Change the font properties of the Form. The font properties of TEdit do not change.
    – Change the ParentFont property of the TEdit to True: this is the crucial part – the actual font properties of the TEdit become the same as the Form’s font.

    The bound label has the flaw that it will not copy the actual font properties of the parent to its own font properties.

    • This reply was modified 5 years ago by HeDiBo.
    • This reply was modified 5 years ago by HeDiBo.
    • This reply was modified 5 years ago by HeDiBo.
    • This reply was modified 5 years ago by HeDiBo.
    #63468
    Support
    Keymaster

    So, the issue is that font properties are not saved in Dfm if ParentFont is True. Right?
    This feature was made because this data is not used if ParentFont is True.
    Why these font data should be saved in Dfm if ParentFont is True?

    #68196
    HeDiBo
    Participant

    Try the steps described in #63260 above both for a TsEdit control and its bound label. You will see the difference.
    In step 3 the font properties of the bound label will not change (its appearance will).
    In step 4 the ParentFont property becomes False, but the original font properties stay the same!!! So, if you had Font Arial for the parent font, for a newly created TsEdit with an active bound label, the bound label’s font would be Tahoma 8 point (the default). That would not show at run time (ParentFont = True), but would suddenly appear if, for instance, the bound label’s font size was changed to 9. That’s because the font properties were not actually copied to the bound label, when ParentFont was set to True.

    • This reply was modified 4 years, 11 months ago by HeDiBo.
    #68216
    Support
    Keymaster

    I see what you mean, the bound label will have same behavior in the next package release.

    #68248
    HeDiBo
    Participant

    Problem solved in AC 14.36 👍🏾

    PS. I’m still not able to close this item. Problem is probably in WordPress settings. The menu item to tag the item as resolved is not present in a user’s reply heading.

    • This reply was modified 4 years, 10 months ago by HeDiBo.
    • This reply was modified 4 years, 10 months ago by HeDiBo.
Viewing 14 posts - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.