Author:halw

Date:2009-01-05T19:34:30.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@152 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-01-05 19:34:30 +00:00
parent ffc468f138
commit 2fa0e9a0ae
7 changed files with 140 additions and 131 deletions

View File

@@ -24,7 +24,7 @@ end
In practice, however, the Eiffel style rules suggest a better documented version: In practice, however, the Eiffel style rules suggest a better documented version:
<code> <code>
indexing note
description: "Root for trivial system printing a message" description: "Root for trivial system printing a message"
author: "Elizabeth W. Brown" author: "Elizabeth W. Brown"
@@ -50,7 +50,7 @@ The two versions perform identically; the following comments will cover the more
Note the absence of semicolons and other syntactic clatter or clutter. You may in fact use semicolons to separate instructions and declarations. But the language's syntax is designed to make the semicolon optional (regardless of text layout) and it's best for readability to omit it, except in the special case of successive elements on a single line. Note the absence of semicolons and other syntactic clatter or clutter. You may in fact use semicolons to separate instructions and declarations. But the language's syntax is designed to make the semicolon optional (regardless of text layout) and it's best for readability to omit it, except in the special case of successive elements on a single line.
The <code>indexing</code> clause does not affect execution semantics; you may use it to associate documentation with the class, so that browsers and other indexing and retrieval tools can help users in search of reusable components satisfying certain properties. Here we see two indexing entries, labeled <code>description</code> and <code>author</code>. The <code>note</code> clause does not affect execution semantics; you may use it to associate documentation with the class, so that browsers and other indexing and retrieval tools can help users in search of reusable components satisfying certain properties. Here we see two notes, labeled <code>description</code> and <code>author</code>.
The name of the class is <code>HELLO</code>. Any class may contain "features"; <code>HELLO </code>has just one, called <code>make</code>. The <code>create</code> clause indicates that <code>make</code> is a "creation procedure", that is to say an operation to be executed at class instantiation time. The class could have any number of creation procedures. The name of the class is <code>HELLO</code>. Any class may contain "features"; <code>HELLO </code>has just one, called <code>make</code>. The <code>create</code> clause indicates that <code>make</code> is a "creation procedure", that is to say an operation to be executed at class instantiation time. The class could have any number of creation procedures.

View File

@@ -43,7 +43,7 @@ The class also has several features that help analyzing exceptions and error cod
Every call to COM should be wrapped into a <code> rescue </code> clause as follows: Every call to COM should be wrapped into a <code> rescue </code> clause as follows:
<code> <code>
some_feature is some_feature
local local
retried: BOOLEAN retried: BOOLEAN
... ...
@@ -98,11 +98,12 @@ class
inherit inherit
APPLICATION_PROXY APPLICATION_PROXY
ECOM_VARIANT_ACCESS ECOM_VARIANT_ACCESS
feature feature
add_workbook is add_workbook
local local
workbook: WORKBOOK_PROXY workbook: WORKBOOK_PROXY
do do

View File

