home *** CD-ROM | disk | FTP | other *** search
- Path: 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
-
- 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
-
-