source: OGRE/trunk/ogrenew/OgreMain/include/OgreUserDefinedObject.h @ 692

/*
-----------------------------------------------------------------------------
This source file is part of OGRE
    (Object-oriented Graphics Rendering Engine)
For the latest info, see http://www.ogre3d.org/

Copyright (c) 2000-2005 The OGRE Team
Also see acknowledgements in Readme.html

This program is free software; you can redistribute it and/or modify it under
the terms of the GNU Lesser General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59 Temple
Place - Suite 330, Boston, MA 02111-1307, USA, or go to
http://www.gnu.org/copyleft/lesser.txt.
-----------------------------------------------------------------------------
*/
#ifndef __UserDefinedObject_H__
#define __UserDefinedObject_H__

#include "OgrePrerequisites.h"

namespace Ogre {


    /** This class is designed to be subclassed by OGRE users, to allow them to
        associate their own application objects with MovableObject instances
        in the engine.
    @remarks
        It's always been suggested that an OGRE application would likley comprise
        a number of game objects which would keep pointers to OGRE objects in order
        to maintain the link. However, in some cases it would be very useful to be able to
        navigate directly from an OGRE instance back to a custom application object.
        This abstract class exists for this purpose; MovableObjects hold a pointer to
        a UserDefinedObject instance, which application writers subclass in order to
        include their own attributes. Your game objects themselves may be subclasses of this
        class, or your subclasses may merely be a link between them.
    @par
        Because OGRE never uses instances of this object itself, there is very little
        definition to this class; the application is expected to add all the detail it wants.
        However, as a hint, and for debugging purposes, this class does define a 'type id',
        which it is recommended you use to differentiate between your subclasses,
        if you have more than one type.
    */
    class _OgreExport UserDefinedObject
    {
    public:
        /** Standard constructor. */
        UserDefinedObject();
        virtual ~UserDefinedObject() {}

        /** Return a number identifying the type of user defined object.
        @remarks
            Can be used to differentiate between different types of object which you attach to
            OGRE MovableObject instances. Recommend you override this in your classes if you
            use more than one type of object.
        @par
            Alternatively, you can override the getTypeName method and use that instead; 
            that version is a litle more friendly and easier to scope, but obviously 
            slightly less efficient. You choose which you prefer.
        */
        virtual long getTypeID(void) const;

        /** Return a string identifying the type of user defined object.
        @remarks
            Can be used to differentiate between different types of object which you attach to
            OGRE MovableObject instances. Recommend you override this in your classes if you
            use more than one type of object.
        @par
            Alternatively, you can override the getTypeID method and use that instead; 
            that version is a litle more efficient, but obviously 
            slightly less easy to read. You choose which you prefer.
        */
        virtual const String& getTypeName(void) const;
        
    };
    
        

}

#endif