From dfb521c1882c3ed764288ea5b0015199e148e66e Mon Sep 17 00:00:00 2001 From: "jan.nijtmans" Date: Thu, 11 Jul 2024 22:15:50 +0000 Subject: [PATCH] Proposal for [475692230a]: Wrong advice regarding TK_OPTION_PIXELS --- doc/SetOptions.3 | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/doc/SetOptions.3 b/doc/SetOptions.3 index cbbe648d8..309089baf 100644 --- a/doc/SetOptions.3 +++ b/doc/SetOptions.3 @@ -523,11 +523,13 @@ integer pixel value corresponding to \fB2m\fR. Unfortunately, this loses the original screen-independent value. Thus for \fBTK_OPTION_PIXELS\fR options it is better to use the \fIobjOffset\fR field. In this case the original value of the option is retained in the object and can be returned when -the option is retrieved. In most cases it is convenient to use the +the option is retrieved. It might seem convenient to use the \fIinternalOffset\fR field as well, so that the integer value is -immediately available for use in the widget code (alternatively, -\fBTk_GetPixelsFromObj\fR can be used to extract the integer value from -the object whenever it is needed). Note: the problem of losing information +immediately available for use in the widget code. But if scaling is +involved, \fIinternalOffset\fR won't change value when the scaling +changes. Therefore it is better always to use +\fBTk_GetPixelsFromObj\fR to extract the integer value from +the object whenever it is needed. Note: the problem of losing information on retrievals exists only for \fBTK_OPTION_PIXELS\fR options. .PP The second reason to use the \fIobjOffset\fR field is in order to