Getting Started Guide Stingray® Studio
Version 11.1
STINGRAY STUDIO GETTING STARTED GUIDE PRODUCT TEAM Development: Terry Crook, Clayton Dean, Boris Meltreger, David Noi Documentation: Marc Betz, Shelley Hoose Development Manager: Clayton Dean Product Manager: Ben Gomez Support: Terry Crook, Boris Meltreger
THIS MANUAL © Copyright 1997-2012 Rogue Wave Software, Inc. All Rights Reserved. Rogue Wave and Stingray are registered trademarks of Rogue Wave Software, Inc. in the United States and other countries. All other trademarks are the property of their respective owners.
ACKNOWLEDGMENTS This documentation, and the information contained herein (the "Documentation"), contains proprietary information of Rogue Wave Software, Inc. Any reproduction, disclosure, modification, creation of derivative works from, license, sale, or other transfer of the Documentation without the express written consent of Rogue Wave Software, Inc., is strictly prohibited. The Documentation may contain technical inaccuracies or typographical errors. Use of the Documentation and implementation of any of its processes or techniques are the sole responsibility of the client, and Rogue Wave Software, Inc., assumes no responsibility and will not be liable for any errors, omissions, damage, or loss that might result from any use or misuse of the Documentation
ROGUE WAVE SOFTWARE, INC., MAKES NO REPRESENTATION ABOUT THE SUITABILITY OF THE DOCUMENTATION. THE DOCUMENTATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ROGUE WAVE SOFTWARE, INC., HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS WITH REGARD TO THE DOCUMENTATION, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT SHALL ROGUE WAVE SOFTWARE, INC., BE LIABLE, WHETHER IN CONTRACT, TORT, OR OTHERWISE, FOR ANY SPECIAL, CONSEQUENTIAL, INDIRECT, PUNITIVE, OR EXEMPLARY DAMAGES IN CONNECTION WITH THE USE OF THE DOCUMENTATION. The Documentation is subject to change at any time without notice.
ROGUE WAVE SOFTWARE, INC. Address: 5500 Flatiron Parkway, Boulder, CO 80301 USA Product Information: Fax: Web:
(303) 473-9118 (800) 487-3217 (303) 473-9137 http://www.roguewave.com
CONTENTS 1Chapter 1 Introduction to Stingray Studio 1.1 Welcome to Stingray® Studio 1 1.2 Supported Platforms 2 1.3 Prerequisites to Using Stingray Studio 2 1.4 Product Documentation 2 1.4.1 Types of Documents 3 1.4.2 Document List 3 1.4.3 Integrating the Documentation as Help 4 1.4.4 Knowledge Base 5 1.4.5 Type Conventions 5
1.5 Professional Services 6 1.6 Technical Support 6 1.7 Licensing Restrictions 6 1.7.1 Library Dependencies for Distribution 7
1.8 Stingray Studio 3rd-Party Software Use 7
2Chapter 2
Building the Libraries 2.1 Building the Individual Libraries Before Using Stingray Studio 9 2.2 Build Wizard 10 2.2.1 How Does It Work? 10 2.2.2 To Run the Build Wizard 11
2.3 Building from the Command Line with nmake 16 2.3.1 Using nmake Directly 16 2.3.2 Compiling with 1-Byte Structure Alignment 17 2.3.3 Cleaning Generated Object Files 18
2.4 Default Windows Defines 18 Contents iii
2.5 Manifest Files 19 2.6 Extending Stingray Libraries 19 2.6.1 How Stingray Imports and Exports Symbols 19 2.6.2 Using CustExtDefs.h in Stingray Extensions 22 2.6.3 Extending Stingray Classes Locally in an Executable 23
2.7 Solving Library Build Problems 25 2.7.1 Visual Studio Compilers 25 2.7.2 Run the Build Wizard 25 2.7.3 Check Visual Studio Paths 25 2.7.4 Microsoft Visual Studio 2010 Changes 27 2.7.4.1 Property Sheets 27 2.7.4.2 Adding a Property Sheet 27 2.7.4.3 Editing an Existing Property Sheet 28
2.7.5 Select the Proper Build Configuration 28
3Chapter 3 Directory Organization 3.1 Stingray Studio Directory Structure 31 3.2 Subsystems and Packages 31 3.3 Top-Level Directories 33 3.4 Include Files 33 3.5 Source Files 34 3.6 Samples 34 3.6.1 Location of Sample Code 35
3.7 Utilities 35 3.8 Documentation 35
4Chapter 4 Migrating Applications to Stingray Studio 4.1 A New Environment 37 4.2 SFL Namespaces 38 4.3 SFL Compatibility With Earlier Component Releases 39 4.4 A New Directory Structure 40
5Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke iv Contents
5.1 Overview 43 5.2 Migrating From MFC to .NET 44 5.3 Objective Views Sample 45 5.3.1 Additional Notes 46
5.4 Objective Grid Sample 47 5.4.1 Building the Objective Grid Sample 47 5.4.2 Testing the Objective Grid Sample 47
5.5
Next Steps 51
5.6 Using Compiler Option /clr 51
AAppendix A 3rd-Party Licenses A.1 Stingray Studio 3rd-Party Software Use 53 A.2 Autohide Source Code License 54 A.3 Base64 and Quoted-Printable Encoding/Decoding Source Code License 55 A.4 Extended Tree Control Sample Source Code 56 A.5 Regex v2.24 Library Source Code 56 A.6 TIFF Library Source Code 58 A.7 zlib Library v 0.95/1.23 Source Code 60
Index
63
Contents v
vi Contents
Chapter 1
Introduction to Stingray Studio 1.1
Welcome to Stingray® Studio Rogue Wave® Stingray® Studio integrated GUI components are designed to handle the low-level details of GUI application development, shortening development time and making it easier to maintain and evolve GUI applications over time. Stingray® components are available in three packages: Stingray® Studio, Objective Grid, and Objective Toolkit. The Stingray Studio package contains the following components:
Stingray Foundation Library (SFL)
Stingray FoundationEx Library (SFLEx)
Objective Chart
Objective Edit
Objective Grid
Objective GridEx (OGEx)
Objective Toolkit
Objective Views
The extended libraries listed above, SFLEx and OGEx, extend functionality available from MSVS 2008 (VC++ 9.0) SP1 and higher feature packs. The Objective Grid package can be purchased separately and includes:
Stingray Foundation Library (SFL)
Objective Grid
The Objective Toolkit can also be purchased separately and includes:
Stingray Foundation Library (SFL)
Objective Toolkit
Chapter 1 Introduction to Stingray Studio 1
1.2
Supported Platforms For a list of supported operating systems and compilers, see http://www.roguewave.com/products/stingray.aspx, then click on the link “Supported Platforms” to download a PDF.
1.3
Prerequisites to Using Stingray Studio To use Stingray Studio effectively, you need prior knowledge of C++ and the Microsoft Foundation Class Libraries (MFC). Familiarity with the Windows Graphical Device Interface (GDI) is helpful, but is not a necessity. Here are some texts that could prove useful:
1.4
Nishant Sivakumar, C++/CLI in Action (Manning, 2007)
Stephen Prata, C++ Primer Plus, Fifth Edition (Sams, 2004)
D.J. Kruglinski, S. Wingo, and G. Shepherd, Programming Microsoft Visual C++, 5th ed. (Microsoft Press, 1998).
Brent E. Rector, Joseph M. Newcomer, Win 32 Programming (Addition Wesley, 1997)
Jeff Prosise, Programming Windows with MFC Second Edition (Microsoft Press, 1999).
Charles Petzold, Programming Windows 95 (Microsoft Press, 1996).
Scot Wingo and George Shepherd, MFC Internals (Addison-Wesley Pub Co, 1996).
Product Documentation Rogue Wave provides a comprehensive set of documents in a variety of formats in the Docs subdirectory of your installation directory. You can access it by selecting Documentation from the Stingray Studio submenu in your Windows Start |Programs menu. The organization of the Docs directory is: Docs +-Copyright and 3rdParty Licenses +-Help Integration -- MSHelp 2.0 and 3.0 files used in MSDN integration +-Other Guides -- PDF-format guides on specific topics *.chm/chi and *.pdf files -- Standalone documentation for each product
For immediate access to product documentation, open the appropriate CHM or PDF file in the toplevel directory. Generally, you should not need to look in the Help Integration directory. This documentation should be integrated into MSDN during installation. If not, see Section 1.4.3.
2
To read a .pdf file, you must open it with Adobe Acrobat Reader, which you can download free of charge from the Adobe System Web site: http://www.adobe.com . All documents are located in the Docs subdirectory of your installation.
1.4.1 Types of Documents These are the types of documents provided with Stingray Studio:
Getting Started Guide Provides an overview of Stingray Studio including instructions for installing, building libraries, migrating applications, and porting to Microsoft® .NET®.
User Guides These documents are how-to manuals and provide an introduction to each component of Stingray Studio. There are several tutorials included to help you learn how to create applications quickly.
Programmer Guides These documents are more advanced and include a discussion of the design and architecture of each component. There are several advanced tutorials to help you gain more proficiency with the product.
Class Reference Guides These documents provide a detailed description of the properties, methods, and events in each component. There is an HTML document for each public class and its methods. These reference guides may be used as standalone (.chm only) or viewed through Microsoft's Help Collection in the compiler IDE or MSDN.
Readme Files These documents offer the latest information about each component and are located in your Stingray Studio installation directory. The readme files are located at \Readme\MFCReadme.htm. From this document you can access the readme files (listed as change logs) for all the Stingray Studio packages.
Release Notes Release notes list the known issues at the time of release for Stingray Studio products. Release notes are provided as a PDF document Stingray Release Notes in the installer download and on the Rogue Wave web site at www.roguewave.com/support/product-documentation/stingray.aspx.
1.4.2 Document List Here is the list of user, programming, and reference guides supplied with Stingray Studio:
Stingray Studio Getting Started Guide
Stingray Foundation Library (SFL) User’s Guide
Stingray Foundation Library (SFL) Reference Guide
Chapter 1 Introduction to Stingray Studio 3
Objective Chart User’s and Programmer’s Guide
Objective Chart Reference Guide
Objective Edit User’s Guide
Objective Edit Reference Guide
Objective Grid User’s and Programmer’s Guide
Objective Grid Reference Guide
Objective Toolkit User’s Guide
Objective Toolkit Reference Guide
Objective Grid .NET User’s Guide
Objective Grid .NET Reference Guide
Objective Views User’s Guide
Objective Views Reference Guide
1.4.3 Integrating the Documentation as Help The Stingray Studio installer does its best to integrate the Getting Started User’s Guide and each Stingray product’s User’s Guide and Reference Guide into either the user-specified MSDN Collection or the compiler-specific MS.VSCC+ Help Collection, but not both. During the installation, you have the option to select between an MSDN or an MSHelp collection for each .NET compiler in which to integrate Stingray Studio online documentation. Below are some helpful MSHelp Integration tips.
If MSHelp integration fails after a successful installation of your Stingray products, or if you choose to switch from the MS.VSCC+ namespace to the MSDN namespace or vice verse, you can manually integrate the Stingray products Help Collection (StingrayStudio.HxC) by running the h2reg.exe utility from the command line. This utility and the h2regVC71MSHelp.ini, h2regVC71MSDN.ini, h2regVC8MSHelp.ini, h2regVC8MSDN.ini, h2regVC9MSHelp.ini, and h2regVC9MSDN.ini files are located in the \Docs\Help Integration directory. You must first copy one of the above h2reg*.ini files and rename it to h2reg.ini before using the file with the h2reg.exe utility. Please refer to the comments in the renamed h2reg.ini file under the [Reg_Plugin] and [UnReg_Plugin] sections for simple instructions on how to integrate the Stingray products Help Collection into your MSDN Help Collection*. For more information on how to download and use the h2reg.exe .NET Help utility, please refer to the H2Reg Home Page at http://helpware.net/mshelp2/h2reg.htm. * Be aware that all Help Collections with the MSDN namespace are also plugged into their respective MS.VSCC+ namespace(s).
4
It is recommended that you first unregister the Stingray Studio Help Collection from the MS.VSCC+ namespace(s), and then re-register the Stingray Studio Help Collection into your MSDN Help Collection.
We recommend using one of the following command line options when using the h2reg utility:
-–r Register Mode uses the command sections in the h2reg.ini file related to registering items. When using this option, we also recomment using the -m
option, which performs a pre-merge of Index and Table of Contents (TOC) files.
-–u Unregister Mode uses the command sections in the h2reg.ini file related
to unregistering items.
We have also noticed that some .NET compiler Help Content filters default to “Visual C++”. To view the StingrayStudio.HxC MSHelp Collection in your IDE’s Help Content, you will need to change your IDE’s Help Content filter to “None”.
To access the integrated Stingray Studio documentation, use the standard Microsoft Visual Studio Help Index.
1.4.4 Knowledge Base The Rogue Wave Knowledge Base contains a large body of useful information created by the Support Services team. It has been created to provide our customers with easy access to technical information. Knowledge Base entries range from common programming problems to complete sample programs and are constantly being updated and expanded. This information is available to any user of the Rogue Wave Web site, and no login or registration is required. kb.roguewave.com/kb/.
1.4.5 Type Conventions The documentation for Stingray Studio uses typographic conventions and pathname conventions similar to other Rogue Wave documentation. These conventions are summarized in the following table: Table 1 – Type Conventions Item
Example
Definition
Functions, Variables and Parameters
Myfunc()
Library functions are in courier font.
Class Name
CODModel
Class names are bold and italic.
Code
#include
Code is in courier font.
Key names, key combinations and key sequences
CTRL+ALT+DEL
All Caps
Menus and menu commands
Select Edit from the File menu.
Menus and menu commands are bold.
Chapter 1 Introduction to Stingray Studio 5
1.5
Professional Services The Rogue Wave Professional Services offers training and mentoring for all levels of project development, from analysis and design to implementation. For information on Professional Services for Stingray products, see www.roguewave.com/services/professional-services.aspx. Rogue Wave international offices provide training in many languages.
1.6
Technical Support Software Technical Support is available to customers who have a valid Maintenance and Support contract for any Rogue Wave product. Please contact Technical Support according to the terms of your Rogue Wave License Agreement for your support level: Basic, Premium, or Enterprise. For information on contacting technical support, refer to the Support page of the Rogue Wave Web site (www.roguewave.com/services/support.aspx). The Rogue Wave Web site recently redesigned its Support page, and re-registering is required. Please read our New Web site Transition Note (www.roguewave.com/support/customer-portal.aspx) if your web account was established prior to February 2011.
Before entering a support request, check the online Knowledge Base. In many cases, your technical support question has already been answered in the Knowledge Base. This valuable resource is provided as a convenience for our customers, and provides technical answers to many frequently asked questions.
1.7
Licensing Restrictions Please read the license agreement that was shipped with this package. You are bound by the licensing restrictions contained in that document. Do not use this product unless you can accept all the terms of the license agreement. You can use all the files accompanying this product for development of an application. You can distribute Stingray Studio component’s Dynamic Link Libraries (DLLs) according to the terms of the license agreement. Your applications can also statically link to the components of Stingray Studio, in which case you do not need to redistribute any Stingray Studio files — except any required language configuration files.
6
1.7.1 Library Dependencies for Distribution If you are dynamically linking to Stingray Studio libraries in your applications, you must be sure to distribute any dependent libraries, or DLLs. This section details dependencies specific to the overall product; for more information on individual component dependencies, see the relevant user’s guide. If a component is dependent on either a specific library or another component, it means that there is a build and/or link dependency.
All Stingray components are dependent on the Stingray Foundation (SFL) DLLs. The RWUXTheme libraries will be automatically built when building any of the individual Stingray MFC product library build configurations. Any build configuration with the term, "All", does not build the RWUXTheme libraries. We recommend using the Batch Build option under the Build menu option in the MSVC IDE.
Objective Edit and Objective Toolkit have optional dependencies on the Regex++ (regular expression) DLLs, depending on your selection in the Build Wizard during the component’s initial build. The Regex option is unchecked by default. For more information about each product's Build Wizard's usage and options, please refer to each product's section about the Build Wizard.
You can also distribute the MFC DLLS with your application. Look in the compiler's root directory where you installed Visual Studio (or a previous version of VC++). You should find a document named redist.txt. This document gives details about which MFC files need to be distributed with various configurations. Distribution of MFC product libraries will also include the distribution of the SFL, RWUXTheme, and optional Regex DLLs for DLL build configurations. Distribution of all dependent Stingray Studio DLLs is required and subject to the Rogue Wave® Stingray® License Terms and Conditions.
1.8
Stingray Studio 3rd-Party Software Use Stingray Studio uses open source or freely licensed code as detailed in Appendix A.
Chapter 1 Introduction to Stingray Studio 7
8
Chapter 2
Building the Libraries 2.1
Building the Individual Libraries Before Using Stingray Studio Before using the Stingray Studio MFC products, you need to build the product libraries. Building the product libraries requires that you have successfully completed product installation. You can obtain prebuilt versions of the libraries by request to Rogue Wave technical support. Prebuilt libraries are available for the currently supported operating systems, along with their associated supported compilers. We recommend, however, that you build the libraries yourself. The prebuilt libraries are built with a particular instance of Visual Studio and the Windows operating system. Building the libraries yourself ensures that they are compatible with your version of the compiler and the operating system they are built on. Note that the Microsoft Platform SDK is required to build the Stingray Studio libraries (specifically Objective Grid and Objective Chart) that support XML serialization functionality. The Platform SDK should be enabled through the normal compiler installation, but if you have problems with XML serialization, check that your PATH environment variable correctly points to the Platform SDK.
Chapter 2 Building the Libraries 9
2.2
Build Wizard Included with each of the Stingray Studio MFC products is a Build Configuration Wizard, a powerful tool that allows you to trim down the binary size of the Stingray Studio libraries and DLLs with a very fine level of granularity, and also allows you to rename the resulting library names (important for DLL distribution). This wizard allows you to modify the build configuration for a particular Stingray Studio component and automatically generates the necessary Stingray Studio file updates to be used by your installed and supported Microsoft Visual Studio compiler(s). Some Stingray Studio components allow custom configurations in which the developer can selectively add or remove subsystems from the component. This yields the ability to create custom libraries that contain only a subset of the total subsystem set. You may consider doing this if you are only using a few subsystems out of the entire component, thereby creating much smaller libraries or DLLs. You can also redefine the library’s file name with this wizard. As the last step of the Build Wizard, you must manually start the version of the Microsoft compiler you wish to use. In Microsoft Visual Studio, you can select the appropriate library version for your project. By default, all of the libraries will be built, but you can choose to build only the libraries that your project requires. Once the library has been built, it is placed in the Stingray Studio Lib directory. The intermediate objects in the Obj directory can be deleted, as they are no longer needed. At this point you are ready to start using the Stingray Studio component in your own projects.
2.2.1 How Does It Work? The Build Configuration Wizard, also called Build Wizard, is a simple wizard dialog that allows you to specify exactly the features to be used in your application, thus minimizing the size of the distributed DLL. After answering a few simple questions, the Build Wizard generates a custom-tailored makefile to build the Stingray Studio product library in the exact configuration you specified. This includes support for customizing the names of the libraries to avoid any potential name collisions or versioning problems. The BuildWizard loads its configuration information from a BuildWiz.ini in the product directory under the utils directory. Alteration of the file BuildWiz.ini will allow you to further customize the build process, including adding your own source files. However, please understand that customizing the build in this way is not supported by Rogue Wave. Technical support issues arising from alteration of the build files are not supported by Rogue Wave.
In addition, the Build Wizard can be used to generate multiple library configurations, such as one configuration with just the tree control and another that builds just the docking windows code. The Wizard dialogs describes this procedure to you. Be sure to customize the target library names of different build configurations to different target names; otherwise collision may occur.
10
2.2.2 To Run the Build Wizard To launch the Build Wizard and build the libraries for each of the Stingray products, use the Build Wizard corresponding to that product. See Figure 1 and Table 2. Figure 1 – Build Wizard Executables
Table 2 – Build Wizard Files Product
Build Wizard
Objective Grid
Stingray Studio\Utils\gridbuildwiz.exe
Objective Toolkit
Stingray Studio\Utils\toolkitbuildwiz.exe
Objective Chart
Stingray Studio\Utils\chartbuildwiz.exe; ChartUTBuildWiz.exe
Objective Views
Stingray Studio\Utils\ViewsBuildWiz.exe
Objective Edit
Stingray Studio\Utils\EditBuildWiz.exe
1. When you run the Stingray Build Configuration Wizard, the first panel displayed is the Build Wizard Welcome panel.
Chapter 2 Building the Libraries 11
Figure 2 – Launching the Build Wizard
2. Click Next to proceed to the Build Wizard Configuration panel. 3. Enter a name for the build configuration or select a previously-saved configuration from the list. You can also leave the default name (Default). Figure 3 – Selecting a Build Configuration
4. Click Next.
12
If you want to create multiple configurations, you can run the Build Wizard multiple times, specifying a different configuration name each time. Several different configurations may coexist on your hard disk. For example, you may have one configuration that contains all the library components, and another configuration that contains only a few components. This is often helpful to decrease the size of an exported DLL. Not all products have configurable options; however, the Build Wizard is included in those products to allow the generated library names to be changed. Changing the library name is highly recommended when distributing Stingray Studio DLLs.
The binary configuration information is stored in UTILS\product\configname.BWC. You can load and modify the configuration any time and rebuild the libraries with different features. 5. The next panel of the Build Wizard allows the specific components to be selected for a given configuration. Figure 4 – Build Wizard Component Selection Panel
6. Click individual components to toggle ON or OFF component selections. Toggle entire branches of components by double-clicking the parent node. Click Next after all desired components have been selected. 7. The next panel displays information about Run Time Type Information (RTTI) and default library file names:
Chapter 2 Building the Libraries 13
Figure 5 – Run-Time Type Information
Some components require that RTTI be enabled. If any of those components are selected in the previous panel, the RTTI checkbox will be checked and disabled. The radio buttons on this panel specify whether the default library names are to be used, or whether the names are to be customized. 8. If the default names are used, click Finish. To customize the names, select No, I want to customize the library names and then click Next (when No is selected, the Finish button changes to Next). 9. If the library names are to be customized, the following panel is displayed: Figure 6 – Target Names
14
10. In the edit control in the lower left portion of the panel, the base name for all of the libraries can be entered. The individual names can also be modified. 11. After modifying the names, click Finish to complete the Build Wizard, and show the Build Wizard Results dialog: Figure 7 – Build result
12. Click Close to terminate the Build Wizard.
Chapter 2 Building the Libraries 15
2.3
Building from the Command Line with nmake When you build from Microsoft Visual Studio, Visual Studio invokes nmake against the product's .mak file as an external makefile, with a command line argument that reflects the library you want to build. In the \Src directory, there are makefiles for each product by supported compiler version. For example, the file toolkit10.mak is for building Toolkit with the MSVC 10.0 compiler. In the corresponding solution file, Toolkit10.sln for the above example, you can look in the project settings to find the command line invocation used. Each product's .mak file invokes a back-end make file named bldback##.mak, which performs the actual build. The bldback##.mak files are located per product in the \Src\\BkEndMak subdirectory. Both the .mak files and bldback##.mak files are affected by the Build Wizard. Some issues have been discovered in building with nmake on Vista and Windows 7. Please refer to the release notes for up-to-date information on these issues.
2.3.1 Using nmake Directly Here is the syntax for using the nmake command: To build a particular library denoted by , where = , or the values ansi, unicode, or all. See below for values of and . Build is 32-bit unless the optional macro is included, in which case it is 64-bit. nmake /f ##.mak [BUILD64BIT=1]
To build all library variants described below. Builds are 32-bit unless the optional macro is included, in which case it is 64-bit. nmake /f ##.mak [BUILD64BIT=1]
To remove all intermediary files created by the build. nmake /f ##.mak [CLEAN] [BUILD64BIT=1]
The variable corresponds to the product name as found in each product’s make file name, e.g., toolkit. Make files are located in \Src. The ## variable refers to one of the supported compiler versions as used in the make file names, which are 80, 90 or 10, corresponding to the MSVC 8.0, 9.0, and 10.0 compilers respectively. Table 3 – Product Abbreviations used in nmake targets
16
Product Name
oc
Chart
oe
Edit
og
Grid
Table 3 – Product Abbreviations used in nmake targets
Product Name
ot
Toolkit
ov
Views
sfl
Stingray Foundation Library
Table 4 shows the different possible target specifications, and describes the resulting build. Table 4 – Build target specifications Target specification
Resulting build
MFC Lib, Stingray Lib, Release
d
MFC Lib, Stingray Lib, Debug
a
MFC DLL, Stingray Lib, Release
ad
MFC DLL, Stingray Lib, Debug
as
MFC DLL, Stingray DLL, Release
asd
MFC DLL, Stingray DLL, Debug
u
MFC Lib, Stingray Lib, Unicode, Release
ud
MFC Lib, Stingray Lib, Unicode, Debug
au
MFC DLL, Stingray Lib, Unicode, Release
aud
MFC DLL, Stingray Lib, Unicode, Debug
asu
MFC DLL, Stingray DLL, Unicode, Release
asud
MFC DLL, Stingray DLL, Unicode, Debug
asm
MFC DLL, Stingray DLL, Release
asdm
MFC DLL, Stingray DLL, Debug
asum
MFC DLL, Stingray DLL, Unicode, Release
asudm
MFC DLL, Stingray DLL, Unicode, Debug
ansi
All ANSI (non-Unicode) build variants
unicode
All Unicode build variants
all
All ANSI and Unicode build variants
2.3.2 Compiling with 1-Byte Structure Alignment The Stingray Studio product libraries are compiled using the default 8-byte structure alignment flag by default. If your application requires another alignment, such as 1-byte, you need to recompile the Stingray Studio product libraries to match it.
Chapter 2 Building the Libraries 17
For a given library, you need to open the back-end make file, described above. So, for example, \Src\Toolkit\BkEndMak\bldback10 if you want to build Toolkit with the MSVC 10.0 compiler. In this file, you will find an entry something like this: ... These flags are common to all configurations: COMMON_CPP=/nologo /D "WIN32" /D "_WINDOWS" $(OTPRO_FLAGS) /GX /W4 /c /Fp"$(INTDIR)/$(BUILDTARG).pch" /Fo"$(INTDIR)/" /GR /Zm200 /I "..\include" /I "..\src" /I "..\..\src"
To build with 1-byte structure alignment, add the flag /Zp1 to this set of flags: ... These flags are common to all configurations: COMMON_CPP=/nologo /D "WIN32" /D "_WINDOWS" $(OTPRO_FLAGS) /GX /W4 /c /Fp"$(INTDIR)/$(BUILDTARG).pch" /Fo"$(INTDIR)/" /GR /Zm200 /Zp1 /I "..\include" /I "..\src" /I "..\..\src"
2.3.3 Cleaning Generated Object Files The intermediary object files that are produced from the Stingray Studio product libraries can appropriate significant disk space on your computer. After building the libraries, we recommend deleting these object files to reclaim the space on your hard drive. The pattern for the location of generated object files is: \Src\objs\\ \
For example, the build objects for Toolkit built with the MSVC 10.0 compiler would be something like: C:\RogueWave\Stingray Studio\10.0\Src\objs\vc10\x86\ot1104asd\*.obj
2.4
Default Windows Defines Information regarding Stingray's supported platforms, operating systems, compilers, and processor architectures is in the header file SupportedPlatforms.h, located in the \Include directory. Use SupportedPlatforms.h to define WINVER, _WIN32_WINNT, and _WIN32_IE with a single NTDDI_VERSION macro definition change. SupportedPlatforms.h should be included at the top of the stdafx.h file for both applications
and samples, and should be included before any other Windows header files.
18
2.5
Manifest Files Manifest files are used to determine the correct MFC and CRT dynamic link libraries to load. Each compiler has a distinct version of these libraries. The file ManifestDefs.h is used to dynamically generate appropriate manifest information used in the compilation of the libraries and samples. This file is located in the \Include directory. ManifestDefs.h should be included at the end of the stdafx.h file for both applications and
samples.
2.6
Extending Stingray Libraries Stingray classes extend Microsoft Foundation Class (MFC) classes. You, in turn, can create classes that build on and extend the Stingray classes. To create these extensions, you need to understand the mechanism for importing and exporting symbols. This section first describes how Stingray itself does this, and then describes what you must do when creating Stingray extensions.
2.6.1 How Stingray Imports and Exports Symbols In an extension library, symbols (functions and variables) must be exported so they have visibility to an application that is linking to the library. When an application links to an extended library, it imports the functions for use. Previously in Stingray Studio products there was no need to mark functions and variables for exportation, but this is now a requirement. Definition files (.def) are no longer used by the Stingray libraries to export functions and variables. Instead the C++ __declspec keyword is used to export and import functions and variables.
__declspec(dllexport) is used by the library to export.
__declspec(dllimport) is used by the application to import.
The Stingray libraries use a header file that defines common macros for exporting and importing functions and variables. Each product contains a header file called ExportDefs.h that is located in the \Include\ directory. During installation, a master header file called StingrayExportDefs.h is updated to #include each purchased and selected product's *ExportDefs.h header file to the master header file. The master header file is located in the \Include directory.
Chapter 2 Building the Libraries 19
The Stingray product implementation files define one of the following preprocessor symbols to indicate in our code that we are going to export symbols: #define #define #define #define #define #define
_SFL_EXPORT_IMPL _OC_EXPORT_IMPL _OE_EXPORT_IMPL _OG_EXPORT_IMPL _OT_EXPORT_IMPL _OV_EXPORT_IMPL
#define #define #define #define #define #define
_SFLEX_EXPORT_IMPL _OCEX_EXPORT_IMPL _OEEX_EXPORT_IMPL _OGEX_EXPORT_IMPL _OTEX_EXPORT_IMPL _OVEX_EXPORT_IMPL
Versions of Stingray Studio older than Stingray Studio 2006 v3 have the following implementation preprocessor commands defined for backward compatibility: #define #define #define #define #define #define
_SFLDLL_IMPL _OC_DLL_IMPL _OE_DLL_IMPL _GXDLL_IMPL _SECDLL_IMPL _OV_DLL_IMPL
_SFL_EXPORT_IMPL _OC_EXPORT_IMPL _OE_EXPORT_IMPL _OG_EXPORT_IMPL _OT_EXPORT_IMPL _OV_EXPORT_IMPL
The Stingray libraries use preprocessor definitions to indicate a function’s or variable’s export/import status. StingrayExportDefs.h defines whether a function or variable is exported or imported by defining one of the following: FOUNDATION_API CHART_API CHART_UT_API EDIT_API GRID_API TOOLKIT_API VIEWS_API FOUNDATIONEX_API CHARTEX_API EDITEX_API GRIDEX_API TOOLKITEX_API VIEWSEX_API The above _API macros should not be used in an extension library as they will cause symbol conflicts with exporting and importing. See the section below on using CustExtDefs.h to create extension libraries.
20
For example, the Foundation preprocessor is defined as: #ifdef _SFLDLL // Dynamic Link Library #ifdef _SFLDLL_IMPL #define FOUNDATION_API __declspec( dllexport ) #define FOUNDATION_GLOBAL_FUNC_API(rettype) extern "C" rettype __declspec(dllexport) #else #define FOUNDATION_API __declspec( dllimport ) // Reference to a GLOBAL Function #define FOUNDATION_GLOBAL_FUNC_API(rettype) extern "C" rettype __declspec(dllimport) #endif #else // !_SFLDLL // Static Link Library #define FOUNDATION_API // Reference to a GLOBAL Function: these must be inline // definitions with no function prototype. #define FOUNDATION_GLOBAL_FUNC_API(rettype) extern "C" rettype __cdecl // Don't mangle the name. // Must use __cdecl here. #endif
A Stingray class might look like the following: // StingrayClass.h #pragma once #include “StingrayExportDefs.h” class CFoundationFoo { public: FOUNDATION_API CFoundationFoo(); FOUNDATION_API virtual ~CFoundationFoo(); FOUNDATION_API virtual void Add(int iVal); // FOUNDATION_DECLARE_MESSAGE_MAP() etc. Private: // Note private variables don’t need to be exported. int m_Sum; }; FOUNDATION_GLOBAL_FUNC_API(void) DoSomethingGlobal(); // StingrayClass.cpp #include “StingrayClass.h” #define _SFL_EXPORT_IMPL CFoundationFoo::CFoundationFoo() { m_Sum = 0; } CFoundationFoo::~CFoundationFoo() { }
Chapter 2 Building the Libraries 21
Void CFoundationFoo::Add(int iVal) { m_Sum += iVal; } FOUNDATION_GLOBAL_FUNC_API(void) DoSomethingGlobal() { // Do something. }
When the above class is compiled, it will export the functions in the class because __declspec(dllexport) will be defined internal to the Stingray library that the class extends. When a sample or application uses the CFoundationFoo class, it only needs to include its header file. Because _SFL_EXPORT_IMPL is not defined in the sample or application, the functions and variables will be imported for use because __declspec(dllimport) will be defined.
2.6.2 Using CustExtDefs.h in Stingray Extensions Stingray extension libraries can be created as static libraries (lib) or dynamic link libraries (dll). Extension libraries are then linked to an application. An extension library needs to expose its functionality to the application by exporting its functions and variables so the application can import them for use. Like the Stingray libraries themselves, there needs to be some code mechanism to switch between exporting and importing. The *_API macros that are defined for the Stingray libraries should not be used in a Stingray Extension library as they are meant for internal use by the Stingray libraries only. To make it easier to create Stingray extension libraries, Stingray Studio provides the file CustExtDefs.h in the \Include directory. Including CustExtDefs.h and using its predefined *_API preprocessors will remove the need to create a mechanism in code for switching between importing and exporting. CustExtDefs.h provides some overrides of the basic MFC macros. For example, the override for DECLARE_MESSAGE_MAP() is CUSTEXT_DECLARE_MESSAGEMAP(). If there are macros that are needed but not provided by the header file, they need to be overridden in the extension library.
If the extension library is to be configured as a dynamic link library (dll), then the preprocessor settings in the library should include _CUSTEXTDLL so the appropriate export/import syntax is used. Static (lib) build configurations should not include this preprocessor symbol. An extended Stingray class might look like the following: // ExtendedClass.h #pragma once #include “CustExtDefs.h” #include “StingrayClass.h” #define MY_CUSTOMEXTENSION_MFC_OVERRIDE() \ CUSTEXT_GLOBAL_VAR_API static int x; \
22
CUSTEXT_CLASS_FUNC_API void MyMFCFunc() \ { \ x = 4; } \ class CSuperFoo: public CFoundationFoo { public: CUSTEXT_CLASS_FUNC_API inline CSuperFoo(){} CUSTEXT_CLASS_FUNC_API inline virtual CSuperFoo(){} CUSTEXT_CLASS_FUNC_API void DoSomethingSuper(); // CUSTEXT_DECLARE_MESSAGE_MAP(), etc. // CUSTEXT_DECLARE_DYNAMIC(CSuperFoo), etc. // MY_CUSTEXTENSION_MFC_OVERRIDE(), etc. }; // ExtendedClass.cpp #define _CUSTEXT_EXPORT_IMPL #include “ExtendedClass.h” // Extension/Wrapper of the CFoundationFoo class. CSuperFoo::DoSomethingSuper() { // Call Foo from the base Stingray class. ::Foo(5); }
2.6.3 Extending Stingray Classes Locally in an Executable Classes in a Stingray library can be extended in an executable locally, meaning that there is no further need to expose functionality outside of the executable. Classes that are extended locally in an executable do not need to use CustExtDefs.h or StingrayExportDefs.h. The macros listed below are exceptions to the above rule. They need to use the overrides in StingrayExportDefs.h even in a locally extended executable.
GRID_DECLARE_CONTROL()
GRID_IMPLEMENT_CONTROL()
GRID_DECLARE_REGISTER()
GRID_IMPLEMENT_REGISTER()
TOOLKIT_DECLARE_BUTTON()
TOOLKIT_IMPLEMENT_BUTTON()
An extension class can be derived from a Stingray class without having to export/import symbols. In this case standard MFC macros can be used, such as DECLARE_MESSAGE_MAP(), without any export/import customization. Here is an example:
Chapter 2 Building the Libraries 23
// MyExtensionClass.h #pragma once // Includes ... class MyExtendedFoo : public CFoundationFoo { public: // DECLARE_DYNAMIC(MyExtendedFoo) etc. ... // Constructor MyExtendedFoo() {} }; // MyExtensionApp.cpp int main() { // Using the extension class MyExtendedFoo mf; mf.Add(10); return 0; }
24
2.7
Solving Library Build Problems If you are having problems building the Stingray Studio libraries, try these solutions to common problems.
2.7.1 Visual Studio Compilers Make sure you are using a supported release of Visual Studio. For details, see http://www.roguewave.com/products/stingray.aspx, then click on Supported Platforms. Stingray Studio libraries will not compile if the MFC source code is not installed.
2.7.2 Run the Build Wizard The Build Wizard executable is in the utils directory. It can also be executed from the Program Group for the product. This executable generates the makefile for building the Stingray Studio libraries. For more information, refer to Section 2.2, “Build Wizard.”
2.7.3 Check Visual Studio Paths Click on Tools | Options… and select the Directories tab, and make sure that all of the directory settings are correct for your setup. It is not only important to make sure the include and lib paths are correct, but the executable path must also point to the Visual Studio bin directory in order to execute nmake.exe. Also, make sure that the include and lib paths include only the directories of the current installation of Stingray Studio. Your directory settings may differ (depending on how your products were installed), but some sample directory settings are provided below. Sample Executable path directory settings: General directory structure: \Bin C:\Windows\System32\msagent C:\Windows\System32\msagent64
// 32-bit OS // 64-bit OS
for VC++ 8.0 and 9.0: $(VCInstallDir)bin; $(WindowsSdkDir)\bin; $(VSInstallDir)Common7\Tools\bin; $(VSInstallDir)Common7\tools; $(VSInstallDir)Common7\ide; $(VSInstallDir); $(VSInstallDir)\SDK\v2.0\bin; $(FrameworkSDKDir)bin; $(FrameworkDir)$(FrameworkVersion);
//1
//2 //3
Chapter 2 Building the Libraries 25
C:\Program Files\Microsoft Platform SDK\Bin; C:\Program Files\Microsoft Platform SDK\Lib; C:\WINDOWS\system32; C:\WINDOWS; C:\WINDOWS\System32\Wbem; //1
VC++ 9.0 on Vista/Windows 2008 Server only
//2
VC++ 8.0 only
//3
VC++ 8.0 and 9.0 only
Sample Include path directory settings: General directory structure: \Include \Regex\Include \RWUXTheme\Include
// optional
for VC++ 8.0 and 9.0: $(VCInstallDir)include $(VCInstallDir)atlmfc\include $(WindowsSdkDir)include $(VCInstallDir)PlatformSDK\include $(VCInstallDir)PlatformSDK\common\include $(FrameworkSDKDir)include C:\Program Files\MSXML 6.0\inc C:\Program Files\Microsoft SDKs\Windows\v6.1\Include C:\Program Files\Microsoft Platform SDK\Include //1
VC++ 9.0 on Vista/Windows 2008 Server only
//2
VC++ 8.0 only
//3
VC++ 8.0 only
//4
VC++ 8.0 and 9.0 only
//1 //2 //3 //4 //4 //4
Sample Lib path directory settings: General directory structure: \Lib\\ for VC++ 8.0 and 9.0: $(VCInstallDir)lib $(VCInstallDir)atlmfc\lib $(VCInstallDir)atlmfc\lib\amd64 $(VCInstallDir)lib\amd64 $(VCInstallDir)PlatformSDK\lib $(VCInstallDir)PlatformSDK\common\lib $(FrameworkSDKDir)lib C:\Program Files\MSXML 6.0\lib C:\Program Files\Microsoft SDKs\Windows\v6.1\Lib C:\Program Files\Microsoft Platform SDK\Lib
26
// 32-bit compilers //1 (64-bit compilers) //1 (64-bit compilers) //1 //1 //1 //2
//1
VC++ 8.0 and 9.0 only
//2
Common to VC++ 8.0 and 9.0
Sample Source directory settings: General directory structure: \Src \Regex\Src \RWUXTheme\Src
// optional
for VC++ 8.0 and 9.0: $(VCInstallDir)atlmfc\src\mfc $(VCInstallDir)atlmfc\src\atl $(VCInstallDir)crt\src C:\Program Files\Microsoft Platform SDK\src
Notes: 1. $(VS_macro_name) are literals, are typed as shown, and are defined by the Microsoft IDE. Refer to Microsoft MSDN documentation for details of these IDE macro names. 2. The Regex paths are required only if the Regex checkbox in either the Objective Toolkit or Objective Edit build wizard is checked. 3. represents "vc8" or "vc9" and represents "x86" or "x64".
2.7.4 Microsoft Visual Studio 2010 Changes Beginning with Microsoft Visual Studio 2010, there is no longer support for global IDE directory paths, meaning that Tools| Options | VC++ Directories no longer exists. These settings have been moved to the project level as *.vcxproj file properties. To access these settings, go to Project | Properties | Configuration Properties | VC++ Directories. Please review the Migrating to Microsoft Visual Studio 2010.pdf document in the \Docs directory for further details.
2.7.4.1 Property Sheets To simplify setting up paths, two property sheets, \Src\SS-Win32PropSheet and \Src\SS-X64-PropSheet, are now installed with Stingray Studio for use with Win32 and x64 Visual Studio 2010 projects.
2.7.4.2 Adding a Property Sheet Property sheets are provided for all Stingray libraries and shipped samples for Visual Studio 2010, but if you are adding a new project or porting an old project to Visual Studio 2010, you need to add a relevant property sheet. To add our property sheet(s) to a project:
Select the Property Manager tab or go to to View | Property Manager. Chapter 2 Building the Libraries 27
Right click on the project and select Add New Project Property Sheet... or Add Existing Property Sheet.
Navigate to \Src directory to select the desired Stingray Studio specific property sheet file.
The VC++ 10.0 library and associated VC++ 10.0 sample solutions use the following Stingray Studio specific property sheets: \Src\SS-Win32-PropSheet.props \Src\SS-X64-PropSheet.props
You may use the Stingray Studio specific property sheets in your new or newly ported applications that link to Stingray Studio libraries. If you need to modify these files, we strongly recommend copying and renaming them before using them in your application in order to prevent Stingray VC++ 10.0 library and sample build errors.
2.7.4.3 Editing an Existing Property Sheet View property sheets by going to the Property Manager tab. To edit an existing property sheet, open an appropriate configuration such as Debug, expand the project and the configuration, right click on the property sheet and select Properties. On the Property Pages dialog you can change project settings as needed. Keep in mind that changes made to a property sheet affect all configurations that contain the same property sheet.The property sheets for setting paths have been added to all shipped samples through their *.vcxproj project files. Here is an example of the entries pointing to these files:
Note that if you wish to move a sample to another location or edit the sample's property sheet, the relative paths above may not be correct for the new location or new property sheet. Each build configuration's property sheet should be removed from the project using the Property Manager, and then re-added with the new location or new property sheet. This way, Visual Studio can adjust the path and filename to use the new file. Alternatively, the sample's *.vcxproj file may be edited manually. Property sheets are added to each build configuration in any MSVS 2010 (or later) Stingray project. It may be necessary to remove property sheet references for configurations that do not require them or to add new build configurations to a property sheet. After a property sheet is created or modified, the new settings are applied to all configurations that contain that property sheet.
2.7.5 Select the Proper Build Configuration After loading the Stingray Studio project, be sure the desired library configuration is selected by clicking Build | Set Active Configuration.
28
You can also optionally add a selection control to one of your toolbars. Click Tools | Customize... on the Commands tab, choose the Build category. You should now see buttons that pertain to the build process. You should also see a selection control on the right side that you can drag to a toolbar. This control will display the current build configuration, and will allow you to change it quickly.
Chapter 2 Building the Libraries 29
30
Chapter 3
Directory Organization 3.1
Stingray Studio Directory Structure The Stingray Studio directory organization promotes cleaner integration across all Stingray Studio products by putting all Stingray Studio products into a common directory. In versions prior to Stingray Studio, each product had its own top-level directory. One drawback to each product having its own directory structure was that files and utilities were duplicated for each product. It also made environment setup more difficult, because multiple directories had to be added to the Visual C++ INCLUDE, LIB, and SRC paths.
3.2
Subsystems and Packages Within the directory structure, the source code is organized into subsystems and packages. A package is a collection of headers and source files that provide related functionality. A subsystem is a collection of one or more packages. For example, the Foundation subsystem contains packages such as Layout, MVC, Events, Properties, Image, and Print. This organization helps to modularize class libraries and maps very neatly onto UML. Each Stingray Studio product consists of one or more subsystem. For the most part, subsystems correspond to individual products. However, a product may consist of more than one subsystem, so it is not strictly a one-to-one relationship. This organization provides more flexibility in the way that products are packaged, without adding complexity to the configuration of the source code. Table 5 lists the Stingray Studio subsystems. Table 5 – Stingray Studio subsystems Subsystem Name
Description
Chart
Objective Chart classes
Edit
Objective Edit classes
Foundation
Stingray Foundation Library
Chapter 3 Directory Organization 31
Table 5 – Stingray Studio subsystems (Continued) Subsystem Name
Description
Grid
Objective Grid classes
Toolkit
Objective Toolkit classes
Views
Objective Views classes
RWUXTheme
UXTheme global drawing functions
ChartEx
MFC 9 and higher feature pack Chart extension classes
EditEx
MFC 9 and higher feature pack Edit extension classes
FoundationEx
MFC 9 and higher feature pack Foundation extension classes
GridEx
MFC 9 and higher feature pack Grid extension classes
ToolkitEx
MFC 9 and higher feature pack Toolkit extension classes
ViewsEx
MFC 9 and higher feature pack Views extension classes
The Foundation subsystem is installed with all Stingray Studio products. The ChartEx, EditEx, ToolkitEx and ViewsEx subsystems listed above ship as DLL/Lib husk projects.
32
3.3
Top-Level Directories Table 6 shows the directories in the top-level Stingray Studio installation directory. By default, all Stingray Studio subsystems are installed into the same directory. It is also possible to spread subsystems across multiple top-level directories, which might be necessary if disk space is limited. Table 6 – Directories in the top-level Stingray Studio installation directory
3.4
Directory Name
Description
Bin
Binaries for utilities and COM servers
COMServers
Source code for COM objects
Docs
User’s guides, class references, and other documentation
Include
.h files
Samples
Sample projects
Src
.cpp files and solution files to build the libraries
Utils
Utility programs and build wizard files
Include Files The following diagram shows a sample of the INCLUDE directory organization. (Not all directories are represented here.) Include +---+ | + | + | | | | | | | | | + | +
Chart Edit Foundation +--+--+--+--+--+--+--+--+---
Apps Controls DragDrop Events Graphics Image Layout MVC Patterns
Grid Toolkit
The first level of directories under the INCLUDE directory represents subsystems. Below each subsystem are package directories. By referencing include files using relative paths, only the top-level include directory must be included in the Visual Studio INCLUDE path. This is more convenient than having a separate include entry for each Stingray Studio product.
Chapter 3 Directory Organization 33
3.5
Source Files The following diagram shows a sample of the SRC directory organization. Src +-------+ | + | + | | | | | + | +
Chart Edit Foundation +--+--+--+--+---
Controls Events Graphics Image Layout
Grid Toolkit
The organization of the SRC directory mirrors the INCLUDE directory. The first level of directories under the SRC directory represents subsystems. Below each subsystem are package directories. Only the top-level SRC directory must be included in the Visual Studio SRC path.
3.6
Samples The following diagram shows a portion of the Samples directory organization.
Note that samples that are specific to a given subsystem are below the appropriate subsystem directory.
34
3.6.1 Location of Sample Code Stingray Studio ships the most basic and commonly used samples with the product itself. The less commonly used and more specialized samples have been removed from the product distribution, but are available from the Rogue Wave Web site or by request from Technical Support. If you are looking for a sample and it does not appear under \Samples\\, you can download the sample bundle from the Knowledge Base on the Rogue Wave web site at http://kb.roguewave.com/kb/index.php?View=entry&EntryID=1398.
The self-extracting archive, Stingray Studio Additional Samples.exe, contains a text file listing all samples in the archive. The archive includes older samples that are easy to update to work with the latest release of Stingray, but that do not ship with the release. To update samples for later Stingray Studio releases:
In the sample's stdafx.h file, add the following #include above all other include statements: #include "SupportedPlatforms.h"
Update macro names if necessary. Some samples use old macro names which must be replaced with the current name. For example, you would replace DECLARE_CONTROL with GRID_DECLARE_CONTROL. For details, please see Section 2.6, “Extending Stingray Libraries.”
For Visual Studio 2010, add property sheets. If you use Visual Studio 2010 to work with these samples, you must add property sheets with Stingray Studio paths as explained in Section 2.7.4, “Microsoft Visual Studio 2010 Changes.”
If the sample you are looking for is not shipped with the product or in this archive, you can submit a request to Technical Support.
3.7
Utilities The UTILS directory contains utility programs and Build Wizard files for each subsystem. Each subsystem has a directory under the UTILS directory. Utilities shared by multiple subsystems are stored in the top-level UTILS directory.
3.8
Documentation The DOCS directory contains User’s Guides (.pdf and .chm formats), Class References (.chm format), and other documentation. Since document filenames are unique across subsystems, all documents are stored in the same top-level DOCS directory.
Chapter 3 Directory Organization 35
36
Chapter 4
Migrating Applications to Stingray Studio 4.1
A New Environment If you have used older versions of Stingray Studio, you should be aware that there are some significant changes from releases prior to 2000. Key among these are:
The new Stingray Foundation Library (SFL)
A new directory hierarchy If you are using an Stingray Studio component in a project that used an earlier release of that component, we strongly suggest that you read this chapter.
Chapter 4 Migrating Applications to Stingray Studio 37
4.2
SFL Namespaces 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.
38
4.3
SFL Compatibility With Earlier Component Releases As mentioned above, any of the Stingray Studio components that previously used the Common and MVC libraries now use SFL. What if you upgrade some of your Stingray components to the current version, but you still want to use an earlier version of another Stingray component? You may be wondering, “How do I link my older Stingray component to the newer SFL?” For example, suppose you have a project that uses Objective Edit 6.0 and Objective Tookit 6.02 and then you installed the most recent Stingray Studio release of Toolkit (which also installs SFL). Now you have Objective Edit 6.0, which used to link with the Common and MVC libraries, and you also have Objective Toolkit 7.11, which will link with SFL. You won’t be able to link both SFL and the Common/MVC libraries in the same application. This means that you will need to rebuild Objective Edit 6.0 to use the newest SFL. A special compatibility layer has been added to SFL to allow earlier versions of Stingray components to link with the new SFL. In this way, your application will be able to use both earlier component releases and components from the most recent Stingray Studio release with SFL. You will no longer need to link to the Common or MVC libraries at all. To rebuild Objective Edit 6.0 with SFL, you only need to run the SFL Environment Wizard. At the bottom of the first page, is a checkbox labeled Add SFL compatibility layer paths and is unchecked by default. By selecting this check box, you effectively modify the search paths for Microsoft Visual Studio. First, the include, src, and lib directories for the older Common and MVC libraries are removed from the search paths. They are replaced by the directories for SFL’s compatibility layer include files. When Objective Edit 6.0 is then rebuilt, its make file will rebuild the Common and MVC libraries, and then Objective Edit. This will behave just as it always has. However, even though the older Common and MVC libraries were rebuilt, Objective Edit will now use the headers for SFL’s compatibility layer and will link to the new SFL.
Chapter 4 Migrating Applications to Stingray Studio 39
4.4
A New Directory Structure With the 2000 release came a new directory hierarchy which allows easier organization and integration of the components. Originally, there was a separate directory for each Stingray product with subdirectories for source, include, libraries, etc. For example: Objective Toolkit
Objective Grid
+---+--- Include | +--- Src | +--- Lib | +--- Bin +------+--- Include | +--- Src | +--- Lib | +--- Bin
This meant that you had to have a separate include, src, lib, and bin directory for each product in Microsoft Visual Studio’s search path. This allowed the possibility of causing build and link problems if the directories were not in a particular order or were missing altogether. The new directory structure solves this problem because it requires only a single entry for the include, src, lib, and bin directories for all of the products. Whether you install only Objective Toolkit or all of the products in Stingray Studio, there will be only one directory added to the search paths. An example of the new structure is shown below: Stingray Studio
---+--- Include --+--- Toolkit | +--- Grid | | +--- Src ------+--- Toolkit | +--- Grid | | +--- Lib ------+--- Toolkit | +--- Grid | | +--- Bin ------+--- Toolkit +--- Grid
This presents a change in the way that headers are referenced in the libraries as well as in your existing application. Instead of including a header file as shown here: #include
or
40
#include #include
By default, the header must now be referenced using relative paths: #include
or #include #include
If you prefer not to alter your project, you must run the Environment Wizard for each of the new Stingray Studio components and modify the environment. At the bottom on the dialog is a checkbox labeled Add product subdirectory paths. Selecting this option will add a single directory for each product to the Microsoft Visual Studio’s include search paths. This will ensure that your existing projects that used an earlier version of a particular component will build without making any changes to its stdafx.h include file.
Chapter 4 Migrating Applications to Stingray Studio 41
42
Chapter 5
Porting MFC Controls to the .NET® Platform Using PInvoke 5.1
Overview This chapter describes how to port Stingray MFC controls to Microsoft® .NET®, with minimal changes in existing MFC projects. It is based on the Platform Invocation (PInvoke) feature for data exchange between MFC and C# parts of the project. VB .NET code will be very similar. This method is advantageous in that it allows the use of old DLLs in new .NET WinForm projects. The samples described in this chapter demonstrate only a limited implementation of an approach for migrating MFC components to .NET. Support for the implementation of additional features based on this technology is beyond regular Technical Support Services; however, Consulting Services may provide additional assistance. Contact your sales representative for more information.
Another way of porting MFC controls to the .NET platform uses the compiler option /clr. For more information, see Section 5.6.
Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke 43
5.2
Migrating From MFC to .NET This approach for exchanging data between managed and unmanaged parts of the project uses PInvoke in .NET to access native APIs in dynamic link libraries (DLLs). Additionally, we will explain a method for placing an MFC control into a WinForm project. The procedure is simple: 1. Place the control onto an MFC dialog. 2. Prepare a regular DLL with the dialog and call it as a modeless dialog, adding the following code into the DLL (MFC part of the project): extern "C" __declspec(dllexport) int CallDlg( HWND hWndParent ) { AFX_MANAGE_STATE(AfxGetStaticModuleState()); pDlg = new CMyDialog ( CWnd::FromHandle( hWndParent ) ); pDlg->Create(IDD_DIALOG); return 0; } int CMyDlgApp::ExitInstance() { delete pDlg; return CWinApp::ExitInstance(); }
3. Choose the CHILD style in the dialog properties. 4. Pass the WinForm handle into the dialog's constructor. 5. Add an attribute and a function declaration in the C# program: [DllImport("MyDlg.dll")] public static extern int CallDlg( int hWnd );
The following code is used to call a modeless MFC dialog from the C# program: private void Form1_Activated(object sender, System.EventArgs e) { if (bFirst == true) { CallDlg(this.Handle.ToInt32()); bFirst = false; } }
6. Override the appropriate handlers to adjust reactions to mouse and keyboard messages. The procedure described in this section is a common method for placing an MFC-based control onto a WinForm, calling it as a modeless dialog. The following examples apply this procedure to dialog applications that wrap both the Objective Views and the Objective Grid components.
44
5.3
Objective Views Sample In the following steps, we port an Objective Views project into a C# project. The related sample is located in \Samples\Views\New samples\Objective Views WinForm Sample. 1. Implement your Objective Views project as a dialog-based project. 2. Move the project's files into a regular DLL. 3. Add the C-style APIs into the DLL. 4. Add the C# project to a Visual Studio solution. 5. In the DLL properties, select Linker | Output File and set it to "../SharpTest/bin/Debug/OVDlg.dll". This places the DLL file into the C# project's bin/Debug folder, which allows us to build both projects at once. 6. In the C# code, call the OV project dialog DLL as a child for the WinForm. 7. As an example, you may add button controls to the WinForm, as shown in Figure 8, “Objective Views project as child for Winform.” The Circle and Line buttons are on an MFC dialog that is embedded onto the WinForm. The Circle#, Delete, AddLabel and LabelText buttons are on the WinForm itself. Figure 8 – Objective Views project as child for Winform
Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke 45
The button AddLabel takes text from the C# code and puts it onto the label of a symbol (that is selected on the canvas) in MFC code. The button LabelText gets text from the label of a symbol selected on the canvas and puts it into a message box in the C# code, as shown in Figure 9, “Using the LabelText Button.” You can also try the Delete, Ctrl+C, Ctrl+X, Ctrl+V keys as well as rightclicking, although you must override a few functions in C# to achieve this functionality. Figure 9 – Using the LabelText Button
1. Use PInvoke and the Windows API for data exchange between C# and MFC parts of the solution. 2. Override a few functions of WinForm to provide message routing. 3. To run the sample, build OV803d (lib_lib_dbg).
5.3.1 Additional Notes
46
To access the controller's functions, we use the Windows API SendMessage.
For data exchange, we implement a text buffer in C++. We also use the .NET function StringBuilder for string marshaling in functions GetStrExchange and SetStrExchange.
The ProcessCmdKey, WndProc, and Form1_KeyDown functions in C# have been overridden to provide appropriate handling of mouse and keyboard messages.
5.4
Objective Grid Sample Following similar steps to the sequence proposed for the Objective Views sample, we port an Objective Grid project into a C# project. The related sample is located in the following folder of your Objective Grid installation: \Samples\Grid\Integration with .Net\GridForm\GridForm
In this sample, marshaling data with Platform Invoke is demonstrated for the following data objects:
Strings, in functions SetValueRowCol and GetValueRowCol
Structure with strings, in functions SetStyleRange and GetStyleRowCol
Array of strings, in functions SetValuesArray and GetValuesArray
To adjust message handling, the PreProcessMessage, ProcessDialogKey and ProcessCmdKey functions have been overridden.
5.4.1 Building the Objective Grid Sample When testing this sample, you should set the build configuration for Objective Grid to Unicode static debug (OG903ud.lib). In the DLL properties, select Linker | Output File and set it to "../SharpTest/bin/Debug/OGDlg.dll". This places the DLL file into the C# project's bin/Debug folder, which allows us to build both projects at once. To run this program in the ANSI configuration, the following changes should be made for the C# program:
Replace Auto (in Attributes) with Ansi.
Change the character set within the DLL properties either to Not Set or Multi-Byte.
5.4.2 Testing the Objective Grid Sample When running the sample, you can test the following features:
Set any cell as current by clicking on it:
SetValueRowCol button: sets text "Text from C#", as shown in Figure 10, “Using the SetValueRowCol Button,”
GetValueRowCol button: shows a .NET dialog with current cell’s text
GetStyleRowCol button: shows a .NET dialog with style settings.
Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke 47
Figure 10 – Using the SetValueRowCol Button
Set current cell or select a range:
SetStyleRange - sets style (hardcoded in C#) to selected cell or range, as shown
in Figure 11, “Using the SetStyleRange Button.”
48
Figure 11 – Using the SetStyleRange Button
Select a range:
SetValuesArray button: sets values in selected range to values in array (hardcoded in C#).
GetValuesArray button: shows a .NET dialog with values from selected range, as shown in Figure 12, “Using the GetValuesArray Button.”
Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke 49
Figure 12 – Using the GetValuesArray Button
50
To switch focus from Grid to WinForm controls, press Ctrl + Tab. To switch back, press Tab.
Test arrows and tab keys on Grid.
5.5
Next Steps We’ve used examples from Objective Grid and Objective Views to describe migrating Stingray MFC controls to .NET. You can use the same approach to migrate Objective Edit, Objective Chart and certain portions of Objective Toolkit to be used with .NET. Further development of this approach should allow porting projects with more sophisticated GUIs. The following articles will be helpful for learning PInvoke and relevant migration approaches:
“Managed Extensions for C++ Migration Guide": http://msdn.microsoft.com/en-us/site/aa712961
"Mixing Managed and Unmanaged Code," by Nick Van den Abbeele: http://www.codeproject.com/dotnet/managed_unmanaged.asp
"Walkthrough: Porting an Existing Native C++ Application to Interoperate with .NET Framework Components": http://msdn.microsoft.com/enus/library/8x6abz2h(v=vs.71).aspx
"C# And APIs", by Ajit Mungale: http://www.codeproject.com/Articles/1285/Calling-API-functionsusing-C
"Call Unmanaged Code Part 2-Marshal Class," by Vyacheslav Biktagirov: http://www.csharphelp.com/2006/11/call-unmanaged-code-part-2marshal-class/
"Call Unmanaged DLLs from C#, Killing Processes Cleanly": http://msdn.microsoft.com/en-us/magazine/cc301501.aspx
"Marshaling Data with Platform Invoke": http://msdn.microsoft.com/enus/library/fzhhdwae(v=vs.100).aspx
"Working with Win32 API in .NET," by Shrijeet Nair: http://www.csharpcorner.com/Code/2002/Nov/win32api.asp
5.6
Using Compiler Option /clr The porting of MFC projects to the .NET platform can also be accomplished through the /clr compiler option. Here are some resources for using this approach:
For documentation, see Section 4.4, “Using Objective Grid in a WinForm,” in the Objective Grid User’s Guide.
For samples:
The specific samples, \Samples\Grid\Integration with .NET and \Samples\Views\Integration with .NET, demonstrate not only /clr compilation and linkage, but also the use of .NET managed API calls.
Additional samples are available from the Stingray Knowledge Base:
Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke 51
Using Objective Grid with C++/CLI, http://kb.roguewave.com/kb/index.php?View=entry&EntryID=1400
Stingray Studio MFC Projects Integration with .NET, http://kb.roguewave.com/kb/index.php?View=entry&EntryID=1399
52
For examples of any build configuration with the prefix, mngd_, please refer to the FoundationEx and GridEx libraries, as well as all Stingray samples’ mngd_ build configurations in their associated Visual Studio 2005, 2008 or 2010 solution and project files. The samples demonstrate the compilation and linkage using the /clr option while linking to a library which also uses this option, as well as linking to unmanaged Stingray library build configurations.
Appendix A
3rd-Party Licenses A.1 Stingray Studio 3rd-Party Software Use Stingray Studio products use open source or freely licensed code, and commercially licensed code, as detailed in the following sections. The text of the license agreements can be found in Appendix A and in the \docs\3rdPartyLicenses subdirectory. Table 7 – Open Source or Freely Licensed Software Shipped with Stingray Studio Software
License
Used In
Used For
Objective Edit
Regex v2.24 Open Source License (Dr. John Maddock) See Section A.5.
Objective Edit Source Code
Regular Expression Interface Classes, Find and Replace Classes, VB Script Regular Expression Classes and Edit Controller
Stingray Foundation Library (SFL)
Base64 and Quoted-Printable Encoding/Decoding Open Source License (Hunny Software) See Section A.3.
Stingray Foundation Library XML Source Code
XML Serialization Encoding/Decoding Classes
Objective Toolkit
GuiToolKit Open Source License (Francisco Campos) See Section A.2.
Objective Toolkit Source Code
Docking Windows Autohide Classes
Extended Tree Control Sample Freely Licensed Software (Yan Slatter) See Section A.4.
...\Samples\Toolkit\MFC\ TreeCtrl\TreeDemo
Extended Tree Control Feature in Sample
Appendix A 3rd-Party Licenses
53
Table 7 – Open Source or Freely Licensed Software Shipped with Stingray Studio (Continued) Software
License
Used In
Used For
Regex v2.24 Open Source License (Dr. John Maddock) See Section A.5.
Objective Toolkit Source Code
Regular Expression Utility Classes
TIFF Library v5.0 Freely Licensed Software (Berkeley) (Silicon Graphics) See Section A.6.
Objective Toolkit Source Code
TIFF Image Classes
zLib Compression Library v0.95 & 1.23 Freely Licensed Software (Gailly and Adler) See Section A.7.
Objective Toolkit Source Code
File Compression Classes
A.2 Autohide Source Code License Below is the latest version of the Autohide Source Code Software License, which is also available in the distribution at: /Docs/Autohide Copyright.txt
The text of the License follows: Copyright Information for Autohide Source Code Special thanks to the knowledge found from: GuiToolKit (MFC extension) Created by Francisco Campos G. www.beyondata.com
[email protected] Copyright © Francisco Campos 2002 This program is free software; so you are free to use it in any of your applications(Freeware, Shareware, Commercial), but leave this header intact. These files are provided "as is" without warranty of any kind. GuiToolKit is forever FREE CODE !!!! Created by: Francisco Campos G. Bug Fixes and improvements : Francisco Campos
54
Files containing this copyright: ...\Src\Toolkit\docking\sbarautohide.cpp
A.3 Base64 and Quoted-Printable Encoding/Decoding Source Code License Below is the latest version of the Base64 and Quoted-Printable Encoding/Decoding License, which is also available in the distribution at: /Docs/Base64 Copyright.txt
The text of the License follows: Copyright Information for Base64 and Quoted-Printable Encoding/Decoding Source Code Copyright: The Base64 and Quoted-Printable Encoding/Decoding implementations used in these classes are based on the free MimePak 1.1 C routines obtained from Hunny Software (www.hunnysoft.com) Copyright (C) 1999 Douglas W. Sauder This software is provided "as is," without any express or implied warranty. In no event will the author be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution. The original distribution can be obtained from www.hunnysoft.com. You can email the author at
[email protected]. $RCSfile: base64.h,v $ $Revision: 1.2 $ $Date: 1999-07-29 18:42:39-04 $ Files containing this copyright: ...\Include\Foundation\XMLSerCore\XMLCTEb64qp.h
Appendix A 3rd-Party Licenses
55
A.4 Extended Tree Control Sample Source Code Below is the latest version of the Extended Tree Control Sample License, which is also available in the distribution at: /Docs/ExtendedTreeCtrl Copyright.txt
The text of the License follows: Copyright Information for extended tree control sample Source Code Copyright: TreeDemoDoc.h : interface of the CDemoTreeDoc class Author
: Yan Slatter,
[email protected]
Copyright © Reference Point Ltd, England Notes: This source code is not for redistrubution, unless permission is given by the owner above. This program is distributed WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If any of this code is copied (under permission) you must copy this header. If you use this product, you can massage my ego by accrediting me in the About Box. e.g., "Extended TreeCtrl by Yan Slatter, Reference Point Ltd,
[email protected], all job offers welcome." Files containing this copyright: ...\Samples\Toolkit\MFC\TreeCtrl\TreeDemo\DemoDoc.h
A.5 Regex v2.24 Library Source Code Below is the latest version of the Regex Library Source Code License, which is also available in the distribution at: /Docs/Regex Copyright.txt
The text of the License follows: Copyright Information for Regex v2.24 Library Source Code Copyright: Copyright (c) 1998-9 Dr John Maddock
56
Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Dr John Maddock makes no representations. It is provided "as is" without express or implied warranty. Files containing this copyright: ...\Regex\demo\jgrep\jgrep.cpp ...\Regex\demo\jgrep\jgrep.h ...\Regex\demo\jgrep\regress\main.cpp ...\Regex\demo\jgrep\regress\parse.cpp ...\Regex\demo\jgrep\regress\regress.cpp ...\Regex\demo\jgrep\regress\regress.h ...\Regex\demo\jgrep\regress\tests.cpp ...\Regex\demo\jgrep\timer\hptimer.h ...\Regex\demo\jgrep\timer\timer.cpp ...\Regex\demo\jgrep\timer\timer.h ...\Regex\demo\jgrep\include\jm\cregex.h ...\Regex\demo\jgrep\include\jm\fileiter.h ...\Regex\demo\jgrep\include\jm\jm_cfg.h ...\Regex\demo\jgrep\include\jm\jstack.h ...\Regex\demo\jgrep\include\jm\re_cls.h ...\Regex\demo\jgrep\include\jm\re_coll.h ...\Regex\demo\jgrep\include\jm\re_kmp.h ...\Regex\demo\jgrep\include\jm\re_lib.h ...\Regex\demo\jgrep\include\jm\re_lst.h ...\Regex\demo\jgrep\include\jm\re_mss.h ...\Regex\demo\jgrep\include\jm\re_nls.h ...\Regex\demo\jgrep\include\jm\re_raw.h ...\Regex\demo\jgrep\include\jm\re_str.h ...\Regex\demo\jgrep\include\jm\re_thrd.h ...\Regex\demo\jgrep\include\jm\regcomp.h ...\Regex\demo\jgrep\include\jm\regex.h ...\Regex\demo\jgrep\include\jm\regfac.h ...\Regex\demo\jgrep\include\jm\regfmt.h ...\Regex\demo\jgrep\include\jm\regmatch.h ...\Regex\demo\jgrep\src\cregrex.cpp ...\Regex\demo\jgrep\src\fileiter.cpp ...\Regex\demo\jgrep\src\re_cls.cpp ...\Regex\demo\jgrep\src\re_coll.cpp ...\Regex\demo\jgrep\src\re_mss.cpp ...\Regex\demo\jgrep\src\re_nls.cpp ...\Regex\demo\jgrep\src\re_nlsw.cpp ...\Regex\demo\jgrep\src\re_psx.cpp ...\Regex\demo\jgrep\src\re_psxw.cpp ...\Regex\demo\jgrep\src\re_strw.cpp ...\Regex\demo\jgrep\src\re_thrd.cpp ...\Regex\demo\jgrep\src\regex.cpp ...\Regex\demo\jgrep\src\regfac.cpp ...\Include\Toolkit\rgdescrip.h
Appendix A 3rd-Party Licenses
57
A.6 TIFF Library Source Code Below is the latest version of the TIFF Library Source Code License, which is also available in the distribution at: /Docs/TIFF Copyright.txt
The text of the License follows: Copyright Information for TIFF Library Source Code Copyrights: Copyright (c) 1991, 1992 Silicon Graphics, Inc. TIFF Library. Rev 5.0 Lempel-Ziv & Welch Compression Support This code is derived from the compress program whose code is derived from software contributed to Berkeley by James A. Woods, derived from original work by Spencer Thomas and Joseph Orost. The original Berkeley copyright notice appears below in its entirety. Copyright (c) 1985, 1986 The Regents of the University of California. All rights reserved. This code is derived from software contributed to Berkeley by James A. Woods, derived from original work by Spencer Thomas and Joseph Orost. Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the University of California, Berkeley. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. File containing these copyrights: ...\Src\Toolkit\image\TIFF\TIF_LZW.cpp Copyrights: Copyright (c) 1991, 1992 Silicon Graphics, Inc. Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that (i) the above copyright notices and this permission notice appear in all copies of the software and related documentation, and (ii) the names of Sam Leffler and Silicon
58
Graphics may not be used in any advertising or publicity relating to the software without the specific, prior writtenpermission of Sam Leffler and Silicon Graphics. THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Files containing this copyright: ...\Include\Toolkit\TIF_FAX3.h ...\Include\Toolkit\TIFF.h ...\Include\Toolkit\TIFFCOMP.h ...\Include\Toolkit\TIFFCONF.h ...\Include\Toolkit\TIFFIO.h ...\Include\Toolkit\TIFFIOP.h ...\Include\Toolkit\T4.h ...\Src\Toolkit\image\TIFF\TIF_VERS.cpp ...\Src\Toolkit\image\TIFF\TIF_READ.cpp ...\Src\Toolkit\image\TIFF\TIF_FAX3.cpp ...\Src\Toolkit\image\TIFF\TIF_DIRW.cpp ...\Src\Toolkit\image\TIFF\TIF_AUX.cpp ...\Src\Toolkit\image\TIFF\TIF_COMP.cpp ...\Src\Toolkit\image\TIFF\TIF_DIRR.cpp ...\Src\Toolkit\image\TIFF\TIF_DIRI.cpp ...\Src\Toolkit\image\TIFF\TIF_DIR.cpp ...\Src\Toolkit\image\TIFF\TIF_PRIN.cpp ...\Src\Toolkit\image\TIFF\TIF_ERRO.cpp ...\Src\Toolkit\image\TIFF\TIF_DUMP.cpp ...\Src\Toolkit\image\TIFF\TIF_THUN.cpp ...\Src\Toolkit\image\TIFF\TIF_CCIT.cpp ...\Src\Toolkit\image\TIFF\TIF_STRI.cpp ...\Src\Toolkit\image\TIFF\TIF_TILE.cpp ...\Src\Toolkit\image\TIFF\TIF_WARN.cpp ...\Src\Toolkit\image\TIFF\TIF_SWAB.cpp ...\Src\Toolkit\image\TIFF\TIF_OPEN.cpp ...\Src\Toolkit\image\TIFF\TIF_JPEG.cpp ...\Src\Toolkit\image\TIFF\TIF_WRIT.cpp ...\Src\Toolkit\image\TIFF\TIF_CLOS.cpp ...\Src\Toolkit\image\TIFF\TIF_FAX4.cpp ...\Src\Toolkit\image\TIFF\TIF_PACK.cpp ...\Src\Toolkit\image\TIFF\TIF_FLUS.cpp ...\Src\Toolkit\image\TIFF\TIF_GETI.cpp ...\Src\Toolkit\image\TIFF\TIF_MSDO.cpp
Appendix A 3rd-Party Licenses
59
A.7 zlib Library v 0.95/1.23 Source Code Below is the latest version of the zlib Library License, which is also available in the distribution at: /Docs/zLib Copyright.txt
The text of the License follows: Copyright Information for zLib Library v 0.95/1.23 Source Code Copyrights: zlib.h -- interface of the 'zlib' general purpose compression library version 0.95, Aug 16th, 1995. zlib.h -- interface of the 'zlib' general purpose compression library version 1.2.3, July 18th, 2005 Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly
[email protected] Mark Adler
[email protected] The data format used by the zlib library is described by RFCs (Request for Comments) 1950 to 1952 in the files http://www.ietf.org/rfc/rfc1950.txt Files containing this copyright: ...\Src\Toolkit\utility\compression\zlib123\deflate.c ...\Src\Toolkit\utility\compression\zlib123\zlib.h ...\Src\Toolkit\utility\compression\zlib123\zutil.h ...\Src\Toolkit\utility\compression\zlib123\zutil.c ...\Src\Toolkit\utility\compression\zlib123\zconf.h ...\Src\Toolkit\utility\compression\zlib123\uncompr.c ...\Src\Toolkit\utility\compression\zlib123\trees.c ...\Src\Toolkit\utility\compression\zlib123\compress.c
60
...\Src\Toolkit\utility\compression\zlib123\deflate.h ...\Src\Toolkit\utility\compression\zlib123\gzio.c ...\Src\Toolkit\utility\compression\zlib095\Deflate.cpp ...\Src\Toolkit\utility\compression\zlib095\ZLIB.h
Appendix A 3rd-Party Licenses
61
62
INDEX Symbols .NET PInvoke 44 A arrays, of strings 47 B build problems 25 Build Wizard 10 building the product libraries 9 C classes extending locally 23 compatibility layer paths 39 CustExtDefs.h 20, 22 D default Windows defines 18 defines default Windows 18 directory organization 31 distributing Objective Toolkit applications 7 documentation 5 htmlhelp 2 documentation organization and formats 2 documentation, conventions 5 E examples preprocessor defines 21 exporting symbols in extension libraries 22 exporting symbols in Stingray libraries 19 extending Stingray libraries 19 extending classes locally 23
H help how to access 5 knowledge base 6 technical support 6 htmlhelp 2 I importing symbols in extension libraries 22 importing symbols in Stingray libraries 19 K knowledge base 6 L labels adding 46 text 46 libraries extending 19 extension, macros for importing and exporting symbols 22 importing and exporting symbols in extensions 22 importing and exporting symbols in Stingray libraries 19 Stingray, macros for importing and exporting symbols 19 loading MFC and CRT dynamic link libraries 19 M macros for importing and exporting symbols in extension libraries 22 for importing and exporting symbols in Stingray libraries 19 manifest files 19 ManifestDefs.h 19
MFC 44 migration from MFC to .NET 44 MVC 38 O Objective Grid project 47 Objective Views prerequisites 2 Objective Views project 45 P PInvoke 44 preprocessor defines example 21 prerequisites Objective Views 2 S Stingray Foundation Library (SFL) 38 Stingray, older versions 37 strings 47 symbols importing and exporting in extension libraries 22 importing and exporting in Stingray libraries 19 T technical support 6 W Windows default defines 18 WinForm 44 controls 50
Index 63
64 Index
