Echelon, LON, LonWorks, Neuron, 3120, 3150, Digital Home,
i.LON, LNS, LonMaker, LonMark, LonPoint, LonTalk,
NodeBuilder, ShortStack, and the Echelon logo are
trademarks of Echelon Corporation registered in the United
States and other countries. FTXL, LonScanner, LonSupport, ISI,
OpenLDV, and LNS Powered by Echelon are trademarks of
Echelon Corporation.
Other brand and product names are trademarks or
registered trademarks of their respective holders.
Neuron
Chips and other OEM Products were not designed for
use in equipment or systems which involve danger to human
health or safety or a risk of property damage and Echelon
assumes no responsibility or liability for use of the Neuron
Chips or LonPoint Modules in such applications.
Parts manufactured by vendors other than Echelon and
referenced in this document have been described for
illustrative purposes only, and may not have been tested by
Echelon. It is the responsibility of the customer to determine
the suitability of these parts for each application.
ECHELON MAKES NO REPRESENTATION, WARRANTY, OR
CONDITION OF ANY KIND, EXPRESS, IMPLIED, STATUTORY, OR
OTHERWISE OR IN ANY COMMUNICATION WITH YOU,
INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR ANY
PARTICULAR PURPOSE, NONINFRINGEMENT, AND THEIR
EQUIVALENTS.
No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means,
electronic, mechanical, photocopying, recording, or
otherwise, without the prior written permission of Echelon
Corporation.
Appendix A Standard Plug-in Commands......................................... 33
Appendix B Standard Plug-in Properties........................................... 35
Appendix C Standard Plug-in Object Classes................................... 41
Appendix D Standard Plug-in Exceptions ......................................... 45
Appendix E Glossary........................................................................... 47
Appendix F Running the ACME Example C# Plug-in........................ 51
Preface
You can use LNS device plug-ins to simplify the installation of your devices for network
integrators. This manual provides an overview of the LNS Plug-in API and how plug-ins
and director applications such as the LonMaker Integration Tool interact. It describes
how to install the LNS Plug-in Framework Developer’s Kit, which implements the LNS
Plug-in API and provides a set of framework assemblies that let you efficiently develop
and redistribute LNS plug-ins. It explains how to write device plug-ins using .NET
programming languages such as C# and Visual Basic .NET, and how to redistribute your
LNS device plug-ins.
Purpose
This document describes how to write LNS plug-ins using .NET programming languages such as C#
and Visual Basic .NET. After reading this document, you should understand the basic mechanics of
how plug-ins work, and how to write a plug -in usi n g t he LNS Pl u g-in Framework.
Audience
Users of this document should have a basic understanding of the LNS Object Server, and experience
programming in C#, Visual Basic .NET, or another .NET programming language.
Software Requirements
Software requirements for computers running the LNS Plug-in Framework Developer’s Kit are listed
below:
•Microsoft Windows Vista™, Microsoft Windows XP, Windows 2000, or Windows Server 2003.
Echelon recommends that you install the latest service pack available from Micro soft for your
version of Windows.
•Microsoft .NET Framework Version 2.0 Redistributable Package. To check whether your
computer has this software and download it (if necessary), go to the Microsoft Windows Update
Web page at
•Microsoft Visual Studio 2005 Professional E di t i on o r hi g he r. Microsoft Visual Studio Express
editions may work, but they have not been tested.
http://update.microsoft.com.
• LNS Server Turbo Edition (3.22 or later).
• LNS Turbo plug-in director application. This may be the LonMaker Integration Tool Turbo
Edition (3.2 or later) or the LNS Turbo ADK Plug-in Director example application.
Content
This guide includes the following content:
•
Introduction: Describes the types of plug-ins that are used with LONWORKS networks, and it
describes how director applications request act i ons fr om plug-ins. Explains how the LNS Plug-in
Framework allows plug-ins to function in the .NET environment and interface with COM-based
director applications.
Creating and Redistributing LNS Device Plug-ins: Explains how to create an LNS device plug-in
•
project using the LNS Plug-in Framework Developer’s Kit, how to debug your plug-ins, and how
to create an installation project for your plug-in so th at you can provide it to users.
How Plug-ins Work with Directors: Summarizes the life cycle of a plug-in. It describes how
•
plug-ins make themselves known to directors, how plug-ins let directors know what they can do,
and how directors and plug-ins interact. Provides examples of how these tasks should be
performed.
•Appendixes: Includes listings of standard plug-in commands, properties, classes, and exceptions;
a glossary that provides definitions for key terms and concepts associated with programming
plug-ins; and a demonstration of plug-in behavior using the example ACME C# plug-in that is
installed by the LNS Plug-in Framework Developer’s Kit.
Related Manuals
The following manuals provide supplemental information to the material in this guide. You can
download these documents from Echelon’s Web site at
www.echelon.com.
LNS®Programmer’s Guide
LonMaker
®
User’s Guide
Describes how to use the LNS Object Server ActiveX Control to
develop an LNS application on a Microsoft Windows Vista
Server 2003, Windows XP, or Windows 2000 host computer.
Describes how to use the LonMaker Integration Tool to design,
commission, modify, and maintain L
ONWORKS networks.
Other Related Material
This document refers to and describes the LNS Plug-in API that all plug-ins use. Because plug-ins
work together with directors, a director is needed in order to fully test and debug the plug-ins that you
write. While any director can be used for this purpose, this guide describes the use of the LonMaker
tool as the director. See the LonMaker User’s Guide for more detailed information on the use of the
LonMaker tool.
For More Information and Technical Support
The LNS Plug-in Framework Online Help details the Echelon.LNS.Plugin and
ACME.DevicePlugin namespaces. The Echelon.LNS.Plugin namespace contains a framework of
interfaces, classes and other types for creating .NET-based LNS Plug-ins. The ACME.DevicePlugin
namespace contains example device plug-ins written in C# and Visual Basic that use the LNS Plug-in
Framework. To view the LNS Plug-in Framework Online Help, click Start, point to Programs, point
to Echelon LNS Plug-in Framework Developer’s Kit, and then select LNS Plug-in Framework Online Help.
The ReadMeFirst file for the LNS Plug-in Framework provides descriptions of known problems, if
any, and their workarounds. To view this ReadMe file, click Start, point to Programs, point to
Echelon LNS Plug-in Framework Developer’s Kit, and then select ReadMe First. For additional
information, you can go to Echelon’s Development Tools Web pages at
www.echelon.com/products/development.
™
,
If you have technical questions regarding the programming of LNS plug-ins not answered by this
document, the LNS Plug-in Framework Online Help, or the ReadMe First file, you can contact
technical support. To receive technical support from Echelon, you must purchase support services
from Echelon or an Echelon support partner. See
Echelon support and training services.
You can obtain technical support via phone, fax, or e-mail from your closest Echelon support center.
The contact information is as follows:
Region Languages Supported Contact Information
The Americas
English
Japanese
www.echelon.com/support for more information on
Echelon Corporation
Attn. Customer Support
550 Meridian Avenue
San Jose, CA 95126
Phone (toll-free):
1-800-258-4LON (258-4566)
Phone: +1-408-938-5200
Fax: +1-408-790-3801
lonsupport@echelon.com
Region Languages Supported Contact Information
Europe
English
German
French
Italian
Echelon Europe Ltd.
Suite 12
Building 6
Croxley Green Business Park
Hatters Lane
Watford
Hertfordshire WD18 8YH
United Kingdom
Phone: +44 (0)1923 430200
Fax: +44 (0)1923 430300
lonsupport@echelon.co.uk
Japan
JapaneseEchelon Japan
Holland Hills Mori Tower, 18F
5-11-2 Toranomon, Minato-ku
Tokyo 105-0001
Japan
Phone: +81-3-5733-3320
Fax: +81-3-5733-3321
lonsupport@echelon.co.jp
China
Chinese
English
Echelon Greater China
Rm. 1007-1008, IBM Tower
Pacific Century Place
2A Gong Ti Bei Lu
Chaoyang District
Beijing 100027, China
Phone: +86-10-6539-3750
Fax: +86-10-6539-3754
lonsupport@echelon.com.cn
Other Regions
EnglishPhone: +1-408-938-5200
Fax: +1-408-328-3801
lonsupport@echelon.com
You can submit a feedback form with suggestions on how to improve the product’s functionality and
documentation at
www.echelon.com/company/feedback. This feedback form is not forwarded to
technical support and should not be used to submit technical or product support related issues. Please
send technical support questions to your Echelon support center.
Introduction
This chapter describes the types of plug-ins that are used with LONWORKS networks,
and it describes how director applications request actions from plug-ins. It explains
how the LNS Plug-in Framework allows plug-ins to function in the .NET
environment and interface with director applications.
1
Introduction
An LNS plug-in is an out-of-process automation server that implements the COM-based LNS Plug-in
API so that it may be instantiated and controlled by an LNS plug-in director application. Plug-ins
provide a standard way to extend and customize the functionality of LNS applications. For example,
plug-ins allow device manufacturers to provide customized software that simplifies the configuration,
monitoring, or control of their devices (plug-ins that are specific to a particular type of device are
sometimes referred to as device plug-ins). Plug-ins can also add new functionality to LNS applications
such as alarming, logging, and trending. The LNS Plug-in API is further described in Chapter 3,
Plug-ins Work with Directors.
An LNS plug-in director applicat i on (herein referred to as a director) is a complex, general-purpose
network manager that is extensible in its functionality, because it can call LNS plug-ins. For example
Echelon’s LonMaker Integration Tool is an LNS plug-in director application that can call LNS
plug-ins to extend its functionality—typically to perform manufacturer-specific device configuration.
When a plug-in is installed on a computer, the setup program installs a number of items for the plug- in
to the computer’s registry. This enables directors to determine which plug-ins a user has installed on
their computer and call the plug-ins at appropriate times. Directors can make access to plug-ins
completely transparent to the end-user. This means that the user cannot tell when a task is built-in to
the director and when it is being provided by a plug-in called by the director.
Plug-ins provide many benefits to network integrators, who are the end-users of tools. Plug-ins make
tools easier to use and make network integrators more productive. They reduce the cost of training
network integrators on the use of tools. They also reduce the time and cost of installing, configuring,
and maintaining systems.
Tool and device manufacturers also benefit from plug-ins. For tool manufacturers, plug-ins make tools
extensible and thus more valuable. Network integrators can incrementally add features—from the
tool’s manufacturer or from other plug-in vendors—to adapt the tool to their needs. A tool that
supports plug-ins is a tool that will become easier to use, more productive, and more powerful over
time.
How
For device manufacturers, plug-ins allow them to make their devices easy to install, configure, and
maintain—without the cost of having to develop an entire, customized tool. Devices that come with
plug-ins have a competitive edge: they are cheaper to install and service, and they are easier to use.
The LNS Plug-in Framework Developer’s Kit allows plug-ins to function in the .NET environment and
interoperate with COM-based directors. It includes the .NET components needed for interfacing with
the COM-based LNS API in the .NET environment. It provides a set of example software and
framework assemblies that let you efficiently develop plug-ins with the latest .NET programming tools
and re-distribute your plug-ins. It provides the plug-in API an d COM interaction so that you do not
need to provide it in your .NET application.
Overview of Plug-ins
A plug-in is a type of LNS application that implements the COM-based LNS Plug-in API. The Plug-in
API consists of the LNS Plug-in Commands (see Appendix A,
Plug-in Properties (see Appendix B,
Appendix D,
example, by the set of commands that it provides and by the class of objects that each command
operates on). For example, a plug-in might implement two actions, a test command of AppDevice
class objects and a test command of Router class objects.
Standard Plug-in Exceptions). A plug-in is defined by the actions that it can perform (for
Standard Plug-in Properties), and LNS Plug-in Exceptions (see
Types of Plug-ins
There are two types of plug-ins: device plug-ins and system plug-ins.
Device plug-ins apply to a single device or a single functional block within a device. For example, you
could create a device plug-in for a device developed with the NodeBuilder tool that allows users to set
Standard Plug-in Commands), the LNS
configuration properties and enforce limits on configuration property values. You can create a device
plug-in executable that operates on multiple device types. The single executable that is able to operate
on multiple device types is a programming convenience. You can also create a separate device plug-in
for each functional block in a device, but it is typical to include the support for all functional blocks of
a device type in a single plug-in, and let the plug-in determine which object to act upon based on the
object that has been passed as a parameter.
System plug-ins apply to an entire network. For example, a system plug-in could provide a custom
interface that would allow you to test all devices on a network and see the results. A system plug-in
could also be designed to manage all of the devices in a room, or on a floor of a building. This
document focuses on device plug-ins; however, you can also implement a system plug-in based on the
instructions in Chapter 2,
The LNS Plug-in API defines a single method, SendCommand(), and a number of properties that a
plug-in must implement.
Creating and Redistributing LNS Device Plug-ins.
LNS Plug-in Commands
The SendCommand() method is used by directors to ask a plug-in to perform a command (specified
by ID) on an object (specified by class ID and object path). Plug-ins can implement standard
commands defined by LNS or custom commands that they define. The plug-in designer is responsible
for having the plug-in implement commands in a way that makes sense (for example, if a plug-in
implements the Browse command, the plug-in designer must design the implementation of the
plug-in’s Browse command). The standard plug-in commands are listed in Appendix A,
Plug-in Commands.
Device plug-ins typically implement the LcaCommandConfigure command. This command is used
by network tools to provide an option for network integrators to configure a device or functional block.
Device plug-ins may also implement the LcaCommandBrowse command if they are used for
monitoring and controlling the device in addition to configuring it. The device plug-in can also decide
whether to display the same user interface for these two commands.
Standard
Plug-ins can also implement custom commands. The values for custom command IDs are assigned by
the plug-in, and may be any value greater than or equal to LcaCommandUserStart (10000).
LNS Plug-in Properties
All plug-ins must also implement a standard set of properties along with any custom properties
required by the developer. The standard properties allow the director to tell the plug-in information
about the network is it operating on (such as the NetworkName and the NetworkInterfaceName
properties) as well as to control the appearance of the plug-in (such as the Left, Height, and Visible
properties). The complete list of required and optional properties is given in Appendix B,
Plug-in Properties. Read access must be provided to all properties. Write access may optionally be
provided for most properties; however, some properties must be read-only or must be read-write as
noted in Appendix B,
Standard Plug-in Properties.
Standard
Overview of the LNS Plug-in Framework Developer’s Kit
The LNS Plug-in Framework Developer’s Kit includes the following components needed for
interfacing with the COM-based LNS API in the .NET environment: the LNS Plug-in Framework and
the LNS .NET wrapper.
The LNS Plug-in Framework is a library of classes, interfaces, and value types that provides access to
LNS Plug-in functionality and is designed to be the foundation on which .NET-based plug-ins are
built. The LNS Plug-in Framework provides the following components:
•A COM Callable Wrapper (CCW) that lets a COM director application, such as the LonMaker
tool, call into the .NET plug-in assembly.
• An implementation of the full LNS Plug-in API interface (ILnsPlugin).
• A simple out-of-process server task model that supports plug-ins in the .NET environment (LNS
plug-ins are out-of-process COM servers, for which support in the .NET environment is not well
documented).
The LNS .NET wrapper is the Primary Interop Assembly, which is generated by Echelon and
distributed with LNS. It provides a Run-time Callable Wrapper (RCW) that allows your .NET
plug-in to interface with the COM-based LNS API. Note that the LNS .NET wrapper is required for
plug-in development with .NET, but is not considered part of the LNS Plug-in Framework because it
may also be used by LNS applications that are not plug-ins. The LNS Primary Interop Assembly is
included with the LNS runtime components starting in LNS 3.23. If your plug-in is targeted for LNS
3.23 or later, you do not need to include the LNS 3.22 Primary Interop Assembly that is included
with the LNS Plug-in Developer’s Kit, version 1.1.
The LNS Plug-in Framework is implemented as a set of base classes that your plug-in will inherit and
extend. These classes are documented by the LNS Plug-in Framework Online Help. The use of
these classes is demonstrated in the
Creating the Plug-in Source Files section in Chapter 2.
•PluginObjectBase. This class contains the basic framework implementation of the LNS Plug-in
API methods and properties.
•PluginServerBase. This class works in conjunction with PluginObjectBase. It contains the
process model handling for the out-of-process server.
•PluginFormBase. This class contains the base class for the optional user interface instantiation of
the plug-in. This may not be necessary in all plug-ins, since some plug-ins may not have user
interfaces.
Creating and Redistributing LNS
Device Plug-ins
This chapter explains how to create an LNS device plug-in using the LNS Plug-in
Framework Developer’s Kit, how to debug your plug-ins, and how to create an
installation project for your plug-in so that you can provide it to users.
2
Creating and Redistributing Plug-ins Overview
You can use the LNS Plug-in Framework Developer’s Kit to create an LNS device plug-in and create
an installation project for your plug-in so that you can prov ide it to users.
To create a new plug-in, you need to first install the Microsoft .NET Framework Version 2.0
Redistributable Package. You then need to install the LNS Plug-in Framework Developer’s Kit and an
LNS Turbo plug-in director application such as the LonMaker Tool Turbo Edition (3.2 or later) if they
are not already installed on your computer. You need a director application to test your plug-in during
development.
After the required software is installed on your computer, you can begin creating your plug-in. To do
this, you create a new C# or VB.NET plug-in project with Microsoft Visual Studio 2005 (or later),
create the plug-in source files (for the plug-in server, plug-in object, and plug-in form derived classes),
and optionally implement command registration for the DeviceTemplate and LonMarkObject scoped
plug-in commands (note that this is not automatically implemented for you by the LNS Plug-in
Framework, version 1.1).
During the development of your plug-in, you can debug it by generating trace information and using
the OLE/COM ObjectViewer to display the registration information.
After you create your device plug-in, you can create an LNS p lug-in installer based on the framework
so that you can redistribute your plug-in.
Note: During development, you can also refer to the ACME plug-in example that is installed on your
computer by the LNS Plug-in Framework Developer’s Kit. The ACME plug-in example is located in
the LonWorks\ObjectServer\Examples\PluginFramework folder on your computer, and it is provided
in both C# and VB.NET programming languages. For more information on using the ACME C#
plug-in example to view the behavior of a plug-in, see Appendix F,
Plug-in.
Running the ACME Example C#
Installing the Developer’s Kit
The LNS Plug-in Framework Developer’s Kit is automatically installed by the NodeBuilder FX tool,
and it is also available as a single-executable installer that you can download from the Echelon Web
site. To install the developer’s kit, follow these steps:
1. Install the Microsoft .NET Framework Version 2.0 Redistributable Package (or newer) if it is not
already installed on your computer. The LNS Plug-in Framework and example plug-in will not
install or run properly unless the .NET 2.0 Framework (or newer) is installed on your computer.
Redistributing Your Plug-in later in this chapter for details. To check whether your computer
See
has this software and download it (if necessary), go to the Microsoft Windows Update Web page
http://update.microsoft.com.
at
2. Install the LNS director application that will be used for plug-in testing. If not already set, this
will set the root directory for the LNS components (for most Echelon products, this directory will
appear by default at [Windows System Drive]\LonWorks, and is known as the LonWorks
directory). It will also install the LNS runtime that is required to successfully run the ACME
example plug-in.
3. If you do not have the NodeBuilder FX tool installed on your computer, download the LNS
Plug-in Developer’s Kit from the Echelon Web site at
www.echelon.com/support/downloads, and then install it.
http://
4. After the LNS Plug-in Framework Developer’s Kit and other requirements have been installed
(either by installing the NodeBuilder FX tool, or downloading it from the Echelon and installing it
standlaone), the following folders will reside in the LonWorks directory on your computer.
• The ObjectServer folder is common to all computers with the LNS Server runtime installed.
• The Assemblies folder contains the .NET assemblies referenced by plug-ins that are built
using the framework. Visual Studio is informed of this directory by a registry entry added
during the installation. This makes the assembly information accessible to the development
environment. These assemblies are also installed directly into the Global Assembly Cache for
runtime support of framework-based plug-ins.
•The Apps folder is used by convention to redistribute LNS plug-ins. The sub-directory under
the Apps folder should give the plug-in manufacturer’s name (for example, this folder
contains an “ACME” subdirectory containing the provided example plug-in). Under the
manufacturer’s directory, there should be a directory specific to each individual plug-in
created by your company. For example, there is an Example folder under the
LonWorks\Apps\ACME directory rep resenting one plug-in created by the ACME company.
If the ACME company created another plug-in named “Example2”, it would be stored in an
Example2 folder under the LonWorks\Apps\ACME directory.
• The Examples folder contains example LNS applications.
• The Documentation folder contains a ReadMe file, a PDF of this manual, the LNS Plug-in
Framework Online Help, and a Visio drawing illustrating the plug-in instantiation models.
•The MergeModules folder contains merge modules for the two .NET assemblies referenced
by framework-driven plug-ins. These merge modules should be included in your installation
when you redistribute a plug-in developed with the Kit. See
Redistributing Your Plug-ins
later in this chapter for details.
•The ExampleCSPlugin folder and sub-directories contain source code and Visual Studio
2005 project files for the ACME Example C# Plug-in.
•The ExampleVBPlugin folder and sub-directories contain source code and Visual Studio
2005 project files for the ACME Example VB.NET Plug-in. This example was created by
translating the C# version of the example plug-in source code to the VB.NET language.
5. After the installation has successfully completed, an Echelon Plug-in Framework Developer’s
Kit program folder will appear in the Windows program folders. Shortcuts within this folder
provide access to the ReadMe file, a PDF of this manual, the LNS Plug-in Framework online help
file, the standalone example plug-in executable, and the C# and VB.NET examples.
Creating thePlug-in Project
You can create a C# or VB.NET plug-in project using Microsoft Visual Studio 2005 (or later)
following these steps (note that the example shown in this section is a C# plug-in project created with
Microsoft Visual Studio 2005 Professional Edition):
1. Create a new C# or Visual Basic Windows Application project. The project must create an EXE
target. Specify a name and location for your project. Click OK.
2. Click Project and then click your application’s Properties option. The Application tab opens.
3. Modify and confirm the following project properties:
•In the Default namespace property, change the namespace to
<YourCompany>.<YourProject>.
•In the Assembly name property, enter a unique and descriptive assembly name that matches
your selected namespace (for example, <YourCompany>.<YourProject>.<YourPlugin>).
• In the Output type property, verify that Windows Application is specified.
• In the Icon property under the Resources box, specify an icon.
4. Click Assembly Information. The Assembly Information dialog opens.
5. Enter the information describing your plug-in assembly, and then click OK to save the
information and return to the Application tab.
6. Click the Build Events tab.
7. Copy the PostBuild.bat file from the
LonWorks\ObjectServer\Examples\PluginFramework\ExampleCSPlugin to your project folder.
8. In the Post-build event command line property, enter the following line:
Call "$(ProjectDir)PostBuild.bat" "$(TargetP a th) "
The PostBuild.bat file will carry out the post-build actions necessary to register your plug-in
during the development process. Specifically, it generates a C OM Type Li brary and registers the
assembly for use with COM using RegAsm /tlb, and it registers the plug-in with LNS directors by
calling the plug-in with a /RegPlugin argument.
9. In the Run the post-build event property, select the When the build updates the project output
option.
10. Click the Debug tab.
11. In the Command line arguments property, enter -Embedding. This enables debugging of the
server.
12. Click Project and then click Add Reference. The Add Reference dialog opens.
13. Select the Echelon.LNS.Interop and the Echelon.LNS.Plugin.Framework .NET assemblies,
and then click OK.
• Echelon.LNS.Interop enables your application to interact with LNS.
• Echelon.LNS.Plugin.Framework provides the base functionality for your plug-in.
Creating the Plug-in Source Files
After you create your LNS plug-in project, you need to create the plug-in source files. To do this, you
create three classes: plug-in server, plug-in object, and plug-in form, which are to be derived from the
PluginServerBase, PluginObjectBase, and PluginFormBase base classes, respectively. After you
create these classes, you then modify them as described in the subsequent sections.
To create the plug-in server, plug-in object, and plug-in form classes, follow these steps:
1. In the Solution Explorer pane, delete the automatically generated Program and Form1 files.
2. Create the plug-in server class. To do this, follow these steps:
a. Click Project and then click Add Class. The Add New Item dialog opens.
b. In the Name property, enter <YourPlugin>Server, where YourPlugin is the name of your
plug-in, and then click Add.
3. Create the plug-in object class. To do this, follow these steps:
a. Click Project and then click Add Class. The Add New Item dialog opens.
b. In the Name property, enter <YourPlugin>Object, where YourPlugin is the name of your
plug-in, and then click Add.
4. Create the plug-in form class, which is a Windows Form item. To do this, follow these steps:
a. Click Project and then click Add Windows Form. The Add New Item dialog opens.
b. In the Name property, enter <YourPlugin>Form, where YourPlugin is the name of your
plug-in, and then click Add
The following subsections describe how to implement your plug-in server, plug-in object, and plug-in
form classes.
.
Loading...
+ 48 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.