mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-07 07:12:25 +01:00
Author:admin
Date:2008-09-25T16:19:15.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@44 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
@@ -17,11 +17,11 @@ The third tutorial describes how to access a COM component. It will build a clie
|
||||
|
||||
==First look at the generated code==
|
||||
At the end of the processing the '''EiffelStudio''' button becomes enabled. Click on it. This will automatically start EiffelStudio with the generated project so you can more easily navigate through the created Eiffel classes.
|
||||
{{note| '''Note''': When accessing a COM component the EiffelCOM Wizard will generate a precompiled library which includes all the generated classes. This allows for easy browsing of the generated classes, however a precompilation project is read-only, so you need to start another EiffelStudio to reuse the generated classes. The interesting classes are all related to the coclass proxy <eiffel>STRING_MANIPULATOR_PROXY</eiffel>. The proxy is the Eiffel class that gives access to the component. Each feature on the proxy calls the corresponding interface function on the component. You can use the EiffelStudio opened by the wizard to browse through the generated classes and study the class hierarchy.}}
|
||||
{{note|When accessing a COM component the EiffelCOM Wizard will generate a precompiled library which includes all the generated classes. This allows for easy browsing of the generated classes, however a precompilation project is read-only, so you need to start another EiffelStudio to reuse the generated classes. The interesting classes are all related to the coclass proxy <eiffel>STRING_MANIPULATOR_PROXY</eiffel>. The proxy is the Eiffel class that gives access to the component. Each feature on the proxy calls the corresponding interface function on the component. You can use the EiffelStudio opened by the wizard to browse through the generated classes and study the class hierarchy.}}
|
||||
|
||||
==Implementing a client==
|
||||
To implement a client of the <eiffel>StringManipulator</eiffel> component open a new EiffelStudio. Create the project in ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\client'' using the ecf file found in that directory. Freeze and run the project. You are now accessing the previously built component and calling functions on its interfaces! The class <eiffel>MY_STRING_MANIPULATOR</eiffel> inherits from the generated <eiffel>STRING_MANIPULATOR_PROXY</eiffel> and redefines the feature ''replace_substring_user_precondition''. The generated interfaces include contracts for each exposed function. You can redefine the ''user_precondition'' features to implement your own preconditions.
|
||||
{{note| '''Note''': If a COM component should be added to an existing client, the generated ecf file can be added as a library. }}
|
||||
{{note|If a COM component should be added to an existing client, the generated ecf file can be added as a library. }}
|
||||
|
||||
==Contracts==
|
||||
Contracts can be broken directly on the proxy in which case you will get a standard contract violation in the client. If contracts are broken on the server then the exception will be forwarded by the EiffelCOM runtime to the client. The feature replace_substring_user_precondition in <eiffel>MY_STRING_MANIPULATOR</eiffel> includes has some assertions.: Comment them out. Now the contract of the [[ref:libraries/base/reference/string_8_chart|<code>replace_substring </code>]] feature is wrong and erroneous calls can be made. Quick melt the changes and run the client. Enter some invalid numbers in the fields used to call this feature. After you click '''Replace''' you will see an error message box warning you that a precondition was violated on the server side. This demonstrates contracts `over the wire'. The precondition was violated in the server; this exception was caught by the EiffelCOM runtime and sent back to the client.
|
||||
|
||||
@@ -30,7 +30,7 @@ The generated Eiffel classes include:
|
||||
* <eiffel>ECOM_STRING_REGISTRATION</eiffel>: This class contains the code required to register the component.
|
||||
You do not need to modify or implement any classes. The wizard produces a ready-to-use component.
|
||||
|
||||
{{tip| '''Tip''': <br/>
|
||||
{{tip|<br/>
|
||||
In most Eiffel systems functionality is spread out throughout the system. No single class exposes the full functionality of the system and can serve as a Facade to the outside world. Running the wizard on any such class would not be practical. Before starting the wizard write an Eiffel class that acts as a Facade and forwards client calls to the appropriate subsystems. Enter the Facade class name into '''Name of Eiffel facade class''' field. The wizard generates an IDL file from this class. }}
|
||||
|
||||
{{seealso| '''See Also''' <br/>
|
||||
|
||||
@@ -9,7 +9,7 @@ If the project consists of adding a COM interface to an existing Eiffel project
|
||||
|
||||
If the project uses a COM definition file (either an IDL file or a type library), the EiffelCOM Wizard generates empty features in the classes corresponding to the component's coclasses. The implementation can then be added into these empty features.
|
||||
|
||||
{{warning| '''Warning''': Depending on the project settings, the EiffelCOM Wizard may overwrite the files containing the classes corresponding to the component's colasses if the project is re-generated thereby replacing the implemented features with empty ones. Make sure the destination folder is different from the folder where the classes have been implemented prior to re-generating the project. }}
|
||||
{{warning|Depending on the project settings, the EiffelCOM Wizard may overwrite the files containing the classes corresponding to the component's colasses if the project is re-generated thereby replacing the implemented features with empty ones. Make sure the destination folder is different from the folder where the classes have been implemented prior to re-generating the project. }}
|
||||
|
||||
Unlike the code generated to access an existing component, the code generated to implement a new COM component will differ for an in-process or an out-of-process component. The difference lies in the component activation code in the class <eiffel>ECOM_<Name_of_system>_REGISTRATION</eiffel>. If the component is in-process then this class includes the four functions that need to be exported from an in-process COM component ( <eiffel>DllRegisterServer</eiffel>, <eiffel>DllUnregisterServer</eiffel>, <eiffel>DllGetClassObject</eiffel>, and <eiffel>DllCanUnloadNow</eiffel>). If the component is out-of-process then the registration class includes a feature initializing the component and its graphical user interface.
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ Depending on the project settings there are between 2 and 6 major steps involved
|
||||
|
||||
Optionally, EiffelStudio can be opened on the generated system by clicking the corresponding button after the system has been compiled.
|
||||
|
||||
{{note| '''Note''': The EiffelStudio button will only be enabled if the Eiffel code was compiled. }}
|
||||
{{note|The EiffelStudio button will only be enabled if the Eiffel code was compiled. }}
|
||||
|
||||
{{seealso| '''See Also''': [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Reusing a COM Component|Accessing a COM Component]] , [[Building a COM Component|Building a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }}
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
[[Property:weight|-1]]
|
||||
[[Property:uuid|089e658f-4bd8-df8f-5647-0c176c00359b]]
|
||||
The Eiffel Codedom Provider Manager allows to graphically configure the Eiffel CodeDom Provider. There can be multiple configurations, each of them being associated with at least one application.
|
||||
{{note| '''Note:''' The Eiffel for ASP.NET installation program will add a shortcut in the start menu to the Eiffel CodeDom Provider Manager. }}
|
||||
{{note|The Eiffel for ASP.NET installation program will add a shortcut in the start menu to the Eiffel CodeDom Provider Manager. }}
|
||||
The main dialog of the Eiffel CodeDom Provider Manager is divided into two vertical panes. The left pane contains a list of available configurations while the right pane contains the settings corresponding to the currently selected configuration. Initially the only available configuration is the '''default''' configuration which applies to all applications. The configurable settings are listed below.
|
||||
==General Settings==
|
||||
* '''Fail on error''': Checking this box will force the Eiffel Codedom Provider to fail when an error occurs. By default the provider rescues the failure and logs an error but it might be easier for debugging to have the Eiffel CodeDom Provider stop and raise an exception.
|
||||
@@ -12,12 +12,12 @@ The main dialog of the Eiffel CodeDom Provider Manager is divided into two verti
|
||||
==Compiler Settings==
|
||||
* '''Default root class''': In the event where the CodeDom tree does not define an entry point, there still needs to be a root class for the Eiffel system to compile properly. If there is an entry point defined in the Codedom tree then this setting is ignored.
|
||||
* '''Precompile ace file''': This setting, if set, gives the path to the ACE file of the precompile that the CodeDom compiler should use when compiling systems with this configuration. The CodeDom compiler will first check whether the precompile for that ACE file already exists in the precompile cache (See Precompile cache below). If it finds one then it will check whether the ACE file was modified since the precompile was created. If there isn't a corresponding precompile or if the ACE file was modified then the CodeDom compiler will create a new precompile in the precompile cache using the specified ace file. It will then compile the system using the precompile in the cache corresponding to the specified ACE file.
|
||||
{{note| '''Note:''' If for any reason the precompilation fails then the CodeDom compiler will still compile the system but without using any precompile. }}
|
||||
{{note|If for any reason the precompilation fails then the CodeDom compiler will still compile the system but without using any precompile. }}
|
||||
|
||||
* '''Metadata cache''': Both the Eiffel CodeDom Provider and the Eiffel compiler require reading from and writing to an Eiffel Metadata Cache. These caches contain information about mapping the .NET types and members names to valid Eiffel identifiers. Because read and write access are required, the application that uses the CodeDom Provider must have write access rights to the Eiffel Metadata Cache folder.
|
||||
{{note| '''Note:''' The Eiffel for ASP.NET installation program will grant write access rights to the Eiffel Metadata Cache folder to the ASPNET user and IIS_WPG group if they exist. ASPNET is the default user account used by the ASP.NET process (aspnet_wp.exe) under Windows XP while IIS_WPG is the default user account used by the ASP.NET process (w3wp.exe) under Windows 2003 Server. }}
|
||||
{{note|The Eiffel for ASP.NET installation program will grant write access rights to the Eiffel Metadata Cache folder to the ASPNET user and IIS_WPG group if they exist. ASPNET is the default user account used by the ASP.NET process (aspnet_wp.exe) under Windows XP while IIS_WPG is the default user account used by the ASP.NET process (w3wp.exe) under Windows 2003 Server. }}
|
||||
|
||||
{{warning| '''Warning:''' Changing the Eiffel Metadata Cache folder path will force the Eiffel CodeDom Provider to regenerate the cache content during the next code generation or compilation. This process can take a long time and in particular can take more time than the default timeout for an ASP.NET page. If the Eiffel CodeDom Provider is used together with ASP.NET and if the Eiffel Metadata Cache path has been modified, it is recommended to change the default timeout for the first ASP.NET page containing Eiffel code to be loaded (this can be done by setting the ''HttpServerUtility.ScriptTimeout'' property). }}
|
||||
{{warning|Changing the Eiffel Metadata Cache folder path will force the Eiffel CodeDom Provider to regenerate the cache content during the next code generation or compilation. This process can take a long time and in particular can take more time than the default timeout for an ASP.NET page. If the Eiffel CodeDom Provider is used together with ASP.NET and if the Eiffel Metadata Cache path has been modified, it is recommended to change the default timeout for the first ASP.NET page containing Eiffel code to be loaded (this can be done by setting the ''HttpServerUtility.ScriptTimeout'' property). }}
|
||||
|
||||
* '''Compiler metadata cache''': This cache is used by the Eiffel Codedom Provider Compiler to map .NET types and members names to valid Eiffel identifiers. Please consult '''Metadata cache''' for additional information (the same note and warning apply).
|
||||
* '''Precompile cache''': If the configuration defines a precompile ace file then the Eiffel CodeDom Provider will create the precompile in the directory specified in this setting. Changing this value will force the Eiffel CodeDom Provider compiler to recreate the precompile in the new directory.
|
||||
@@ -26,7 +26,7 @@ The main dialog of the Eiffel CodeDom Provider Manager is divided into two verti
|
||||
This list associates .NET assemblies with the prefix that will be used for Eiffel class names corresponding to .NET types belonging to the assembly. For example the prefix for the assembly ''System.Xml.dll'' is ''XML_'', this means that the Eiffel class names of all the types in the assembly ''System.Xml.dll'' will all begin with ''XML_''. This is necessary because Eiffel doesn't have a notion of namespace. The default assembly prefixes cannot be modified but new assembly/prefix pairs can be added if necessary.
|
||||
==Applications==
|
||||
This last setting will only appear for configurations other than the default configuration. It lists the applications that will use the configuration when they load the Eiffel CodeDom Provider assembly. If an application is not listed in any configuration then it will use the default configuration.
|
||||
{{note| '''Note:''' For a change in an existing configuration to take effect, the process that uses the modified configuration must be restarted. }}
|
||||
{{note|For a change in an existing configuration to take effect, the process that uses the modified configuration must be restarted. }}
|
||||
|
||||
==New Configuration==
|
||||
New configurations may be created by clicking the ''New'' button or the ''New'' entry in the ''File'' menu. The New Configuration dialog box asks for the name and the path of the configuration. It will create a file with the extension '''.ecd''' ('''E'''iffel '''C'''ode'''D'''om) with the specified name in the directory located at the specified path. Whenever one of the applications listed at the bottom of the New Configuration dialog loads the Eiffel CodeDom Provider, it will use this new configuration.
|
||||
|
||||
@@ -3,9 +3,9 @@
|
||||
[[Property:uuid|82691c82-50a5-ed7f-b138-90946d094dae]]
|
||||
The Name Mapper utility allows retrieving the Eiffel identifier corresponding to a .NET type name or a .NET member name. There are only two input fields in the interface: the .NET type name should be entered in the first one while the .NET member name should be entered in the second one. Once a valid .NET type name is entered in the type name input field, the tool starts searching for the corresponding Eiffel identifier. When the Name Mapper finds the corresponding Eiffel identifier, it automatically fills the .NET member name input combo box with all the member names of the corresponding type. This means that the .NET member type name can be chosen from the combo box entries or typed in (if it's typed in then the tool will autocomplete the member name).
|
||||
The assemblies the tool will look into for the .NET type whose name was given in the .NET type name input field are listed below the input fields. It is possible to add new assemblies to the list by clicking the ''Add'' button. Assemblies that were added this way can be removed by clicking the ''Remove'' button after selecting the assembly from the list.
|
||||
{{note| '''Note:''' Assemblies that are listed by default cannot be removed. }}
|
||||
{{note|Assemblies that are listed by default cannot be removed. }}
|
||||
|
||||
{{note| '''Note:''' When adding an assembly and if the assembly has not been consumed (i.e. the XML names mapping files have not been generated in the Eiffel Metadata Cache) then the Name Mapper will consume the assembly, this may take a while. }}
|
||||
{{note|When adding an assembly and if the assembly has not been consumed (i.e. the XML names mapping files have not been generated in the Eiffel Metadata Cache) then the Name Mapper will consume the assembly, this may take a while. }}
|
||||
|
||||
|
||||
{{seealso| '''See also:''' [[Names Mappings|Names Mapping]] }}
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
The Eiffel Codedom Provider uses XML configuration files that define additional settings specific to Eiffel. Such settings include whether to fail on error, what events to log, where to log them etc... Each application can define its own configuration to be used when it loads the Eiffel CodeDom Provider. If an application is not associated with a configuration file then a default configuration is used.
|
||||
The association between applications and configurations as well as the actual settings the configuration defines can be set in the [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] . Run ''ecdpman.exe'' to start the manager.
|
||||
|
||||
{{note| '''Note:''' The Eiffel for ASP.NET installation program will add a shortcut in the start menu to the Eiffel CodeDom Provider Manager. }}
|
||||
{{note|The Eiffel for ASP.NET installation program will add a shortcut in the start menu to the Eiffel CodeDom Provider Manager. }}
|
||||
|
||||
{{seealso| '''See also:''' [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , [[Logging|Logging]] , [[Required Permissions|Required permissions]] }}
|
||||
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
There are a few topics specific to the implementation of the Eiffel CodeDom Provider that are worth mentioning.
|
||||
==Multiple Classes File==
|
||||
The Eiffel compiler expects that there is only one class per source file (file with extension '''.e'''), however the CodeDom interface specification requires multiple classes to be generated in the same file (actually in the same ''stream''). The Eiffel CodeDom Provider code generator generates files with the extension '''.es''' which may contain multiple class definitions. Each class definition is separated with a special marker that the Eiffel CodeDom Provider compiler will parse to create multiple '''.e''' files - each containing a single class definition - prior to calling the command line Eiffel compiler.
|
||||
{{note| '''Note:''' Only the Eiffel CodeDom Provider compiler knows how to handle '''.es''' files. The standard Eiffel compilers can only parse '''.e''' files. }}
|
||||
{{note|Only the Eiffel CodeDom Provider compiler knows how to handle '''.es''' files. The standard Eiffel compilers can only parse '''.e''' files. }}
|
||||
Eiffel for ASP.NET includes the [[eSplitter|eSplitter]] utility which can 'split' Eiffel multi-class files ('''.es''' files) into single class files ('''.e''' files).
|
||||
==Inheritance Snippet==
|
||||
Any type defined in a CodeDom tree to be consumed by the Eiffel CodeDom Provider may include one (and only one) snippet member that includes an inheritance clause declaration. This ''inheritance snippet'' must start with the keyword '''inherit''' and follows the Eiffel syntax for inheritance clauses. All the feature adaptations available in the Eiffel language may be used in such a snippet ('''rename''', '''export''', '''undefine''', '''redefine''', '''select''').
|
||||
{{note| '''Note:''' The CodeDom tree itself might define additional inheritance clauses in which case the Eiffel CodeDom Provider will merge the snippet and the implicit clauses in the generated source file. }}
|
||||
{{note|The CodeDom tree itself might define additional inheritance clauses in which case the Eiffel CodeDom Provider will merge the snippet and the implicit clauses in the generated source file. }}
|
||||
|
||||
==Indexing Snippet and Precompiled Libraries==
|
||||
Another interesting snippet member is the ''indexing clause snippet'' which must start with the '''indexing''' keyword and follows the Eiffel syntax for indexing clauses. This snippet may include the indexing clause '''precompile_definition_file''' which can be used to specify the path to the precompiled library ACE file to be used by the Eiffel CodeDom Compiler. This is specially useful in ASP.NET pages where each page can specify which precompiled ACE file to use when compiling it. This path will be used instead of the path defined in the [[Configuration|configuration file]] .
|
||||
{{note| '''Note:''' Only one class per compile unit should define a path to the precompiled library ACE file. If more than one class contain a '''precompile_definition_file''' indexing clause then there is no guarentee on which one the Eiffel CodeDom Compiler will use. }}
|
||||
{{note|Only one class per compile unit should define a path to the precompiled library ACE file. If more than one class contain a '''precompile_definition_file''' indexing clause then there is no guarentee on which one the Eiffel CodeDom Compiler will use. }}
|
||||
|
||||
==Eiffel Configuration==
|
||||
There are several Eiffel specific settings that can be set in the Eiffel CodeDom Provider which will affect the generated code as well as the CodeDom compiler behavior. These settings are covered in the [[Configuration|Configuration]] section.
|
||||
|
||||
@@ -8,7 +8,7 @@ For certain tools (including ASP.NET) to detect the availability of a CodeDom Pr
|
||||
Conversely, should the Eiffel Codedom Provider not be required anymore, running the following command line will remove it from the ''machine.config'' file:
|
||||
<code>InstallUtil /u EiffelSoftware.Codedom.dll</code>
|
||||
|
||||
{{note| '''Note''': The '''Eiffel for ASP.NET''' installation program will take care of registering and unregistering the Eiffel CodeDom Provider properly. }}
|
||||
{{note|The '''Eiffel for ASP.NET''' installation program will take care of registering and unregistering the Eiffel CodeDom Provider properly. }}
|
||||
|
||||
{{seealso| '''See also''': [[Supported Constructs|Supported constructs]] }}
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ Writing ASP.NET pages in Eiffel also requires to be familiar with the Eiffel lan
|
||||
|
||||
==Samples==
|
||||
The '''Samples''' folder of the Eiffel for ASP.NET delivery includes ASP.NET pages written in Eiffel. To run the samples you can either click on the corresponding link in the ''Start'' menu or open the page [http://localhost/EiffelSample http://localhost/EiffelSample] in your internet browser. Each sample comes with an extensively commented source code.
|
||||
{{note| '''Note''': The samples will only be available if IIS was installed prior to installing Eiffel for ASP.NET. }}
|
||||
{{note|The samples will only be available if IIS was installed prior to installing Eiffel for ASP.NET. }}
|
||||
|
||||
{{seealso| '''See also:''' [[Using Eiffel (to write ASP.NET pages)|Using Eiffel]] }}
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
[[Property:weight|4]]
|
||||
[[Property:uuid|fa212869-ffb0-0a6a-cbd0-7a184b11491d]]
|
||||
Maybe the most striking difference when writing pages in Eiffel comes from the name of the .NET types and methods. Because of different naming conventions, overloading and differences in identifier validity rules, .NET identifiers cannot be mapped directly to Eiffel identifiers. As a consequence, the Eiffel compiler creates XML mapping files in the ''Eiffel Metadata Cache''. These files are created only once for each referenced assembly.
|
||||
{{note| '''Note:''' The ASP.NET installation program pre-generates the Eiffel Metadata Cache for all assemblies required by ASP.NET by default. }}
|
||||
{{note|The ASP.NET installation program pre-generates the Eiffel Metadata Cache for all assemblies required by ASP.NET by default. }}
|
||||
The name mapping algorithm is quite complex but it is possible to guess the Eiffel identifier from the .NET identifier in most cases. The following simple steps can be followed to retrieve the Eiffel identifier corresponding to a .NET type:
|
||||
# Only the simple type name is used, the namespace isn't used by the Eiffel identifier:
|
||||
<code>System.Xml.NameTable -> NameTable</code>
|
||||
|
||||
@@ -176,7 +176,7 @@ end -- Class SOME_CLASS
|
||||
|
||||
When you write a feature in a class, you typically will include some of the following:
|
||||
* The feature's name
|
||||
{{note| '''Note:''' In Eiffel every feature of a class must have a name that is unique within that class. }}
|
||||
{{note|In Eiffel every feature of a class must have a name that is unique within that class. }}
|
||||
|
||||
* The feature's type (in the case of an attribute or a function)
|
||||
* The feature's formal argument list (in the case of a function or procedure that has arguments)
|
||||
@@ -275,7 +275,7 @@ The precondition part of a feature is introduced by the keyword " <code> require
|
||||
|
||||
This part contains the declarations for any "local entities" used by the feature. Sometimes the computation accomplished in a feature requires the use of entities which are only temporary. It would not be appropriate to make these attributes of the class. So, instead we can use local entities, which have scope only within the feature in which they are declared. In the example, <code> hd_item </code> is available as type <code> WEL_HD_ITEM </code> during the computation of feature <code> insert_text_header_item </code>.
|
||||
|
||||
{{note| '''Note:''' A local entity name must not be the same as any feature of the class in which its feature occurs or the same as any argument name of the feature in which it occurs. }}
|
||||
{{note|A local entity name must not be the same as any feature of the class in which its feature occurs or the same as any argument name of the feature in which it occurs. }}
|
||||
|
||||
===Routine Body===
|
||||
<code>
|
||||
@@ -303,7 +303,7 @@ There are other forms that a routine body can take. Here are some examples of so
|
||||
|
||||
The routine body above is for an "external" routine. External routines are used to represent within Eiffel classes, routines that are written in other languages.
|
||||
|
||||
{{tip| '''Tip:''' Because of the high degree of language interaction provided by Microsoft.NET, it is not necessary in Eiffel for.NET to use externals to use software components from.NET assemblies. Instead, these components are presented to the Eiffel programmer as if they were Eiffel classes. Read more about this in [[Conventions|Conventions]] . }}
|
||||
{{tip|Because of the high degree of language interaction provided by Microsoft.NET, it is not necessary in Eiffel for.NET to use externals to use software components from.NET assemblies. Instead, these components are presented to the Eiffel programmer as if they were Eiffel classes. Read more about this in [[Conventions|Conventions]] . }}
|
||||
|
||||
====Once Routines====
|
||||
<code>
|
||||
|
||||
@@ -209,7 +209,7 @@ You may declare multiple <code> feature </code> statements. This helps you group
|
||||
|
||||
Although the words " <code> Initialization </code>" and " <code> Access </code>" are actually in comments after the <code> feature </code> keyword, some language processing tools apply some significance to these, for example, ordering the groups in "pretty-printed" views of a class. Also, some tools allow you to build templates for creating new classes which have <code> feature </code> clauses already in place for predetermined groups.
|
||||
|
||||
{{tip| '''Tip:''' There is not a technical requirement governing the grouping or ordering of features in a class. It is the option of the producer of a class to group and order the features in some fashion that has some meaning. Many years of Eiffel development experience are reflected in the classes in the Eiffel Base Library. This is a good place to look for examples of well constructed classes. }}
|
||||
{{tip|There is not a technical requirement governing the grouping or ordering of features in a class. It is the option of the producer of a class to group and order the features in some fashion that has some meaning. Many years of Eiffel development experience are reflected in the classes in the Eiffel Base Library. This is a good place to look for examples of well constructed classes. }}
|
||||
|
||||
|
||||
===Invariant===
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
[[Property:uuid|1e19c2f0-995e-02c1-0588-c134a11e0003]]
|
||||
As of EiffelEnvision 2.6, Eiffel for ASP.NET 5.6 and EiffelStudio 5.7; Eiffel for .NET introduces the notion of '''Eiffel-Compliance'''. .NET specifies a number of language interopability rules in a [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp Common Language Specification-Compliance] specification. Eiffel for .NET supports all CLS-Compliant type and features in .NET but now additionally supports a number of non-CLS-compliant types and features. This is the purpose of the Eiffel-Compliant notion.
|
||||
|
||||
{{note| '''Note''': The information contained within this page does not go into any depth on the Common Language Specification (CLS) or CLS-Compliance. For this information please see Microsoft's on-line documentation [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp What is the Common Language Specification?] }}
|
||||
{{note|The information contained within this page does not go into any depth on the Common Language Specification (CLS) or CLS-Compliance. For this information please see Microsoft's on-line documentation [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp What is the Common Language Specification?] }}
|
||||
<span id="applicablity"></span>
|
||||
==Applicability==
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ on_paint (paint_dc: WEL_PAINT_DC; invalid_rect: WEL_RECT) is
|
||||
end
|
||||
</code>
|
||||
|
||||
{{note| '''Note:''' If you look at MAIN_WINDOW, you will see that it contains many features. However, nearly all of these are features are inherited from WEL_FRAME_WINDOW. }}
|
||||
{{note|If you look at MAIN_WINDOW, you will see that it contains many features. However, nearly all of these are features are inherited from WEL_FRAME_WINDOW. }}
|
||||
|
||||
This sample contains the following classes:
|
||||
* HELLO_DEMO
|
||||
|
||||
@@ -19,7 +19,7 @@ This sample shows you how to set up your first [[ref:/libraries/wel/reference/we
|
||||
|
||||
After you launch the sample, You should see the window displayed in the screen as illustrated above. You will have full control over the window, and the program will quit when you close the window.
|
||||
|
||||
{{note| '''Note:''' The size and shape of the window may be different on your machine. }}
|
||||
{{note|The size and shape of the window may be different on your machine. }}
|
||||
|
||||
==Under the Hood==
|
||||
|
||||
|
||||
Reference in New Issue
Block a user