Article View: comp.sys.mac.oop.macapp3
Article #221Another one! (Part 1)
From: Research SW Design, D Goldman,PR...
Date: Tue, 05 Jan 1993 09:59
Date: Tue, 05 Jan 1993 09:59
39 lines
1737 bytes
1737 bytes
I'm not hunting for these, really! But here is another tiny bug that I have
just stumbled upon, whose fix I again assert is completely safe to make BY
INSPECTION, without any lengthy QA cycle.
I am posting these in part for the usual reason of alerting my fellow
developers to problems they might encounter in their work. But in the context
of this thread, I really do want to demonstrate that there are plenty of truly
localized bugs that somebody could EASILY be fixing in a master copy of MacApp,
and distributing to all of us on a periodic basis.
[Again, to avoid any hard feelings, I want to emphasize that the discussion of
these really tiny bugs is not intended in any way as a criticism of MacApp or
its creators and maintainers.]
The bug:
In TTabber::Tab we find this:
fNext->BecomeTarget();
fNext->SetTargetSelection(kRedraw);
The problem:
If the current target refuses to resign, and therefore BecomeTarget()
returns FALSE, we will nevertheless scroll to bring the aborted new
target into sight. Depending on your situtation, this could actually
scroll the still-current target out of sight.
The solution:
if ( fNext->BecomeTarget() )
fNext->SetTargetSelection(kRedraw);
So, anybody have an argument with this one?
-- Dave Goldman
Research Software Design
Technical Details
Message-ID:
<726228373.1142670@AppleLink.Apple.COM>Path:
arc1-ca.pugleaf.net!sparky!uunet!olivea!apple!applelink.apple.comShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!olivea!apple!applelink.apple.com From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT) Newsgroups: comp.sys.mac.oop.macapp3 Subject: Another one! (Part 1) Message-ID: <726228373.1142670@AppleLink.Apple.COM> Date: 5 Jan 93 09:59:00 GMT Sender: daemon@Apple.COM Organization: AppleLink Gateway Lines: 39