Crystal Space 2.0.0: 4.3.1.11 Advanced Techniques

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

#### 4.3.1.11 Advanced Techniques

The SCF library implements some things that you will need to know about to use some advanced techniques. They are described in detail, below.

#### Dynamic Class Registration

You can register and deregister SCF classes at run time. There are times when you would like to provide a named SCF class in your main application, rather than in a plugin module. In this case, you will need to manually register the class with SCF since it will not be discovered by the automatic scan for plugins. To do this, the following method is provided:

    bool iSCF::RegisterClass (
      scfFactoryFunc,
      char const* ClassName,
      char const* Description,
      char const* Dependencies,
      char const* context);

Rather than having to remember to call this method from your code, you can automate the registration by instead using the `SCF_REGISTER_STATIC_CLASS()` macro, which takes the following arguments:

    SCF_REGISTER_STATIC_CLASS(
      C++Class,
      "scf.class.name",
      "description",
      "comma-separated dependency list" or NULL)

This macro should be used at the top-level of the source file, outside of any function.

If a class resides in a plugin module which was not discovered by the startup scan, and if you do not elect to have SCF scan for the plugin with `iSCF::ScanPluginsPath()` or an additional call to `scfInitialize()`, then you can manually tell SCF all about the class with the following method:

    bool iSCF:RegisterClass (
      char const* ClassName,
      char const* PluginPath,
      char const* FactoryClass,
      char const* Description,
      char const* Dependencies,
      char const* context);

You can deregister a registered class with the following function:

    bool iSCF::UnregisterClass(char const* ClassIName)

#### Non-Registered Classes

Often, you do not need or want to register a class with the SCF kernel. That is, you create your objects manually, using `‘new’` or some other method and return them to callers of your functions as pure SCF interfaces. This is a perfectly valid use of SCF classes, and is often employed. It is common, for instance, for a named, published SCF class to vend unnamed classes to callers of its methods. These classes are often helper classes. In this case the unnamed object is not a part of the class registry.

#### Non-Parented Classes

Often, classes do not need to be parented. This is frequently true of classes which are not named and part of the class registry, as noted above. In this case your object is not a part of the class tree (see above) and thus does not have a parent. To implement such a class, you simply don't pass a parent to `scfImplementationType()`.

[ < ] | [ > ] |  | [ << ] | [ Up ] | [ >> ] |  |  |  |  | [Top] | [Contents] | [Index] | [ ? ]

This document was generated using texi2html 1.76.