diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki index 27a00816..42995172 100644 --- a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki +++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki @@ -18,12 +18,12 @@ This first tutorial describes creating a COM component from a COM definition fil ==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. You can save the processing output by clicking the '''Save''' button. +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 navigate more easily through the created Eiffel classes. You can save the processing output by clicking the '''Save''' button. The deferred class STRING_MANIPULATOR_COCLASS represents the component and exposes all its functionality. It inherits from ISTRING_INTERFACE which corresponds to the '''IString''' interface and has one heir STRING_MANIPULATOR_COCLASS_IMP which implements all the deferred features. The default implementation in the heir is empty. ==Implementing the component== -To do something more interesting than merely returning an error to the client edit the implementation of the STRING_MANIPULATOR_COCLASS_IMP class. There is an implementation of the class in ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\server''\. Copy this file over to ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component\server\component'' and freeze the project. Voila!, you have your first EiffelCOM component up and running. +To do something more interesting than merely returning an error to the client, edit the implementation of the STRING_MANIPULATOR_COCLASS_IMP class. There is an implementation of the class in ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\server''\. Copy this file over to ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component\server\component'' and freeze the project. Voila!, you have your first EiffelCOM component up and running. ==Running the component== The component needs to be registered prior to being loaded. Register an out-of-process component using the following syntax: diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki index 8485ac87..48659d0b 100644 --- a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki +++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki @@ -7,9 +7,9 @@ Also, you'll find out how .NET types sometimes look a little different in the pr Because there are differences in the underlying object models upon which .NET and Eiffel have been designed, before .NET types can be made available to Eiffel developers, the assemblies in which they reside must be processed by a utility called the Eiffel Metadata Consumer. Fortunately, this all happens behind the scenes for you. You need only be aware that when you are looking at .NET types from within EiffelEnvision, you're seeing them through Eiffel-tinted lenses. -This is really the same thing that happens with other .NET languages with Visual Studio .NET support. For example, if you look at a constructor in a .NET type using the "ildasm" utility, the constructor will be named .ctor . But, if you're in C# and look at the same constructor in the Visual Studio .NET Object Browser, the constructor will have the same name as the type ...it's a C# convention. Likewise, the same constructor viewed in Visual Basic .NET will have the name New ...that's the Visual Basic .NET convention. So, when you use EiffelEnvision, you see things as presented using Eiffel Conventions. +This is really the same thing that happens with other .NET languages with Visual Studio .NET support. For example, if you look at a constructor in a .NET type using the "ildasm" utility, the constructor will be named ".ctor". But, if you're in C# and look at the same constructor in the Visual Studio .NET Object Browser, the constructor will have the same name as the type ...it's a C# convention. Likewise, the same constructor viewed in Visual Basic .NET will have the name New ...that's the Visual Basic .NET convention. So, when you use EiffelEnvision, you see things as presented using Eiffel Conventions. -Consider what happens when you look at .NET types using EiffelEnvision. When you look, for example at the type System. EventArgs, you will see it represented as an Eiffel class called EVENT_ARGS. The members of the .NET type will show up as features of the Eiffel class. Of course, you can also see the corresponding .NET names as they exist in the assembly metadata. +Consider what happens when you look at .NET types using EiffelEnvision. When you look, for example at the type System.EventArgs, you will see it represented as an Eiffel class called EVENT_ARGS. The members of the .NET type will show up as features of the Eiffel class. Of course, you can also see the corresponding .NET names as they exist in the assembly metadata. The documents in this section tell you what you need to know in order to use .NET types in Eiffel, and vice versa.