In earlier releases, a number of the components depended on two common libraries: Common and Model View Controller (MVC). Now, the Common and MVC libraries have been combined into a new library, Stingray Foundation Library (SFL).

SFL includes these as well as a number of other subsystems that provide powerful components for use in your MFC and ATL applications. As an example, a number of MFC-like helper classes have been added for use in thin client ATL applications (i.e. device context, rectangle, and point classes, just to name a few). This allows you to code in ATL with some of the ease of MFC, but without having to add all of MFC's extra weight to your thin ATL project. To allow two classes with the same name in SFL, C++ namespaces have been used to prevent them from conflicting. SFL uses namespaces to prevent conflicts between classes that may have the same class name.

If your project uses classes from the old Common or MVC libraries, you can use the same classes now found in the SFL library, wrapped by the stingray::foundation namespace. This means that some classes may not compile within your project unless their scope has been resolved. For example, objects like this:

SECJpeg m_imageJpeg; SECBitmapButton m_btnBmp;

will compile with errors unless their scope is resolved either on an object by object basis like this:

stingray::foundation::SECJpeg m_imageJpeg; stingray::foundation::SECBitmapButton m_btnBmp;

or by using the entire namespace:

using namspace stingray::foundation; SECJpeg m_imageJpeg; SECBitmapButton m_btnBmp;

While either of these two methods will resolve the object's scope, it is usually preferable to use the first. Exporting an entire namespace into your project is not a good way to maintain compartmentalization and can possibly cause naming conflicts.