@@ -27,7 +27,7 @@ This feature is a <code>once</code> function that can return the class correspon
The COM standard specifies that each COM routine should return a status code to the client. The status code is encoded in a <eiffel>HRESULT</eiffel> value. Such behavior goes against the Command Query Separation Principle in Eiffel. The EiffelCOM generated system should use exceptions instead of returning <eiffel>HRESULT</eiffel> values to the client. By default the EiffelCOM runtime will always return <eiffel>S_OK</eiffel> meaning that the routine succeeded. To notify the client of a problem (e.g. invalid argument value), the EiffelCOM component should raise the corresponding exception from class <eiffel>ECOM_EXCEPTION</eiffel> using the feature <eiffel>trigger</eiffel> from the same class. The EiffelCOM runtime will catch the exception and send the corresponding <eiffel>HRESULT</eiffel> back to the client. Here is what the Eiffel code for a COM component should look like: The COM standard specifies that each COM routine should return a status code to the client. The status code is encoded in a <eiffel>HRESULT</eiffel> value. Such behavior goes against the Command Query Separation Principle in Eiffel. The EiffelCOM generated system should use exceptions instead of returning <eiffel>HRESULT</eiffel> values to the client. By default the EiffelCOM runtime will always return <eiffel>S_OK</eiffel> meaning that the routine succeeded. To notify the client of a problem (e.g. invalid argument value), the EiffelCOM component should raise the corresponding exception from class <eiffel>ECOM_EXCEPTION</eiffel> using the feature <eiffel>trigger</eiffel> from the same class. The EiffelCOM runtime will catch the exception and send the corresponding <eiffel>HRESULT</eiffel> back to the client. Here is what the Eiffel code for a COM component should look like:
<code> <code>
indexing note
description: "Eiffel coclass server example" description: "Eiffel coclass server example"
class class
ECOM_SERVER_COCLASS_IMP ECOM_SERVER_COCLASS_IMP
@@ -42,7 +42,7 @@ inherit
feature -- Basic Operations feature -- Basic Operations
coclass_feature (an_argument: ARGUMENT_TYPE) is coclass_feature (an_argument: ARGUMENT_TYPE)
-- Example of a coclass feature -- Example of a coclass feature
do do
if not is_valid (an_argument) then if not is_valid (an_argument) then
@@ -54,7 +54,7 @@ feature -- Basic Operations
feature {NONE} -- Implementation feature {NONE} -- Implementation
is_valid (an_argument: ARGUMENT_TYPE): BOOLEAN is is_valid (an_argument: ARGUMENT_TYPE): BOOLEAN
-- Is an_argument a valid argument? -- Is an_argument a valid argument?
do do
-- Test of validity of an_argument -- Test of validity of an_argument

View File

