NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/programm/16080

Internet Message Format | 1992-11-19 | 5.9 KB

Path: sparky!uunet!spool.mu.edu!darwin.sura.net!ukma!cs.widener.edu!dsinc!bagate!cbmvax!peter
From: [e-mail] (Peter Cherna)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: GRIPE! about refreshing string gadgets
Message-ID: <[e-mail]>
Date: 19 Nov 92 14:46:23 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Peter Cherna)
Organization: Commodore-Amiga, Inc.  West Chester, PA.
Lines: 100

In article <[e-mail]> [e-mail] (Paul Kienitz) writes:
>In my current project, I have lots of string gadgets, and sometimes
>they need to be enabled and disabled in response to other input, and
>sometimes they need to have their text contents altered, and sometimes
>both at once.  I've noticed that all versions of Intuition do a LOUSY
>JOB of refreshing string gadgets in different states, when the string
>is shorter than the gadget and I'm also using the 2.x feature of
>having different colors for active and inactive string gadgets.
>Furthermore, different versions mess up in different ways.

Intuition does not do a "lousy" job of this at all.  There is a single
buglet that I know of, and it only affects 2.0, not 1.3 or 3.0.  (That
hardly qualifies as "all versions").  This bug involves StringExtend
string gadgets whose background color is set to be other than zero.
If one string gadget is disabled, then all string gadgets earlier in the
list will have some remnant of the ghosting pattern in their container.

If you wish to report any other bug, please describe that bug.  Also,
be sure to remove a string gadget from the window before modifying
its contents or the fields of any of its structures.

> - Pad the current string in the gadget with spaces so as to
>    completely fill the visible space with text.  Under 2.x, pad it
>    so the terminating nul char falls just after the end of the
>    visible space, under 1.x pad it so the nul is just inside the end
>    or else it will refresh one character space OUTSIDE the
>    boundaries of the gadget.

There is a version-based difference in how wide the area to be cleared
will be.  Well-designed gadgets come out the same under all versions,
but ill-specified ones may have their appearance altered depending on
the OS version.  Under 1.3 and earlier, Intuition clears only a whole
number of characters.  If you're using Topaz 8, and you make your gadget
70 pixels wide, Intuition clears only the largest multiple of the font
width (8 in this case) less than the gadget width.  That would be 64
in this case.

Under 2.0 and up, we needed to respect the declared gadget's width.  This
caused too many visual problems, so we only did it for StringExtend gadgets.
The visual problems were caused when someone did something like:

(DON'T DO THIS, THIS EXAMPLE IS WRONG)
Declare a topaz 8 string gadget to be 70 pixels wide.  Now observe that
the gadget appears to be only 64 pixels wide.  Make a border suitable
to cover a 64-pixel wide gadget (eg. a box 66 pixels wide).  Now V1.3
only rendered in 64 pixels of the string, so the visuals worked.  2.0
and up tried to use all 70 (as the programmer _requested_), and this overwrote
the borders.  The programmer erred by specifying 70 pixels instead of
64 for the gadget, or erred by sizing the border to fit a 64 instead of
a 70-pixel wide gadget.

This bug was so frequently seen in applications that Intuition grew
Yet Another Kludge, and we only do the right thing (respecting the gadget's
declared width) for StringExtend gadgets, whichwe assume are well-designed,
since they're new for 2.0.  If you add StringExtend to a gadget you designed
in this "ill-specified" way, you must fix your bug.

The other thing with width of rendering is that some people got tricky
and allowed the cursor to "hang out" of the edge of the gadget render area.
This was done by specifying a container width of (maxchars+1)*font-width.
So a three-character topaz-8 gadget of width 32 had this property.  (Intuition
used to only blast up to maxchars*fontwidth).  The cursor could actually
exceed the gadget render area, which is bad for a number of reasons.  Such
applications now find that the full 32 pixels will be set to background
color, instead of the former 24.

In case people are curious as to why Intuition had to change behavior,
the answer lies in a few areas.  Blasting the gadget's declared width
is required in order to support proportional fonts (and compatibility aside,
is the preferred behavior for monospace fonts too).  Not allowing the
cursor to "hang outside" the render area is required by the way the cursor
is drawn under 2.0 and up, which in turn is mandated by the fact that
modern gadgets must not make "canvas assumptions", that is to say, must
not assume the state of the pixels that it's rendering on top of, unless
it can _ensure_ that state.

>    anyway, come to think of it), RefreshGList the gadget a second
>    time with the window rastport's write mask temporarily set to
>    zero.  This lets Intuition know the current string length,
>    without doing any actual rendering.

Do you think Intuition is supposed to respect the write mask you set
in your window?  I don't think it's correct for it to do so, and under
1.3 it accidentally does in some places.  Under 2.0 and up, we've caught
all these cases, and Intuition ensures that it's rendering comes out
how it _needs+ it to be.  Assuming your mask will curtail Intuition's
activity is called "relying on a side-effect".  Relying on a side-effect
is a compatibility bug in your app.

Your example code is poking into the StringInfo of a gadget currently
attached to a window.  This is illegal.  You must remove the gadget
from the window before playing with it.

     Peter
--
Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
{uunet|rutgers}!cbmvax!peter    [e-mail]
My opinions do not necessarily represent the opinions of my employer.
"I believe it's bad luck to be superstitious."