Getting Started Guide Stingray® Studio
Version 11.2.0
STINGRAY STUDIO GETTING STARTED GUIDE THIS MANUAL © Copyright 1997-2014 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 6
1.8 Stingray Studio 3rd-Party Software Use 7
2Chapter 2
Building the Libraries 2.1 Build Wizard 9 2.1.1 How Does It Work? 9 2.1.2 To Run the Build Wizard 10
2.2 Building from the Command Line with nmake 16 2.2.1 Using nmake Directly 16 2.2.2 Compiling with 1-Byte Structure Alignment 17 2.2.3 Cleaning Generated Object Files 18
Contents iii
2.3 Default Windows Defines 18 2.4 Manifest Files 19 2.5 Extending Stingray Libraries 19 2.5.1 How Stingray Imports and Exports Symbols 19 2.5.2 Using CustExtDefs.h in Stingray Extensions 22 2.5.3 Extending Stingray Classes Locally in an Executable 23
2.6 Solving Library Build Problems 25 2.6.1 Visual Studio Compilers 25 2.6.2 Run the Build Wizard 25 2.6.3 Stingray Studio Paths in Property Sheets 25 2.6.4 Select the Proper Build Configuration 26
3Chapter 3 Directory Organization 3.1 Stingray Studio Directory Structure 27 3.2 Subsystems and Packages 27 3.3 Top-Level Directories 29 3.4 Include Files 29 3.5 Source Files 30 3.6 Samples 30 3.6.1 Location of Sample Code 31
3.7 Utilities 31 3.8 Documentation 31
4Chapter 4 Migrating Applications to Stingray Studio 4.1 A New Environment 33 4.2 SFL Namespaces 33 4.3 SFL Compatibility With Earlier Component Releases 34 4.4 A New Directory Structure 35 4.5 Migrating to MSVC 2010 or Later from Earlier Versions 36 4.5.1 Global IDE Pathing 36 4.5.2 *.vcxproj Project Extension 37 4.5.3 Target Names 37 4.5.4 Build Configurations 38
iv
4.5.5 Managed Configurations 39 4.5.6 Using Precompiled Headers 40 4.5.7 Specific Issues 40
5Chapter 5 Porting MFC Controls to the .NET® Platform Using PInvoke 5.1 Overview 45 5.2 Migrating From MFC to .NET 46 5.3 Objective Views Sample 47 5.3.1 Additional Notes 48
5.4 Objective Grid Sample 49 5.4.1 Building the Objective Grid Sample 49 5.4.2 Testing the Objective Grid Sample 49
5.5
Next Steps 53
5.6 Using Compiler Option /clr 53
6Chapter 6 MFC and WPF Interoperability 6.1 Introduction to MFC and WPF Interoperability Tools 55 6.2 FoundationEx .NET 55 6.2.1 Framework and References 55 6.2.2 Header Files and Namespaces 56 6.2.3 CLR Support 56 6.2.4 Exceptions 56 6.2.5 Optimization 56 6.2.6 FoundationEx .NET Sample 57
6.3 WPF Window Layouts 57 6.3.1 Canvas 57 6.3.2 Dock Panel 57 6.3.3 Grid 57 6.3.4 Stack Panel 58 6.3.5 Wrap Panel 58
6.4 XAML 58 6.4.1 Delegate Mapping 59 6.4.2 Creating XAML Controls in Code Behind 59
6.5 WPF Docking Panes 59 6.5.1 Overrides 59
v
6.6 Wrap Panel Access 61
AAppendix A 3rd-Party Licenses A.1 Stingray Studio 3rd-Party Software Use 63 A.2 Autohide Source Code License 64 A.3 Base64 and Quoted-Printable Encoding/Decoding Source Code License 65 A.4 Regex v2.24 Library Source Code 66 A.5 TIFF Library Source Code 67 A.6 zlib Library v 0.95/1.23 Source Code 69
Index
vi
71
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 supported compilers that have their respective Feature Packs installed. 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 for Stingray is available through our web site at http://www.roguewave.com/support/contact-support.aspx for customers with a valid Maintenance and Support Agreement for Stingray. Before entering a support request, check the Knowledge Base and other valuable resources available through the Rogue Wave support page at http://www.roguewave.com/support.aspx. These resources provide answers to many common technical 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.
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.
6
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
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.1.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.
Chapter 2 Building the Libraries 9
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.
2.1.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.
10
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.2
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.2.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. For example, for VC++ 11.0 the numbers would be 11. 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.2.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.2.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.3
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.4
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.5
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.5.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.5.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.5.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.6
Solving Library Build Problems If you are having problems building the Stingray Studio libraries, try these solutions to common problems.
2.6.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.6.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.1, “Build Wizard.”
2.6.3 Stingray Studio Paths in Property Sheets 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 Section 4.5, “Migrating to MSVC 2010 or Later from Earlier Versions,” for further details.
2.6.3.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.6.3.2 Adding a Property Sheet Property sheets are provided for all Stingray libraries and shipped samples for Visual Studio 2010 or later, but if you are adding a new project or porting an old project to Visual Studio 2010 or later, 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.
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.
Chapter 2 Building the Libraries 25
The VC++ 10.0 or later library and associated VC++ 10.0 or later 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 or later library and sample build errors.
2.6.3.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.6.4 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. 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.
26
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 27
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.
28
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 29
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.
30
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.5, “Extending Stingray Libraries.”
For Visual Studio 2010 or later, add property sheets. If you use Visual Studio 2010 or later to work with these samples, you must add property sheets with Stingray Studio paths as explained in Section 2.6.3, “Stingray Studio Paths in Property Sheets,” in the Stingray Studio Getting Started Guide.
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 31
32
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.
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.
Chapter 4 Migrating Applications to Stingray Studio 33
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.
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.
34
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.
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
Chapter 4 Migrating Applications to Stingray Studio 35
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 #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.
4.5
Migrating to MSVC 2010 or Later from Earlier Versions 4.5.1 Global IDE Pathing As of Microsoft Visual Studio 2010 Beta 2, global IDE directory paths are no longer supported, meaning that Tools > Options > VC++ Directories no longer exists. Instead, this has been moved to the VS2010 *.vcxproj file properties, at Project > Properties > Configuration Properties > VC++ Directories.
4.5.1.1 Property Sheets To facilitate easier addition of paths to project files, Stingray projects add two property sheets to every project under the VS2010 compiler: SS-Win32-PropSheet and SS-X64-PropSheet. The IDE pathing for Stingray Studio has been added to those property sheets so that appropriate pathing will be picked up when a project is compiled. For the VS2012 compiler, use the SS-Win32Propsheet11 and SS-X64-Propsheet11 property sheets. For the VS2013 compiler, use the SSWin32-Propsheet12 and SS-X64-Propsheet12 property sheets. The property sheets for Stingray Studio are located in the \Src directory.
36
Note: In order to move a project to another directory (not a sibling), it is necessary to remove property sheets from each configuration; otherwise the project may become unreadable due to pathing. After moving, property sheets should be re-added. The Stingray Assistant tool takes care of adding-removing property sheets, particularly while moving the project into another directory. The Assistant tool is located in the \Utils directory.
4.5.1.2 Adding a Property Sheet Property sheets can be added by selecting the Property Manager tab or going to View > Property Manager. Right-click on a project and select Add New Project Property Sheet… or Add Existing Property Sheet…. Note: Property sheets are added to each configuration in the project. It may be necessary to delete property sheets for configurations that do not require them. After a new property sheet is created, any available settings that are changed are applied to all configurations that contain that property sheet.
4.5.1.3 Editing an Existing Property Sheet View property sheets by going to the View > Property Manager window. To edit an existing property sheet, open an appropriate configuration such as Debug, expand the project and the configuration, then right-click on the property sheet and select Properties. This opens the Property Pages dialog, which you can use to change any necessary project settings. Changes made in this property sheet affect all configurations that contain the same property sheet.
4.5.2 *.vcxproj Project Extension The project extension has changed in Visual Studio 2010, and later versions, from *.vcproj to *.vcxproj. Opening a previous version project or solution file in Visual Studio should open the Project Conversion Wizard, which will convert the existing project into the new format.
4.5.3 Target Names Projects that have been converted from a previous version such as Microsoft Visual Studio 2008 SP1 to MSVS 2010 SP1 or later, may generate warnings that Target Name and the Output Name do not match. MSB8012 is displayed at the end of the library/assembly build in the output window: 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\\Microsoft.CppBuild.targets(1095,5): warning MSB8012: TargetPath() does not match the Library's OutputFile property value (). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
Chapter 4 Migrating Applications to Stingray Studio 37
This is a known Microsoft VS2010 SP1 through VS2013 issue: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID= 501237 http://connect.microsoft.com/VisualStudio/feedback/details/523864/how-to-fixmsb8012-lib-outputfile#
4.5.3.1 Setting Target Names One way to resolve the warning is to manually set the Target Name and TargetExt macros in the project properties. To set the Target Name and Target Extension, select Project > Properties and go to the General options to set the Target Name. Use the $(TargetName)$(TargetExt) macro in the project settings for any necessary references. Some suggestions for these macro settings are: Target Name:
$(ProjectName)
Target Ext:
exe, dll, lib, etc. as required by your application
Further suggested settings for these Project properties are: 1. Set Configuration Properties | Linker | General | Output file to $(OutDir)$(TargetName)$(TargetExt). 2. Set Configuration Properties | General | Output Directory to “desired directory path”, which could also be prefixed with $(Platform)\$(Configuration)\. 3. Set Configuration Properties | General | Intermediate Directory to “desired directory path” which could also be prefixed with $(Platform)\$(Configuration)\. 4. Set Configuration Properties | General | Target Name to “desired name for output file” 5. Set Configuration Properties | General | Target Extension to “desired output file extension” (include the preceding dot). The “desired directory path” is user-defined and should match the end-user’s environment needs.
4.5.4 Build Configurations 4.5.4.1 Build Configurations Not Checked When converting a project from a previous version of Microsoft Visual Studio, the Build checkbox is not selected by default in the Configuration Manager. You must manually check the Build checkbox in order for builds to work.
38
4.5.4.2 Template Build Configurations When converting a project from a previous version of Microsoft Visual Studio, there may be a build configuration named Template listed in the Configuration Manager. This build configuration will cause errors if a build is attempted. It is safe to remove this build configuration.
4.5.5 Managed Configurations This link may be helpful for setting up managed configurations. http://msdn.microsoft.com/en-us/library/ms235211.aspx
4.5.5.1 To Compile an MFC Executable or Regular DLL Using /clr 1. Right-click the project in Solution Explorer and then click Properties. 2. In the Project Properties dialog box, expand the node next to Configuration Properties and select General. In the right pane, under Project Defaults, set Common Language Runtime support to Common Language Runtime Support (/clr). In the same pane, make sure that Use of MFC is set to Use MFC in a Shared DLL. 3. Under Configuration Properties, expand the node next to C/C++ and select General. Make sure that Debug Information Format is set to Program Database /Zi (not /ZI). 4. Select the Code Generation node. Set Enable Minimal Rebuild to No (/Gm-). Also set Basic Runtime Checks to Default. 5. Under Configuration Properties, select C/C++ and then Code Generation. Make sure that Runtime Library is set to either Multi-threaded Debug DLL (/MDd) or Multi-threaded DLL (/MD). 6. For Stingray Applications, under the Preprocessor section add the preprocessor command: _MANAGED
4.5.5.2 To Compile an MFC extension DLL Using /clr 1. Follow the steps in the previous section, “To compile an MFC executable or regular DLL using /clr”. 2. Under Configuration Properties, expand the node next to C/C++ and select Precompiled Headers. Set Create/Use Precompiled Header to Not using Precompiled Headers. Alternatively, in Solution Explorer, right-click Stdafx.cpp and then click Properties. Under Configuration Properties, expand the node next to C/C++ and select General. Set Compile with Common Language Runtime support to No Common Language Runtime support. 3. For Stingray Applications, make sure that in the Preprocessor section the _MANAGE flag is not defined.
Chapter 4 Migrating Applications to Stingray Studio 39
4. For the file that contains DllMain and anything it calls, in Solution Explorer, right-click the file name and then click Properties. Under Configuration Properties, expand the node next to C/C++ and select General. In the right pane, under Project Defaults, set Compile with Common Language Runtime support to No Common Language Runtime support.
4.5.6 Using Precompiled Headers To use precompiled header files in a project: 1. Right click on the project and select Properties. Under Configuration Properties > C/C++ > Pre Compiled Headers, for all configurations, select Use /Yu for the Precompiled Header option. Select OK. 2. Expand the project in the Solution Explorer and locate the file called stdafx.cpp, or the similar project main cpp file, then right click and select Properties. Under Configuration Properties > C/C++ > Pre Compiled Headers, for all configurations, select Create /Yc for the Precompiled Header option. Select OK.
4.5.7 Specific Issues 4.5.7.1 Platform Targeting and Deployment Platform targeting and deployment have not been tested nor certified. Modifying NTDDI_VERSION for platforms other than the development/build platform is at your own risk. Technical support is on a best effort basis.
4.5.7.2 The Multi-byte Character Set is No Longer Available with MFC 12.0 In Visual Studio 2013 and later, the MFC libraries for multi-byte character encoding (MBCS) are provided as an add-on to Visual Studio and are available free of charge to Visual Studio customers (Pro, Premium and Ultimate editions only) from the MSDN download site. The libraries require about 440 MB, and the installation includes all localized versions of the libraries. You can install the add-on on any machine on which Visual Studio Pro, Premium or Ultimate edition is installed, and which has the in-box MFC feature enabled. If you uninstall or repair Visual Studio, the MBCS libraries will also be uninstalled or repaired. However, if you just remove the MFC feature, the MBCS libraries will remain on your system. If you repair the MBCS libraries, Visual Studio is not modified in any way. The Redistributable Packages for Visual Studio 2013 and later will still include the MBCS MFC DLLs. No additional steps are required to redistribute the DLLs to your customers. If these MFC libraries are not installed from the MBCS MFC Add-in for MSVS 2013, then the following error appears: >LINK : fatal error LNK1104: cannot open file 'mfc120.lib' 1>NMAKE : fatal error U1077: '"C:\Program Files (x86)\VC\BIN\link.exe"' : return code '0x450'
40
Refer to http://msdn.microsoft.com/en-us/library/vstudio/dn251007(v=vs.120).aspx for more details about this add-in. Remove MBCS Character Set To remove the MBCS as the character set in your project, change the Character Set to Not Set or Unicode under the project settings Configuration Properties > General. Suppress MBCS Warnings To suppress warnings about MBCS, define the following macro in your stdafx.h or another appropriate header file: #define NO_WARN_MBCS_MFC_DEPRECATION http://blogs.msdn.com/b/vcblog/archive/2013/07/08/mfc-support-for-mbcsdeprecated-in-visual-studio-2013.aspx
Some Stingray samples do not suppress this warning because it is displayed via the inclusion of MFC header files that precede Stingray header files.
4.5.7.3 Output Files Warnings In Visual Studio 2013, if warnings are issued about being unable to locate vc120.pdb, then change the project properties to use $(IntDir)$(TargetName).pdb or similar in the Configuration Properties > C/C++ > Output Files setting.
Chapter 4 Migrating Applications to Stingray Studio 41
4.5.7.4 ADO Issues as of Windows 7.0 SP1 or Later When compiling Objective Grid with ADO Grid components from the Build Wizard’s Components page, as shown below, on Windows 7 or later and on MSVS 2012 or later, a few Microsoft issues are exposed.
ADO Design Change as of Windows 7.0 SP1 There is a Microsoft by-design change in ADO in Windows 7 SP1 that interfaces have new GUIDs. The pattern is that most ADO interfaces (say Connection) have new GUIDs while the old GUIDs are assigned to interfaces named xxx_deprecated (say Connection_Deprecated). The reason for this change is mentioned in KB983246: “Some ADO APIs are platform dependent in ADO 2.7 and later versions. On 64-bit versions of Windows, these ADO APIs process arguments by using a 64-bit data type (such as the LONGLONG data type). However, applications that use these APIs still use the LONG data type. Therefore, you receive a “Type Mismatch” error message when you try to run the macro.” The interfaces with the new GUIDs (in Windows 7 SP1 or later) don't have this issue. As a result, if your application is re-compiled on Windows 7 SP1 and it uses the earlier bindings to ADO, it probably will not work on down-level OSs, such as Windows 7 RTM, XP, and so on. Please note that this problem only occurs when the application is re-compiled. Existing applications should run on Windows 7 SP1 without any problems. Below we suggest three ways to build with ADO on Windows 7 SP1 or later. Our suggestions do not include the main way recommended by Microsoft in output messages when you build Grid: “Change your target platform to Windows 7 or below if your application requires backward compatibility for the ADO interface.” 42
If you have to re-compile your application on SP1, here are three workarounds: 1. Request a KB983246 package and install it on your customers' machines. The re-compiled application should work after the package is installed. 2. Re-write your application to use the later binding to ADO, or use interfaces with the names xxx_deprecated. 3. Keep an old version of the ADO typelib (i.e., msado28.tlb) (you can copy it from Windows 7 RTM), then compile your application with the old typelib instead of the one on your system.
4.5.7.5 Troubleshooting Cannot Open SupportedPlatforms.h If you receive this error: Fatal error C1083: Cannot open include file “SupportedPlatforms.h” : No such file or directory
it means that you may not have paths set up correctly for the project you are working on. Refer to Section 4.5.1, “Global IDE Pathing,” Ambiguous Call to OpenDocumentFile() The API for OpenDocumentFile() has changed in CSingleDocTemplate and CMultiDocTemplate to: virtual CDocument* OpenDocumentFile(LPCTSTR lpszPathName, BOOL bAddToMRU, BOOL bMakeVisible = TRUE);
A second boolean parameter to add to the MRU list can be added to the call to resolve it. Application Cannot Start If you receive an error message when trying to start the Visual Studio 2010 IDE that says, “Cannot start application,” it may be due to a bug with font support in VS2010. You can work around this by resetting the IDE data. Open the VS2010 command prompt and type: devenv /resetuserdata
MSXML 6.0 Conversion from VC9 to VC10 on XP x64 SP2 requires MSXML 6.0 SP2 to be installed: http://connect.microsoft.com/VisualStudio/feedback/details/522619/conversionwizard-hangs-when-trying-to-convert-vs2008-project
Chapter 4 Migrating Applications to Stingray Studio 43
44
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 45
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.
46
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 47
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
48
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 49
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.”
50
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 51
Figure 12 – Using the GetValuesArray Button
52
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 53
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
54
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 and supported Visual Studio compiler 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.
Chapter 6
MFC and WPF Interoperability 6.1
Introduction to MFC and WPF Interoperability Tools Stingray Studio 11.1 introduced Windows Presentation Foundation (WPF) child windows for Single Document Interface (SDI), Multiple Document Interface (MDI), and Docking Pane windows in MFC applications. This new functionality for MFC and WPF Interoperability is located in the new FoundationEx .NET project.
6.2
FoundationEx .NET FoundationEx .NET functionality is an extension to the existing FoundationEx classes and is supported on Microsoft Visual Studio 2010 and later. This functionality is located in a new project that separates the dependencies of the .NET framework from FoundationEx. The solution and project files are in \Src\FoundationEx* .NET.sln, where * is a numerical value for the compiler version. Using the features of FoundationEx .NET requires the addition of various elements to your existing or new FoundationEx-based application, as discussed in this section.
6.2.1 Framework and References FoundationEx .NET requires the Microsoft .NET framework. This framework is installed with your compiler. When creating a FoundationEx .NET project, the Visual Studio project settings need to reference .NET assemblies. These .NET assemblies include: PresentationCore, PresentationFramework, System, System.Xaml, WindowsBase. Set these in the project settings under Common Properties >Framework and References. Select Add New Reference to locate the .NET assembly references mentioned above and add them to the project.
Chapter 6 MFC and WPF Interoperability 55
6.2.2 Header Files and Namespaces To access the new FoundationEx.NET functionality, add header files to your new or existing FoundationEx project. These include FoundationExNet.h, vcclr.h, and msclr\event.h. // Typically added to stdafx.h #include // View Classes will typically need the following: // C++/CLI Headers and Namespaces #include #include using namespace System; using namespace System::Windows; using namespace System::Windows::Controls; using namespace System::Windows::Media; using namespace System::Windows::Shapes; using namespace System::Windows::Media::Imaging; using namespace System::Windows::Media::Animation; using namespace System::Windows::Interop; using namespace sflexnet;
As shown in the code snippet above, it is also necessary to include a reference to the sflexnet namespace.
6.2.3 CLR Support The common language runtime (CLR) must be added as an option in the project settings. In Visual Studio, set the project setting Configuration Properties > General > Common Language Runtime Support to Common Language Runtime Support (/clr). In addition, add the CLR to any files in a mixed programming application that uses managed code. To add this support in Visual Studio, right-click on the .cpp file and select properties. Then choose Configuration Properties > C/C++ > General > Common Language Run Time Support and select Common Language Runtime Support (/clr).
6.2.4 Exceptions In mixed mode programming using C++/CLI, the exception option /EHs is incompatible with the /clr switch. In the Visual Studio project settings, change Code Generation to exceptions to /EHa by setting Configuration Properties > C/C++ > Code Generation > Enable C++ Exceptions to Yes with SEH Exceptions (/EHa).
6.2.5 Optimization In mixed mode programming using C++/CLI, the optimization options must be disabled. In the Visual Studio project settings, disable optimization by setting Configuration Properties > C/C++ > Optimization > Optimization to Disabled (/Od).
56
6.2.6 FoundationEx .NET Sample A sample is provided that demonstrates the usage of the FoundationEx .NET features involving MFC and WPF interoperability. The sample is located in the \Samples\FoundationEx .NET\WPFMDIEx\ directory and is used in discussion of all code samples related to MFC and WPF Interoperability throughout this document.
6.3
WPF Window Layouts WPF is a .NET graphical subsystem of Microsoft .NET that includes a rich set of tools for designing user interfaces, supporting an application architecture that separates user interface code from implementation, or business logic, code. This design is made possible by an XML-based markup language called XAML (Extensible Application Markup Language) that declaratively represents the user interface. FoundationEx .NET adds the following child window and docking window layouts: Canvas, Dock Panel, Grid, Stack Panel, Wrap Panel, and XAML.
6.3.1 Canvas The Canvas View Layout supports exact placement of WPF controls on a WPF canvas. Canvases can be nested inside each other in order to provide a higher degree of precision when placing controls. Canvas View Class
To create a Canvas View Class, derive from the SFLWPFCanvasViewEx class. See the sample file \Samples\FoundationEx .NET\WPFMDIEx\WPFMDIExCanvasView.h for an example.
Canvas Access
To access the Canvas control, call GetWpfCanvas().
6.3.2 Dock Panel The Dock Panel View Layout supports placement of WPF controls in a panel that can be docked to the top, bottom, left, or right of the MFC window. Dock Panel View Class
To create a Dock Panel View Class, derive from the SFLWPFDockPanelViewEx class. See the sample file \Samples\FoundationEx .NET\WPFMDIEx\WPFMDIExDockPanelView.h for an example.
Dock Panel Access
To access the Dock Panel control, call GetWpfDockPanel().
6.3.3 Grid The Grid View Layout supports placement of WPF controls in a grid, allowing exact specification of the row and column of the control.
Chapter 6 MFC and WPF Interoperability 57
Grid View Class
To create a Grid View Class, derive from the SFLWPFGridViewEx class. See the sample file \Samples\FoundationEx .NET\WPFMDIEx\WPFMDIExGridView.h for an example.
Grid Access
To access the Grid control, call GetWpfGrid().
6.3.4 Stack Panel The Stack Panel View supports placement of controls stacked on top of each other either vertically or horizontally. Stack Panel Class
To create a Stack Panel View Class, derive from the SFLWPFStackPanelViewEx class. See the sample file \Samples\FoundationEx .NET\WPFMDIEx\WPFMDIExStackPanelView.h for an example.
Stack Panel Access
To access the Stack Panel control, call GetWpfStackPanel().
6.3.5 Wrap Panel The Wrap Panel View supports placement of controls in the container such that the controls can be wrapped horizontally or vertically as the container is resized. Wrap Panel Class
To create a Wrap Panel View Class, derive from the SFLWPFWrapPanelViewEx class. See the sample file \Samples\FoundationEx .NET\WPFMDIEx\WPFMDIExWrapPanelView.h for an example.
Wrap Panel Access
6.4
To access the Wrap Panel control, call GetWpfWrapPanel().
XAML The XAML View loads controls from a XAML file. The root of the XAML file cannot be a Window or a Page. Instead, the file must start with one of the existing WPF layout types: Canvas, DockPanel, Grid, StackPanel, or WrapPanel. Delegate function names are not defined in the XAML; rather, they are defined in code as shown in the section “Delegate Mapping”. XAML Class
To create an XAML View, derive from the SFLWPFXAMLViewEx class. See the sample file \Samples\FoundationEx .NET\WPFMDIEx\WPFMDIExXAMLView.h for an example.
Loading XAML
Load the XAML using the SFLXAMLDocumentEx function LoadXAML(). You can call this function in the derived document class’s OnNewDocument() function or in the OnInitialUpdate() call of the corresponding View class. For example: CXAMLDoc* pDoc = (CXAMLDoc*)GetDocument(); if(pDoc) pDoc->LoadXAML(“XamlWindow.xaml”);
58
6.4.1 Delegate Mapping Delegates for WPF controls are mapped using the BEGIN_DELEGATE_MAP() and END_DELEGATE_MAP() macros. Between the begin and end macros, the EVENT_DELEGATE_ENTRY() macro is used to map delegate functions to function names in the XAML file. For example: // Header public: BEGIN_DELEGATE_MAP( CWPFMDIExXAMLView ) EVENT_DELEGATE_ENTRY(button1_Click, Object^, RoutedEventArgs^) EVENT_DELEGATE_ENTRY(button2_Click, Object^, RoutedEventArgs^) END_DELEGATE_MAP() public: void button1_Click(Object^ sender, RoutedEventArgs^ e); void button2_Click(Object^ sender, RoutedEventArgs^ e);
6.4.2 Creating XAML Controls in Code Behind Visual Studio contains no facility for automatic code generation for creating WPF controls in C++/CLI. Controls that correspond to the control labels in XAML are easily set up using the macros SFLEX_WPF_CREATE_CTRL_FROM_VIEW() and SFLEX_WPF_ASSIGN_DELEGATE(). For example: SFLEX_WPF_CREATE_CTRL_FROM_VIEW(Button, btn1, "button1") SFLEX_WPF_ASSIGN_DELEGATE(btn1, Click, button1_Click) SFLEX_WPF_CREATE_CTRL_FROM_VIEW(Button, btn2, "button2") SFLEX_WPF_ASSIGN_DELEGATE(btn2, Click, button2_Click)
6.5
WPF Docking Panes Like WPF Window Layouts, WPF Docking Panes allow WPF layouts inside a MFC Feature Pack Docking Pane. In a WPF Docking Pane, you can add any kind of WPF control. Examples include the WPF Calendar and any of the WPF layout controls, such as Canvas.
6.5.1 Overrides When creating a WPF control inside a Docking Pane, two functions should be overridden, CreateControl() and AdjustLayout().
Chapter 6 MFC and WPF Interoperability 59
6.5.1.1 CreateControl() The function CreateControl() handles any special control creation that might be needed, such as custom sizes and control properties. A typical example of CreateControl() is: BOOL CWPFDockingPane2::CreateControl() { if(m_wpfControlType) { try { // Create the WPF Control m_wpfFrameworkElement = safe_cast( Activator::CreateInstance(m_wpfControlType) ); if(m_wpfFrameworkElement) { CRect rect; GetClientRect(&rect); GetWpfControl()->Height = rect.Height(); //Add 1 to work around CTP bug GetWpfControl()->Width = rect.Width() + CPPCLI_CTP_WIDTH_OFFSET_BUG; // Set the background to white so it looks // more pleasing to the eye. ((Canvas^)(FrameworkElement^)m_wpfFrameworkElement)-> Background = Brushes::White; } }catch(NotSupportedException^ e) { Console::WriteLine("SFLWPFDockableCtrlPaneEx Exception: {0}", e->Message); return false; }catch(Reflection::TargetInvocationException^ e) { Console::WriteLine("SFLWPFDockableCtrlPaneEx Exception: {0}", e->Message); return false; } } return TRUE; }
60
6.5.1.2 AdjustLayout() The function AdjustLayout() handles any special layout considerations such as positioning of nested controls. A typical example of AdjustLayout() is: void CWPFDockingPane2::AdjustLayout() { if(m_wpfFrameworkElement) { // Width and Height. CRect rect; GetClientRect(&rect); GetWpfControl()->Height = rect.Height(); GetWpfControl()->Width = rect.Width() + //Adding 1 to work around CTP bug //CPPCLI_CTP_WIDTH_OFFSET_BUG; ((Canvas^)(FrameworkElement^)GetWpfControl())-> Background = Brushes::White; } }
6.6
Wrap Panel Access To access the Docking Pane control, call GetWpfControl(). In most situations, you need to cast to a FrameworkElement and then to the appropriate WPF control, such as: ((Canvas^)(FrameworkElement^)GetWpfControl())
Chapter 6 MFC and WPF Interoperability 61
62
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.4.
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
Regex v2.24 Open Source License (Dr. John Maddock) See Section A.4.
Objective Toolkit Source Code
Regular Expression Utility Classes
Appendix A 3rd-Party Licenses
63
Table 7 – Open Source or Freely Licensed Software Shipped with Stingray Studio (Continued) Software
License
Used In
Used For
TIFF Library v5.0 Freely Licensed Software (Berkeley) (Silicon Graphics) See Section A.5.
Objective Toolkit Source Code
TIFF Image Classes
zLib Compression Library v0.95 & 1.23 Freely Licensed Software (Gailly and Adler) See Section A.6.
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 Files containing this copyright: ...\Src\Toolkit\docking\sbarautohide.cpp
64
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
65
A.4 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 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
66
...\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
A.5 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.
Appendix A 3rd-Party Licenses
67
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 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
68
...\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
A.6 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]
Appendix A 3rd-Party Licenses
69
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 ...\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
70
INDEX Symbols .NET PInvoke 46 A arrays, of strings 49 B build problems 25 Build Wizard 9 C classes extending locally 23 compatibility layer paths 34 CustExtDefs.h 20, 22 D default Windows defines 18 defines default Windows 18 directory organization 27 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 48 text 48 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 46 migration from MFC to .NET 46 MVC 33 O Objective Grid project 49 Objective Views prerequisites 2 Objective Views project 47 P PInvoke 46 preprocessor defines example 21 prerequisites Objective Views 2 S Stingray Foundation Library (SFL) 33 Stingray, older versions 33 strings 49 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 46 controls 52
Index 71
72
