- This topic has 13 replies, 2 voices, and was last updated 5 years, 3 months ago by
HeDiBo.
-
AuthorPosts
-
October 16, 2019 at 12:41 pm #62565
HeDiBo
ParticipantA 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 😭
October 17, 2019 at 6:27 pm #62767Support
KeymasterCan you give me one such form, where font data is lost after opening?
I will check why it may be happened.October 17, 2019 at 9:06 pm #62772HeDiBo
ParticipantI 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, 5 months ago by
HeDiBo.
October 20, 2019 at 12:46 pm #63136HeDiBo
ParticipantI 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, 5 months ago by
HeDiBo.
-
This reply was modified 5 years, 5 months ago by
HeDiBo.
Attachments:
You must be logged in to view attached files.October 21, 2019 at 8:39 pm #63156Support
KeymasterThank you for files, I will check it soon.
October 21, 2019 at 9:37 pm #63170HeDiBo
ParticipantThank 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.October 23, 2019 at 12:12 pm #63202Support
KeymasterSo, do you mean this behavior is correct?
October 23, 2019 at 12:23 pm #63203HeDiBo
ParticipantNo, 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.October 23, 2019 at 12:44 pm #63204Support
Keymasterfont 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.
October 23, 2019 at 4:11 pm #63260HeDiBo
ParticipantThis 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.
October 24, 2019 at 10:06 am #63468Support
KeymasterSo, 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?December 3, 2019 at 2:00 pm #68196HeDiBo
ParticipantTry 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 5 years, 4 months ago by
HeDiBo.
December 9, 2019 at 12:03 am #68216Support
KeymasterI see what you mean, the bound label will have same behavior in the next package release.
December 30, 2019 at 8:02 pm #68248HeDiBo
ParticipantProblem 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 5 years, 5 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.