Volume Number: 14 (1998)
Issue Number: 11
Column Tag: From The Factory Floor
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<CSomePane*>
(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.