@@ -27,7 +27,7 @@ where <eiffel>ISOMETHING_INTERFACE</eiffel> is a generated deferred class corres
All the Eiffel classes corresponding to the component's interfaces are generated in '''Common\Interfaces'''. These deferred classes include one deferred feature per function defined on the interface. They are equipped with automatically generated assertions. However, the wizard cannot generate fully specified contracts since it has no domain specific knowledge. It can only generate contracts that are domain independent. Such contracts, although useful, are not enough to describe entirely the behavior of the component. Generated contracts include checking for <eiffel>Void</eiffel> Eiffel objects as well as <code>null</code> C pointers for wrappers. There might be a need for additional assertions. Invariants and postconditions can be added in an heir of the generated Eiffel coclass proxy. Preconditions, however, cannot be strengthened. A workaround provided by the wizard consists of generating a precondition function for each feature in the interface. The default implementation of these functions always returns <eiffel>True</eiffel>. They can be redefined to implement the correct behavior: All the Eiffel classes corresponding to the component's interfaces are generated in '''Common\Interfaces'''. These deferred classes include one deferred feature per function defined on the interface. They are equipped with automatically generated assertions. However, the wizard cannot generate fully specified contracts since it has no domain specific knowledge. It can only generate contracts that are domain independent. Such contracts, although useful, are not enough to describe entirely the behavior of the component. Generated contracts include checking for <eiffel>Void</eiffel> Eiffel objects as well as <code>null</code> C pointers for wrappers. There might be a need for additional assertions. Invariants and postconditions can be added in an heir of the generated Eiffel coclass proxy. Preconditions, however, cannot be strengthened. A workaround provided by the wizard consists of generating a precondition function for each feature in the interface. The default implementation of these functions always returns <eiffel>True</eiffel>. They can be redefined to implement the correct behavior:
<code> <code>
function (a: INTEGER): MY_STRUCT is function (a: INTEGER): MY_STRUCT
-- Example of a generated Eiffel coclass feature -- Example of a generated Eiffel coclass feature
require require
function_user_precondition: function_user_precondition function_user_precondition: function_user_precondition
@@ -47,7 +47,7 @@ As a result, any feature in the client making calls to the Eiffel classes corres
The following code snippet illustrates how a client can process exceptions raised by a call to an Eiffel class representing a component's coclass: The following code snippet illustrates how a client can process exceptions raised by a call to an Eiffel class representing a component's coclass:
<code> <code>
indexing note
description: "Eiffel coclass client example" description: "Eiffel coclass client example"
class class
@@ -61,7 +61,7 @@ inherit
feature -- Basic Operations feature -- Basic Operations
coclass_feature_client is coclass_feature_client
-- Example of a coclass feature caller -- Example of a coclass feature caller
local local
retried: BOOLEAN retried: BOOLEAN

View File

@@ -2,22 +2,30 @@
[[Property:weight|1]] [[Property:weight|1]]
[[Property:uuid|5990eda2-2eac-6a40-8e99-5a0c5e9fc15f]] [[Property:uuid|5990eda2-2eac-6a40-8e99-5a0c5e9fc15f]]
1 - Launch the Resource Bench application. This small dialog box will appear for the initialization process: 1 - Launch the Resource Bench application. This small dialog box will appear for the initialization process:
[[Image:retriev]]
Then you get the main window of Resource Bench:
[[Image:rb]]
[[Image:retriev]]
Then you get the main window of Resource Bench:
[[Image:rb]]
2 - Open a resource file (why not the example.rc file provided with this release of Resource Bench). Let the application parse the file. You will see a dialog box that informs you of the parsings state. <br/> 2 - Open a resource file (why not the example.rc file provided with this release of Resource Bench). Let the application parse the file. You will see a dialog box that informs you of the parsings state. <br/>
First, there is the preprocessing of the resource file: First, there is the preprocessing of the resource file:
[[Image:prepro]] [[Image:prepro]]
Then you have the analysis phase: Then you have the analysis phase:
[[Image:analyz]] [[Image:analyz]]
3 - After these two steps you will see a hierarchical view of the resource file that show you what resource's type are included in the resource file (Below the result of the "example.rc" file). 3 - After these two steps you will see a hierarchical view of the resource file that show you what resource's type are included in the resource file (Below the result of the "example.rc" file).
[[Image:collaps]] [[Image:collaps]]
You can expand the tree view to see associated resources for each resource's type. You can expand the tree view to see associated resources for each resource's type.
[[Image:expand]] [[Image:expand]]
At this point you are able to: At this point you are able to:
* Select some properties for the Eiffel code generation * Select some properties for the Eiffel code generation
* Save a project file * Save a project file
@@ -28,8 +36,8 @@ At this point you are able to:
4 - To save a project file, click on the save button of the toolbar or select the save item in the file menu. A standard save dialog box will appear in which you can specify the file name of your project. The file's extension for a Resource Bench project is "*.prb" 4 - To save a project file, click on the save button of the toolbar or select the save item in the file menu. A standard save dialog box will appear in which you can specify the file name of your project. The file's extension for a Resource Bench project is "*.prb"
5 - To generate Eiffel Code, select the "Generate Eiffel Code..." item in the Build menu, this dialog box will appear to ask you in which directory Resource Bench must save the Eiffel classes: 5 - To generate Eiffel Code, select the "Generate Eiffel Code..." item in the Build menu, this dialog box will appear to ask you in which directory Resource Bench must save the Eiffel classes:
[[Image:browse]]
[[Image:browse]]
6 - To generate a resource file, select the "Generate Resource file..." item in the Build menu, a standard save dialog box will appear to save the file. 6 - To generate a resource file, select the "Generate Resource file..." item in the Build menu, a standard save dialog box will appear to save the file.

View File

@@ -28,7 +28,7 @@ inherit
active_medium active_medium
end end
creation create
make make
feature feature
@@ -73,7 +73,7 @@ inherit
BASIC_ROUTINES BASIC_ROUTINES
creation create
make make
feature feature
@@ -114,7 +114,7 @@ class
POLLING_SERVER POLLING_SERVER
creation create
make make
feature feature
@@ -150,7 +150,7 @@ The client follows the same scheme, reversing the order of read and write operat
class class
POLLING_CLIENT POLLING_CLIENT
creation create
make make
feature feature