[Go] Explain the ins and outs of C # component development

C # Component development begins with understanding the capabilities of components and why components exist. In Visual Studio. NET environment, there will be new forms of C # component development.

Features of the component

Microsoft's forthcoming release of Visual Studio. NET will enable program developers to gain an integrated development environment that provides a rich set of tools for developing traditional, C + + applications, as well as exciting Microsoft. NET components. These components, written in administrative code and built at the common language runtime, provide developers with a new hybrid development environment that is as easy as Microsoft Visual Basic, while providing powerful low-level programming capabilities that are more relevant to ATL or MFC. With the advent of a productivity-centric management environment, it can work well with traditional COM components. Developers can spend more time building large components without worrying about memory leaks, security, and header files.

In addition to providing the development of Microsoft. NET Framework components, Visual Studio.NET (VS. NET) has a number of tools that allow components to leverage the advantages of the designer architecture in vs. NET to design the components that are included with vs. NET in appearance and performance. Similar products. When developing a management component, all the attributes obtained in the Vs.net designer use the. NET Framework of the component itself, resulting in tight integration between design-time and run-time components.

What is a component?

It is clear that Microsoft. NET Framework components are easy to write. Let them with visual Studio. NET designers work together, the only requirement is that they implement System.ComponentModel.IComponent, which usually indicates the default application that inherits from IComponent. IComponent enables a component to track design-time information, such as its container component or name, or to access the services provided by the designer.

Let's write a simple C # component development, which has the following form:

 Public Partial classbooltracker:component {Private BOOLState ; PrivateEventHandler Handler; Private Static ObjectEventvaluechanged =New Object();  PublicBooltracker () {InitializeComponent (); }         Publicbooltracker (IContainer container) {container. ADD ( This);        InitializeComponent (); } Public BOOLValue {Get            {                returnState ; }            Set            {                if( This. state! =value) {                     This. State =value; OnValueChanged (NewEventArgs ()); }            }        }         Public voidaddonvaluechanged (EventHandler h) {handler=(EventHandler) Delegate.combine (Handler, h); }        protected Virtual voidonvaluechanged (EventArgs e) {if(Handler! =NULL) {Handler ( This, E); }        }         Public voidremoveonvaluechanged (EventHandler h) {handler=(EventHandler) Delegate.remove (Handler, h); }    }

Obviously, this component does not function, but it is placed in the Visual Studio.netwin form Designer or Component Designer, you can see from the property browser that it has a name, there is also a property called "value", use the drop-down arrow to set the value to TRUE or FALSE, Event onvaluechanged can be triggered when the value is toggled between True and False.

For the designer, the component is just half of what we want to say, and the most important part is the property, which makes up the metadata, which is information about classes, properties, events, and so on. Let's take the Value property as an example. As an attribute, there is already metadata associated with it, such as the type (Boolean), the behavior (read/write), or the name ("Value"). Use reflection to retrieve basic metadata, that is, the common language runtime allows users to check the type, base type, properties, methods, constructors, fields, and access levels of an object at run time. All of this information is considered meta data.

Customizing meta-data

Custom metadata includes any segment of information (field, property, or method) that can be added to a class or class member, in fact the type itself is recognized by a particular customer. For Visual Studio. NET Designer, custom metadata forms the basis for all extensibility. All metadata attributes that are understood by the VS. NET Designer are based on a class that is System.ComponentModel.Member attribute. It provides a basic class, so the properties that the developer cares about can be quickly identified by their type.

This concept can be more easily understood through a typical example. For example, we do not want the Value property to be displayed in the property browser. We can add a metadata property System.ComponentModel.BrowsableAttribute to control whether a property can be browsed.

[Browsable (false)]         Public BOOLValue {Get            {                returnState ; }            Set            {                if( This. state! =value) {                     This. State =value; OnValueChanged (NewEventArgs ()); }            }        }

When you specify a property, you can indent "BrowsableAttribute" slightly "browsable". The word "Attribute" is added to us by the C # compiler. The only limitation is that if a property value is specified, it must match the property type of the constructor, and the value must be a constant. In this example, BrowsableAttribute has a single Boolean parameter "browsable" of the constructor, the compiler binds this metadata property to the constructor and creates an instance of the attribute class. If the property class browser obtains this object, it enumerates the properties of the object and ignores the "browsable" property because it is labeled with this property. Therefore, it appears that the object has no attributes. BrowsableAttribute can also be applied to events.

The Microsoft. NET Framework has a rich set of properties to control how the designer uses components. Here is a list of some of the useful properties that will make you more aware of the meaning in later reading:

The property name indicates whether the BrowsableAttribute control property or event is displayed in the property browser. Bindableattribute determines whether the property is suitable for binding to the data binder. CategoryAttribute Specifies the categories that properties should be grouped in the property browser ("Appearance", "Layout", "Behavior", "Misc", and so on). Defaulteventattribute/defaultpropertyattribute the default event or property of the specified object. HelpAttribute the Help files and topics that specify properties or events. LicenseProviderAttribute points to the LicenseProvider that provides the license information for the component. Mergablepropertyattribute allows or blocks the inclusion of a property in the property browser when multiple components are browsed and selected. Persistableattribute determines whether the property value should be consistent with the code when generating code in a visual designer such as Win Forms Designer or ComponentDesigner. Persistcontentsattribute Determines whether code generation should revert to the object's non-numeric type properties and whether the code is kept consistent with the property values. The ICollection attribute type is a typical example of this application. Showintoolboxattribute Determines whether this component is allowed to be used in a tool box. TOOLBOXITEMATTRIUBTE Specifies the type of toolboxitem that should be used when creating a class from a tool box.

Citation connection: the ins and outs of C # component development

[Go] Explain the ins and outs of C # component development