Nov 98 Factory Floor
Volume Number: 14
Issue Number: 11
Column Tag: From The Factory Floor
A PowerPlant Update, Part 2
by John Daub and Dave Mark, ©1998 by Metrowerks, Inc., all rights reserved.
This month's column is the second installment in our series on PowerPlant. Last month
we spoke with the godfather of PowerPlant, Greg Dow. This month, we'll hear from
John Daub, another key member of the PowerPlant team.
Dave: What are your thoughts on getting started with PowerPlant?
John: I think what Greg Dow said in last month's Factory Floor provided a good
starting point, from a coding perspective. I've found a few concepts that are not exactly
coding related, but have helped me (and others) not only get started in PowerPlant,
but also follow through. These still help me every day.
1. Lay a good foundation - Many people starting out with PowerPlant start
knowing little and desiring to accomplish a lot. The enthusiasm is commendable, but do
not let this enthusiasm turn into impatience. I've seen too many beginners desire to
write the next great Killer App over a weekend, expect PowerPlant to do it all for
them, then get frustrated and give up because of impatience, unrealistic expectations
of PowerPlant, and/or unrealistic goals. That's a shame.
Make a good assessment of where your skills currently are and where they need to be
to accomplish the goals you set for yourself. Then fill in the gaps along that route and
set out.
To work with PowerPlant, you need to know the C++ programming language, and
knowing how to get around the Mac OS Toolbox is certainly beneficial.
If you do not know C++, you should pick up a good book on the language and learn it
first. There are many at your local bookstore, and there are some on the CodeWarrior
CD as well.
Although PowerPlant does hide many of the details of the OS from the user, sooner or
later you will find yourself needing to deal directly with the OS. That's not as scary as
it might sound, and the more familiar you are with the Mac OS Toolbox, the less scary
it will certainly seem. You should at least be familiar with basic concepts like event
loops and dispatching; basic managers like Windows, Dialogs, Menus, Controls; basic
memory management; etc. There are many good books on Mac programming at your
local bookstore (and on the CodeWarrior CD).
After you've laid yourself a good foundation, then start to work with PowerPlant.
I know... that's a lot of background work and could take you some weeks or even months
before you touch PowerPlant at all... and you want to start writing apps now! I do
understand this excitement. I believe you should still take the time to lay a good
foundation for yourself, but tinkering around and getting your hands dirty can be a lot
of fun as well. Just remember that you tend to go further building a house upon rock
than upon sand.
2. Be honest - Not only with others, but mostly with yourself. Learning PowerPlant
isn't easy, but it's not difficult either.
One of the most difficult parts of learning PowerPlant is knowing when you've truly
mastered some concept or technique. When will you know if you've mastered it? You'll
know (don't you hate answers like that? :)
And if you aren't certain, if you doubt your understanding of a concept, perhaps you do
not fully understand it. It's best to be honst with yourself and take the time to go back
and see. Maybe you didn't know it and now you know better. Maybe you did and through
reduncancy you've fostered some learning.
Or maybe you thought you did but corrected yourself, or picked up on a finer point that
you missed the first time around.
Never let your ego get in the way of learning.
3. Read, Ask, Do - Read everything that you can. Books, documentation, magazines,
websites, FAQs, newsgroup archives, and most importantly here, source code. You
learn a lot. Just read, and reread, and reread again.
Ask questions whenever you are not certain of something. If someone is going to look
down on you for asking a question, they've got a problem they need to get over. And keep
asking until you fully understand. The only dumb question is the one never asked.
Do. Write code, write apps. So what if there are a zillon text editors on the market.
Write the zillion-and-one editor. The more you write code, the more you'll learn.
Experience teaches us a great deal that we cannot learn any other way.
4. Spend time in the debugger - The debugger is a great place for the beginner
to learn. If you start out at main and then Step Into every single line of code watching
what goes on, examining variables, monitoring flow, you will learn a great deal about
how PowerPlant works. It can also help you see how the pieces of PowerPlant all fit
together to form an application. And as well, it can help you learn how to debug, which
is a necessary part of development.
5. Be patient and don't give up - I don't believe that anything worth having in
life comes easy. Same holds true for PowerPlant. Like I said before, learning
PowerPlant isn't easy, but it isn't difficult either. If you hit a frustating problem that
you just can't solve, keep at it. Maybe leave it for a while to clear your head, but don't
totally quit. Ask someone else for a fresh perspective. Try to find a different angle
from which to approach the problem. Some of the biggest joys come from solving the
worst problems.
Hang in there. If you don't know what I mean yet, you definitely will sooner or later.
6. There is no such thing as a mistake, so long as you learn from it - So
the app crashed. So it totally trashed your machine and now it won't boot. So what!
Have you learned something from this (aside from "Yea, don't do that!")? In the
beginning, you will probably crash more than run. Take the time to understand why
your code failed and what you (or someone else perhaps) did wrong. Learn from it,
grow from it.
And last, but most of all, have fun.
Dave: What are some of the PowerPlant classes you've work on?
John: I've written some examples and sundry code for PowerPlant, like
LTextEditView, LCMAttachment (Contextual Menu support for PowerPlant), and some
Grayscale implementations ("GA Imps", part of the Appearance Classes). I've also
worked on larger projects like the Cursor Classes (provides cursor support, including
animated cursors. I'm hoping to revamp this for Pro 5) and Debugging Classes.
Dave: Cool, debugging classes. What do they do?
John: The Debugging Classes are a set of tools that hope to make your life a bit easier
and your code more robust and stable. They help you stress test, sanity check, view
information, and a host of other features.
One of the most visible features of the Debugging Classes is the Debug Menu, provided
by LDebugMenuAttachment (see Figure 1).
Figure 1. The Debug menu, provided by the PowerPlant class
LDebugMenuAttachment.
To gain this menu and its functionality within your own project is very simple: just
add the attachment to your application object like this:
void
CMyApp::Initialize()
{
LApplication::Initialize();
#if PP_DEBUG
mDebugMenuAttachment =
new LDebugMenuAttachment(...);
AddAttachment(mDebugMenuAttachment);
#endif
}
That's all! Using the Debugging Classes and the Debug Menu isn't just as simple as that,
but it is fairly close.
The menu is generated on the fly (so it should be relatively painless to add to existing
as well as new projects), and it allows you to perform actions such as breaking into a
debugger; performing compactions, purges, and/or scrambles to your heap; validate
your PPob's; modify the behavior of gDebugThrow and gDebugSignal at runtime
(typically you'd have to recompile to do this); and consume memory to simulate
low-memory conditions.
One of the very useful parts of the menu are the displays of pane and commander
hierarchies on the fly. I know being able to display the commander chain has helped
many people solve their commander problems already. A big thanx to Greg Bolsinga
(our Class Wrangler Wrangler) for the original code to LCommanderTree.
One additional behavior of the menu is how it allows you to work with Metrowerks
utilities, such as ZoneRanger and DebugNew, and third-party utilities, such as QC, at
runtime. Turn QC tests on and off, generate a DebugNew log, clear all DebugNew leaks,
whatever you'd like to do. Normally to change these behaviors you would have to
recompile; but now they have an interface and can be accessed at runtime. Much
handier.
The other portion of the Debugging Classes provides macros and utilities for use within
your code. These build upon the core debugging functionality in PowerPlant (Assert_,
ThrowIfOSErr_, ThrowIfMemFail_, etc.) to help you sanity check and ensure your
code will be solid.
And just like the core macros, when you turn debugging off in PowerPlant, the
Debugging Classes macros are redefined to minimal implementations.
For example, to find a pane by ID, you typically do this:
CSomePane *thePane = dynamic_cast
(theWindow->FindPaneByID(kPaneID));
ThrowIfNil_(thePane);
That's a lot of code to have to type. Plus, although the dynamic_cast is technically
correct, it's not *really* necessary here: after your initial debugging run to ensure
you set your code and PPob correctly, you are pretty much guarenteed that looking for
kPaneID will return the proper object (unless someone fouls up your PPob).
Furthermore, the nil check isn't needed since you should have no problem obtaining a
proper and valid pointer.
With all of this in mind, you can reduce the typing, the code bloat, and runtime
overhead (of the RTTI and the nil check) by using DebugFindPaneByID_.
CSomePane *thePane = DebugFindPaneByID_( theWindow,
kPaneID, CSomePane);
That's all there is to it.
In debug builds, the macro will expand to ensure theWindow is not nil, then perform
the FindPaneByID and dynamic_cast just the same as the original code. It will check
for nil and signal if there is failure. So you have all of the original functionality, and a
lot less typing.
In release builds, the macro reduces to a simple call to FindPaneByID, static_cast'ing
the return result. A lot less overhead (no RTTI, no nil checks) and a lot less code for
releases, but still the sanity and robustness needed for development.
Of course, if you do need to determine the proper object type on the fly, i.e. you need
the dynamic_cast because the pane type is unknown at compile time and/or could vary
at runtime, then by all means do use the previous method to FindPaneByID() so you do
not lose the dynamic_cast when the macro is turned off.
Dave: What's going on with Constructor?
John: As of this writing, Constructor is in maintenance mode and I am the maintainer.
We are not working on any major improvements. The forthcoming RAD tools (and some
future PowerPlant developments) will supersede Constructor in form and function.
I am not adverse to fixing bugs or adding features; in fact I have a list for each category
and would like to work to make the lists shorter. However, RAD at Metrowerks is now
the top priority, so major changes to Constructor probably will not be happening.
We will continue to ship a Constructor with CodeWarrior for a good long while, as
there are many legacy projects that will continue to need and utilize Constructor. We
will ship Constructor until we have a complete and viable replacement.
Dave: What other programming things do you do?
John: Aside from my work at Metrowerks, I try to stay involved in the Mac OS
development community. I've contributed to the WASTE project, do a little informal
(non-profit) consulting work here and there, and write some classes for PowerPlant
that I distribute on my own.
Some people ask me why I write PowerPlant classes outside of my regular PowerPlant
work, or why my outside classes are not rolled into PowerPlant officially. Most of the
things I write in my own time are experiments, tinkering, or just something that
doesn't fit into the scope of "PowerPlant proper". They're still useful (many people
love my CURLPushButton class), but not something that really fits within the core
PowerPlant scope.
Currently (at the time of this writing) I'm looking at WT++, a new all C++ text
engine from Timothy Paustian (author of CWASTEEdit and WebWarrior). It's pretty
neat. And I'm also getting more serious with Linux.
Dave: Any parting comments?
John: I always welcome input and feedback from our users. If you have any comments
or criticisms about any of the topics discussed here or about PowerPlant in general, do
feel free to drop me a line.
I'm hoping to be able to find some time in the near future to write some more in-depth
articles for MacTech, about getting started, the debugging classes, or some other
topics. If readers have any input as to what they might like to see, in terms of some
future articles on PowerPlant, drop a line to editor@mactech.com and CC me. I cannot
promise anything (any of you with children know how life can be sometimes :-) but
I'll certainly see what I can do.