I would like to share with you a neat technique of using function objects with the BMessage class to simplify some common patterns in your application code.

Consider a menu containing an item for every window open in an application. When an item from the menu is selected, we would like to call some code to make the corresponding window active. Part of the menu building code might look something like this:

for (int32 index = 0; index < windowCount; index++) {
  BWindow *window = windowList->ItemAt(index);
  BMessage *message = new BMessage(kSelectWindowMessage);
  message->AddInt32("index", index);
  menu->AddItem(new BMenuItem(window->Title(), message));
}

We would then have a corresponding MessageReceived() function, that would contain the following code:

switch (message->what) {
  case kSelectWindowMessage:
    int32 index;
    message->FindInt32("index", &index);
    windowList->ActivateIndexedWindow(index);
    ...

where windowList is of an unspecified WindowList class.

When we were building up the window menu, we knew ahead of time that we would end up calling ActivateIndexedWindow() when an item was selected, and passing it the index as a parameter, we knew we would call it on the windowList object. It seems like it would be convenient to be able to hide the corresponding message dispatching and parameter packaging code into some more convenient shorthand. Wouldn't it be nice if instead we could write:

for (int32 index = 0; index < windowCount; index++) {
  BWindow *window = windowList->ItemAt(index);
  BMessage *message = new NewFunctionObjectMessage(
    &WindowList::ActivateIndexedWindow, windowList, index);
  BMenuItem *item = new BMenuItem(window->Title(), message);
  menu->AddItem(item);
}

and get rid of the code in MessageReceived() altogether. We will try to do just that using a function object packaged inside a BMessage.

windowList->ActivateIndexedWindow(index);

class FunctionObject {
  public:
    FunctionObject(void (WindowList::*callThis)(int32),
      WindowList *onThis,
      int32 withThis)
      :  function(callThis),
         target(onThis),
         parameter(withThis)
      { }
     void operator()() const
       { (target->*function)(parameter); }
  private:
    void (WindowList::*function)(int32);
    WindowList *target;
    int32 parameter;
  };

FunctionObject *functor = new FunctionObject(
  &WindowList::ActivateIndexedWindow, windowList, index);

(*functor)();

windowList->ActivateIndexedWindow(index);

function();
function(param1);
function(param1, param2);
function(param1, param2, param3);
...

class FunctionObject {
  // the abstract superclass that defines the common interface
  public:
    virtual ~FunctionObject() {}
    virtual void operator()() const = 0;
    virtual ulong Size() const = 0;
  };

template<class FT, class T>
class PlainMemberFunctionObject : public FunctionObject {
  // function object without any parameters
  public:
    PlainMemberFunctionObject(FT callThis, T *onThis)
      :  function(callThis),
         target(onThis)
      {
      }
    virtual ~PlainMemberFunctionObject() {}
    virtual void operator()() const
      { (target->*function)(); }
    virtual ulong Size() const { return sizeof(*this); }
  private:
    FT function;
    T *target;
  };

template<class FT, class T, class P>
class SingleParamMemberFunctionObject : public FunctionObject {
  // function object with a single parameter
  public:
    SingleParamMemberFunctionObject(FT callThis, T *onThis, P withThis)
      :  function(callThis),
         target(onThis),
         parameter(withThis)
      {
      }
    virtual ~SingleParamMemberFunctionObject() {}
    virtual void operator()() const
      { (target->*function)(parameter); }
    virtual ulong Size() const { return sizeof(*this); }
  private:
    FT function;
    T *target;
    P parameter;
  };

template<class FT, class T, class P>
class DoubleParamMemberFunctionObject : public FunctionObject {
// function object with two parameters
  public:
    DoubleParamMemberFunctionObject(FT callThis, T *onThis,
      P1 withThis1, P2 withThis2)
      :  function(callThis),
         target(onThis),
         parameter1(withThis1),
         parameter2(withThis2)
      {
      }
    virtual ~DoubleParamMemberFunctionObject() {}
    virtual void operator()() const
      { (target->*function)(parameter1, parameter2); }
    virtual ulong Size() const { return sizeof(*this); }
  private:
    FT function;
    T *target;
    P1 parameter1;
    P2 parameter2;
  };

class FunctionObjectMessage {
  public:
    static bool DispatchIfFunctionObject(BMessage *);
  protected:
    static BMessage *NewMessage(constFunctionObject *);
  };

BMessage *
FunctionObjectMessage::NewMessage(constFunctionObject *functor)
{
  BMessage *message = new BMessage('fCmG');
    // any message with this pattern
    // will be a function object
  message->AddData("functor", B_RAW_TYPE, functor,
    functor->Size());
    // invoke the virtual Size call here to get the actual size of
    // the concrete function object subclass
    // need to check for errors in a real app
  return message;
}

bool
FunctionObjectMessage::DispatchIfFunctionObject(BMessage *message)
{
  if (message->what != 'fCmG')
    return false;
  // find the function object
  long size;
  constFunctionObject *functor;
  status_t error = message->FindData("functor", B_RAW_TYPE, &functor,
    &size);
  if (error != B_NO_ERROR)
    return false;
  // function object found, call it
  (*functor)();
  return true;
}

void
MyApp::MessageReceived(BMessage *message)
{
  if (FunctionObjectMessage::DispatchIfFunctionObject(message))
    return;
  // not a function object, handle other messages here
  ...

class WindowListFunctionObjectMessage : public FunctionObjectMessage {
  public:
    static
      BMessage *NewFunctionObjectMessage(void (WindowList::*func)(),
      WindowList *target)
      { return NewMessage(
        &PlainMemberFunctionObject<void (WindowList::*)(),
          WindowList>(func, target)); }

    static BMessage *NewFunctionObjectMessage(void
      (WindowList::*func)(ulong),
      WindowList *target, ulong param)
      { return NewMessage(
        &SingleParamMemberFunctionObject<
          void (WindowList::*)(ulong),
          WindowList, ulong>(func, target, param)); }
  };

for (int32 index = 0; index < windowCount; index++) {
  BWindow *window = windowList->ItemAt(index);
  BMessage *message =
    new WindowListFunctionObjectMessage::
      NewFunctionObjectMessage(
        &WindowList::ActivateIndexedWindow,
        windowList, index);
  BMenuItem *item =
    new BMenuItem(window->Title(), message);
  menu->AddItem(item);
}

Hello! Let me take this opportunity to introduce myself—I'm Brian, one of the Be support staff. I am often the one who replies to messages sent to custsupport, devsupport and devservices@be.com, so some of you have already had some interaction with me.

When I'm not running around the company searching for the answers to your questions, I accept (and occasionally regretfully deny) your applications to become official registered Be developers. I also test developer's BeWare submissions on the ftp site, and then move them into their appropriate pub/contrib directories.

And from time to time, I get pulled into helping out on whatever tasks need extra assistance at that particular moment (as does every Be employee). You may have seen me at Apple's WWDC, or you may read the few sections of the Be User's Guide authored by yours truly (10 points if you can guess which ones!).

Now that I have formally introduced myself, let me be a wee bit honest. I recently returned from vacation to find a friendly e-mail message from Valerie informing me of my assignment to write a Be Newsletter article.

Bewildered for a moment, it hit me—take this opportunity to try to clarify four issues which in the past we might have made confusing, in order to help you become informed about Be and the BeOS. Let me start with the required Be newsletter metaphor and go from there...

I recently went back to Massachusetts to attend my high school reunion. While there, I spent two nights in a row stargazing and reminiscing with an old friend. Friday night was rather overcast, with only the occasional star poking out here and there, but Saturday night was something else entirely. There was not a cloud in the sky and with the air in rural western Massachusetts, you can see EVERYTHING, from your favorite constellation to the beautiful stream of the Milky Way.

How does this pertain to online support at Be? I like to look at it in the following way: Trying to find information on some web sites is much like trying to stargaze on an overcast night. You might find a nugget or two of information, but for the most part, there are still unanswered questions.

Realizing how annoying this is for customers, at Be we try to make it as easy as stargazing on a clear night in rural Massachusetts. We believe we have very little to gain by keeping information from you. So before you ask your neighbor if Orion can be seen, try looking up. You'll be surprised at what you'll find in the sky—or on the Be web site!

Still, we do occasionally cloud our own skies; I can see that in some of the e-mail messages I respond to. I'd like to make an attempt to blow the clouds away from those issues, and clear the skies so you can see Neptune...

So that's it. I hope this article is of help to you and has cleared up any confusion we may have caused concerning any of the four issues I covered. Let me know if I need to brush up on my metaphors...

Can you spot the change from the last version?

status_t HomeDirectory(char *dir, constint buffLen)
{
    app_info info;
    be_app->GetAppInfo(&info);

    BEntry appentry;
    appentry.SetTo(&info.ref);

    BPath path;
    appentry.GetPath(&path);
    strncpy(dir,path.Path(),buffLen);
    dir[buffLen-1] = '\0';

    return B_NO_ERROR;
}

Anyway... Blue box, yellow box, little blue box, Windows NT, pizza, Jolt, Mountain Dew, 90 degrees, 99.999% humidity... What does this sound like?

Mac Hack of course! You know, it's kind of funny. The conference starts at Midnight and goes on for a few days. You do a lot of, "How late did you stay up?", "5am". But then you don't wake up until 12pm. You might as well just go to bed on time and get up early, but that would not adhere to the hacker ethic.

It was fun. Yasmin and Anita came along too. While I was staying up bleary eyed, they were visiting the Henry Ford Museum, and other choice places around Detroit. This conference really is for the Mac faithful. The crowd was split between really old timers, and really new timers. The Woz gave his life history, which I actually found to be interesting, maybe because it didn't end until 3am. He even managed to slip in a controversial analysis of Steve Job's opinion of Apple's NeXT purchase. And in his mind, Apple should be concentrating on K-12.

Well, Benoit did a hack and gave a show. It was a real-time Mandelbrot zoomer that had the crowd cheering even before he showed the "fast" version. It didn't win one of the many awards, but things like multi-colored menus did. Things just aren't what they used to be. The take home point for me was, we are merely guests at this party.

ftp://ftp.be.com/pub/dr9/samples/mandelhack.tgz

I spent my time doing a hack as well, but I didn't feel like submitting it because it actually might be useful.

ftp://ftp.be.com/pub/dr9/samples/pciviewer.tgz

This thing is like PCIProbe and the poke command combined. It will list your PCI devices in the left half of the window using BOutlineListView, and show the actual register values and other stuff on the right when you click on the individual entries. For those of you who have been wanting to use the BOutlineListView, here's you're chance. It uses this class, as well as a custom ListItem. What great fun. I thought about making it into a full-fledged PCI debugger like poke is, but I ran out of time. Maybe that's an exercise for the reader.

Well, the Preview Release is now headed for the doors and the final anticipation can begin. You wouldn't believe how tense things can get when a lock down is in progress. We have a thing here called Dr. No. That's an engineer who is assigned the unthankful task of saying "NO!" to last minute changes so that the final release is as stable as possible, and actually gets out the door on time. The couple of Dr. No's did an excellent job and I think we have a really good release headed your way. As you read the release notes you will find that although we did a tremendous amount of good work, you can expect there to be some anomalous behavior. This release is a good solid foundation upon which our future can be built.

When you do finally get it within a few weeks, code like mad, give us feedback, and move on to commercial Nirvana.

Geoff is back from Europe, and his first e-mail said he is anxious to write an article about the experience. So, not to steal any steam, I'm sure you can look forward to an enlightening expose from our American in Paris.

I saw the question being asked in several on-line messages; this is a good opportunity to clarify our position on the matter of UI guidelines. First, as I write this in the Geneva airport, and if I believe e-mail and voice-mail messages, we're in great danger of cutting the final, really, Preview Release CD and sending it to duplication.

The developer conference AA:PR CD gave us a great deal of feedback, energetic and, for the most part, encouraging. Positive or humbling, the feedback is most appreciated and we're doing our best to reciprocate, that is, making this developer release a credible foundation upon which to start building useful and money-making applications. This, of course, is for developers to decide. I rest secure, sort of, in the knowledge we're not dealing with a shy and retiring community.

Still with the UI guidelines in mind, the Preview Release was a very ambitious project. Some would say we deluded ourselves when we started, others might add this is the very kind of denial required for starting a family, remodeling a house—or writing OS software. Among the features and functions we wanted to improve, the user interface. The graphic look, up to DR 8, was well received, but function was found wanting. In particular, the "dock" concept didn't get many votes. What we got, instead, were many requests for a (now) more conventional desktop, keeping the workspaces.

Make it so, you said.

This reopened many UI issues and launched us into a great deal of experimenting with everything from color schemes, to text, to icons, to taskbars, to preferences... In many respects, for the Preview Release, UI decisions were made last. The next result is our documentation is behind the software, itself behind schedule—with our apologies.

Now, when it comes to UI guidelines, I understand the need for them and, at the same time I fear them a little. I don't want them to stifle creativity. Call this trying to put a good face on our lateness, but after our sometimes painful experimentation with UI function and look, I hope we'll see some daring exploration from Be developers. You're not going to see UI ayatollahs from Be demanding observance to UI guidelines, published or not. I think it's a) for us at Be to set one (by no means representing it to be the only one) example of decent UI design and, b) for users to vote with their wallet for what they like most, no reasons asked.

Of course, there is danger with that approach. Anarchy, ugliness, confusion. As for anarchy, I firmly believe developers will do what they want, anyway. The meek will not inherit our region of the Earth. For ugliness, it disappears quickly, unless the product is incredibly useful, or inexpensive. All of which is fair. Lastly, confusion. In the early days of bit-mapped screens and pointing devices, perhaps, when customers, even sophisticated ones, were unfamiliar with the emerging paradigms, sorry, ways.

No such problem anymore.

Still, no excuses, we need to, and will publish UI guidelines, if only to provoke creativity and observance in the breach.