April 91 - TAspectPicture
TAspectPicture
James Plamondon
The Bed of Procrustes
Greek mythology contains the tale of Procrustes, a wealthy man of Eleusis who was in
the habit of taking in travelers for the night. After treating such a traveler to a
sumptuous dinner, Procrustes would take him to a room in which there was an iron
bed, exactly the right size for a man of average height. Procrustes would then bid his
guest to lay down on the bed. If the guest was of average height, then all was well; his
sleep would be comfortable and uninterrupted; in the morning he would go on his way.
However, if the guest was shorter than average, Procrustes would place him upon a
rack, stretching him out until he was tall enough to fit the bed. Likewise, if the guest
were taller than average, Procrustes would decapitate him, to ensure that he, too, fit
the bed. The tale of Procrustes was all the more terrible to the ancient Greeks, because
of the high value they placed on hospitality.
MacApp often reminds me of Procrustes and his iron bed: so long as one is writing an
"average" application-one that uses documents, views, and controls in the manner
foreseen by MacApp's designers-all is well. Otherwise, you may have to decapitate
your feature list, or extend the MacApp source code, to fit MacApp's iron bed. This
limitation is all the more terrible to us, because of the high value object programmers
place on code reusability and extensibility.
TAspectPicture
Recently, I found myself strapped to the iron bed when I least expected it. I wanted to
do something that appeared to be simple: display a picture in a button-like control. No
problem, right? TPicture, in MacApp's UDialog unit, does just that-so I used it.
Unfortunately, TPicture (like old Procrustes) distorts its picture as necessary to
make it fit in its extent. I needed to maintain the picture's original aspect ratio.
Well, TPicture was still close; surely, I'd just have to override a single routine to get
the behavior I wanted. So I looked at the TPicture.Draw() source, and was quite
discouraged to see that it called ControlArea() to get the rectangle in which to draw the
picture. I had expected to find a routine called something like GetPictureArea(), which
would be easy to override. Overriding ControlArea() would have undesirable
side-effects. Darn.
OK, no problem; I'd just override Draw(). Whoops! I couldn't do that-calling
INHERITED Draw() would then call TPicture.Draw(), drawing the picture twice
(differently each time). If I didn't call INHERITED Draw(), my control would not be
properly adorned, since adornment is performed by the version of Draw() that is
inherited by TPicture. Object Pascal-the language I was using-does not allow me to
call a grandparent's version of Draw(), only that of the parent class. Procrustes' iron
bed was beckoning.
Well, if there's one thing I've learned in object programming, it's never to write any
code you don't have to. If I couldn't inherit the solution to my problem, maybe I could
get someone to give it to me. So I described my problem to MacApp.Tech$ as a contest,
in which the person supplying the best solution would win. I got a number of excellent
responses.
Knepper's solution
Chris Knepper submitted an entry which I classify as an "elegant kludge." This
apparent oxymoron describes a solution which relies on the implementation, rather
than the interface, of a method (thus, it's a kludge), but which does so in a clever way.
Here it is:
PROCEDURE TAspectPicture.Draw(area: Rect); OVERRIDE;
VAR
saveDataHandle: PicHandle;
BEGIN
{ 1st. draw the picture "correctly" }
fill in this blank
{ 2nd. (the hard part!) call INHERITED Draw }
{ without having TPicture.Draw do anything }
saveDataHandle := fDataHandle;
fDataHandle := NIL;
INHERITED Draw(area);
fDataHandle := saveDataHandle;
Since TPicture.Draw() just calls INHERITED Draw() if fDataHandle is NIL, this
OVERRIDE of TAspectPicture does the trick. TControl.Draw() gets called, the
adornments get drawn, and everybody's happy-assuming that the "fill in the blank
part draws the picture in the right place, with the correct aspect ratio.
Eastman's solution
Gordon Eastman's entry was also a kludge, and if it was somewhat less elegant, it was
downright cunning. His approach relies on the inner workings of Object Pascal and the
MPW Linker. Here it is:
PROCEDURE TControl_Draw(area: Rect; me: TControl); EXTERNAL;
PROCEDURE TAspectPicture.Draw(area: Rect); OVERRIDE;
BEGIN
{ draw picture with correct aspect ratio, then }
TControl_Draw(area, SELF);
To quote Eastman's description of his solution, "This is a slime dog trick that relies on
how the MPW Pascal compiler and linker work. The linker sees TControl.Draw as
TControl_Draw. The compiler generates an extra SELF parameter for methods." I beg
to differ; this solution is an affront to slime dogs everywhere. But it works (this
week, anyway).
Berdahl's solution
Eric Berdahl found the whole contest laughable, I think; to his mind, it was a
undeniable demonstration of the superiority of C++ over Object Pascal. Just to rub it
in, he submitted an entry showing how easy it is to implement TAspectPicture in C++,
which allows calls to ancestral methods via its scope resolution operator. Here's his
solution:
TAspectPicture::Draw(Rect* area) {
// Compute the rect, then draw the pict, then
// Skip TPicture::Draw and go directly to TControl::Draw
TControl::Draw(area);
} // Draw
The solution does indeed prove C++'s superiority (in this specific ability, at least).
It's worth noting again, though, that this whole problem stems from a flaw in the
design of the class, not of the language-if MacApp's TPicture class had a GetPictRect()
method, there would have been no problem. Good languages are a poor substitute for
good design.
The missing solution
No one submitted a solution that I was expecting: changing the MacApp source code to
add the method GetPictRect() to TPicture, and modifying TPicture.Draw() to call it. I
think of the MacApp source as being like putty-if I don't like it, I change it. So long as I
mark my changes well, it's not too hard to move them to the next version of MacApp.
Of course, I always notify the MacApp wizards of my changes, in the hope that they may
be incorporated directly into MacApp in the future (thus relieving me of the burden of
maintaining my changes with each new MacApp release).
I carefully worded my contest rules to allow this solution. Perhaps everyone else
worships the MacApp source as an immutable deity; if so, burn me for a heretic.
Cheung's solution(s!)
Tseung Cheung supplied not just one, but two solutions. The first overrode
ControlArea(), since that's the routine called by TPicture.Draw() to calculate the rect
in which to draw the control's picture. While it works, this solution has a number of
side effects (since ControlArea() is used in a lot of other places).
The second solution used the trick described under Knepper's Solution, above, to
bypass TPicture.Draw() by setting fDataHandle to NIL before calling INHERITED
Draw(), and then restoring it afterwards. It was the only submission which met all of
the contest's "victory conditions," and so it is the winner-and a pretty good one at that.
Here it is:
{ CenterRectInRect(): Centre the inner rect within the
outer rect, either horizontally, or vertically, or both }
PROCEDURE CenterRectInRect(VAR inner: Rect; outer: Rect;
horiz, vert: Boolean);
VAR
innerSize, outerSize: Point;
BEGIN
WITH outer DO
SetPt(outerSize, right - left, bottom - top);
WITH inner DO
BEGIN
SetPt(innerSize, right - left, bottom - top);
IF horiz THEN
left := outer.left+(outerSize.h-innerSize.h) DIV 2;
IF vert THEN
top := outer.top+(outerSize.v-innerSize.v) DIV 2;
right := left + innerSize.h;
bottom := top + innerSize.v;
END; { with }
END; { CenterRectInRect}
TYPE
TAspectPicture = OBJECT(TPicture)
PROCEDURE Draw(area: Rect); OVERRIDE;
{ Draw(): Modified from TPicture.Draw to grab the actual
picture frame, and then centre this frame within the
TPicture area before drawing it. }
PROCEDURE TAspectPicture.Draw(area: Rect); OVERRIDE;
VAR
oldState: SignedByte;
cntlFrame,
myPicFrame: Rect;
saveDataHandle: picHandle;
BEGIN
IF fDataHandle <> NIL THEN
BEGIN
IF fRsrcID <> kNoResource THEN
LoadResource(Handle(fDataHandle));
IF fDataHandle^ <> NIL THEN
BEGIN { If there's room for the picture }
ControlArea(cntlFrame);
myPicFrame := fDataHandle^^.picFrame;
CenterRectInRect(myPicFrame, cntlFrame,
TRUE, TRUE);
oldState :=
GetHandleBits(Handle(fDataHandle));
HNoPurge(Handle(fDataHandle));
PenNormal;
DrawPicture(fDataHandle, myPicFrame);
SetHandleBits(Handle(fDataHandle),
oldState);
END; { then }
END; { then }
saveDataHandle := fDataHandle;
fDataHandle := NIL;
INHERITED Draw(area);
fDataHandle := saveDataHandle;
And the moral of this story is
A number of lessons can be drawn from this example.
First, it would have been better had MacApp's TPicture class contained a GetPictRect()
method, which was called by TPicture.Draw() as ControlArea() is now.
TPicture.GetPictRect() could have called ControlArea(), so the added method would not
have changed the functionality of the code at all.
This is just one example of a problem that runs throughout MacApp: its methods do too
much. The MacApp wizards know this, and will admit to feeling deeply ashamed of
themselves for it (or will with enough beer in them). They, too, are imperfect people,
who write imperfect code-but there are only so many hours in a man-month, and even
wizards need sleep.
Second, a sufficiently powerful language can hide a multitude of sins. C++'s scope
resolution operator does not remove the problem, but it makes dealing with it much
easier. A powerful language can never make up for a bad design, but MacApp cannot
reasonably be expected to reach perfection anytime soon, whereas I'm supposed to have
shipped yesterday. MacApp 3.0's being in C++ sounds better and better each day (but
perhaps I'm having ear trouble).
Third, this example shows that in MacApp development, you can do just about
anything, one way or another-or another, or another, or another.
Fourth, and finally, I offered to split the payment for this article with the winner of
the contest because I knew that FrameWorks didn't pay anything for its articles. Ha,
ha, funny me. A new editor took over FrameWorks, changed the policy-and now I have
to fork over some real money to the winner. I out-foxed myself. There's got to be a
lesson in here somewhere.
Procrustes revisited
The fact that we were able to get the TAspectPicture class to work-eventually-suggests
that the analogy between MacApp and the iron bed of Procrustes is unfair. But I think
not; I think it's fair to say that, even after racking our brains, the solutions we came
up with were quite a stretch-and that's what Procrustes' iron bed was all about. n