One of the new features in DR8 is message filtering, which is based on the BMessageFilter class. This class, along with associated functions in BLooper and BHandler, gives developers a powerful tool for filtering messages. Prior to DR8, the BeOS allowed you to filter only a few system-defined messages, such as B_MOUSE_DOWN and B_KEY_DOWN. This old-style filtering was part of the BWindow class (see the sections on BWindow::FilterMouseDown, FilterKeyDown, and so on in The Be Book). The new filtering system is much improved.

It's worth noting that the old style of filtering still exists in DR8, but it's on the chopping block, and one day soon it will be gone. So now's the time to learn about the new filtering mechanism and to update your code.

BMessageFilter provides two styles of filtering. The first is based on a built-in hook function, which you can override in your subclass:

virtual filter_result
  BMessageFilter::Filter(BMessage *msg, BHandler **target)

The Filter() function is then called for any message that matches the "filter" criteria. The target parameter indicates which handler is destined to receive the message. By passing a pointer to a pointer, you're allowed to alter the target. The hook function returns a filter_result that is either B_SKIP_MESSAGE or B_DISPATCH_MESSAGE. The latter tells the system to continue processing the message, while the former says to stop, the message should be discarded.

BMessageFilter also supports a function pointer interface, removing the need for subclassing (this ought to make some of you out there happy). With this style you can define a filter function like so:

filter_result
  my_filter_func(BMessage *msg, BHandler **target,
      BLooper *looper)

You can then pass a pointer to this function to the BMessageFilter constructor:

new BMessageFilter(... <other arguments> ...,
     my_filter_func)

What's with "<other arguments>" you might ask? Let me explain. The BMessageFilter class is designed to filter messages using various criteria, specified using these <other arguments>. Are you interested in a filtering a particular kind of message, for example, the B_MOUSE_DOWN message, or are you interested in any message sent by a particular party, for example, any third party? Maybe you're interested in some combination? BMessageFilters give you all this power and more.

There are three distinct characteristics of a message that can be used to define the filter criteria:

• "How" How did the message arrive. Was it dropped by a user or programatically delivered using PostMessage or SendMessage. The options are B_ANY_DELIVERY, B_DROPPED_DELIVERY, or B_PROGRAMMED_DELIVERY.

• "Who" Who originated the message. Was it the app itself or was it some other application. The options are B_ANY_SOURCE, B_LOCAL_SOURCE, or B_REMOTE_SOURCE.

• "What" What type of message is it. This is the "what" field of a BMessage and can be any value.

Now the "<other arguments>" will make sense:

new BMessageFilter(message_delivery how,
                   message_source   who,
                   ulong            what)

These three criteria can be combined in arbitrary ways. Here are several examples:

• You want to filter a particular message, say B_KEY_DOWN, but you're not interested in how the message was delivered or who sent the message. Here's the filter to want:

  new TMyMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE,
       B_KEY_DOWN)
  

  This example is basically mimics the old-style BWindow::FilterKeyDown() function.

• You want to filter any dropped message that came from another application, and instead of subclassing and overriding the Filter() function, you've decided to write your own filter function:

  new BMessageFilter(B_DROPPED_DELIVERY, B_REMOTE_SOURCE,
      my_filter)
  

  By not specifying a particular "what" field, all dropped messages will be filtered, regardless of the "what" field.

• You're really nosy and want to peak at every stinking message. Here's what you would do:

  new TNosyMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE)
  

Now that you know how to create filters, you need to know how to attach them to loopers and handlers in order to actually do anything. You've got a couple of options here. You can filter messages targeted for a specific handler, for example, a specific view in a window. Or you can filter all messages that go through a particular looper, for example, all messages being dispatched by a window. You chose between these alternative by adding the filter to the appropriate object:

BLooper::AddCommonFilter(BMessageFilter *filter)

or

BHandler::AddFilter(BMessageFilter *filter)

Filters added to a handler only apply to that handler, while filters added to a looper using AddCommonFilter apply to all messages dispatched by that looper.

That's about all there is to filtering. Until next time, happy filtering.

I'll admit it. I didn't have enough time to spend on this week's article. I was off in Seattle giving demos and writing articles for magazines. So those of you who are very astute will notice that I'm treading water this week and only offering what amounts to a lot of filler. But I want to stay in your face and on your mind lest you forget how nifty and neat the BeOS is to program and use.

First of all, although I've been very busy, I still have a coding sample.

ftp://ftp.be.com/pub/Samples/Multipede.tgz

Multipede is a very minimalist port of the xcentipede game. This is an arcade classic. The primary feature of this little app is that it demonstrates how to use the following:

• GameStick from previous newsletter
• Messaging
• BWindowScreen
• Graphics stuff

Of particular interest might be the ATicker class. This is a simple thread-based ticker, which can generate a Tick() at any given interval, or rate, using any units of time. It's used by the GameStick object to periodically poll the joystick position.

You may also find the AThread object (oskernel.h) useful as a simple encapsulation of the thread functions of the BeOS. This is very useful in many different areas when you may not feel comfortable with the standard 'C' interface to threads the OS provides.

