You initialize a BAppFileInfo object by passing it a BFile object that represents an application or add-on. The BFile needn't be open for reading, but it must be open for writing if you want to set information. The BAppFileInfo object doesn't take over ownership of the BFile that you pass it; in particular, deleting a BAppFileInfo doesn't cause the underlying BFile to be deleted.

To initialize a BAppFileInfo to point to the executable of be_app, you do this:

/* To get app file info for be_app. */
app_info appInfo;
BFile file;
BAppFileInfo appFileInfo;

be_app->GetAppInfo(&appInfo);
file.SetTo(&appInfo.ref, B_READ_WRITE);
appFileInfo.SetTo(&file);

When you ask a BAppFileInfo object to get some information, it looks in its BFile's attributes; if the information isn't there, it then looks in the file's resources. When you ask it to set some information, the info is written as an attribute and also stored as a resource. You can modify this behavior through SetInfoLocation(): You can tell the object to only access the file's attributes, or to only access the resources.

The signature, icons, and supported types that you set through the functions provided here ( SetSignature(), SetIcon(), SetIconForType(), SetSupportedTypes()) are also recorded in the File Types database, as described in the various functions.

You should take care when using the following functions (inherited from BNodeInfo):

SetPreferredApp()

Never set an application's preferred app; an application is automatically set to be its own preferred app—it won't work otherwise. An add-on's preferred app is usually itself, but it doesn't have to be. For example, you could set an add-on's preferred app to be the server or application that loads the add-on.

SetType()

Never set the type of an application or add-on. The type is automatically set to be B_APP_MIME_TYPE (a platform-dependent value). If you change the type, your application or add-on will still run (probably), but other parts of the system (double-clicked documents, for example) may have a hard time finding it.

When you ask a BAppFileInfo to retrieve information by reference, the object doesn't clear the reference argument if it fails. Because of this, you should always check the error code that's returned by the Get…() functions.

The common errors that BAppFileInfo functions return are these:

The info-reading and -writing functions may also return the error codes declared by BNode::ReadAttr() and BNode::WriteAttr() , and by BResources::WriteTo().