The original X-based code was all in one file. It was compact and pretty straightforward. The Multipede release consists of many files, it's more modular, and, I believe, easily understood. I tried to create a sample that was first, a native implementation of the BeOS, and second, easy to understand and useful for subclassing. So there you have it.

While the AppModeler development toolkit never came out with DR8 as announced, AppSketcher replaces it now. A few more weeks were needed to make it solid and robust, ready to increase Be developers' productivity. Many Be developers have been helping us to enhance AppSketcher, with relevant comments in the comp.sys.be newsgroup and the BeDevTalk mailing list. Beta testers were also very helpful in our efforts to design an object development tool that provides benefits to the whole Be developer community.

Why and What Is AppSketcher?

Although Be Interface Kit is very easy to use and to program with, most of us prefer to concentrate on the development of specific parts of our applications, rather than spending time generating a coherent user interface.

As you will discover, AppSketcher is more or less a nutshell: All it knows is that a world can be described with windows, views, controls, and menus. But no particular object is loaded the first time you launch AppSketcher, so the first step is to parse the header files corresponding to the kits provided by our favorite Be engineers. Then AppSketcher knows more: It can manipulate objects from the Interface Kit and even create applications. You can now design your interface graphically, connect control objects to your functions, even test your user interface. What comes next depends only on you: If the objects provided by Be fulfill your needs, you don't need to read more. But if you want to implement your own objects, with their own look and feel, or if you want to set some parameters for objects directly in AppSketcher, then you will have to teach it about your own classes. As part of this process, you will modify AppSketcher and increase the range of its features. Our job is done now, and we're waiting for you to take care of our child and to help him become a grown-up.

What Can You Expect from AppSketcher?

AppSketcher offers:

• A graphical interface design tool, which can be used interactively

• The capability to add C++ objects, either as interface elements or simply as objects that applications create

• A way to connect interface items (controls) with the member functions of the objects that have been added

• A process for initializing object members with the pointer to other application components

• A tool you can use throughout a project's lifetime

All you have to do now is connected to the Be web site, download AppSketcher, and read its documentation. (AppSketcher will be available in the Developer area of the Be web site this week. Watch the What's New page for the announcement.)

We'd like to thank Be, Inc., whose BeOS has made the one- year-old AppSketcher application possible. All of us at Lorienne [Now BeatWare] were very pleased to work with talented Be team.

Once again, we're treated to a great show. Fortunately, there's also substance behind the verbal pyrotechnics and the demos. I'm referring to the most recent Network Computer announcements—of course. And I'm betting we'll all benefit in the end from the sometimes raucous conflict between the advocates of the NC and the defenders of the PC.

But let's start with the basics. Ostensibly, the NC is a way to fight the ever-increasing cost of ownership of a PC. A number of studies by the Gartner Group or Forrester Research agree corporations spend around $10,000 per year, per PC. The culprit is the growing disorder and fat afflicting hardware and software configurations.

For years, Sun has claimed the newtwork _is_ the computer, and they built a nice business on that claim. They also transmogrified their set-top box language, OAK, into Java, a way to design and deliver platform-independent applications. Et voila, all the ingredients for NC. Just a processor, memory, and network connection and you have a machine that's both less expensive to purchase and to own. Less expensive to purchase because you get rid of unnecessary organs, such as the floppy, the hard disk, or a bus. Less expensive to own because all the data and programs are centrally (and thus more safely and economically) managed. When you need it, you invoke the Java word processor from the server. When you're done, it disappears without cluttering your system. Clean computing.

We know, of course, life is never that simple. Nagging questions arose immediately. Such as the need for some caching device. A hard disk, perhaps. But then, what's the difference with a PC? The fact Microsoft doesn't control the architecture? Unfortunately, the argument degenerated into an anti-Microsoft one, confusing what the NC does for the customer with what it does against Microsoft.

In the early days of the NC battle of words, Bill Gates openly derided the concept, pointing to the weak difference in hardware costs between a PC and an NC. But the issue of cost of ownership did not go away, especially with the sometimes painful transition from Windows 3.1 to Windows 95 and Windows NT. Larry Ellison and Scott McNealy are powerful ideologues and very successful businessmen. Their advocacy of the NC carries weight, and Java gained traction, now assured of becoming a mainstream language.

So what did Bill Gates do? Last week, at the Agenda Conference in Phoenix, Arizona, Larry Ellison had an off day. His pitch for the NC wasn't as calm and statesmanlike as we were used to expect from him. Bill Gates, on the contrary, decided to embrace the key NC concepts and, by pure coincidence, the official announcement came yesterday, right on the eve of Sun's official NC intro. There are some good ideas there, some real problems, said Bill. We'll have a simplified PC architecture supported by Compaq, Hewlett- Packard, Dell, and other noted players. It will be less expensive to purchase and to own because we'll offer the capability to centrally manage data and application software.

Critics say it's a mere retooling of the SIPC, the Simple Interactive PC architecture previewed in February. It doesn't matter. What counts is what will be delivered, by whom, and when. In the end, we're likely to get in the healthy habit of delivering and updating software automatically over the network, the Internet or the intranet, thus making users and software developers happier. Plus it will make a couple of companies, such as Marimba, who've already thought of that business, richer.