diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki
new file mode 100644
index 00000000..4118ac0a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/compiling-and-executing-system.wiki
@@ -0,0 +1,52 @@
+[[Property:title|4 COMPILING AND EXECUTING A SYSTEM]]
+[[Property:link_title|Compiling and Executing a System]]
+[[Property:weight|-12]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+EiffelStudio first comes up with a window and a dialog on top of it; the dialog looks like this (from here on the look-and-feel will be different on non-Windows platform, but the contents will be the same):
+ [[Image:index-2]] [[general/guided_tour/studio/index-2.png|(link)]]
+As this is our first project we want to Add Project. We could also
+* " Create project ", which would let you select one among the common schemes -- basic application, graphical Windows application, graphical multi-platform application, Microsoft .NET application -- and set up everything for you.
+* " Open project ", which would let you open a previously added project..
+
+In future sessions you'll probably use the first option for a new project, as it takes care of generating everything for you, and the second option for an existing project.
+
+Right now you first have to add the project, so click on Add Project. This brings up a File Explorer inviting you to select an ECF file. The file you want is
+
+ $ISE_EIFFEL\examples\studio\tour\simple.ecf
+
+
+remember that $ISE_EIFFEL stands for the location of the Eiffel installation, such as C:\Eiffel50 ; ECF files are normally marked by the .ecf file extension).
+
+Use the File Explorer to go to the directory $ISE_EIFFEL/examples/studio/tour/ and select the appropriate file. You will then be back on the startup dialog.
+ [[Image:index-3]] [[general/guided_tour/studio/index-3.png|(link)]]
+Click Open to confirm. This starts compilation of your project.
+
+During Eiffel compilation, a progress bar displays the successive compilation steps, or "degrees". The bulk of our little project is the EiffelBase library, which the EiffelStudio installation procedure has precompiled; so just now there's only a few extra classes to compile, and the process is almost instantaneous on a state-of-the-art computer. Even if you had to compile the EiffelBase classes, EiffelStudio compilation is so fast that you would hardly have the time to read the "degree" messages; you can see them later in compilations of bigger classes and systems.
+
+{{note| ''On an IBM Thinkpad, Pentium III 850 MHz, 256 MB, running Windows 2000 Professional, Eiffel compilation takes about 9 seconds for the entire Guided Tour system including non-precompiled EiffelBase. '' }}
+
+After Eiffel compilation completes you will see the message
+ Eiffel Compilation Succeeded
+
+At this stage your project is finished compiled and you can start using EiffelStudio.
+
+Congratulations! You have successfully compiled your first Eiffel project. More precisely it's been both "melted". Strange terminology, you may think; in a little while we'll see why these compilation steps are called that way.
+
+==Executing the system==
+
+The system doesn't do anything exciting, but let's execute it anyway. Find the execution icon ("Run with breakpoints") at the top of the EiffelStudio window.
+
+It would be OK too to use the neighboring icon to the left, "Run without breakpoints", since we haven't set any breakpoints. Click either icon to execute the system.
+
+This little application doesn't use graphics or anything fancy but simply creates some objects and displays some information. Output done using the default Eiffel I/O (from the EiffelBase classes ANY and STANDARD_FILES ) goes to a console. On Unix/Linux and VMS it's the window from which you started EiffelStudio. On Windows it's by default a new console window that comes up when and if the system does its first output operation, and stays up:
+ [[Image:index-6]] [[general/guided_tour/studio/index-6.png|(link)]]
+The message " Press Return to finish the execution " would not appear if you executed the system from outside of EiffelStudio, for example from a command line. Its purpose within EiffelStudio is clear: to let you see the console output; without it, the console would go away at the end of execution. (None of this applies to Unix/Linux/VMS since there is no new console window to get rid of.)
+
+If before closing the console window you look at the main EiffelStudio window (by moving away the console window) you will notice that it looks different from before, since it now shows the fields useful in monitoring execution and debugging. But we'll look at this later. For the moment just dismiss the console by following the advice to " Press Return ": hit the Return or Enter key.
+
+[[2 COPYING THE EXAMPLE FILES|<< Previous]] [[5 A LOOK AT THE PROJECT DIRECTORY|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/copying-example-files.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/copying-example-files.wiki
new file mode 100644
index 00000000..1198045f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/copying-example-files.wiki
@@ -0,0 +1,29 @@
+[[Property:title|2 COPYING THE EXAMPLE FILES]]
+[[Property:link_title|Copying the Example Files]]
+[[Property:weight|-14]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+{{note|If you are using Eiffel on a personal computer under Windows, you can work directly on the installation directory and don't need to make copies of files as per the present section. Skip directly to the next section, 3. Do read the present section and apply its instructions if you work under Unix, or may have to share the Eiffel installation with other users, do not have write permissions on the installation, or want to keep the installation unchanged.}}
+
+If you are going to work on a copy, choose or create a directory of your own; let's call it YOURDIR for the rest of the discussion.
+
+To copy all the files of the example to YOURDIR :
+* On Windows, open a Windows Explorer, go to $ISE_EIFFEL\examples\studio\tour , select all the files in that directory, and drag-and-drop them to YOURDIR .
+* On Unix execute the shell command
+ cp $ISE_EIFFEL/examples/studio/tour/* YOURDIR
+
+* On VMS execute the command
+ copy $ISE_EIFFEL:[examples.studio.tour]*.* YOURDIR
+
+
+Once you have compiled the example under EiffelStudio, relying on the precompiled EiffelBase library (the default), and without optimization, the contents of YOURDIR will take up less than one megabyte, including information on diagrams and metrics.
+
+The final executable generated through " ''finalization''" (optimized compilation) will take only about 300 kilobytes.
+
+Without precompiled EiffelBase you would need about 3.5 megabytes, plus about 25 megabytes of generated C code and auxiliary files. The executable in that case will take up about 250 kilobytes.
+
+[[1 OVERVIEW AND PREREQUISITES|<< Previous]] [[3 STARTING EIFFELSTUDIO AND OPENING A PROJECT|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/how-eiffelstudio-compiles.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/how-eiffelstudio-compiles.wiki
new file mode 100644
index 00000000..ed78efc1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/how-eiffelstudio-compiles.wiki
@@ -0,0 +1,190 @@
+[[Property:title|16 HOW EIFFELSTUDIO COMPILES]]
+[[Property:link_title|How EiffelStudio Compiles]]
+[[Property:weight|3]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+So far we have relied on the compiling capabilities of EiffelStudio without exploring them in any detail. We must now understand the principles behind EiffelStudio's compiling strategy, in particular how it reconciles fast turnaround, efficient generated code, and strong typing.
+
+==Compilation is automatic==
+
+Any speed issue aside, the most important property of the compilation process is that it is entirely automatic.
+
+You've seen it from the beginning of this Tour: all the information the compiler has -- obtained from a configuration file, as here, or generated automatically by the other options -- is the name of the root class and the list of directories holding Eiffel clusters. In fact it only needs these directories for non-precompiled clusters; here, since we are using precompiled EiffelBase, the only directory we are required to specify is the one containing the root cluster, denoted simply as " . " (current directory) since, to simplify things, we've started EiffelStudio from the Tour's own root cluster directory.
+
+The compiler takes care of the rest, in particular of finding all the classes that must be compiled.
+
+There is never any need, when compiling Eiffel systems, to supply "Make files", "include files", or other manual descriptions of inter-module dependencies.
+
+==Compilation modes==
+
+EiffelStudio offers several forms of compilation, which you can see in the entries of the Compile menu (don't trigger any of them right now) as well as keyboard shortcuts and, in some cases, buttons:
+* '''Melt''': quick incremental recompilation, doesn't optimize code for changed parts.
+* '''Freeze''': incremental recompilation, not as fast as Melt, but generates more efficient code for changed parts.
+* '''Finalize''': recompile entire system, generating highly optimized code.
+* '''Precompile''' (available both in the Project menu and through Tools --> Precompilation wizard ), to process an entire library, on which many systems can then rely without having to compile it.
+
+You'll quickly learn to use each of these modes to suit your needs.
+
+==Criteria==
+
+EiffelStudio's '''Melting Ice Technology''' reconciles the following goals:
+* ''Security and efficiency of the generated code'': compiling techniques for the strongly typed Eiffel language ensure that compilers can catch many errors before it is too late, and generate more efficient code. The "validity constraints" of the language, whose violations are caught as compilation errors, are particularly useful here, playing the role of enforceable design rules.
+* ''Quick turnaround '': you should experience an almost immediate transition from the time you write or (more commonly) modify software to the time you can execute it.
+* ''C code generation'': for portability, it is useful to take advantage of C in its proper role, that of a portable assembly language. C's closeness to machine concepts -- one of the very properties making it less suitable for human programming except in the case of short routines to access low-level mechanisms --, its almost universal availability, and its good level of standardization, make it an excellent target language for a code generator. This also enables the environment to benefit from the often extensive optimizations performed by good C compilers, and facilitates interfacing new software with the large body of existing C-based systems, tools and libraries. As the final output of Eiffel compilation, you can obtain a complete C package that you can either C-compile on the same machine or port to other platforms, making EiffelStudio a tool of choice for '''cross-platform development''': develop on one platform, deploy on one or more others.
+
+==The Melting Ice Principle==
+
+The idea of the melting ice is based on the observation that, for the practicing software developer, the crucial day-to-day compilation problem is not how to process an entire system but how best to process a '''changed system''', of which an earlier state had previously been processed.
+
+The change may be big or small; the system may be big or small. ("Small system" here means up to a few tens of thousands of lines.) This gives four possible cases, of which only one is really critical:
+{|
+|-
+|
+| '''Small System'''
+| '''Large System'''
+|-
+| Small Change
+|
+| xxx
+|-
+| Big Change
+|
+|
+|}
+
+If the system is small, as in both of the left column entries, speed of recompilation with a good compiler will be acceptable.
+
+In the bottom-right box, the developers have spent days or weeks changing many classes in a large system, so they will not resent having to wait a little to see the results of the recompilation, as long as the time remains reasonable. In EiffelStudio this corresponds, as we'll see shortly, to
finalization, which is in fact fairly fast anyway, but not as fast as the incremental modes.
+
+In the day-to-day, minute-by-minute practice of building and modifying software, the case that recurs by far the most often -- and can cause most frustration -- is the one marked xxx: you change only a small share of a big system. Then the result should come quickly enough. More precisely:
+
+{{note|'''Melting Ice Principle '''
+The time to re-process a system after a change should be a function of the logical size of the change, not of the size of the system. }}
+
+''The "logical size" of a change may be different from its physical size because a small physical change in a class may have consequences in many others. Imagine for example that you add a feature to class ''
ANY '', although this is an extreme case and won't normally happen. Since every class is a descendant of ''
ANY '', the logical change may affect the entire system.''
+
+''In practice, however, most small physical changes will also be small logical changes and will only cause minimal recompilation. In particular, EiffelStudio will detect that a change does not affect the interface of a class -- for example if it's only a change to non-exported features -- avoiding the need to re-process its clients.''
+
+Processing such incremental changes, in time proportional to the logical size of the changes, is known in EiffelStudio as '''melting'''. The reason for this terminology is the metaphor illustrated on the following figure. Think of a compiled system as a block of ice; it may have taken some time to "freeze" -- compile. Now you start working on it again; the changes are like melted drops of water, dripping from the ice as a result of the heat generated by your work.
+
[[Image:index-140]]
+The Melting Ice Technology ensures that incremental compilation will only process the "melted" part, usually small, leaving alone the "frozen" part, which may be large. This is crucial to the incrementality of the mechanism.
+
+The roles of the four compilation modes follow from this analysis:
+* '''Melting''' is the fastest mode: it processes the melted part without affecting the frozen part. With EiffelStudio, the melted elements will be
interpreted while the rest is compiled.
+* '''Freezing''' is the process of putting back the melted parts into the "freezer": bringing them to the same compiled state as the parts that have not been modified.
+* '''Finalizing''' is the non-incremental process of producing a stand-alone C package and the resulting executable, extensively optimized, from the current system.
+* '''Precompiling''' is the process of compiling an entire set of reusable classes, once and for all, so that it can be shared by many systems and many users without duplicating the code or compiling it again for each project.
+
+==Properties of the compilation modes==
+
+The following table summarizes the differences between the four compilation modes:
+{|
+|-
+|
+| '''Regenerate C Code?'''
+| '''Incremental?'''
+| '''Compilation result shared between projects?'''
+|-
+| '''Melt'''
+| No
+| Yes (fast)
+| No
+|-
+| '''Freeze'''
+| Yes
+| Yes (but requires C compilation of changes and linking)
+| No
+|-
+| '''Finalize'''
+| Yes
+| No
+| No
+|-
+| '''Precompile'''
+| Yes
+| No
+| Yes
+|}
+
+During the production and modification of your software, you will usually alternate between melting and freezing, since both of these modes are incremental. Most of the time, you will simply '''melt''', since melting satisfies the Melting Ice Principle: the time to get back to a working system is very short -- proportional to the size of the changes. Note in particular that the unit of melting is the smallest possible one: each feature of a class -- attribute or routine -- may be melted separately.
+
+The main difference between melting and '''freezing''' is that freezing implies re-generating C code for the changed elements, and hence relinking the system as well. In contrast, when you melt changes, you do not change any C code: it remains frozen.
+
+As a consequence, melting can only process changes to Eiffel code. If you add new external code (in C, C++ or other languages whose modules will require linking), you must freeze. This is also true if you add new Eiffel agents. If you ask for a Melt in such cases, the operation will trigger a freeze anyway. More generally, the
Compile button, which you have used a number of times to recompile the system in this Tour, triggers a Melt by default, and a Freeze when it has to.
+
+EiffelStudio knows how to hide the differences and present you with a uniform view of the frozen parts (the C code) and the melted parts. Here indeed is the full view of the picture that was previously given in part:
+
[[Image:index-141]]
+When you examine a component of the system -- to edit a class, produce a view such as Contract or Flat Contract, enable a breakpoint on a routine, run the system, inspect a run-time object -- EiffelStudio automatically knows where to look for the corresponding information: melted or frozen part. If one of your actions requires melting or freezing more elements, EiffelStudio will also handle this automatically.
+
+As suggested by the lower red arrow, successive melting operations "pour water into the bowl", corresponding to the elements that you have changed since the last freeze. Freezing, represented by the top red arrow, updates the C code so that it integrates all the latest changes, emptying the bowl in the process.
+
+Because the difference between melted and frozen code is largely invisible to users of the environment, the term '''workbench code''' will cover both kinds; workbench code is code resulting from a succession of freezing and melting operations. As long as you are working within EiffelStudio, you are using workbench code.
+
+When you are happy with the results of your development, you will normally finalize the system, thereby generating '''final code'''. Although not strictly required, this step is in most cases appropriate since final code is significantly more efficient than workbench code in both time and space: finalization performs a number of optimizations -- dead code removal, replacement of dynamic by static binding -- that wouldn't be justified in incremental development where, for example, some code element that is "dead" one minute may be resurrected the next moment through the addition of just one line of text. In addition, because finalized code is more efficient than frozen code, it is the natural choice if, using EiffelStudio for cross-platform development, you wish to port the resulting C-package to other architectures.
+
+If you have a set of reusable classes that may be useful to many applications, you can '''precompile them''' into a library. This set of classes must be
self-contained in the sense that all the classes needed by any of them must be either in the library itself or in another library that you will include in the precompilation.
+
+==Bytecode==
+
+The result of melting operations -- the contents of the "bowl" -- is an internal software representation known as melted code or (for no particularly good reason) as bytecode. EiffelStudio generated bytecode serves two complementary purposes:
+* It can be executed directly. This is what happens during melting: while the rest of your system, the frozen part, is executed in the form produced by Eiffel compilation generation and C-compilation of the result, the melted part is interpreted "as is" without further translation.
+* It can be compiled into C for further processing.
+
+Internally, the melted code is in a file simple.melted (where simple is our project's name) in the subdirectory EIFGENs/simple/W_CODE of the project directory. The file is not human-readable, but as you add elements to your software and melt you watch its size grow. Whenever you freeze, it's emptied.
+
+On the Microsoft .NET implementation of EiffelStudio, bytecode is replaced by that platform's own internal code, MSIL.
+
+==Degrees==
+
+You can now see the reason behind the terminology used to describe compilation steps, called '''degrees''' on the messages that flash on the screen when you do a compilation. The names are inspired by the international temperature scale -- Celsius, also known as centigrade -- where water freezes at 0 (and boils at 100, but Eiffel software never reaches that). For EiffelStudio:
+* Compilation starts at degree 6, which examines the clusters of your system to determine what classes may have changed. In many cases the compilation can safely skip part of this degree.
+* Degree 5 parses modified classes. It's executed not only when you explicitly request a compilation, but also when you save a class from the EiffelStudio editor, or exit from an external editor, so that you can see and fix syntax errors without delay.
+* Degrees 4 down to 1 take care of melting.
+* Negative degrees only take place when you freeze or finalize.
+* After negative degrees comes C-compilation if needed.
+
+==Using melting and freezing==
+
+When should you melt, freeze, finalize or precompile? The answers are simple and follow directly from the preceding overview; they provide the key to getting the environment to work for you in the most effective way possible.
+
+Melting is the bread and butter of the Eiffel developer. As you build your software, either from scratch or by modifying an existing system, you will regularly melt to benefit from the various checks that compilation performs and, of course, to generate executable code that you can test and debug immediately. During this process, there is no need to refreeze, since this operation (although still incremental) takes significantly more time than melting.
+
+Only two operations, noted above,
require freezing: the addition of external (non-Eiffel) routines, such as C functions or C++ classes, and the addition of agents. The reason is easy to understand: the EiffelStudio compiler knows how to melt Eiffel software, but not software written in C or other languages; agents similarly require special code generation.
+
+''For the first compilation of a system that does not use precompiled EiffelBase, a Freeze is needed since class ''
ANY '', from which all other classes inherit, uses some external routines. In this case the environment automatically starts a freeze even if you just click Melt. This does not apply if you have access to precompiled EiffelBase.''
+
+Except for the addition of external routines or agents, freezing is never strictly necessary. It is indeed possible to use melting throughout a development, never requesting a freeze after the first compilation. But as the melted-to-frozen ratio grows, you may detect a certain degradation in the performance of the system (determined by how big a share of your system is melted, not how many times you melt it). After a while, then, you may want to refreeze. Like melting, freezing is incremental: only those parts of a system that have been logically changed will be recompiled; as with melting, the determination of what needs to be recompiled is entirely performed by the environment, without any manual intervention on the developer's part.
+
+The principal difference is that freezing takes longer than melting. Because of this you are requested to confirm the first time you freeze. Freeze the example system by choosing the menu entry
Project --> Freeze . You get the following dialog:
+
[[Image:index-142]] [[general/guided_tour/studio/index-142.png|(link)]]
+Note the
No option: by default, freezing will start a C compilation, but you can stop after C generation if you wish. This is useful for example if you want to generate a C package for cross-development, C-compiling the result on a different platform.
+
+Click
Yes to confirm freeze and C-compilation. Once the Eiffel compilation is complete, a message in the Development Window (
C compilation launched in background ) tells you when that C-compilation has started. C-compilation does not block EiffelStudio: at this point you can continue working with the environment. Any messages from C compiler will appear:
+* On Windows, in a new console that comes up for the occasion (minimize it if you don't want to see the messages).
+* On Unix/Linux and VMS, in the window from which you launched EiffelStudio.
+
+You will be able to execute the frozen system as soon as the C compilation finishes.
+
+You will note that freezing, although it takes more time than melting, is actually quite fast, both due to the speed of Eiffel compilation and to the structure of the generated C code, designed to optimize the operation of the C compiler.
+
+==Using finalizing==
+
+The main reason for finalizing a system is run-time performance of the generated system. Finalization enables you to generate the high-performance executables that are among the hallmarks of ISE Eiffel. As a consequence, finalized code is the best vehicle for cross-development: you can port the resulting C package to various target platforms and C-compile them on these platforms.
+
+The '''optimizations''' performed by finalization affect both space and time:
+* Dead code removal strips the executable module of all the routines in the system that are not actually called, directly or indirectly, by the root's creation procedure. In a large system relying on many general-purpose classes, dead code removal can easily reduce an executable's size by one third or more.
+* Finalization also applies static binding to non-polymorphic calls, and inlines some routine calls.
+
+As long as you continue changing, melting and freezing your system, the workbench compiling mechanisms cannot perform such optimizations: if a routine is "dead" today you may resurrect it tomorrow by adding a new call to it somewhere; and if a call is non-polymorphic a single additional assignment may require dynamic binding. Compilation can only generate optimal code by working on a full, stable system. This is the task of finalization.
+
+'''Cross-development''', the second reason for finalizing, is important if you are taking advantage of the portability of ISE Eiffel to develop your system on a certain platform and then run the result on target computers with possibly different architectures. A target machine may lack an ISE Eiffel compiler (unmistakably signaling its owner's backwardness) but include a C compiler. If the development and target platforms are of different architectures you will need to obtain a copy of the run-time system for the target architecture. The run-time system is also ANSI-C-based, so porting it is usually a straightforward matter.
+
+Note that cross-development does not require finalization, since you can cross-compile a frozen version. In practice, however, the finalized version is usually the preferred form for porting a C package because of the performance advantage.
+
+Finalize the example system now by selecting the menu entry Project --> Finalize . Here too you will be asked to confirm, although the dialog enables you to suppress that confirmation for later attempts, and you may skip C compilation. You will note that finalization is longer than freezing, but still remains quite reasonable thanks to the extensive optimization of the Eiffel compilation process and the structure of the generated C code.
+
+[[15 GRAPHICS-BASED DESIGN|<< Previous]] [[17 THE COMMAND-LINE COMPILER|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/index.wiki
new file mode 100644
index 00000000..b0db8637
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/index.wiki
@@ -0,0 +1,49 @@
+[[Property:title|EiffelStudio: A Guided Tour]]
+[[Property:weight|0]]
+==Interactive Software Engineering==
+
+===[[MANUAL IDENTIFICATION AND COPYRIGHT|MANUAL IDENTIFICATION AND COPYRIGHT]]===
+
+{{note| This is not an introduction to the Eiffel method and language. See the list of [[Getting started with Eiffel|introductory documents]] for ''Invitation to Eiffel'' and a longer tutorial. }}
+
+==[[1 OVERVIEW AND PREREQUISITES|1 OVERVIEW AND PREREQUISITES]]==
+
+==[[2 COPYING THE EXAMPLE FILES|2 COPYING THE EXAMPLE FILES]]==
+
+==[[3 STARTING EIFFELSTUDIO AND OPENING A PROJECT|3 STARTING EIFFELSTUDIO AND OPENING A PROJECT]]==
+
+==[[4 COMPILING AND EXECUTING A SYSTEM|4 COMPILING AND EXECUTING A SYSTEM]]==
+
+==[[5 A LOOK AT THE PROJECT DIRECTORY|5 A LOOK AT THE PROJECT DIRECTORY]]==
+
+==[[6 STARTING TO BROWSE|6 STARTING TO BROWSE]]==
+
+==[[7 CLASS VIEWS|7 CLASS VIEWS]]==
+
+==[[8 PRODUCING AND EXPORTING DOCUMENTATION|8 PRODUCING AND EXPORTING DOCUMENTATION]]==
+
+==[[9 BROWSING FEATURES|9 BROWSING FEATURES]]==
+
+==[[10 RETARGETING THROUGH PICK-AND-DROP|10 RETARGETING THROUGH PICK-AND-DROP]]==
+
+==[[11 RECOMPILING AND EDITING|11 RECOMPILING AND EDITING]]==
+
+==[[12 HANDLING SYNTAX AND VALIDITY ERRORS|12 HANDLING SYNTAX AND VALIDITY ERRORS]]==
+
+==[[13 DEBUGGING AND RUN-TIME MONITORING|13 DEBUGGING AND RUN-TIME MONITORING]]==
+
+==[[14 COMPUTING PROJECT METRICS|14 COMPUTING PROJECT METRICS]]==
+
+==[[15 GRAPHICS-BASED DESIGN|15 GRAPHICS-BASED DESIGN]]==
+
+==[[16 HOW EIFFELSTUDIO COMPILES|16 HOW EIFFELSTUDIO COMPILES]]==
+
+==[[17 THE COMMAND-LINE COMPILER|17 THE COMMAND-LINE COMPILER]]==
+
+==[[18 EXECUTING A SYSTEM WITHIN AND WITHOUT EIFFELSTUDIO|18 EXECUTING A SYSTEM WITHIN AND WITHOUT EIFFELSTUDIO]]==
+
+==[[19 APPENDIX: WRITING DOCUMENTATION FILTERS WITH EFF, THE EIFFEL FILTER FORMAT|19 APPENDIX: WRITING DOCUMENTATION FILTERS WITH EFF, THE EIFFEL FILTER FORMAT]]==
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/manual-identification-and-copyright.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/manual-identification-and-copyright.wiki
new file mode 100644
index 00000000..72e97eb4
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/manual-identification-and-copyright.wiki
@@ -0,0 +1,73 @@
+[[Property:title|MANUAL IDENTIFICATION AND COPYRIGHT]]
+[[Property:link_title|Manual identification and copyright]]
+[[Property:weight|7]]
+Title: ''EiffelStudio: A Guided Tour'', Eiffel Software Technical Report TR-EI-68/GT. (Replaces TR-EI-38/EB.)
+
+===Publication history===
+
+First published 1993 as ''First Steps with EiffelBench'' (TR-EI-38/EB) and revised as a chapter of ''Eiffel: The Environment'' [http://www.eiffel.com/doc/ (TR-EI-39/IE), also available as] An Object-Oriented Environment (Prentice Hall, 1994, ISBN 0-13-245-507-2.
+
+Version 3.3.8, 1995.
+
+Version 4.1, 1997
+
+This version: July 2001. Corresponds to release 5.0 of the EiffelStudio environment.
+
+===Author===
+''Bertrand Meyer''
+===Software credits===
+
+Emmanuel Stapf, Arnaud Pichery, Xavier Rousselot, Raphael Simon; Etienne Amodeo, Jrome Bou Aziz, Vincent Brendel, Gauthier Brillaud, Paul Colin de Verdiere, Jocelyn Fiat, Pascal Freund, Savrak Sar, Patrick Schonbach, Zoran Simic, Jacques Sireude, Tanit Talbi, Emmanuel Texier, Guillaume Wong-So; EiffelVision 2: Leila Ait-Kaci, Sylvain Baron, Sami Kallio, Ian King, Sam O'Connor, Julian Rogers. See also acknowledgments for earlier versions in ''Eiffel: The Environment''(TR-EI-39/IE)
+
+Non-Eiffel Software: special thanks to Thomas Beale, Eric Bezault, Paul Cohen, Paul-Georges Crismer, Michael Gacsaly, Dave Hollenberg, Mark Howard, Randy John, Eirik Mangseth, Glenn Maughan, Jacques Silberstein.
+
+===Cover design===
+
+Rich Ayling.
+
+===Copyright notice and proprietary information===
+
+Copyright Interactive Software Engineering Inc. (Eiffel Software), 2001. May not be reproduced in any form (including electronic storage) without the written permission of Eiffel Software. "Eiffel Power" and the Eiffel Power logo are trademarks of Eiffel Software.
+
+All uses of the product documented here are subject to the terms and conditions of the Eiffel Software user license. Any other use or duplication is a violation of the applicable laws on copyright, trade secrets and intellectual property.
+
+Any third-party products mentioned in this document are hereby acknowledged as trademarks of their respective owners.
+
+===Special duplication permission for educational institutions===
+
+Degree-granting educational institutions using EiffelStudio teaching purposes as part of the [http://www.eiffel.com/educators/resources.html Eiffel University Partnership Program] may be permitted under certain conditions to copy specific parts of this book. Contact Eiffel Software for details.
+{|
+|-
+| '''About Eiffel Software '''
+|-
+|
+Eiffel Software (Interactive Software Engineering) helps you produce software better, faster and cheaper.
+
+Eiffel Software provides a wide range of products and services based on object technology, including EiffelStudio, a complete development environment for the full system lifecycle. Eiffel Software's training courses, available worldwide, cover key management and technical topics. Eiffel Software's consultants are available to address your project needs at all levels.
+
+Eiffel Software's TOOLS (Technology of Object-Oriented Languages and Systems) conferences, [http://www.tools-conferences.com http://www.tools-conferences.com] , are the meeting point for anyone interested in the software technologies of the future.
+
+Eiffel Software originated one of the earliest .NET products and offers a full range of .NET services and training at [http://www.dotnetexperts.com http://www.dotnetexperts.com] .
+
+For more information
+
+Interactive Software Engineering Inc.
+Eiffel Software Building, 360 Storke Road
+Goleta, CA 93117 USA
+Telephone 805-685-1006, Fax 805-685-6869
+
+Internet and e-mail
+
+Eiffel Software maintains a rich source of information at [http://www.eiffel.com http://www.eiffel.com] , with more than 1200 Web pages including online documentation, downloadable files, product descriptions, links to Eiffel Software partners, University Partnership program, mailing list archives, announcements, press coverage, Frequently Asked Questions, Support pages, and much more.
+
+Visit [http://www.eiffel.com/general/contact_details.html http://www.eiffel.com/general/contact_details.html] to request information about products and services. To subscribe to the Eiffel Software user list, go to[http://groups.eiffel.com/join http://groups.eiffel.com/join] .
+
+Support programs
+
+Eiffel Software offers a variety of support options tailored to the diverse needs of its customers. See [http://support.eiffel.com http://support.eiffel.com] for details.
+
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/overview-and-prerequisites.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/overview-and-prerequisites.wiki
new file mode 100644
index 00000000..a50d5e68
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/overview-and-prerequisites.wiki
@@ -0,0 +1,87 @@
+[[Property:title|1 OVERVIEW AND PREREQUISITES]]
+[[Property:link_title|Overview and Prerequisites]]
+[[Property:weight|-15]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+EiffelStudio is the central tool of Eiffel Software's implementation of Eiffel, letting you design, develop, debug, document, measure, maintain, revise and expand systems using the full power of object technology and Design by Contract TM.
+
+This presentation introduces the essential properties of EiffelStudio. It will take you through a tour of the environment, using a pre-existing example system.
+
+==What will I achieve?==
+
+Although it skips many specific or advanced facilities, this Tour will help you quickly become familiar with the way you can use the environment for your work. After reading it you will know the basics of working with EiffelStudio:
+* Starting a project and retrieving an existing project.
+* Entering new software elements -- clusters, classes and features.
+* Compiling your software.
+* Making changes and having them immediately recompiled using the Melting Ice Technology TM.
+* Displaying a graphical representation of your software elements, and modifying the software through the graphical views (as well as through its text).
+* Producing extensive documentation of your system, textual or graphical, under many different formats such as HTML, RTF, Postscript, XMI (for example Rational Rose) and others.
+* Browsing through simple or complex software systems, to find out their various components, properties and relationships.
+* Measuring quantitative properties of the software, by applying metrics predefined in EiffelStudio as well as new ones that you define.
+* Executing a compiled system, and controlling its execution through the debugging mechanisms of EiffelStudio.
+
+==About the scope of EiffelStudio==
+
+The most important property to keep in mind as you are discovering EiffelStudio is that it is neither just a "programming environment" nor just a "CASE tool" (Computer-Aided Software Engineering) for analysis and design. It encompasses both of these functions and many others. Most system builders today are used to a dichotomy between the high end and the low end:
+* At the analysis and design levels, graphical tools help you clarify your thinking about the system, interacting with customers and end users, and devise high-level system architectures, usually in diagrammatic form.
+* At the low end, programming tools help you edit, compile and debug your programs.
+
+Keeping these tools separate is, however, detrimental to the quality of the software process and the resulting products. If they are in the hands of different teams, communication problems may arise, leading to discrepancies between need and realization; this can be a source of bugs or even project failure. If it's the same people using tools of both kinds, they have to keep switching notations, tools and modes of thinking. The use of different frameworks at both ends makes it difficult to keep the high-level model and the implementation consistent; too often, a change decided at the implementation level is not reflected back in the higher model. After a while, the system gets into the state of disorder and inconsistency that good tools are precisely meant to avoid.
+
+EiffelStudio, in line with the principles of seamless development and reversibility of the Eiffel method, removes the gap by providing a single set of tools that accompany you throughout a project, from the most high-level initial stages to the most low-level aspects of implementation and maintenance.
+
+This generality is reflected throughout the environment by, for example, the dual use of text and graphics. As another example, you should think of the EiffelStudio compiler, not just as a tool for executing Eiffel software in its final form, but also, thanks to its extensive validity checking facilities, as a design consistency tool that performs many verifications commonly associated with CASE tools.
+
+Depending on your project needs, you may take advantage of EiffelStudio's versatility to address specific purposes:
+* You may use EiffelStudio as a programming environment, with advanced tools for compiling, browsing and debugging.
+* Some people use EiffelStudio as a modeling tool only, building system descriptions consisting only of deferred (abstract) classes with no implementation, and relying on the Diagram Tool to build, present and discuss these descriptions through graphical views.
+* You may use EiffelStudio in both capacities, taking advantage of the seamlessness between all the affected phases.
+
+==Learning by doing==
+
+If you have access to EiffelStudio as you read this Tour, the most effective technique is to execute all the suggested operations as you read about them.
+
+Please execute user actions, such as clicking, only when asked to do so.
+
+==What should I already know?==
+
+This Tour assumes very little about what you know and what you don't.
+
+It does assume that you can do simple manipulations on your platform of choice, such as: on Windows, finding and drag-and-dropping folders and files in the Windows Explorer; on Unix, changing to a certain directory ( cd ) and listing the files of a directory ( ls ).
+
+The more you already know about object technology and object-oriented environments, the better. But remember, if you have used other environments before, keep a fresh outlook; EiffelStudio is different, and it may take a while before you fully understand why it does some things in a certain way.
+
+==A note on platform differences==
+
+EiffelStudio is one of the most portable environments in the industry, running in an almost identical fashion on Windows, on the new Microsoft .NET environment, on many variants of Unix, on Linux, on VMS.
+
+Once an EiffelStudio session has been started, you can largely forget about the operating system. But a few operations -- mostly at the beginning, to launch EiffelStudio -- require platform-dependent mechanisms: starting a program, traversing the file structure, selecting a file. These cases will be marked accordingly below.
+
+Windows users should particularly note the following two conventions of terminology:
+* Operating systems store files into hierarchically nested structures called folders or directories. Although "folder" is the more common term for Windows, we will mostly speak of "directories". It's exactly the same thing.
+* A file has a full path name, used to describe how to reach it from the root of its file system, as in c:\d1\d2\f . This example uses the Windows notation, which separates successive components of a path name by a backward slash character \ . On Unix and Linux, the separator is a forward slash / , as in /d1/d2/f ; this is also the convention on the Internet for denoting addresses (URLs). Most file names in this manual appear in this Unix/Internet style. On Windows you will normally have to use the backslash convention, although EiffelStudio also accepts forward slashes. In any case you must be consistent: don't mix backward and forward slashes in the same path name. Also note that some names, such as those of object files to be linked with your system, will be passed to outside tools -- C compilers, loaders -- that may not accept the forward slash.
+
+VMS users may similarly use either the Unix convention or the specific VMS path naming convention.
+
+If you are a one-platform person, just ignore, for the next few pages, all references to any platform other than your heart's favorite. They will quickly go away.
+
+==What should I have done first?==
+
+To run the example you must have installed EiffelStudio and set up the environment. Check in particular the following:
+* On Windows, you must have run the installation procedure; it will have put EiffelStudio in the Programs section of the start menu, subsection "EiffelStudio version", where version is the version number, e.g. 6.0.
+* The environment variable ISE_EIFFEL must be set to the installation directory, and the environment variable ISE_PLATFORM to the platform. On Windows this is taken care of automatically by the installation procedure, but on Unix/Linux and VMS you must update your path and environment manually. Throughout this discussion the notations $ISE_EIFFEL and $ISE_PLATFORM will refer to the values of these variables -- the installation directory, and the platform. (The Windows notation would be %ISE_EIFFEL% and %ISE_PLATFORM% .)
+* On Unix/Linux and VMS, your "path" must include the place where EiffelStudio executables reside. (On Windows the installation procedure takes care of this.)
+* Also, the discussion assumes that as part of the installation you have included the EiffelBase library, in precompiled form. EiffelBase is automatically included if you have installed another precompiled library, such as WEL, the Windows Eiffel Library. The installation procedure takes care of precompiling EiffelBase.
+
+==Locating the example==
+
+Please take a moment to locate the example files on your installation. They all appear in the following directory, part of the Eiffel delivery:
+$ISE_EIFFEL/examples/studio/tour
+
+(Windows users: remember that instead of the slash / your platform uses a backslash \ . VMS users: this is to be replaced by the VMS path naming conventions.)
+
+[[2 COPYING THE EXAMPLE FILES|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/producing-and-exporting-documentation.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/producing-and-exporting-documentation.wiki
new file mode 100644
index 00000000..10b1ae0d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/producing-and-exporting-documentation.wiki
@@ -0,0 +1,146 @@
+[[Property:title|8 PRODUCING AND EXPORTING DOCUMENTATION]]
+[[Property:link_title|Producing and Exporting Documentation]]
+[[Property:weight|-7]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+Software development is, most of the time, cooperative work. You must tell the rest of the team what you're up to, and find out what they can offer you. Bring in distributed development -- increasingly common these days, with some people working at headquarters, others at home, others traveling, an offshore team half a world away ... -- and the problem becomes even more critical.
+
+EiffelStudio provides unique facilities to make such distributed development possible in a safe, effective, harmonious way. Some of the key criteria are:
+* You must be able to export the information easily to the World-Wide Web, the most general and widely available interaction mechanism.
+* The documentation must be faithful to the software. Because of the ever-changing nature of software, this goal is impossible to satisfy unless the documentation is extracted from the software -- as opposed to the traditional approach, still perpetuated by many CASE tools, of treating the two as separate.
+* The task of updating the documentation after a software change must be straightforward and automatic.
+* It's not enough to support HTML; many other formats are useful too.
+* Users must have the ability to adapt the mechanism to support new formats.
+* For existing formats, they must have a way to tune the output easily to any specific style standards, company policies, local variants.
+
+EiffelStudio's documentation generation satisfies all these requirements.
+
+==Documentation filters==
+
+Let's see how documentation works by starting to generate it for our Guided Tour system -- which really means for EiffelBase, since that's what it mostly consists of. The HTML result is available as part of the present documentation (we'll tell you where in just a minute), so you don't have to regenerate it unless you want to. Indeed we'll show you when to click Cancel if you are happy with the pre-generated version. But let's get started anyway to understand the principles and possibilities.
+
+Click the following menu entry, used to generate documentation:
+
+ Project --> Generate documentation...
+
+
+This is the next-to-last entry in the Project menu. The last one, by the way, XMI Export ..., is directly relevant too: it will make it possible to export information in the standard XML representation for UML, for consumption by third-party products such as Rational Rose. But for the moment we choose the Documentation entry to start the Eiffel Documentation Wizard.
+
+The Wizard starts with a list of available output formats, also called filters:
+ [[Image:index-37]] [[general/guided_tour/studio/index-37.png|(link)]]
+The filter names correspond to major documentation formats which EiffelStudio supports by default. Among the most important, listed here in rough order of appearance in the list:
+* ASCII : plain text, no formatting codes.
+* eiffel : essentially the same as ASCII; useful if you want EiffelStudio to pretty-print your class texts and replace the originals, as explained below.
+* MML : internal format for Adobe FrameMaker.
+* Postscript : to generate Adobe Postscript output, suitable for printing on a Postscript printer, display on a Postscript previewer such as Ghostscript, or distilling to Adobe PDF.
+* COM : to generate class specifications in the form of an Interface Description Language (IDL) interface for Microsoft's COM component model.
+* RTF : Microsoft's Rich Text Format, used in particular for Windows "Help" files.
+* TeX1 , TeX2 : two variants for Donald Knuth's TEX processing format.
+* troff : if you already know what this is, congratulations (or condolences), you've been around the industry for a while. This is a traditional text-processing format available on Unix systems. Also works for the gtroff variant.
+* html-classic : HTML, no style sheets. The next variant, with style sheets, is strongly recommended unless your colleagues will be reading your documentation with Mosaic 1, vintage 1993, or Netscape 2, Vintage 1995.
+* html-stylesheet : HTML with style sheets. This is particularly attractive for Web publishing not only because the output makes full use of style sheet capabilities (fonts, colors, layout, formatting) but also because it becomes trivial to change the look-and-feel to support any style you or your users like, even after generation, simply by editing the style sheet file.
+
+Not only do these predefined filters provide support for a number of important industry formats; better yet, if you want another format not represented on the list, or would like to adapt an existing format to your own style preferences, it's easy to define a new filter. The list that EiffelStudio displays comes from the files with a . fil extension that it finds in a subdirectory of the installation:
+
+ $ISE_EIFFEL/studio/filters
+
+
+To define a new filter, simply add a file to this directory. Filters are expressed in a simple notation called EFF ( Eiffel Filter Format ), general enough to support a wide variety of tools for text processing, project management, Web publishing etc. The best way to define a new filter is usually to start from an existing one and adapt it. You will find the specification of EFF at the end of this manual, [[19 APPENDIX: WRITING DOCUMENTATION FILTERS WITH EFF, THE EIFFEL FILTER FORMAT|here]] .
+
+==Generating an HTML record of your project==
+
+Let's select the most obviously attractive of the predefined filters: HTML with stylesheets. Click the line html-stylesheet in the list to make it active, then click Next at the bottom of the Documentation Wizard window. The next window appears:
+ [[Image:index-38]] [[general/guided_tour/studio/index-38.png|(link)]]
+This is to let you decide which clusters of your system the documentation will include. Initially all clusters/libraries appear in the Include list on the right; but you might want to exclude some standard libraries or other clusters from the documentation.
+
+To move a cluster from the right column to the left one, click it to select it, and click the left arrow button; for the reverse, use the right arrow.
+
+You can play with moving a couple of clusters back and forth, but for this Tour we'll want to generate everything, including EiffelBase, so make sure that in the end all clusters appear in the right column, as on the last figure. Then click Next .
+
+==Generating Metatags from Indexing entries==
+
+The next step of the documentation wizard asks you to select indexing entries:
+ [[Image:index-39]] [[general/guided_tour/studio/index-39.png|(link)]]
+Eiffel classes, as you know, may start with an Indexing entry that enables class authors to include documentary information in any category they like. It is standard (and part of the official style guidelines) to include at the very least an entry of the form description: Descriptive text in every class. The earlier displays of class LIST showed that entry, which read " Sequential lists, without commitment to a particular representation ".
+
+You may have noted that the purpose of Eiffel's Indexing clauses is, conceptually, similar to that of '''metatags''' in HTML. Metatags carry information which Web page visitors do not normally see in the browser; this information is available, however, to search engines and other tools that explore and classify Web pages. So it seems quite appropriate to generate metatags from Indexing entries.
+
+The dialog illustrated in the last figure lets you select the entries you wish to transform into metatags. It appears only if you have selected an HTML filter. It lists all the Indexing tags found anywhere in the system; those on the right will be retained for metatags. Initially the Exclude list on the left contains three tags conventionally used -- at Eiffel Software and other Eiffel sites -- for interfacing with configuration management tools, and hence of internal interest only.
+
+There is no need to change the default selection, so just click Next .
+
+==Choosing a level of detail==
+
+The next step of the Documentation Wizard lets you specify what kinds of documents you want to generate:
+ [[Image:index-40]] [[general/guided_tour/studio/index-40.png|(link)]]
+This is a very important facility since it gives you control over how much you want to publish about the properties of the software:
+* You may want to publish everything, source included, for example on your Intranet for a group of developers working closely together on the same classes, or on the Internet for open-source software.
+* You may want to publish only the interfaces (Contract or Flat-Contract views). This is not necessarily to protect proprietary information; even if you don't care about showing your source code, it is usually too detailed for client programmers, especially in the case of libraries. If various teams work on separate parts of a project, what each releases to the other should usually be the specification, not the implementation.
+* You may of course want to publish both the text and the interface, and let the recipients use the version that best suits their needs for each use.
+* You may want to publish the diagrams, showing the structure in graphical form. Note the warning -- which we are about to ignore -- telling us this may take a while.
+* The class list, cluster list, cluster hierarchy view, cluster chart (following the conventions of BON) are also optional.
+
+The dialog shown on the last figure lets you specify the exact combination you wish. The figure indicates the default options.
+
+This time, if we generate anything, we'll generate everything. Please check '''all''' the boxes (the generation won't occur until the last step) and click Next to move to the next dialog of the Documentation Wizard.
+
+==Specifying cluster views==
+
+The next dialog only appears when you have asked to generate diagrams:
+ [[Image:index-41]] [[general/guided_tour/studio/index-41.png|(link)]]
+Although we didn't use this possibility yet, the Diagram view lets you define different subviews of any cluster. One view might show inheritance only, the other client links only; one might include all classes, the other hide some library classes. The last dialog shown will allow you, for any cluster, to select a subview other than the default for the generated diagram.
+
+Here we only have the default view, so just click Next .
+
+==Generating==
+
+The last dialog simply asks you where you want to generate the result:
+ [[Image:index-42]] [[general/guided_tour/studio/index-42.png|(link)]]
+By default, as shown, EiffelStudio will produce the documentation in a subdirectory -- created for the occasion, if it doesn't exist yet -- of the project directory:
+
+ Project_directory /Documentation
+
+
+You may, however, select any other location you like. In the case of HTML generation, as here, EiffelStudio takes great care to use only '''relative hyperlinks''' so that you can move the Documentation directory around, for use either on a file system or on your Web site, with the guarantee that the hyperlinks will work -- as long as you move the entire directory together.
+
+To continue the Guided Tour, you do '''not''' need to complete the generation now unless you want to. If you are happy to continue without generating the documentation at the moment then click Cancel on the last dialog.
+
+{{note| ''If you prefer to produce your own, click "Finish". For our example system the process takes 7 minutes on the Thinkpad configuration mentioned earlier, and generates a 82 megabyte documentation directory.'' }}
+
+==Browsing generated documentation==
+
+Let's take a look at the generated documentation. We start with the root of the generated documentation, Documentation/index.html :
+ [[Image:index-43]] [[general/guided_tour/studio/index-43.png|(link)]]
+This root page shows overall information about the system. The top set of links, repeated at the bottom, enables you to browse the system from its list of classes, its list of clusters, or the cluster hierarchy; note the box labeled to Go , which provides a built-in search engine, enabling you to type any class list and go directly to the corresponding page. Let's look at the class list: click the box Classes at the top left.
+ [[Image:index-44]] [[general/guided_tour/studio/index-44.png|(link)]]
+This shows the beginning of the list of classes, alphabetically sorted. You could click any class to get the corresponding information, but wait; we'll look at individual classes in a moment. Instead, click Cluster hierarchy to see the overall organization of the system into clusters:
+ [[Image:index-45]] [[general/guided_tour/studio/index-45.png|(link)]]
+Click BASE to see details of the EiffelBase library where (under EiffelStudio) we had found the class LIST used as example in the preceding sections:
+ [[Image:index-46]] [[general/guided_tour/studio/index-46.png|(link)]]
+This indicates the relations of the cluster to others in the hierarchy, and its list of classes. Again you could click any class name but instead note the mention (diagram) next to the cluster name near the top. Remember that when generating the documentation we elected to generate everything, diagrams included. Hadn't we checked the corresponding check box, the (diagram) link wouldn't be there. Click it now to get the generated diagrams:
+ [[Image:index-47]] [[general/guided_tour/studio/index-47.png|(link)]]
+The output is a diagram showing graphically the classes of the cluster and their inheritance relations. All EiffelStudio-generated HTML diagrams use the PNG graphics format ( Portable Network Graphics ), supported by all recent browsers.
+
+The class bubbles in a diagram are all hyperlinks. To see the HTML documentation for our old friend the class LIST -- which you could also obtain by clicking its name on one of the preceding diagrams, or typing it in the Go to field -- just click its bubble:
+ [[Image:index-48]] [[general/guided_tour/studio/index-48.png|(link)]]
+The display shows key information on the class, in a form called the "Chart format" listing the ancestors and then the features, divided into Queries (shown in part on the figure) and Commands . Note that all class names and feature names are hyperlinks, which would lead you to the appropriate place in a class text.
+
+The top row of hyperlinks now includes class formats corresponding to those we discovered under EiffelStudio ( [[7 CLASS VIEWS|"CLASS VIEWS"]] ): Relations (covering ancestors, descendants, clients, suppliers, ), full Text , Contracts , Flat contracts . Click Flat contracts to see the full interface of the class:
+ [[Image:index-49]] [[general/guided_tour/studio/index-49.png|(link)]]
+We'll stop this brief review here but you may continue browsing through the HTML pages if you like. Note how closely the appearance of the class texts, flat forms, contract forms, diagrams and other forms of documentation matches the corresponding formats under EiffelStudio.
+
+Although we suggest staying with the standard, you can easily change any convention that doesn't match your own preferences:
+* For the EiffelStudio appearance, use Tools --> Preferences .
+* For the HTML appearance, if you know about Cascading Style Sheets (CSS) for HTML, edit the style sheet default.css . You will find this file in the generated documentation directory; alternatively, to ensure the changes are applicable to the generated documentation of all future projects, edit defaults.css in the directory after backing it up. For more profound changes in the structure of the generated HTML, you may also backup and edit the Eiffel Filter Format file html-stylesheet.fil in the same directory. EFF is described in [[19 APPENDIX: WRITING DOCUMENTATION FILTERS WITH EFF, THE EIFFEL FILTER FORMAT| Chapter 19, "Appendix"]] .
+
+ $ISE_EIFFEL/studio/filters
+
+
+
+The documentation generation mechanisms, using HTML or other formats, let you publish your designs, at the level of detail you desire, on an Intranet, the Internet, or as part of documents you release. They are an important part of the power of EiffelStudio for quality software development.
+
+[[7 CLASS VIEWS|<< Previous]] [[9 BROWSING FEATURES|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/starting-eiffelstudio-and-opening-project.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/starting-eiffelstudio-and-opening-project.wiki
new file mode 100644
index 00000000..7c0a08a0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/starting-eiffelstudio-and-opening-project.wiki
@@ -0,0 +1,28 @@
+[[Property:title|3 STARTING EIFFELSTUDIO AND OPENING A PROJECT]]
+[[Property:link_title|Starting EiffelStudio and Opening a Project]]
+[[Property:weight|-13]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+In the rest of this Tour YOURDIR denotes the directory where the example resides (the original, $ISE_EIFFEL/examples/studio/tour , or a copy). Launching will use the operating system's mechanism for starting a program, so we look separately at Windows and at Unix/VMS.
+
+==Launching EiffelStudio under Window==
+
+On Windows, you can launch EiffelStudio from the Start Menu under
+ Programs --> EiffelStudio Version --> EiffelStudio
+
+where Version is the version number, e.g. 6.0. Alternatively, you can double-click the icon that the installation procedure will have added to your desktop (if you have selected that option during installation).
+
+If this is the first time you are using EiffelStudio, you may get a dialog asking for an unlock code or inviting you to register the product. See [[Software Installation for EiffelStudio 6.2|your platform installation instructions]] for registration information.
+
+==Launching EiffelStudio under Unix or VMS==
+
+To launch EiffelStudio on Unix or VMS, change directory to YOURDIR and, from the command line, type
+ estudio
+
+In general you can start EiffelStudio from any directory, but to make things simple for this Tour '''please make sure''' indeed to execute the estudio command from YOURDIR . (This will allow us to use relative rather than absolute names for some of the files involved.)
+
+[[2 COPYING THE EXAMPLE FILES|<< Previous]] [[4 COMPILING AND EXECUTING A SYSTEM|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki
new file mode 100644
index 00000000..e5dce81e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-guided-tour/viewing-classes.wiki
@@ -0,0 +1,91 @@
+[[Property:title|7 CLASS VIEWS]]
+[[Property:link_title|Viewing Classes]]
+[[Property:weight|-9]]
+[[Help reading the EiffelStudio Guided Tour|Help reading this manual]]
+
+We haven't even looked at a class text yet, but it's important anyway to see how EiffelStudio provides you with numerous, complementary views of your software. The Context Tool is the primary place to look for such views.
+
+We'll need just one Development Window for the moment, the one that was targeted to LIST . You can get rid of the others by closing their windows (through the top right cross mark on Windows and the equivalent in other window managers), or through File --> Close -- but don't select "Exit" which would take you out of EiffelStudio altogether!
+
+{{note| ''If you don't see a tool targeted to '' LIST '', just retarget one, as you know how to do this now, for example by typing the name followed by Enter in the Class Field at the top left.'' }}
+
+First let's give ourselves more space. Right now we don't need the Cluster Tree, Feature Tree and Properties panes. Get rid of them by clicking the close buttons on the top right corner of the panes.
+
+You can get these panes back later by clicking the buttons in the toolbar or by going to the View, Tools Menu.
+
+{{note| ''Another way to hide a pane is to click on the button in the toolbar or by unselecting them in the View, Tools Menu.'' }}
+
+Two panes remain, showing the Editing Tool and the Context Tool.
+ [[Image:index-26]] [[general/guided_tour/studio/index-26.png|(link)]]
+Make sure the Context Tool pane is large enough; you can resize the window and, if necessary, narrow down the Editing Tool pane since we don't need it for the moment. Don't worry, though, if the Context Tool shows only part of the diagram, as it does on the last figure, since we will now use the Context Tool to display information other than the diagram, by selecting the corresponding tabs.
+
+==The Class Tab==
+
+The first tab we'll look at is the Class Tab. You'll find it at the bottom of the Context Tool.
+
+This gives you access to many forms of information about the current class -- the target of the Development Window. A set of buttons at the top of the Context Tool enables you to display a number of '''views''' of the class. The currently highlighted button indicates the default view: Ancestors . You can see the others' names by moving the cursor over the various view icons, '''without clicking''', and reading the tooltips.
+
+The view currently displayed, Ancestors , shows the inheritance structure that leads to the current target, LIST :
+ [[Image:index-29]] [[general/guided_tour/studio/index-29.png|(link)]]
+This shows that LIST is an heir of CHAIN which itself, as an example of multiple inheritance, is an heir of CURSOR_STRUCTURE , INDEXABLE , and -- twice, as an example of repeated inheritance -- SEQUENCE . If, because of direct or indirect repeated inheritance, a class appears more than once, the display doesn't repeat its ancestry the second and subsequent times; the omitted repetition appears as just three dots, '''...''', as illustrated here for the second occurrences of BAG , ACTIVE and others.
+
+As you may have guessed, all the class names that appear on this display, by default in blue, can function as hyperlinks: you can use any one of them to retarget the Development Window to the corresponding class. This will be another major retargeting mechanism. But let's not pursue it for the moment and instead continue looking at the documentation views.
+
+Next to Ancestors button is Descendants, which will give you the descendants of a class in a similar format:
+ [[Image:index-30]] [[general/guided_tour/studio/index-30.png|(link)]]
+The progeny of LIST , as you can see, is just as impressive as its ancestry.
+
+Let's now look at the other formats, starting from the left. The first button, Clickable , gives the class text. It's essentially the same information as appears in the top Editing Tool (whose pane was reduced to its bare minimum in the last few pictures, showing only the first three lines or so), but with some differences:
+* The top Text view is editable. In fact it's EiffelStudio's primary tool for entering software texts. The bottom Clickable view is just a view; you can't change it.
+* The Text view retains the formatting of the class text the way it was typed in; the Clickable view is automatically formatted -- "pretty-printed" -- according to the standard Eiffel layout rules.
+* The Clickable view does not include comments inside routine implementations ( do and once clauses), although it does retain features' header comments.
+* As part of the pretty-printing, the Clickable view uses colors and fonts to distinguish keywords, identifiers, comments and other syntactical elements. You can change the fonts and colors, like many other elements of the interface, through Tools --> Preferences . (Now is not the time.)
+
+This view is called "clickable" because, as we'll see later, every syntactical element on it is a hyperlink, which you can use for browsing.
+
+After Clickable comes the Flat view button. The layout of the result is similar. The flat form of a class is the reconstructed class text including not only what's declared in the class itself but also everything that it inherits from its ancestors, direct or indirect. This applies to the flat form's features, which include ancestor features, but also to contracts: the flat form's invariant includes all clauses from ancestors' invariants, and the preconditions are expanded to take require else and ensure then clauses into consideration. (The [[An Eiffel Tutorial|Eiffel Tutorial]] explains these notions in detail.)
+
+As a result, the Flat view shows the class text as it might have come out had inheritance (what a horrible thought even to contemplate!) not been available to write it.
+
+The first two features appearing in the above display, cursor and first , are indeed inherited from ancestors, rather than declared in LIST itself. Note how EiffelStudio, when producing the flat form, adds a line of the form
+
+ -- (From CLASS_OF_ORIGIN)
+
+
+to the header comments of inherited routines, to document where they come from.
+
+The flat form is an important notion of object technology, making it possible to understand a class by itself, regardless of the possibly rich inheritance structure that led to it. Looking at the Flat view of LIST , you may note how few of its properties come from the class itself; most of the interesting work has been done in ancestors, and LIST just adds a few details.
+
+{{note| ''If at any time you want to search for a certain pattern in the views displayed, click the '' Search '' button at the top of the window, or type CTRL-'' F . ''A self-explanatory Search Tool will come up, with various options such as '' ''Match case'' '' and '' ''Whole word'' }}
+
+Next come two essential documentation views: Contract and Flat Contract . Based on Eiffel's principles of Design by Contract, they document the interface properties of a class. Unlike the previous two, they do not show actual Eiffel texts, but information useful for client classes.
+
+The contract form (also known as the '''short form''' of a class) is the class text deprived of any internal detail to retain interface information only. It discards any feature that's not exported (available to all clients); for the retained features, it discards the implementation -- do or once clause -- but retains the header (feature name, arguments, results), the header comment, and the contracts (precondition, postcondition, invariant) minus any contract clause that refers to a non-exported feature and hence would be useless to clients.
+
+As you will know, particularly if you have read the book [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] , the contract form is the preferred way of documenting software elements, especially reusable components, as it provides clients with just the right level of abstraction: precise enough thanks to the type signature and the contracts; clear enough thanks to the header comments; and general enough since it omits implementation details that are irrelevant to client programmers (and might lead them to write client code that won't work any more if the implementation changes).
+
+In practice you will often want to use, instead of the Contract view, the next one, Flat Contract , also known as "flat-short form" and "interface form", which applies the same rules to the flat form rather than to the original class. This means it shows information on all the features of the class, immediate (defined in the class itself) as well as inherited, whereas the short form, non-flat, only considers immediate features. The Flat Contract view provides the complete interface information for the class. Try it now on class LIST .
+
+The next two buttons are for the Ancestors and Descendants views, which we have already seen, showing classes connected with the target through one of the two inter-class relations, inheritance. After them come Clients and Suppliers , to list the classes connected through the other relation, client. Clicking the Clients button shows the (empty) list of clients of LIST .
+
+No class of this system directly uses LIST as client, although some use its descendant ARRAYED_LIST . Now click the next button to see the Suppliers of LIST .
+
+The only two classes that LIST needs for its own algorithms are basic types from the Kernel Library, BOOLEAN and INTEGER_32 . In Eiffel, as you may remember, all types are defined by classes, even those describing such elementary values as integers and booleans.
+
+==Feature information in the Class View==
+
+Let's resist the natural urge to go see now what the classes INTEGER_32 and BOOLEAN look like, and instead continue our survey of views. The remaining views will all display information about the '''features''' of the class. The first of them, Attributes , lists the attributes. It's not very interesting for LIST , a deferred class with only one attribute -- you can check this for yourself by clicking the Attributes button -- so let's look at the next one. Click the Routines button now to display information about the routines of class LIST :
+ [[Image:index-36]] [[general/guided_tour/studio/index-36.png|(link)]]
+The sections of this display group routines according to the ancestors of LIST -- including LIST itself -- that first introduced them; for example (second and third sections) extendible originally comes from COLLECTION and extend from BAG . Much of the benefit of this display comes from its support for browsing: all the colored elements, representing classes and features, will be "clickable" hyperlinks.
+
+The remaining Class View buttons all display information in the same format. Each selects a specific subset of the target class's features. The last two selected attributes and routines. You can now try any of the others by clicking the corresponding button:
+* Deferred features: abstract features which don't have an implementation in the current class, only in eventual descendants. Try this for LIST ; you'll see that this deferred class indeed has a number of deferred features.
+* Once and constants : constant attributes, "once functions" which provide shared objects (close to the "singleton" pattern), and once procedures which provide a convenient initialization mechanism. LIST has 'Operating_environment' and 'Io' inherited from the parent class ANY.
+* External features, implemented as calls to routines, macros or other elements implemented in other languages. LIST hasn't any.
+* Exported features: those available to all clients. LIST has quite a few.
+
+[[6 STARTING TO BROWSE|<< Previous]] [[8 PRODUCING AND EXPORTING DOCUMENTATION|Next >>]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/index.wiki
new file mode 100644
index 00000000..41181954
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Browsing]]
+[[Property:weight|1]]
+* [[Searching|Searching]]
+* [[Viewing information about a component|Viewing information about a component]]
+* [[Opening new windows|Opening a new window]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/opening-new-windows.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/opening-new-windows.wiki
new file mode 100644
index 00000000..77b8151b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/opening-new-windows.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Opening new windows]]
+[[Property:weight|2]]
+There are several ways to open a new window. First, you can use the pick and drop shortcut. Then, you can use new window menu items and the corresponding icons. There are three such commands:
+* Clicking on '''New window''' in the '''File''' menu or on [[Image:new-window-icon]] make an new window appear. In this window, the editor and the context tool will be visible.
+* Clicking on '''New editor window''' in the '''File''' menu or on [[Image:new-editor-icon]] does the same as the previous command but the context tool is minimized in the new window.
+* Clicking on '''New context window''' in the '''File''' menu make this time a new window with a minimized editor appear.
+ '''Note''': Icons mentioned above are droppable: instead of simply clicking on them, you can drop a stone on them. The tools in the new window will then be centered on the corresponding component.
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/index.wiki
new file mode 100644
index 00000000..ae813f01
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Searching]]
+[[Property:weight|0]]
+* [[Looking for a cluster|Looking for a cluster]]
+* [[Looking for a class|Looking for a class]]
+* [[Looking for a feature|Looking for a feature]]
+* [[Looking for an expression in a text|Looking for an expression]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-class.wiki
new file mode 100644
index 00000000..ed65f57a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-class.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Looking for a class]]
+[[Property:weight|1]]
+There are two simple ways to find a class if you know its name or a part of it :
+* You may use the [[Cluster tool: Introduction|cluster tool]] . This tool presents the entire universe of your project. By developing the [[System tree representation|cluster tree]] , you will be able to find what you are looking for. This method is quick if you already have an idea of where the class is in the universe.
+* Using [[Address bars: Introduction|address bars]] will be quicker if you do not have this information or if the size of your project is important. If you type the name of the searched class (you can use wildcards, i.e."*" and "?") in the [[Main address bar|main address bar]] - and then select the right class in the displayed list if there are several possibilities - the editor will be centered on the class you are looking for. The information about the class location will be displayed in the title bar of the window. If you need more complete information about the class location, you can [[Pick-and-drop mechanism|pick]] the name of the class in the editor and drop it on the [[Locate command|view icon ]] [[Image:general-search-icon]] of the [[Cluster tool: Introduction|cluster tool]] . This tool will then show where the class is in the universe.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-cluster.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-cluster.wiki
new file mode 100644
index 00000000..effa75e3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-cluster.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Looking for a cluster]]
+[[Property:weight|0]]
+If you know the name of a cluster but not where it is located in the system, there are two ways to find this out:
+* You can try to find it in the [[Cluster tool: Introduction|cluster tool]] by expanding the cluster tree.
+* In a window where the context tool is independent from the editor, you can type the name of the cluster in [[Context tool address bar|context tool address bar]] . You may use wildcards ("*" or "?") if you know only a part of the name. You can then locate the cluster in the system by [[Pick-and-drop mechanism|picking]] the cluster stone in the [[Context tool address bar|address bar]] and dropping it on the [[Locate command|view icon ]] [[Image:general-search-icon]] of the [[Cluster tool: Introduction|cluster tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-expression-text.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-expression-text.wiki
new file mode 100644
index 00000000..f67c4876
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-expression-text.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Looking for an expression in a text]]
+[[Property:link_title|Looking for an expression in text]]
+[[Property:weight|3]]
+To find a word or an expression in a text, you can use the [[Search tool|search tool]] . If it is not displayed, you can make it appear by clicking on its icon [[Image:tool-search-icon]] in the tool bar. This tool will allow you to search a word or a regular expression and to replace it if you want to. It can be case sensitive and look for isolated words.
+'''Note''': The [[Search tool|search tool]] will look for the wanted word in the editor or in the context tool, depending on which one has the focus.
+
+{{tip| '''Tip''': There are several accelerators that will make it even easier to perform a search. They are detailed in the [[Search functionality|editor help]] . }}
+
+{{tip| '''Tip''': You can use the quicksearch to search in the current text. Press CTRL + F to get the quick search bar. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-feature.wiki
new file mode 100644
index 00000000..9c8a005e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-feature.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Looking for a feature]]
+[[Property:weight|2]]
+There are many ways to find a feature in a class. In particular :
+* You can use the [[Feature tool: Introduction|feature tool]] and search the tree by expanding feature clauses. This tool, however, displays only the features that are defined or redefined in the current class text. If you do not know if the feature is inherited or not, you may therefore not find what you are looking for with this method.
+* You can also use the [[Class formatters: Introduction|class tab]] in the context tool. It will allow you to see all the [[Attributes| attributes]] or [[Routines|routines]] , or all the [[Exported features|public features]] for instance. If you do not know if the feature you seek is an attributes or a function and if it is public, this may not be the right method either.
+* If you know the name or a part of the name of the feature you are looking for, the easier and faster way will probably be to use the [[Main address bar|address bar]] . If you type this name in the feature field of the bar (using "*" and "?" wildcards if you want to), the editor will be centered on the right class if necessary (i.e. if the feature is inherited) and scroll to the position of the text of the feature.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/centering-tools-component.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/centering-tools-component.wiki
new file mode 100644
index 00000000..b790e17c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/centering-tools-component.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Centering tools on a component]]
+[[Property:weight|0]]
+There are three kind of tools directly available in a default development tool : [[Browsing tools: Introduction|browsing tools]] on the left, the [[EiffelStudio Editor Introduction|editor]] on the upper right and context tools on the lower right. No browsing tool, except the feature tool, displays information about a particular component. On the contrary, the editor and context tools display information about a given cluster, class or feature : they are centered on this component. There are several ways to center the editor on an element:
+* use the [[Main address bar|address bar]] on the top of the editor. It allows you to set which class (and even which feature in the class) you want the editor to display. You may use wildcards ("?" or "*") as you type the names of these components.
+* use [[Pick-and-drop mechanism|pick and drop]] . Pick a cluster, class or feature stone anywhere in EiffelStudio and drop it in the editor. It will center it on the component automatically.
+* find it in the [[Cluster tool: Introduction|cluster]] , [[Feature tool: Introduction|feature]] or [[Favorites tool: Introduction|favorites]] tool and click it.
+The context tool can be [[Change data share mode|independent]] from the editor. If it is not, both the editor and the context tool will be centered on the same component. If it is, there is a [[Context tool address bar|second address bar]] , in the context tool title bar. You may then center the context tool on a component by using the three methods described for the editor. You can also center the context tool on the same component as the editor ( the context tool remaining independent): Just click [[Image:context-sync-icon]] or select '''Send to the context''' tool in the '''View''' menu.
+To make the context tool independent if it is not, click [[Image:context-link-icon]] or select '''Isolate context tool''' in the '''View''' menu. To do the opposite, click the same icon or select '''Merge context tool''' in the '''View''' menu.
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/index.wiki
new file mode 100644
index 00000000..aa1b021e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Viewing information about a component]]
+[[Property:weight|1]]
+* [[Centering tools on a component|Centering tools on a component]]
+* [[Viewing information about a cluster|Viewing information about a cluster]]
+* [[Viewing information about a class|Viewing information about a class]]
+* [[Viewing information about a feature|Viewing information about a feature]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-class.wiki
new file mode 100644
index 00000000..86c59ca0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-class.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Viewing information about a class]]
+[[Property:weight|2]]
+Once you [[Centering tools on a component|centered the editor]] on a class, you have access to its [[Class formatters: Basic text view|basic text]] . If the class is compiled, the [[Feature tool: Introduction|feature tool]] shows the list of the features that are defined or redefined in this text. You can also view [[Clickable view|clickable]] , [[Class formatters: Flat view|flat]] , [[Flat Contract view|flat contract]] and [[Contract view|contract]] views of the class in the editor. The class tab in the context tool can display more information. If the [[Centering tools on a component|context tool is independent]] , [[Centering tools on a component|center it]] on the wanted class and select this tab. You can then see information about the features ( [[Routines|routines]] , [[Attributes|attributes]] , [[Exported features|exported features, ]] [[Class views|etc.]] ..) of the class, its [[Ancestors|ancestors]] and [[Descendants|descendants]] or its [[Clients|clients]] and [[Suppliers|suppliers]] .
+The [[Metric tool: Introduction|metric tool]] provides another kind of data. It allows you to compute a complete set of [[How to analyze a project: Introduction|measures ]] on your class.
+{{seealso| '''See Also'''
+[[Looking for a class|Looking for a class]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-cluster.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-cluster.wiki
new file mode 100644
index 00000000..f8c410b1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-cluster.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Viewing information about a cluster]]
+[[Property:weight|1]]
+To view information about a cluster, you have to center the context tool on this component. Then the [[Metric tool: Introduction|metric tool]] will provide a complete set of measures that you will able to compute.
+{{seealso| '''See Also'''
+[[Looking for a cluster|Looking for a cluster]]
+[[How to analyze a project: Introduction|Analysing a project]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-feature.wiki
new file mode 100644
index 00000000..90e00f69
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-feature.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Viewing information about a feature]]
+[[Property:weight|3]]
+Once you [[Centering tools on a component|centered the editor]] on a feature, you have access to its text. The feature tab in the context tool can display more information. To have access to it, you have first to center the context tool on the wanted class and select the feature tab. You can then consult the different views of the text of the feature ( [[Feature formatters: Basic text view|basic text]] or [[Feature formatters: Flat view|flat]] ) and other information such as its [[Callers|callers]] or its [[Descendant versions|descendant]] versions.
+The [[Metric tool: Introduction|metric tool]] provides another kind of data. It enables you to compute some [[How to analyze a project: Introduction|measures]] on your feature.
+{{seealso| '''See Also'''
+[[Looking for a feature|Looking for a feature]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/enabling-profiler.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/enabling-profiler.wiki
new file mode 100644
index 00000000..6088f96b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/enabling-profiler.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Enabling the profiler]]
+[[Property:weight|4]]
+To profile an executable, the profiler must first be enabled. To enable the profiler:
+* Open the [[General Target Options|Project Settings]] dialog.
+* In the '''Target''' section, enable '''Profile'''.
+* Click '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|Profiler reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/generating-executables.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/generating-executables.wiki
new file mode 100644
index 00000000..1677ecc8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/generating-executables.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Generating executables]]
+[[Property:weight|0]]
+There are several ways to compile an executable with EiffelStudio.
+
+Compilation modes include the following: melting, freezing and finalizing. To learn more about the compilation semantics in EiffelStudio, see the [[Compiler: introduction|compiler reference]] .
+
+There is a command for all compilation modes in the '''Project''' menu, under the entries '''Compile''', '''Freeze''' and '''Finalize'''. There is also a
+
+These commands are also available in the '''Project''' toolbar [[Image:project-melt-icon]] , [[Image:project-freeze-icon]] , [[Image:project-finalize-icon]] .
+
+To solve the errors that occur during the Eiffel compilation, use the [[Error wizard|compilation error wizard]] . For errors occurring during the C compilation, check that the installation is not corrupted and refer to your C compiler documentation for more information.
+
+{{seealso| '''See Also'''
+[[Command line: Introduction|Command line options]]
+[[Compiler: introduction|Compiler reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/generating-libraries.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/generating-libraries.wiki
new file mode 100644
index 00000000..23274394
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/generating-libraries.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Generating libraries]]
+[[Property:weight|1]]
+There are two main types of libraries in Eiffel: precompiled Eiffel libraries and C libraries. Both kinds of libraries can be created via EiffelStudio. The former can only be used in Eiffel projects, C libraries can be used either in Eiffel programs, or in standard C programs.
+
+To generate an Eiffel precompiled library:
+* Select the '''Precompilation Wizard''' in the '''Tools''' menu and follow the instructions,
+
+or
+* Launch a new EiffelStudio session,
+* Select your project
+* Change the action to '''Precompile''',
+* Click '''Open'''
+
+To generate a dynamically linked C library using Eiffel code:
+* Generate a definition file for this library, via the [[Dynamic library builder|Dynamic library Builder]] ,
+* Open the [[Advanced Options|Project Settings]] dialog,
+* In the '''Advanced''' section, set the '''Shared Library Definition''',
+* Enter the name of the definition you created in the first step(including the path if necessary),
+* Compile the current project.
+
+The generated C library should be located in the EIFGENs|target_name|W_code directory in the directory of your project.
+
+To generate a C library from a C compiler, please refer to the documentation of your C compiler.
+
+{{seealso| '''See Also'''
+[[Using libraries|Using libraries]]
+[[CECIL|CECIL library: calling Eiffel routines from C programs]]
+[[Command line: Introduction|Command line options]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/index.wiki
new file mode 100644
index 00000000..e5387381
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Compiling]]
+[[Property:weight|3]]
+* [[Generating executables|Generating executables]]
+* [[Generating libraries|Generating libraries]]
+* [[Setting the assertion level|Changing the assertion level]]
+* [[Enabling the profiler|Enabling the profiler]]
+* [[Using libraries|Using libraries]]
+* [[Tuning a program|Tuning a program]]
+* [[Using threads|Using threads]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/setting-assertion-level.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/setting-assertion-level.wiki
new file mode 100644
index 00000000..a27011f1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/setting-assertion-level.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Setting the assertion level]]
+[[Property:weight|2]]
+To modify the assertion level in a generated binary (executable or library),
+* Open the [[Assertion Options|Project Settings]] dialog.
+* In the '''Target, Assertions'''section, select the assertions you want to check (among require, ensure, check, loop and class invariant).
+* Click '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+{{seealso| '''See Also'''
+[[8 Design by Contract (tm), Assertions and Exceptions|Assertions in Eiffel]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki
new file mode 100644
index 00000000..6f8723fb
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Tuning a program]]
+[[Property:weight|6]]
+The best way to speed up a program is of course to improve the algorithms and data structures you are using. Spotting the functions that slow down the execution and improving can change a lot in a program. [[Profiling|Profiling]] can be used for this.
+
+Try to keep the number of classes and objects in your system as low as possible to ensure maximum efficiency. This should never hinder the design of the system, though.
+
+You can also use the functionality provided by the [[ref:/libraries/base/reference/memory_chart|MEMORY]] class to tweak the garbage collector behavior according to your needs. However, be careful with this, since providing erroneous parameters might lead to memory leaks, huge memory consumption, or on the contrary a dramatic slow down of the application. If you are not entirely sure what a parameter is for, avoid changing it. The default values should fit for most standard applications.
+
+On top of that, EiffelStudio provides powerful optimizations, some being done automatically, others being configurable. To obtain a maximum efficiency, it is recommended to [[Generating executables|Finalize]] your program from scratch and without using precompiled libraries.
+
+In the [[Advanced Options|Project Settings dialog advanced section]] , try experimenting with the '''Inlining''' option, and setting the maximum size of features that should be inlined. Only Eiffel features are inlined by this option, to see how to inline the C functions you may be using in your program, please refer to your C compiler documentation.
+
+In the [[Advanced Options|Project Settings dialog advanced section]] , enabling the '''Dead code removal''' will help produce smaller executables.
+
+Removing the '''Execution Trace''' will optimize the executable in size and speed, but in case of crash no information will be available.
+
+All these options are located in the [[Advanced Options|Project Settings]] dialog, in the '''Advanced''' section. They are only effective during finalizations.
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|Profiler reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-libraries.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-libraries.wiki
new file mode 100644
index 00000000..e77e02e2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-libraries.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Using libraries]]
+[[Property:weight|5]]
+There are two kinds of libraries in Eiffel: precompiled Eiffel libraries and C libraries.
+
+To use an Eiffel precompiled library:
+* Open the [[Group Options|Project Settings]] dialog.
+* Add a new precompile group to your target.
+* You must [[Generating executables|recompile]] your project from scratch for the changes to take effect.
+
+{{note| '''Note''': You can only use one precompiled library at a time in a project. To use more than one, you should precompile all the libraries you want to use together in a single precompiled library. }}
+
+To use a C library:
+* Open the [[Externals Options|Project Settings]] dialog.
+* Add an include external for the directory where the header files needed to use the library are.
+* Add an object external for each object file needed to use the library. These files can be either library files (.lib, .a, etc) or object files (.obj, .o, etc)
+* Click '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+{{seealso| '''See Also'''
+[[Generating libraries|Creating libraries]]
+[[Adding a cluster|Adding classes and clusters from Eiffel libraries without precompiling the library]]
+[[C externals|Making C calls in Eiffel]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki
new file mode 100644
index 00000000..47ff0a9a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Using threads]]
+[[Property:weight|7]]
+Eiffel supports multithreaded programs. The [[EiffelThread Library|thread library]] provides ways to handle threads safely inside an Eiffel program. Make sure you [[Adding a library|add]] it to your project if you want to use threads.
+
+To create a multithreaded program or library:
+* Open the [[Advanced Options|Project Settings]] dialog.
+* In the '''Advanced''' section, enable '''Multithreaded''' option.
+* Click '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+{{warning| '''Caution''': Make sure the external and precompiled libraries you use have also been compiled with support for threads. }}
+
+{{seealso| '''See Also'''
+[[Generating libraries|Creating libraries]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-default-history-size.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-default-history-size.wiki
new file mode 100644
index 00000000..4f082efc
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-default-history-size.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Changing the default history size]]
+[[Property:weight|4]]
+By default, there may not be more than 10 items in the history of a development window. It means that combo boxes in the [[Main address bar|address bar]] will let you choose between at most 10 possibilities. You can change this number.
+To do so, use the [[Preference window overview|preference window]] : select '''Preferences''' in the '''Tools''' menu. Then in the preferences tree, select the "Browsing tools "sub-category in the "Tools" category. On the right part of the window, a list of preferences will appear, including "number of items displayed in the history combo boxes". Click on this item and enter the new value.
+
+Click on '''save and exit''' to complete the change.
+
+{{seealso| '''See Also'''
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences: Introduction|Preferences reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-texts-display.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-texts-display.wiki
new file mode 100644
index 00000000..1bd2dba9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-texts-display.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Changing texts display]]
+[[Property:weight|1]]
+By modifying EiffelStudio [[EiffelStudio preferences: Introduction|preferences]] , you can change the font and the colors used to display texts in the editor. For more information, refer to EiffelStudio [[Interface|graphical preferences reference]] .
+{{seealso| '''See Also'''
+[[Customizing class text views|Customizing formatted output]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/choosing-classes-be-ignored-bon-diagrams.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/choosing-classes-be-ignored-bon-diagrams.wiki
new file mode 100644
index 00000000..9e3fa465
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/choosing-classes-be-ignored-bon-diagrams.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Choosing classes to be ignored in BON diagrams]]
+[[Property:weight|5]]
+Every class in your system inherits from ANY. INTEGER, like other classes that represent basic types, is very often a supplier of the classes the user wrote. It may therefore not be interesting to display classes such as ANY or INTEGER in [[Diagram tool: Introduction|BON diagrams]] .
+EiffelStudio allows you to customize a list of classes that it has to ignore when it creates diagrams. This list is stored in the [[EiffelStudio preferences: Introduction|preferences]] . To modify it, first open the [[Preference window overview|preferences window]] by choosing '''Preferences...''' in the '''Tools''' menu. Select then the "context tool" sub-category of the "Tools" category in the preferences tree. On the right, you will then see a table of preferences, which includes "Show ALL classes in the diagram" and "Names of classes that should not appear in generated diagrams". If "Show ALL classes in the diagram" is not False, click on it and set it to False. Then click on "Names of classes that should not appear in generated diagrams" and edit the list. Class names must be separated by semicolons.
+
+After modifying the list, click on '''save and exit''' to complete the change.
+
+{{seealso| '''See Also'''
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences: Introduction|Preferences reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/configuring-external-editor.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/configuring-external-editor.wiki
new file mode 100644
index 00000000..b61cfb3c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/configuring-external-editor.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Configuring an external editor]]
+[[Property:weight|7]]
+By clicking on, or by [[Pick-and-drop mechanism|dropping a pebble]] on the external editor toolbar button( [[Image:command-send-to-external-editor-icon]] ), you can launch an external editor. By default, this editor is VI on Unix and Notepad on Windows. You can tell EiffelStudio to launch another editor by editing the preferences.
+To do so, first open the [[Preferences Reference|preferences window]] by choosing '''Preferences...''' in the '''Tools''' menu. Select then the "Global preferences" category in the preferences tree. Click on "Command used to launch an external editor" and modify the command line so that it calls your favorite editor. You can use keywords that represent the filename ($target)and the line number ($line) as is explained in the [[Preferences Reference|preferences reference]] .
+
+After modifying the command line, click on '''save and exit''' to complete the change.
+
+{{seealso| '''See Also'''
+[[Preferences Reference|Preference window description]]
+[[EiffelStudio preferences: Introduction|Preferences reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-class-text-views.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-class-text-views.wiki
new file mode 100644
index 00000000..a8798503
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-class-text-views.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Customizing class text views]]
+[[Property:weight|6]]
+It is possible in EiffelStudio to customize some properties of [[Formatters: Introduction|class text views]] (other than basic texts) displayed in the editor or class and feature tabs of the context tool. Besides [[Changing texts display|graphical appearance]] , you may modify:
+* the order of feature clauses.
+* the type of callers and suppliers displayed in the corresponding views.
+* the views that are selected by default.
+* the indexing clauses that should not be displayed.
+These properties are set in the [[EiffelStudio preferences: Introduction|preferences]] . You can modify them in the [[Preference window overview|preferences window]] . To open this window, select '''Preferences...''' in the '''Tool''' menu. Then select the "Context tool" sub-category of the "Tools" category in the preferences tree. Click then on a preference on the right to modify its value.
+Click on '''save and exit''' to complete the changes.
+
+{{seealso| '''See Also'''
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences: Introduction|Preferences reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-toolbars.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-toolbars.wiki
new file mode 100644
index 00000000..5cd6248b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-toolbars.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Customizing toolbars]]
+[[Property:weight|2]]
+There may be up to 26 buttons in the [[Main toolbars|standard toolbar]] and up to 17 in the [[Main toolbars|project toolbar]] . All those buttons are not shown by default though. Only 16 icons are displayed in the default standard toolbar for instance.
+It is possible to choose which button are shown and in which order they appear in the toolbars. To do so, use [[Toolbar customization|toolbar customization]] windows. they appear when you choose '''Customize standard toolbar...''' or '''Customize project toolbar...''' in the toolbars sub-menu of the View menu or in the contextual menu of the toolbars (which is displayed when you right-click in the empty space on the right of the toolbars).
+
+{{seealso| '''See Also'''
+[[Main toolbars|The toolbars and their buttons]]
+[[Toolbar customization|Toolbars customization windows]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/index.wiki
new file mode 100644
index 00000000..d9e838a6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Customizing EiffelStudio]]
+[[Property:weight|8]]
+* [[Setting the editor behavior|Setting the editor behavior]]
+* [[Changing texts display|Changing texts display]]
+* [[Customizing toolbars|Customizing toolbars]]
+* [[Making the context tool independent from the editor|Making the context tool independent from the editor]]
+* [[Changing the default history size|Changing the default history size]]
+* [[Choosing classes to be ignored in BON diagrams|Choosing classes to be ignored in bon diagrams]]
+* [[Customizing class text views|Customizing class text views]]
+* [[Configuring an external editor|Configuring an external editor]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/making-context-tool-independent-editor.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/making-context-tool-independent-editor.wiki
new file mode 100644
index 00000000..8ead7a8b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/making-context-tool-independent-editor.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Making the context tool independent from the editor]]
+[[Property:weight|3]]
+By default, [[EiffelStudio Editor Introduction|the editor]] and the [[EiffelStudio window overview|context tool]] are [[Centering tools on a component|centered]] on the same cluster, class or feature. It is possible to make the context tool independent from the editor. It has then its own address bar and can display information on a totally different component than the one on which the editor is centered.
+To do so, click on or select '''Isolate context tool''' in the '''View''' menu. To go back to the previous configuration, click on the same icon again or select '''Merge context tool''' in the '''View''' menu.
+
+You can also modify the [[EiffelStudio preferences: Introduction|preferences]] so that next time a window is opened, its context tool will be automatically independent: open the [[Preference window overview|preferences window]] by choosing '''Preferences...''' in the '''Tools''' menu. Select then the "context tool" sub-category in the "Tools" of the preferences tree. Lastly click on "Share addresses between the editor and the context tool" and set it to '''False'''.
+Click on save and exit to complete the change.
+
+{{seealso| '''See Also'''
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences: Introduction|Preferences reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/setting-editor-behavior.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/setting-editor-behavior.wiki
new file mode 100644
index 00000000..8ee38161
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/setting-editor-behavior.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Setting the editor behavior]]
+[[Property:weight|0]]
+Some of [[EiffelStudio Editor Introduction|the editor]] properties are customizable. [[Automatic completion: Introduction|Automatic completion]] , for instance, can be partially or totally disabled, and inserted strings can be defined by the user. Some accelerators are customizable too. For more information, please refer to the [[Editor Preferences|editor preferences reference]] .
+{{seealso| '''See Also'''
+[[Changing texts display|Text colors and font customization.]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-class.wiki
new file mode 100644
index 00000000..6d31b125
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-class.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Creating a new class]]
+[[Property:weight|0]]
+* To create a new class pick from the '''Create a new class''' button. [[Image:16x16--new-class-icon]] Then drop on the diagram where you want to place the class bubble. A dialog now appears where you can enter a name and specify the cluster.
+
+{{seealso|'''See Also'''
+[[New class command|Creating a new class using the address bar]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-feature.wiki
new file mode 100644
index 00000000..33fc1517
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-feature.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Creating a new feature]]
+[[Property:weight|1]]
+To create a new feature just [[Creating client/supplier links|add a new client link]] in the diagram.
+{{seealso| '''See Also'''
+[[Adding a feature: Introduction|Creating a new feature]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/deleting-items.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/deleting-items.wiki
new file mode 100644
index 00000000..34ee4104
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/deleting-items.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Deleting items]]
+[[Property:weight|6]]
+* Pick-and-drop the item you want to remove in the '''Delete''' hole. [[Image:16x16--general-delete-icon]] For links, the associated Eiffel code will be removed from the class text. Clusters and classes will be deleted from disk!
+
+{{warning| '''Caution''': An action that deletes one or more files or directories cannot be undone! }}
+
+{{tip| '''Tip''': Turn on '''Automatic backups'''. EiffelStudio will make a copy of each class file every time a compilation is done. }}
+
+{{seealso|'''See also'''
+[[Removing items from a view|Removing items from the view only]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/index.wiki
new file mode 100644
index 00000000..00116694
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Altering the system]]
+[[Property:weight|2]]
+* [[Creating a new class|Creating a new class]]
+* [[Creating a new feature|Creating a new feature]]
+* [[Refactoring|Refactoring]]
+** [[Rename class|Class Rename]]
+** [[Rename Feature|Feature Rename]]
+** [[Pull up Feature|Feature Pull up]]
+
+* [[Deleting items|Deleting items]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/index.wiki
new file mode 100644
index 00000000..0de4d891
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Refactoring]]
+[[Property:weight|2]]
+There are several different refactorings available. Refactorings start with a compilation and also end with a compilation. Refactoring have a separate undo functionality which allows to undo a refactoring as long as no changes have been done to the classes that have been refactored.
+
+* [[Rename class|Class Rename]]
+* [[Rename Feature|Feature Rename]]
+* [[Pull up Feature|Feature Pull up]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/pull-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/pull-feature.wiki
new file mode 100644
index 00000000..14c57a2c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/pull-feature.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Pull up Feature]]
+[[Property:weight|5]]
+# Start pick-and-drop on the feature bubble which you want to pull up.
+# Drop it in the '''Pull up Feature''' hole. [[Image:refactor-feature-up-icon]]
+# After a compilation the '''Select Class''' dialog appears. You can choose the parent where to pull the feature.
+# Click '''OK'''.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-class.wiki
new file mode 100644
index 00000000..e437f51a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-class.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Rename class]]
+[[Property:link_title|Rename Class]]
+[[Property:weight|3]]
+# Start pick-and-drop on the class bubble of which you want to change the name.
+# Drop it in the '''Rename Feature/Class''' hole. [[Image:refactor-rename-icon]]
+# After a compilation the '''Refactoring: Class Rename''' dialog appears. You can enter a new name.
+
+
+# You can choose between these options:
+#* '''Compiled Classes''': only to the refactoring in compiled classes.
+#* '''All Classes''': do the refactoring in all classes, even in uncompiled classes.
+#* '''Rename File''': rename the file of the class to correspond with the class name, if another file with this name already exists the file will not be renamed and a warning will be given.
+#* '''Replace Name in Comments''': replace usage of the class name in comments that follow the '''{CLASSNAME}''' syntax.
+#* '''Replace Name in Strings''': replace usage of the class name in strings that follow the '''{CLASSNAME}''' syntax.
+
+# Click '''OK'''.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-feature.wiki
new file mode 100644
index 00000000..9ea6c319
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-feature.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Rename Feature]]
+[[Property:weight|4]]
+# Start pick-and-drop on the feature bubble of which you want to change the name.
+# Drop it in the '''Rename Feature/Class''' hole. [[Image:refactor-rename-icon]]
+# After a compilation the '''Refactoring: Feature Rename''' dialog appears. You can enter a new name.
+
+
+# You can choose between these options:
+#* '''Replace Name in Comments''': replace usage of the feature name in comments that follow the '''`featurename'''' syntax.
+#* '''Replace Name in Strings''': replace usage of the feature name in strings that follow the '''`featurename'''' syntax.
+
+# Click '''OK'''.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/exporting-diagram-png-image-file.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/exporting-diagram-png-image-file.wiki
new file mode 100644
index 00000000..ab543875
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/exporting-diagram-png-image-file.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Exporting a diagram to PNG image file]]
+[[Property:weight|6]]
+* To save the current diagram to an image file, click '''Export diagram to PNG'''. [[Image:diagram-export-to-png-icon]]
+A dialog will pop up where you can specify a location for the generated file.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/index.wiki
new file mode 100644
index 00000000..08f1106b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Designing a project]]
+[[Property:weight|5]]
+* [[Switching to the diagram tool|Switching to the diagram tool]]
+* [[Undoing and redoing|Undoing and redoing]]
+* [[Altering the system|Altering the system]]
+* [[Managing links|Managing links]]
+* [[Modifying the display|Modifying the display]]
+* [[Managing views|Managing views]]
+* [[Exporting a diagram to PNG image file|Exporting a diagram to PNG image file]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-aggregate-clientsupplier-links.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-aggregate-clientsupplier-links.wiki
new file mode 100644
index 00000000..6cfd44bb
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-aggregate-clientsupplier-links.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Creating aggregate client/supplier links]]
+[[Property:weight|2]]
+# Select the button '''Create new aggregate client/supplier links'''. [[Image:new-aggregate-supplier-link-icon]]
+# Start pick-and-drop on the class where the feature should be added.
+# Drop on the desired supplier class.
+# The '''Create feature''' dialog appears. See [[Adding an attribute|Creating an attribute]] or [[Adding a function|Creating a function]] using the feature wizard for more information.
+
+{{seealso|'''See Also'''
+[[Creating client/supplier links|Creating client/supplier links]]
+[[Creating inheritance links|Creating Inheritance links]]
+[[New feature dialog: Introduction|Feature wizard]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-clientsupplier-links.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-clientsupplier-links.wiki
new file mode 100644
index 00000000..6f5ed636
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-clientsupplier-links.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Creating client/supplier links]]
+[[Property:weight|1]]
+# Select the button '''Create new client/supplier links'''. [[Image:new-supplier-link-icon]]
+# Start pick-and-drop on the class where the feature should be added.
+# Drop on the desired supplier class.
+# The '''Create feature''' dialog appears. See [[Adding an attribute|Creating an attribute]] or [[Adding a function|Creating a function]] using the feature wizard for more information.
+
+{{seealso|'''See Also'''
+[[Creating aggregate client/supplier links|Creating aggregate client/supplier links]]
+[[Creating inheritance links|Creating Inheritance links]]
+[[New feature dialog: Introduction|Feature wizard]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-handles.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-handles.wiki
new file mode 100644
index 00000000..64e3dfb9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-handles.wiki
@@ -0,0 +1,6 @@
+[[Property:title|Creating handles]]
+[[Property:weight|4]]
+Once you have created a link to show the relationship between the classes in your system you may wish to organize them. One technique for doing this easily is to create handles in the links. A handle is simply a point anywhere along the link that causes the link to change direction. To create a handle just click the mouse at the exact point on the link you wish to put the handle and then drag it to where you want the handle to be positioned in the overall diagram. You can create as many handles as you wish and use them to organize you diagram so that it is easier to interpret and so that links do not get too jumbled and become incoherent.
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-inheritance-links.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-inheritance-links.wiki
new file mode 100644
index 00000000..60c92e2a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-inheritance-links.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Creating inheritance links]]
+[[Property:weight|0]]
+# Select the button '''Create new inheritance links'''. [[Image:new-inheritance-link-icon]]
+# Start pick-and-drop on the class where the parent should be added.
+# Drop on the desired parent class.
+
+{{note| '''Note''': This action will also add the parent in the class text. }}
+
+{{seealso| '''See Also'''
+[[Creating client/supplier links|Creating client/supplier links]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/index.wiki
new file mode 100644
index 00000000..38e50702
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Managing links]]
+[[Property:weight|3]]
+* [[Creating inheritance links|Creating inheritance links]]
+* [[Creating client/supplier links|Creating client/supplier links]]
+* [[Creating aggregate client/supplier links|Creating aggregate client/supplier links]]
+* [[Creating handles|Creating handles]]
+* [[Using the link tool|Using the link tool]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/using-link-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/using-link-tool.wiki
new file mode 100644
index 00000000..9c0d9a7f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/using-link-tool.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Using the link tool]]
+[[Property:weight|3]]
+If you do not want straight arrows, you can insert handles on them. It is recommended that you use the link tool to do this, because it inserts the handles so that the angles in the line are exactly 90 degrees.
+# To apply straight angles to a link, drop it in the '''Put handles on a link''' hole. [[Image:diagram-force-right-angles-icon]]
+# The '''Link tool''' appears. Select the type of angle(s) you want for the link.
+[[Image:link-tool]]
+The combinations of handles you can apply to your link are:
+#* Put handle left
+ [[Image:link-tool-left]]
+#* Put handle right
+ [[Image:link-tool-right]]
+#* Put two handles left
+ [[Image:link-tool-two-left]]
+#* Put two handles right
+ [[Image:link-tool-two-right]]
+#* Remove handles
+ [[Image:link-tool-no-handles]]
+
+# Click '''OK''' when you are satisfied with the result, pressing '''Cancel''' will put the link back the way it was.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/adding-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/adding-view.wiki
new file mode 100644
index 00000000..ad241a86
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/adding-view.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Adding a view]]
+[[Property:weight|0]]
+# To add a view of the current class or cluster, select the view you want to duplicate to the new one using the '''View''' combo box.
+ [[Image:diagram-defaultview]]
+# Enter the name of the new view in the '''View''' combo box.
+ [[Image:diagram-myview]]
+# Press enter. The view is now created.
+
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/deleting-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/deleting-view.wiki
new file mode 100644
index 00000000..f89bda37
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/deleting-view.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Deleting a view]]
+[[Property:weight|1]]
+# To delete a view, select the view you want to remove using the '''View''' combo box.
+ [[Image:diagram-defaultview]]
+# Click the '''Delete current view''' button. [[Image:16x16--general-delete-icon]]
+
+# If you choose to confirm, the view has been deleted, and the "DEFAULT" view is selected.
+
+
+
+{{note| '''Note''': You cannot delete the view "DEFAULT". }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/index.wiki
new file mode 100644
index 00000000..53c78728
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Managing views]]
+[[Property:weight|5]]
+* [[Adding a view|Adding a view]]
+* [[Deleting a view|Deleting a view]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/adjusting-physics-settings.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/adjusting-physics-settings.wiki
new file mode 100644
index 00000000..fd8248f3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/adjusting-physics-settings.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Adjusting Physics Settings]]
+[[Property:weight|11]]
+* You can adjust the behavour of the physics mode by altering various parameters in the physics settings dialog. To disaply the physics setting dialog press this button [[Image:diagram-physics-settings-icon]] .
+
+{{tip| '''Tip''': To see the effects of each parameter modify it whilst your diagram is in view and you will see the diagram adjust to the new settings dynamically. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/anchoring.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/anchoring.wiki
new file mode 100644
index 00000000..6e183b00
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/anchoring.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Anchoring]]
+[[Property:weight|10]]
+* You may anchor a class to the diagram by right clicking the figure and dropping it onto the anchor button [[Image:diagram-anchor-icon]] .
+
+{{tip| '''Tip''': To see the effects of anchoring [[Turn on Physics Mode|turn on physics mode]] and then anchor a class as described above. Now [[Adjusting Physics Settings|open the physics settings dialog]] and adjust the sliders. In the diagram you will see all anchored classes do not move whilst those surrounding them adjust to the new settings. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/change-display-quality.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/change-display-quality.wiki
new file mode 100644
index 00000000..f8ca9363
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/change-display-quality.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Change the Display Quality]]
+[[Property:weight|7]]
+* To change the display quality of the diagram press the Toggle Quality button [[Image:diagram-toggle-quality-icon]] .
+
+{{tip| '''Tip''': Lower quality display is faster for drawing so is recommended for very large diagrams. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-colors-classes.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-colors-classes.wiki
new file mode 100644
index 00000000..a8de6884
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-colors-classes.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Changing colors of classes]]
+[[Property:weight|3]]
+# Start pick-and-drop on the class bubble you want to change the color of.
+# Drop it in the '''Change color''' hole. [[Image:diagram-choose-color-icon]]
+# A color selection dialog appears. Select the color you want and click '''OK'''.
+[[Image:color-dialog-windows]]
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-system-exploration-depth.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-system-exploration-depth.wiki
new file mode 100644
index 00000000..484c3c73
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-system-exploration-depth.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Changing system exploration depth]]
+[[Property:weight|1]]
+* If you want to change the context of the current cluster or class in the diagram, click the '''Select depth of relations''' button. [[Image:diagram-depth-of-relations-icon]]
+The '''Context''' dialog appears. The layout depends on whether the current context is one of a class or cluster.
+** Context is a class:
+[[Image:context-dialog-class]]
+
+** Context is a cluster:
+[[Image:context-dialog-cluster]]
+
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/iconifying-and-restoring-cluster.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/iconifying-and-restoring-cluster.wiki
new file mode 100644
index 00000000..0cad9f55
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/iconifying-and-restoring-cluster.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Iconifying and restoring a cluster]]
+[[Property:weight|6]]
+* If you do not want to hide the cluster, only its contents, iconify it by double clicking on the cluster label. Double clicking it again returns the cluster to its normal state.
+
+{{tip| '''Tip''': If the entire cluster is of no relevance to your diagram, [[Removing items from a view|hide it from the view]] altogether. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/index.wiki
new file mode 100644
index 00000000..b985b317
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/index.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Modifying the display]]
+[[Property:weight|4]]
+* [[Showing or hiding links and labels|Showing or hiding links and labels]]
+* [[Changing system exploration depth|Changing system exploration depth]]
+* [[Removing items from a view|Removing items from a view]]
+* [[Changing colors of classes|Changing colors of classes]]
+* [[Zooming a diagram|Zooming a diagram]]
+* [[Retrieving all classes into a cluster|Retrieving all classes into a cluster]]
+* [[Iconifying and restoring a cluster|Iconifying and restoring a cluster]]
+* [[Change the Display Quality|Change the Display Quality]]
+* [[Turn on Physics Mode|Turn on Physics Mode]]
+* [[Switching between BON and UML View|Switching between BON and UML View]]
+* [[Anchoring|Anchoring]]
+* [[Adjusting Physics Settings|Adjusting Physics Settings]]
+* [[Using the Cluster Legend|Using the Cluster Legend]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/removing-items-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/removing-items-view.wiki
new file mode 100644
index 00000000..94ceb79e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/removing-items-view.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Removing items from a view]]
+[[Property:weight|2]]
+* To remove an class, cluster, or link from the current view, use pick-and-drop to drop it in the '''Remove figure''' hole. [[Image:general-reset-icon]] . To remove a link handle you can also the same technique
+
+{{note| '''Note''': If you want to remove the item from the system, use the [[Deleting items|Delete]] hole. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/retrieving-all-classes-cluster.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/retrieving-all-classes-cluster.wiki
new file mode 100644
index 00000000..d48891c4
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/retrieving-all-classes-cluster.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Retrieving all classes into a cluster]]
+[[Property:weight|5]]
+* If you have a cluster in your view that is incomplete and you want to show all classes in it, drop the cluster into the '''Include all classes of cluster''' hole. [[Image:diagram-fill-cluster-icon]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/showing-or-hiding-links-and-labels.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/showing-or-hiding-links-and-labels.wiki
new file mode 100644
index 00000000..a85026c0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/showing-or-hiding-links-and-labels.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Showing or hiding links and labels]]
+[[Property:weight|0]]
+* To toggle visibility of all client links, click '''Show/hide client-supplier links'''. [[Image:diagram-supplier-link-icon]]
+* To toggle visibility of all inheritance links, click '''Show/hide inheritance links'''. [[Image:diagram-inheritance-link-icon]]
+* To toggle visibility of all client link labels, click '''Show/hide labels'''. [[Image:diagram-show-labels-icon]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/switching-between-bon-and-uml-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/switching-between-bon-and-uml-view.wiki
new file mode 100644
index 00000000..6ccaa5c3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/switching-between-bon-and-uml-view.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Switching between BON and UML View]]
+[[Property:weight|9]]
+* You can switch the diagran between BON and UML views by pressing the BON/UML Toggle Button [[Image:diagram-view-uml-icon]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/turn-physics-mode.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/turn-physics-mode.wiki
new file mode 100644
index 00000000..45cb0375
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/turn-physics-mode.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Turn on Physics Mode]]
+[[Property:weight|8]]
+* You can turn on and off physics to the diagram by pressing the physics mode button [[Image:diagram-toogle-physics-icon]]
+
+{{tip| '''Tip''': The particular configuration of the classes in your system when using the physics mode is determined by the various settings in the [[Adjusting Physics Settings|Physics Setting Dialog]] . }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/using-cluster-legend.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/using-cluster-legend.wiki
new file mode 100644
index 00000000..6347848c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/using-cluster-legend.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Using the Cluster Legend]]
+[[Property:weight|12]]
+* The cluster legend allows you to quickly determine which classes in the view belong to which clusters in the system by changing the colors to match those of cluster assigned ones. Pressing the legend button [[Image:diagram-show-legend-icon]] will display a list of all the clusters in the system for which at least one class is visible in the view. Next to each cluster name is a color, and pressing the top right color square will automatically set a unique color for each cluster and change the classes belonging to that cluster to match. Pressing again the legend button will hide it from view. The image below shows the legend in use and the classes colored.
+[[Image:cluster-legend]]
+
+{{tip|'''Tip:''' Use the cluster legend also to quickly see sub-cluster organization within your overall cluster design.}}
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/zooming-diagram.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/zooming-diagram.wiki
new file mode 100644
index 00000000..517bcde5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/zooming-diagram.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Zooming a diagram]]
+[[Property:weight|4]]
+* To enlarge the diagram, click '''Zoom in'''. [[Image:diagram-zoom-in-icon]]
+
+* To shrink the diagram, click '''Zoom out'''. [[Image:diagram-zoom-out-icon]]
+
+* To enlarge and shrink the diagram to a specific size use the Zoom combo box, enter the percentage size and press the Enter key.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/switching-diagram-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/switching-diagram-tool.wiki
new file mode 100644
index 00000000..a9b7a997
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/switching-diagram-tool.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Switching to the diagram tool]]
+[[Property:weight|0]]
+* In order to switch from coding to designing, click the '''Diagram''' tab in the '''Context''' tool. Open the context tool by checking menu item '''View | Explorer Bar |Context'''.
+
+{{tip| '''Tip''': To make sure all your changes are in the diagram, perform a compilation. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/undoing-and-redoing.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/undoing-and-redoing.wiki
new file mode 100644
index 00000000..e082b16a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/designing-project/undoing-and-redoing.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Undoing and redoing]]
+[[Property:weight|1]]
+Almost all actions in the diagram tool are undoable. Every action that can be undone, can also be redone. For advanced undoing, open the history tool.
+
+{{tip| '''Tip''': Undo actions cannot be undone. Use redo to undo an undo action. }}
+* To undo the last action, click '''Undo last action'''. [[Image:general-undo-icon]]
+* To redo the last action, click '''Redo last action'''. [[Image:general-redo-icon]]
+* To undo all actions up until a specific action:
+*# Click the '''History tool''' button. [[Image:general-undo-history-icon]]
+*# The '''History tool''' dialog appears with a list of all undoable actions. By clicking on one of the actions, the diagram returns to the state it was in just after you performed this action.
+ [[Image:history-tool]]
+
+
+{{note| '''Note''': When an action is performed that cannot be undone, the history tool is emptied. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-class.wiki
new file mode 100644
index 00000000..d06f5bc5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-class.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Adding a class]]
+[[Property:weight|2]]
+A dialog window is dedicated to the creation of new classes.
+[[Image:new-class-dialog]]
+A list of all the clusters of the system lets you to choose in which one the new class will be inserted. The name of the new class and the name of the corresponding file can be set thank to two text fields above the list. It is also possible to define whether the class should be deferred or expanded, what its creation feature is (if any), what its parents are and whether the default feature clauses should be generated.
+{{tip| '''Tip''': You can change the class text that is generated by default by editing the following files:$ISE_EIFFEL\studio\help\defaults\$ISE_PLATFORM\full.cls (with default feature clauses) and ...\empty.cls (without default feature clauses). }}
+To make the window appear, you can:
+* Click [[Image:16x16--new-class-icon]] in the [[Main toolbars|standard toolbar]] .
+* Select '''New class''' in the '''Tools''' menu.
+* Type the name of the new class in the class field of the [[Main address bar|main address bar]] or the [[Context tool address bar|context tool address bar]] . The current cluster will then be preselected.
+* Use the [[Diagram tool: Introduction|diagram tool]] : Pick the icon [[Image:16x16--new-class-icon]] and drop it on the diagram in the right cluster. This will make the dialog window appear with the chosen cluster selected.
+
+{{seealso| '''See Also'''
+[[Removing a class|Removing a class]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-cluster.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-cluster.wiki
new file mode 100644
index 00000000..da98d105
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-cluster.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Adding a cluster]]
+[[Property:weight|0]]
+It is possible to create new clusters from EiffelStudio. A dialog window has been designed to help you do so.
+[[Image:new-cluster-dialog]]
+
+There are three ways to make this window appear. You can:
+* Click [[Image:16x16--new-cluster-icon]] in the [[Main toolbars|standard toolbar]] .
+* Click [[Image:new-cluster-icon]] in the [[Cluster tool: Introduction|Cluster tool]] .
+* Select '''New cluster''' in the '''Tools''' menu.
+Using this dialog, you can either create a subcluster of an existing cluster or a top-level cluster.
+If you decide to create a top-level cluster, you should give it a name and a path (if the selected path does not exist, it will be created). You can also choose if it should be recursive or not..
+
+If you want to create a subcluster, give it a name and select its parent in the list of available clusters. Giving it a path is not required. If you do not set a path for a new subcluster, it will be located by default in a subdirectory of its parent cluster, named after the subcluster name. This is the recommended way of creating a subcluster (since its path in the configuration file will be automatically relative to the parent), but it is not compulsory.
+
+To import an existing cluster, you can also go to the '''Groups''' section in the [[Group Options|Project Settings dialog]] and click '''Add cluster'''. Although this solution may be slightly more tedious, it gives access to more options.
+
+{{seealso| '''See Also'''
+[[Removing a cluster|Removing a cluster]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-attribute.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-attribute.wiki
new file mode 100644
index 00000000..9f16d036
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-attribute.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Adding an attribute]]
+[[Property:weight|4]]
+Once [[Opening the new feature dialog|the new feature dialog]] is displayed and '''attribute''' selected in '''feature type''', follow the following steps:
+# [[Feature clauses|Choose a feature clause]]
+# [[Name field|Type a name]]
+# [[Type selection|Select the type]]
+# [[Header comment|Type a header comment]]
+# [[Invariant field|Select a class invariant]]
+# [[Set-procedure|Select to create a set-procedure]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-function.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-function.wiki
new file mode 100644
index 00000000..e6e6d689
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-function.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Adding a function]]
+[[Property:weight|3]]
+Once [[Opening the new feature dialog|the new feature dialog]] is displayed and '''function''' selected in '''feature type''', follow the following steps:
+# [[Feature clauses|Choose a feature clause]]
+# [[Name field|Type a name]]
+# [[Argument list|Select formal parameters]]
+# [[Type selection|Select the type]]
+# [[Header comment|Type a header comment]]
+# Enter [[Precondition|precondition]] , [[Local variable|local variable]] , [[Feature body|body]] and [[Postcondition|postcondition]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-procedure.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-procedure.wiki
new file mode 100644
index 00000000..6b6c2f73
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-procedure.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Adding a procedure]]
+[[Property:weight|2]]
+Once [[Opening the new feature dialog|the new feature dialog]] is displayed and '''procedure''' selected in '''feature type''', follow the following steps:
+# [[Feature clauses|Choose a feature clause]]
+# [[Name field|Type a name]]
+# [[Argument list|Select formal parameters]]
+# [[Header comment|Type a header comment]]
+# Enter [[Precondition|precondition]] , [[Local variable|local variable]] , [[Feature body|body]] and [[Postcondition|postcondition]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/index.wiki
new file mode 100644
index 00000000..97ab295a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Adding a feature]]
+[[Property:weight|3]]
+* [[Adding a feature: Introduction|Introduction]]
+* [[Opening the new feature dialog|Opening the new feature dialog]]
+* [[Adding a procedure|Creating a procedure]]
+* [[Adding a function|Creating a function]]
+* [[Adding an attribute|Creating an attribute]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/opening-new-feature-dialog.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/opening-new-feature-dialog.wiki
new file mode 100644
index 00000000..07ece2c0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/opening-new-feature-dialog.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Opening the new feature dialog]]
+[[Property:weight|1]]
+To make the [[New feature dialog overview|new feature window]] appear, you can:
+* Click [[Image:16x16--new-feature-icon]] in the [[Main toolbars|standard toolbar]] .
+* Select '''New feature''' in the '''Tools''' menu.
+* Use the [[Diagram tool: Introduction|diagram tool]] : First, select '''create new client-supplier links''' by clicking on [[Image:new-supplier-link-icon]] .Then, pick the class to which you want to add the new feature. Lastly, drop the pebble on the class that corresponds to the type returned by the new feature.
+This last method does not allow you to create procedures.
+The first thing to do when the dialog is displayed is to choose the kind of feature you want to create. The rest of the process depends on what you selected : [[Adding a procedure|procedure]] , [[Adding a function|function]] or [[Adding an attribute|attribute]] .
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-library.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-library.wiki
new file mode 100644
index 00000000..ced59a2a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-library.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Adding a library]]
+[[Property:weight|1]]
+A dialog window has been designed to help you to add a library to your project.
+[[Image:new-library-dialog]]
+
+There are two ways to make this window appear. You can:
+* Click [[Image:new-library-icon]] in the [[Cluster tool: Introduction|Cluster tool]] .
+* Select '''Add library''' in the '''Tools''' menu.
+Using this dialog, you can either choose a library from a list or select your own library.
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/changing-project-parameters.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/changing-project-parameters.wiki
new file mode 100644
index 00000000..4be434fa
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/changing-project-parameters.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Changing project parameters]]
+[[Property:weight|8]]
+A tool has been designed to help you to modify the settings of your project. To make the Project configuration tool appear, there are two possibilities:
+* Click [[Image:tool-config-icon]] in the [[Main toolbars|standard toolbar]] .
+* Select '''Project settings...''' in the '''Project''' menu.
+This tool will allow you, for instance, to add or remove clusters, set the assertion level or activate debug clauses.
+For more complete information, please refer to the [[EiffelStudio: Project settings window|Project configuration tool help]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/index.wiki
new file mode 100644
index 00000000..d97d84bf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Editing a project]]
+[[Property:weight|2]]
+* [[Adding a cluster|Adding a cluster]]
+* [[Adding a library|Adding a library]]
+* [[Adding a class|Adding a class]]
+* [[Adding a feature|Adding a feature]]
+* [[Removing a cluster|Removing a cluster]]
+* [[Removing a class|Removing a class]]
+* [[Removing a feature|Removing a feature]]
+* [[Moving a class|Moving a class]]
+* [[Changing project parameters|Changing project parameters]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/moving-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/moving-class.wiki
new file mode 100644
index 00000000..c5a5ecb5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/moving-class.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Moving a class]]
+[[Property:weight|7]]
+To move a class from a cluster to another one, you have to use the [[Diagram tool: Introduction|Diagram tool]] . First, [[Centering tools on a component|center the tool]] on the cluster that contains the class you want to move. Then, if the destination cluster is not shown on the diagram, [[Pick-and-drop mechanism|pick]] it in the [[Cluster tool: Introduction|cluster tool]] and drop it in the [[Diagram tool: Introduction|diagram]] . Once both clusters are displayed, you just have to drag the class to its destination.
+{{seealso| '''See Also'''
+[[Looking for a class|Find where a class is]]
+[[Looking for a cluster|Find where a cluster is]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-class.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-class.wiki
new file mode 100644
index 00000000..c7a7bc1d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-class.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Removing a class]]
+[[Property:weight|5]]
+To remove a class, you can:
+* [[Centering tools on a component|Center the editor on the component]] , and click [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or select '''Remove current item''' in the '''Tools''' menu.
+* [[Pick-and-drop mechanism|Drop a pebble]] of this component on [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or in the [[Diagram tool: Introduction|Diagram tool]] [[Diagram toolbar|toolbar]] .
+
+{{warning| '''Caution''': Removing a class from the system implies the deletion of the corresponding file on disk. }}
+
+{{warning| '''Caution''': Picking a feature and dropping it on the delete icon, or calling '''Remove current item''' as the editor is centered on a feature, will not remove the feature but the class to which it belongs. }}
+
+{{seealso| '''See Also'''
+[[Adding a class|Adding a class]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-cluster.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-cluster.wiki
new file mode 100644
index 00000000..84a6b56d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-cluster.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Removing a cluster]]
+[[Property:weight|4]]
+To remove clusters, you can:
+* [[Centering tools on a component|Center the editor on the component]] , and click [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or select '''Remove current item''' in the '''Tools''' menu.
+* [[Pick-and-drop mechanism|Drop a pebble]] of this component on [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or in the [[Diagram tool: Introduction|Diagram tool]] [[Diagram toolbar|toolbar]] .
+* Use the cluster tab in the project configuration window.
+
+{{seealso| '''See also'''
+[[Adding a cluster|Adding a cluster]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-feature.wiki
new file mode 100644
index 00000000..a17789d9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-feature.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Removing a feature]]
+[[Property:weight|6]]
+To remove a feature, you may of course delete the corresponding lines in the class text. You can also use the Diagram tool if it is an attribute or a function. To do so, make sure that supplier links are shown in the diagram (if [[Image:diagram-supplier-link-icon]] is not pressed, click it). Pick the link that correspond to the feature you want to remove and drop the pebble on [[Image:16x16--general-delete-icon]] .
+{{seealso| '''See Also'''
+[[Adding a feature: Introduction|Adding a feature]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki
new file mode 100644
index 00000000..1a0ea6f0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki
@@ -0,0 +1,20 @@
+[[Property:title|EiffelStudio: Creating a new project]]
+[[Property:weight|0]]
+The first thing to do to start Eiffeling is to create a project. Most commands are disabled when no project is created.
+
+When opening EiffelStudio, by default a dialog is popped up that proposes to create or open a project:
+ [[Image:startup-dialog]]
+Under '''Create project''', several options are offered, which depend on the platform you are on.
+* '''Basic application''' is the most basic new project that can be generated. It only includes the [[EiffelBase Library|base library]] and by default only creates the frame of the project. This is the ideal choice to start a textual (console) application, or to discover Eiffel. Indeed, the project is very light and includes only things that are essential in any project. It is available on all platforms.
+* '''.NET application''' has by default all essential components to start a project targeting the Microsoft .NET platform. Of course, it is only available on Windows, and only if you have chosen to install the .NET support during the installation.
+* '''Vision2 application''' creates a new project that includes the [[EiffelVision Introduction|Eiffel Vision2 library]] . This is the perfect choice to start a platform-independent graphic application, or even any graphic application, since EiffelVision2 is easier to use than platform-specific libraries. This option is available on all platforms.
+* '''WEL application''' generates a project using the [[WEL Library|Windows Eiffel Library(WEL)]] . This option is recommended for projects needing advanced Windows features, or Windows applications that are time-critical, since the graphic functionality provided by WEL is more efficient than the one provided by Vision2, which on the other hand provides a platform-independent abstract interface. This wizard is only available on Windows.
+All those options are also available in the ''' File'''/ '''New project...''' menu. This pops up a dialog with all the options to generate a new project: [[Image:create-a-project]]
+{{tip| '''Tip''': If you checked the "Don't show this dialog at startup" checkbox in the start-up dialog but want to get it back, you can use the [[Discardable dialogs|Preferences dialog]] to reset the default value. }}
+
+{{seealso| '''See Also'''
+[[Retrieving a project from a configuration file|Retrieving a project from an configuration file]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/index.wiki
new file mode 100644
index 00000000..88632172
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|EiffelStudio: Starting a project]]
+[[Property:weight|0]]
+* [[EiffelStudio: Creating a new project|Creating a new project]]
+* [[Retrieving a project from a configuration file|Retrieving a project from a configuration file]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/retrieving-project-configuration-file.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/retrieving-project-configuration-file.wiki
new file mode 100644
index 00000000..3c80f67e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/retrieving-project-configuration-file.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Retrieving a project from a configuration file]]
+[[Property:weight|1]]
+If you have already designed a project and want to retrieve it, or if you want to open a project created by someone else (such as the examples of the libraries which are shipped with EiffelStudio), you can either directly select it from the list of last opened projects or use the '''Add Project''' button to open the configuration file.
+
+This dialog also allows you to select which target to compile and you can also specify your own location where the project will be compiled. The '''action''' describes what should be done and the optional '''clean''' removes the compiled files of a previous compilation before doing the action.
+
+'''Reset user settings''' removes all stored custom information about the project (but not the configuration of the project itself). For example last used target, locations where this project has been compiled, arguments and working directory.
+
+{{seealso| '''See Also'''
+[[EiffelStudio: Creating a new project|Creating a new project]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-multi-format-documentation.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-multi-format-documentation.wiki
new file mode 100644
index 00000000..49e0f33e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-multi-format-documentation.wiki
@@ -0,0 +1,42 @@
+[[Property:title|Generating multi-format documentation]]
+[[Property:weight|0]]
+EiffelStudio can generate documentation for a system using many different formats.
+
+The '''Documentation Wizard''', which helps you to get the documentation you want, is available in the '''Project''' menu, under the entry '''Generate Documentation'''.
+
+The first page of the Documentation Wizard lets you choose between the available formats for the documentation:
+
+[[Image:doc-wizard-filter-selection]]
+
+{{tip| '''Tip''': The nicest output is produced by the '''html-stylesheet''' format. }}
+
+Now the wizard asks you to select the clusters you want to produce documentation for:
+
+[[Image:doc-wizard-cluster-selection]]
+
+In the next page you can specify indexing items on which HTML metatags will be based:
+
+[[Image:doc-wizard-indexing-selection]]
+
+{{note| '''Note''': This page is only available for HTML documentation. }}
+
+You can then pick the formats you need among those available. For example, you might need a file containing the '''Cluster hierarchy''' of your system or, for each class, a file containing the '''Contracts''' of that class. At this point you can also decide to generate BON diagrams for the clusters selected in the previous page.
+
+[[Image:doc-wizard-format-selection]]
+
+If you have checked '''Cluster diagrams''' in the previous page, you will now be able to choose a view for each diagram that is going to be generated. You have the choice between an automatically arranged view and all of the [[Views|views ]] you may have manually arranged with the [[Diagram tool|Diagram Tool]] .
+
+[[Image:doc-wizard-view-selection]]
+
+{{note| '''Note''': Cluster diagrams are only available for HTML documentation. }}
+
+Here comes the last page; you can choose the directory where the documentation is going to be generated:
+
+[[Image:doc-wizard-path-selection]]
+
+{{seealso| '''See Also'''
+[[Generating XMI documentation|Generating XMI documentation]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-xmi-documentation.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-xmi-documentation.wiki
new file mode 100644
index 00000000..00579d94
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-xmi-documentation.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Generating XMI documentation]]
+[[Property:weight|1]]
+EiffelStudio can generate an '''XMI''' description of a system; '''XMI''' (XML Metadata Interchange) format is the new industry standard way to describe and exchange object-oriented systems, further information can be found [http://www.omg.org/technology/xml/ here] .
+
+The '''XMI Export wizard''' is available in the '''Project''' menu, under the entry '''Export XMI'''.
+
+The first page of the wizard lets you select the clusters you want to produce documentation for:
+
+[[Image:xmi-wizard-cluster-selection]]
+
+On the second and last page, you can choose the directory where the XML file is going to be generated:
+
+[[Image:doc-wizard-path-selection]]
+
+{{seealso| '''See Also'''
+[[Generating multi-format documentation|Generating multi-format documentation]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/index.wiki
new file mode 100644
index 00000000..868b9dfe
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/generating-documentation/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Generating documentation]]
+[[Property:weight|7]]
+* [[Generating multi-format documentation|Generating multi-format documentation]]
+* [[Generating XMI documentation|Generating XMI]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/evaluating-measure.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/evaluating-measure.wiki
new file mode 100644
index 00000000..af244465
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/evaluating-measure.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Evaluating a measure]]
+[[Property:weight|1]]
+To evaluate a metric over a scope:
+# Select the '''Metric Evaluation''' tab from the Metric tool.
+# Define the scope by adding either groups, classes or features to the input domain list.
+# Select a metric from the list of available metrics.
+# Click the '''Run selected metric''' button and the result will appear in the '''Value''' text field.
+
+You can get more information about the evaluated metric. See [[Viewing measure details|detailing a measure]] .
+
+
+
+{{warning| '''Caution''': When calculated, a measure is not saved. }}
+
+{{seealso| '''See Also'''
+[[Saving a measure|Saving a measure]]
+[[Viewing measure details|Detailing a measure]]
+}}
+
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/index.wiki
new file mode 100644
index 00000000..301c954d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Computing a measure]]
+[[Property:weight|1]]
+* [[Computing a measure: Introduction|Introduction]]
+* [[Evaluating a measure|Evaluating a measure]]
+* [[Saving a measure|Saving a measure]]
+* [[Viewing measure details|Detailing a measure]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/saving-measure.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/saving-measure.wiki
new file mode 100644
index 00000000..c69cb3ec
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/saving-measure.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Saving a measure]]
+[[Property:weight|2]]
+To save the result of evaluation of a metric:
+# Select the '''Metric Archive''' tab of the Metric tool.
+# Select the input domain as described in [[Evaluating a measure|Evaluating a measure]] and the metrics you want to compute and save over the selected scope
+# Select a file to use to store the results. If you specify a non-existing file, it will be created, if you specify an existing file it will be overriden. The selection of the file can be done by clicking on the button with the three dots in the '''Archive Management''' frame.
+# Click the '''Start metric archive evaluation'''.
+
+{{seealso| '''See Also'''
+[[Evaluating a measure|Evaluating a measure]]
+[[Viewing measure details|Detailing measures]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/viewing-measure-details.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/viewing-measure-details.wiki
new file mode 100644
index 00000000..432eeae8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/viewing-measure-details.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Viewing measure details]]
+[[Property:weight|3]]
+It is possible to have some details when evaluating a metric.
+# Select the '''Metric Evaluation''' tab of the metric tool.
+# [[Evaluating a measure|Evaluate a metric]] .
+# Click the '''Run selected metric and show detailed result''' button and the result will appear in the '''Detailed Result''' tab of the metric tool.
+# To come back to the main interface click again on '''Metric Evaluation''' tab of the metric tool.
+
+{{seealso| '''See Also'''
+[[Evaluating a measure|Evaluating a measure]]
+[[Saving a measure|Saving measures]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/comparing-archive.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/comparing-archive.wiki
new file mode 100644
index 00000000..bca5f6d1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/comparing-archive.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Comparing to an archive]]
+[[Property:weight|2]]
+The main goal of archives is comparing archives one to another. In order to compare your project to an archived file, you must select the '''Metric archive''' tab of the metric tool.
+
+The goal is to load the archive of a (preferably different) project, to compare the archived measures to the system's. You can select your current archive or any other archive, against a reference archive file.
+
+Once the archives are selected, click the '''Compare''' button to start the comparison. It will bring you to the '''Detailed Result''' tab.
+
+{{seealso| '''See Also'''
+[[Creating an archive|Creating an archive]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/creating-archive.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/creating-archive.wiki
new file mode 100644
index 00000000..c1fd3f5c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/creating-archive.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Creating an archive]]
+[[Property:weight|1]]
+Users may want to archive the result of the system they are working on. To create an archive is basically the same as [[Saving a measure|saving a measure]] .
+
+{{seealso| '''See Also'''
+[[Comparing to an archive|Comparing to an archive]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/index.wiki
new file mode 100644
index 00000000..14223515
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Handling archives]]
+[[Property:weight|3]]
+* [[Handling archives: introduction|Introduction]]
+* [[Creating an archive|Creating an archive]]
+* [[Comparing to an archive|Comparing to an archive]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-derived-metrics.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-derived-metrics.wiki
new file mode 100644
index 00000000..d11605a6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-derived-metrics.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Defining derived metrics]]
+[[Property:weight|1]]
+To define a derived metric, you must select the''' Metric Definition''' tab and click the '''New metric''' button. A menu appears asking you the kind of metric you want to define. Select '''Basic metric''' and then the type of the results you are looking for (i.e. Class, Feature, Line, ...). Once done, you can perform the following steps:
+# Enter a name for the metric in the "Name" field. Next to the field you will see the type of metric as well as the unit for this metric.
+# Enter a description for the metric. The description is shown as a tooltip when you navigate the list of available metrics.
+# Choose your criteria by selecting the item with ... in the '''Criterion definition''' list. Once selected you can press Ctrl+Space to see the list of available criterion. Once the criterion is set, you can add some properties (e.g. a property could be STRING if the criterion you have is to look for descendants of the STRING class).
+# Once you have completed the metric definition you need to save your metric by clicking on the Save button.
+# If you want to define another derived metric, repeat all the previous steps.
+
+For more information about criterion, read the [[Criterion References|Managing criterion]] section.
+
+A summary of the metric you just defined appears in a textual representation in the '''Expression''' text field.
+
+{{seealso| '''See Also'''
+[[Managing new metrics: Introduction|Managing metrics]]
+[[Criterion References|Managing criterion]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-linear-metrics.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-linear-metrics.wiki
new file mode 100644
index 00000000..3089ac7e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-linear-metrics.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Defining linear metrics]]
+[[Property:weight|2]]
+To define a linear metric, you must select the '''Metric Definition''' tab and click the '''New metric''' button. A menu appears asking you the kind of metric you want to define. Select '''Linear metric''' and then the type of the results you are looking for (i.e. Class, Feature, Line, ...). Once done, you can perform the following steps:
+# Enter a name for the metric in the "Name" field. Next to the field you will see the type of metric as well as the unit for this metric.
+# Enter a description for the metric. The description is shown as a tooltip when you navigate the list of available metrics.
+# Define a single term by choosing a metric from the combo box that appears when selecting the '''Metrics''' column, and then choose a coefficent in the '''Coefficient''' column of the metric definition list.
+# To add other terms, repeat operation 3 as many times as needs.
+# Once you have completed the metric definition you need to save your metric by clicking on the Save button.
+# If you want to define another linear metric, repeat all the previous steps.
+
+A summary of the metric you just defined appears in a textual representation in the '''Expression''' text field.
+
+{{seealso| '''See Also'''
+[[Managing new metrics: Introduction|Managing metrics]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-ratio-metrics.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-ratio-metrics.wiki
new file mode 100644
index 00000000..dc69b3ff
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-ratio-metrics.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Defining ratio metrics]]
+[[Property:weight|3]]
+To define a ratio metric, you must select the '''Metric Definition''' tab and click the '''New metric''' button. A menu appears asking you the kind of metric you want to define. Select '''Ratio metric'''. Once done, you can perform the following steps:
+# Enter a name for the metric in the "Name" field. Next to the field you will see the type of metric as well as the unit for this metric.
+# Enter a description for the metric. The description is shown as a tooltip when you navigate the list of available metrics.
+# Select a metric for numerator in the "Metric" combo box of the "Numerator" frame to change the numerator in the "Ratio" field.
+# Select a metric for denominator in the "Metric" combo box of the "Denominator" frame to change the denominator in the "Ratio" field.
+# If you want to change again either numerator or denominator repeat operations 3. or 4. as many times as needed.
+# Once you have completed the metric definition you need to save your metric by clicking on the Save button.
+# If you want to define another ratio metric, repeat all the previous steps.
+
+A summary of the metric you just defined appears in a textual representation in the '''Expression''' text field.
+
+{{seealso| '''See Also'''
+[[Managing new metrics: Introduction|Managing metrics]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/index.wiki
new file mode 100644
index 00000000..f890dab6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Defining new metrics]]
+[[Property:weight|1]]
+* [[Defining new metrics: introduction|Introduction]]
+* [[Defining derived metrics|Derived metrics]]
+* [[Defining linear metrics|Linear metrics]]
+* [[Defining ratio metrics|Ratio metrics]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/index.wiki
new file mode 100644
index 00000000..07b38d71
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Handling new metrics]]
+[[Property:weight|2]]
+* [[Handling new metrics: Introduction|Introduction]]
+* [[Defining new metrics|Defining new metrics]]
+* [[Managing new metrics|Managing metrics]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/managing-new-metrics.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/managing-new-metrics.wiki
new file mode 100644
index 00000000..9c1c7e88
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/managing-new-metrics.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Managing new metrics]]
+[[Property:weight|2]]
+* [[Managing new metrics: Introduction|Introduction]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/index.wiki
new file mode 100644
index 00000000..3fb75aa7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|How to analyze a project]]
+[[Property:weight|6]]
+* [[How to analyze a project: Introduction|Introduction]]
+* [[Computing a measure|Computing a measure]]
+* [[Handling new metrics|Handling new metrics]]
+* [[Handling archives|Handling archives]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/index.wiki
new file mode 100644
index 00000000..f2cfabb0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|EiffelStudio How To's]]
+[[Property:weight|-1]]
+* [[EiffelStudio: Starting a project|Starting a project]]
+* [[Browsing|Browsing]]
+* [[Editing a project|Editing a project]]
+* [[Compiling|Compiling]]
+* [[Running and debugging|Running and debugging]]
+* [[Designing a project|Designing a project]]
+* [[How to analyze a project|Analysing a project]]
+* [[Generating documentation|Generating documentation]]
+* [[Customizing EiffelStudio|Customizing]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/exploring-application-dynamic-state.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/exploring-application-dynamic-state.wiki
new file mode 100644
index 00000000..3cf0c6f6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/exploring-application-dynamic-state.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Exploring an application dynamic state]]
+[[Property:weight|2]]
+To view the dynamic state of a debugged application, just stop it at the point where you want to see its context. The debugger tools will automatically be popped up then, yielding the call stack of the application, as well as the state of the objects located in the object tree, which include at least the object corresponding to the level of the call stack where the call stack cursor [[Image:callstack-active-arrow-icon]] is.
+
+To see at which point the features in the call stack have stopped, just click the feature on which you want this information in the call stack. Doing this will change the cursor position in the call stack and display the flat view of the feature in the context tool.
+
+To follow an object state between pauses of the application, pick and drop it into the object tree, which will make it stay in it.
+
+You can also query features dynamically by using the evaluation tool, which can be very useful to have glimpses of the C memory of the system, for instance.
+
+{{seealso| '''See Also'''
+[[Interrupting an application|Pausing an application]]
+[[Callstack tool: Introduction|Call stack tool]]
+[[Objects tool: Introduction|Object tool]]
+[[Expression evaluation: Introduction|Evaluation tool]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki
new file mode 100644
index 00000000..400ef79a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Handling exceptions]]
+[[Property:weight|4]]
+It is possible to raise and catch exceptions in Eiffel. Catching exceptions is done by using the rescue keyword. The [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] class provides helper features to analyze the caught exception and handle it.
+
+The [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] class also provides ways to raise exception, via its feature [[ref:libraries/base/reference/exceptions_flatshort|raise]] .
+
+When an exception is raised while the application is being debugged, the application stops immediately and the debugger displays the context in which the exception occurred, whether or not the exception is rescued.
+
+{{seealso| '''See Also''':
+[[8 Design by Contract (tm), Assertions and Exceptions|Reference of exceptions]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/index.wiki
new file mode 100644
index 00000000..13010940
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Running and debugging]]
+[[Property:weight|4]]
+* [[Running an application|Running an application]]
+* [[Interrupting an application|Interrupting an application]]
+* [[Exploring an application dynamic state|Exploring an application dynamic state]]
+* [[Using breakpoints|Using breakpoints]]
+* [[Handling exceptions|Handling exceptions]]
+* [[Using debug clauses|Using debug clauses]]
+* [[Setting the command line arguments|Setting command line arguments]]
+* [[Profiling|Profiling]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/interrupting-application.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/interrupting-application.wiki
new file mode 100644
index 00000000..7e8c0808
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/interrupting-application.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Interrupting an application]]
+[[Property:weight|1]]
+There are two ways a debugged application can be interrupted: its execution can be paused, or it can be killed.
+
+Two methods can be used to pause a debugged application:
+* The [[Pause an application]] , located in both the debug menu and the project toolbar.
+* Breakpoints, which make it easy to stop the application at a precise point.
+
+To kill a debugged application, use the [[Stop a debugged application]] , located in both the debug menu and the project toolbar.
+
+{{seealso| '''See Also'''
+[[Running an application|Running a program]]
+[[Using breakpoints|Using breakpoints]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki
new file mode 100644
index 00000000..1d2f812c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki
@@ -0,0 +1,71 @@
+[[Property:title|Profiling]]
+[[Property:weight|7]]
+The profiler is a tool that gives dynamic execution time information. It is very useful to detect which parts of a program need to be optimized most.
+
+To use the profiler, the first thing to do is to enable it.
+
+To enable the profiler:
+* Open the [[General Target Options|Project Settings]] dialog.
+* In the '''Target''' section, enable '''Profile'''.
+* Click '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+By default the profiler will profile the entire program. However it is possible to enable or disable the profiler on certain clusters only. To do this:
+* Open the [[Group Options|Project Settings]] dialog.
+* In the '''Clusters''' property, check the '''Profile''' boolean value in the clusters where you want the profiler to be enabled.
+* Click '''Apply''' or '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+It is also possible to dynamically start and stop the profiler in a program. To do this:
+* Create an object of type [[ref:/libraries/base/reference/profiling_setting_chart|PROFILING_SETTING]] .
+* Call [[ref:libraries/base/reference/profiling_setting_flatshort|start_profiling]] on this object to start the profiler.
+* Call [[ref:libraries/base/reference/profiling_setting_flatshort|stop_profiling]] on this object to stop the profiler.
+
+{{tip| '''Tip''': To profile only part of a program, turn off the profiler at the very beginning of the program, turn it on just before the part of the code that should be profiled, and turn it back off after this section. Typically, it results in the following code: }}
+
+In the root feature:
+
+
+ local
+ ps: PROFILING_SETTING
+ -- Other local variables if necessary.
+ do
+ create ps.make
+ ps.stop_profiling
+ -- Real program execution.
+ ps.start_profiling
+ end
+
+
+And in the feature(s) that needs to be profiled:
+
+ local
+ ps: PROFILING_SETTING
+ -- Other local variables if necessary.
+ do
+ create ps.make
+ ps.start_profiling
+ -- What needs to be profiled.
+ ps.stop_profiling
+ end
+
+
+{{note| '''Note''': Even if the profiler should only work in certain sections of code, the '''Profiling''' check box of the [[General Target Options|Projects Settings]] dialog must be checked or the '''profile''' option must be set on certain clusters. }}
+
+Once the profiler has been enabled and the program has been recompiled, it is necessary to launch the program.
+
+{{tip| '''Tip''': It is possible to profile debuggable(frozen/melted) executables as well as finalized ones. It is more interesting to profile finalized executables, though, since the execution speed is more representative of what will be obtained by your end users. }}
+
+When the program exits, a file named 'profinfo' should be generated next to it.
+
+All that's left to do is launch the [[Profiler wizard: Introduction|Profiler wizard]] and follow the instructions.
+
+{{seealso| '''See Also'''
+[[Generating executables|Generating executables]]
+[[Running an application|Running a program]]
+[[Tuning a program|Tuning a program]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/running-application.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/running-application.wiki
new file mode 100644
index 00000000..10311b67
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/running-application.wiki
@@ -0,0 +1,27 @@
+[[Property:title|Running an application]]
+[[Property:weight|0]]
+There are several ways to launch an application. Not all are available depending on the way you compiled your system.
+
+Melted and frozen executables can be debugged. Several methods can be used to launch such an executable:
+* The default [[Run and stop at breakpoints]] . It launches the executable located in the EIFGENs/target_name/W_code directory under the project directory. The execution stops whenever a breakpoint is encountered.
+* The [[Run without breakpoints]] . It has the same behavior except that the execution won't stop when a breakpoint is met.
+* The step commands, which execute only a small part of the program at a time:
+** The [[Step into a feature]] , which tries to enter the feature that is about to be called.
+** The [[Execute one line at a time]] , which executes one execution line.
+** The [[Step out of a feature]] , which launches the application and stops it as soon as the application exits the feature it is stopped in.
+
+
+{{tip| '''Tip''': All the above commands can be accessed either in the '''Project''' toolbar or in the '''Debug''' menu.
+They can be used either to launch the program or to resume its execution after it has been paused. }}
+* It is also possible to select '''Run to breakpoint''' in a [[Breakpoint editing|breakpoint context menu]] to have the application be launched and executed until it reaches the selected execution line.
+
+Finalized executables can also be run, but they are not debuggable and cannot be interrupted. To run a finalized executable, use the [[Run a finalized executable]] , located in the '''Project''' menu and the '''Project''' toolbar.
+
+{{seealso| '''See Also'''
+[[Generating executables|Compiling an executable]]
+[[Using breakpoints|Using breakpoints]]
+[[Interrupting an application|Interrupting an application]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/setting-command-line-arguments.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/setting-command-line-arguments.wiki
new file mode 100644
index 00000000..e37eab8b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/setting-command-line-arguments.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Setting the command line arguments]]
+[[Property:weight|6]]
+To debug a program that uses command line parameters, it is possible to have the debugger call the generated program with certain command line arguments automatically.
+
+To change the command line arguments used when debugging:
+* Open the Debug, Debugging Options Dialog
+* In this dialog, you can change the current arguments and also store and load argument sets.
+* Click '''OK'''.
+
+{{tip| '''Tip''': To get the command line arguments in a program, it is possible to either define the root feature as taking an array of [[ref:/libraries/base/reference/string_8_chart|STRING_8]] objects, or to use the [[ref:/libraries/base/reference/arguments_chart|ARGUMENTS]] class, which provides a lot of functionality linked with command line arguments. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-breakpoints.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-breakpoints.wiki
new file mode 100644
index 00000000..13767db9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-breakpoints.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Using breakpoints]]
+[[Property:weight|3]]
+To change the status of one breakpoint, it is possible to use the [[Breakpoint editing|breakpoints menu]] , which changes the state of a single breakpoint at a time.
+
+To change the status of several breakpoints at the same time, the easiest way is to use the [[Breakpoint commands|breakpoints-related commands]] , which have actions at feature-scope, class-scope and system-scope.
+
+{{seealso| '''See Also'''
+[[Running an application|Running an application]]
+[[Interrupting an application|Interrupting an application]]
+[[Breakpoints: Introduction|Breakpoints reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-debug-clauses.wiki b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-debug-clauses.wiki
new file mode 100644
index 00000000..26de242f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-debug-clauses.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Using debug clauses]]
+[[Property:weight|5]]
+Eiffel provides ways to add debug code to features to help during their debugging. You may think of it as the well-known C construct: #ifdef MY_DEBUG_FLAG/* Debug code is here */ #endif
+
+
+The corresponding construct in Eiffel is provided by the debug keyword. It is possible to wrap code inside a debug clause like this:
+
+ debug("MY_DEBUG_FLAG")
+ -- Debug code is here.
+ end
+
+
+It is then possible to enable or disable debug clauses globally.
+
+To modify the debug clauses status:
+* Open the [[Debug Options|Project Settings]] dialog.
+* In the '''Debug''' section, you can enable/disable the debug clauses.
+* Click '''OK'''.
+* You must [[Generating executables|recompile]] your project for the changes to take effect.
+
+{{tip| '''Tip''': Debug clauses make it easy to remove all debug messages when finalizing a system. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/change-data-share-mode.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/change-data-share-mode.wiki
new file mode 100644
index 00000000..a138fd91
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/change-data-share-mode.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Change data share mode]]
+[[Property:weight|3]]
+Located in the '''View''' menu, named either '''Link context tool''' or '''Unlink context tool''', this command allows you to switch between the two possible [[Address bars: Introduction|addressing modes]] . It is also accessible through the main toolbar ( [[Image:context-link-icon]] ).
+
+{{note| '''Note''': This command only applies to the development window where it is invoked, and this setting is not automatically saved when exiting EiffelStudio. }}
+
+{{seealso| '''See Also'''
+[[Development Window Preferences|Change the default data sharing]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/context-tool-address-bar.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/context-tool-address-bar.wiki
new file mode 100644
index 00000000..c5656547
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/context-tool-address-bar.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Context tool address bar]]
+[[Property:weight|2]]
+The address bar of the context tool has a different look from the [[Main address bar|main address bar]] , but provides the same functionality.
+
+[[Image:context-address-bar]]
+
+It also contains history arrows, and by clicking on the cluster, class or feature name, a window is popped up that contains fields similar to the ones of the [[Main address bar|main address bar]] , except that a cluster can also be entered, since the diagram tool and the metrics also work with clusters:
+
+[[Image:context-address-window]]
+
+{{tip| '''Tip''': Labels in this address bar are pickable, to send the address to other tools easily. }}
+
+{{note| '''Note''': The context tool only has an address bar if it is unlinked from the editor. }}
+
+{{seealso| '''See Also'''
+[[Change data share mode|Unlinking the context tool]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/index.wiki
new file mode 100644
index 00000000..a6a4d763
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Address bars]]
+[[Property:weight|1]]
+* [[Address bars: Introduction|Introduction]]
+* [[Main address bar|Main address bar]]
+* [[Context tool address bar|Context tool address bar]]
+* [[Change data share mode|Switch between address sharing modes]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/main-address-bar.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/main-address-bar.wiki
new file mode 100644
index 00000000..8f71ea47
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/main-address-bar.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Main address bar]]
+[[Property:weight|1]]
+The main address bar is located in the top part of windows, between the two [[Main toolbars|main toolbars]] (when they are displayed).
+
+[[Image:main-address-bar]]
+
+It has several components:
+* History back and forth arrows [[Image:view-previous-icon]] and [[Image:view-next-icon]]
+* Fields where the current class or feature name is displayed
+* View icons to change the view displayed in the editor [[Image:view-editor-icon]] , [[Image:view-clickable-icon]] , [[Image:view-flat-icon]] , [[Image:view-contracts-icon]] and [[Image:view-flat-contracts-icon]]
+
+It is possible to type a class or feature name to center the editor on it. Typing a class name that does not exist in the set of known classes pops up a dialog to create a class of that name.
+
+{{tip| '''Tip''': Wildcards (* and ?) are available in these fields. }}
+
+{{tip| '''Tip''': The history is also accessible in the '''View/Go to''' menu. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-menu.wiki
new file mode 100644
index 00000000..3d3865a8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-menu.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Favorites menu]]
+[[Property:weight|2]]
+The '''favorites''' menu is composed of two parts.
+
+First, there are three commands:
+* The '''Add to Favorites''' command, that adds the currently edited class to the root of the favorites tree.
+* The '''Show/Hide Favorites''' command, that shows or hides the [[Favorites tree|favorites tree]] .
+* The '''Organize Favorites''' command, that displays the [[Organize favorites dialog: Introduction|Organize Favorites dialog]] .
+
+After the separator, the favorites are displayed in a menu representation. Clicking on any of these menu items will send the selected favorite class to the editor.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-tree.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-tree.wiki
new file mode 100644
index 00000000..1a256bf2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-tree.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Favorites tree]]
+[[Property:weight|1]]
+The favorites tree gives a graphical representation of the favorite classes of the system, as opposed to the favorites menu.
+
+[[Image:favorites-tree]]
+
+In this tree, the folders are user-definable through the [[Organize favorites dialog: Introduction|Organize Favorites dialog]] . They have no other goal than ordering the favorites. In particular, they are entirely independent from the clusters of the system.
+
+Clicking a class in the favorites tree edits it. Keyboard navigation is also available. Favorite classes are [[Pick-and-drop mechanism|pickable]] too, so that it is possible to send them to all interface components that accept classes.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/index.wiki
new file mode 100644
index 00000000..a1685380
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Favorites tool]]
+[[Property:weight|4]]
+* [[Favorites tool: Introduction|Introduction]]
+* [[Favorites tree|Tree representation]]
+* [[Favorites menu|Menu representation]]
+* [[Organize Favorites dialog|Organize Favorites dialog]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/create-favorite-folder-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/create-favorite-folder-command.wiki
new file mode 100644
index 00000000..3035d122
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/create-favorite-folder-command.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Create favorite folder command]]
+[[Property:weight|2]]
+This command [[Image:favorites-dialog-new-folder]] is accessible in the Organize favorites dialog. When clicked, a dialog is popped up that prompts for a name for the new folder:
+
+[[Image:favorites-new-folder-dialog]]
+
+After typing the name of the new folder, pressing '''OK''' adds it to the root of the favorites.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/index.wiki
new file mode 100644
index 00000000..999fc515
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Organize Favorites dialog]]
+[[Property:weight|3]]
+* [[Organize favorites dialog: Introduction|Introduction]]
+* [[New favorite class command|New Favorite Class command]]
+* [[Create favorite folder command|Create Folder command]]
+* [[Move to Folder command|Move to Folder command]]
+* [[Remove favorite command|Remove command]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/move-folder-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/move-folder-command.wiki
new file mode 100644
index 00000000..02f73fea
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/move-folder-command.wiki
@@ -0,0 +1,21 @@
+[[Property:title|Move to Folder command]]
+[[Property:weight|3]]
+The Move to Folder command [[Image:favorites-dialog-move-to]] , located in the [[Organize favorites dialog: Introduction|Organize Favorites dialog]] , makes it possible to move favorite items (classes and folders) to specific folders. It is enabled only when an item is selected in the left-hand tree in this dialog. The source is the selected item that could be moved. You can select a different source item by clicking it in the tree, or by using the keyboard.
+
+When pressed, a dialog is popped up, that prompts for the favorite folder the selected item should be moved to.
+
+[[Image:favorites-choose-folder-dialog]]
+
+Select the destination folder by expanding the tree and by clicking it. The top tree item, named Favorites, represents the root of the favorites.
+
+Pressing '''OK''' moves the source item to the destination folder. Pressing '''Cancel''' discards the dialog box and does not move the source item.
+
+{{tip| '''Tip''': You can also move items around by picking them in the favorites tree and dropping them where you want. }}
+
+{{seealso| '''See Also'''
+[[Favorites tree|Favorites tree]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/new-favorite-class-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/new-favorite-class-command.wiki
new file mode 100644
index 00000000..e3c342bd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/new-favorite-class-command.wiki
@@ -0,0 +1,18 @@
+[[Property:title|New favorite class command]]
+[[Property:weight|1]]
+Located in the [[Organize favorites dialog: Introduction|Organize Favorites dialog]] , this command [[Image:favorites-dialog-new-class]] provides a way of adding a class to the favorites. When clicked, a new dialog is popped up, that allows to select a class among the clusters of the system:
+
+[[Image:favorites-new-class-dialog]]
+
+Clicking on a class name sets its name in the top text field, whereas double-clicking it automatically selects it and closes the dialog box. It is also possible to directly type the name of the wanted class in the top text field to select it.
+
+The selected class goes to the root of the favorite tree. It is then possible to [[Move to Folder command|move]] it to a different favorite folder.
+
+{{seealso| '''See Also'''
+[[Favorites tool: Introduction|Favorite tool]]
+[[Favorites menu|Favorite menu]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/remove-favorite-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/remove-favorite-command.wiki
new file mode 100644
index 00000000..d51f5faf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/remove-favorite-command.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Remove favorite command]]
+[[Property:weight|4]]
+The Remove favorite command [[Image:favorites-dialog-remove]] discards a favorite item from the favorites. It is enabled whenever an item is selected in the left-hand tree of the [[Organize favorites dialog: Introduction|Organize favorites dialog]] .
+
+Pressing it removes the selected item from the favorites.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/feature-tree.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/feature-tree.wiki
new file mode 100644
index 00000000..76f1faa5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/feature-tree.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Feature tree]]
+[[Property:weight|1]]
+[[Image:feature-tree]]
+
+The feature tree gives a summary of all the features of the currently edited class. They are in the same order as they are in the class file, and they are grouped by their feature clause.
+
+The icon relative to the feature clause indicates the export status of the features inside it:
+* [[Image:folder-features-all-icon]] means features are exported to all classes
+* [[Image:folder-features-some-icon]] means features are exported to some classes
+* [[Image:folder-features-none-icon]] means features are not exported
+
+The icon on the features indicates the nature of the feature:
+* [[Image:feature-attribute-icon]] for attributes
+* [[Image:feature-once-icon]] for once and constant features
+* [[Image:feature-deferred-icon]] for deferred features
+* [[Image:feature-external-icon]] for external features
+* [[Image:feature-frozen-routine-icon]] for frozen features
+* [[Image:feature-routine-icon]] for normal Eiffel routines
+
+Clicking a feature or a feature clause in the tree centers the editor on it. Key navigation is also available. All features can be [[Pick-and-drop mechanism|picked]] , to [[Pick-and-drop mechanism|be dropped]] them into any component of the interface that accepts features.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/index.wiki
new file mode 100644
index 00000000..a1c2d241
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Feature tool]]
+[[Property:link_title|Features tool]]
+[[Property:weight|3]]
+* [[Feature tool: Introduction|Introduction]]
+* [[Feature tree|Tree representation]]
+* [[New feature command|New feature command]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/new-feature-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/new-feature-command.wiki
new file mode 100644
index 00000000..d310540f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/new-feature-command.wiki
@@ -0,0 +1,9 @@
+[[Property:title|New feature command]]
+[[Property:weight|2]]
+The new feature command [[Image:new-feature-icon]] located in the [[Feature tool: Introduction|feature tool]] acts like the [[New feature dialog: Introduction|main new feature command]] . Clicking it pops up the same dialog, making it possible to add a new feature in the currently edited class.
+
+This command is only available when the class currently in the editor is compiled, can be modified, and has a file on the disk (this may not be the case if the class is precompiled).
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/index.wiki
new file mode 100644
index 00000000..afea1e67
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Cluster tool]]
+[[Property:link_title|Groups tool]]
+[[Property:weight|2]]
+* [[Cluster tool: Introduction|Introduction]]
+* [[System tree representation|System tree representation]]
+* [[New cluster command|New cluster command]]
+* [[New class command|New class command]]
+* [[Locate command|Locate command]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/locate-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/locate-command.wiki
new file mode 100644
index 00000000..bd8e9e74
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/locate-command.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Locate command]]
+[[Property:weight|4]]
+The locate command ( [[Image:general-search-icon]] ), located in the [[Cluster tool: Introduction|cluster tool]] , provides an easy way to find a class or a cluster in the [[System tree representation|cluster tree]] .
+
+Clicking it automatically expands the clusters containing the edited class or cluster and selects it.
+
+[[Pick-and-drop mechanism|Dropping]] a class or a cluster on it expands the clusters containing the searched item and selects it.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-class-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-class-command.wiki
new file mode 100644
index 00000000..09e1caeb
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-class-command.wiki
@@ -0,0 +1,11 @@
+[[Property:title|New class command]]
+[[Property:weight|3]]
+The new class command ( [[Image:new-class-icon]] ) located in the cluster tool toolbar creates a class in the same fashion as the main new class command. The only difference is that when using the cluster tool command, the new class is by default located in the cluster selected in the [[System tree representation|cluster tree]] (or the parent cluster of the selected class, if a class is selected).
+
+A dialog is then popped up in which it is possible to select the name of the new class, the name of the file it should be created in (by default ".e" is appended to the name of the new class to generate the file name), and the cluster in which the new class should be inserted. Only clusters that are not libraries are displayed in the list, since library clusters cannot be modified.
+
+[[Image:new-class-dialog]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-cluster-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-cluster-command.wiki
new file mode 100644
index 00000000..87dca8bd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-cluster-command.wiki
@@ -0,0 +1,16 @@
+[[Property:title|New cluster command]]
+[[Property:weight|2]]
+The new cluster command ( [[Image:new-cluster-icon]] ) located in the cluster tool toolbar creates a cluster in the same fashion as the main new cluster command. The only difference is that when using the cluster tool command, the new cluster is by default located in the cluster selected in the [[System tree representation|cluster tree]] (or the selected class's parent cluster, if a class is selected).
+
+A dialog is then popped up in which it is possible to select the name of the new cluster and the cluster in which the new cluster should be inserted. Only clusters that are not libraries are displayed in the list.
+
+[[Image:new-cluster-dialog]]
+
+Enabling the '''recursive''' option makes the compiler search not only the cluster directory but also all its sub-directories for classes.
+The '''library''' option optimizes compilations, since the classes inside a library cluster are compiled only once. However, if you modify the classes inside a library cluster, the modifications will not be taken into account in your project. Besides, you cannot add or remove classes in a library cluster, so use this option with care: if you intend to create new classes inside this cluster later in your design, do not select the library option. You should use this option only if the new cluster is given an existing directory, which already contains classes that you will not modify.
+
+{{tip| '''Tip''': You don't have to enter a path for the new cluster if you choose to create a sub-cluster: the new cluster directory will be a sub-directory of the directory of the parent cluster, and its name will be the name of the newly created cluster. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/system-tree-representation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/system-tree-representation.wiki
new file mode 100644
index 00000000..90cd990b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/system-tree-representation.wiki
@@ -0,0 +1,23 @@
+[[Property:title|System tree representation]]
+[[Property:weight|1]]
+The cluster tool is mainly composed of a tree representation of the system.
+
+[[Image:cluster-tree]]
+
+Here is the meaning of the symbols of the cluster tree:
+* [[Image:folder-cluster-icon]] , [[Image:folder-cluster-readonly-icon]] , [[Image:folder-blank-icon]] , [[Image:folder-override-cluster-icon]] , [[Image:folder-hidden-cluster-icon]] , are clusters (normal, readonly, subfolder in a recursive cluster, override cluster, hidden/implementation cluster)
+* [[Image:folder-library-icon]] are libraries
+* [[Image:folder-assembly-icon]] are assemblies
+* [[Image:folder-namespace-icon]] are namespaces in assemblies
+* [[Image:class-normal-icon]] , [[Image:class-frozen-icon]] , [[Image:expanded-normal-icon]] , [[Image:class-deferred-icon]] , [[Image:class-overriden-normal-icon]] , [[Image:class-override-normal-icon]] are compiled classes (normal, frozen, expanded, deferred, overriden, overriding)
+* Greyed out classes are classes outside the system.
+* Classes and clusters that are part of a readonly group are shown with a lock (for clusters) or brighter icon than normal (they cannot be modified)
+* [[Image:folder-target-icon]] are targets
+
+Left-clicking on any item will send it to the editor. It is also possible to [[Pick-and-drop mechanism|pick]] items to send them to various components of the development window.
+
+[[Pick-and-drop mechanism|Dropping]] a class in this tree representation moves it to a different cluster (either the cluster it is dropped on or the cluster containing the class it is dropped on, according to where it is dropped). This is only possible if the dropped class is not in a library cluster, if its source file is readable and writable, and if the destination cluster is not a library or precompiled cluster itself.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/index.wiki
new file mode 100644
index 00000000..1b7aa7d9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Browsing tools]]
+[[Property:weight|-13]]
+* [[Browsing tools: Introduction|Introduction]]
+* [[Address bars|Address bars]]
+* [[Cluster tool|Cluster tool]]
+* [[Feature tool|Feature tool]]
+* [[Favorites tool|Favorites tool]]
+* [[Windows tool|Windows tool]]
+* [[Search tool|Search tool]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/search-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/search-tool.wiki
new file mode 100644
index 00000000..fc5e48e8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/search-tool.wiki
@@ -0,0 +1,43 @@
+[[Property:title|Search tool]]
+[[Property:weight|6]]
+==Description and usage==
+
+EiffelStudio includes a search tool which allows you to look for a word or a pattern in the editor, the class tool, the feature tool or the output tool, and to replace it by another word if you want. It is located in the left part of the development window, like the cluster tool or the favorites for instance.
+
+To make it appear, if it is not displayed, click on the search icon [[Image:tool-search-icon]] or choose the '''Search''' entry in the '''Edit''' menu. The search panel is divided in three parts (see Fig. 1).
+
+[[Image:search-tool]]
+
+Fig. 1: Search panel
+
+In the top part, you will find a combo box and a check box. The title of this text field is "Search for:", it will be used to enter the pattern you want to look for. The button is labeled "Replace with". If you click on it, another text field will appear. If you click again, the second text field will be hidden. This text field will be used to enter the word which you want the editor to use to replace found patterns.
+In the middle part of the search panel, you will find search options. They are described below.
+The bottom part contains two buttons: "Search" and "Replace". Click on the first one to launch the search for the pattern entered in the "Search for" field. The "Replace" button will be active only if the "Replace with" field is displayed. Press this button if you want to replace the last found pattern by the contents of the "Replace with" text field.
+
+==Options==
+
+The options are located in the middle of the search panel. There are five buttons, each of them corresponding to an option:
+*
+Match case: If this option is selected, the search will be case-sensitive, which means that if you search for "example", the tool will highlight "example" but not "EXAMPLE" or "Example", as there are no capital letters in the searched pattern.
+
+* Whole word: If this option is selected, the tool will look for isolated words. A word is isolated if it is surrounded by spaces or if it is at the beginning or the end of a line.
+*
+Use wildcards: If this option is not selected, the tool will look for the exact sequence of letters you entered in the "Search for" field. If it is selected, you will be able to use '*' and '?'wildcards. '?' in the searched pattern is equivalent to any character. For instance, "sample" and "simple" will be highlighted if you look for "s?mple".
+'*' is equivalent to any sequence of characters, including no characters at all. It means that if you search for "exam*ple", every piece of text beginning with "exam" and finishing with "ple" will be highlighted. Use it in combination with "Whole word" to search for words beginning with "exam" and finishing with "ple".
+
+*
+Replace all: If it is selected when you press the "Replace" button, every occurrence of the searched pattern will be replaced with the content of the "Replace with" field. It is possible to activate this option only if the "Replace with" field is displayed.
+
+*
+Search backwards: If this option is selected, the tool will highlight the previous occurrence of the searched pattern instead of the next occurrence when you press the "Search" button.
+
+
+'''Note''': If the search tool hits one end of the text, it will automatically continue from the other end.
+
+
+{{seealso| '''See Also'''
+There are keyboard shortcuts and menu entries to launch searches without using the search tool directly. They are described the [[Search functionality|editor section]] of this help. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/index.wiki
new file mode 100644
index 00000000..92f94dba
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Windows tool]]
+[[Property:weight|5]]
+* [[Windows tool: Introduction|Introduction]]
+* [[Window list|Window list]]
+* [[Window menu|Window menu]]
+* [[Window related commands|Window related commands]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki
new file mode 100644
index 00000000..b8c85b45
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Window list]]
+[[Property:weight|1]]
+The window list is the main part of the [[Windows tool: Introduction|window tool]] .
+
+[[Image:windows-tool]]
+
+It displays all opened development windows. Left-clicking a development window in the list raises it so that it becomes the top-level window. Right-clicking one pops up a context menu.
+
+The four first commands, '''Close''', '''Minimize''', '''Maximize''' and '''Raise''', are relative to the clicked development window. The last command, '''New window''', creates a new development window.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-menu.wiki
new file mode 100644
index 00000000..492a8ecd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-menu.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Window menu]]
+[[Property:weight|2]]
+The '''window''' menu is divided into two parts. The first one is composed of the [[Window related commands|window-related commands]] . The second one is the list of all opened development windows. Clicking any of these raises the selected development window, so that it becomes the top-level window.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-related-commands.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-related-commands.wiki
new file mode 100644
index 00000000..d7ee23bf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-related-commands.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Window related commands]]
+[[Property:weight|3]]
+A few commands give the possibility to manage the development windows globally. They are located both in the [[Window menu|Window menu]] and in the main toolbar.
+* '''New window''': this command ( [[Image:new-window-icon]] ) creates a new empty development window. Note that it is also possible to [[Pick-and-drop mechanism|drop]] a class or a feature on it to create a development window that is immediately centered on the dropped item.
+* '''Minimize all''': this command ( [[Image:windows-minimize-all-icon]] ) iconifies all development windows.
+* '''Raise all''': this command ( [[Image:windows-raise-all-icon]] ) raises all minimized development windows.
+* '''Raise unsaved windows''': this command raises all the development windows that have not been saved. It may be combined with the '''Minimize all''' command to find easily which development windows need to be saved.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki
new file mode 100644
index 00000000..82e31023
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki
@@ -0,0 +1,46 @@
+[[Property:title|Batch compilation]]
+[[Property:weight|2]]
+In order to launch a compilation without user intervention you need to specify the `-batch' switch in the '''ec''' command line, otherwise the Eiffel compilation will be blocked. We will present below a typical example of batch processing on both Unix and Windows platforms where we want to compile a project in both frozen and finalized mode, then to launch the C compilations. At the same time we want to save the output of '''ec''' and the C compilations.
+
+===Unix===
+In a file called `launch_ec' you can have the following:
+
+#!/bin/sh
+output_file="/output_path/OUTPUT"
+
+cd /your_project_path
+
+#Launch Eiffel compilation
+ec -batch -config config.ecf -finalize -c_compile 2> $output_file
+
+#Since only C compilation for finalized code is done
+#Launch C compilation for frozen code
+
+cd EIFGENs/target_name/W_code
+finish_freezing > $output_file
+
+
+It will go the directory where your project is located and compile your Eiffel code using the `config.ecf' file located in your project directory and compile automatically the C code. All outputs will be stored in the file `/output_path/OUTPUT'.
+
+'''Note:''' All output from '''ec''' are going to the error output, so do not forget to redirect the error output when you want to see the result.
+
+===Windows===
+In a file called `launched_ec.bat' you can have the following:
+
+rem Launch Eiffel compilation
+ec -batch -config config.ecf -finalize -c_compile > c:\output_path\OUTPUT
+
+rem Since only C compilation for finalized code is done
+rem Launch C compilation for frozen code
+cd EIFGENs\target_name\W_code
+finish_freezing > c:\output_path\OUTPUT
+
+
+It will go the directory where your project is located and compile your Eiffel code using the `config.ecf' file located in your project directory and compile automatically the C code. All outputs will be stored in the file `c:\output_path/OUTPUT'.
+
+{{seealso| '''See Also'''
+[[EiffelStudio: Command line options|Command line compiler options]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki
new file mode 100644
index 00000000..e4a2b30f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki
@@ -0,0 +1,70 @@
+[[Property:title|Class menu]]
+[[Property:weight|2]]
+The Class command (c or C) in the main menu will only work if the system has been successfully compiled, and will give you information based on the result of the last successful compilation. It produces the following menu:
+
+ (A) Ancestors : show the ancestors of a class.
+ (B) Attributes : show the attributes of a class.
+ (C) Clients : show the clients of a class.
+ (E) Deferred : show the deferred features of a class.
+ (D) Descendants : show the descendants of a class.
+ (V) Edit : edit the text of a class.
+ (P) Exported : show the exported features of a class.
+ (X) Externals : show the external features of a class.
+ (F) Flat : show the flat form of a class.
+ (I) Flatshort : show the flat-short form of a class.
+ (O) Once : show the once & constant features of a class.
+ (R) Routines : show the routines of a class.
+ (S) Short : show the short form of a class.
+ (U) Suppliers : show the suppliers of a class.
+ (T) Text : show the text of a class.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+
+Each command will prompt you for the name of a class and a filter to use; you can also include the class name and the filter name after the command, separated by a space, as in:
+Command => a linked_list ascii
+to obtain the ancestors of the LINKED_LIST class:
+
+ -- Automatic generation produced by ISE Eiffel --
+LINKED_LIST [G]
+ DYNAMIC_LIST [G]
+ LIST [G]
+ CHAIN [G]
+ CURSOR_STRUCTURE [G]
+ ACTIVE [G]
+ BAG [G]
+ COLLECTION [G]
+ CONTAINER [G]
+ ANY
+ INDEXABLE [G, H -> INTEGER]
+ TABLE [G, H]
+ BAG [G]...
+ SEQUENCE [G]
+ ACTIVE [G]...
+ BILINEAR [G]
+ LINEAR [G]
+ TRAVERSABLE [G]
+ CONTAINER [G]...
+ LINEAR [G]...
+ FINITE [G]
+ BOX [G]
+ CONTAINER [G]...
+ SEQUENCE [G]...
+ DYNAMIC_CHAIN [G]
+ CHAIN [G]...
+ UNBOUNDED [G]
+ FINITE [G]...
+ DYNAMIC_CHAIN [G]...
+
+ -- Generated by ISE Eiffel --
+ -- For more details: http://www.eiffel.com --
+
+Command =>
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki
new file mode 100644
index 00000000..eba35515
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Compile (and run) menu]]
+[[Property:weight|1]]
+The Compile command (i or I) in the main menu yields the following item menu:
+
+ (A) Arguments : set the arguments.
+ (C) F-compile : (re)compile the C code generated by finalize.
+ (Z) Finalize : finalize the system (discard assertions by default).
+ (F) Freeze : freeze the system.
+ (L) Melt : melt the system.
+ (K) Quick melt : quick melt the system.
+ (R) Run : execute the system.
+ (W) W-compile : (re)compile the C code generated by freeze.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+
+The most common compiling option is L (Melt): recompile the system, melting recent changes. The other compilation possibilities are F (Freeze) and Z (Finalize). After a Freeze you will need to C-compile the result using the W (W-compile) command; similarly, you can C-compile the result of a Finalize using C (F-compile).
+
+{{warning| '''Caution''': You cannot select a different project from within ec loop; also, you cannot select a different configuration file from within the command, although you may of course change the contents of the configuration file (for example by using an editor in an other window). }}
+
+The R option (Run) runs the application. You will be prompted for the arguments if the application needs any.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki
new file mode 100644
index 00000000..0945fe41
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Documentation menu]]
+[[Property:weight|7]]
+The Documentation Menu enables you to generate documentation about the classes of your system:
+
+ (I) Documentation (Flat/Short): Generate flat/short form of all classes in system.
+ (S) Documentation (Short): Generate short form of all classes in system.
+ (F) Documentation (Flat): Generate flat form of all classes in system.
+ (T) Documentation (Text): Generate text form of all classes in system.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+
+The four documentation commands will trigger the creation of documentation files corresponding to requested information using the specified filter. These files will then be located in the Documentation subdirectory of your project directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki
new file mode 100644
index 00000000..216d1784
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki
@@ -0,0 +1,44 @@
+[[Property:title|Feature menu]]
+[[Property:weight|3]]
+The Feature Menu enables you to find properties of a feature:
+
+ (A) Ancestors : show the ancestor versions of a feature.
+ (C) Callers : show the callers of a feature.
+ (D) Descendants : show the descendant versions of a feature.
+ (F) Flat : show the flat form of a feature.
+ (O) Homonyms : shown the homonyms of a feature.
+ (I) Implementers : show the classes implementing a feature.
+ (T) Text : show the text of a feature.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+
+Each command will prompt you for the name of a class, the name of a feature in that class and a filter name; you can specify these names (or just the class name) after the command.
+{|
+|-
+| '''Command'''
+| '''Description'''
+|-
+| Ancestors
+| All the versions of a feature that appeared in ancestors.
+|-
+| Callers
+| The list of classes which contains calls to the feature. Modifiers:
+* All senders - include all callers rather than only those in the specified class
+* Only assigners - restrict callers to those that use given feature only as a target of an assignment instruction
+* Only creators - restrict callers to those that use given feature only as a target of a creation instruction
+
+|-
+| Descendants
+| All the versionsof a feature that appeared in descendants.
+|-
+| Implementers
+| The list of classes where the feature is redeclared.
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki
new file mode 100644
index 00000000..67767ecd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Command line interactive mode]]
+[[Property:weight|3]]
+* [[Interactive command line: Introduction|Introduction]]
+* [[Compile (and run) menu|The Compile (and Run) menu]]
+* [[Class menu|The Class menu]]
+* [[Feature menu|The Feature menu]]
+* [[System menu|The System menu]]
+* [[Profile menu|The Profile menu]]
+* [[Documentation menu|The Documentation menu]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki
new file mode 100644
index 00000000..9a909181
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki
@@ -0,0 +1,155 @@
+[[Property:title|Profile menu]]
+[[Property:weight|6]]
+An execution of an instrumented system will generate a file that contains profiling information. This file (named profinfo) is located in the same directory as your compiled system. You must process it through a profile converter to produce the Execution Profile.
+The profile menu will enable you to produce the Execution profile and to extract information from it.
+
+The menu (obtained by selecting (P) Profile in the main menu) looks like this:
+
+ (S) Switches : show the output switches
+ #Call-E Name-E Total-D
+ Self-D Desc-D %Time-D.
+ (U) Query : manipulate subqueries.
+ (I) Input : specify input file (filename or last_output)
+ [*.pfi].
+ (L) Language : specify language (eiffel, c, cycles)
+ [eiffel].
+ (R) Run : run the query.
+ (G) Generate : generate profile information for latest run.
+ (E) Defaults : reset all values to their defaults.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+==Switches submenu==
+The (S) Switches submenu enables you to set global options. It leads you to the following set of choices:
+
+ (N) Calls : disable output of number of calls to a feature [enabled].
+ (F) Feature name : disable output of feature names [enabled].
+ (T) Total : enable output of time spent in both the function and its descendants [disabled].
+ (S) Self : enable output of time spent in a function itself [disabled].
+ (D) Descendants : enable output of time spent in descendants of a function [disabled].
+ (P) Percentage : enable output of percentage of time spent in a feature [disabled].
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (U) Parent menu : go back to parent menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+Each one of these commands switches on or off the corresponding column output. The default is set on for the first two, off for the others. To enable or disable a column, type the name with a toggle effect.
+
+==Query submenu==
+The (U) Query submenu enables you to define a set of queries. The result will be a Total Query; by default it is the boolean and all the queries you have entered individually, but you may deactivate some of these and choose other boolean operators.
+
+ (A) Add : add a sub query.
+ (I) Inactivate : inactivate sub query.
+ (R) Reactivate : reactivate sub query.
+ (C) Operator : change the boolean operator.
+ (S) Show : show the list of queries.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (U) Parent menu : go back to parent menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+To get useful information, you should add the appropriate queries through (A) Add. Each individual query has the following form: attribute operator value, where attribute is one of:
+* feature name
+* calls
+* total
+* self
+* descendants
+* percentage
+operator is one of: <, >, <=, >=, =, /=, in
+and value is one of:
+* An integer (for calls)
+* A string (for feature name). The string may contain wild card characters: ?, standing for arbitrary characters, and *,standing for arbitrary substrings.
+* A real value (for other attributes)
+* An interval, of the form a-b for two values a and b.
+* max
+* min
+* avg
+The (S) Show command will display the current queries, each with an associated number. The output includes the total query, explained next.
+To inactivate a query, use (I) Inactivate. You will be prompted for a query index, which you may retrieve from (S) Show. This is useful if you make a change about a query, or want to set it aside for future use.
+
+To reactivate a query, use (R) Reactivate. Again you will have to provide a query index.
+
+The Total Query resulting from a succession of (A) Add commands, possibly with some (I) Inactivate and (R) Reactivate commands, is a boolean query resulting by default from adding all the currently active queries. For example after the following set of commands(note that commands output help lines, which have been skipped here):
+
+Command => a
+--> Subquery: featurename = put*
+
+Command => a
+--> Subquery: calls = 3
+ -- Here we change our mind and deactivate the second query
+ -- to replace it by calls = 3:
+
+Command => s
+[1] featurename = put* is active
+[2] calls = 3 is active
+
+The total active query:
+featurename = put* and
+calls >
+
+Command => i
+--> Subquery index: 2
+
+Command => a
+--> Subquery: calls > 5
+
+The (S) Show command will show the following result:
+
+Command => s
+All subqueries:
+[1] featurename = put* is active
+[2] calls = 3 is inactive
+[3] calls > 5 is active
+
+The total active query:
+featurename = put* and
+calls > 5
+
+To change the boolean operator to 'or' rather than 'and', use the (C) Operator command. It will prompt you for the index of the operator and the new value:
+
+Command => c
+--> Operator index followed by operator ('and' or 'or'): 1 or
+
+Command => s
+All subqueries:
+[1] featurename = put* is active
+[2] calls = 3 is inactive
+[3] calls > 5 is active
+
+The total active query:
+featurename = put* or
+calls > 5
+
+==Input command==
+The (I) Input command serves to load Execution Profiles. It is initially set to *.pfi meaning that it will load all files with extension pfi. By calling the command repeatedly with new arguments, you are able to load more Execution Profiles. If you use the command without any argument, and the set of input files contained just one file, then the queries will use the last generated output. This avoids explicitly loading a file.
+==Language command==
+The (L) Language command enables you to specify the languages to which profiling should be applied. You can specify Eiffel only, C only, or both. If you specify only one language, the query results will not contain any information about routines written in the other language.
+The default is Eiffel only. To switch to both Eiffel and C, use Command => L eiffel and c
+
+To return to just Eiffel, simply type L.
+
+==Run Command==
+To run the current total query, use (R) Run.
+==Generate command==
+To run the profile converter under the command-line interface, use the (G) Generate command. This will generate an Execution Profile, stored in a file with the extension .pfi.
+When running the Generate command with no arguments, you will be prompted for the following information:
+* Name of file to be converted (default: profinfo).
+* Compilation mode: workbench or finalized (default: workbench).
+* Name of profiler tool (default: eiffel).
+
+You can also type in the arguments directly without waiting to be prompted, as in command => g profinfo finalize eiffel
+
+
+{{seealso| '''See Also'''
+[[Profiler Wizard|Profiler wizard]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki
new file mode 100644
index 00000000..a6cf8e88
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki
@@ -0,0 +1,23 @@
+[[Property:title|System menu]]
+[[Property:weight|4]]
+The System Menu gives general information about the system:
+
+ (A) Config : show the config file.
+ (L) Classes : show the classes in alphabetic order.
+ (S) Cluster hierarchy: display the cluster hierarchy of the system.
+ (C) Clusters : show the system's classes, cluster by cluster.
+ (V) Edit : edit the config file.
+ (I) Indexing : show indexing clauses of classes.
+ (O) Modifications: show classes modified since last compilation.
+ (T) Statistics : show system statistics.
+
+ (H) Help : show list of commands.
+ (M) Main : go back to main menu.
+ (Q) Quit : terminate session.
+ (Y) Yank : yank (save) output of last command to a file.
+
+The A (Config) command shows the configuration file; the E (Edit) command enables you to edit the configuration file; the C (Clusters) command is useful to display the entire list of classes, cluster by cluster.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki
new file mode 100644
index 00000000..ab0da14c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki
@@ -0,0 +1,186 @@
+[[Property:title|EiffelStudio: Command line options]]
+[[Property:link_title|Using command line options]]
+[[Property:weight|1]]
+You may start ec through a command of the following form:
+'''ec''' ''option'' ... [''class_name''][''feature_name'']
+
+
+''class_name'', if present, must be the name of a class of the system to which '''ec''' is applied. This system is identified by its configuration file; by default this is the file called Ace.ecf in the working directory, but you can select any other one through the -config ''file_name'' option. Similarly, the default project directory is the working directory, but you can select another through the -project_path ''directory_name'' option.
+
+''feature_name'', if present, must be the final name of a feature of the class called ''class_name''.
+The table below lists the available options, the arguments they require, and their effect:
+{|
+|-
+| '''OPTION'''
+| '''ARGUMENTS'''
+| '''EFFECT'''
+|-
+| ''Operation options''
+|-
+| -melt
+|
+| Normal compilation, except on an incremental recompilation where added/removed classes (of classes not in system) will be detected.
+|-
+| -freeze
+|
+| Freeze system.
+|-
+| -finalize
+|
+| Produce a finalized system. See below.
+|-
+| -precompile
+|
+| Precompile a system, treating it as a library.
+|-
+| ''Browsing operations''
+|-
+| -ancestors
+| class_name
+| Print the ancestors of the class.
+|-
+| -aversions
+| class_name, feature_name
+| Print the ancestor versions of the feature.
+|-
+| -callers
+| class_name, feature_name
+| Print all the routines that call the feature.
+|-
+| -clients
+| class_name
+| Print the clients of the class
+|-
+| -descendants
+| class_name
+| Print the descendants of the class.
+|-
+| -dversions
+| class_name, feature_name
+| Print all the versions of the feature in the descendant versions of the class.
+|-
+| -flat
+| class_name
+| Print the flat view of the class.
+|-
+| -flatshort
+| class_name
+| Print the Flat Contract view (previously called flat-short form) of the class.
+|-
+| -implementers
+| class_name, feature_name
+| Print all the classes that declare or redeclare the feature.
+|-
+| -short
+| class_name
+| Print the Contract view (previously called short form) of the class.
+|-
+| -suppliers
+| class_name, feature_name
+| Print all the suppliers of the class.
+|-
+| ''Other options''
+|-
+| -batch
+|
+| Launch the compilation without user request.
+|-
+| -clean
+|
+| Delete project if already compiled and compile project as if it was the first time.
+|-
+| -config
+| file_name
+| Use the file as configuration.
+|-
+| -c_compile
+|
+| Launch C compilation, if needed, after Eiffel compilation.
+|-
+| -file
+| file_name
+| Save the output to the file.
+|-
+| -filter
+| filter_file_name
+| Print text as processed by the filter.
+|-
+| -help
+|
+| Print the help.
+|-
+| -keep
+|
+| Keep assertions in final mode. Useful with -finalize only.
+|-
+| -loop
+|
+| Enter interactive mode. See below.
+|-
+| -metadata_cache_path
+| directory_name
+| Specify location of Metadata Cache used for .NET compilation. This overrides any settings from your configuration file.
+|-
+| -no_library
+|
+| When converting an old configuration file format, do not convert clusters into libraries.
+|-
+| -project_path
+| directory_name
+| Use this directory as compilation directory. (Default: current directory.)
+|-
+| -stop
+|
+| Stop on errors. (Default: no.)
+|-
+| -use_settings
+|
+| Use the project global settings to retrieve the project location for the last compilation of this project.
+|-
+| -version
+|
+| Print compiler version number.
+|}
+
+'''Note''': In the third column, to print means to produce the requested information on the default output of the '''ec''' command.
+
+
+Some options can have modifiers that can affect their results. The modifiers are listed in the table below:
+{|
+|-
+| '''Option'''
+| '''Modifier'''
+| '''Effect'''
+|-
+| -callers
+|-
+|
+| -show_all
+| Include all callers rather than only those in the specified class.
+|-
+|
+| -assigners
+| Restrict callers to those that use given feature only as a target of an assignment instruction.
+|-
+|
+| -creators
+| Restrict callers to those that use given feature only as a target of a creation instruction.
+|}
+
+==Finalization==
+To produce a finalized system, you may use the command '''ec''' -finalize. The effect is the same as when you press the Finalize button in the graphical environment, except for two differences:
+# All assertion checking will by default be turned off in the resulting finalized system. In the graphical environment, an interactive panel asks you whether you want to keep or discard assertions. Command '''ec''', however, was designed to be callable automatically from shell scripts or programs, and for that reason never asks for interactive user input (except under the loop option). To retain the assertion checking options specified in the configuration file, use the option -keep in connection with -finalize (the order of the two options is arbitrary).
+# At the end of the Eiffel part of the compilation you are presented with the message:
+System recompiled.
+You must now run "finish_freezing" in:
+ ''your_project_path''|EIFGENs|''target_name''|F_code
+
+
+with | replaced by \ if your platform is Windows, / if it is Unix. To execute the C compilation and linking part of the finalization, change directory to ''your_project_path''|EIFGENs|''target_name''|F_code as indicated and execute '''finish_freezing'''.
+
+{{seealso| '''See Also'''
+[[Batch compilation|Batch compilation]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki
new file mode 100644
index 00000000..32cb3ab0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Command line]]
+[[Property:weight|-13]]
+* [[Command line: Introduction|Introduction]]
+* [[EiffelStudio: Command line options|Command line options]]
+* [[Batch compilation|Batch compilation]]
+* [[Command line interactive mode|Command line interactive mode]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki
new file mode 100644
index 00000000..90a705d8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Assertions checking configuration changes]]
+[[Property:weight|0]]
+One of the major differences between 4.5 and 5.0 is how to specify the assertion checking in the ace file or in the project settings window. In 4.5, assertions of a certain type where checked if their level was below the requested level. Here is what the level hierarchy looked like:
+# require
+# ensure
+# loop
+# check
+# invariant
+# all
+
+Meaning that you could not just check one type of assertions. With 5.0 this is now possible and we changed the presentation to follow the cost to evaluate a given type of assertions, the first one being the less expensive:
+# check
+# require
+# ensure
+# loop
+# invariant
+# all
+
+The default assertion level has changed too. Not specifying any assertion level used to be equivalent to selecting the 'require' level. This is not the case any more in 5.0 it will be not checking assertions.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki
new file mode 100644
index 00000000..056e61ea
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki
@@ -0,0 +1,31 @@
+[[Property:title|Compiler differences from 4.5 to 5.0]]
+[[Property:weight|1]]
+==What's new==
+* Implementation of new external syntax.
+* Implementation of verbatim strings.
+* Implementation of agents.
+* Implementation of agent creations on `Result' and `Current' object.
+* Improved incrementality of the C compilation: fewer directories will have their C files changed after a freeze.
+* New MSIL generation.
+* Introduction of 4 new basic classes: INTEGER_8, INTEGER_16, INTEGER_64, WIDE_CHARACTER.
+* Changed the storable mechanism so that we do not store POINTER objects with their value, instead we store a NULL value. As a consequence it is safe to store on disk objects that have references to C objects. Upon retrieval those references will be equal to `default_pointer'. This is now the default behavior, if someone wants to have the previous behavior, simply call `set_keep_pointer_value' from STORABLE.
+
+==Improvements==
+* New run-time speed improvement (between 30 to 100% faster than the 4.5 release).
+* Compiler that is much faster (between 200 and 300% faster than 4.5).
+* Compiler now detects unused local variables (at freeze/finalize time only)
+
+==Bug fixes==
+* Compiler now fixes incrementality issues with frozen/melted code.
+* Degree 4/Degree 3 crash on *_SERVER when doing an incremental recompilation has been fixed.
+* Fixed crash when using creation expression that includes a feature call.
+* Fixed creation of an ARRAY of BIT type.
+* CHARACTER has been extended to support the extended ASCII which means that the following expressions are now True instead of being False as it was in our previous version:
+** '%/127/' < '%/128/'
+** '%/127/' < '%/128/'
+** When using `independent_store', in case of retrieval error due to a name change in one of the class attributes we will display the original attribute name that was used to make the storable file. This will help when managing many storable files.
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki
new file mode 100644
index 00000000..1105d0a0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0]]
+[[Property:link_title|5.0]]
+[[Property:weight|-7]]
+* [[Assertions checking configuration changes|Assertions checking]]
+* [[Changes between 4.5 and 5.0|EiffelThread]]
+* [[Compiler differences from 4.5 to 5.0|Miscellaneous]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki
new file mode 100644
index 00000000..e7a831a2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki
@@ -0,0 +1,61 @@
+[[Property:title|Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1]]
+[[Property:link_title|5.1]]
+[[Property:weight|-8]]
+==What's new==
+
+
+* .NET generation now includes:
+** Support for multiple inheritance.
+** Support for generics.
+** Partial implementation of generic conformance (same as what was supported up to and including ISE Eiffel 4.2).
+** Support for tuples and agents.
+** Support for any existing Eiffel code that does not use C externals.
+** Partial support for compiling Eiffel libraries using C externals (e.g. WEL)
+
+And the following limitations:
+** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients).
+** The compiler performances are rather poor now (both in terms of memory usage and speed)
+
+Those limitations should disappear with 5.2 which will be the official release that fully supports .NET
+** Support for INTEGER_64 constants. Now a manifest integer value that is written in decimal or hexadecimal format that can't fit into an INTEGER_32 will be automatically promoted to an INTEGER_64 constant value.
+** New feature access syntax for accessing constants, C/C++ externals and IL static externals. [[Differences between ETL 2nd printing and Eiffel Software implementation|Check out more here]] .
+
+
+==Improvements==
+* Compiler that is about 20% faster than 5.0.
+
+==Bug fixes==
+* Fixed VAPE errors that were not previously reported. Now VAPE errors are checked against arguments of a feature used in a precondition and are also checked for a qualified call.
+* Fixed a conformance bug that made a manifest array not conform to ANY.
+* Fixed a generic conformance bug where an assignment attempt would change the behavior of the execution.
+* Fixed a wrongly reported error by the compiler in the following case:
+In a system that has a generic class CLIENT with constraint `G -> SUPPLIER create make end', where the creation procedure of SUPPLIER is exported to {CLIENT}. If another class has an attribute `x: CLIENT [SUPPLIER]' the compiler reports a VTCG error, though it should accept the classes.
+
+* Fixed a crash when one of the following command lines was used in a directory with no existing project that contains no default configuration file:
+ec -flat -all
+ec -short -all
+ec -flatshort -all
+ec -flat -all_and_parents
+ec -short -all_and_parents
+ec -flatshort -all_and_parents
+
+* Fixed a bug in output display between standard output and error output. Doing the following:
+io.put_string ("foo%N")
+io.error.put_string ("bar%N")
+
+you get the following output when simply launched from the command line:
+foo
+bar
+
+however if you do:
+my_program >& RESULT
+
+to redirect both standard and error outputs to RESULT you get in the RESULT file this incorrect content:
+bar
+foo
+
+* Fixed a non reported VTEC or VTCG error when an invalid type used as actual generic parameters in an explicit type in a creation instruction.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki
new file mode 100644
index 00000000..bae36b37
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2]]
+[[Property:link_title|5.2]]
+[[Property:weight|-9]]
+==What's new==
+* .NET generation now includes support for the following language features:
+** Support for multiple inheritance.
+** Support for generics.
+** Partial implementation of generic conformance
+** Support for tuples and agents.
+** Support for any existing Eiffel code that does not use C externals.
+** Support for compiling Eiffel libraries using C externals that are not related to the Eiffel Software C runtime.
+
+And the following limitations:
+** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients).
+** No support for `expanded' keyword.
+
+
+* .NET generation now supports assembly signing in enterprise edition.
+* .NET generation now supports precompiled libraries.
+* Supports for manifest integer constants of different sizes, i.e. you can now assign for example the value `8' to a location of type INTEGER_8, INTEGER_16, INTEGER or INTEGER_64, however you can only assign the value `254' to a location of type INTEGER_16, INTEGER or INTEGER_64.
+
+==Improvements==
+* Compiler that is about 20% faster than 5.1.
+* Runtime is about 10-20% faster than 5.1
+
+==Changes==
+* One cannot create an instance of a basic expanded class ( BOOLEAN, CHARACTER, INTEGER_8, INTEGER_16, INTEGER, INTEGER_64, POINTER, REAL, DOUBLE), you will now get a VGCC(6) error. Instead directly assign to it, or create an instance of its corresponding _REF class.
+
+==Bug fixes==
+* Fixed memory corruption issue when trying to access an INTEGER_64 value.
+* Fixed a problem with manifest INTEGER_64 constants whose values were incorrectly interpreted.
+* Fixed VAPE errors that were not previously reported in 5.1. Now VAPE errors are checked against call to infix and prefix features.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki
new file mode 100644
index 00000000..cec87a8c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki
@@ -0,0 +1,164 @@
+[[Property:title|Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3]]
+[[Property:link_title|5.3]]
+[[Property:weight|-10]]
+==What's new==
+* Finalized executable with option `exception trace' enabled will now display the instruction number (usually equivalent to the line number in the routine) being executed when a failure occurred. It was already displaying this information in workbench/melted mode, we have just extended this feature to finalize mode.
+* Incremental compilation is now available for .NET code generation. Meaning that if you modify one class, only this class is being recompiled. It dramatically improves development time when targeting .NET.
+* In .NET code generation, assertions can be turned on or off on a class per class basis without having to recompile those classes.
+* Implemented [[EiffelBase, The Kernel|recoverable storable]] to enable the retrieval of slightly different version of an object. It only applies for classic Eiffel.
+
+==Improvements==
+* Enabled support for Borland C compiler in .NET.
+* Removed too many warnings during C compilation on Tru64.
+* Improved formatting of exception traces so that class names, feature names, exception tags are not truncated. Display limit has been pushed at about 256 characters.
+
+==Changes==
+* Made `\\' follow the balancing rules for various integer types.
+* Precompiled libraries now precompiles all classes reachable from clusters defined in project settings only if root class is ANY, otherwise it will only precompile classes reachable from the root class. In 5.1 and prior version it was precompiling all classes reachable from clusters.
+
+==Bug fixes==
+
+===Language issues===
+* Fixed semantic of object creations to strictly follow definition given in "Eiffel: The Language". Namely, if you have x of type X:
+create x.make is equivalent to x := create {X}.make
+It implies some bug fixes which might break existing code. For example:
+
+x: X is
+ once
+ -- If make calls back to x then it used to return
+ -- a non-Void value for x, where it should have been Void.
+ create Result.make
+ end
+
+x: X
+
+ -- If make accesses back the x attribute then it used to return
+ -- new value of x rather than the old value.
+create x.make
+Or in melted code only the following code now works properly, i.e. make gets the old value of x, not the new one
+create x.make (x)
+
+* Fixed undetected VDRD(3) errors: compiler was not strict enough and accepted ensure where only ensure then was valid.
+
+===Store/Retrieve issues===
+* Fixed issue in storable mechanism when retrieving expanded objects.
+* Fixed issue with independent_store where storing arrays of objects whose count was greater than 65536 will cause a memory corruption.
+* Added correct_mismatch on HASH_TABLE to enable retrieval of the 5.1 and older version of HASH_TABLE.
+
+===Runtime/code generation issues===
+* Fixed incorrect C code generation in final mode when creating an ARRAY of expanded type.
+* Fixed incorrect C code generation in final mode when creating a complex object which contains expanded objects that have expanded objects.
+* Fixed random crash issue in finalized applications due to incorrect memory management when you have code similar to:
+ f (g: STRING): ANY is
+ do
+ Result := create {STRING}.make_from_string (g)
+ end
+
+* Fixed issue with deep_equal on ARRAY of expanded types which was returning False where it should have returned True .
+* Fixed code generation issue with double constants where code below was not producing the expected result of 1e+030:
+ value: DOUBLE is 1.0e15
+ print (value * value)
+
+* Fixed issue in melted code where computation such as INTEGER_X // INTEGER_Y will either crash or give an incorrect computation where X and Y represents integers that are either 8, 16, 32 or 64 bits long and X < Y.
+* Fixed incorrect C code generation of finalized code when your project configuration includes a precompiled library and that you cancel finalization process at degree -2, and then restart a finalization.
+* Fixed issue with incorrect C code generation of inspect instruction based on character values above 128.
+* Fixed compilation crash at degree 3 with following code:
+ local
+ i: INTEGER
+ do
+ i := << 1 >> @ 2
+ end
+
+* Fixed a crash in finalized mode with invariant checking enabled with following code and when checking the invariant triggers a garbage collection cycle:
+ value: INTEGER
+ is_value_required: BOOLEAN is
+ do
+ Result := value = 1
+ end
+
+
+* Fixed crash of compiler at degree 4 while trying to compile this incorrect class:
+class CRASH
+
+inherit
+ CHAIN -- Missing generic parameter
+
+create
+ make
+
+feature -- Initialization
+
+ make is
+ do
+ end
+
+ index: INTEGER is
+ do
+ end
+
+ duplicate (n: INTEGER): like Current is
+ do
+ end
+
+end
+
+* Fixed issue with pathological memory allocation scheme that could trigger an `out of memory' exception where enough memory is still available.
+* Fixed incorrect allocation of expanded arrays where creation routine of expanded class was not called on all items of the newly created array.
+* Fixed incorrect creation type of attribute where attribute's type has some generic parameter. In some cases, instead of creating an ARRAY [B2 [C]] it would create an ARRAY [B2 [STRING]].
+
+===.NET issues===
+* Fixed issue in IL code generation where having a class that inherits from a non-Eiffel .NET class. And the class has the following features:
+ a: ARRAY [like f]
+ f: STRING is
+ do
+ end
+Then you could neither load nor execute the generated code.
+* Fixed incorrect C file naming when generating a .NET system that uses a C++ external (it should be .cpp, not just .c).
+* Fixed incorrect .NET code generation with following assignment attempts whose source is expanded:
+ local
+ a: ANY
+ o: SYSTEM_OBJECT
+ do
+ a ?= 12
+ o ?= 12
+ end
+
+* Fixed incorrect code generation in .NET for assertions checking with following code where precondition of test will not be checked although it should:
+ make is
+ do
+ test_which_fail_and_rescued
+ test
+ end
+
+ test is
+ require
+ should_be_checked: False
+ do
+ end
+
+ test_which_fail_and_rescued is
+ local
+ retried: BOOLEAN
+ do
+ if not retried then
+ failure
+ end
+ rescue
+ retried := true;
+ retry
+ end
+
+ failure is
+ require
+ should_be_checked: False
+ do
+ end
+
+* Fixed .NET verification issue where sometimes you could get the following message when checking an Eiffel assembly against peverify: [IL]: Error: Unverifiable PE Header/native stub.
+* Fixed incorrect code generation when creating and accessing a NATIVE_ARRAY of expanded type.
+* Fixed incorrect metadata heap generation to use standard CLI tables.
+* Fixed bug where content of NATIVE_ARRAY could not be looked up in .NET debuggers (cordbg, DbgClr or Visual Studio)
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki
new file mode 100644
index 00000000..39702ee7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki
@@ -0,0 +1,79 @@
+[[Property:title|Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4]]
+[[Property:link_title|5..4]]
+[[Property:weight|-11]]
+==What's new==
+* Support for assertion checking on external routines.
+* Removed limitation about implementing or redefining a non-external routine by an external one and vice versa.
+* Support for new C/C++ inline specification.
+* For .NET, allow calling of overloaded features for a .NET classes to be called without using disambiguated names. Disambiguated names are still needed when redefining inherited features from .NET classes.
+* Support for inclusion of .NET resources within Eiffel assemblies.
+* Launch C compilation when needed if "-c_compile" option is specified on the "ec" command line.
+* Added ability to define custom attributes on assembly. One as to define custom attributes under the new `assembly_metadata' index clause of the root class.
+* Limited support for new convert keyword (only on argument passing and assignments. Not supported when used with infix routines).
+
+==Improvements==
+* Improved speed of compilation by about 20-30%
+* Improved run-time memory allocation speed and footprint so that it has a 15%-20% faster allocation scheme and takes less memory than before.
+* Reduced waiting time at the end of the degree 6 when performing a compilation from scratch (reduced to about 50% or more of the time it used to take)
+* Improved speed of TUPLE creation and TUPLE access which generates more compact C code.
+* Improved speed of agent calls by a factor of 2 to 3.
+* Improved speed of Eiffel calls from C (CECIL and use of $ operator on routines). It also makes generated executables smaller (about 1-5% smaller depending on number of routines used in this context)
+
+==Changes==
+* Changed the way we generate calls to C/C++ external routines. It is possible that because of this change, code that used to C compile, will not compile anymore. This happens mostly when mixing C and C++ code and the C call being made is incorrect but was not previously checked against the C header files if provided.
+* In multithreaded mode, all C externals that could potentially block the execution of the system should be marked `blocking' as in:
+ sleep (m: INTEGER) is
+ external
+ "C blocking"
+ end
+Not doing it could generate dead-lock during the execution of a multithreaded system.
+* Static access on externals is now only authorized when external is a frozen external without assertions.
+* Compiler will now report a warning for assignments like those:
+td: TUPLE [DOUBLE]
+ti: TUPLE [INTEGER]
+
+td := ti
+The warning will help you correct code using this pattern, because in the next release this will be rejected in order to conform to the Eiffel language specification.
+* Now we do not generate by default the .NET attribute ComVisibleAttribute with a False value. If needed it has to be done through the new compiler functionality to add custom attributes on assembly.
+* Changed indexing clause tag for specifying custom attributes for .NET systems. Now `attribute' is replaced by `metadata'. Now you can have:
+** metadata: generated for both interface and implementation classes
+** assembly_metadata: generated for assembly only when specified in root class of system
+** class_metadata: generated only for implementation class
+** interface_metadata: generated only for interface class
+
+
+==Bug fixes==
+
+===Language issues===
+* Now checks for valid export status in agent creation. Meaning that in class MY_CLASS, the following agent creation agent target. call is valid if and only if call is exported to MY_CLASS.
+* Allowed type specification for open operands in agent creation, i.e. one can now write: agent f ({ A}).
+* Fixed bug which allowed compiler to accept the following incorrect code: char: CHARACTER is "rdsf"
+* Fixed bug in error reporting for incompatible BIT types involving bit manifest constants. It would always report BIT 0, instead of the actual number of bits in the bit manifest constant.
+
+===Compiler issues===
+* Fixed non-detection of changes when changing code from agent call to agent Current . call. Which should check for the validity of export of call to current class.
+* Fixed creation and assignment attempts on generic types that have anchored types in their generic parameter, and the anchor is itself generic.
+
+===Runtime/code generation issues===
+* Fixed issue when shared library definition file did not exist or was invalid. Now it will not produce any C compilation errors.
+* Fixed bug in recoverable storable when there is a mismatch. The first assignment attempt in internal_correct_mismatch from ANY would crash.
+* Fixed issue when retrieving storable files that contain TUPLE instances.
+* Fixed issues when using agents in a multithreaded application, they will sometimes disable the garbage collector and the application might quickly run out of memory.
+* Fixed random crashes when EIF_MEMORY_CHUNK, EIF_MEMORY_SCAVENGE and EIF_STACK_CHUNK environment variables had an incorrect value. Instead the runtime will now fix the value to an appropriate one.
+
+===.NET issues===
+* Fixed bug in code generation with following statement:
+l_time: TIME_SPAN
+print (l_time.total_milliseconds.out)
+
+* Fixed incorrect code generation with code accessing attributes of .NET expanded types.
+* Fixed incorrect computation of equal when used with basic types, e.g. equal (1, 1) would return False instead of True.
+
+===Store/Retrieve issues===
+* Fixed memory corruption bug with recoverable storable when a mismatch was detected
+* Fixed issue where mismatch was not detected if attributes were dropped
+* Fixed issue with independent store when storing TUPLE objects where it would crash if storable did not include a reference to ANY.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki
new file mode 100644
index 00000000..f74c3912
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki
@@ -0,0 +1,148 @@
+[[Property:title|Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5]]
+[[Property:link_title|5.5]]
+[[Property:weight|-12]]
+==What's new==
+* Full support for new convert keyword.
+* Made Void, previously a feature of ANY, a keyword. This prevents the renaming of Void into not_void previously possible when it was a routine of ANY.
+* Addition of the reference keyword used in generic constraints (See next point).
+* Added support for reference and expanded constraints on a formal generic parameter. In other word, one can now write:
+class A [reference G] ... end
+class B [expanded G] ... end
+to say that the valid actual generic parameters for A are always reference types, and for B are always expanded types.
+* Added support for Microsoft .NET 2.0 runtime.
+* Allowed agent creation on infix or prefix routines.
+
+==Improvements==
+* Reduced, in classic mode, size of finalized executables by 10 to 50%.
+* Improved speed of evaluation of global onces, in a multithreaded system, by having a lock-free mechanism after a once has been evaluated.
+* Reduced memory usage of special of expanded which do not have any reference attributes. Before there was a 8 bytes (or 16 bytes depending on the platform) overhead per item in the special.
+
+==Changes==
+* Compiler is now checking that you cannot redeclare a formal generic parameter into a reference type unless the formal generic parameter is being constraint to be always a reference type (See the '''What's new''' section above).
+* Removed obsolete eifcid, eif_expand and eifexpfrom the CECIL interface, one has to use eif_type_idinstead.
+* In .NET, changed the naming conventions of resources included in an assembly. The extension `.resources' is appended for resources that are originally provided as `.resx' or `.txt' files. Other files are embedded as is in the assembly and the name of the resource is the name of the file.
+* In .NET, now all classes inherit from ANY. Before all classes inherited from SYSTEM_OBJECT. The consequences are:
+** You can write an Eiffel generic classes where the actual generic parameter is a .NET class.
+** If you used to inherit from .NET classes and Eiffel classes you can replace the inheritance clause below:
+class A
+inherit
+ APPLICATION_EXCEPTION
+ undefine
+ finalize,
+ equals,
+ to_string,
+ get_hash_code
+ end
+
+ ANY
+by the much simpler inheritance clause:
+class A
+inherit
+ APPLICATION_EXCEPTION
+
+
+** If you were using a feature of SYSTEM_OBJECT directly on Eiffel classes, now you need to assign the value to a variable entity of type SYSTEM_OBJECT. In other word:
+e: EIFFEL_CLASS
+o: SYSTEM_OBJECT
+...
+o := e
+o.feature_of_system_object
+
+** The following assignment attempt will succeed whereas it failed before because SYSTEM_OBJECT did not inherit from ANY:
+a: ANY
+o: SYSTEM_OBJECT
+...
+check o /= Void and a = Void end
+a ?= o
+check o /= Void and a /= Void end
+
+
+* New format of the independent storable files which takes into account internal changes made for a better generic conformance in classic mode.
+* New validity rule for expanded types: It is valid to use an expanded type of base class C in the text of a class B if and only if it satisfies the following conditions:
+** C is not a deferred class
+** C's version of the procedure default_create (inherited from ANY) is one of the creation procedures of C available to B for creation.
+
+* New validity rule for expanded class: An expanded class C needs to have the version of the procedure default_create (inherited from ANY) as one of its creation procedure.
+
+==Bug fixes==
+
+===Language issues===
+* Fixed issue about conformance checking of type containing a formal generic parameter. We would always evaluate the formal to its constraint, thus allowing the code below to be accepted where it should not have been:
+
+class A [G]
+feature
+ bug is
+ local
+ l_any: LIST [ANY]
+ l_g: LIST [G]
+ do
+ l_any := l_g
+ l_g := l_any
+ end
+
+The workaround is to use the reference keyword to guarantee that the formal generic parameter will always be instantiated with a reference type. For example the code below is correct:
+
+class A [reference G]
+feature
+ bug is
+ local
+ l_any: LIST [ANY]
+ l_g: LIST [G]
+ do
+ l_any := l_g
+ l_g ?= l_any
+ end
+
+
+
+===Compiler issues===
+* Enabled creation of SPECIAL instances, no need to create an instance of TO_SPECIALor ARRAY to get a SPECIALinstance. Now you can simply do:
+my_special: SPECIAL [INTEGER]
+create my_special.make (10)
+
+* Fixed incrementality issues with strip and static calls on external routines which could fail after a class has been added to or removed from the system.
+
+===Runtime/code generation issues===
+* Fixed incorrect code generation which would result in a C compiler error in classic mode when assigning a Void entity to a formal generic parameter that will be instantiated as a basic type.
+* In multithreaded mode, fixed dead lock on Unix platforms when evaluating global onces.
+* In multithreaded mode, prevented dead lock when a thread is exiting.
+* In multithreaded mode, prevented memory corruption which could occur if the first thing that a thread performs when launched is to trigger a GC collection.
+* Fixed incorrect generic conformance data when manipulating expanded generic types. For example, the following code:
+class A [G, H]
+feature
+ item: H
+end
+
+class C [G]
+end
+
+class ROOT_CLASS
+create
+ make
+feature
+ make is
+ local
+ l_a: A [STRING, expanded C [ANY]]
+ do
+ create l_a
+ io.put_string (l_a.item.generating_type)
+ end
+end
+
+would print
+expanded C [STRING]
+instead of
+expanded C [ANY]
+
+* Fixed issue where you could get a bogus reference when trying to get a reference to the object associated to an ID (obtained through the IDENTIFIED class).
+
+===.NET issues===
+* Fixed incorrect code generation of native arrays which would cause the code to be rejected in newer version of the .NET Framework.
+* Fixed incorrect computation of `max_stack' for a routine body which could make the generated code not verifiable.
+
+===Store/Retrieve issues===
+* Fix some issues related to the use of recoverable storable when manipulating generic types.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki
new file mode 100644
index 00000000..0782d02a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki
@@ -0,0 +1,152 @@
+[[Property:title|Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6]]
+[[Property:link_title|5.6]]
+[[Property:weight|-13]]
+==What's new==
+
+{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
+* Implemented once manifest strings. They can be used at the same places where normal manifest strings can be used, e.g.:
+s := once "abc"
+io.put_string (once "Hello World!")
+Once manifest strings are not created every time they are accessed. Instead one instance is created at the first access and then it is reused for subsequent accesses. In multithreaded application one instance is created for one thread.
+* Supported aligned and non-aligned verbatim strings. Aligned verbatim strings use characters [ and ] in opening and closing sequence respectively, non-aligned verbatim strings use { and }.
+* Added support for manifest type expression "{MY_TYPE}" which gives an instance of TYPE [MY_TYPE].
+* New syntax for manifest constants. Now they can be preceeded by a manifest type expression. For example 1 is of type INTEGER, whereas {INTEGER_8} 1 is of type INTEGER_8.
+* Support for NATURAL_XX types which are unsigned integers.
+* Supported new feature alias syntax to specify operator and bracket names:
+negate alias "-": like Current ...
+multiply alias "*" (other: like Current): like Current ...
+item alias "[]" (index: INTEGER): G ...
+The first two declarations can be used similar to features prefix "-" and infix "*". The last one can be used to make feature calls with bracket expressions like
+letter := letters [i]
+Operator and bracket aliases can also be used in rename subclause to change an alias name associated with a feature.
+* Supported new feature assigner syntax to associate feature with an assigner command:
+item alias "[]" (index: INTEGER): G assign put ...
+put (value: G; index: INTEGER) ...
+Given the declaration above the following instructions become equivalent:
+x.put (x.item (i + 1), i)
+x.item (i) := x.item (i + 1)
+x [i] := x [i + 1]
+
+
+==Improvements==
+* Optimized .NET code generated for inspect instruction.
+* Optimized access to process-relative once routines to avoid heavy-weight synchronization primitives when possible.
+* Speed-up access to once routines in finalized multi-threaded applications.
+* Improved some error messages to be more precise.
+* Removed the requirement to freeze code that declares process-relative once routine.
+* Improved multi-threaded application performance in classic mode by using built-in support for thread-local storage provided by some ''C'' compilers.
+* Allowed underscores in hexadecimal literals.
+* Provided syntax highlighting for hexadecimal literals in editor.
+* Slightly improved reporting of syntax errors.
+* Made keyword operator names clickable in flat view.
+
+==Changes==
+* Void does not conform to expanded types. As a consequence, assignments of Void to expanded entities will be rejected rather than throwing an exception at run-time. And comparison of expanded entities to Void will cause a VWEQ validity error.
+* Changed default behavior of once routines in .NET mode from once-per-process to once-per-thread to match behavior in classic mode.
+* Provided project options (old_verbatim_strings and old_verbatim_strings_warning) to support semantics of verbatim strings as in previous versions when they were not left-aligned.
+* Changed processing of hexadecimal integer literals to be consistent for different integer types. For example, 0xFF gives 255 when assigned to a variable of type INTEGER rather than -1 as before.
+* Due to the new {} syntax, a few older syntax constructs have been removed:
+** "{X} Precursor (..)" is rejected and should be replaced by "Precursor {X} (...)".
+** "agent f (?, {A})" is now rejected, as it would conflict with a manifest type expression, instead you should write "agent f (?, {A} ?)".
+
+* In .NET, all usage of INTEGER_8 from .NET libraries have been changed to NATURAL_8.
+* In .NET, renamed TYPE, ATTRIBUTE_ and VOID_ from the mscorlib assembly into SYSTEM_TYPE, SYSTEM_ATTRIBUTE and SYSTEM_VOID.
+* Changed exception handling for once routines so that exception raised during the first call is raised during any subsequent call to this routine.
+* Introduced upper limit for value of integer constant used in BIT type declaration and extended VTBT rule to cover this change.
+* To evaluate the type of a manifest array we now use the first item of the manifest array instead of the last one as a first guessed type.
+* Allowed for integer literals with intermediate underscores at arbitrary positions.
+* To ensure same behavior on various platforms, the standard output is now unbuffered (it previously was unbuffered on Windows and line buffered on Unix platforms).
+
+==Bug fixes==
+
+===Language issues===
+* Used '%N' as an end of line in verbatim strings regardless of the end of line sequence in source code.
+* Fixed incorrect handling of negative hexadecimal integer literals when sign before the literal was not taken into account. For example, -0x1 could be interpreted as 1.
+* Implemented checks for input ranges of integer constants and fixed issue with inability to assign minimum integer values to variables of the corresponding integer types.
+{|
+|+ Allowed integer values
+|-
+| Type
+| Integer interval
+| Unsigned hexadecimal representation
+|-
+| INTEGER_8
+| -128 .. 127
+| 0x0 .. 0xFF
+|-
+| INTEGER_16
+| -32768 .. 32767
+| 0x0 .. 0xFFFF
+|-
+| INTEGER_32
+| -2147483648 .. 2147483647
+| 0x0 .. 0xFFFFFFFF
+|-
+| INTEGER_64
+| -9223372036854775808 .. 9223372036854775807
+| 0x0 .. 0xFFFFFFFFFFFFFFFF
+|}
+
+* Excluded nonsignificant leading zeroes from determination of allowed integer constant type, so that 00000000000000123 is now a valid INTEGER_8 value.
+* Shared the same data accross once routines and string constant attributes from different generic derivations of the same class. Added a warning for once routines that appear in a generic class to notify about this change in semantics.
+* Correctly supported replication of once features when compiling for .NET.
+* Changed order of evaluation of once routines to check precondition with class invariant even when once routine has already been called.
+* Added a check that length of identifier, manifest string and free operator does not exceed a maximum value of 32767 bytes.
+
+===Compiler issues===
+* Fixed crash of the compiler at the very end of a finalization of a system which has an assignment of a manifest type into a variable of type ARRAY [like anchor] where anchor is a feature being redefined with a different type in a descendant class.
+* Fixed an issue where compiler would report more than once the same error in an incremental recompilation.
+* Fixed issue where changing a normal routine to an external and having a compile error, and then reverting back to a normal routine while fixing the error would cause the compiler to crash.
+* Fixed some cases where project could be corrupted after a recompilation.
+* Now compiler reports VTCT errors at the end of degree 5, rather than during degree 5, so that you can collect all the VTCT errors at once.
+* Thanks to the improvement in VTCT errors reporting, now compiler will not generate an incorrect VTCT errors during an incremental recompilation for a class which has actually been removed from the system.
+* Supported recompilation of once routines when their status is changed from "process-relative" to "thread-relative" or back.
+* Supported output of multi-line obsolete messages.
+* Fixed a recompilation bug that resulted in incorrect (or even, in case of .NET, in invalid) generated code when incrementally finalizing a system without explicitly specified root creation procedure.
+* Fixed a bug with resolving some generic-like types (i.e., types that are processed in a special way: tuple, native array, typed pointer) that depend on anchored types: before they were converted to "normal" generic types thus loosing their special properties.
+* Fixed a bug that caused compiler to crash when finalizing a code that looks like
+if true then [else(if) ...] end
+i.e. has empty compound for a primary condition which is a constant true.
+* Fixed a bug in processing configuration option precompiled that caused a compiler to crash when no option value was provided.
+* Fixed a bug in incremental recompilation when multi-branch validity rules are violated in one class because constant attribute used in the multi-branch instruction is changed in another class, that declares them, into a non-constant feature.
+* Fixed multiple bugs in feature basic text view that caused truncated or extraneous output.
+* Fixed bug where if an actual generic parameter was an anchor, then if the type containing this actual was used for assignment attempt or for creation we would use an incorrect type for the actual generic. We were using the type of the anchor in the class were the code was written, instead of actually re-evaluating the type of the anchor for each descendant class.
+
+===Runtime/code generation issues===
+* Fixed bug in deep_twin from ANY in .NET which would cause a call on Void target when applied on object of type STRING and possibly other types.
+* Corrected C code on Windows for constants of type INTEGER_64. Before constants of this type between -2147483648 and -1 could be processed as positive 64-bit values.
+* Fixed incorrect C and IL code generation for INTEGER_8 and INTEGER_16 arithmetic and shift operations that might produce incorrect result when combined in two or more operations in a row. For example,
+i := (i + i) |>> 1
+assigned -128 to i of type INTEGER_8 if the initial value of i was -128. Now this instruction assigns 0.
+* Synchronized access to data of process-relative once routines to avoid race conditions when two or more threads simultaneously access the same once routine.
+* Avoided permanent blocking of a thread accessing process-relative once routine when this routine is concurrently evaluated in some other thread and raises an exception.
+* Fixed bugs in memory allocation in C code for result of a once function that returns basic type:
+** it might cause memory corruption when memory size required to store the result is greater than size of a pointer;
+** there was a memory leak.
+
+* Fixed a bug in classic mode that caused last exception to be cleared after returning from a routine that has a rescue clause but returns normally.
+* Fixed several bugs related to handling of nested exceptions in classic mode.
+* Changed a limit of maximum class name length in melted byte code from 256 bytes to 32767 bytes.
+* Changed C code generation for long strings (that result from long manifest strings, identifiers, etc.) to avoid restrictions imposed by some C compilers on long string literals (in particular, by the Microsoft C compiler cl that issued error C2026).
+* Fixed a bug in finalized C code generation when calling Precursor in a routine which is recursively calling itself before the call to Precursor. Instead of generating the call to Precursor we would generate a recursive call to the routine.
+* Fixed a bug where calls to standard_is_equal from ANY on objects whose type is generic would yield False where it should have been True.
+
+===.NET issues===
+* Corrected processing of literal floating point fields from external assemblies (such as System.Math.PI) to obtain proper values.
+* Fixed a bug where the value -1 was actually 255 on .NET.
+* Fixed issue where declaring a NATIVE_ARRAY of a .NET expanded type would be rejected by the compiler.
+* Fixed issue where assigning a .NET expanded type to an entity of type ANY would be rejected by the compiler.
+* Fixed a crash in the compiler when generating the code for a class which inherits from a .NET class and from an Eiffel class which has some anchored types.
+* Fixed a bug in assertion monitoring that could lead to wrong monitoring of assertions that are evaluated concurrently in different threads.
+* Fixed a bug in code generation for entry point of executable when root procedure is a redeclaration of a deferred feature that caused an exception MissingMethodException to be raised on startup of such an application.
+* Fixed a bug in code generation when solely inheriting from a .NET interface.
+* Fixed a bug in code generation when inheriting from a .NET class which has a routine whose name is identical to one of the routine of ANY.
+* Fixed a bug in code generation of custom attributes encoding in the case of a named argument whose base type is a .NET enum type.
+* Improved conforms_to from ANY so that even though full generic conformance is still not yet supported, it checks it properly when the base class are the same.
+
+===Store/Retrieve issues===
+* Fixed an issue where the GC would be disabled after a failure in a retrieval operation.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki
new file mode 100644
index 00000000..de65d651
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki
@@ -0,0 +1,67 @@
+[[Property:title|Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7]]
+[[Property:link_title|5.7]]
+[[Property:weight|-14]]
+==What's new==
+
+{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
+* Support for new expanded semantics defined in ECMA-367. The current limitations are: no copy semantics in the .NET code generation, and still no generic conformance.
+* Inline agents as defined in ECMA-367 with the limitation to only accept the do form.
+* Added possibility to define agents on attributes or externals.
+* Named tuples as defined in ECMA-367.
+* Added PREDICATE class for agent based on boolean queries.
+* Added CHARACTER_32 for Unicode support.
+
+==Improvements==
+* Improved memory management:
+** Ensure that if a block of allocated memory is not used it will eventually be freed. Before it will only be freed if it was the last allocated block.
+** Compaction is actually working. Before it was working if you had a lot of dead objects, now it will compact even if all you have is alive objects and that the memory is fragmented.
+** For large memory heap (i.e. larger than 1GB) improved speed of collections where there is a lot of dead objects.
+
+* Changed the way we search melted file, it is done in the following order:
+** Directory specified by environment parameter MELT_PATH
+** Current working directory
+** Directory where application is launched
+** Original directory where .melted file was generated the first time.
+
+* Improved speed of initial compilation of .NET projects as well as the speed for incremental compilation at degree 6 which went from a few seconds to no time if no new assemblies have been added to the system.
+* No freeze is required when adding an agent, saving you time since C compilation can be long for very large project.
+* Reduced the required disk space for a workbench compilation in classic mode (went from 1.8 GB to 1GB for a very large project).
+* Improved speed of agent calls in classic mode.
+* Support use of IL enumerations with underlying integer types different from System.Int32. In particular, the built-in features `to_integer' and `from_integer' now use the underlying type rather than System.Int32.
+* Support generation of IL properties as well as custom attributes for them.
+* Support the new syntax without the is keyword in the feature declaration.
+* Allowed bracket expressions to be used as a target of a qualified feature call (this is an extension to ECMA standard that does not permit this syntax at the moment).
+* Added checks for VYCP(2,3) and VYCQ(2,3) (validity rules for conversion features to prohibit conversion to conforming types).
+
+==Changes==
+* VWEQ is not an error, but a warning that can be triggered or not depending on your configuration.
+* Inherited assertions are rechecked each time that a feature is redefined, meaning that some errors that were not previously detected by the compiler can now be found.
+
+==Bug fixes==
+* Fixed an issue with x2c if you had inlined C code which contains comments with single or double quote. Then it will not properly convert .x into .c file.
+* Fixed bugs in code generation for once manifest strings that caused "index out of bounds" exception, void results.
+* Fixed a bug in processing synonyms of a routine with an indexing clause that might cause a compiler crash, in particular this could happen for synonyms of a global once routine.
+* Fixed a bug in recompilation of a once routine that changes its process-relative status into thread-relative one or back in multithreaded finalized mode that can cause C compilation to fail due to unresolved externals.
+* Corrected inlining of routines redeclared into attributes or into routines with a different internal/external status.
+* Fixed a bug in incremental recompilation of queries with assigner commands.
+* Added detection of a VUEX error for static feature calls used in intervals of a multibranch instruction.
+
+===Compiler issues===
+* Added a new validity error VTEC(3) to report unsupported inheritance hierarchy under .NET when an expanded type is based on a class with an external ancestor.
+* Not supported reverse attachment of boxed built-in .NET value types to Eiffel reference types such as NUMERIC, HASHABLE, etc.
+
+===Runtime/code generation issues===
+* Ensured that our runtime is async-safe for signals for all the runtime routines using some locking mechanisms.
+* Fixed a memory corruption issue in arycpy if a GC cycle was triggered as part of the processus of reallocating the SPECIAL object.
+* Fixed a bug with allocating memory for once routines that caused "no memory" exception at program startup when Borland run-time is used.
+
+===.NET issues===
+* Removed limitation to inherit an Eiffel class which inherited from a .NET class.
+
+===Store/Retrieve issues===
+* Fixed a memory leak in the recoverable retrieval when an exception is raised from a correct_mismatch routine call.
+* Fixed test#store008 regarding a crash when retrieving a type that does not exist in retrieved system.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki
new file mode 100644
index 00000000..c8d29af9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki
@@ -0,0 +1,71 @@
+[[Property:title|Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0]]
+[[Property:link_title|6.0]]
+[[Property:weight|-7]]
+==What's new==
+
+{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
+* Added support for multiple constraints in formal generic parameters.
+* The root class can now be a generic class, and thus one can now specify a root type.
+* The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
+* Added experimental option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries. The next release should fix all the remaining issues.
+* Integers can now also be specified with binary and octal representation.
+* Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit.
+* Supported reattachment of generic derivations with expanded parameters to generic derivations with reference parameters.
+
+==Improvements==
+* The command line compiler doesn't need a configuration file to compile a system, one can simply provide a root class and the compiler will automatically use the current directory and EiffelBase. You can also add more libraries if needed.
+* Improved backup mechanism so that overridden classes are copied in the library where they are defined (they were previously copied in the library where the override cluster was defined).
+* Possibility for hidden/implementation clusters in libraries, i.e. clusters that are not accessible if the library is used (like libraries in libraries are not accessible).
+* Class names which don't match the source filename emit a warning.
+* The unique keyword will yield a syntax warning if enabled.
+* Static access on external routines is allowed even if not marked frozen (this simply applies a relaxed rule that was adopted by ECMA).
+* When an environment variable is being used to compile a system and if this environment variable value changes next time you use a project, you will get a prompt asking whether or not you want to update the value or keep the initial one.
+* Externals (includes, objects, resources, ...) can now be relative to the ecf file by using the new replacement $ECF_CONFIG_PATH.
+* UUID is not needed for non library systems. If no UUID is specified a random one will be generated.
+
+==Changes==
+* Added supplier_precondition assertion level that enables to only check preconditions of trusted libraries. By default when importing an old project they are not enabled, thus assertions on the library you are using are most likely going to be disabled.
+* Added the platform value as part of the version info of the compiler. This will prevent trying to load a project compiled for a different platform instead of failing with a retrieval error.
+* The compiler can be compiled against the original EiffelBase version or with the FreeELKS version which is now the default one for EiffelBase.
+
+==Bug fixes==
+* Fixed eweasel test#tuple006 showing a failure when calling deep_copy on a TUPLE instance.
+* Fixed bug#12782 where compiler would crash at degree 1 when removing a formal generic parameter of class (eweasel test#incr249 and test#incr284).
+* Fixed bug#12823 where specifying in the command line a target in a different case than the lower case version of the actual target name would fail to find the target in your configuration file.
+* Fixed bug#12698 where compiler was not processing the target extension properly if not specified in lower case.
+* Fixed bug#12591: compiler would not find classes from library referenced deeply using relative path. This also removes the extra `.' or `..' in the displayed path for a class.
+* Fixed issue with incorrect labeled tuples which were not detected in signature of features (see eweasel test#tuple008).
+* Fixed crash when checking an incorrect labeled tuple (e.g. TUPLE [a, a: INTEGER]) (see eweasel test#tuple009).
+* Fixed issue with inline agents where if you have one and during a compilation from scratch you have a compiler error, then fixing this error and recompiling, it would crash when melting or freezing (test#incr277).
+* Fixed issue with C compilation linking error when a generic class which have an invariant clause has its formal generics changed (test#incr278).
+* Fixed C compilation error on Windows for trying to compile empties Cxxx directories (test#ccomp061).
+* Fixed incorrect code generation of agents on attribute when target is open (test#exec264).
+* Fixed incremental bug when an agent creation based on a feature whose signature changes for less arguments (test#incr276).
+* Fixed a backup creation bug when two classes from the same cluster/library have the same original file name, the backup would only contain one or the other because we use the original file name. Now we use the original class name.
+* Fixed various issues with the processing of the Eiffel Configuration File.
+
+===Compiler issues===
+* Adapted the compiler so that ISE_EIFFEL does not need to be defined with a short path name on Windows, since some file systems can disable support for short path.
+* Fixed incrementality bug with agents where finalizing and then freezing would cause some unresolved externals.
+
+===Runtime/code generation issues===
+* Fixed a memory corruption which would occur once an invariant has been violated.
+* Fixed a memory corruption which could occur when performing a deep_twin on an object whose graph contains a TUPLE object. See test#tuple006.
+
+===.NET issues===
+* Speed up consumer cache synchronization so working with large .NET caches or large assembly sets is much faster.
+* Fixed bug#12565 where a wrong EIFFEL_NAME_ATTRIBUTE custom attribute would be generated on .NET for Eiffel generic class where the actual generic parameter is a .NET value type..
+* Fixed bug in .NET resx to resource generation when using resx files with relative paths.
+* .NET Enums can be automatically converted to INTEGERs.
+* Indexing tags ''interface_metadata'' and ''class_metadata'' are supported on feature level like this is done on class level and allow to specify custom attributes for associated methods only in interface type or only in implementation type.
+* All versioned COM import interfaces now have versioned interface member names based on the trailing version number of the interface name, as this meta information is not available in any other way. This greatly improves the versioned names and makes implementing interfaces much easier.
+* Fixed various issues in the .NET consumer that would prevent the usage of certain .NET assemblies.
+* Added configurable (project to class-level) optimization for .NET project that will mark all classes frozen if they are not descended by another.
+
+===Store/Retrieve issues===
+* Now the retrieval of objects is done with the GC (garbage collector) disabled.
+* Fixed issue when retrieving 64-bit storables on 32-bit machines. It requires a regeneration of the 64-bit storables if one wants to retrieve them on 32-bit machines. Fixed bug#11744.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki
new file mode 100644
index 00000000..f07013f1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki
@@ -0,0 +1,50 @@
+[[Property:title|Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1]]
+[[Property:link_title|6.1]]
+[[Property:weight|-8]]
+==What's new==
+
+{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
+* Multiple errors are reported for each compilation degree.
+* Experimental support for Non-conforming Inheritance has been added (Classic only). Classes may now be inherited (using inherit {NONE} but no conformance of that class is implied.
+* Attachment marks are supported. Now it's possible to specify whether an entity is attached or detachable:
+a: !A -- a cannot be used before it is attached
+b: ?A -- b can be used before it is attached
+Default attachment status (for types without an attachment mark) is controlled by the option ''is_attached_by_default''.
+* Object test expression is a replacement for the reverse assignment construct with a new notion of scope:
+if {o: !A} e then do_something_with (o) end
+
+* Attached variables are subject to the new check that they are properly set before use, in particular, attached attributes must be set by a creation procedure and all attached local variables must be set before they are used. The checks are performed when the option ''is_void_safe'' is turned on.
+* A feature call can be performed only on an attached target if the option ''is_void_safe'' is turned on.
+* Certified attachment patterns (CAP) are used to identify additional cases when an entity is attached (controlled by the option ''is_void_safe''). In particular, the following code is considered void-safe:
+f (a: ?ANY)
+ do
+ if a /= void then
+ x := a.out
+ end
+ end
+
+
+==Improvements==
+* Improved speed of degree 3. Improvements are even more visible when the checking of inherited features in their descendants is enabled.
+
+==Changes==
+* No major known changes.
+
+==Bug fixes==
+* Fixed an issue where the version of default_create from ANY would not yield a dynamic binding if statically it had an empty body (See test#exec280).
+
+===Compiler issues===
+* The options ''is_void_safe'' and ''is_attached_by_default'' are not tracked during recompilation, so in order to take any changes in their settings, the project has to be recompiled from scratch.
+* Object test is not permitted inside a precondition or a check instruction.
+* Object tests inside a feature should use different names for the corresponding locals.
+
+===Runtime/code generation issues===
+* Non-conforming inheritance dynamic conformance only works with Classic compilations, for .Net non-conforming inheritance has no effect on code generation
+* Implemented time accounting on Windows.
+
+===Store/Retrieve issues===
+* Fixed a potential dead lock when an exception occurs while retrieving an object in a multithreaded environment (See test#store012).
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki
new file mode 100644
index 00000000..9587dde7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki
@@ -0,0 +1,52 @@
+[[Property:title|Major changes between ISE Eiffel 6.1 and ISE Eiffel 6.2]]
+[[Property:link_title|6.2]]
+[[Property:weight|-9]]
+==What's new==
+
+{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
+* Exceptions as objects are now implemented.
+* Added support for new ~ operator which can compare 2 objects safely regardless of their type.
+* Added detection of harmful catcall at runtime (harmless ones are currently ignored).
+* Added support for `note' keyword with a migration path in case `note' is being used as an identifier in your code.
+* Added `-gc_stats' option to get some information on how much CPU time is spent in GC during an Eiffel compilation.
+* Introduced several new much more powerful CAPs that now can be applied not only to read-only entities, but also to local variables (including Result), and can take into account execution paths as well as some obvious void-safe patterns.
+
+==Improvements==
+* Improved speed of compiler by a significant factor for large system.
+* Generated code is about 3-4% faster with a size reduction of about 2-3%.
+* Improved number of dynamic to static bindings in finalized code. Improved quality of inlined code for reducing even more of the dynamic calls.
+* Reduced the size of the AST stored in memory during a compilation by 20/25% which results in a memory usage reduction for EiffelStudio of about 15%. For example when compiling EiffelStudio on Windows 64-bit, it was taking 920MB with the previous version, and now it would be 800MB.
+* Fixed performance issue with {SPECIAL}.clear_all when handling a special of reference.
+* Removed VUOT(2) that required that the type of an object test local is attached.
+
+==Changes==
+* Protected several calls to `eif_wean' on the same EIF_OBJECT. This will prevent a memory corruption for people using it incorrectly with a minor slow down since in a typical application there should not be too many protected objects.
+* Removed VFAV(4) validity error that is no longer specified in the standard.
+* Due to new meaning of ~, the old syntax for agents is not being supported anymore. If you still have some code using the old agent syntax, compile it with 6.1 with syntax warning enabled to fix your code before upgrading to 6.2.
+
+==Bug fixes==
+
+===Language issues===
+* Fixed various limitations with support of attached types in 6.1, including support for
+** attachment marks for tuple types and formal generics
+** object tests in class invariants
+
+
+===Compiler issues===
+* Fixed eweasel test#final046 by avoiding useless creation of temporary objects during dynamic dispatch. It can also dramatically speed up certain kinds of code; on the compiler itself, the speed up is about 8-10%. In the worst case scenario it is 400% or more. Note this bug was introduced in version 6.0. Compared to 5.7, in 6.2 the worst case scenario is still about 10% slower.
+* Fixed an incorrect code generation for `is_equal' in ANY when exception trace is off which could cause a memory corruption.
+* Fixed various issues with compiler when inlining is enabled.
+* Fixed compiler crash when compiling a class where a type used in a signature of a feature has the wrong number of generic parameters. Fixed eweasel test#incr285.
+* Fixed an incorrect code generation for the dynamic binding of routines defined in generic classes and attribute access in general. Fixed eweasel test#exec272 and test#final039.
+* Fixed eweasel test#melt081 where having a redefined routine involving an anchor to a non-existing feature would crash the compiler instead of reporting a VEEN error.
+* Various bug fixes with respect of handling of expanded generic classes used in generic classes.
+
+===Runtime/code generation issues===
+* Changed the usage of `eif_adopt', `eif_protect', `eif_wean', `eif_freeze' and `eif_unfreeze' so that they can be used in concurrent thread, meaning that it is safe to use them as long as the argument is different in various threads.
+
+===Store/Retrieve issues===
+* Fixed some issues with the storing or retrieving of generic expanded types.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki
new file mode 100644
index 00000000..a0b16bcf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Compiler History]]
+[[Property:weight|-8]]
+* [[Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1|Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1]]
+* [[Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0|Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0]]
+* [[Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7|Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7]]
+* [[Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6|Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6]]
+* [[Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5|Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5]]
+* [[Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4|Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4]]
+* [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3]]
+* [[Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2|Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2]]
+* [[Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1|Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1]]
+* [[Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0|Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki
new file mode 100644
index 00000000..0c0120d1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki
@@ -0,0 +1,85 @@
+[[Property:title|Differences between ETL 2nd printing and Eiffel Software implementation]]
+[[Property:link_title|]]
+[[Property:weight|-9]]
+{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
+
+==Added classes==
+* New basic classes have been added: INTEGER_8, INTEGER_16, INTEGER_64 and WIDE_CHARACTER. INTEGER is now specified as having a 32 bits representation
+* New TUPLE, ROUTINE, PROCEDURE and FUNCTION classes required by the agent mechanism.
+
+==Added keywords==
+* Precursor
+* reference: new keyword to specify that a type is used as a reference type.
+* agent: new keyword used by the agent mechanism.
+* create: Instead of using the famous exclamation mark to create an instance of a class, you can use the keyword create. Below you will find a correspondence table between the old and the new syntaxes. The old syntax is still valid, but at some points Eiffel Software will remove it from its implementation:
+{|
+|-
+| Old syntax
+| New syntax
+|-
+| !! a
+| create a
+|-
+| !! a.make
+| create a.make
+|-
+| !B! a
+| create {B} a
+|-
+| !B! a.make
+| create {B} a.make
+|}
+
+
+==Added semantics==
+* [[7 Genericity and Arrays|Generic creation]]
+* Expression creation: you can now create an object within an expression. For example, you want to create an object and pass it as an argument to a function. Whereas you had to create a local variable, create the object and pass it to the function, you now simply need to pass to the function the creation expression. Here is a small example:
+{|
+|-
+| Old method
+| New method
+|-
+|
+
+local
+ a: STRING
+do
+ !! a.make (10)
+ f (a)
+end
+
+
+|
+
+do
+ f (create {STRING}.make (10))
+end
+
+
+|}
+This is also very useful since it can improve the power of assertions.
+* Mutually recursive constraints: one can now write class A [H, G->H] or class B [H -> C, G -> ARRAY [H]]. As a result, the declaration A [D, E] is valid only if E is a descendant of D. Similarly, the declaration B [E, ARRAY [D]] is not valid, if E is a descendant of D.
+* [[10 Other Mechanisms|Tuples]]
+* [[11 Agents|Agents]]
+* Feature access:
+
+local
+ value: INTEGER
+do
+ value := {MY_CLASS}.value
+end
+
+
+The previous call is valid, if and only if:
+** value is a feature representing a constant of a basic type (INTEGER, DOUBLE or CHARACTER)
+** value is a C/C++/DLL external feature
+** value is an IL static external feature
+
+
+==Added external support==
+
+Look at the page for [[C externals|C]] and [[C++ Externals|C++]] with the introduction of `struct' and C++ external features encapsulation.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki
new file mode 100644
index 00000000..6fb9dd4e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki
@@ -0,0 +1,337 @@
+[[Property:title|Differences between standard ECMA-367 and Eiffel Software implementation]]
+[[Property:weight|-10]]
+==Kernel classes==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Fictitious class for tuples
+| TUPLE
+| No
+| Yes
+| Yes
+|}
+
+==Features==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Prefix and infix feature names
+| infix "+"
+| Yes
+| No
+| Yes
+|-
+| Operator and bracket aliases
+| add alias "+"
+| No
+| Yes
+| Yes, except for new rules for free operator names
+|-
+| Assigner command
+| item alias "[]" (index: INTEGER): G assign put
+| No
+| Yes
+| Yes
+|}
+
+==Genericity==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Mutually recursive constraints
+| A [H, G -> H]
+B [H -> C, G -> ARRAY [H]]
+| No
+| Yes
+| Yes
+|-
+| Full mutually recursive constraints
+| A [H -> G, G -> H]
+
+| No
+| Yes
+| Yes
+|-
+| Expandedness restriction on formal generic
+| A [reference G]
+B [expanded H]
+| No
+| No
+| Yes
+|}
+
+==Creating objects==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Implicit creation procedure (version of ANY.default_create)
+| class A feature ... end
+-- The following instructions are equivalent:
+create {A} a
+create {A} a.default_create
+| No
+| Yes
+| Yes
+|-
+| Bang-bang syntax
+| !! a
+!! a.make
+!B! a
+!B! a.make
+| Yes
+| No
+| Yes, marked as obsolete
+|-
+| Keyword syntax
+| create a
+create a.make
+create {B} a
+create {B} a.make
+| No
+| Yes
+| Yes
+|-
+| Creation expression
+| print (create {TIME}.make_now)
+| No
+| Yes
+| Yes
+|-
+| [[7 Genericity and Arrays|Generic creation]]
+| create {G} x.make
+| No
+| Yes
+| Yes
+|}
+
+==Attachment==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Preserving expandedness status when attaching expanded object to reference entity
+| x := y
+| No, object is copied to new object of the corresponding reference type
+| Yes
+| Yes, except for TYPED_POINTER that is converted to POINTER before reattachment
+|-
+| Reverse assignment
+| x ?= y
+| Yes
+| No
+| Yes
+|}
+
+==Feature calls==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Precursor call
+| Precursor
+| No
+| Yes
+| Yes
+|-
+| Non-object call
+| c := {COLOR}.green
+| No
+| Yes
+| Yes
+|-
+| Assigner call
+| x [i] := x [i] + 1
+| No
+| Yes
+| Yes
+|-
+| Bracket expression as call target
+| x [i].update
+| No
+| No
+| Yes
+|}
+
+==Void safety==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Attachment marks
+| a: !ANY
+b: ?ANY
+| No
+| Yes, attached by default
+| Yes, default attachment status is controlled by option ''is_attached_by_default''
+|-
+| Object test
+| {o: !STRING} e
+| No
+| Yes
+| Yes, all object tests should use different names for locals inside a feature, object tests are not permitted in preconditions and check instructions
+|-
+| Attached target of a call
+| x.f
+| No
+| Yes
+| Yes, by option ''is_void_safe''
+|-
+| Properly set variable
+| x := value
+use (x)
+| No
+| Yes
+| Yes, by option ''is_void_safe''
+|}
+
+==Expressions==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Bracket expression
+| y := x [i]
+| No
+| Yes
+| Yes
+|-
+| Creation expression
+| set_buffer (create {STRING}.make (100))
+| No
+| Yes
+| Yes
+|-
+| Manifest type
+| {MY_TYPE}
+| No
+| Yes
+| Yes
+|-
+| Manifest [[10 Other Mechanisms|tuple]]
+| [a, b, c]
+| No
+| Yes
+| Yes
+|-
+| [[11 Agents|Agent]]
+| list.do_all (agent print (?))
+| No
+| Yes
+| Yes
+|-
+| Once manifest string
+| once "abc"
+| No
+| Yes
+| Yes
+|}
+
+==Constants==
+{|
+|-
+| '''Feature'''
+| '''Example'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Verbatim string
+|
+x := "[
+ This string is left-adjusted.
+]"
+y := "{
+ This string is used "as is".
+}"
+
+| No
+| Yes
+| Yes
+|-
+| Manifest type qualifier
+| {INTEGER_8} 123
+| No
+| Yes
+| Yes
+|-
+| Non-decimal integer
+| 0xFF
+| No
+| Yes
+| Hexadecimal integers
+|-
+| Integer with intermediate underscores
+| 1_000 0xFFFF_0000
+| In groups by 3 digits
+| Yes
+| Yes
+|}
+
+==Interfacing with external software==
+{|
+|-
+| '''Feature'''
+| '''ETL2'''
+| '''ECMA-367'''
+| '''EiffelStudio'''
+|-
+| Access to software written in C
+| Basic syntax for any external software
+| Registered sub-language
+| See details for [[C externals|C externals]]
+|-
+| Access to software written in C++
+| Basic syntax for any external software
+| Registered sub-language
+| See details for [[C++ Externals|C++ externals]]
+|-
+| Access to dynamically loaded libraries (DLLs)
+| Basic syntax for any external software
+| Registered sub-language
+| No
+|-
+| Other external software
+| Basic syntax for any external software
+| Unregistered sub-language
+| No
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki
new file mode 100644
index 00000000..315e3894
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki
@@ -0,0 +1,68 @@
+[[Property:title|Definition file]]
+[[Property:weight|2]]
+The syntax is pretty simple when you understand what you need to export a feature: you need the name of the '''feature''', the name of the concerned '''class''', and the name of a '''creation procedure'''. What is optional is to specify an '''alias''', an '''index''' and a '''calling convention'''. The index and calling convention are mainly used to create a DLL for windows, and the alias to export the feature under a different name.
+
+===Syntax===
+
+{|
+|-
+| '''Export_feature'''
+| Class_name [Creation_part] ":" Feature [Optional_part]
+|-
+| '''Creation_part'''
+| "(" feature_name ")"
+|-
+| '''Optional_part'''
+| [Index_part] [Alias_part]
+|-
+| '''Index_part'''
+| "@" integer
+|-
+| '''Alias_part'''
+| "Alias" alias_name
+|-
+| '''Call_type_part'''
+| "call_type" call_type_name
+|}
+
+
+===Example===
+
+ROOT_CLASS (make): foo @ 4 Alias my_foo call_type __stdcall
+
+
+===Constraint===
+
+* on the class:
The class cannot be deferred or generic.
+* on the feature:
It could be any feature except an attribute, an external feature or a deferred feature.
+* on the creation procedure:
It must have zero argument, and no return type.
+* on the alias name:
It must be a valid name for a C function.
+* on the index:
It must be strictly positive.
+* on the call type:
It must be a valid call type for the targeted platform (useful for Windows only). For Visual C++, the valid calling conventions are __stdcall, __cdecl and __fastcall.
+
+For each feature the required fields are the '''class''', the '''creation procedure''', and of course the '''feature''' itself.
+* If the feature is a creation procedure then do not specify any creation, it will use the feature as creation. For example '''ROOT_CLASS: make'''.
+* If the class has no creation procedure, do not specify any creation. default_create will be automatically used.
+
+===A definition file===
+
+
+-- EXPORTED FEATURE(s) OF THE SHARED LIBRARY
+-- SYSTEM : demo
+
+-- CLASS [BAR]
+-- Here get_string uses make_b as creation
+BAR (make_b) : get_string
+-- Here print_bar uses make_a as creation
+BAR (make_a) : print_bar
+
+-- CLASS [ROOT_CLASS]
+-- Here the feature is also a creation
+ROOT_CLASS : make
+ROOT_CLASS (make) : foo
+ROOT_CLASS (make) : test_bar
+
+
+* EIFGENs/target_name/W_code/'''system.def''' (or F_code)
+* EIFGENs/target_name/W_code/'''edynlib.c''' (or F_code)
+* $(ISE_EIFFEL)/studio/spec/$(ISE_PLATFORM)/templates/'''egc_dynlib.template'''
+this file will be copied during the compilation into the EIFGENs/target_name/W_code/E1 directory as '''egc_dynlib.c'''
+* $(ISE_EIFFEL)/studio/spec/$(ISE_PLATFORM)/include/'''egc_dynlib.h'''
+* and the Makefile
+
+The ''system.def'' is only used on windows, it is the definition file used to generate a DLL when linking.
+Information about the DLL
+LIBRARY demo.dll
+DESCRIPTION DEMO.DLL
+The following are EXPORTed functions.
+EXPORTS
+This part concerns the run-time. It initializes the run-time and reclaim Eiffel objects.
+
+;System
+ init_rt
+ reclaim_rt
+
+The exported for the BAR class:
+; CLASS [BAR]
+ get_string
+ print_bar
+
+The exported for the ROOT_CLASS class:
+; CLASS [ROOT_CLASS]
+ make
+ foo
+ test_bar
+
+
+The ''edynlib.c'' file is the interface between the Eiffel system and the C code. It contains the declaration and the implementation of the function used to directly call the eiffel feature with its real name.
+
+The ''egc_dynlib.c'' and ''egc_dynlib.h'' files are used for operations performed by the run-time.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki
new file mode 100644
index 00000000..5176a5c9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Dynamic library generation]]
+[[Property:weight|-12]]
+* [[Dynamic library generation: Introduction|Introduction]]
+* [[Dynamic library builder|Dynamic library builder]]
+* [[Definition file|Definition file]]
+* [[Dynamic library: Generated files|Generated files]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/index.wiki
new file mode 100644
index 00000000..23c303f2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Compiler]]
+[[Property:weight|-9]]
+* [[Compiler: introduction|Introduction]]
+* [[Differences between ETL 2nd printing and Eiffel Software implementation|Differences between ETL 2nd printing and Eiffel Software implementation]]
+* [[Command line|Command line compiler]]
+* [[External features|External features]]
+* [[Dynamic library generation|Dynamic library generation]]
+* [[Melting Ice Technology|Melting Ice Technology]]
+* [[Supported C compilers|Supported C compilers]]
+* [[Compiler History|Version History]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki
new file mode 100644
index 00000000..6e618c7a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Melting Ice Technology]]
+[[Property:weight|-15]]
+EiffelStudio relies on Melting Ice Technology, the proprietary compilation mechanism of Eiffel Software, which offers three forms of compilation:
+* ''melting'' for making a few changes. The fastest of the mechanisms, typically taking a few seconds after small changes. Melting time is proportional to the size of the changed parts and affected classes, while the time needed to freeze or finalize is partly proportional to the size of the whole system. As long as you do not include new external C/C++ code, a C/C++ compiler is not required. However, execution speed is not optimal. The generated executable is debuggable.
+* ''freezing'' generates C code from the active system, and then compiles it into machine code; you must have a C/C++ compiler installed. You need to use this option if you add new agents or external C/C++ calls. Unless you add external code, you can re-freeze every couple of days. The rest of the time, you can melt your software to receive immediate feedback. The speed is still slower than when finalizing, but the generated executable is still debuggable.
+* ''finalizing'' delivers a production version (intermediate or final) of your software. It can be used to measure its performance in operational conditions. Finalization performs extensive time and space optimizations that enable Eiffel to match the efficiency of C/C++; it also creates a stand-alone C package that you can use for cross-platform development. Because of all the optimizations involved, finalizing takes the most time, and the generated executable is not debuggable.
+
+Melting and freezing generate an executable in the EIFGENs|target_name|W_code subdirectory of the project directory. The executable is composed of a standard executable file named after the system, and of a < ''system name''>.melted file, which is called the Eiffel update file. Although it is recommended to finalize the system when running it from outside EiffelStudio (since the performance is better), it is possible to launch a melted/frozen executable. However, the Eiffel update file is necessary, the executable alone will not run.
+
+Basically, the Eiffel update file incorporates the changes that have been made to the system since it was last frozen. Therefore, it is very small when the system has just been frozen, and progressively becomes bigger each time the system is melted. On the contrary, the executable is only modified when the system is frozen, never when it is melted.
+
+The contents of the Eiffel update file are in a byte code representation which is dynamically interpreted at run-time.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki
new file mode 100644
index 00000000..ba1cee02
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Supported C compilers]]
+[[Property:weight|-14]]
+==Unix/Linux Users:==
+
+EiffelStudio supports `gcc' on most platforms and the native`cc' compiler if it is an ANSI C compiler.
+
+
+
+==Microsoft Visual C++ Users==
+
+EiffelStudio supports only version 6.0 and higher of the Microsoft Visual C++ environment. You can still use older versions of the Microsoft C++ environment (version 4.1, 4.2 or 5.0) as long as you have the latest Platform SDK from Microsoft, but this won't be supported by Eiffel Software.
+
+Normally it will automatically detect the location of the C compiler. In case it wouldn't, make sure that the Microsoft tools are correctly setup to run from the MS-DOS prompt. To do that you need to set the environment variable PATH, LIB and INCLUDE to the value specified in the file`vcvars32.bat' from the `bin' directory of the VC installation.
+
+==Borland C++ Users:==
+
+EiffelStudio only supports version 5.5.1 of Borland C++ which is included in the installation of EiffelStudio. We do not support any other versions.
+
+By default the installation program will set in the registry keys the ISE_C_COMPILER key to `bcb'.
+
+
+
+==Changing your C compiler on Windows==
+
+You can do it in two different ways. The first one is using the registry keys of the Windows
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/console-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/console-tool.wiki
new file mode 100644
index 00000000..fecd32e2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/console-tool.wiki
@@ -0,0 +1,69 @@
+[[Property:title|Console tool]]
+[[Property:weight|-4]]
+The Console tool lets you run external commands from within EiffelStudio. The Console tool is shown in the following figure:
+[[Image:console1|Defining an input domain]]
+
+You can type your command in the "Command" region and then press the [[Image:metrics-tool--debug-run-icon|Launch Command]] Run button to launch that command. When a command is running, you can type input data to that command in the "Input" region if necessary. And you can press the [[Image:metrics-tool--debug-stop-icon|Stop Command]] Stop button to terminate a running command. If the command uses a different locale from your default locale, you can specify the desired locale in the "Locale" region where all supported locales are listed. The selected locale will be used for both the input and output of the command. After the command has exited, its return value will be displayed at the bottom line.
+
+==Placeholders==
+
+In the "Command" region, the following placeholders can be used:
+* $class_name: this will be replaced by the name in lower case of the targeted class in editor
+* $directory_name: this will be replaced by the directory location of the targeted class in editor
+* $file: this will be replaced by file name part, i.e., without heading directory, of $path of the targeted class in editor
+* $file_name: this will be replaced by the path to the targeted class in editor
+* $f_code: this will be replaced by the F_code directory of current target, if defined
+* $group_directory: this will be replaced by the directory of the group where targeted class in editor locates
+* $group_name: this will be replaced by the group name of the targeted class in editor
+* $line: this will be replaced by the line number of the cursor of the targeted class in editor
+* $path: same as $file_name
+* $project_directory: this will be replaced by the directory of current project, if defined
+* $target_directory: this will be replaced by the directory of current target, if defined
+* $target_name: this will be replaced by current target name
+* $w_code: this will be replaced by the W_code directory of current target, if defined
+
+==Buffer support==
+
+Buffer is a way to refer to text of a class, a feature or text/selected text in an editor tab in external command. Three kinds of buffers are supported:
+* {SOME_CLASS} represents text of SOME_CLASS
+* @{SOME_CLASS} represents selected text in the opened editor tab for class SOME_CLASS
+* {SOME_CLASS}.some_feature represents text of some_feature from SOME_CLASS
+
+For example, if you run the command:
+{{note| gvim {ANY} }}
+The text of class ANY will be displayed in a gvim window.
+
+If you run the command:
+{{note| gvim @{ANY} }}
+And if class ANY is opened in an editor tab and some text is selected there, the selected text will be displayed in a gvim window.
+
+If you run the command:
+{{note| gvim @{ANY}.is_equal }}
+The text of feature is_equal from class ANY will be displayed in a gvim window.
+
+If you run the command:
+{{note| gvim -d {ANY}.is_equal {APPLICATION}.is_equal }}
+A gvim windows in diff mode will be opened showing the difference between ANY.is_equal and APPLICATION.is_equal.
+
+The text used in buffer is stored in a temporary file so whatever change done to that text won't affect the text used in EiffelStudio.
+
+==Auto-completion==
+
+The command area supports auto-completion. You can auto-complete placeholder, class name and feature name, shown in the following pictures:
+
+Auto-complete placeholder: [[Image:console-auto1|Auto-complete placeholder]]
+
+Auto-complete class name: [[Image:console-auto2|Auto-complete class name]]
+
+Auto-complete feature name: [[Image:console-auto3|Auto-complete feature name]]
+
+==Pick and drop==
+
+You can also pick and drop a group/class/feature into the command area to have related name/path inserted.
+
+{{seealso| '''See Also'''
+[[External commands editor dialog|External commands Editor dialog]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-commands.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-commands.wiki
new file mode 100644
index 00000000..f89b10eb
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-commands.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Breakpoint commands]]
+[[Property:weight|2]]
+Located in the '''debug''' menu and the '''project''' toolbar, these three commands allow to change the state of set [[Breakpoints: Introduction|breakpoints]] in the system.
+
+Enable breakpoints ( [[Image:16x16--breakpoints-enable-icon]] ), disable breakpoints ( [[Image:16x16--breakpoints-disable-icon]] ) and remove breakpoints ( [[Image:breakpoints-delete-icon]] ) have all global and local actions. Left-clicking on them has a global action: all set breakpoints of the system will be respectively enabled, disabled, or discarded. However, it is also possible to [[Pick-and-drop mechanism|drop]] a feature or a class onto them, in which case only set breakpoints of the feature/class will be affected.
+
+Note that these commands work only on set breakpoints (that is, enabled or disabled breakpoints). Therefore, discarded breakpoints cannot be set again thanks to these commands.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-editing.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-editing.wiki
new file mode 100644
index 00000000..7dea6d4e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-editing.wiki
@@ -0,0 +1,62 @@
+[[Property:title|Breakpoint editing]]
+[[Property:weight|1]]
+In all flat views ( [[Feature formatters: Flat view|feature flat view]] and [[Class formatters: Flat view|class flat view]] ), a margin is displayed on the left of the editor. [[Breakpoints: Introduction|Breakpoints]] are there symbolized as circles, of a different appearance depending on their state: enabled ( [[Image:bp-enabled-icon]] ), disabled ( [[Image:bp-disabled-icon]] ) or not set ( [[Image:bp-slot-icon]] ). A small question mark in the circle ( [[Image:bp-enabled-conditional-icon]] , [[Image:bp-disabled-conditional-icon]] )indicates [[Breakpoint menu|conditional breakpoints]] .
+
+Right-clicking on any breakpoint pops up a context menu:
+
+ [[Image:breakpoint-context-menu]]
+
+The first line provides the breakpoint slot index of the selected breakpoint(i.e: the one used in call stack or exception trace output).
+Clicking one of the three first entries of the context menu changes the state of the breakpoint that was right-clicked. The last entry ( '''Run to breakpoint''') launches the debugged application so that it will stop as soon as the selected breakpoint is encountered, as if the breakpoint had been enabled.
+
+
+"Edit This Breakpoint" allows the user to edit the parameters of the breakpoint (condition, hit count, when hits actions...) thanks to the breakpoint dialog. This dialog provides on hte first tab "Context": access to the associated tags, condition, and hit count control. And on the second tab, it allows to associate "When hits..." action(s) to the breakpoint.
+
+{|
+|-
+|
+Context's tab
+ [[Image:breakpoint-dialog-context|Context's tab]]
+|
+When hits action 's tab
+ [[Image:breakpoint-dialog-when-hits-action|When hits... 's tab]]
+|}
+
+
+* The tags allow to identified a collection of breakpoints, either from the [[Breakpoint information command|breakpoints tool]] , or even in the parameters of "When hits .." actions.
+Note that any existing breakpoint can be referenced by an implicit tag with ''"'''bp:'''cluster.{CLASS}.feature@index"'' (cluster is not mandatory).
+
+{{sample|For instance "'''bp:'''elks.{LINKED_LIST}.extend@2"}}
+
+* the "Condition" allows the user to set a condition for stopping.
+* the "Hit count" allows the user to set a condition on hitcount for stopping.
+* And the "When Hits..." allows to associate specific actions to the breakpoint:
+** Print message: display the expanded message to the output (there are predefined variables, and you can also evaluate expressions).
+** Disable/Restore Assertion Checking: this might be useful to desactivate assertion checking on a specific part of the execution.
+** Record Execution: start or stop the execution recording (cf: [[Execution record and replay|Execution recording and replay]] )
+** Enable/Disable Breakpoints: either use tags or implicit tags (ex: ''"bp:elks.{LINKED_LIST}.extend@2"''), to reference a set of existing breakpoints. This can be pretty useful to enable a breakpoint only if the execution takes a specific execution path.
+** Reset Hits count
+
+
+
+
+"Edit Condition" allows the user to set a condition for stopping, it opens the same dialog as "EditThis Breakpoint", but focus on the "condition" field.
+
+ [[Image:breakpoint-dialog-condition]]
+
+"Hit count" allows the user to set a condition on hitcount for stopping
+
+ [[Image:breakpoint-dialog-hit-count]]
+
+"When hits ..." allows the user to do an action when we actually stopped on this breakpoint. This can be for instance `print message'.
+
+ [[Image:breakpoint-dialog-when-hits]]
+
+{{seealso| '''See Also'''
+[[Breakpoint commands|Breakpoint commands]]
+[[Breakpoint information command|Breakpoint information command]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-information-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-information-command.wiki
new file mode 100644
index 00000000..7f6ddd78
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-information-command.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Breakpoint information command]]
+[[Property:weight|3]]
+The breakpoint information command, located in the '''debug''' menu and in the '''project''' toolbar ( [[Image:tool-breakpoints-icon]] ), displays the list of all set breakpoints in the system (enabled or disabled).
+
+Display all breakpoints in a grid
+ [[Image:breakpoints-list]]
+
+Note: the * shows that the breakpoint has a [[Breakpoint menu|condition]] .
+Note: you can edit the selected breakpoint by double clicking on it, or pressing [enter] which show the menu.
+Note: you can disable/enable the selected breakpoint(s) by pressing [space].
+Note: you can sort by clicking the column, especially the first column which provide tree, flat or sorted view.
+
+Display all breakpoints in a list
+ [[Image:breakpoints-list-flat]]
+
+Display all breakpoints in a list filtered by a tag using button [[Image:breakpoints-list-filter-button]]
+ [[Image:breakpoints-list-filter]]
+
+{{seealso| '''See Also'''
+[[Breakpoint commands|Breakpoints commands]]
+[[Breakpoint information command|Breakpoint information command]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-menu.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-menu.wiki
new file mode 100644
index 00000000..291c6ff0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-menu.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Breakpoint menu]]
+[[Property:weight|4]]
+A condition breakpoint is a breakpoint in which debugger will stop if a certain condition is met. To set a conditional breakpoint use the [[Breakpoint editing|breakpoint menu]] and choose `Set conditional breakpoint':
+
+[[Image:breakpoint-context-menu]]
+
+Once done a dialog pops up where you can enter a condition:
+
+[[Image:breakpoint-dialog-condition]]
+
+The condition is a Boolean expression that follows the same rule as the expression you can enter in the [[Expression evaluation|expression evaluation tool]] .
+
+
+{{warning|'''Caution''': if you enter an expression that is not supported or which raises an error during evaluation, by default the condition is considered as True (then the debugger will stop) }}
+
+{{seealso| '''See Also'''
+[[Breakpoint editing|Breakpoint menu]]
+[[Breakpoint commands|Breakpoints commands]]
+[[Breakpoint information command|Breakpoint information command]]
+[[Expression evaluation|Expression evaluation tool]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/index.wiki
new file mode 100644
index 00000000..ab433c77
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Breakpoints]]
+[[Property:weight|-14]]
+* [[Breakpoints: Introduction|Introduction]]
+* [[Breakpoint editing|Breakpoint menu]]
+* [[Image:16x16--breakpoints-enable-icon]] [[Image:16x16--breakpoints-disable-icon]] [[Image:breakpoints-delete-icon]] [[Breakpoint commands|Breakpoint commands]]
+* [[Image:tool-breakpoints-icon]] [[Breakpoint information command|Breakpoint information command]]
+* [[Breakpoint menu|Conditional breakpoints]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/call-stack-tool-interface.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/call-stack-tool-interface.wiki
new file mode 100644
index 00000000..b00fb303
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/call-stack-tool-interface.wiki
@@ -0,0 +1,27 @@
+[[Property:title|Call stack tool: Interface]]
+[[Property:weight|1]]
+[[Image:call-stack-tool]]
+
+The call stack tool gives information about the current call stack of a debugged application.
+
+It is mainly composed of a list representing the call stack elements, where the entry feature of the program is at the bottom and the top of the call stack is at the top.
+- The current call stack element, to which the [[Information relative to a stack element|other debug tools]] refer, is represented by a green arrow [[Image:callstack-active-arrow-icon]] .
+- Clicking on a call stack element represented by an empty arrow [[Image:callstack-empty-arrow-icon]] , or picking it and dropping it onto either the call stack list or the locals view defines it as being the current call stack element.
+- The call stack elements with no pixmap are called external call stack elements, they represent a call stack out of Eiffel, for instance a true dotnet call stack.
+- For each feature in the call stack, its name, its dynamic class and its static class are displayed. An asterisk next to the name of a feature means the feature is melted, as opposed to frozen. The dynamic class is the type of the object upon which the feature is called, whereas the static class is the class in which the feature was written.
+
+On top of this list, a line gives the state of the debugged application, and another one describes the exception that caused the application to stop, if any. For more information concerning exceptions, see the [[Supported exceptions|supported exceptions]] .
+The button [[Image:debug-exception-dialog-icon]] is used to open the Exception dialog which show the exception details. For instance a call on Void target in a dotnet system would popup :
+
+ [[Image:exception-dialog]]
+
+When more than one thread is available to the debugger, you can switch from one to the other, for that you have to click on the thread's id "0x000..." and select from the popup list of available threads. Or (recommended) you can use the [[Threads tool|threads tool]] (clicking on '''Show threads panel''' will show the threads tool).
+ [[Image:call-stack-tool-with-threads]]
+
+
+In the toolbar, the button [[Image:general-save-icon]] gives the possibility to [[Save call stack|save the call stack]] to a text file, and the button [[Image:general-copy-icon]] copy to the clipboard. The [[Image:debugger-callstack-depth-icon]] button makes it possible to choose which call stack depth should be displayed in the list (the default is to display the 100 top stack elements, but it is configurable with the same button).
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/index.wiki
new file mode 100644
index 00000000..96ee6728
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Call stack tool]]
+[[Property:weight|-13]]
+* [[Callstack tool: Introduction|Introduction]]
+* [[Call stack tool: Interface|Call stack tool]]
+* [[Information relative to a stack element|Information about the current stack level]]
+* [[Supported exceptions|Supported exceptions]]
+* [[Save call stack|Save call stack command]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/information-relative-stack-element.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/information-relative-stack-element.wiki
new file mode 100644
index 00000000..a8a403a8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/information-relative-stack-element.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Information relative to a stack element]]
+[[Property:weight|2]]
+In addition to the [[Call stack tool: Interface|call stack tool]] that provides information concerning the call stack in its globality, some other debug tools give information concerning the [[Call stack tool: Interface|current call stack element]] .
+
+In debug mode, the context tool is automatically switched to the feature tab in flat view, and displays the feature which corresponds to the current call stack element. In the left margin, a yellow arrow ( [[Image:bp-current-line-icon]] ) marks the execution line where the program is currently stopped, whereas a green arrow ( [[Image:bp-slot-other-frame-icon]] ) indicates the execution line that was attained in the feature in the current call stack element. Therefore, if a feature is recursive, and appears several times in the call stack, changing the current call stack element may cause green arrows to be displayed at different places in the same feature (if the different calls did not reach the same execution point). On the other hand, the yellow arrow can only appear at one place as long as the application is not started again.
+
+The left part of the [[Objects tool: Introduction|object tool]] gives valuable information concerning parameters that were passed to the feature corresponding to the current call stack, the current value of the local variables, and, if it is a function, the current value of its result.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/save-call-stack.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/save-call-stack.wiki
new file mode 100644
index 00000000..2cfd44e2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/save-call-stack.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Save call stack]]
+[[Property:weight|4]]
+It is possible to copy the current call stack to the clipboard ( [[Image:general-copy-icon]] ) or to a text file ( [[Image:general-save-icon]] ). This may be useful to indicate to other people of a team where an error occurred. After the button is clicked, a dialog is popped up that prompts for a place where to save the [[Call stack tool: Interface|call stack]] (if the selected file already exists, it is overwritten).
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/supported-exceptions.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/supported-exceptions.wiki
new file mode 100644
index 00000000..38ede1a1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/supported-exceptions.wiki
@@ -0,0 +1,47 @@
+[[Property:title|Supported exceptions]]
+[[Property:weight|3]]
+Here is a list of exceptions that may appear in the [[Call stack tool: Interface|call stack tool]] . When they are raised, a tag may be there to give more information, if necessary. All these exceptions are declared in EXCEPT_CONST.
+
+'''Feature call on Void target''': An attempt was made to calla feature on an object that is Void. The tag indicates the name of the feature of the feature that could not be called. For instance if the code line is a.b.c and the tag is "c" then a.b was Void.
+
+'''No more memory''': A memory allocation failed.
+
+'''Precondition violated''': One of the conditions necessary prior to entering a feature is not verified. This may indicate either that the precondition is too strong, or that the call is invalid. The tag should give the name of the violated precondition, if any.
+
+'''Postcondition violated''': One of the conditions checked when a feature exits is not verified. This may indicate either that the postcondition is too strong, or that the feature did not behave correctly. The tag should give the name of the violated postcondition, if any.
+
+'''Class invariant violated''': One of the conditions that checks the validity of objects is not verified. This may indicate that an object was left in an invalid state after a method call. The tag should give the name of the violated invariant, if any.
+
+'''Assertion violated''': An assertion was not verified. The tag should give the name of the violated assertion, if any.
+
+'''Non-decreasing loop variant''': A loop variant does not vary. This may lead to stack overflows or erroneous results.
+
+'''Loop invariant violated''': A condition that should be checked when executing a loop is not verified. The tag should give the name of the violated invariant.
+
+'''Floating point exception''' (signal SIGFPE): An error occurred while processing floating point numbers. This may be for example a FPU overflow, a division by zero, or an invalid operation.
+
+'''Unmatched inspect value''': An inspect clause couldn't find the value it was passed among the `when' clauses. If any value maybe passed to the `when' clause, adding an `else' clause will solve this problem.
+
+'''I/O error''': An error occurred while accessing a stream. Examples of this are a missing file, or insufficient rights.
+
+'''Retrieval error''': A file could not be retrieved. This maybe caused by an invalid header, or more generally by a corrupted data file.
+
+'''Developer exception''': Developer exceptions can be raised by calling {EXCEPTIONS}.raise. They can indicate any kind of internal error.
+
+'''Operating system signal''': The program received a signal from the operating system.
+
+'''Exception in rescue clause''': An exception occurred within a rescue clause.
+
+'''Void assigned to expanded''': An attempt was made to assign a Void value to an expanded object.
+
+'''Run-time I/O error''': Exception raised by the run-time when encountering a I/O error internally.
+
+'''External event''': On Unix, this happens when an operating system error occurs and does not set the `errno' variable.
+
+'''Operating system error''': On Unix, this happens when an operating system error occurs and sets the `errno' variable.
+
+'''COM error''': Raised when EiffelCOM encounters an error.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debuggees-object-storage.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debuggees-object-storage.wiki
new file mode 100644
index 00000000..54180f80
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debuggees-object-storage.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Debuggee's Object Storage]]
+[[Property:weight|-9]]
+This command can be accessed through the context menu, and from the objects tool, and watches tools thanks to the tool bar's button [ [[Image:execution-object-storage-icon]] ].
+
+By Pick-and-Dropping a debuggee object onto the button [ [[Image:execution-object-storage-icon]] ], you raise the "save" dialog. Then you need to choose the target filename where we'll store the debuggee object.
+
+ [[Image:debuggee-object-storage-save]]
+
+By clicking on a watch tool's button [ [[Image:execution-object-storage-icon]] ], you raise the "load" dialog. Then you need to select the filename which contain the debuggee object's storage. If the loading is successful, the retrieved object will be added in the related watch tool.
+
+
+ [[Image:debuggee-object-storage-load]]
+
+{{tip|By Pick-and-Dropping an object onto the button, you can load the retrieved values into the dropped object (make sure it has same type).}}
+
+{{warning|For now this command is pretty basic, and provided as it is. The underlying implementation is using {FILE}.independent_store and {FILE}.retrieved for save and load operation, to load the value into an existing object, it is using {ANY}.standard_copy (..). For details, you can have a look at the RT_EXTENSION_GENERAL code }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-limitations.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-limitations.wiki
new file mode 100644
index 00000000..42778d49
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-limitations.wiki
@@ -0,0 +1,21 @@
+[[Property:title|Debugging limitations]]
+[[Property:weight|-2]]
+General limitations:
+* Watch expression: Agents are not supported (for instance "agent my_function" is not supported").
+* The debugger is still not very helpful when the execution is stopped inside an invariant.
+
+Limitations or known bugs for the Classic debugger:
+* Evaluating Precursor will produce the current feature's Result (not the precursor)
+* If you use any of the previous non supported expressions in a breakpoint condition, since the evaluation is failing the condition will always return True. In such case the debugger will stop.
+
+Limitations or known bugs for the .Net debugger:
+* It happens the debugger does not show the correct executed line, especially when dealing with disabled assertions or disabled debug clauses.
+* The same trouble occurs when stepping through an unordered inspect code.
+
+Various known issues for classic system :
+* If a precondition is violated inside a rescue, the debugger reports the assertion violation will the exception's tag.
+* If you use the "Disable Assertion Handling" functionality when the execution is stopped in a rescue, the effect might be cancelled as soon as the execution exits the rescue's associated feature.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-preferences.wiki
new file mode 100644
index 00000000..e2492b3a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-preferences.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Debugging preferences]]
+[[Property:weight|-4]]
+Two main preferences are available for the debugger, in order to speed up the objects display :
+* Enable/disable the debug_output display (see [[Debug output|debug output]] )
+* Enable/disable the full generic type display (for instance see ARRAY [INTEGER] instead of only ARRAY
+* To avoid infinite evalution processing, the debugger abort evaluation after "max evaluation duration" timeout. So you can change this value to fit your needs.
+ [[Image:debugging-tools-preferences]]
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-tips-objects-grid-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-tips-objects-grid-view.wiki
new file mode 100644
index 00000000..c7df6074
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/debugging-tips-objects-grid-view.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Debugging tips with the objects grid view]]
+[[Property:weight|-5]]
+General behavior
+* Double clicking on the grid's header separator will resize the corresponding column. If you hold the [SHIFT] key at the same time, it will resize according to the displayed cells.
+* Right clicking on the header's cell will popup a menu that enable or disable the auto resizing on the selected column. This can be useful to resize automatically the "name" column when inspecting an object value.
+* Pressing [CONTROL] + [E] when the selected line represents a value with potential text representation (STRING, DEBUG_OUPUT ...) will open the [[Object Viewer (also known as Expanded display)|expanded view dialog]]
+
+Watch tools (alias evaluation tool)
+* Dropping an object value on a [[Evaluation tool or Watch tool|watch tool ]] will open the [[New expression dialog|expression definition dialog]] with the object's address filled. This way you can evalute expression directly on this object. If you press [Ctrl] during the dropping, the dropped object will be added as expression in the watch tool as itself.
+* You can also drop the object on the notebook tab of the wanted watch tool.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/exceptions-handling-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/exceptions-handling-tool.wiki
new file mode 100644
index 00000000..7ba9c2be
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/exceptions-handling-tool.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Exceptions handling tool]]
+[[Property:weight|-7]]
+This tool is used to precise whether the debugger stops or continues on specific exceptions.
+To show this tool, go to menu : '''Debug > Exception handling''' .
+Note: now that exception are object in Eiffel too, the mechanism is unified for classic and dotnet system using the Eiffel exception class names.
+
+==Exception handling dialog==
+
+If the "filter exceptions" is enabled, for each exception you can leave the exception action as '''Disabled''' (default behavior: catch), '''Catch''' (stop on such exception), '''Ignore''' (do not stop on such exception). By double clicking on the exception name you toggle Ignore/Catch.
+
+In the following picture, we stop on every exception except the "External Exception".
+
+ [[Image:exceptions-handling-tool|Exception handling tool]]
+
+{{tip|Using the "Pattern" field, you can add you own filter using regular expression.}}
+
+
+==Cat call detection during the execution==
+
+This dialog also provides a way to disable/enable the cat call warning on the console or in the debugger with the first two checkbox fields.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execute-one-line-time.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execute-one-line-time.wiki
new file mode 100644
index 00000000..94413a33
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execute-one-line-time.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Execute one line at a time]]
+[[Property:weight|-9]]
+If no application was already running, this command launches an application compiled in Work Bench mode and stops at its first line.
+
+If an application was stopped, it attempts to execute the instruction located on the execution line where the application is stopped. If this execution line does not contain an instruction, the execution stops at the next execution line.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-step-over-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]]
+[[Generating executables|Compiling in Workbench mode]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/index.wiki
new file mode 100644
index 00000000..6cdc0015
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Execution commands]]
+[[Property:weight|-15]]
+* [[Eiffel Debugger Execution: Introduction|Introduction]]
+* [[Image:debug-run-icon]] [[Run and stop at breakpoints|Run and debug]]
+* [[Image:debug-run-icon]] [[Run with arguments|Run with arguments]]
+* [[Image:debug-run-without-breakpoint-icon]] [[Run without breakpoints|Run regardless of breakpoints]]
+* [[Image:debug-run-finalized-icon]] [[Run a finalized executable|Run a finalized executable]]
+* [[Image:debug-step-into-icon]] [[Step into a feature|Step into a feature]]
+* [[Image:debug-step-over-icon]] [[Execute one line at a time|Execute an instruction line]]
+* [[Image:debug-step-out-icon]] [[Step out of a feature|Step out of a feature]]
+* [[Image:debug-pause-icon]] [[Pause an application|Pause the execution]]
+* [[Image:debug-stop-icon]] [[Stop a debugged application|Stop the debugged application]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/pause-application.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/pause-application.wiki
new file mode 100644
index 00000000..e1f599e8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/pause-application.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Pause an application]]
+[[Property:weight|-7]]
+This command stops the execution of a running debugged application.
+
+This gives access to dynamic information concerning the application, such as the current [[Callstack tool: Introduction|call stack]] and the [[Objects tool: Introduction|state of objects]] in the system.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-pause-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-and-stop-breakpoints.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-and-stop-breakpoints.wiki
new file mode 100644
index 00000000..eb5407e6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-and-stop-breakpoints.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Run and stop at breakpoints]]
+[[Property:weight|-15]]
+This command launches an application compiled in Work Bench mode. The application will stop as soon as a [[Breakpoints: Introduction|breakpoint]] is encountered, or when an exception occurs.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-run-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]]
+[[Generating executables|Compiling in Workbench mode]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-arguments.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-arguments.wiki
new file mode 100644
index 00000000..6d0e8ccf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-arguments.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Run with arguments]]
+[[Property:weight|-14]]
+While working on a project, you may want to launch it with one or more arguments.
+
+There are two ways to specify arguments for a program from EiffelStudio:
+* From the '''Debug, Debugging Options''' menu.
+* By right-clicking any of the buttons on the debugging toolbar.
+
+==Using the Argument Dialog==
+
+[[Image:argument-dialog]]
+
+
+
+The dialog allows you to manage different execution profiles to specify parameters to be passed to the system at execution time.
+
+Each profile allows to set a title, the '''arguments''', the '''working directory''', and you can also set your own '''environment variables'''.
+
+To use a profile, just select it by clicking the corresponding line in the grid..
+
+Once the appropriate execution profile is selected then the system can be run with those parameters using the Run button (If "Keep Dialog Open" is selected the dialog remains opened).
+To run without any particular parameter select '''default''' 's profile.
+
+If you click on "Run Workbench" or "Run Finalized", the system will be executed outside EiffelStudio (thus no debugging)..
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-finalized-executable.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-finalized-executable.wiki
new file mode 100644
index 00000000..2fb5e344
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-finalized-executable.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Run a finalized executable]]
+[[Property:weight|-11]]
+As opposed to other execution commands, this command launches an application compiled in finalized mode. This has the same effect as running the application in the EIFGENs/target_name/F_code directory from a console prompt.
+
+No debugging is possible with this command, but it lets you test the real speed of your program without any overhead.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-run-finalized-icon]] ) or through the '''project''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]]
+[[Generating executables|Compiling in finalized mode]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-without-breakpoints.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-without-breakpoints.wiki
new file mode 100644
index 00000000..62def7de
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-without-breakpoints.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Run without breakpoints]]
+[[Property:weight|-12]]
+This command launches an application compiled in Workbench mode. The application will not stop when a [[Breakpoints: Introduction|breakpoint]] is encountered. However, it stops when an exception occurs.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-run-without-breakpoint-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]]
+[[Generating executables|Compiling in Workbench mode]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-feature.wiki
new file mode 100644
index 00000000..51cd9dc5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-feature.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Step into a feature]]
+[[Property:weight|-10]]
+If no application was already running, this command launches an application compiled in Work Bench mode and stops at its first line.
+
+If an application was stopped, it attempts to enter the feature located on the execution line where the application is stopped. If this feature is an attribute, or another non debuggable feature, it simply executes the current execution line and stops at the next one.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-step-into-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]]
+[[Generating executables|Compiling in Workbench mode]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-out-feature.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-out-feature.wiki
new file mode 100644
index 00000000..ef2f5269
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-out-feature.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Step out of a feature]]
+[[Property:weight|-8]]
+If no application was already running, this command launches an application compiled in Work Bench mode and stops at its first line.
+
+If an application was stopped, it attempts to exit the feature where the application is stopped.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-step-out-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]]
+[[Generating executables|Compiling in Workbench mode]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/stop-debugged-application.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/stop-debugged-application.wiki
new file mode 100644
index 00000000..9d2250ed
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/stop-debugged-application.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Stop a debugged application]]
+[[Property:weight|-6]]
+This command kills the debugged application, if any. This stops the debugging session.
+
+It is accessible through the '''project''' toolbar ( [[Image:debug-stop-icon]] ) or through the '''debug''' menu.
+
+{{seealso| '''See Also'''
+[[Eiffel Debugger Execution: Introduction|Execution commands]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/index.wiki
new file mode 100644
index 00000000..039b525d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Execution record and replay]]
+[[Property:weight|-12]]
+* [[Introduction to execution record and replay|Introduction]]
+* [[Record execution|Execution recording]]
+* [[Replay (recorded) execution|Execution replaying]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/record-execution.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/record-execution.wiki
new file mode 100644
index 00000000..d6012033
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/record-execution.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Record execution]]
+[[Property:weight|1]]
+For performance reason, the recording mechanism has a few parameters. For now there is no way to change them easily with the graphical debugger, however you can change those parameters by editing (and recompiling) {RT_DBG_EXECUTION_PARAMETERS}.make.
+* integer parameter: {RT_DBG_EXECUTION_PARAMETERS}.'''maximum_record_count''' (default: 1_000_000):
+the recording keeps only the last '''maximum_record_count''' object's records.
+* boolean parameter: {RT_DBG_EXECUTION_PARAMETERS}.'''flatten_when_closing''' (default: True):
+when leaving a feature, the recorder can flatten the associated record. This will save memory space, and optimize underlying mechanism. By default it is enabled (and recommanded).
+* boolean parameter: {RT_DBG_EXECUTION_PARAMETERS}.'''keep_calls_records'''(default: True):
+when flattening call records' values, keep the sub-call records (i.e: the execution calls history)?
+* boolean parameter: {RT_DBG_EXECUTION_PARAMETERS}.'''recording_values'''(default: True):
+during execution, record attribute and locals assignment?(if you just want to review the calls history, you can discard value recording to speed up the recording.)
+
+{{warning|Since there is no way to restore local values when the execution left the related call stack frame, the recording discards the recorded local values.}}
+
+
+The recording functionality is graphically available on the Call stack tool, or though the "Execution" menu (former "Debug" menu).
+
+When you start debugging, at some point you decide to start recording, click on the "record" button:
+
+ [[Image:exec-replay-00]]
+
+{{note|If you want to record from the beginning, just enable the recording before starting the debug session (the recording button is a toggle button)}}
+
+{{tip|You can also use the "When hits.." actions of [[Breakpoint editing|breakpoints]] to start and stop the execution recording. This can be useful to record only the part you are interested in.}}
+
+ [[Image:exec-replay-00-1]]
+
+The execution is now recorded, whenever the application is stopped, you can decide to [[Replay (recorded) execution|replay]] the previously recorded execution. [[Replay (recorded) execution|Read how to replay execution]] .
+
+{{warning|For now, EiffelStudio supports only "Replay back" and "Replay forth" (finner replay might be added for 6.2).}}
+
+{{warning|EiffelStudio 6.1 provides this feature only on classic system, this is not yet supported on dotnet (planned for 6.2).}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/replay-recorded-execution.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/replay-recorded-execution.wiki
new file mode 100644
index 00000000..67971f54
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/replay-recorded-execution.wiki
@@ -0,0 +1,43 @@
+[[Property:title|Replay (recorded) execution]]
+[[Property:weight|2]]
+The replay functionality is graphically available on the Call stack tool, or though the "Execution" menu.
+
+{{note|First, you must be sure execution recording is activated ([[Record execution|read how to record execution]] ).}}
+
+Now, whenever the application is stopped in the debugger, you can replay the recorded execution by clicking on the "Replay" button:
+
+ [[Image:exec-replay-01]]
+
+Now we are in "execution replay" mode, as you can notice the "Replay" button is enabled, and there is a new commands bar with replay "Back", "Forth", "Previous", "Next", and "Go to". And on the right the number indicates the call stack depth, the breakable index, and the nested breakable index .
+* '''Back''': means replay back to caller, i.e: down in the call stack.
+* '''Forth''': means replay to callee, i.e: up in the call stack.
+* '''Previous''': means replay to previous instruction (previous call in the same stack; i.e: similar to step previous) if possible.
+* '''Previous''': means replay to next instruction (next call in the same stack; i.e: similar to step next) if possible.
+* '''Go to''': replay to the selected call when possible.
+In the first column, you will find a tree structure, which show on the root level, the effective call stacks, and for each root node, you can inspect the sub element to browse the calls history.
+The '''bold entries''' show the active call stacks (i,e: the current call stack when we stopped the debugger).
+The '''red arrow''' shows the replayed call stack level, and the call stack levels which can be replayed have a light blue background.
+
+ [[Image:exec-replay-02]]
+
+If you expand a node, you will be able to browse the whole recorded execution history from this stack (if you expand the bottom node, the whole recorded execution history will be available).
+You can still select other call stack level as you do in normal debugging mode to inspect them, in this case the red arrow stick to the replayed call, and the green arrow show you the selected call stack level.
+
+ [[Image:exec-replay-02-1]]
+
+Here we clicked on "Back" 3 times, you can now also replay "Forth" 3 times. When you execute a "Replay" operation, the debugger restores the related recorded values, and the various debugger tools are updated with tools values (including the watch tools)
+
+ [[Image:exec-replay-03]]
+
+And then if you replay "previous" twice, you rewind the execution in the same call stack frame, you will notice the "blue" dot to show the replayed execution cursor.
+
+
+ [[Image:exec-replay-04]]
+
+{{note|When replaying, you will notice the debugging tools are synchronized and refresh.
+This means the objects tool, the watch tools, and the feature tool will display the replayed context (values, and replayed execution cursor).
+If you evaluate an expression in a watch tool, it will use the recorded values, then be careful about side effects, since you can modify those values... }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/evaluation-tool-or-watch-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/evaluation-tool-or-watch-tool.wiki
new file mode 100644
index 00000000..3b9c988d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/evaluation-tool-or-watch-tool.wiki
@@ -0,0 +1,42 @@
+[[Property:title|Evaluation tool or Watch tool]]
+[[Property:weight|1]]
+The expression evaluation tool's main part is the list of expressions that should be evaluated.
+
+[[Image:expression-evaluation-tool]]
+
+Its first column gives the expression's text, the context's column gives the context in which the [[New expression dialog|expression]] is evaluated. The value's column gives the result of the expression, and the type's column the result's type of the expression..
+
+In the screenshot, you can see various expressions, the 4th one, is a dropped object, and the debugger displayed it as itself, this is shown by the context's value "As object", and also by the italic style. The user can name the dropped object by editing the "expression" cell. This is useful to remember the origin of the value.
+
+The 5th expression has an error, the icon is different, and the 'value' shows there is an error, double click on it for more details
+
+{{tip| '''Tip''': If the expression returns a non-Void (and non basic type) object, then the corresponding row in the list is pickable, and can be dropped for example in the Watch tool to evaluate expression on it, or even to keep the object over the steppings. }}
+
+{{tip| '''Tip''': holding the mouse pointer over the expression's cell will popup a tooltip with details on the pointed expression }}
+
+On top of the list, four buttons can be found.
+* the button [[Image:toolbar-dropdown-icon]] is used to create/close watch tools via a menu popup
+* [[Image:debugger-auto-values]] Enable or disable auto expressions.
+* [[Image:new-expression-icon]] pops up the [[New expression dialog|expression definition dialog]] , and can be used to define new expressions. If you have selected text in the editor, this text will be used to create the expression.
+* [[Image:general-edit-icon]] edits a currently selected expression (it is not possible to change the context of an expression, only the expression itself).
+The associated key shortcut is F2.
+* [[Image:general-toogle-icon]] disable/enable the evaluation of the selected expressions from the list.
+
+* [[Image:debugger-set-sizes-icon]] set the slice limits of dropped SPECIAL or NATIVE_ARRAY objects.
+
+* [[Image:debugger-show-hex-value-icon]] Toggle format display of numeric between decimal and hexadecimal format.
+
+* [[Image:debugger-expand-info-icon]] This command can give an [[Object Viewer (also known as Expanded display)|expanded display]] of the string relative to an object, by dropping the object onto the button (or pressing Ctrl+E on the selected value). Use it if an object has a very long string representation or a string representation that contains carriage returns, for example.
+
+* [[Image:execution-object-storage-icon]] This button is used to remotely store or load a "stored" object (check [[Debuggee's Object Storage|remote object storage]] ).
+
+* [[Image:general-delete-icon]] removes the selected expressions from the list.
+The associated key shortcut is Del.
+* And the last two buttons are used to move up and down the expressions. You can also move the expressions up and down using [CONTROL] + [-] or [CONTROL] + [+].
+
+{{tip| '''Tip''': Dropping an object onto this list lets you define quickly an expression whose context is the dropped object. This avoids having to type object addresses manually.
+If you press the [Control] key during the dropping, you will add the dropped object as itself. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/index.wiki
new file mode 100644
index 00000000..580476a3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Expression evaluation]]
+[[Property:weight|-10]]
+* [[Expression evaluation: Introduction|Introduction]]
+* [[Evaluation tool or Watch tool|Evaluation tool (alias Watch tool)]]
+* [[New expression dialog|New expression dialog]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/new-expression-dialog.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/new-expression-dialog.wiki
new file mode 100644
index 00000000..b5ea58f1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/new-expression-dialog.wiki
@@ -0,0 +1,28 @@
+[[Property:title|New expression dialog]]
+[[Property:weight|2]]
+Adding new expressions to the [[Evaluation tool or Watch tool|list of expressions]] that should be dynamically evaluated is performed via a dialog.
+
+
+{|
+|-
+| [[Image:new-expression-definition-dlg]]
+context: Current feature
+| [[Image:new-expression-as-object-definition-dlg]]
+context: As object
+|}
+
+
+The first part in the dialog makes it possible to select the context of the expression.
+* The default context is the context of the [[Information relative to a stack element|currently selected call stack element]] . This context gives access to the locals, the arguments, the result and the enclosing object features.
+
+* The object context, that requires a valid object address, gives access to the features of the selected object. But if the "As object" is selected, the result of the expression, is the pointed object it self; and you can name the object (see the second screenshot).
+* The last context, the class-related context, gives access to the once and constants features of that class. It requires a valid class name.
+
+
+The second part prompts for the expression itself. This field supports arguments, dot calls and operators (to a certain extent), but does not support creation expressions, agents or static calls (as in "feature {MY_CLASS}.my_feature"). Genericity is partially supported. Despite these limitations, we believe the expression evaluation tool should provide you with a lot of useful functionality.
+
+And the "Keep Assertion Checking" checkbox is used to enable assertion checking during expression evaluation if wanted (by default assertions won't be checked).
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/index.wiki
new file mode 100644
index 00000000..62d45043
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/index.wiki
@@ -0,0 +1,22 @@
+[[Property:title|EiffelStudio Debugger]]
+[[Property:link_title|Debugger]]
+[[Property:weight|-8]]
+* [[Eiffel Debugger: Introduction|Introduction]]
+* [[Execution commands|Execution commands]]
+* [[Breakpoints|Breakpoint management]]
+* [[Call stack tool|Call stack information]]
+* [[Execution record and replay|Execution replay mechanism]]
+* [[Object tool|Objects tool (stack information)]]
+* [[Object Viewer (also known as Expanded display)|Object viewer tool (also known as expanded display)]]
+* [[Expression evaluation|Dynamic evaluation of expressions]]
+* [[Debuggee's Object Storage|Debuggee object storage]]
+* [[Threads tool|Threads information]]
+* [[Exceptions handling tool|Exception caching handler tool]]
+* [[Stack overflow prevention|Stack overflow prevention]]
+* [[Debugging tips with the objects grid view|Debugging tips with the objects grid view]]
+* [[Debugging preferences|Debugging preferences]]
+* [[Debugging limitations|Debugging limitations]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki
new file mode 100644
index 00000000..56211d16
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Attribute symbols]]
+[[Property:weight|1]]
+In both trees of the [[Objects tool: Introduction|object tool]] , objects are displayed. Two categories are made for each objects: its attributes (grouped under the `attributes' folder [[Image:feature-attribute-icon]] ) and its once routines (grouped under the `once routines' folder [[Image:feature-once-icon]] ).
+
+All follow the following symbol scheme to describe the kind of each item:
+* [[Image:debugger-object-immediate-icon]] An attribute of a basic type, such as [/libraries/base/reference/kernel/integer_chart.xml| INTEGER ], [/libraries/base/reference/kernel/classic/double_chart.xml| DOUBLE ],...
+* [[Image:debugger-object-eiffel-icon]] An attribute that is a reference to an object
+* [[Image:debugger-object-void-icon]] A Void reference
+* [[Image:debugger-object-expanded-icon]] An object that is expanded
+
+For .NET system, special symbols are used to describe :
+* [[Image:debugger-object-dotnet-icon]] An object that is external (i.e not known as an Eiffel type)
+* [[Image:debugger-object-dotnet-static-icon]] A static value object that is external (i.e not known as an Eiffel type)
+* [[Image:debugger-object-static-icon]] A static value object that is known as an Eiffel type
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki
new file mode 100644
index 00000000..13fbaa4b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Debug output]]
+[[Property:weight|2]]
+In both grids of the [[Objects tool: Introduction|object tool]] , objects are displayed. For virtually all objects, it is possible to display a user-definable string value next to the object address.
+
+To do so, inherit from the class DEBUG_OUTPUT in the classes that should let their objects display a string value, and implement the `debug_output' feature. At run-time, the debugger will automatically query the result of this feature on all objects that define it and display it in the object tool and the [[Expression evaluation|evaluation tool]] .
+
+{{sample| '''Sample''': The NUMERIC class inherits from the DEBUG_OUTPUT one so that it is possible to see the value of *_REF objects without expanding them. }}
+
+{{tip| '''Tip''': If an object has a long string output or an output with carriage returns, for instance, pick-and-drop it to the expanded display command [[Image:debugger-expand-info-icon]] in the object tool. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki
new file mode 100644
index 00000000..a0387330
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Object tool]]
+[[Property:weight|-11]]
+* [[Objects tool: Introduction|Introduction]]
+* [[Attribute symbols|Attribute symbols]]
+* [[Debug output|Debug output]]
+* [[Image:debugger-set-sizes-icon]] [[Set slice size command|Set slice size command]]
+* [[Image:general-delete-icon]] [[Remove object command|Remove object command]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki
new file mode 100644
index 00000000..3c56f4c6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki
@@ -0,0 +1,47 @@
+[[Property:title|Object Viewer (also known as Expanded display)]]
+[[Property:weight|4]]
+You can either show the "Object Viewer" tool (Menu Execution>Tools>Object Viewer, or popup the object viewer dialog thanks to the button located in the tool bar of the [[Object tool|objects tool]] and [[Expression evaluation|watch tool]] .
+This command [[Image:debugger-expand-info-icon]] opens an object viewer dialog when an object is dropped onto the button.
+
+Depending the nature of the dropped object, you can view it with several viewers:
+* '''Object dump''': dump a text representation of the value
+* '''String display''': string representation
+* '''XML display''': xml viewer
+* '''Object browse''': browse the object, as you would do in objects or watch tools
+* '''Object internal''': display a few internal data such as class_name, type_name, dynamic_type, field_count, deep_physicial_size, and physical_size
+
+{{note|Note that the "string display" viewer is available for object with a string representation, for instance object conformed to [[ref:/libraries/base/reference/string_8_chart]] or conform to [[ref:/libraries/base/reference/debug_output_chart]] (see [[Debug output|Debug Output]] )}}
+
+{{note|And the "XML display" is available for object eligible to "String display", and whose string representation has XML content. The viewer is display XML in a basic tree enabled grid.}}
+
+
+'''String display viewer:''':
+
+ [[Image:expanded-display-default]]
+
+Displays the object as a string, by default the displayed length is 50:
+If the limits are over the current slice limits, the displayed string will end by "..." to show there is more.
+If you click on the auto expand button [[Image:debugger-object-expand-icon]] , the slice limits will be set to the lower and upper limits of the string value.
+
+You can enable or disable the line wrapping by clicking onto [[Image:general-word-wrap-icon]] .
+
+
+'''Object dump viewer:'''
+ [[Image:object-viewer-dump]]
+
+
+'''Object browse viewer:'''
+ [[Image:object-viewer-browse]]
+
+
+'''Object internal viewer:'''
+ [[Image:object-viewer-internal]]
+
+
+'''XML viewer:'''
+ [[Image:object-viewer-xml]]
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/remove-object-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/remove-object-command.wiki
new file mode 100644
index 00000000..2268b7d7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/remove-object-command.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Remove object command]]
+[[Property:weight|5]]
+Located in the [[Objects tool: Introduction|object tool]] toolbar, this command [[Image:general-delete-icon]] discards an object from the [[Objects tool: Introduction|object tools]] . All top-level objects can be removed, except the first one, which is the object relative to the [[Callstack tool: Introduction|current call stack element]] .
+
+Left-clicking on this button removes the selected object from the [[Objects tool: Introduction|object tools]] , if possible. It is also possible to [[Pick-and-drop mechanism|drop]] an object onto the button to remove the object.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki
new file mode 100644
index 00000000..31828fce
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Set slice size command]]
+[[Property:weight|3]]
+Located in the object tool toolbar, this command [[Image:debugger-set-sizes-icon]] changes the display size of special objects (i.e. objects whose class is [[ref:/libraries/base/reference/special_chart]] ).Since special objects may contain thousands of attributes, only the first fifty are displayed by default. If left-clicked, a dialog is popped up that sets the exploration indices of special objects that will be loaded in the future.
+This popup also shows the "Maximum displayed string size" in the grid ([[Objects tool: Introduction|objects tool]] , or the [[Expression evaluation|watch tools]] ).
+
+This dialog changes the settings for future special objects:
+
+[[Image:set-default-slice-size-dlg]]
+
+If a special object is [[Pick-and-drop mechanism|dropped]] onto this command, the special object that is dropped is shrunk or extended in the tree according to the new exploration indices it is given in the dialog box. The dropped object may be any object, top-level or not.
+
+This dialog changes the settings for a single special object (the dropped object) :
+
+[[Image:set-slice-size-dlg]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/stack-overflow-prevention.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/stack-overflow-prevention.wiki
new file mode 100644
index 00000000..8061a8e7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/stack-overflow-prevention.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Stack overflow prevention]]
+[[Property:weight|-6]]
+Accessible via the '''Debug/Overflow prevention...''' menu, this command makes it possible to detect stack overflows before they occur. Selecting it pops up a dialog that lets you decide at which call stack depth a warning should be issued.
+
+[[Image:stack-overflow-dlg]]
+
+By default a warning is issued when the debugged program reaches a stack depth of 1,000 elements.
+
+{{note| '''Note''': Once an application has stopped at the selected level, it will not stop again until its stack depth goes below the critical stack depth again. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/threads-tool.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/threads-tool.wiki
new file mode 100644
index 00000000..804c98ad
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/debugger/threads-tool.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Threads tool]]
+[[Property:weight|-8]]
+This tool displays the list of current Eiffel '''threads'''.
+To show this tool, go to menu : '''Debug > Tools > Threads''' .
+ [[Image:threads-tool|Threads tool]]
+By double clicking on a row, you change the current thread for the debuggee (application). If you double click on "Note" cell, you can edit a note, this can be useful to identify a thread during the debugging session.
+The highlighted line shows the current thread.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/contexts.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/contexts.wiki
new file mode 100644
index 00000000..5ef58a43
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/contexts.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Contexts]]
+[[Property:weight|4]]
+A diagram in the diagram tool is always the context of a certain class or cluster. Context means the direct relations up to a certain depth.
+
+For clusters, the relations are:
+* subclusters
+* superclusters
+
+The relations for classes are:
+* ancestors
+* descendants
+* clients
+* suppliers
+This is an example of the class LIST, with ancestor depth 2, descendant depth 2 and both client and supplier depth zero. [[Image:bon-list-relations]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-tool-code-generation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-tool-code-generation.wiki
new file mode 100644
index 00000000..4d934fd0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-tool-code-generation.wiki
@@ -0,0 +1,97 @@
+[[Property:title|Diagram tool: Code generation]]
+[[Property:weight|5]]
+All actions taken in the diagram tool that modify a part of the system are immediately reflected in the Eiffel system. Following is a summary of these actions.
+* When you create a new class, this is the generated empty class:
+
+indexing
+ description: "Objects that ..."
+ author: ""
+ date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $"
+ revision: "$Revision: 74646 $"
+
+class
+ CLASS_NAME
+
+end -- class CLASS_NAME
+
+
+* When you delete a class, the class file is removed from the disk.
+* When you add a parent to a class, the parent is inserted in the existing inheritance clause, ''without'' any additional ( undefine / select /etc.) clauses to solve possible conflicts.
+
+indexing
+ description: "Objects that ..."
+ author: ""
+ date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $"
+ revision: "$Revision: 74646 $"
+
+class
+ CLASS_NAME
+
+inherit
+ NEW_PARENT
+
+end -- class CLASS_NAME
+
+
+* When removing an inheritance link, the entire parent clause is removed, i.e. including any redefine / undefine /etc. until the matching end .
+* When creating a client link, a function or attribute is generated by the feature wizard. When creating a function, this code is generated:
+
+indexing
+ description: "Objects that ..."
+ author: ""
+ date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $"
+ revision: "$Revision: 74646 $"
+
+class
+ CLASS_NAME
+
+feature -- Access
+
+ f: TYPE is
+ -- Client from CLASS_NAME to TYPE.
+ do
+ end
+
+end -- class CLASS_NAME
+
+
+* If you choose to create an attribute for the client link, and optionally specify to generate a set-procedure and an invariant, the following code will be pasted into the class text:
+
+indexing
+ description: "Objects that ..."
+ author: ""
+ date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $"
+ revision: "$Revision: 74646 $"
+
+class
+ CLASS_NAME
+
+feature -- Access
+
+ f: TYPE is
+ -- Client from CLASS_NAME to TYPE.
+
+feature -- Element change
+
+ set_f (a_f: TYPE) is
+ -- Client from CLASS_NAME to TYPE.
+ require
+ a_f_not_void: af /= Void
+ do
+ f := a_f
+ ensure
+ f_assigned: f = a_f
+ end
+
+invariant
+ f_not_void: f /= Void
+
+end -- class CLASS_NAME
+
+
+* When removing a client link, only the matching function or attribute is removed. Any additionally generated set-feature or invariant is not removed.
+* When removing a cluster, the associated directory is not erased, but the reference to the cluster is removed from the configuration file. At this time, it is not possible to create a cluster using the diagram tool, only to remove one.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-toolbar.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-toolbar.wiki
new file mode 100644
index 00000000..d8a4351f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-toolbar.wiki
@@ -0,0 +1,51 @@
+[[Property:title|Diagram toolbar]]
+[[Property:weight|2]]
+The toolbar of the diagram contains these buttons:
+* [[Image:diagram-target-cluster-or-class-icon]] Target to cluster or class
+Drop a class or a cluster on this icon to build the corresponding diagram.
+* [[Image:new-inheritance-link-icon]] [[Creating inheritance links|Create new inheritance links]]
+Selecting this button allows you to create inheritance, client-supplier or aggregate links by picking from one class and dropping on the other.
+* [[Image:16x16--new-class-icon]] [[Creating a new class|Create a new class]]
+Pick from this button and drop on the diagram to add a new class.
+* [[Image:general-undo-icon]] [[Undoing and redoing|Undo last action]]
+Click to undo the last action.
+* [[Image:general-undo-history-icon]] [[Undoing and redoing|History tool]]
+Click to open the '''History tool'''.
+* [[Image:general-redo-icon]] [[Undoing and redoing|Redo last action]]
+Click to redo the last undone action.
+* [[Image:general-reset-icon]] [[Removing items from a view|Remove figure]]
+Drop figures in this hole that you want to remove from the view only.
+* [[Image:diagram-choose-color-icon]] [[Changing colors of classes|Change color]]
+Drop class bubbles in this hole to change their color, or click this button and change the color of all class bubbles at once.
+* [[Image:diagram-fill-cluster-icon]] [[Retrieving all classes into a cluster|Include all classes of cluster]]
+Drop a cluster in this hole to show all classes of the cluster in this view.
+* [[Image:diagram-depth-of-relations-icon]] [[Changing system exploration depth|Select depth of relations]]
+Click to bring up the '''Select depth''' dialog.
+* [[Image:diagram-zoom-out-icon]] [[Zooming a diagram|Zoom out]]
+Shrink the diagram.
+* [[Image:diagram-fit-to-screen-icon]] [[Zooming a diagram|Fit Diagram to Screen]]
+Fit the diagram to the screen dimensions so it is all visible.
+* [[Image:diagram-zoom-in-icon]] [[Zooming a diagram|Zoom in]]
+Enlarge the diagram.
+* [[Image:diagram-inheritance-link-icon]] [[Showing or hiding links and labels|Show/hide inheritance links]]
+Toggle visibility of all inheritance links in the view.
+* [[Image:diagram-supplier-link-icon]] [[Showing or hiding links and labels|Show/hide client-supplier links]]
+Toggle visibility of all client-supplier links in the view.
+* [[Image:diagram-show-labels-icon]] [[Showing or hiding links and labels|Show/hide labels]]
+Toggle visibility of all client link labels in the view.
+* [[Image:diagram-export-to-png-icon]] [[Exporting a diagram to PNG image file|Export diagram to.png]]
+Click to generate a .png file from current view.
+* [[Image:diagram-toggle-quality-icon]] Toggles the drawing quality.
+* [[Image:diagram-toogle-physics-icon]] Toggles the physics mode on and off.
+* [[Image:diagram-view-uml-icon]] Toggles view between BON notation and UML.
+* [[Image:diagram-anchor-icon]] Allows to anchor or unanchor a class/cluster figure.
+* [[Image:diagram-physics-settings-icon]] Displays physics settings dialog to control physics behavour.
+* [[Image:16x16--general-delete-icon]] [[Deleting items|Delete]]
+Drop items in this hole to remove them from the system.
+* [[Image:diagram-show-legend-icon]] Toggle cluster color legend.
+* [[Image:diagram-force-right-angles-icon]] [[Using the link tool|Put handles on a link]]
+Click on this button to toggle right angles on all links in the view. Drop a link on it to bring up the link tool for that link.
+In addition to these toolbar buttons there is also a drop down list for selecting various zoom percentages on the current view, and a view list for switching between previously saved views/layouts of various parts of the system.
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/index.wiki
new file mode 100644
index 00000000..ca135cd0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Diagram tool]]
+[[Property:weight|-6]]
+* [[Diagram tool: Introduction|Introduction]]
+* [[Notation|Notation]]
+* [[Diagram toolbar|Diagram toolbar]]
+* [[Views|Views]]
+* [[Contexts|Contexts]]
+* [[Diagram tool: Code generation|Code generation]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/notation.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/notation.wiki
new file mode 100644
index 00000000..65131577
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/notation.wiki
@@ -0,0 +1,58 @@
+[[Property:title|Notation]]
+[[Property:weight|1]]
+The diagram tool uses the [http://bon-method.com BON] (Business Object Notation) to represent Eiffel systems. This article will give a summary of all components of an EiffelStudio diagram. For detailed information on BON, please read [http://bon-method.com/book.htm Seamless Object-Oriented Software Architecture] by Kim Walden and Jean-MarcNerson, Prentice Hall 1994.
+
+==Class==
+
+[[Image:bon-class]] An object class is represented by an ellipse(sometimes referred to as ''bubble''). It contains the class name and formal generics of the Eiffel class it represents. Second, it displays information about properties of a class. These properties are:
+* Deferred: class is declared as deferred .
+[[Image:bon-class-deferred]]
+
+* Effective: class is not deferred and has at least one deferred parent, or redefines one ore more features.
+[[Image:bon-class-effective]]
+
+* Persistent: class inherits STORABLE or has indexing tag persistent .
+[[Image:bon-class-persistent]]
+
+* Interfaced: class has one ore more external features.
+[[Image:bon-class-interfaced]]
+
+* Reused: class resides in a precompiled library or in a library cluster.
+[[Image:bon-class-reused]]
+
+* Root class: class has the program's entry point.
+[[Image:bon-class-root]]
+
+
+{{seealso| '''See also'''
+[[Rename class|Changing class names]] }}
+
+==Cluster==
+
+A cluster is a collection of classes and sub-clusters. It is represented by a stippled, rounded rectangle. The cluster name is in a similar rectangle, by default located at the top of the cluster just outside of it. A cluster can be iconified, which means it is minimized to take up as less space as possible.
+ [[Image:bon-cluster-iconified]] [[Image:bon-cluster]]
+
+{{seealso| '''See also'''
+[[Iconifying and restoring a cluster|Iconifying a cluster]] }}
+
+==Inheritance links==
+
+Inheritance between classes is represented by an arrow from a class to its parent. Typically, inheritance links point upwards.
+ [[Image:bon-inheritance]]
+
+
+{{seealso| '''See also'''
+[[Creating inheritance links|Creating inheritance links]] }}
+
+==Client/supplier links==
+
+Client relationships between classes are represented by an arrow with a double line from the client to the supplier. Typically, these links point to the right. A special kind of relationship is the aggregate client/supplier link. Aggregate means that the supplier is an integral part of the client. In the class text, it corresponds to expanded features. In the diagram, an aggregate link has a little line along the back side of the arrow.
+ [[Image:bon-client]] [[Image:bon-agg-client]]
+
+
+{{seealso| '''See also'''
+[[Creating client/supplier links|Creating client/supplier links]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/views.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/views.wiki
new file mode 100644
index 00000000..eba33403
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/diagram-tool/views.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Views]]
+[[Property:weight|3]]
+Every class or cluster has one or more views. Every view shows the [[Contexts|context]] of a class or cluster, a subset of the Eiffel system. For example, for a certain cluster, you can show only the hierarchy of the classes in it, but you could have a second view that shows only a couple of classes in it, but with all relations between them.
+ [[Image:diagram-view-combo]]
+The view combo box, as seen in the image above, can be used to add a view or switch to a previously added one. Every class and cluster has a view "DEFAULT" that is generated automatically. If you create a new view and move for example a class around in it, the "DEFAULT" view is unaffected.
+
+The case tool provides you with the following possibilities to manipulate views:
+* [[Adding a view|Adding a view]]
+* [[Deleting a view|Deleting a view]]
+* [[Showing or hiding links and labels|Showing or hiding links and labels]]
+* [[Removing items from a view|Removing items from a view]]
+* [[Changing colors of classes|Changing colors of objects]]
+* [[Using the link tool|Using the link tool]]
+* [[Changing system exploration depth|Changing system exploration depth of objects]]
+* [[Retrieving all classes into a cluster|Retrieving all classes into a cluster]]
+* [[Iconifying and restoring a cluster|Minimizing a cluster and restoring it to its normal state]]
+
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eiffel-scheme-syntax.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eiffel-scheme-syntax.wiki
new file mode 100644
index 00000000..206a9cf4
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eiffel-scheme-syntax.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Eiffel Scheme Syntax]]
+[[Property:weight|0]]
+'''eiffel:?<''eiffel-resource''>'''
+
+
+<''eiffel-resource''> is a combination of following parts, connected by '''&''' if more than one part are required:
+* <''systeme''>, in the form of system=to_be_replaced, '''to_be_replaced''' consists of system_name or uuid of the system, or both connected by "'''.'''".
+* <''targete''>, in the form of target=to_be_replaced, '''to_be_replaced''' consists of target_name or uuid of the system, or both connected by "'''.'''".
+* <''clustere''>, in the form of cluster=to_be_replaced, '''to_be_replaced''' is the name of the cluster.
+* <''classe''>, in the form of class=to_be_replaced, '''to_be_replaced''' is the name of the class.
+* <''featuree''>, in the form of feature=to_be_replaced, '''to_be_replaced''' is the name of the feature.
+
+{{note| '''Note: '''All parts above are unordered. }}
+
+{{seealso| '''See Also'''
+[[EIS incoming Examples|Examples]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eis-incoming-examples.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eis-incoming-examples.wiki
new file mode 100644
index 00000000..bd5f0d3d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eis-incoming-examples.wiki
@@ -0,0 +1,13 @@
+[[Property:title|EIS incoming Examples]]
+[[Property:weight|1]]
+The following are examples of EIS incoming URIs.
+* eiffel:?class=STRING_8&feature=is_equal
+* eiffel:?cluster=elks&class=STRING_8&feature=is_equal
+* eiffel:?target=base&cluster=elks&class=STRING_8&feature=is_equal
+* eiffel:?system=ec.D398E904-E3C8-4F8A-B9E7-6FE493CEA02F&target=base&cluster=elks&class=STRING_8&feature=is_equal
+* eiffel:?class=STRING_8
+* eiffel:?cluster=elks
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/index.wiki
new file mode 100644
index 00000000..69f4bf1b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|EIS: Incoming]]
+[[Property:weight|3]]
+Incoming mechanism is based on URI, and introduces a new URI scheme: '''eiffel'''. By entering the URI into address of a browser, or clicking on the hyper link, an existing EiffelStudio instance or new EiffelStudio instance will try to resolve the URI and display corresponding resources.
+* [[Eiffel Scheme Syntax|Eiffel scheme Syntax]]
+* [[EIS incoming Examples|Examples]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/index.wiki
new file mode 100644
index 00000000..adc8ed06
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/index.wiki
@@ -0,0 +1,34 @@
+[[Property:title|EIS: Outgoing]]
+[[Property:weight|2]]
+==Annotations==
+
+Annotations may be applicable to:
+* An individual class or feature. In this case the annotation figures in the class text, as part of an Eiffel "note" clause ("indexing" is still supported, it depends on which syntax level users choose).
+* A target, library or cluster. In this case the annotation figures in the associated ECF file; EiffelStudio provides support for entering it through a Information (EIS) Tool.
+{{seealso| '''See Also'''
+[[Information Tool|Information Tool]] }}
+
+
+The basic way to specify a dependency is to include such an annotation. The required part of an annotation is:
+* The "EIS" marker
+
+However the following parts are suggested:
+* The "protocol", indicating the type of external information, and making it possible for EIS to determine the associated external tool. Without the "protocol" part, the source defaults to be web page.
+* The source, identification of where to find information itself, for example a URL, or a file name.
+
+==Syntax for Annotations==
+
+The following example illustrates the basic form of an EIS note entry:
+EIS: "name=Project Requirement", "src=($PROJ)/docs/requirements.pdf", "protocol=PDF", "nameddest=4.1", "tag=requirement"
+
+The label (Node_entry as called in the ECMA/ISO Eiffel Standard syntax) is '''EIS'''. '''EIS''' Note_value tells the Eiffel Information System that this Note_entry is of interest to EIS, as distinct from any other information that might be expressed through a Note_entry. The file name (src) includes '''$PROJ''', referring to a variable, defining the project location. The protocol is PDF. The '''nameddest''' property (name destination) is a specific property of PDF documents. The tag '''requirement''' indicating that this entry links the enclosing Eiffel class or feature with some parts of the requirement documents.
+
+{{seealso| '''See Also'''
+[[Variable Definition|Variable Definition]] }}
+
+[[EIS: Outgoing|Syntax for Annotations]] }}
+
+
+==Removing==
+
+By pressing '''Delete''', or clicking the third button on the bottom toolbar deletes all selected annotations in the list. And corresponding code is synchronized.
+
+{{note| '''Note: '''Annotation list can be multi-selected. }}
+
+{{note| All means to manage annotations via the tool are inreversible, except that the location - class or feature - has been opened in the editor, thus undo can be achieved via the editor. Removing is prompted on user demands. The tag tree is automatically updated when annotations are added/modified/removed or through system sweeping. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/browsing-information.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/browsing-information.wiki
new file mode 100644
index 00000000..5b713b60
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/browsing-information.wiki
@@ -0,0 +1,52 @@
+[[Property:title|Browsing Information]]
+[[Property:weight|0]]
+[[Image:information-tool]]
+==Information Tree==
+
+On the left of the tool window is the information tree. The tree displays all locations where annotations are, as well as a subtree of tags by which annotations can be better organized in tag style. Double clicking or pressing enter on tree nodes opens annotation list corresponding to that node.
+
+The following are types of nodes in the tree can be navigated to:
+* Target
+* Cluster
+* Library
+* Class
+* Feature
+* Targets without tags
+* Listed tag
+
+==Annotation List==
+
+Double clicking on the tree node, the annotation list appears on the right of the tool window.
+
+The following columns are available in the list:
+* Location - the development object where that piece of annotation belongs to. Typical locations are target, cluster, class and feature.
+* Name - the name of the piece of annotation, given by users.
+* Protocol - type of the annotation EIS treats.
+{{seealso| '''See Also'''
+[[Protocols|Protocols]] }}
+
+* Source - normally the location EIS takes to open. Variables can be used.
+* Tags - terms or phrases users use to categrize the piece of information. Tags are separated by '''","'''
+* Others - other related attributes. Attributes are separated by '''","'''
+{{note| '''Note: '''Only attributes used by '''protocol''' are taken into account. Otherwise, ignored. }}
+
+
+{{note| '''Hint: '''Clicking on title of each column sorts that column. }}
+
+==Openning Resources==
+
+Information or resources can be opened by either double clicking into the annotation list or pressing enter on it. EIS interpretes available attributes via the given protocol and opens the target resource.
+
+{{note| '''Note: '''Pressing '''F1''' in the editor, a list of all available information pops up, from which information can be accessed too. }}
+
+==Sweeping Information==
+
+Sweeping information synchronizes all information of current system into the tool. This is needed when changes may occur externally and EIS may need to know full information to display a correct list of existing tags. Two ways of sweeping:
+* Automatic - EIS automatically sweeps information when Information tool is shown. Enabling the first button on the bottom toolbar activates this function.
+* Manual - The second button on the bottom toolbar triggers a manual sweeping.
+
+The progress bar in the bottom of the tool indicates current sweeping progress.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/index.wiki
new file mode 100644
index 00000000..d1ea32a1
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Information Tool]]
+[[Property:weight|0]]
+* [[Browsing Information|Browsing Annotations]]
+* [[Annotation Management|Annotation Management]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/protocols.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/protocols.wiki
new file mode 100644
index 00000000..4b95c098
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/protocols.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Protocols]]
+[[Property:weight|2]]
+EIS supports following protocols now:
+*
+Raw URL: This protocol does not need to specified. By default, it will be taken if nothing is specified or unknown protocol is specified.
+
+*
+PDF: PDF protocol supports three attributes for now. "type" "page" and "nameddest". (Windows only)
+** type: "file" is used to open PDF files in PDF reader. Otherwise in a browser.
+** page: Specify the page number to navigate to.
+** nameddest: Specify the named destination to navigate to.
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/variable-definition.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/variable-definition.wiki
new file mode 100644
index 00000000..da1f1127
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/variable-definition.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Variable Definition]]
+[[Property:weight|3]]
+EIS supports following types of variables which can be used in '''Source''' of annotation list.
+* EiffelStudio installation built in variables
+** ISE_WIKI = http://dev.eiffel.com
+** EIFFELROOM = http://www.eiffelroom.com
+
+* Context related built in variables. These variables can be used in specific context. For instance, '''feature_name''' refers to the name of the feature in which annotation is written.
+** feature_name
+** class_name
+** group_name
+** target_name
+
+{{note|'''Note: '''This kind of variables can only be used in components that are enclosed in those the variable name refers to. For example, '''feature_name''' has no effect if used in a target component.}}
+
+* Individual system or library preferences. This kind of variables are defined in .ecf files, can be accessed via Project Setting dialog.
+{{note|System -> Target -> Advanced -> Variables}}
+
+* Environment variables. Variables defined in the operating system environment.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki
new file mode 100644
index 00000000..df7a02bf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Eiffel Information System]]
+[[Property:weight|-2]]
+* [[Eiffel Information System: Introduction|Introduction]]
+* [[EIS: Incoming|Incoming]]
+* [[EIS: Outgoing|Outgoing]]
+** [[Information Tool|Information(EIS) Tool]]
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/class-name-auto-complete.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/class-name-auto-complete.wiki
new file mode 100644
index 00000000..b6b674e4
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/class-name-auto-complete.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Class name auto complete]]
+[[Property:weight|3]]
+EiffelStudio editor offers the possibility to complete class names automatically. This means that when the user types " ''a_variable: AN_INCOMPLETE_CLASS_NAME''" and then triggers the auto-complete, the editor will propose a list of possible valid class names.
+To be more precise, a window will pop up and display the list of classes that match ''AN_INCOMPLETE_CLASS_NAME''. The user can accept the suggested name, choose another name (in the list or not), or simply cancel the auto-complete.
+
+[[Image:editor-class-auto-completion-window]]
+
+To trigger the auto complete, press the key combination "Ctrl+Shift+Space" or click on '''Complete class name''' in the '''Advanced''' sub-menu of the [[Edit menu commands|menu]] . If automatic completion is possible, there are two cases : if only one name matches, this name will be inserted in the editor. If there are no matching names or several ones a window will appear. This window will contain a text field and a list. The text field will be filled with the beginning of the class name that was entered. The first item in the list, if any, will be selected.
+To complete your code with the selected item, press "Enter" or "Ctrl+Space".
+To choose another item, use keyboard Up and Down arrows or the mouse. You can also modify the content of the text field. The list will be updated automatically. To validate your choice, press "Enter" or "Ctrl+Space". If there is no selected item, the content of the text field will be inserted.
+To cancel the auto-complete, press "Esc" at any time.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/feature-call-auto-complete.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/feature-call-auto-complete.wiki
new file mode 100644
index 00000000..d96bd2b8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/feature-call-auto-complete.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Feature call auto complete]]
+[[Property:weight|2]]
+EiffelStudio editor now offers the possibility to complete feature calls automatically. This means that when the user types " ''an_identifier.an_incomplete_feature_name''" and then triggers the auto-complete, the editor will propose a list of possible feature names correct in this situation.
+To be more precise, a window will pop up and display the list of features that can be called on ''an_identifier'' and that match ''an_incomplete_feature_name''. The user can accept the suggested name, choose another name (in the list or not), or simply cancel the auto-complete.
+
+[[Image:editor-auto-completion-window]]
+
+To trigger the auto complete, press the key combination "Ctrl+Space" or click on '''Complete word''' in the '''Advanced''' sub-menu of the [[Edit menu commands|menu]] . If automatic completion is possible, there are two cases : if only one name matches, this name will be inserted in the editor. If there are no matching names or several ones a window will appear. This window will contain a text field and a list. The text field will be filled with the beginning of the feature name that was entered. The first item in the list, if any, will be selected.
+To complete your code with the selected item, press "Enter" or "Ctrl+Space".
+To choose another item, use keyboard Up and Down arrows or the mouse. You can also modify the content of the text field. The list will be updated automatically. To validate your choice, press "Enter" or "Ctrl+Space". If there is no selected item, the content of the text field will be inserted.
+To cancel the auto-complete, press "Esc" at any time.
+
+{{tip| '''Tips''': }}
+* If the selected feature is a query, you can call the auto-complete again right after the previous completion. There is no need to type a dot.
+* You can call the auto-complete without an identifier. The auto-complete window will then show the features of the current class.
+* The keyboard shortcut for automatic completion can be changed in the [[Keyboard shortcuts preferences|editor preferences]] .
+* Typing a non-alphanumeric character in the completion window automatically closes it. You can therefore type '.', ' ' or '(' to close the completion window and start typing the next token straight away.
+
+{{note| '''Notes''': }}
+* Only identifiers that were already defined when the class was compiled for the last time can be completed, except for local entity names that can always be completed.
+* Only compiled features will appear in the auto-complete window.
+* By default, features from class ANY will be ignored by the auto-complete window. This can be changed in the [[General Editor Preferences|editor preferences]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/index.wiki
new file mode 100644
index 00000000..8453f90e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Automatic completion]]
+[[Property:weight|6]]
+* [[Automatic completion: Introduction|Introduction]]
+* [[Syntax auto complete|Syntax auto-complete]]
+* [[Feature call auto complete|Feature call auto-complete]]
+* [[Class name auto complete|Class name auto-complete]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/syntax-auto-complete.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/syntax-auto-complete.wiki
new file mode 100644
index 00000000..82153840
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/syntax-auto-complete.wiki
@@ -0,0 +1,69 @@
+[[Property:title|Syntax auto complete]]
+[[Property:weight|1]]
+Syntax auto-complete in EiffelStudio editor is twofold :
+*
+The editor can close brackets ("(", "{" and "[") and quotes(""", "'" and "`") automatically. This feature is disabled by default. It can be activated in the editor preferences.
+
+*
+The editor can complete syntactic structures or part of them. The auto-complete is triggered when "Enter" or "Space" keys are pressed after a reserved word included in the following list:
+{|
+|-
+| class
+| ensure
+| invariant
+| require else
+|-
+| check
+| ensure then
+| is
+| rescue
+|-
+| create
+| export
+| local
+| select
+|-
+| creation
+| external
+| loop
+| then
+|-
+| debug
+| feature
+| obsolete
+| undefine
+|-
+| deferred
+| from
+| once
+| until
+|-
+| do
+| if
+| precursor
+| variant
+|-
+| else
+| indexing
+| redefine
+| when
+|-
+| elseif
+| inherit
+| rename
+|-
+| end
+| inspect
+| require
+|}
+
+The way these reserved words are completed is fully [[Syntax automatic completion preferences|customizable]] .
+
+
+{{seealso| '''See Also'''
+To see how the editor completes by default and how it can be changed, please read the following pages: [[Syntax automatic completion preferences|Syntax auto-complete preferences]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/clipboard-functionality.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/clipboard-functionality.wiki
new file mode 100644
index 00000000..fb85ca9c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/clipboard-functionality.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Clipboard functionality]]
+[[Property:weight|3]]
+EiffelStudio editor provides common clipboard functionality, i.e. Cut, Copy and Paste commands.
+*
+To copy text to the clipboard, [[Selection|select]] it in the editor first. Then, you may either press the key combination "Ctrl+C" (or "Shift+Ins"), click on the copy icon [[Image:16x16--general-copy-icon]] or choose '''Copy''' in the '''Edit''' menu.
+
+*
+To cut text, i.e. copy it to the clipboard and delete it, [[Selection|select]] it and then either press "Ctrl+X" (or "Shift+Del"), click on the cut icon [[Image:general-cut-icon]] or choose '''Cut''' in the '''Edit''' menu.
+
+*
+To paste text from the clipboard, either press "Ctrl+V" (or"Ctrl+Ins"), click on the paste icon [[Image:general-paste-icon]] or choose '''Paste''' in the '''Edit''' menu.
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/cursor-moves.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/cursor-moves.wiki
new file mode 100644
index 00000000..e869b4ef
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/cursor-moves.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Cursor moves]]
+[[Property:weight|1]]
+There are two ways to position the cursor in EiffelStudio editor: you can use either the mouse or the keyboard.
+
+If you choose to use the mouse, just click in the text where you want the cursor to be moved. If the text is not entirely visible, you can use the scroll bar at the bottom and on the left of the edition zone to display the part you are interested in.
+
+The keys that you may use to move the cursor in EiffelStudio editor are "Home", "End", "Page up", "Page Down" and the four arrows. Pressing "Home" will make the cursor go to the beginning of the line. Pressing "End" will move the cursor to the end of the line. You can use "Page Up" to move the cursor one page closer to the beginning of the text. Pressing "Page down" will position the cursor one page further.
+Left and Right arrows can be used to move respectively to the character on the left or on the right of current position. Up and Down arrows allow you to move the cursor to the previous and next lines.
+
+{{tip| '''Tip''': By maintaining "Ctrl" pressed as you use Left and Right arrows, you will move the cursor to the next or previous word instead of the next or previous character. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/edit-menu-commands.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/edit-menu-commands.wiki
new file mode 100644
index 00000000..c1d063b0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/edit-menu-commands.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Edit menu commands]]
+[[Property:weight|8]]
+In the '''Edit''' menu, the following commands are available:
+* [[History functionality|Undo]] : undo last change.
+* [[History functionality|Redo]] : redo last undone change.
+* [[Clipboard functionality|Cut]] : Cut [[Selection|selected]] text.
+* [[Clipboard functionality|Copy]] : Copy [[Selection|selected]] text.
+* [[Clipboard functionality|Paste]] : Paste text from the clipboard.
+* [[Selection|Select All]] : Select the entire text.
+* [[Search tool|Find]] : Show and go to the [[Search tool|search panel]] .
+* [[Search tool|Replace]] : Show and go to the [[Search tool|search panel]] with replace option activated.
+* Toggle Line Numbers: Show or hide the line numbers in the current editor.
+* [[Search functionality|Search]] :
+** [[Search functionality|Find next]] : Find the next occurrence of the last searched expression.
+** [[Search functionality|Find previous]] : Find the previous occurrence of the last searched expression.
+** [[Search functionality|Find selection]] : Find the next occurrence of the selected text.
+
+* Advanced
+** [[Indent and un indent selection|Indent selection]]
+** [[Indent and un indent selection|Unindent selection]]
+** [[Comment and uncomment lines|Comment]]
+** [[Comment and uncomment lines|Uncomment]]
+** [[Embed lines in 'if then...end' or in 'debug...end'|Embed in if...]]
+** [[Embed lines in 'if then...end' or in 'debug...end'|Embed in debug...]]
+** [[Feature call auto complete|Complete word]]
+** [[Class name auto complete|Complete class name]]
+
+* [[Preference window overview|Preferences]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/editor-customization.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/editor-customization.wiki
new file mode 100644
index 00000000..e4e616b5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/editor-customization.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Editor customization]]
+[[Property:weight|9]]
+Many of the editor features, the [[Automatic completion: Introduction|automatic completion]] in particular, can be customized in the preferences.
+Please refer to the [[Editor Preferences|editor section]] of the preferences help for more details.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/history-functionality.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/history-functionality.wiki
new file mode 100644
index 00000000..308fa13e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/history-functionality.wiki
@@ -0,0 +1,13 @@
+[[Property:title|History functionality]]
+[[Property:weight|4]]
+EiffelStudio editor provides an history functionality, i.e. Undo and Redo commands.
+*
+To undo last change, press the key combination "Ctrl+Z", click on the undo icon [[Image:general-undo-icon]] or choose '''Undo''' in the '''Edit''' menu. If you repeat this operation, the editor will undo the last change and so on until there are no more changes to undo.
+
+*
+To redo last undone change, press the key combination "Ctrl+Y", click on the redo icon [[Image:general-redo-icon]] or choose '''Redo''' in the '''Edit''' menu. If you repeat this operation, the editor will redo the last undone change and so on until there are no undone changes left.
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/index.wiki
new file mode 100644
index 00000000..a75bf52d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/index.wiki
@@ -0,0 +1,17 @@
+[[Property:title|EiffelStudio Editor]]
+[[Property:link_title|Editor]]
+[[Property:weight|-12]]
+* [[EiffelStudio Editor Introduction|Introduction]]
+* [[Cursor moves|Cursor moves]]
+* [[Selection|Selection]]
+* [[Clipboard functionality|Clipboard functionality]]
+* [[History functionality|History functionality]]
+* [[Search functionality|Search functionality]]
+* [[Automatic completion|Automatic completion]]
+* [[Operations on text blocks|Operations on text blocks]]
+* [[Edit menu commands|Commands in the edit menu]]
+* [[Editor customization|Customization]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/comment-and-uncomment-lines.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/comment-and-uncomment-lines.wiki
new file mode 100644
index 00000000..0f819ad9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/comment-and-uncomment-lines.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Comment and uncomment lines]]
+[[Property:weight|1]]
+EiffelStudio editor offers the possibility to comment or uncomment several lines at a time.
+*
+The "Comment" command corresponds to the '''Comment''' entry in the '''Advanced''' sub-menu of the [[Edit menu commands| '''Edit''' Menu ]] . It may be called by using the keyboard shortcut "Ctrl+K". Its action is to insert two dashes in front of each [[Selection|selected]] line.
+
+*
+The "Uncomment" command corresponds to the '''Uncomment''' entry in the '''Advanced''' submenu of the [[Edit menu commands| '''Edit''' Menu ]] . It may be called by using the keyboard shortcut "Ctrl+Shift+K". Its action is to remove the two dashes in front of each [[Selection|selected]] line if there are such characters.
+
+
+
+{{note| '''Note''': If there is no selection, these commands will be applied to the current line. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/embed-lines-if-thenend-or-debugend.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/embed-lines-if-thenend-or-debugend.wiki
new file mode 100644
index 00000000..d0c3b2e4
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/embed-lines-if-thenend-or-debugend.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Embed lines in 'if then...end' or in 'debug...end']]
+[[Property:weight|3]]
+=Embed lines in "if then...end" or in "debug...end"=
+
+EiffelStudio editor offers the possibility to embed several lines in "if then...end" or in "debug...end" structures.
+* The first command corresponds to the '''Embed in if''' entry in the '''Advanced''' submenu of the [[Edit menu commands]] [[Edit menu commands| Menu]] . It may be called by using the keyboard shortcut "Ctrl+I" too. Its action is to insert a line with "if then" before the [[Selection|selected]] lines and a line with "end" after those lines. The lines will be indented and the cursor positioned between "if" and "then".
+* The second command corresponds to the '''Embed in debug''' entry in the '''Advanced''' submenu of the [[Edit menu commands]] [[Edit menu commands| Menu]] . It may be called by using the keyboard shortcut "Ctrl+D" too. Its action is to insert a line with "debug" before the [[Selection|selected]] lines and a line with "end" after those lines. The lines will be indented and the cursor positioned after "debug" and "then".
+
+{{note| '''Note''': If there is no selection, these commands will be applied to the current line. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/indent-and-unindent-selection.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/indent-and-unindent-selection.wiki
new file mode 100644
index 00000000..4de5fcad
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/indent-and-unindent-selection.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Indent and un indent selection]]
+[[Property:link_title|Indent and unindent selection]]
+[[Property:weight|2]]
+EiffelStudio editor offers the possibility to indent or unindent selected lines.
+*
+The "Indent" command corresponds to the '''Indent selection''' entry in the '''Advanced''' sub menu of the [[Edit menu commands| '''Edit''' Menu ]] . It may be called by using the keyboard shortcut "Tab". Its action is to insert a tabulation in front of each [[Selection|selected]] line.
+
+*
+The "Unindent" command corresponds to the '''Unindent selection''' entry in the '''Advanced''' sub menu of the [[Edit menu commands| '''Edit''' Menu ]] . It may be called by using the keyboard shortcut "Shift+Tab". Its action is to remove the tabulation in front of each [[Selection|selected]] line if there is such a character.
+
+
+
+{{note| '''Note''': If there is no selection, you may still use the unindent shortcut "Shift+Tab". The command will be applied to the current line.
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/index.wiki
new file mode 100644
index 00000000..9c88a9d6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Operations on text blocks]]
+[[Property:weight|7]]
+* [[Editing text block: Introduction|Introduction]]
+* [[Comment and uncomment lines|Comment and uncomment lines]]
+* [[Indent and un indent selection|Indent and unindent selection]]
+* [[Embed lines in 'if then...end' or in 'debug...end'|Embed lines in "if then...end" or in "debug...end"]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/search-functionality.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/search-functionality.wiki
new file mode 100644
index 00000000..95d3b596
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/search-functionality.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Search functionality]]
+[[Property:weight|5]]
+EiffelStudio editor provides a search functionality. To search an expression in the edited text, you can either use the [[Search tool|Search tool]] or use a set of keyboard accelerators available directly from the editor. From the editor, you can:
+*
+Search the next occurrence of the last searched pattern.
+To do so, press "F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] .
+
+*
+Search the previous occurrence of the last searched pattern.
+To do so, press "Shift+F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] .
+
+*
+Search the next occurrence of the current selected pattern.
+To do so, press "Ctrl+F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] .
+
+*
+Search the previous occurrence of the current selected pattern.
+To do so, press "Ctrl+Shift+F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] .
+
+
+{{seealso| '''See Also'''
+[[Search tool|Search tool]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/selection.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/selection.wiki
new file mode 100644
index 00000000..4e84892f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/selection.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Selection]]
+[[Property:weight|2]]
+In EiffelStudio editor, you can select text by using either the mouse or the keyboard.
+
+To select a text zone with the keyboard, [[Cursor moves|move the cursor]] to one end of the zone. Then press "Shift" and maintain the key pressed until you moved the cursor to the other end of the zone. The selected zone will appear in reverse video. If you want to select the entire text, press "Ctrl" and "A".
+
+{{tip| '''Tip''': You can combine "Ctrl" and "Shift" when using Left and Right arrows to select text word by word }}
+
+If you choose to use the mouse, first [[Cursor moves|position the cursor]] to one end of the text zone you want to select, and click there without releasing the mouse button. Then move the mouse pointer to the other end of the zone and release the button. The selected text is shown in reverse video. If the other end of the zone is not visible, move the mouse pointer out of the edition area as you select text in the direction where the end is. EiffelStudio Editor will start scrolling automatically and will stop as soon as the mouse pointer enters the edition area again.
+
+There are other ways of using the mouse to select text in EiffelStudio editor:
+* You can select a word by double-clicking on it. If you do not release the mouse button after the second click, then you will be able to select a text zone but the bound of the zone will move one word at a time.
+* If you triple click in the edition area, then the pointed line will be selected. If you do not release the mouse button after the third click, you will be able to select text line by line.
+* A quadruple click will select the entire text (this is an option that you can [[Editor Preferences|modify]] in the preferences dialog).
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/index.wiki
new file mode 100644
index 00000000..d19106ec
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|EiffelStudio interface mechanisms]]
+[[Property:weight|0]]
+* [[Pick-and-drop mechanism|Pick-and-drop]]
+* [[Pick-and-drop shortcut|Pick-and-drop shortcut]]
+* [[Toolbar customization|Toolbars customization]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-mechanism.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-mechanism.wiki
new file mode 100644
index 00000000..2a53cc2f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-mechanism.wiki
@@ -0,0 +1,21 @@
+[[Property:title|Pick-and-drop mechanism]]
+[[Property:weight|0]]
+Pick-and-drop is one of Eiffel Software's exclusive technologies and is provided by [[EiffelVision Introduction|Eiffel Vision2]] . In EiffelStudio it allows you to easily send data from a component of the interface to another.
+
+You can pick every reference to a '''development object''' (like a class, a feature or an execution object) with a single click on the '''right''' mouse button. Then as you start moving the mouse around - not pressing any of its buttons - a pebble tracks the cursor position, and a line continuously connects the pebble to the object's original position. The pebble's shape indicates the type of the development object that you picked (oval disk for a class, cross for a feature, folder for a cluster...).
+
+ [[Image:editor-pick-and-drop]]
+
+You may terminate this situation in either of two ways:
+* If the pebble you are dragging is not crossed, you can right-click again to confirm the pick-and-drop and so effectively send the dragged development object to the targeted component. For a class, a droppable pebble looks like this: [[Image:context-class-cursor]]
+Right-clicking when the pebble is crossed will only stop the pick-and-drop because the component you are hovering with the mouse does not accept your development object. For a class, a not droppable pebble looks like this: [[Image:context-disabled-class-cursor]]
+
+* If, for any reason, you change your mind, you can cancel the pick-and-drop by left-clicking anywhere or by pressing the Escape key.
+
+{{seealso| '''See Also'''
+[[Pick-and-drop shortcut|Pick-and-drop shortcut]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-shortcut.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-shortcut.wiki
new file mode 100644
index 00000000..c38eccc7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-shortcut.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Pick-and-drop shortcut]]
+[[Property:weight|1]]
+In the [[EiffelStudio Editor Introduction|editor]] and the [[EiffelStudio window overview|context tool]] , pressing the '''control''' key while right-clicking on a development object opens a new development window which is centered on the clicked object.
+
+{{tip| '''Tip''': The effect of control-picking is now configurable in the [[Preferences Reference|preferences]] . }}
+
+{{seealso| '''See Also'''
+[[Pick-and-drop mechanism|Pick-and-drop mechanism]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/toolbar-customization.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/toolbar-customization.wiki
new file mode 100644
index 00000000..fb5506a8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/toolbar-customization.wiki
@@ -0,0 +1,27 @@
+[[Property:title|Toolbar customization]]
+[[Property:weight|2]]
+It is possible to choose which icons appear in the [[Main toolbars|standard toolbar]] and in the [[Main toolbars|project toolbar]] . To customize the standard toolbar, select '''Customize standard toolbar...''' in the '''Toolbars''' sub-menu of the '''View''' menu. To customize the project toolbar, select '''Customize project toolbar...''' in the same sub-menu.
+In both cases, a toolbar customization window will appear. Two lists of icons are displayed in the window. The list on the right shows the icons that are in the toolbar. The list on the left gathers the icons that are currently not in the toolbar and that may be added. It also contains a separator that may be used to organize icons.
+
+
+
+ [[Image:toolbar-customization-dialog]]
+
+
+To add an icon or a separator to the toolbar, select it in the left list and click on the '''Add ->''' button. It will then be inserted in the right list after the selected item.
+To remove an icon, click on it in the right list and click on '''<- Remove'''.
+
+The order of the icons in the right list is the same as in the toolbar. If you want to move an icon in the list, select it and use '''Up''' and '''Down''' buttons. '''Up''' will move it to the top, i.e. to the left of the toolbar. '''Down''' will move it in the opposite direction.
+
+{{tip| '''Tip''': You can also pick-and-drop icons to organize them. }}
+
+Lastly, some icons can be displayed with an explanatory text. A menu at the bottom of the window will allow you to choose if the text should be displayed. The tables below present the list of these icons for both toolbars and what they look like with and without text.
+
+Once you made the changes you wanted, validate them by clicking on '''OK'''. You can also go back to the initial toolbar layout by clicking on '''C ancel'''.
+
+{{seealso| '''See Also'''
+[[Main toolbars|Toolbars Reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-key-shortcuts.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-key-shortcuts.wiki
new file mode 100644
index 00000000..d00b737a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-key-shortcuts.wiki
@@ -0,0 +1,229 @@
+[[Property:title|EiffelStudio: Key shortcuts]]
+[[Property:weight|3]]
+Many operations in EiffelStudio do not require the use of the mouse. The same effect can be achieved through the keyboard only.
+
+This page gathers all the keyboard shortcuts available in the environment. They are sorted in several categories, depending on their domain of application.
+
+==Editor shortcuts==
+
+===Clipboard shortcuts===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Ctrl+C
+| Copy : Copy selected text into the clipboard.
+|-
+| Ctrl+Ins
+| Equivalent to Ctrl+C.
+|-
+| Ctrl+X
+| Cut: Copy selected text into the clipboard and remove it.
+|-
+| Shift+Del
+| Equivalent to Ctrl+X.
+|-
+| Ctrl+V
+| Paste: Insert clipboard content into the text.
+|-
+| Shift+Ins
+| Equivalent to Ctrl+V.
+|}
+
+
+===Undo/redo shortcuts===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Ctrl+Z
+| Undo last action.
+|-
+| Ctrl+Y
+| Redo last undone action.
+|}
+
+
+===Search shortcuts===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Ctrl+F
+| Display the quick search bar and give the focus to the "Search for..." text field.
+This shortcut may be customized.
+|-
+| Ctrl+H
+| Display the Search tool and give the focus to the "Replace with..." text field.
+This shortcut may be customized.
+|-
+| F3
+| Search the next occurrence of the last searched expression.
+This shortcut may be customized.
+|-
+| Shift+F3
+| Search the previous occurrence the last searched expression.
+This shortcut may be customized.
+|-
+| Ctrl+F3
+| Search the next occurrence of the current selected expression.
+This shortcut may be customized.
+|-
+| Ctrl+Shift+F3
+| Search the previous occurrence the current selected expression.
+This shortcut may be customized.
+|}
+
+
+===Shortcuts to modify selected text===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Tab
+| Indent selection (only if several lines are selected).
+|-
+| Shift+Tab
+| Unindent the selected lines or the current line if there is no selection.
+|-
+| Ctrl+K
+| Comment the selected lines or the current line if there is no selection.
+|-
+| Ctrl+Shift+K
+| Uncomment the selected lines or the current line if there is no selection.
+A line is uncommented only if '--' is at its beginning.
+|-
+| Ctrl+I
+| Embed selection (or the current line if there is no selection)
+in an "if...then...end" structure.
+|-
+| Ctrl+D
+| Embed selection (or the current line if there is no selection)
+in an "debug...end" structure.
+|}
+
+
+===Other shortcuts===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Ctrl+A
+| Select the entire text.
+|-
+| Ctrl+Space
+| Auto-complete current word.
+This shortcut may be customized.
+|}
+
+
+{{note| '''Note''': These shortcuts are not available everywhere. All operations that do not imply changes in the text are available both in the editor and in the class and feature tabs of the context tool. Other operations are available only in the editor. }}
+
+==Compiler==
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| F7
+| Melt the system. This is the standard way to compile a debuggable system.
+|-
+| Alt+F8
+| Look for externally added, unreferenced classes and recompile. This is normally not needed if classes are added in EiffelStudio or if they are referenced by another class that is in the system.
+|-
+| Shift+F8
+| Only check override clusters for changed classes and recompile.
+|-
+| Ctrl+F7
+| Freeze the system. This melts the system and recompile the generated C code.
+|-
+| Ctrl+Shift+F7
+| Finalize the system. This generates an optimized executable which is not debuggable.
+|}
+
+
+==Debugger==
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| F5
+| Run. This is the standard way to run a system and debug it.
+|-
+| Ctrl+F5
+| Run without breakpoints. Same as run except that breakpoints are ignored.
+|-
+| Shift+F5
+| Kill the debugged application
+|-
+| Ctrl+Shift+F5
+| Pause the debugged application.
+|-
+| F11
+| Step into.
+|-
+| F10
+| Step by step.
+|-
+| Shift+F11
+| Step out.
+|}
+
+
+==Miscellaneous==
+
+===File shortcuts===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Ctrl+S
+| Save the file currently edited in the editor.
+|-
+| Ctrl+N
+| Open a new window.
+|}
+
+
+===Editor views shortcuts===
+
+{|
+|-
+| '''Key shortcut'''
+| '''Purpose'''
+|-
+| Ctrl+Shift+T
+| Display the text view in the editor.
+|-
+| Ctrl+Shift+C
+| Display the clickable view in the editor.
+|-
+| Ctrl+Shift+F
+| Display the flat view in the editor.
+|-
+| Ctrl+Shift+O
+| Display the contract view in the editor.
+|-
+| Ctrl+Shift+I
+| Display the flat contract view in the editor.
+|}
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-window-overview.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-window-overview.wiki
new file mode 100644
index 00000000..fa563ced
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-window-overview.wiki
@@ -0,0 +1,73 @@
+[[Property:title|EiffelStudio window overview]]
+[[Property:weight|1]]
+==Window layout==
+
+In EiffelStudio all windows have the same components. However, components to be displayed are chosen by the user. Moreover, windows have two modes: the edition mode and the debug mode. Basically, a standard window looks like this:
+
+[[Image:general-edition-mode]]
+
+As you can see, it is divided in several parts: a top section, a left panel, a right panel and a status bar.
+
+The top part is rather not surprising. It first contains a menu bar, which adapts itself to the context of the current project. It also contains two toolbars (the main toolbar and the project toolbar). Between the toolbars is located the main address bar.
+
+The left panel contains various ''tools'' that help the navigation in the system.
+
+The right panel contains two major tools: the editor and the context tool.
+
+The status bar supplies various information:
+* Its first field gives punctual information concerning a recent operation (such as loading a project, syntax errors in a class text, etc.).
+* The second field contains the name of the current project, which can come quite handy if you work on several projects simultaneously.
+* The next field contains the current line and column in the main editor of the window (lines and columns start at position 1).
+* The last three fields contain icons representing the state of the project, according to several points of view.
+** The first icon indicates whether some class files have been edited since the last compilation. This makes it easy to know whether you have changes to take into account ( [[Image:16x16--general-edit-icon]] ) and whether you should recompile.
+** The second icon gives the compilation state of the project. It may indicate either that the last compilation was successful [[Image:compile-success-icon]] , or that it failed [[Image:compile-error-icon]] or that the project is being compiled [[Image:compile-animation-6-icon]] .
+** The last icon gives the state of the debugger. It may indicate that the application is running [[Image:run-animation-4-icon]] , paused [[Image:debug-pause-icon]] or dead (no icon).
+
+
+In debug mode, a window looks like this:
+
+[[Image:general-debug-mode]]
+
+In debug mode, the same tools are present, but there are three extra tools. Two are located in the left panel, which display respectively the call stack and the dynamic value of expressions. The other is in the right panel and can be used to view the state of objects while debugging.
+
+==Layout configuration==
+
+===Tool configuration===
+
+All tools have similar controls to give their display options. It is possible to minimize, restore and maximize all tools by using the proper button in their top right-hand corner. Most tools can also be closed. These tools have a close button in the corner.
+* The minimize button [[Image:toolbar-minimize-icon]]
+* The maximize button [[Image:toolbar-maximize-icon]]
+* The restore button [[Image:toolbar-restore-icon]]
+* The close button [[Image:toolbar-close-icon]]
+
+Tools that can be closed have a corresponding entry in the '''View/Explorer Bar''' menu. They also have a corresponding button in the main toolbar.
+
+The only tools that cannot be closed are the editor, and when in debug mode the debug tools.
+
+===Toolbar configuration===
+
+Both main toolbars can be customized. This allows to select buttons that should be displayed in the toolbars, as well as whether an explanatory text should be displayed next to icons.
+
+==Context tool==
+
+The context tool, located in the right panel, is a major part of EiffelStudio. It itself contains several tabs that each correspond to some powerful functionality.
+* The '''Output''' tab is where general information and error messages are displayed
+* The '''Diagram''' tab uses the BON notation to analyze and design a project
+* The '''Class''' tab gives advanced information concerning a class
+* The '''Feature''' tab gives advanced information concerning a feature
+* The '''Metrics''' tab provides quantitative information concerning a system or some of its components
+
+By default, the context tool is unlinked from the rest of the window, which means all left tools refer to the object that is in the editor and the main toolbar, while the context tool (and the debug tools if they are present) displays information concerning a different object. It is possible to link the context tool, so that the whole development window displays information relative to the same development object.
+
+{{seealso| '''See Also'''
+[[EiffelStudio: A Guided Tour|EiffelStudio Guided Tour]]
+[[Browsing tools: Introduction|Browsing tools]]
+[[Main toolbars|Toolbar customization]]
+[[EiffelStudio Editor Introduction|Editor reference]]
+[[Formatters: Introduction|Formatted information about compiled classes and features]]
+[[Diagram tool: Introduction|Diagram reference]]
+[[Metric tool: Introduction|Metrics reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/index.wiki
new file mode 100644
index 00000000..4e81b911
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|EiffelStudio: General interface description]]
+[[Property:link_title|General Description]]
+[[Property:weight|-14]]
+* [[EiffelStudio interface mechanisms|General interface mechanisms]]
+* [[EiffelStudio window overview|EiffelStudio window overview]]
+* [[Main toolbars|Main toolbars]]
+* [[EiffelStudio: Key shortcuts|Key shortcuts]]
+* Docking[[Docking| (See EiffelBuild documentation on docking mechanism for more details)]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/main-toolbars.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/main-toolbars.wiki
new file mode 100644
index 00000000..7b9bd26b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/main-toolbars.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Main toolbars]]
+[[Property:weight|2]]
+At the top of a development window, two toolbars are displayed by default. They are separated by [[Main address bar|the address bar]] , which contains class and feature fields and buttons to select the current view. The standard toolbar is above the address bar, the project bar below it:
+ [[Image:main-toolbars]]
+
+You can hide toolbars (or the address bar) by unselecting them in the '''Toolbars''' sub-menu of the '''View''' menu or in the context menu that you can get by right-clicking in the empty space on the right of the bars. If you want them to be displayed again, just select them in the '''Toolbars''' sub-menu of the '''View''' menu.
+
+In the standard toolbar, you will find buttons to manage [[Browsing tools: Introduction|tools]] and windows or that are related to the [[EiffelStudio Editor Introduction|editor]] .
+
+
+{{note| '''Note''': For both toolbars, it is possible to choose which buttons are displayed and which ones are not. See the [[Toolbar customization|Toolbars customization page]] for more information. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/index.wiki
new file mode 100644
index 00000000..57adc8f0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|EiffelStudio Preferences]]
+[[Property:weight|1]]
+* [[EiffelStudio preferences: Introduction|Introduction]]
+* [[Preference window overview|Preferences dialog window]]
+* [[Preferences Reference|Preferences reference]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preference-window-overview.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preference-window-overview.wiki
new file mode 100644
index 00000000..e8f89764
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preference-window-overview.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Preference window overview]]
+[[Property:weight|1]]
+The preferences dialog provide the main table, a filter bar, a the bottom tool bar.
+[[Image:dialogs-and-wizards--preferences-dialog]]
+
+The table is used to display a grid with the preferences displayed in a tree or flat view.
+
+There are several kinds of preferences:
+* Boolean preferences : their possible values are "True" and "False". A check box will allow you to choose between both.
+* Color preferences : Their value is represented by three integers, which are the RGB code of the color. You do not have to use RGB codes though. When you double-click such a preference a color chooser dialog will display, allowing you to change the color value.
+* Font preferences : A font selection window will appear if you double-click the value label.
+* Shortcut preferences : edit the value cell, and press the wanted shortcuts..
+* Other preferences : They will be modified by typing their value directly into an editable text field.
+If there is no message stating you need to restart EiffelStudio, changes will be taken into account immediately.
+{{tip| '''Tip''': below the table, you will find a text field with the internal name of the preference (for instance: ''editor.eiffel.auto-complete_...''). }}
+
+
+{{tip| '''Tip''': you can export preferences to xml file, and import from xml file, this can be convenient when reinstalling EiffelStudio). }}
+
+
+{{warning| '''Caution''': You can restore preferences default values by clicking on the "Restore Default" button. ALL preferences will be reset. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/debugger-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/debugger-preferences.wiki
new file mode 100644
index 00000000..c4665f3d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/debugger-preferences.wiki
@@ -0,0 +1,45 @@
+[[Property:title|Debugger Preferences]]
+[[Property:weight|4]]
+This category contains preferences that are specific to the EiffelStudio Debugger and the debugger tool. These preferences are:
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| Critical stack depth
+| Stack overflow detection: depth of stack at which execution will pause and ask whether it is ok to continue (only works in classic Eiffel).
+|-
+| Debug output evaluation
+| Display DEBUG_OUTPUT.debug_output for objects whose base class inherits from DEBUG_OUTPUT.
+|-
+| Default displayed string size
+| Default number of displayed characters of a STRING (increasing this value might slow down debugging).
+|-
+| Default expanded view size
+| Default number of displayed characters in the expanded view (increasing this value might slow down debugging).
+|-
+| Default maximum stack depth
+| Default number of call stack elements shown in Call Stack tool (-1 to show all of them).
+|-
+| Delay before cleaning objects grid
+| Delay in milliseconds before cleaning the Objects tool view.
+|-
+| Dotnet debugger
+| Which .NET debugger to launch.
+|-
+| Expanded display background color
+| Background color for expanded display view (default is white, change it to better see white spaces in displayed text).
+|-
+| Generating type evaluation
+| Display the base type of an object if enabled, otherwise just the base class (disabling it might speed up debugging).
+|-
+| Interrupt every n instructions
+| Number of instructions that will be executed before interrupting the execution.
+|-
+| Max evaluation duration
+| Number of seconds to wait before cancelling an evaluation.
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/index.wiki
new file mode 100644
index 00000000..c8e6be1c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/index.wiki
@@ -0,0 +1,176 @@
+[[Property:title|Eiffel Editor Preferences]]
+[[Property:weight|2]]
+The Eiffel category under the main Editor category contains preferences for Eiffel specific editor values. For example, here you can customize the behavour of autocompletion in the editor, syntax completion on Eiffel keywords, or the colors of Eiffel keywords.
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| Auto-complete brackets and parenthesis
+| Brackets and parentheses are closed automatically?
+|-
+| Auto-complete quotes
+| Quotes are closed automatically?
+|-
+| Auto auto-complete
+| Auto complete appears automatically?
+|-
+| Auto-complete words
+| Automatically completes words when a single best match is available?
+|-
+| Customized string 1
+| User customized string.
+|-
+| Customized string 2
+| User customized string.
+|-
+| Customized string 3
+| User customized string.
+|-
+| Filter completion list
+| Completion list entries are filtered based on matches?
+|-
+| Once and constant in upper
+| Complete once and constants with a first upper case character?
+|-
+| Show ANY features
+| ANY features appear in the feature call complete window?
+|-
+| Show completion signature
+| Completion list shows feature signatures?
+|-
+| Show completion type
+| Completion list shows return type?
+|-
+| Syntax complete enabled
+| Enable syntax autocomplete?
+|-
+| Text mode is windows
+| Text files format: True = Windows / False = UNIX.
+|-
+| Underscore is separator
+| Underscore ' ' is a word separator?
+|}
+
+==Display Colors==
+
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| Normal text color
+| Foreground color for normal text.
+|-
+| Normal background color
+| Background color for normal text.
+|-
+| Selection text color
+| Foreground color for selected text.
+|-
+| Selection background color
+| Background color for selected text.
+|-
+| String text color
+| Foreground color for manifest strings.
+|-
+| String background color
+| Background color for manifest strings.
+|-
+| Keyword text color
+| Foreground color for keywords.
+|-
+| Keyword background color
+| Background color for keywords.
+|-
+| Spaces text color
+| Foreground color for spaces.
+|-
+| Spaces background color
+| Background color for spaces.
+|-
+| Comments text color
+| Foreground color for comments.
+|-
+| Comments background color
+| Background color for comments.
+|-
+| Number text color
+| Foreground color for numbers.
+|-
+| Number background color
+| Background color for numbers.
+|-
+| Operator text color
+| Foreground color for operators.
+|-
+| Operator background color
+| Background color for operators.
+|-
+| Breakpoint background color
+| Color for breakable marks and breakpoints.
+|-
+| Assertion tag text color
+| Foreground color for assertion tags.
+|-
+| Assertion tag background color
+| Background color for assertion tags.
+|-
+| Indexing tag text color
+| Foreground color for indexing tags.
+|-
+| Indexing tag background color
+| Background color for indexing tags.
+|-
+| Reserved text color
+| Foreground color for reserved words.
+|-
+| Reserved background color
+| Background color for reserved words.
+|-
+| Generic text color
+| Foreground color for generics.
+|-
+| Generic background color
+| Background color for generics.
+|-
+| Local text color
+| Foreground color for locals.
+|-
+| Local background color
+| Background color for locals.
+|-
+| Class text color
+| Foreground color for classes.
+|-
+| Class background color
+| Background color for classes.
+|-
+| Feature text color
+| Foreground color for features.
+|-
+| Feature background color
+| Background color for features.
+|-
+| Cluster text color
+| Foreground color for clusters.
+|-
+| Cluster background color
+| Background color for clusters.
+|-
+| Error text color
+| Foreground color for errors.
+|-
+| Error background color
+| Background color for errors.
+|-
+| Object text color
+| Foreground color for objects.
+|-
+| Object background color
+| Background color for objects.
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/default-values-keyword-completion-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/default-values-keyword-completion-preferences.wiki
new file mode 100644
index 00000000..629fe1d3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/default-values-keyword-completion-preferences.wiki
@@ -0,0 +1,509 @@
+[[Property:title|Default values for keyword completion preferences]]
+[[Property:weight|3]]
+This document contains the description of default completion for recognized keywords. The [[Keyword completion customization|syntax]] used is the one used to redefine keyword completion in the preferences.
+Four tables list default values for each of the [[Keywords automatic completion preferences|four preferences]] attached to each keyword.
+#
+Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Space after keyword was typed)"]]
+
+{| border="1"
+|-
+| '''Keyword'''
+| '''Value'''
+|-
+| indexing
+| "$cursor$"
+|-
+| class
+| "$cursor$"
+|-
+| inherit
+| "$cursor$"
+|-
+| creation
+| "$cursor$"
+|-
+| feature
+| "$cursor$"
+|-
+| is
+| "$cursor$"
+|-
+| require
+| "$cursor$"
+|-
+| require else
+| "$cursor$"
+|-
+| local
+| "$cursor$"
+|-
+| do
+| "$cursor$end"
+|-
+| once
+| "$cursor$end"
+|-
+| deferred
+| "end$cursor$"
+|-
+| external
+| ""$cursor$"end"
+|-
+| rescue
+| "$cursor$"
+|-
+| ensure
+| "$cursor$"
+|-
+| ensure then
+| "$cursor$"
+|-
+| if
+| "$cursor$then%N$indent$%T%N$indent$end"
+|-
+| then
+| "$cursor$"
+|-
+| elseif
+| "$cursor$then%N$indent$%T"
+|-
+| else
+| "$cursor$"
+|-
+| inspect
+| "$cursor$%N$indent$when then%N$indent$%T%N$indent$else%N$indent$%T%N$indent$end"
+|-
+| when
+| "$cursor$then%N$indent$%T"
+|-
+| from
+| "$cursor$%N$indent$until%N$indent$loop%N$indent$end"
+|-
+| variant
+| "$cursor$"
+|-
+| until
+| "$cursor$"
+|-
+| loop
+| "$cursor$"
+|-
+| debug
+| "$cursor$end"
+|-
+| check
+| "$cursor$end"
+|-
+| rename
+| "$cursor$"
+|-
+| redefine
+| "$cursor$"
+|-
+| undefine
+| "$cursor$"
+|-
+| select
+| "$cursor$"
+|-
+| export
+| "$cursor$"
+|-
+| Precursor
+| "{$cursor$}"
+|-
+| create
+| "$cursor$"
+|-
+| obsolete
+| ""$cursor$""
+|-
+| invariant
+| "$cursor$"
+|-
+| end
+| "$cursor$"
+|}
+
+
+#
+Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Return after keyword was typed)"]]
+
+{| border="1"
+|-
+| '''Keyword'''
+| '''Return'''
+|-
+| indexing
+| "%N$indent$%T$cursor$"
+|-
+| class
+| "%N$indent$%T$cursor$"
+|-
+| inherit
+| "%N$indent$%T$cursor$"
+|-
+| creation
+| "%N$indent$%T$cursor$"
+|-
+| feature
+| "%N$indent$%T$cursor$"
+|-
+| is
+| "%N$indent$%T%T--$cursor$"
+|-
+| require
+| "%N$indent$%T$cursor$"
+|-
+| require else
+| "%N$indent$%T$cursor$"
+|-
+| local
+| "%N$indent$%T$cursor$"
+|-
+| do
+| "%N$indent$%T$cursor$%N$indent$end"
+|-
+| once
+| "%N$indent$%T$cursor$%N$indent$end"
+|-
+| deferred
+| "%N$indent$end$cursor$"
+|-
+| external
+| "%N$indent$%T"$cursor$"%N$indent$end"
+|-
+| rescue
+| "%N$indent$%T$cursor$"
+|-
+| ensure
+| "%N$indent$%T$cursor$"
+|-
+| ensure then
+| "%N$indent$%T$cursor$"
+|-
+| if
+| "%N$indent$%T$cursor$%N$indent$then%N$indent$%T%N$indent$end"
+|-
+| then
+| "%N$indent$%T$cursor$"
+|-
+| elseif
+| "%N$indent$%T$cursor$%N$indent$then%N$indent$%T"
+|-
+| else
+| "%N$indent$%T$cursor$"
+|-
+| inspect
+| "%N$indent$%T$cursor$%N$indent$when then%N$indent$%T%N$indent$else%N$indent$%T%N$indent$end"
+|-
+| when
+| "%N$indent$%T$cursor$%N$indent$then%N$indent$%T"
+|-
+| from
+| "%N$indent$%T$cursor$%N$indent$until%N$indent$%T%N$indent$loop%N$indent$%T%N$indent$end"
+|-
+| variant
+| "%N$indent$%T$cursor$"
+|-
+| until
+| "%N$indent$%T$cursor$"
+|-
+| loop
+| "%N$indent$%T$cursor$"
+|-
+| debug
+| "%N$indent$%T$cursor$%N$indent$end"
+|-
+| check
+| "%N$indent$%T$cursor$%N$indent$end"
+|-
+| rename
+| "%N$indent$%T$cursor$"
+|-
+| redefine
+| "%N$indent$%T$cursor$"
+|-
+| undefine
+| "%N$indent$%T$cursor$"
+|-
+| select
+| "%N$indent$%T$cursor$"
+|-
+| export
+| "%N$indent$%T$cursor$"
+|-
+| Precursor
+| "%N$indent$%T$cursor$"
+|-
+| create
+| "%N$indent$%T$cursor$"
+|-
+| obsolete
+| "%N$indent$%T"$cursor$""
+|-
+| invariant
+| "%N$indent$%T$cursor$"
+|-
+| end
+| "%N$indent$$cursor$"
+|}
+
+
+#
+Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Space, other cases)"]]
+
+{| border="1"
+|-
+| '''Keyword'''
+| '''Space'''
+|-
+| indexing
+| "$cursor$"
+|-
+| class
+| "$cursor$"
+|-
+| inherit
+| "$cursor$"
+|-
+| creation
+| "$cursor$"
+|-
+| feature
+| "$cursor$"
+|-
+| is
+| "$cursor$"
+|-
+| require
+| "$cursor$"
+|-
+| require else
+| "$cursor$"
+|-
+| local
+| "$cursor$"
+|-
+| do
+| "$cursor$"
+|-
+| once
+| "$cursor$"
+|-
+| deferred
+| "$cursor$"
+|-
+| external
+| "$cursor$"
+|-
+| rescue
+| "$cursor$"
+|-
+| ensure
+| "$cursor$"
+|-
+| ensure then
+| "$cursor$"
+|-
+| if
+| "$cursor$"
+|-
+| then
+| "$cursor$"
+|-
+| elseif
+| "$cursor$"
+|-
+| else
+| "$cursor$"
+|-
+| inspect
+| "$cursor$"
+|-
+| when
+| "$cursor$"
+|-
+| from
+| "$cursor$"
+|-
+| variant
+| "$cursor$"
+|-
+| until
+| "$cursor$"
+|-
+| loop
+| "$cursor$"
+|-
+| debug
+| "$cursor$"
+|-
+| check
+| "$cursor$"
+|-
+| rename
+| "$cursor$"
+|-
+| redefine
+| "$cursor$"
+|-
+| undefine
+| "$cursor$"
+|-
+| select
+| "$cursor$"
+|-
+| export
+| "$cursor$"
+|-
+| Precursor
+| "$cursor$"
+|-
+| create
+| "$cursor$"
+|-
+| obsolete
+| "$cursor$"
+|-
+| invariant
+| "$cursor$"
+|-
+| end
+| "$cursor$"
+|}
+
+
+#
+Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Return, other cases)"]]
+
+{| border="1"
+|-
+| '''Keyword'''
+| '''Return'''
+|-
+| indexing
+| "%N$indent$$cursor$"
+|-
+| class
+| "%N$indent$$cursor$"
+|-
+| inherit
+| "%N$indent$$cursor$"
+|-
+| creation
+| "%N$indent$$cursor$"
+|-
+| feature
+| "%N$indent$$cursor$"
+|-
+| is
+| "%N$indent$$cursor$"
+|-
+| require
+| "%N$indent$$cursor$"
+|-
+| require else
+| "%N$indent$$cursor$"
+|-
+| local
+| "%N$indent$$cursor$"
+|-
+| do
+| "%N$indent$$cursor$"
+|-
+| once
+| "%N$indent$$cursor$"
+|-
+| deferred
+| "%N$indent$$cursor$"
+|-
+| external
+| "%N$indent$$cursor$"
+|-
+| rescue
+| "%N$indent$$cursor$"
+|-
+| ensure
+| "%N$indent$$cursor$"
+|-
+| ensure then
+| "%N$indent$$cursor$"
+|-
+| if
+| "%N$indent$$cursor$"
+|-
+| then
+| "%N$indent$$cursor$"
+|-
+| elseif
+| "%N$indent$$cursor$"
+|-
+| else
+| "%N$indent$$cursor$"
+|-
+| inspect
+| "%N$indent$$cursor$"
+|-
+| when
+| "%N$indent$$cursor$"
+|-
+| from
+| "%N$indent$$cursor$"
+|-
+| variant
+| "%N$indent$$cursor$"
+|-
+| until
+| "%N$indent$$cursor$"
+|-
+| loop
+| "%N$indent$$cursor$"
+|-
+| debug
+| "%N$indent$$cursor$"
+|-
+| check
+| "%N$indent$$cursor$"
+|-
+| rename
+| "%N$indent$$cursor$"
+|-
+| redefine
+| "%N$indent$$cursor$"
+|-
+| undefine
+| "%N$indent$$cursor$"
+|-
+| select
+| "%N$indent$$cursor$"
+|-
+| export
+| "%N$indent$$cursor$"
+|-
+| Precursor
+| "%N$indent$$cursor$"
+|-
+| create
+| "%N$indent$$cursor$"
+|-
+| obsolete
+| "%N$indent$$cursor$"
+|-
+| invariant
+| "%N$indent$$cursor$"
+|-
+| end
+| "%N$indent$$cursor$"
+|}
+
+
+
+{{seealso| '''See Also'''
+[[Keywords automatic completion preferences|Keywords automatic completion preferences]]
+[[Keyword completion customization|Keyword completion customization]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/index.wiki
new file mode 100644
index 00000000..c1313189
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Syntax automatic completion preferences]]
+[[Property:weight|-1]]
+* [[EiffelStudio preferences for Automatic completion: Introduction|Introduction]]
+* [[Keywords automatic completion preferences|Keywords automatic completion preferences]]
+* [[Keyword completion customization|Keyword completion customization]]
+* [[Default values for keyword completion preferences|Default values for keyword completion preferences]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keyword-completion-customization.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keyword-completion-customization.wiki
new file mode 100644
index 00000000..7e83d92c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keyword-completion-customization.wiki
@@ -0,0 +1,78 @@
+[[Property:title|Keyword completion customization]]
+[[Property:weight|2]]
+This document describes the syntax used to customize keyword automatic completion.
+[[Keywords automatic completion preferences|Four strings]] are used to define the completion of a keyword. The rules are the same for all of them:
+*
+These strings will be inserted right after the keyword. The key that triggers the automatic completion will not be taken into account, i.e. no space or "new line" character will be inserted even though you press Return or Space. The strings should therefore begin with a space or a "new line" character (see below for "newline").
+
+*
+Two reserved words will allow you to position the cursor and to indent the text properly. Insert the word ''$cursor$'' in the string where you want the cursor to be moved once the completion is finished. Insert the word ''$indent$'' where you want to copy as many blank spaces as there were on the line where the keyword was typed.
+
+*
+Three special characters are available:
+** ''%N'' represents the new line character.
+** ''%T'' represents the tabulation
+** ''%B'' represents the back space
+
+
+
+
+Examples :
+#
+You want the lines of code :
+
+''if''
+next_line_of_code
+
+to become:
+''if'' ''then''
+
+''end''
+next_line_of_code
+
+
+as you press Space just after typing ''if''. You should define the "Customized auto complete (Space after keyword was typed)" string for ''if'' as :
+
+" $cursor$ then%N$indent$%T%N$indent$end"
+
+First, EiffelStudio editor has to insert a blank space after ''if''. The string begins therefore by a blank space.
+Then, ''$cursor$'' tells EiffelStudio to move the cursor to this position after the completion.
+''then'' is inserted after the cursor position.
+''%N'' indicates that you want to insert a new line after ''then''.
+''$indent$%T'' means that this line is filled with as many blank spaces as there are before ''if'' plus a tabulation.
+Another line is inserted with ''%N''.
+Then ''$indent$end'' means that ''end'' will be inserted in this new line with the same indentation as ''if''.
+
+#
+You want the lines of code :
+
+''end''
+next_line_of_code
+
+to become:
+
+''end''
+
+next_line_of_code
+
+as you press Return just after typing ''end''. You should define the "Customized auto complete (Return after keyword was typed)" string for ''end'' as :
+
+"%B%B%B%Bend%N$indent$%B$cursor$"
+
+The four ''%B'' will remove ''end'' plus one character before ''end'' (the tabulation character).
+''end'' will be inserted at this new position.
+''%N'' indicates that you want to insert a new line.
+''$indent$%B$cursor$'' means that the cursor will be moved to the end of the line where one less blank space than before the original ''end'' will have been inserted.
+
+
+{{note| '''Note''': EiffelStudio editor can insert spaces instead of tabulation when you use special character ''%T''. This is set in [[General Editor Preferences|another section of the preferences]] .
+}}
+
+{{seealso| '''See Also'''
+[[Keywords automatic completion preferences|Keywords automatic completion preferences]]
+[[Default values for keyword completion preferences|Default values for keyword completion preferences]]
+}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keywords-automatic-completion-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keywords-automatic-completion-preferences.wiki
new file mode 100644
index 00000000..1860de26
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keywords-automatic-completion-preferences.wiki
@@ -0,0 +1,78 @@
+[[Property:title|Keywords automatic completion preferences]]
+[[Property:weight|1]]
+==Description==
+
+Keywords completion preferences can be found in the subdirectories of "Automatic completion" (located in "Editor" ->"Eiffel"). Keywords are located in subdirectories as described below :
+* Class structure keywords:
+** class
+** creation
+** feature
+** indexing
+** inherit
+
+* Feature structure keywords
+** is
+** require
+** require else
+** local
+** do
+** deferred
+** external
+** rescue
+** ensure
+** ensure then
+
+* Control structures keywords
+** if
+** then
+** elseif
+** else
+** inspect
+** when
+** from
+** variant
+** until
+** loop
+** debug
+** check
+
+* Inherit clauses keywords
+** rename
+** redefine
+** undefine
+** select
+** export
+
+* Other keywords
+** Precursor
+** create
+** obsolete
+** invariant
+** end
+
+
+==Usage==
+
+A directory is associated with each keyword. These directories contains six items which you may modify to customize the automatic completion of the keyword:
+*
+Autocomplete : If this is set to True, the automatic completion will be triggered when you type the keyword in the editor. If it is set to False, the keyword will be processed as a normal word.
+
+*
+Use default autocomplete: If this is set to True, the next preferences will be ignored and the default completion scheme will be used. Otherwise, the automatic completion will use the user-defined strings described below.
+
+*
+Customized autocomplete (Return after keyword was typed): This [[Keyword completion customization|string]] defines what will be inserted as you press Return just after typing the keyword if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above).
+
+*
+Customized autocomplete (Space after keyword was typed): This [[Keyword completion customization|string]] defines what will be inserted as you press Space just after typing the keyword if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above).
+
+*
+Customized autocomplete (Return, other cases): This [[Keyword completion customization|string]] defines what will be inserted as you press Return after a keyword which had been previously typed. It is effective only if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above).
+
+*
+Customized autocomplete (Space, other cases): This [[Keyword completion customization|string]] defines what will be inserted as you press Space after a keyword which had been previously typed. It is effective only if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above).
+
+The syntax used in the four last item is described in [[Keyword completion customization|Keyword completion customization]] . [[Default values for keyword completion preferences|Default values]] are accessible in Keyword completion default values.
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/general-editor-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/general-editor-preferences.wiki
new file mode 100644
index 00000000..994f31f2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/general-editor-preferences.wiki
@@ -0,0 +1,118 @@
+[[Property:title|General Editor Preferences]]
+[[Property:weight|1]]
+General Preferences
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| Automatic update
+| Automatic update when the file has not been modified.
+|-
+| Blinking cursor
+| Does text cursor blink?
+|-
+| Editor font
+| All-purpose editor font.
+|-
+| Keyword font
+| Keyword editor font.
+|-
+| Left margin width
+| Width of left margin in editor. Note: this is not the breakpoint margin, but the whitespace to the left of the editor.
+|-
+| Mouse wheel scroll full page
+| Mouse wheel scroll full page?
+|-
+| Mouse wheel scroll size
+| Mouse wheel scroll size.
+|-
+| Quadruple click enabled
+| Does a quadruple click select the entire document?
+|-
+| Scrolling common line count
+| Number of common lines staying on screen after scrolling by one page up or down.
+|-
+| Show line numbers
+| Indicates if editor displays the line numbers by default.
+|-
+| Smart indentation
+| Should editor perform auto-indenting?
+|-
+| Tab step
+| Number of spaces that a tabulation character represents.
+|-
+| Use buffered line
+| Indicates if editor line drawing is first buffered and then drawn, or just drawn directly to the screen. If true scrolling will be smoother, but performance will be slower.
+|-
+| Use tab for indentation
+| Should tab character be used for auto-indentation?
+|}
+
+Display Colors
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| colors.normal_text_color
+| Color for normal text.
+|-
+| colors.normal_background_color
+| Background color for normal text.
+|-
+| colors.selection_text_color
+| Color of selected text.
+|-
+| colors.selection_background_color
+| Background color of selected text.
+|-
+| colors.string_text_color
+| Color of string text.
+|-
+| colors.string_background_color
+| Background color of string text.
+|-
+| colors.keyword_text_color
+| Color of keyword text.
+|-
+| colors.keyword_background_color
+| Background color of keyword text.
+|-
+| colors.spaces_text_color
+| Color of space characters.
+|-
+| colors.spaces_background_color
+| Background color of space characters.
+|-
+| colors.comments_text_color
+| Color of comments text.
+|-
+| colors.comments_background_color
+| Background color of comments text.
+|-
+| colors.operator_text_color
+| Color of operator text.
+|-
+| colors.operator_background_color
+| Background color of operator text.
+|-
+| colors.number_text_color
+| Color of number text.
+|-
+| colors.number_background_color
+| Background color of number text.
+|-
+| colors.margin_background_color
+| Background color of line number margin.
+|-
+| colors.margin_separator_color
+| Color of separator between line number margin and editor.
+|-
+| colors.line_number_text_color
+| Color of line number text.
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/index.wiki
new file mode 100644
index 00000000..ca67d7b3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Editor Preferences]]
+[[Property:weight|3]]
+* [[EiffelStudio preferences for Editor: Introduction|Introduction]]
+* [[General Editor Preferences|General preferences]]
+* [[Eiffel Editor Preferences|Eiffel Specific preferences]]
+* [[Keyboard shortcuts preferences|User-definable keyboard shortcuts]]
+* [[Syntax automatic completion preferences|Syntax Autocompetion]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/keyboard-shortcuts-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/keyboard-shortcuts-preferences.wiki
new file mode 100644
index 00000000..edfbf15e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/keyboard-shortcuts-preferences.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Keyboard shortcuts preferences]]
+[[Property:weight|2]]
+Some of the keyboard shortcuts used in the editor can be customized. A subfolder of the"Keyboard Shortcuts" folder in the editor preferences corresponds to each of these customizable shortcuts. There are four values to set to define a shortcut: which key must be pressed and whether Ctrl, Alt or Shift have to be pressed at the same time. You will find a combination of all in each shortcut subfolder. The customizable shortcuts are:
+* Autocomplete: Shortcut to trigger the feature call automatic completion. The default key combination is "Ctrl+Space".
+* Class name autocomplete: Shortcut to trigger the class name automatic completion. The default key combination is "Ctrl+Shift+Space".
+* Search selection: Shortcut to launch a search of the currently selected item. If there is no selected item, the editor will look for the next occurrence of the last searched pattern. The default key combination for this command is "F3".
+* Search again: Shortcut to move to the next occurrence of the searched pattern. If the shortcut is the same as for Search Selection, the effect of the command will be to search for the next occurrence of the currently searched pattern unless something else is selected in the editor. In that case, the editor will look for the next occurrence of the selected text. The default key combination for this command is"F3".
+* Search backwards: Shortcut to move to the previous occurrence of the searched pattern. The default key combination for this command is "Shift+F3".
+* Show search panel: Shortcut to make the search panel appear if it is not displayed and to give the focus to the "Search for" field. The default key combination for this command is "Ctrl+F".
+* Show search and replace panel: Shortcut to make the search panel with the"Replace with" field appear if it is not displayed. The focus will be given to the "Search for" field. The default key combination for this command is"Ctrl+H".
+
+'''Caution''':
+You should not use combinations made of only "Alt" and another key as they are reserved for menu shortcuts.
+
+'''Tips''':
+On the other hand, you may use combinations made of only a key to create very fast shortcuts, for example with the function keys.
+To know what string corresponds to a given key, you can look up in the EV_KEY_CONSTANTS of EiffelVision2.The `key_strings' table links keys with a string representation.
+
+There are three other categories in the shortcut preferences. These can be used to automatically insert a user-defined string in the editor. If you find yourself typing some strings very often, these preferences can be handy.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/context-tools.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/context-tools.wiki
new file mode 100644
index 00000000..d888c58f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/context-tools.wiki
@@ -0,0 +1,109 @@
+[[Property:title|Context Tools]]
+[[Property:weight|1]]
+This category gathers the preferences related to context tools.
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| Default class formatter index
+| Class view format that is selected by default (see table below for available format indexes).
+|-
+| Default feature formatter index
+| Feature view format that is selected by default (see table below for available format indexes).
+|-
+| Excluded indexing items
+| Indexing items that need not be included in formatted texts.
+|-
+| Formatters history size
+| Number of cached formatted text in history.
+|-
+| Show all callers
+| Show all callers (as opposed to local callers) in `callers' form.
+|}
+
+Class views indices:
+{| border="1"
+|-
+| '''Index'''
+| '''Class view'''
+|-
+| 1
+| Clickable view
+|-
+| 2
+| Flat view
+|-
+| 3
+| Contract view
+|-
+| 4
+| Interface view
+|-
+| 5
+| Ancestors
+|-
+| 6
+| Descendants
+|-
+| 7
+| Clients
+|-
+| 8
+| Suppliers
+|-
+| 9
+| Attributes
+|-
+| 10
+| Routines
+|-
+| 11
+| Deferred features
+|-
+| 12
+| Once routines and constants
+|-
+| 13
+| External features
+|-
+| 14
+| Exported features
+|}
+
+
+Feature views indices:
+{| border="1"
+|-
+| '''Index'''
+| '''Feature view'''
+|-
+| 1
+| Basic text view
+|-
+| 2
+| Flat view
+|-
+| 3
+| Callers
+|-
+| 4
+| Implementers
+|-
+| 5
+| Ancestor versions
+|-
+| 6
+| Descendants versions
+|-
+| 7
+| Homonyms
+|}
+
+
+{{seealso| '''See Also'''
+[[EiffelStudio Tools Preferences|Preferences for other tools]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/eiffelstudio-diagram-tool-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/eiffelstudio-diagram-tool-preferences.wiki
new file mode 100644
index 00000000..f11d6f23
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/eiffelstudio-diagram-tool-preferences.wiki
@@ -0,0 +1,174 @@
+[[Property:title|EiffelStudio Diagram Tool Preferences]]
+[[Property:weight|2]]
+This category gathers the preferences related to the EiffelStudio BON Diagram tool. Preferences for BON notation are under the 'Bon' category and for UML notation are under the 'UML' category.
+==General Preferences==
+
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete description'''
+|-
+| Ancestor depth
+| Show ancestors of a class up to a level of preference value.
+|-
+| Autoscroll speed
+| Color for UML inheritance links.
+|-
+| Client depth
+| Show clients of a class up to a level of preference value.
+|-
+| Descendant depth
+| Show descendants of a class down to a level of preference value.
+|-
+| Excluded class figures
+| Names of classes that should not appear in generated diagrams.
+|-
+| Ignore excluded class figures
+| Show ALL classes in the diagram (ignore the following list)?
+|-
+| Subcluster depth
+| Show subclusters of a cluster down to a level of preference value.
+|-
+| Supercluster depth
+| Show superclusters of a cluster up to a level of preference value.
+|-
+| Supplier depth
+| Show suppliers of a class up to a level of preference value.
+|}
+
+==BON Preferences==
+
+{| border="1"
+|-
+| Bon class name font
+| Font for class names in BON class figures.
+|-
+| Bon class name color
+| Color for class names in BON class figures.
+|-
+| Bon class fill color
+| Color for BON class figures.
+|-
+| Bon class uncompiled fill color
+| Color for uncompiled BON class figures.
+|-
+| Bon class generics font
+| Font for generics in BON class figures.
+|-
+| Bon class generics color
+| Color for generics in BON class figures.
+|-
+| Bon client label font
+| Font for feature names on BON client supplier links.
+|-
+| Bon client label color
+| Color for feature names on BON client supplier links.
+|-
+| Bon client color
+| Color for BON client supplier links.
+|-
+| Bon client line width
+| Line width for BON client supplier links.
+|-
+| Bon cluster line color
+| Color for BON cluster line.
+|-
+| Bon cluster iconified fill color
+| Iconified BON Cluster fill color.
+|-
+| Bon cluster name area color
+| BON cluster name area fill color.
+|-
+| Bon cluster name color
+| BON cluster name color.
+|-
+| Bon cluster name font
+| BON cluster name font.
+|-
+| Bon inheritance color
+| Color for BON inheritance links.
+|-
+| Bon inheritance line width
+| Line width for BON inheritance links.
+|}
+
+==UML Preferences==
+
+{| border="1"
+|-
+| Uml class name font
+| Font for class names in UML class figures.
+|-
+| uml class deferred font
+| Font for names of deferred classes in UML class figures.
+|-
+| Uml class properties font
+| Font for class properties in UML class figures.
+|-
+| Uml class properties color
+| Color for class properties in UML class figures.
+|-
+| Uml class name color
+| Color for class names in UML class figures.
+|-
+| Uml class fill color
+| Color for UML class figures.
+|-
+| Uml generics font
+| Font for generics in UML class figures.
+|-
+| Uml generics color
+| Color for generics in UML class figures.
+|-
+| Uml class features font
+| Font for class features in UML class figures.
+|-
+| Uml class features color
+| Color for class features in UML class figures.
+|-
+| Uml class feature section font
+| Font for class feature sections in UML class figures.
+|-
+| Uml class feature section color
+| Color for class feature sections in UML class figures.
+|-
+| Uml client line width
+| Line width for UML client supplier links.
+|-
+| Uml client color
+| Color for UML client supplier links.
+|-
+| Uml client label color
+| Color for feature names on UML client supplier links.
+|-
+| Uml client label font
+| Font for feature names on UML client supplier links.
+|-
+| Uml cluster line color
+| Color for UML cluster line.
+|-
+| Uml cluster iconified fill color
+| Iconified UML Cluster fill color.
+|-
+| Uml cluster name area color
+| UML cluster name area fill color.
+|-
+| Uml cluster name color
+| UML cluster name color.
+|-
+| Uml cluster name font
+| UML cluster name font.
+|-
+| Uml inheritance line width
+| Line width for UML inheritance links.
+|-
+| Uml inheritance color
+| Color for UML inheritance links.
+|}
+
+{{seealso| '''See Also'''
+[[EiffelStudio Tools Preferences|Preferences for other tools]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/index.wiki
new file mode 100644
index 00000000..3b775f88
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|EiffelStudio Tools Preferences]]
+[[Property:weight|2]]
+* [[EiffelStudio preferences for Tools: Introduction|Introduction]]
+* [[Context Tools|Context tools]]
+* [[EiffelStudio Diagram Tool Preferences|Diagram Tool]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/general-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/general-preferences.wiki
new file mode 100644
index 00000000..3c214596
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/general-preferences.wiki
@@ -0,0 +1,21 @@
+[[Property:title|General Preferences]]
+[[Property:weight|0]]
+This category gathers non graphical and general preferences that are not related to a tool in particular. These preferences are:
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete description'''
+|-
+| Acrobat Reader
+| Command to read Adobe Acrobat files.
+|-
+| Shell command
+| You may open a class in an external editor by dropping the corresponding pebble on the external editor icon. This preference sets which command line will be used to launch the external editor. The parameter "$target"will be replaced in the command with the file name corresponding to the class, "$line" with the line number if this information is relevant, with 1 otherwise.
+|-
+| Internet browser (GTK platforms only)
+| This sets the command line that should be used to open an internet browser on a given HTML page. If present, "$url" will be replaced with the URL of the HTML page. This is used to display help files.
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/index.wiki
new file mode 100644
index 00000000..80729e58
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Preferences Reference]]
+[[Property:weight|2]]
+The top level preference categories for EiffelStudio preferences are listed below.
+* [[General Preferences|General]]
+* [[Interface|Interface]]
+* [[EiffelStudio Tools Preferences|Tools ]]
+* [[Editor Preferences|Editor]]
+* [[Debugger Preferences|Debugger]]
+* [[Recent Project Preferences|Recent Projects]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/development-window-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/development-window-preferences.wiki
new file mode 100644
index 00000000..23dd6fff
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/development-window-preferences.wiki
@@ -0,0 +1,66 @@
+[[Property:title|Development Window Preferences]]
+[[Property:weight|1]]
+This category gathers a list of preferences related to the development window in EiffelStudio.
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete Description'''
+|-
+| Class completion
+| Allow class name completion in the address combo boxes?
+|-
+| Ctrl right click receiver
+| Receivers of control-right-click.
+|-
+| Dock tracking
+| Docked tools track main window?
+|-
+| Editor left side
+| Display editor on left? (Requires restart)
+|-
+| Expand feature tree
+| Automatically expand the feature tree.
+|-
+| Feature clause order
+| Order used to sort feature clauses in formatted texts.
+|-
+| Graphical output disabled
+| Disable graphical output?
+|-
+| Left panel use explorer style
+| Show only one tool (Features, Clusters, Search, Windows) at a time. (Requires restart)
+|-
+| Maximum history size
+| Maximum number of items displayed in the history combo boxes.
+|-
+| Progress bar color
+| Color for progress bar.
+|-
+| Remember completion list size
+| Should size of completion list be remembered between completions in the editor?
+|-
+| Search tool show_options
+| Should search tool be shown?
+|-
+| Show address toolbar
+| Should address toolbar be shown?
+|-
+| Show all text in general toolbar
+| Is text of toolbar items displayed?
+|-
+| Show general_toolbar
+| Should general toolbar be shown?
+|-
+| Show project toolbar
+| Should project toolbar be shown?
+|-
+| Show text in general_toolbar
+| Should text be shown in general toolbar?
+|-
+| Unified stone
+| Link the context tool with other components by default?
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/discardable-dialogs.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/discardable-dialogs.wiki
new file mode 100644
index 00000000..52ca1278
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/discardable-dialogs.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Discardable dialogs]]
+[[Property:weight|2]]
+Some dialogs in EiffelStudio include a check box labeled "Do not show me again". If you select it, the dialog will not be shown the next time the same situation occurs. The "dialogs" sub-category of "Interface" in the preferences lists the state of those discardable dialogs: a boolean preference is associated with each of them. The window will be shown if and only if the corresponding preference is set to True.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/index.wiki
new file mode 100644
index 00000000..3d4bd5cc
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Interface]]
+[[Property:weight|1]]
+* [[EiffelStudio preferences for Interface: Introduction|Introduction]]
+* [[Preferences Reference|EiffelStudio development window preferences]]
+* [[Discardable dialogs|Discardable dialog windows]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/recent-project-preferences.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/recent-project-preferences.wiki
new file mode 100644
index 00000000..3476d93d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/recent-project-preferences.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Recent Project Preferences]]
+[[Property:weight|5]]
+This category gathers a list of recently opened projects in EiffelStudio. It also let's you decide how many recently opened projects to store in the list:
+{| border="1"
+|-
+| '''Label in the preferences window'''
+| '''Complete description'''
+|-
+| Keep n projects
+| This integral preference defines the maximum number of entries that should be displayed in the '''File/Recent projects''' menu.
+|-
+| Last opened projects
+| A semi-colon separated list of the actual recently opened project
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/debug-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/debug-options.wiki
new file mode 100644
index 00000000..bd28698a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/debug-options.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Debug Options]]
+[[Property:weight|6]]
+[[Image:debug-options|Debug dialog]]
+* Enabled: globally enabled/disable debugs.
+* Unnamed Debugs: debug clauses without a name
+* Named Debugs: if the system is compiled, an entry for each name in a debug appears and can be enabled/disabled.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/externals-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/externals-options.wiki
new file mode 100644
index 00000000..6c953c0a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/externals-options.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Externals Options]]
+[[Property:weight|7]]
+[[Image:external-options|Externals dialog]]
+
+In most cases this is not needed but for some C/C++ externals and in some .NET projects it is necessary to specify additional includes, objects or resources.
+
+If you use a library, externals of this library are automatically included. E.g. if you use vision2 the externals for vision2 don't need to be added to the project itself.
+* Include: This is where you can enter the location of the directories where the C/C++ compiler will look for the header files that are required. The header files which the C/C++ compiler will look for are the ones that appear in an encapsulation of a C/C++ external in an Eiffel class. Click [[External features: Introduction|here]] to have more information about C/C++ externals specification.
+* Object: additional C/C++ object files
+* Library: like object files, but will be added last, needed for some very strict C compilers
+* Makefile: additional makefiles, if possible use tasks instead
+*
+Resource: .NET resources
+** The .resx resource file format is a XML based format to include objects (such as images and other binary formats) and strings.
+** The .txt resource file format can only contains strings.
+
+Externals have three properties:
+* Location: location of the external, will be copied verbatim into the makefile
+* Description: an optional description about the external
+* Condition: allows the same configuration with externals to work in different situations (e.g. windows and unix) (see [[General Target Options|conditions]] )
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/index.wiki
new file mode 100644
index 00000000..aad03a26
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/index.wiki
@@ -0,0 +1,187 @@
+[[Property:title|Advanced Options]]
+[[Property:weight|4]]
+[[Image:advanced-options|Advanced dialog]]
+* Address Expression: lets you pass ` '''$(s.to_c)'''' to a feature instead of declaring `a' of type '''ANY''', and then assigning ` '''s.to_c'''' to `a' and passing ` '''$a''''. Turn this option on only if you have advanced knowledge of the garbage collector insides, since using this syntax illegally can lead to bugs very hard to trace.
+* Automatic Backup: generate a backup of the class and configuration files during recompilation?
+* Check VAPE: Enforce VAPE validity constraint: lets you disable type checking for VAPE errors in preconditions, which correspond to insufficiently exported features used in preconditions (ETL 2nd edition page 122).
+* Console Application: has no effect on Unix systems. It lets Windows users choose between creating a console application or a GUI application (in which case a console will be created if needed, instead of using the console the program was launched from).
+* Dead Code Removal: should unused code be removed? (C code generation mode only)
+* Dynamic Runtime: makes the generated executable use a shared library version of the runtime on both Windows (DLL) and Unix platforms (.so) that supports shared libraries.(C code generation mode only)
+
+{{note| '''Note''': On Windows, the dynamic run-time is available only if you compile with the Microsoft Visual compiler. }}
+* Enforce unique class names: enforce all class names to be system wide unique?
+* Exception Trace: makes it possible to see a complete exception trace in a finalized application. Because it is adding some code to remember where the application was during the crash it can slow down the performance of your application by a factor of 5% to 30% depending of your platform. (C code generation mode only)
+* Inlining, Inlining Size: enables inlining on Eiffel features that can be inlined, i.e. whose size is less or equal to the specified size in the combo box. The size value given in parameter corresponds to the number of instructions as seen by the Eiffel compiler (for example a := b.f corresponds to 2 instructions). The inlining is very powerful since it can inline a function in all your Eiffel code, without scope limitation as found in C or C++ compilers. (C code generation mode only)
+* Multithreaded: generates a multithreaded application. This option cannot be changed during the development of your project and has to be set correctly at the first compilation of your system. (C code generation mode only)
+* Old Verbatim Strings: Use the old format for verbatim strings
+* Platform: override platform value used for checking conditions, useful for cross compilation
+* Shared Library Definition: lets you specify a `file_name.def' as the file where the Eiffel compiler will look when it tries to generate the exported functions of the shared library you are developing (C code generation mode only). To have more information concerning definition files, see the [[Dynamic library generation: Introduction|Dynamic library builder reference]] .
+* Library Root: Absolute path to use as base for relative paths. If this is not defined, the path to the configuration file will be used.
+
+==.NET Options==
+* Use Optimized Precompile: use an optimized version of a precompile
+* Use Cluster Name as Namespace: See [[Advanced Options|Class and feature naming]]
+* Use Recursive Cluster Name as Namespace: See [[Advanced Options|Class and feature naming]]
+* .NET Naming Convention: See [[Advanced Options|Class and feature naming]]
+* IL Verifiable: in the .NET world, verifiability is important. This is the only way to ensure that an application is not going to crash or to crash your system by accessing not authorized memory locations. Due to some semantic differences between Eiffel and.NET, our code generation is not always verifiable for performance reasons. If you want your code to be verifiable, you need to select this option. The compiler will then generate a code that will be slightly slower.
+* CLS Compliant: mark generated assemblies as CLS compliant
+* Metadata Cache Path: Location where information about external assemblies is stored.
+* Classes per Module: Number of classes generated per .NET module during incremental compilation. Increasing this value will slow down the incremental recompilation, but speed up the time to load the assembly while debugging in workbench mode.
+* .NET Runtime Version: .NET version to use
+* Generation Type: generate an exe or a dll (exe is default)
+* Signing Key: specify a cryptographic key for your application so that the compiled assembly can be added to the Global Assembly Cache (GAC). If a non existing filename is chosen, a key will be automatically generated.
+* Force 32bit: on a 64bit machine, forces compilation for 32 bit.
+
+===Class and feature naming===
+
+
+The standard naming conventions for .NET and Eiffel are different. To accommodate this difference Eiffel Studio provides a number of options to the developer, allowing for consistent naming of classes and features within and between .NET systems. To illustrate this we shall consider a system using the EiffelBase library and focus on the CURSOR class. The base cluster is included in the project settings Cluster tab as shown below, where $ISE_EIFFEL is the environment variable pointing to the location of Eiffel on your hard disk.
+
+
+The CURSOR class is located at '$ISE_EIFFEL\library\base\structures\cursors'.
+
+
+* Follow .NET naming guidelines: this option determines whether the generated .NET code uses the Eiffel or .NET naming convention. Using Ildasm, the IL disassembler tool provided with the .NET Framework, we can see the difference between them. The Eiffel naming convention uses uppercase characters for all classes whereas the .NET nomenclature uses the Camel Case style. Note that this option is only available in a non-compiled system. Once the system has been compiled the naming standard is fixed for the project.
+
+No .NET naming guidelines
+
+[[Image:ildasm-no-dotnet-naming]]
+
+.NET naming guidelines
+
+[[Image:ildasm-dotnet-naming]]
+
+
+* Use cluster names and Use recursive cluster names: These options dictate how a class is known to the system. In our CURSOR example there are 4 main scenarios. For a quick overview of all scenarios refer to the table at the bottom of the page. If neither box is selected we just have 'CURSOR' or 'Cursor' (depending on whether the .NET naming guidelines are used), as seen above. If 'Use cluster names' is checked then the cluster name is pre-pended to the class name, so 'CURSOR' now becomes 'base.CURSOR'.
+
+[[Image:use-cluster-names]]
+
+
+
+If 'Use recursive cluster names' is true then the full cluster name is pre-pended to the class name, so it thus becomes 'base.structures.cursors.CURSOR'.
+
+
+
+[[Image:use-full-cluster-names]]
+
+
+
+The final scenario is where a namespace has been defined for the cluster in the Clusters tab of the Project Settings. In this situation the namespace overrides the name of the cluster. In the example below the namespace name 'MyBaseNameSpace' is used so the resulting name is 'MyBaseNameSpace.structures.cursors.CURSOR'.
+
+
+
+[[Image:use-namespace-name]]
+
+
+
+===Naming Scenarios===
+
+This table shows how the class name generation is affected by the naming options using the CURSOR class found in '$ISE_EIFFEL\library\base\structures\cursors' as an example.
+{|
+|-
+| Use .NET naming guidelines
+| Use cluster names
+| Use full cluster names
+| Namespace Name
+| Generated Name
+|-
+| no
+| no
+| no
+| (empty)
+| CURSOR
+|-
+| yes
+| no
+| no
+| (empty)
+| Cursor
+|-
+| no
+| yes
+| no
+| (empty)
+| base.CURSOR
+|-
+| yes
+| yes
+| no
+| (empty)
+| Base.Cursor
+|-
+| no
+| no
+| yes
+| (empty)
+| structures.cursors.CURSOR
+|-
+| yes
+| no
+| yes
+| (empty)
+| Structures.Cursors.Cursor
+|-
+| no
+| yes
+| yes
+| (empty)
+| base.structures.cursors.CURSOR
+|-
+| yes
+| yes
+| yes
+| (empty)
+| Base.Structures.Cursors.Cursor
+|-
+| no
+| no
+| no
+| MyNameSpace
+| MyNameSpace.CURSOR
+|-
+| yes
+| no
+| no
+| MyNameSpace
+| MyNameSpace.Cursor
+|-
+| no
+| yes
+| no
+| MyNameSpace
+| MyNameSpace.CURSOR
+|-
+| yes
+| yes
+| no
+| MyNameSpace
+| MyNameSpace.Cursor
+|-
+| no
+| no
+| yes
+| MyNameSpace
+| MyNameSpace.structures.cursors.CURSOR
+|-
+| yes
+| no
+| yes
+| MyNameSpace
+| MyNameSpace.structures.cursors.Cursor
+|-
+| no
+| yes
+| yes
+| MyNameSpace
+| MyNameSpace.structures.cursors.CURSOR
+|-
+| yes
+| yes
+| yes
+| MyNameSpace
+| MyNameSpace.Structures.Cursors.Cursor
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/tasks-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/tasks-options.wiki
new file mode 100644
index 00000000..3b0a20cd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/tasks-options.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Tasks Options]]
+[[Property:weight|8]]
+[[Image:task-options|Tasks dialog]]
+
+It is possible to have a command executed before/after an eiffel compilation.
+Tasks have these properties:
+* Command: command to execute
+* Description: an optional description about the external
+* Working directory: an optional working directory, if nothing is specified, the path to the configuration file will be used
+* Must succeed: does the task have to finish successful for the compilation to continue?
+* Condition: allows the same configuration with tasks to work in different situations (e.g. windows and unix) (see [[General Target Options|conditions]] )
+
+==Examples==
+
+===Windows===
+Execute a command and pause until user presses a key
+{{sample|cmd /c "dir && pause"}}
+
+===Unix===
+Execute a command and pause for 10 seconds
+{{sample|bash -c "ls;sleep 10"}}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/type-mapping.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/type-mapping.wiki
new file mode 100644
index 00000000..3823913d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/type-mapping.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Type mapping]]
+[[Property:weight|10]]
+[[Image:mapping-options|Type mappings dialog]]
+
+Type mappings map one class name to another. E.g. STRING can be mapped to STRING_32. So whenever STRING is used in a class, STRING_32 will be used instead.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/variables.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/variables.wiki
new file mode 100644
index 00000000..2864a934
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/variables.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Variables]]
+[[Property:weight|9]]
+[[Image:variable-options|Variables dialog]]
+
+Variables specified here can be used in locations of groups and take precedence over environment variables. They can also be used in conditions.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/warning-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/warning-options.wiki
new file mode 100644
index 00000000..ce7aae1a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/warning-options.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Warning Options]]
+[[Property:weight|5]]
+[[Image:warning-options|Warning dialog]]
+* Enabled: globally enabled/disable warnings.
+* Old Syntax: warn about the use of old syntax
+* Same UUID: different configuration files with the same uuid
+* Old Verbatim Strings: warn about usage of old verbatim strings
+* Assignment on Formal/Expanded: warn about assignment attempts on formal or expanded targets
+* Options Unknown Class: class options for an unknown class
+* Onces in Generics: once features in a generic
+* Obsolete Features: features that are obsolete
+* Missing Class Export: features are exported to a class that does not exist
+* Obsolete Classes: classes that are obsolete
+* Incompatible Types Equality: incompatible types in equality comparison
+* Unused Locals: locals that are not used
+* Renaming Unknown Class: renaming was defined for a class that does not exist
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/assertion-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/assertion-options.wiki
new file mode 100644
index 00000000..176ba535
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/assertion-options.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Assertion Options]]
+[[Property:weight|2]]
+This is where you can configure the assertion level for your project.
+
+[[Image:assertion-options|Condition dialog]]
+
+Each precondition setting can be changed independently from each other.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/group-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/group-options.wiki
new file mode 100644
index 00000000..0c34742b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/group-options.wiki
@@ -0,0 +1,76 @@
+[[Property:title|Group Options]]
+[[Property:weight|3]]
+This is where you can configure the groups of your project. A group is a container for classes and has some additional options associated. There are five types of groups
+* Cluster: represents a directory or directory structure on the disk with class files in it
+* Override cluster: similar to cluster but overrides classes in other clusters with the same name, can only appear in an application, never in a library
+* Library: a configuration of a library is included, all classes in clusters are accessible
+* Precompile: a precompile is similar to a library, but the contents of the library have already been compiled and therefore compilation is a lot faster, there can only be one precompile group
+* Assembly: classes in an assembly (.NET code generation mode only)
+
+To add a new group, choose the corresponding add group button or context menu entry and enter a name and location or choose from a list (for assemblies and libraries).
+
+[[Image:group-options|Group dialog]]
+
+==Common Group Options==
+* Name: name of the group
+* Description: an optional description of the group
+* Read Only: in a read only group, classes cannot be modified
+* Location: directory for clusters, assembly file for assemblies and ecf file for libraries and precompiles
+* Profiling: turn on the Eiffel profiler during the application execution (C code generation mode only). The results can be seen at the end of the execution in the profiler window.
+* Trace: display on the console all the features that are called during the system execution (C generation mode only).
+* .NET Namespace: specify the namespace for this group (.NET code generation mode only)
+* Assertions: [[Assertion Options|assertion level]] for this group
+* Warning: [[Warning Options|warnings]] for this group
+* Debug: [[Debug Options|debugs]] for this group
+
+===Advanced===
+* Condition: group nodes can be [[General Target Options|conditioned]] to only be used under certain conditions.
+* Prefix: name prefix for classes in this group (see [[Group Options| Renaming]] )
+* Renaming: renamings for classes in this group (see [[Group Options| Renaming]] )
+* Class Options: options specific for certain classes
+
+==(Override) Cluster Options==
+Clusters can be added as a sub clusters of other clusters, just select the parent cluster before adding the cluster.
+* Recursive: should subdirectories automatically be included?.
+* Hidden: Is this a hidden cluster that can not be used if the system is used as a library?
+* Exclude Rules: [[General Target Options|exclude rules]] for this group
+* Dependencies: specify which groups are checked for classes if the class cannot be found in the group itself
+* Type Mapping: [[Type mapping|mapping]] of types, e.g. STRING is mapped to STRING_32
+* Visible Classes: visible classes (see [[Group Options| Visible Classes]] )
+
+==Override Cluster Options==
+* Overrides: which groups are overridden by this override (default to all).
+
+==Library/Precompile Options==
+If a library is not read only, the configuration can be directly edited by clicking on the edit library button.
+* Visible Classes: visible classes (see [[Group Options| Visible Classes]] )
+* Use Application Options: Should this library use options from the application instead of from the library?
+
+==Assembly Options==
+It is possible (but not recommended) to specify an assembly only with GAC information. To do this set the location to ''none'' and specify:
+* Assembly Name: Full name of the assembly as found in the GAC.
+* Assembly Culture: Culture of the assembly.
+* Assembly Version: Version of the assembly.
+* Assembly Public Key Token: Public key token that identifies the asssembly.
+
+==Resolving Conflicts==
+There are multiple ways to resolve conflicts between different classes with the same name.
+===Renaming===
+
+A class can be renamed with a renaming or a group can have a name prefix which will get added to every class. Outside of this group, the class can then be reached by the renamed name.
+
+===Dependencies===
+
+It is possible to specify which other groups will be searched if a class cannot be found in the current group.
+
+==Visible classes==
+
+If a feature should be reachable from CECIL and may not be used it must be made visible because otherwise it will be removed by the dead code optimizer. To do this you have to make the class visible. In addition it is also possible to rename a class or a feature. In most cases we make a class completely visible and do not need renaming.
+
+[[Image:visible-dialog|Visible dialog]]
+
+To make a class visible, just enter the class name and press ''Add class''. Optionally it is possible to specify a different name under which it is accessible. After a class has been added, it is possible to restrict the access to certain features only. To do this, enter the name of the feature (and optionally a renamed name), select the class it belongs to and click on ''Add feature''.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki
new file mode 100644
index 00000000..d8a4a9c5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki
@@ -0,0 +1,53 @@
+[[Property:title|General Target Options]]
+[[Property:weight|1]]
+This is where you can configure most general aspects of your target.
+
+Here is what you will see when you switch to the target section in the project settings of the calculator example:
+
+[[Image:target-options|General target properties]]
+
+You can change the name of the target and give it a description. A target can be marked as abstract if it should not appear in the list of targets when opening a configuration.
+
+Targets can inherit from each other, which means they take certain settings from a base target if they don't specify it themselves. Inherited values are displayed with a light grey, overridden values with a light red background. Overridden values can be reset to their inherited value, by right clicking on them and choosing ''Use inherited value'' from the context menu.
+
+An important setting that affects other settings is the compilation type. Here you can specify if you want to generate normal C/byte code (classic application) or if you want to generate .NET code.
+
+With the output name option you can change the name of the generated executable if you want this to be different than the name of the system.
+
+If you want to change the root of your system, you will see a dialog like this:
+
+[[Image:root-dialog|Root dialog]]
+
+You can specify a root class, root cluster and root feature. Both root cluster and root feature are optional. Instead of specifying a root class it is also possible to choose ''Compile all classes'' which doesn't generate a binary but checks all classes in the target. This can be used for making sure that a library doesn't have any compiler errors.
+
+The version dialog looks similar to this one:
+
+[[Image:version-dialog|Version dialog]]
+
+It allows a version number and some copyright information to be set. On .NET this information will be put into the generated assembly.
+
+The Exclude Rules setting allows to define rules to exclude certain files from every cluster. This can be used to exclude CVS or SVN directories globally instead of excluding them on each cluster. The dialog looks like this:
+
+[[Image:exclude-dialog|Exclude Rules dialog]]
+
+Exclude rules are regular expressions which are matched against directories and file names. The basic semantics are that everything is included that either does not match an exclude pattern or does match an include pattern. Matching is done against the path relative to the location of the cluster and / is used as a directory separator.
+
+{{sample| We have a recursive cluster in c:\projects\calculator\cluster and in there we have a file c:\projects\calculator\cluster\interface\ignore_me.e
+Matching would now be first done against ''/interface'' and then against ''/interface/ignore_me.e''
+A rule like ''^/interface$'' would exclude the whole subdirectory, a rule like ''^/interface/ignore_me\.e$'' would only exclude the ignore_me.e class. }}
+
+It is also possible to add conditions to a file rule (set of include and exclude file patterns). Adding conditions allows a file rule to be active only under certain conditions. The condition dialog looks like this:
+
+[[Image:condition-dialog|Condition dialog]]
+
+Conditioning possibilities are platform (e.g. only Windows or everything but windows), kind of build, .NET generation, dynamic runtime, multithreaded, version of compiler and version of msil clr. It is also possible to specify custom conditions where a user defined variable has to have a certain value.
+
+Further options are
+* Profiling: turn on the Eiffel profiler during the application execution (C code generation mode only). The results can be seen at the end of the execution in the profiler window.
+* Trace: display on the console all the features that are called during the system execution (C generation mode only).
+* .NET Namespace: specify the namespace for this target (.NET code generation mode only)
+* Line generation: generate some extra information that will enable a .NET debugger or a C debugger to step through the Eiffel code rather than MSIL code or C code.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/index.wiki
new file mode 100644
index 00000000..b59b99d7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/index.wiki
@@ -0,0 +1,35 @@
+[[Property:title|EiffelStudio: Project settings window]]
+[[Property:link_title|Project Settings]]
+[[Property:weight|-10]]
+This is where settings regarding your project are going to be made. In here you can specify:
+* the clusters that contain your classes
+* the libraries and/or assemblies that you use
+* which assertion level you want to check
+* which debug clauses will be activated
+* which warnings will be reported
+* which C/C++ externals your project needs
+* what kind of tasks should be executed before or after a compilation
+* various other options such as multithreading
+
+
+
+The window is organized in eleven sections:
+* [[System Options|System Options]]
+* [[General Target Options|Target Options]]
+** [[Assertion Options|Assertions]]
+** [[Group Options|Groups]]
+** [[Advanced Options|Advanced Options]]
+*** [[Warning Options|Warnings]]
+*** [[Debug Options|Debug]]
+*** [[Externals Options|Externals]]
+*** [[Tasks Options|Tasks]]
+*** [[Variables|Variables]]
+*** [[Type mapping|Type Mapping]]
+
+
+
+The changes you make are taken into account the next time you recompile your project. Instead of automatically performing the compilation each time you click Ok or Apply we decided to save the modifications and let the user decide when to recompile.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/system-options.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/system-options.wiki
new file mode 100644
index 00000000..083b164e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/system-options.wiki
@@ -0,0 +1,21 @@
+[[Property:title|System Options]]
+[[Property:weight|0]]
+This is where you can configure the most general aspects of your system. For example you can set the name of your application and the targets in the system.
+
+Here is what you will see when opening the project settings window for the first time in a session when using the ecf file of the calculator example located at $ISE_EIFFEL|examples|base|calculator:
+
+[[Image:system-options|General system properties]]
+* Name: specifies the name for the system and is also used as the default for the name of the generated executable. The name of the executable can be changed in the [[General Target Options|target settings]] .
+* Description: an optional description of the system
+* Library Target: the target that should be used if this system is used as a library
+* Library Readonly: Is this system read only per default if it is used as a library?
+* File Name: Location of the configuration file.
+* UUID: unique identifier for this system
+
+A system also has one or multiple targets which are the main blocks that specify an application or library. A target can extend another target. For example in the calculator application we have three targets: common, classic and dotnet. The common target specifies the part of the application that is common to classic and .NET compilation. The dotnet and classic targets extend the common target and add their specific settings.
+
+To add a new target select the system node and click on '''Add Targe'''t. If a target should extend another target, select the parent target and click '''Add Target'''.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-50.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-50.wiki
new file mode 100644
index 00000000..b31a683d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-50.wiki
@@ -0,0 +1,62 @@
+[[Property:title|Release notes for EiffelStudio 5.0]]
+[[Property:link_title|5.0]]
+[[Property:weight|-8]]
+==Graphical environment==
+* New Look and feel.
+* New way of starting EiffelStudio and simplified the process of compiling an existing project.
+* New editor with:
+** smart syntax highlighting
+** feature completion (by pressing Ctrl+Space after an identifier).
+** syntax completion of major control statement (if, from, is,...)and of symbols such as `{', `[', `(', `"',...
+** smart auto indenting
+** block indent and exdent.
+** infinite level of Undo/Redo
+
+* When edition of a class text which has been successfully compiled, the class will be fully `pick-and-droppable'.
+* Faster rendering for Clickable, Flat, Contract (previously known as Short) and Flat Contract views.
+* System tool has been replaced by a `project settings' window. The underlying mechanism of the configuration file is kept, but all changes are done through a nice GUI making it simpler for beginners to create their first configuration file.
+* Toolbars are now customizable
+* EiffelCase has been merged within EiffelStudio to provide a true reverse engineering using the BON notation.
+
+==Compiler==
+The compiler has been improved in many ways and some functionality have been added. [[Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0|Check it out]] .
+==Debugger==
+* New debugger functionalities:
+** one can step-in, step-out, step-by-step when they want to.
+** one can put a breakpoint on the fly (Windows Only)
+** one can see all local variables and arguments.
+** one can set breakpoints in all kind of assertion clauses except in invariants.
+
+* Debugging is faster.
+
+==Documentation==
+* New documentation generation (limited now to HTML) which is completely clickable as if within EiffelStudio. It also includes an EiffelCase-like documentation generation.
+* Generation of XMI which can be used in tools such as Rational Rose.
+
+==Libraries==
+
+===EiffelBase:===
+* No more GENERAL class as proposed by the NICE committee. It has been replaced by ANY which does not inherit any more from PLATFORM.
+* Adaptation of the ARRAY class to the ELKS 2000 standard.
+* This implies a change in our CONTAINER class where we renamed empty into is_empty and made empty obsolete. If you were inheriting from CONTAINER and redefining empty, make sure to update your code so that you redefine is_empty instead. That way your polymorphic calls will still work as expected without having to change all call to empty into calls to is_empty.
+* New implementation of is_equal on LIST which will now check that two lists are identical if their items are identical.
+* New implementation of copy on LIST.
+* New implementation of an iterative is_equal on TREE which will now check that two trees are identical if their items are identical.
+* New implementation of an iterative copy on TREE, which recursively copies the tree.
+* New ROUTINE classes which perform better type checking on argument passing.
+* Introduction of binary operations on INTEGER types: infix "&",infix "|", bit_xor, bit_not, bit_shift, infix "|>>", infix "|<<"and bit_text.
+* Removed infix "^" from NUMERIC. It does not break any inheritance, but break clients that were using this operator on an entity declared of type NUMERIC. This is due to the different return type of this operator depending the NUMERIC type you are handling.
+* Changed the signature of pruned in BINARY_SEARCH_TREE to take an extra argument. This was necessary to fix a problem that caused the `parent' attributes to become inconsistent under certain conditions when calling pruned.
+* Re-implemented the features disjoint and symdif of SUBSET. These features caused problems under certain conditions and were also quite inefficient. The new implementation of these features uses the strategy pattern to choose among different versions of these calculations depending on the properties of the elements contained in the set.
+* All features on SUBSET that take another subset as an argument(e.g. intersect) now accept any other subset type as an argument, independent of its underlying implementation, and not only subsets of type `like Current'.
+* Many smaller bug fixes for bugs that were reported by our customers or that have been discovered during our development andtesting.
+
+===WEL:===
+
+Modified classes relative to the use of registry keys to be written only using Eiffel and externals to Win32 API (no more C intermediates). In the process close_key and delete_key are now commands and not queries. To find out if it their call was successful, you can query last_call_successful.
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-51.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-51.wiki
new file mode 100644
index 00000000..02c00663
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-51.wiki
@@ -0,0 +1,35 @@
+[[Property:title|Release notes for EiffelStudio 5.1]]
+[[Property:link_title|5.1]]
+[[Property:weight|-9]]
+==Graphical environment==
+* Numerous improvements in usability and bug fixes.
+* Richer class and cluster creation dialogs.
+* Class name completion in the editor (by pressing Ctrl+Shift+Space half-way through the class name).
+* Editor now supports drag-and-drop of the selection.
+* When debugging a project from EiffelStudio, the current directory will be your project directory. It is a change from previous version where:
+** on Windows, it used to be launched in the W_code subdirectory of your project directory
+** on Unix, it used to be launched from the same directory where `estudio' (or `ebench') was launched.
+
+* EiffelStudio GUI now also available on Unix platforms and Windows 9x/Me
+
+==Compiler and .NET==
+* Click [[Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1|here]] for more details on compiler improvements and full Eiffel support on .NET
+
+==Libraries==
+
+===EiffelBase===
+* It is now forbidden to create a BIT_REF or a BIT X object using its creation procedure (before it was accepted but did not work)
+* Added make_temporary_name in FILE_NAME
+* Made to_c obsolete from class INTEGER_INTERVAL
+* Changed semantic of split from class STRING
+* Fixed a bug in clear_all from HASH_TABLE that kept a reference to the last found item. Now it does not keep the reference after a call to clear_all .
+
+===Vision2===
+* Support for Vision2 applications on GTK platforms.
+* Some changes in the Vision2 library have been made, [[Revisions and Bug Fixes|check here on how to update your code]] .
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-52.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-52.wiki
new file mode 100644
index 00000000..5feb2661
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-52.wiki
@@ -0,0 +1,109 @@
+[[Property:title|Release notes for EiffelStudio 5.2]]
+[[Property:link_title|5.2]]
+[[Property:weight|-10]]
+==Graphical environment==
+* Added a status bar, which gives a lot of information, such as the state of the compilation or the name of the current project.
+* Clicking feature clauses in the feature tree now centers the editor on the selected feature clause.
+* More specific icons in the feature and cluster trees, so that identifying deferred classes and the nature of features is now straightforward.
+* Up to 10 [[External commands editor dialog|external commands]] can now be defined and called from the '''Tools''' menu.
+* The new '''Quick compile''' command lets you recompile only the classes that have been edited in EiffelStudio, skipping the sometimes tedious degree 6, that looks for modified classes.
+* Control picking now has a configurable effect.
+* More improvements in usability and bug fixes.
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2|here]] for more details on compiler improvements and full Eiffel support on .NET
+
+==Debugger==
+* Right-clicking on one of the run buttons will pop up a dialog enabling you to choose the command line argument (it is a shortcut for `Project Settings'-> Debug tab).
+* Expressions can now be dynamically evaluated in the debugger. ( [[Expression evaluation|info]] )
+* Conditional breakpoints. ( [[Breakpoints|info]] )
+* Classes can now define debug_output , a feature inherited from DEBUG_OUTPUT , whose string result is automatically displayed in the debugger for all objects of that type. ( [[Debug output|info]] )
+* Possible stack overflows can now be detected in the debugger before they occur. ( [[Stack overflow prevention|info]] )
+
+==Libraries==
+
+===EiffelBase===
+* Improved speed of search operations in ARRAYED_LIST and HASH_TABLE .
+* Reduced number of exported features in TUPLE .
+* Updated INTERNAL and TUPLE to accept INTEGER_XX based queries/commands.
+* STRING changes:
+** Fixed is_integer to return False for strings of the form "(-|+)[a-zA-Z]+[0-9]*)"
+** Improved speed of to_lower and to_upper .
+** Updated for ELKS 2001 conformance:
+*** Changed signature of out and replace_substring to use STRING instead of `like Current'.
+*** Added keep_tail , keep_head , remove_tail , remove_head and make head and tail obsolete.
+*** Added string , same_string , has_substring , fill_with , insert_string , insert_character , as_lower , as_upper .
+*** Modified make_from_string so that no sharing of internal string is done.
+*** Made remake , replace_character and insert obsolete.
+
+
+
+===EiffelThread===
+* Fixed crashes when using join or terminated from THREAD_CONTROL .
+
+===EiffelTime===
+* Rewritten so that no additional C libraries is needed. Therefore you have to update your project configuration files to reflect this change, i.e. removing the include directory and the object file of the old EiffelTime library.
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here to see list of update and modification to Eiffel Vision2]] .
+
+===WEL===
+* Changed type of non-exported feature internal_data of WEL_WINDOW from INTEGER to POINTER .
+* Fixed a GDI memory leak when creating/releasing instances of descendant of WEL_CONTROL .
+
+==Patch releases==
+
+===Version 5.2.1402:===
+* Put Windows and Unix version to the same version number.
+* Fixed EiffelWeb documentation and example.
+* Fixed minor issues found with EiffelVision2 on Unix and Windows which were affecting EiffelBuild.
+* Fixed incorrect configuration file specification for EiffelVision2 examples and wizards on Unix platforms where application could be linked dynamically with `libpng' but should not.
+* Fixed EiffelStore handle for Oracle so that it works fine when compiled with the Borland C compiler.
+* Fixed incorrect version number in VERSION file on Unix platforms.
+
+===Version 5.2.1313:===
+* Fixed resource leak on Windows 98 and Windows Me.
+* Fixed incorrect implementation of area and substring for STRING in dotnet mode.
+* Fixed issue with setting of arguments. After restarting EiffelStudio the command line argument contains an extra `]' character.
+* Fixed issue with working directories where only the first one ever set was used even if new ones have been set afterwards.
+* Fixed issue in IL code generation where having a class that inherits from a non-Eiffel .NET class. And the class has the following features:
+
+a: ARRAY [like f]
+f: STRING is
+ do
+ end
+
+Then you could neither load nor execute the generated code.
+
+* Fixed issue with incorrect C code generation of inspect instruction based on character values above 128.
+* Fixed bug in copy from STRING where following code was violating valid_count invariant from STRING :
+
+local
+ s, t: STRING
+do
+ create s.make (9)
+ create t.make (10)
+ t.append ("1234567890")
+ s.copy (t)
+end
+
+* Fixed incorrect C file naming when generating a .NET system that uses a C++ external (it should be .cpp, not just .c).
+* Enabled support for Borland C compiler in .NET.
+* Fixed issue where generating documentation for all/library cluster would stop during generation without completing.
+* Fixed crash in diagram tool when moving label on client/supplier link between two classes.
+
+===Version 5.2.1123:===
+* Fixed issue when inheriting a .NET class that has some static constants defined.
+
+===Version 5.2.1122:===
+* Fixed issue when opening the about dialog of EiffelStudio.
+* Enabled EiffelStudio for all users on a machine, not just for the one installing EiffelStudio.
+
+===Version 5.2.1118:===
+* First initial release of EiffelStudio 5.2
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-53.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-53.wiki
new file mode 100644
index 00000000..941a52e3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-53.wiki
@@ -0,0 +1,97 @@
+[[Property:title|Release notes for EiffelStudio 5.3]]
+[[Property:link_title|5.3]]
+[[Property:weight|-11]]
+==Graphical environment==
+
+===Changes===
+* In project settings, we now accept a root class without creation procedure.
+* In .NET code generation, we do not force the C compilation at each compilation. It is only done when necessary (for example when a C external has been added).
+* Incremental .NET code generation (See [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|compiler release notes]] for more info).
+* Recoverable storable (See [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|compiler release notes]] for more info).
+
+===Bug fixes===
+* Fixed issue with setting of arguments. After restarting EiffelStudio the command line argument contains an extra `]' character.
+* Fixed issue with working directories where only the first one ever set was used even if new ones have been set afterwards.
+* Fixed issue where generating documentation for all/library cluster would stop during generation without completing.
+* Fixed crash in diagram tool when moving label on client/supplier link between two classes.
+* Fixed resource leak on Windows 98 and Windows Me.
+* Fixed issue in projects where clusters are specified with relative path would not compile after adding a local assembly.
+* Fixed problem with cluster tool management where moving classes around or looking up a class will generate an error box instead of performing the requested operation.
+* Fixed incorrect configuration file specification for EiffelVision2 examples and wizards on Unix platforms where application could be linked dynamically with `libpng' but should not.
+* Fixed disappearance of EiffelStudio when debugging a routine `infix' or `prefix' in which an exception was raised. This issue was only occurring with melted code (usually noticeable when using a precompiled library).
+* Changing the project specific command line arguments will not touch the project settings configuration file (ace file).
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|here]] for the compiler release notes.
+
+==Libraries==
+
+===CECIL===
+* Enforced definition of EIF_OBJECT so that it is different from EIF_REFERENCE to better catch errors when passing a protected reference to a feature accepting an unprotected reference and vice versa. Because of this change some C code might not compile anymore which is good as it points out that code was doing something wrong that could corrupt the Eiffel memory.
+
+===EiffelBase===
+* Added in INTERNAL the following new features: field_static_type_of_type , class_name_of_type , type_name and type_name_of_type .
+* Added truncated_to_integer_64 in REAL and DOUBLE .
+* Added to_integer_64 in STRING .
+* Added new classes MEMORY_STRUCTURE , MANAGED_POINTER and C_STRING to better manage access to C and C++ memory structure.
+* Fixed incorrect implementation of area and substring for STRING in dotnet mode.
+* Fixed bug in copy from STRING where following code was violating valid_count invariant from STRING :
+
+local
+ s, t: STRING
+do
+ create s.make (9)
+ create t.make (10)
+ t.append ("1234567890")
+ s.copy (t)
+end
+
+* Added support for storable in .NET. However .NET and classic implementation are completely different and independent_store will not be able to retrieve a storable file if not made using the same code generation.
+* Fixed a bug in is_equal from LIST where comparing two lists of different counts could break the comparison:
+
+make is
+ local
+ a, b: LIST [INTEGER]
+ do
+ create {ARRAYED_LIST [INTEGER]} a.make (2)
+ a.extend (10)
+
+ create {ARRAYED_LIST [INTEGER]} b.make (2)
+ b.extend (10)
+ b.extend (11)
+
+ print (equal (b, a))
+ end
+
+* Fixed .NET implementation of open_write and create_read_write in FILE . They were not resetting the file size to zero if file already existed.
+* Added correct_mismatch on ANY used for `recoverable storable'.
+* Added correct_mismatch on HASH_TABLE to enable retrieval of the 5.1 and older version of HASH_TABLE.
+* Fixed bug in implementation of copy and is_equal for TREE and descendant classes. Now descendants of TREE that would like to compare additional attributes of their class needs to redefine node_is_equal whose default implementation will always result in a true value.
+* Changed default semantic of make and put_child from FIXED_TREE, to preserve existing semantic, you should use make_filled and replace_child instead.
+
+===Eiffel2Java===
+* Updated library so that it works both in classic and dotnet mode.
+
+===EiffelCOM===
+* Fixed crash in ccom_set_name from FONT_IMPL_PROXY.
+
+===EiffelNet===
+* Fixed assertion violation of call to to_integer in feature get_content_length from HTTP_PROTOCOL if assertions are enabled on EiffelBase.
+
+===EiffelStore===
+* Updated library so that it works both in classic and dotnet mode.
+* Fixed issue with oracle handle which did not work with the included Borland C compiler.
+* Removed nb_classes from EXT_INTERNAL .
+* Removed need for additional object file (`support.lib' on Windows and `libsupport.a' on Unix platforms), so make sure to remove it from your project configurations.
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here to see list of update and modification to Eiffel Vision2]] .
+
+===WEL===
+* Removed inheritance to WEL_STRUCTURE in WEL_STRING, it now inherits from new C_STRING class. In the process removed the following features which were inherited from WEL_STRUCTURE and did not make sense to WEL_STRING memory_copy, structure_size, dispose, set_item, set_shared, set_unshared, shared, to_integer. No replacements have been provided for those features. Made initialize and initialize_with_character obsolete, instead we now provide two features inherited from C_STRING fill_blank and fill_value.
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-54.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-54.wiki
new file mode 100644
index 00000000..02d12cf3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-54.wiki
@@ -0,0 +1,95 @@
+[[Property:title|Release notes for EiffelStudio 5.4]]
+[[Property:link_title|5.4]]
+[[Property:weight|-12]]
+==Graphical environment==
+
+===Improvements===
+* Added support for mouse wheel in editor and associated parameterization in preferences.
+* Cluster tree is not collapsed anymore between compilation.
+* All callers will not show empty entries.
+
+===Bug fixes===
+* Fixed issue where setting the string background color to `auto' in the preferences will set it to a black color next time your relaunch EiffelStudio.
+* Fixed issue where typing in an empty features tree will close down EiffelStudio.
+* Fixed issue with BON diagram where expanded client links were not properly displayed (the expanded bar was drawn on top of classes instead of on the link itself).
+
+==Debugger==
+
+===Improvements===
+* Ability to debug .NET applications from EiffelStudio. It behaves like the traditional debugger except with the current limitations:
+** no conditional breakpoints
+** no expression evaluation
+** no expansion to see attributes of non-Eiffel objects
+
+
+===Bug fixes===
+* Fixed issue on Unix platforms where passing more than 5 arguments will disable debugging and ultimately crash the environment.
+
+==EiffelBuild==
+* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes.
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4|here]] for the compiler release notes.
+
+==Libraries==
+
+===Eiffel2Java===
+* Fixed incorrect memory freeing in get_string in JNI_ENVIRONMENT that could cause some memory corruption.
+* Fixed VDRD error in method_id from JAVA_OBJECT.
+
+===EiffelBase===
+* Optimized i_th from PRIMES for the first 200 prime numbers.
+* Fixed bug in generic_typecode from TUPLE in .NET implementation which fixed an issue with is_reference_item.
+* Made TUPLE a descendant of HASHABLE and defined hash_code (based on the hash_codes of the elements of a TUPLE).
+* Added default_create as creation procedure of TUPLE and made make obsolete.
+* Added convenience features to TUPLE: put_XX_item where `XX' can be replaced by `character, boolean, integer, double,...'.
+* Optimized ROUTINE, PROCEDURE and FUNCTION implementation to speed up agent calls by a factor of 2 to 3. Removed open_operand_type from ROUTINE as its specification was only used internally and specification was not precise enough to be used by clients of ROUTINE.
+* Fixed append from SEQUENCE to not perform a deep_clone when passed argument is the same reference as Current. This was a problem when the base class of the type of the elements inherited from MEMORY and redefined dispose. You could possibly end up freeing twice an external resource.
+* Changed implementation of INTERACTIVE_LIST to be based on ARRAYED_LIST rather than on LINKED_LIST.
+* Added efficient implementation of append in ARRAYED_LIST.
+* Fixed bug in multithreaded mode when you open in two different threads a different file with a different mode. For example one is in read mode, the other one is in write mode. If the operation happens at the same time, you could end up with two files open in read mode or two files open in write mode, which is not the expected behavior.
+
+===EiffelNet===
+* Fixed bug in set_delay and set_nodelay in NETWORK_STREAM_SOCKET, because their implementations were inverted.
+* Fixed incorrect spelling of maximum_seg_size in NETWORK_STREAM_SOCKET.
+* Added recoverable storable to EiffelNet (was not included in previous version although recoverable storable was available for files).
+* Fixed SMTP_PROTOCOL to follow more closely SMTP RFCs.
+* Added support for multi-line error codes in SMTP_PROTOCOL.
+
+===EiffelTime===
+* Improved speed of DATE and TIME comparison.
+* In DATE_VALUE added ordered_compact_date and made compact_date obsolete.
+* In DATE added make_by_ordered_compact_date and make_by_compact_date obsolete.
+* In DATE_VALIDITY_CHECKER added ordered_compact_date_valid.
+* Fixed C_DATE to buffer the current time rather than querying it for each of the time components. Not doing that was causing a bug in DATE, DATE_TIME and TIME where if the computation was done on December 31st at 23:59:59 2003, we could end up with a date of January 1st 2003, therefore being one year off. This is a breaking change from before and if you are using C_DATE, use update before each call to the *_now queries if you expected to reflect the time at the time of the query.
+
+===EiffelThread===
+* Added support for .NET
+* Made OBJECT_OWNER obsolete
+* Added wait_with_timeout in CONDITION_VARIABLE
+* Added READ_WRITE_LOCK class to be used in a system where few writes are done compare to reads. A typical example of its use would be to have a thread safe lookup table where few insertions are done.
+* Now a C externals that might block the execution of a system, should be marked `blocking'. [[Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4|See compiler changes for more details]] .
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here to see list of update and modification to EiffelVision2]] .
+
+===EiffelWeb===
+* Fixed issue when sending exception trace to browser. On most servers you were getting an internal error rather than the exception trace.
+* Fixed issue with cookies from CGI_ENVIRONMENT as keys were stored as items, now the keys are stored as keys, items as items.
+
+===WEL===
+* Renamed convert from CONVERTER class into extract_definition.
+* Renamed convert from WEL_FONT_FAMILY_ENUMERATOR class into update_current.
+* In WEL_TREE_VIEW, calling deselect_item will now really deselect the item, whereas previously, it only caused the item to be redrawn without selection.
+* In WEL_REGISTRY, open_value_key will now accept an empty string so that the default key value can be read.
+* Fixed issue with dword_value in WEL_REGISTRY_KEY_VALUE which returned incorrect values.
+* Made make in WEL_REGISTRY_KEY_VALUE accepts only string values, if you want to create a new instance with a value of a different type you need to use the new creation procedure make_with_value.
+
+===.NET libraries===
+* Renamed THREAD and MUTEX into SYSTEM_THREAD and SYSTEM_MUTEX to avoid name conflicts with EiffelThread.
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-55.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-55.wiki
new file mode 100644
index 00000000..d07685bd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-55.wiki
@@ -0,0 +1,82 @@
+[[Property:title|Release notes for EiffelStudio 5.5]]
+[[Property:link_title|5.5]]
+[[Property:weight|-13]]
+==Graphical environment==
+
+===Improvements===
+* Added full configuration of colors used in editor
+* Added docking facilities for various tools. It permits the re-ordering of tools within the interface, including making them "float" externally [[Docking|(See EiffelBuild documentation on docking mechanism for more details)]] .
+* Ability to see when a class is deferred in the context tool formatters. It is shown by adding the `*' character at the end of the class name.
+
+===Changes===
+* One cannot add a .NET assembly from the GAC anymore, instead you have to specify the path to the assembly in the assembly references list.
+
+===Bug fixes===
+* Fixed a crash when performing feature completion on classes with errors.
+* On Windows, prevented the EiffelStudio window to go to the back of all windows when you click Ok on the dialog box which appears when a syntax error occurs while compiling a project.
+
+==Debugger==
+* Enabled conditional breakpoint and expression evaluation for .NET
+* Improved expression evaluation abilities (full range of Eiffel expressions are now supported).
+* Improved object viewer window (word wrapping for large text, ability to see the whole content in one click without having to enter the lower and upper index of a range).
+
+==EiffelBuild==
+* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes.
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5|here]] for the compiler release notes.
+
+==Libraries==
+
+===CECIL===
+* Added ability to query type of a generic class where an actual generic parameter is expanded although its base class is not. It suffices to prefix the class name with "expanded ". Reciprocally, you can use the reference version of an expanded class by prefixing with "reference ".
+
+===EiffelBase===
+* Removed consistent and setup from ANY
+* Removed Void from ANY as Void is now a keyword.
+* Added for_all, do_all, do_if and there_exists to ARRAY. As a consequence descendants of ARRAY which also inherit from LINEAR have to select the proper version of those routines as they also appear in LINEAR.
+* Fixed dynamic_type_from_string from INTERNAL under .NET which was not working if you were using the .NET naming convention or if you specified a namespace.
+* Added generic_count, generic_count_with_type in INTERNAL to find out how many generic parameter a type has.
+* Added generic_dynamic_type_with_type in INTERNAL to find out the type of the i-th generic parameter of a given type.
+* Added memory_map and memory_count_map to give you a precise accounting of all living objects in the running system. It will help you find out any potential memory leak because objects are still referenced where they should not.
+* Improved performance of FILE objects creation by not allocating the last_string internal buffer until it is needed.
+* On Windows, removed side effects of put from EXECUTION_ENVIRONMENT. Before it was setting also some registry keys, now it only set the environment variable for the running process and its children when launched.
+* Allowed zero sized MANAGED_POINTER. Allowed MANAGED_POINTER to share a pointer rather than doing a full memory copy at creation time.
+* Fixed issue with agents where GC did not collect passed arguments to call or item from ROUTINE/FUNCTION. Thus arguments stayed alive until the next call to call or item.
+
+===EiffelNet===
+* Added close_socket in SOCKETwhich only close the socket for the current process. It will not close it for all processes which are using this socket (e.g. obtained after a fork on Unix platform).
+
+===EiffelTime===
+* Fixed incorrect display of the short year format when using the following code:
+l_date: DATE_TIME
+...
+create l_date.make_now
+print (l_date.formatted_out ("[0]mm/[0]dd/yy"))
+
+
+
+===EiffelThread===
+* Added a new C routine eif_thread_fork for Unix based system for users who would like to use a forking mechanism in a multithreaded system, as the default version of fork will most likely causes some deadlock.
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]]
+
+===WEL===
+* Added various missing constants in WEL_*_CONSTANTS classes.
+* Added creation procedure make_permanent in WEL_DLL so that the loaded DLL is loaded until the very end of program's execution. Now WEL_RICH_EDIT_DLL and WEL_COMMON_CONTROLS_DLL are using this new creation procedure. It fixes the issue where a program using WEL_RICH_EDIT would crash when exiting.
+* Fixed a possible C compilation error when using WEL_RICH_EDIT due to a bug in the Microsoft Platform SDK header file for RichEdit.
+* Fixed WEL_SCROLL_BAR to return a valid position when position is more than 65535.
+* Added string_size_extended in WEL_FONT to better know where to draw a string using a specified font on screen,
+* Added height_in_points, height_in_pixels, height_in_twips, and log_font in WEL_CHARACTER_FORMAT. Made height and set_height obsolete.
+* Changed implementation of WEL_REGISTRY_KEY_VALUE in order to fix set_dword_valuewhich was writing incorrect data to the registry keys. Enhanced the typing of values, thus making the non-typed routines obsolete.
+* Made default_key_value obsolete in WEL_REGISTRY.
+* Properly defined is_equal and copy in WEL_STRUCTURE, possibly causing some compilation errors while analyzing the inheritance structure of your classes.
+* Changed signature of non exported routine cwin_destroy_window from WEL_WINDOW to now return a value.
+* Fixed issues when using WEL in a multithreaded application. It would crash if a non WEL thread was trying to destroy a WEL window.
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-56.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-56.wiki
new file mode 100644
index 00000000..757609e3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-56.wiki
@@ -0,0 +1,159 @@
+[[Property:title|Release notes for EiffelStudio 5.6]]
+[[Property:link_title|5.6]]
+[[Property:weight|-14]]
+==Graphical environment==
+
+===Improvements===
+* New implementation of the diagram tool with enhanced performance and functionalities
+** Support for UML view.
+** Physics: auto-arrangement of classes using force directed graph.
+** Multiple selection of classes.
+** Improved speed/behavior of drawing/scrolling operations especially on large diagram.
+
+* Added ability to find features performing an assignment to an attribute, or creating an attribute, as well as features using a procedure as creation procedure.
+* Feature tree is now showing a different icon for frozen and obsolete features.
+* Improved look and feel of applications using the EiffelVision library under Windows XP theme engine.
+* Improved keyboard navigation in EiffelStudio windows/dialogs.
+* Full support for 64 bits operating systems such as Windows, Linux, Solaris, Irix, VMS,...
+* Features tree is also available for classes which are part of the universe, but not yet compiled.
+* New EiffelCOM wizard. Click [[EiffelCOM Wizard|here]] for more details.
+* Improved speed of class completion for large system.
+* Added new toggles for alias names and assigner commands to feature tree.
+
+===Changes===
+* Changed the default C compilation flags on Windows when using Visual Studio as a back-end C compiler. It will now compile C code using the -MT option. It may cause some linking problems if you are using C libraries compiled against the static C library. To solve those issues recompile your C code using the -MT option.
+* Provided keyword highlighting in editor and different views for new keyword assign.
+
+===Bug fixes===
+* Fixed infinite loop in finish_freezing which could use all the available memory.
+* Fixed some issues with formatting of agent using expressions as target, and display of character and string constants in context tool.
+* Fixed issue where tools that have been externally docked were not properly restored when reopening EiffelStudio.
+* Fixed issue where one could not remove entries added to the list of external commands.
+* Supported keyword highlighting for the keywords infix and prefix in editor and different views.
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6|here]] for the compiler release notes.
+
+==Debugger==
+* Click [[Release notes for EiffelStudio 5.6 related to the debugger|here]] for the EiffelStudio's debugger release notes.
+
+==EiffelBuild==
+* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes.
+
+==Libraries==
+
+===CECIL===
+* Due to renaming of EIF_REAL and EIF_DOUBLE into EIF_REAL_32 and EIF_REAL_64, we have also changed the names of some CECIL facilities. Although old names are still valid we may remove their definition in future releases of the compiler. Below is the list of old names and their corresponding new names:
+{|
+|-
+| '''Old name'''
+| '''New name'''
+|-
+| EIF_REAL_FUNCTION
+| EIF_REAL_32_FUNCTION
+|-
+| EIF_DOUBLE_FUNCTION
+| EIF_REAL_64_FUNCTION
+|-
+| eif_real_function
+| eif_real_32_function
+|-
+| eif_double_function
+| eif_real_64_function
+|-
+| EIF_REAL_TYPE
+| EIF_REAL_32_TYPE
+|-
+| EIF_DOUBLE_TYPE
+| EIF_REAL_64_TYPE
+|-
+| EIF_FN_FLOAT
+| EIF_FN_REAL_32
+|-
+| EIF_FN_DOUBLE
+| EIF_FN_REAL_64
+|}
+
+
+===EiffelBase===
+* Added new storable facility entierly written in Eiffel which enables you to exchange data between classic and .NET. Former version built-in in the Eiffel run-time did not apply for .NET. The classes are located in the new serialization cluster of EiffelBase.
+* ARRAY:
+** Changed signature of subarray to match ELKS specification. It now returns an ARRAY [G] instead of like Current.
+** Fixed has to return True when searching for Void when comparing objects in an array containing a Void element.
+** Fixed issue on .NET with clone/copy which were not really duplicating the internal of the array, and therefore enabling aliasing of its content by more than one array.
+** Fixed a bug in feature occurences that returned 0 when called with void argument and object_comparision is true.
+** Fixed a bug in feature is_equal that caused stack overflow when some array item is the array itself and object_comparision is true.
+
+* ARRAYED_LIST:
+** Removed array_valid_index from ARRAYED_LIST. Descendants of ARRAYED_LIST may need to update their inheritance clause. This fixes ability to use put_i_th with indexes that may violate the invariant of ARRAYED_LIST, for example the code below should trigger a precondition and not violate the invariant of ARRAYED_LIST:
+list: ARRAYED_LIST [INTEGER]
+
+create list.make (5)
+list.put_i_th (3, 3)
+
+** Added implementation query new_filled_list in ARRAYED_LIST. Descendants of ARRAYED_LIST may need to update their inheritance clause.
+
+* HASH_TABLE:
+** Added merge to HASH_TABLE.
+** Now remove will reset found_item when an element is removed.
+
+* INTERNAL:
+** Implemented all the routines in the .NET version.
+** Added support for creating TUPLE types in dynamic_type_from_string.
+** Added precondition to set_reference_field to ensure validity of reattachement to attributes.
+
+* STRING:
+** Changed signature of infix "+" to match ELKS specification. It now returns like Current instead of STRING.
+** Added implementation query new_string. Descendants of STRING may need to update their inheritance clause.
+** Fixed a bug in .NET implementation of feature replace_substring that might produce incorrect result when argument and target of the call is the same object.
+** Merged .NET and classic implementation of STRING so that all features of STRING are now properly implemented for both platforms.
+** Fixed center_justify that would corrupt memory on classic.
+** Changed character_justify, left_justify, right_justify and center_justify so that justification is now done on count instead of capacity. You might expect different results after upgrading, thus check all callers of those routines.
+** Added is_case_insenstive_equal to compare two strings regardless of their case.
+** Rewrote routines is_integer, is_real, is_double, to_integer, to_real and to_double so that they do not rely on C externals. This could breeak some existing code relying on specific locale to read floating numbers.
+
+* Changed behavior of item and eval in FUNCTION. They will not set last_result with their result. If you want to use last_result you should use call instead.
+* Added new set of classes NATURAL_8, NATURAL_16, NATURAL_32 and NATURAL_64 to perform unsigned integer operations.
+* Made implementations of cursor in descendants of CURSOR_STRUCTURE return a precise CURSOR type.
+* Reduced feature exportation of routines also used as creation procedures of CURSOR descendants to NONE
+* Removed make_sublist from TWO_WAY_LIST public creation procedures.
+* Made file_prunable from FILE obsolete. Use prunable instead.
+* Implemented features collect and full_collect of class MEMORY for .NET.
+* Changed type of feature sign in classes INTEGER_8 and INTEGER_16 to INTEGER_8 and INTEGER_16 respectively.
+* Added a subcluster refactoring with classes that can be helpful for performing code refactoring.
+* Augmented many features that are used to access items by their index (such as ARRAY.item and TABLE.item) with a bracket alias and an assigner command.
+
+===EiffelNet===
+* Enable to open an URL on a virtual host.
+* Enable to open an URL with login and password (for instance http://login:password@host/path/).
+* Fixed wrong URL analysis.
+
+===EiffelThread===
+* Added feature sleep to class THREAD_CONTROL.
+* Provided inheritance link between classes THREAD and THREAD_CONTROL on all platforms.
+
+===EiffelTime===
+* Breaking changes:
+** In time format, the use of hh12 alone without specifying AM or PM will default to AM.
+** Changed implementation of DATE_SET to use ordered_compact_date as storage.
+
+* Added support for [0]hh12 hour format.
+* Added support for specifying hh12 as a standalone format string.
+* Fixed a bug where calling TIME.make_by_fine_seconds would set fractional_second to zero rather than to the expected value.
+* In TIME, comparison of fractional_second is done using a precision of 1.0e-10.
+* Fixed is_positive in DATE_TIME_DURATION so that it is true when either the date or time is zero but the other is positive.
+* Fixed incorrect postcondition of set_origine_date_time in DATE_TIME_DURATION which would fail when argument was Void.
+* Fixed is_correct_date in DATE_VALIDITY_CHECKER to check that year is less than 65535.
+* Fixed DATE_TIME_PARSER when handling time in 12h format, but internally we would convert it into 24h format thus making is_time and is_date_time return False where True was expected.
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]]
+
+===WEL===
+* Made WEL 64 bits compliant. This required a breaking change in signatures. Some routines were actually using an INTEGER to represent a POINTER. On 64 bits platform this is not working as INTEGER is 32 bits and POINTER is 64 bits. As a consequence if you are using low level facilities of WEL your code might not compile anymore. Simply replace INTEGER by POINTER to make it compile.
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-57.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-57.wiki
new file mode 100644
index 00000000..1b07b859
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-57.wiki
@@ -0,0 +1,144 @@
+[[Property:title|Release notes for EiffelStudio 5.7]]
+[[Property:link_title|5.7]]
+[[Property:weight|-15]]
+==Graphical environment==
+
+===What's new===
+* Dual licensing of EiffelStudio both commercial and open-source.
+* Refactoring facilities: renaming and feature pull-up.
+* Metric engine. It lets you define more advanced metrics. This is the first result of our new query engine.
+* UUID library for generating UUID.
+* Process library for launching, waiting, redirecting outputs of processes.
+* Configuration system. It brings a new dimension to the way you manage multiple projects and simplifies it.
+
+===Improvements===
+* Output of C compilation now appears within the EiffelStudio environment.
+* Improved tool for launching external commands from within the EiffelStudio environment.
+* Introduced basic support for Unicode in Eiffel libraries, namely EiffelBase, EiffelVision2 and WEL.
+* Improved display of clusters, libraries and assemblies.
+* Added ability to see more relations in the diagram tool. For example, you can select a class and choose to see its descendants in the diagram.
+* If a project that needs a precompile is opened and the precompile does not exist it will automatically be compiled.
+* New projects use precompiles by default which speeds up the initial compilation.
+* Improved search facility that has two faces: a quick search bar in the editor for finding text in the current editor, and a search panel to perform exhaustive search over your project.
+* Profiler output is now sortable and can also be represented as a tree.
+* Redesigned completion engine:
+** Completion on wild-cards to quickly find a routine in a long list.
+** Completion list is now available anytime a text field accepts a class or an expression (Class creation dialog, debugger evaluation expression, ...)
+** On .NET, overloaded routines are all put together under one name.
+** Hidden option can now be set with a toolbar at its bottom.
+** Completion is available even if you have a syntax error in your class.
+
+* Formatters are now presenting results in a structured way with sorting capability.
+* Overridden classes are now shown with the list of classes they are overriding.
+
+===Changes===
+* New configuration system. EiffelStudio will automatically convert your existing ace or epr files to the new format.
+* Compilation progress is now displayed in the status bar and in the output pane, no more dialog box.
+* Display of errors and warnings is now done in different panes, so that you do not lose their content when the output pane has changed.
+* Pick and drop is now a dashed line.
+* Redesigned the starting dialog to make it easier to create new projects as well as managing many existing projects.
+
+===Bug fixes===
+* When in a different format than the editable format, one can now select a feature and it will bring you to the feature in the selected format, rather than going back to the editable format.
+* Fixed various formatting issue for our documentation format.
+* Fixed some memory corruption that could cause EiffelStudio to randomly crash.
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7|here]] for the compiler release notes.
+
+==Debugger==
+* Click [[Release notes for EiffelStudio 5.7 related to the debugger|here]] for the EiffelStudio's debugger release notes.
+
+==EiffelBuild==
+* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes.
+
+==Libraries==
+
+===EiffelBase===
+* STRING, STRING_8, STRING_32 and STRING_GENERAL:
+** Added Unicode support through the addition of STRING_32. For the moment Unicode support is limited to the data-structure.
+** Added STRING_GENERAL, a common ancestor to STRING_8 and STRING_32. It is useful if you want to handle both ASCII and Unicode string. For example this facility is used in EiffelVision2 and WEL.
+** STRING can be either STRING_8 or STRING_32 depending on your configuration. Default is STRING_8.
+** Added is_integer_xx, is_natural_xx, to_integer_xx and to_natural_xx where xx stands for 8, 16, 32 or 64.
+** Added is_number_sequence which is semantically identical to the behavior of is_integer in 5.6. Changed behavior of is_integer to check that it fits into a 32-bit integer value.
+** Updated is_double, is_real, is_real_32, is_real_64 so that the specification allows optional integral part or decimal part, but not both (as per the ECMA specification of a real constant). This fixes the bug where 1.e-4 was not considered a valid floating point value.
+** Changed behavior of is_boolean to match the ELKS specification which says the lower case version of the string should either be true or false.
+** Fixed issue in from_c_substring which would not properly if argument start_pos was greater than 1.
+
+* CHARACTER, CHARACTER_8 and CHARACTER_32:
+** Removed WIDE_CHARACTER and WIDE_CHARACTER_REF; they are replaced by CHARACTER_32 and CHARACTER_32_REF.
+
+* REAL_32 and REAL_64:
+** Renamed REAL into REAL_32, and DOUBLE into REAL_64. REAL can be either REAL_32 or REAL_64 depending on your configuration. Default is REAL_32.
+** Added rounded_xxx, floor_xxx and ceiling_xxx where xxx is the current floating point type, as the version returning an INTEGER is definitely not precise for large numbers.
+
+* SED serialization facility:
+** Fixed read_attributes in SED_INDEPENDENT_DESERIALIZER because we simply forgot to check that between the retrieved system and the stored system, a type has the same number of attributes.
+** Fixed wipe_out in SED_OBJECTS_TABLE' which did not reset last_index. As a consequence if you were doing several storing in a row, then last_index kept being incremented but when retrieving the data it would fail because it would expect last_index to start at 1, not at the last incremented value.
+** Changed SED_MEDIUM_READER_WRITER encoding so that it can also be used in a networking context. Basically now before sending the data, we first send the number of bytes of the data, and then the data. The old encoding is still available in SED_MEDIUM_READER_WRITER_1.
+
+* Added lock_marking and unlock_marking to use lock and unlock in INTERNAL in a multithreaded context. Currently used by the serialization classes.
+* IO_MEDIUM:
+** Added read_integer_XX, put_integer_XX, last_integer_xx and read_natural_XX, put_natural_XX, last_natural_XX where XX stands for 8, 16, 32, 64.
+
+* HASH_TABLE:
+** Fixed an infinite cycle when using replace_key with a key which is not present in the table.
+** Improved correct_mismatch to also retrieve HASH_TABLEs from version 5.4.
+** Prevented catcalls in HASH_TABLE when you have keys which have a different type.
+
+* Added a bracket feature to item from ARRAY2.
+* In ACTIVE_INTEGER_INTERVAL the action sequence will only be called if the range actually changes.
+* Fixed launch from EXECUTION_ENVIRONMENT to not inherit handles on Windows.
+* Moved list_eiffel3 and table_eiffel3 to the obsolete library.
+* Changed .NET implementation of the feature FILE.read_line to follow the behavior of the feature in classic mode and to treat either single '%N' or a sequence of '%R' and '%N' as an end of line.
+* Ensured that feature POINTER.out produces under .NET a hexadecimal number like in classic mode rather than a decimal number preceded by 0x.
+
+===EiffelNet===
+* Added in SOCKET read_integer_XX, put_integer_XX, last_integer_xx and read_natural_XX, put_natural_XX, last_natural_XX where XX stands for 8, 16, 32, 64.
+* Modified put and read in NETWORK_RESOURCE, FTP_PROTOCOL, HTTP_PROTOCOL, FILE_PROTOCOL so that the error checking code is not using socket_ok which might triggers error when there are none.
+* Improved handling of recipients and header_from in SMTP_PROTOCOL so that you can provide a nice `From' or `To' in the message since they are different from the addresses you have to pass from MAIL FROM and RCPT TO.
+* Improved error handling in EiffelNet. Now each time an error occurs you get an exception and the operating system error code is preserved.
+* Added ability to get the number of bytes read for all the read operation through the bytes_read query. This is useful to detect graceful shutdown of sockets.
+
+===EiffelThread===
+* Refactored the library so that even if you do not have the multithreaded option set, it will compile. However new preconditions have been added so that you know when you are using the library when you cannot.
+
+===EiffelVision2===
+* Added Unicode support. Read the WEL entry for Unicode below to see the impact on your code.
+* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]]
+
+===Process===
+* New library to launch processes and redirect their output.
+
+===UUID===
+* New library to generate UUID.
+
+===WEL===
+* Added Unicode support:
+** All routines taking an argument of type STRING or a generic type with STRING in one of the actual generic parameter have been changed to take an argument of type STRING_GENERAL which should not impact you at all, however make sure that if your redefine such a routine, you need to change the signature to STRING_GENERAL, otherwise you may introduce a CATCALL.
+** All queries of type STRING have been changed to STRING_32. Because STRING_32 should not be convertible to STRING, it would break a lot of existing code, as a result and only for a transition period, we made STRING_32 convert to STRING. In the next release this conversion will be marked obsolete, and in the release after the next it will be removed.
+** For queries whose type is a generic with STRING as one of the actual generic parameter, we changed STRING into STRING_32. Because no automatic conversion can be done in this case, we have introduced for a routine nnnnn following this pattern a new routine nnnnn_8 whose actual generic parameter is still STRING.
+
+* WEL_TREE_VIEW:
+** Fixed get_item_rect which was always returning a 0,0,0,0 rect as we were not correctly initializing the rect structure with the pointer to the item.
+** Added get_item_text_rect which returns a rect only for the text of the items.
+
+* WEL_WINDOWS_ROUTINES:
+** Improved window_of_item to reduce the number of cases where we might get an exception. This makes debugging easier.
+** Fixed resource_string_id which generated a call on Void target exception.
+
+* Added ability to have drop down menus in WEL_TOOL_BAR_BUTTON.
+* Added the ability to add an icon to the SystemTray.
+* Added ability to drop files to WEL_WINDOW components.
+* Made all contextual menus being selectable from both left and right click (formerly it was only left click).
+* Fixed issue with contextual menus which might not appear correctly, nor respond to click or Esc key properly because the menu is not at the front.
+* Fixed in WEL_LIST_VIEW a bug where if the text of the string is too long, it would be displayed but truncated.
+* Fixed incorrect result for title_bar_height in WEL_SYSTEM_METRICS.
+* Fixed a memory corruption due to Windows not sending a WM_DESTROY or WM_NCDESTROY message in all cases when a window is actually destroyed.
+* Fixed a bug in WEL_REGISTRY_KEY_VALUE.string_value that might cause assertion violation when a value is an empty string, because a check whether the last character is null was done without checking if string has at least one character.
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-60.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-60.wiki
new file mode 100644
index 00000000..1b0cdc8b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-60.wiki
@@ -0,0 +1,75 @@
+[[Property:title|Release notes for EiffelStudio 6.0]]
+[[Property:link_title|6.0]]
+[[Property:weight|-7]]
+==Graphical environment==
+
+===What's new===
+* New docking facilities which let you control the layout of tools in EiffelStudio. One can also lock the layout to prevent unwanted changes.
+* New tabbed editor.
+* Added configurable pick and drop which lets you choose between traditional context menu or pick and drop for a mouse right click operation.
+* EiffelStudio is now internationalized, it fully supports English, Chinese and German. A partial translation for French and Russian is provided.
+* Shortcuts can now be customized.
+* Added dependency view so supplier/client dependency of a group/folder/class can be investigated. Feature calls are included in dependency view.
+
+===Improvements===
+* The combo boxes in the address bar can now be resized to see more text (useful with long class names).
+* Added ability to add new classes/clusters/assemblies early on in the compilation phase instead of waiting for a successful compilation.
+* Faster rendering of EiffelStudio when running it through Remote Desktop.
+* Auto-completion after bracketed expression. i.e. arr [i].*
+* Added preference "Maximum processor usage" to dictate the maximum number of processors/cores to use when compiling c-code.
+* Updated metrics documentation, see [[Metrics tool|for more details]] .
+
+===Changes===
+* Changed the diagram default color from light yellow to white for consistency with the background color of other tools.
+* Improved history behavior.
+* Project settings such as arguments/working directory/location are now stored in a user specific location that does not depend on the UUID of the project, but on its path.
+* Favorites are now stored in the user settings.
+
+===Bug fixes===
+* EiffelStudio and various tools should better handle paths with spaces.
+* Fixed add assemblies dialog not showing assemblies such as mscorlib on 64 bit systems.
+* Fixed bug#12083 where classes in override clusters would not get recompiled properly when automatically saved by EiffelStudio when requesting a compilation.
+* More bug fixes can be seen at [http://dev.eiffel.com/EiffelStudio_6.0_Releases the EiffelStudio open source site] .
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0|here]] for the compiler release notes.
+
+==Debugger==
+* Click [[Release notes for EiffelStudio 6.0 related to the debugger|here]] for the EiffelStudio's debugger release notes.
+
+==EiffelBuild==
+* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes.
+
+==Libraries==
+
+===EiffelBase===
+* Fixed issue with LINKED_QUEUE.twin which would violate its invariant.
+* Revisited contracts of LINEAR_ITERATOR.
+* Added facilities to read/write REAL_32 and REAL_64 values in big and little endian format in MANAGED_POINTER.
+* Changed INTERNAL so that it does not have the is_pre_ecma_mapping_disabled attribute. If you were setting it to True, you should instead create an instance of ECMA_INTERNAL (fixes bug#11792).
+* HASH_TABLE:
+** Sped up HASH_TABLE iteration and lookup by about 8% or more.
+** Added two new possibilities to detect/prevent catcalls, they can be enabled by enabling assertion checking and enabling the debug clauses ''prevent_hash_table_catcall'' and ''detect_hash_table_catcall''.
+
+* TUPLE can now compare items using reference equality (=) or object comparison (is_equal).
+* Sped up SPECIAL.copy_data which was previously not inlined due to a change of signature preventing the inlining.
+* EXECUTION_ENVIRONMENT.get will only retrieve environment variable. It won't retrieve a value from the registry key on Windows (from HKLM\Software\ISE\Eiffelxx\app_name). This also means that MELT_PATH on Windows cannot be set in registry; this is not really a problem because now you do not need to set it since the W_code knows where to find it.
+
+===EiffelNet===
+* Updated reading routines of EiffelNet so that for all basic types they would read all the required bytes, not just stop after reading the first. This is important as in some very bad network situation or if you have some signals you could mess up the reading by only reading half of the expected bytes.
+
+===EiffelThread===
+* Fixed bug#12838 where on Linux you could not create more than 2^15 threads even if they all exited. Now we force creation of threads in a detached mode to allow more than 2^15 thread creations.
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]]
+
+===WEL===
+* Raised compatibility bar to Windows 2000 or greater. No more support for Windows 98 or NT 4.0.
+* Added ability to convert image formats among all image formats on Windows (using WEL_GDIP_BITMAP).
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-61.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-61.wiki
new file mode 100644
index 00000000..fba012e5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-61.wiki
@@ -0,0 +1,54 @@
+[[Property:title|Release notes for EiffelStudio 6.1]]
+[[Property:link_title|6.1]]
+[[Property:weight|-8]]
+==Graphical environment==
+
+===What's new===
+* New default layout for EiffelStudio tools to highlight the most common used tools whereas other tools are still available at the bottom or via the View menu.
+* New Errors and Warnings tool. It replaces the former Errors tool and Warnings tool and provides a nicer way to show errors and filtering them.
+* Revisited all the dialogs to provide a nicer and consistent look and feel.
+* Multiple errors are reported for each compilation degree.
+
+===Improvements===
+* Use the default OS font for displaying tooltips.
+* C compilation failure will now show up as an error in the new Errors and Warnings tool.
+* Completion list will now show immediately after pressing '.' when the completion list is active.
+* Added ability to submit a problem report within EiffelStudio when it quits unexpectedly.
+
+===Changes===
+* Support for the MinGW C compiler on Windows 32-bit. Borland is officially not supported anymore.
+* Completion list no longer shows obsolete items by default (set via a preference option).
+
+===Bug fixes===
+* Fixed incorrect results when using the profiler with a finalized system.
+* More bug fixes can be seen at [http://dev.eiffel.com/EiffelStudio_6.1_Releases the EiffelStudio open source site] .
+
+==Compiler==
+* Click [[Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1|here]] for the compiler release notes.
+
+==Debugger==
+* Click [[Release notes for EiffelStudio 6.1 related to the debugger|here]] for the EiffelStudio debugger release notes.
+
+==EiffelBuild==
+* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes.
+
+==Libraries==
+
+===EiffelBase===
+* BINARY_SEARCH_TREE: Added tree_item which matches the item being searched.
+* LINEAR: Added item_for_iteration as a synonym of item.
+* STRING_8 and STRING_32:
+** Improved speed of the to_xxx routines.
+** Added starts_with and ends_with.
+
+* GC_INFO: Fixed non working computation of CPU time usage on Windows and added two new queries (cpu_total_time and sys_total_time) to find out the total CPU execution time of the program at the last GC cycle.
+* MEMORY: Added execute_without_collection to execute a procedure with no GC.
+
+===EiffelVision2===
+* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]]
+
+[[EiffelStudio release notes|Click here to check out what was new in other versions]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-62.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-62.wiki
new file mode 100644
index 00000000..fef288ab
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-62.wiki
@@ -0,0 +1,62 @@
+[[Property:title|Release notes for EiffelStudio 6.2]]
+[[Property:link_title|6.2]]
+[[Property:weight|-9]]
+==Graphical environment==
+
+===What's new===
+* Added new contract editor tool to ease edition of contracts on routines and classes.
+* Added Eiffel Information System which let you connect external documentation to your Eiffel code and vice versa.
+* Added ability to avoid comment duplication by using the
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Descendants|Descendants]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/attributes.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/attributes.wiki
new file mode 100644
index 00000000..f0f40e5d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/attributes.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Attributes]]
+[[Property:weight|-5]]
+The attributes view [[Image:class-features-attribute-icon]] displays all the attributes of the current class, including inherited attributes.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Routines|Routines]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-basic-text-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-basic-text-view.wiki
new file mode 100644
index 00000000..059a3103
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-basic-text-view.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Class formatters: Basic text view]]
+[[Property:weight|-14]]
+Basic text view [[Image:view-editor-icon]] is the only editable view; this is why it is only available through the [[EiffelStudio Editor|editor]] .
+
+[[Image:class-mini-format-bar]]
+This is also the view selected by default when the editor is opened for the first time.
+In this view, most of the development objects are [[Pick-and-drop mechanism|clickable]] , except for special cases like assertions, anchored types, identifiers within a comment line... for which the [[Clickable view|clickable view]] might be needed.
+
+'''Note''': The generated text is not editable, but it is compilable. This view is not available to .NET classes which are imported through by means of an assembly. This is because the assembly .exe or .dll exposes only the interface methods and therefore is no implementation to display. Such classes may be viewed, in a clickable format using the Contract View or Interface View.
+
+{{seealso| '''See Also'''
+[[EiffelStudio Editor|Editor]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-external-features.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-external-features.wiki
new file mode 100644
index 00000000..e49535e2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-external-features.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Class formatters: External features]]
+[[Property:weight|1]]
+The external view [[Image:class-features-external-icon]] displays all the external features of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-flat-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-flat-view.wiki
new file mode 100644
index 00000000..fed4fe96
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-flat-view.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Class formatters: Flat view]]
+[[Property:weight|-12]]
+The flat view [[Image:view-flat-icon]] displays all the features for the current class, i.e. including both written-in and inherited features; it is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] . This is also the only view where [[Breakpoints|breakpoints]] are displayed.
+
+{{warning| '''Caution''': For classes with many [[Ancestors|ancestors]] , computation of the flat view may require a few seconds. }}
+
+{{note| '''Note''': This view is not available to .NET classes which are imported through by means of an assembly. This is because the assembly .exe or .dll exposes only the interface methods and therefore is no implementation to display. Such classes may be viewed, in a clickable format using the Contract View or Interface View. }}
+
+{{seealso| '''See Also'''
+[[Flat Contract view|Flat Contract view]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clickable-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clickable-view.wiki
new file mode 100644
index 00000000..cfb527dd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clickable-view.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Clickable view]]
+[[Property:weight|-13]]
+The clickable view [[Image:view-clickable-icon]] allows to [[Pick-and-drop mechanism|pick]] every class or feature name in the class text and is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{note| '''Note''': This view is not available to .NET classes which are imported through by means of an assembly. This is because the assembly .exe or .dll exposes only the interface methods and therefore is no implementation to display. Such classes may be viewed, in a clickable format using the Contract View or Interface View. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clients.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clients.wiki
new file mode 100644
index 00000000..20f1a6e9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clients.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Clients]]
+[[Property:weight|-7]]
+The clients view [[Image:class-clients-icon]] displays all the classes which are using features of the current class, and thus rely on its [[Flat Contract view|interface]] .
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Suppliers|Suppliers]]
+[[Callers|Feature callers]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/contract-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/contract-view.wiki
new file mode 100644
index 00000000..4e658206
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/contract-view.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Contract view]]
+[[Property:weight|-11]]
+The contract view [[Image:view-contracts-icon]] displays the contracts of all written-in features of the current class. It is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Flat Contract view|Flat contract view]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/creators.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/creators.wiki
new file mode 100644
index 00000000..b98a3ebf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/creators.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Creators]]
+[[Property:weight|-2]]
+The creators view [[Image:class-features-creator-icon]] displays all the creation procedure signatures of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/deferred-features.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/deferred-features.wiki
new file mode 100644
index 00000000..d12a2929
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/deferred-features.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Deferred features]]
+[[Property:weight|-1]]
+The deferred view [[Image:class-features-deferred-icon]] displays all the deferred features of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/descendants.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/descendants.wiki
new file mode 100644
index 00000000..4c126e7f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/descendants.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Descendants]]
+[[Property:weight|-8]]
+The descendants view [[Image:class-descendents-icon]] displays all the classes which inherit from the current class,directly or not, using a tree-like indented layout.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Ancestors|Ancestors]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/exported-features.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/exported-features.wiki
new file mode 100644
index 00000000..f9d481b9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/exported-features.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Exported features]]
+[[Property:weight|2]]
+The exported view [[Image:class-features-exported-icon]] displays all the features of the current class that all other classes may call.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/flat-contract-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/flat-contract-view.wiki
new file mode 100644
index 00000000..d4ff2e3c
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/flat-contract-view.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Flat Contract view]]
+[[Property:weight|-10]]
+The Flat Contract view [[Image:view-flat-contracts-icon]] displays the contracts of all written-in and inherited features of the current class. It is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{warning| '''Caution''': For classes with many [[Ancestors|ancestors]] , computation of the Flat Contract view may require a few seconds. }}
+
+{{seealso| '''See Also'''
+[[Class formatters: Flat view|Flat view]]
+[[Contract view|Contract view]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/index.wiki
new file mode 100644
index 00000000..03ab4638
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/index.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Class views]]
+[[Property:weight|1]]
+* [[Class formatters: Introduction|Introduction]]
+* [[Class formatters: Basic text view|Basic text view]]
+* [[Clickable view|Clickable view]]
+* [[Class formatters: Flat view|Flat view]]
+* [[Contract view|Contract view]]
+* [[Flat Contract view|Flat Contract view]]
+* [[Ancestors|Ancestors]]
+* [[Descendants|Descendants]]
+* [[Clients|Clients]]
+* [[Suppliers|Suppliers]]
+* [[Attributes|Attributes]]
+* [[Routines|Routines]]
+* [[Deferred features|Deferred features]]
+* [[Once routines and constants|Once routines and constants]]
+* [[Class formatters: External features|External features]]
+* [[Exported features|Exported features]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/invariants.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/invariants.wiki
new file mode 100644
index 00000000..7b936cce
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/invariants.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Invariants]]
+[[Property:weight|-3]]
+The invariants view [[Image:class-features-invariant-icon]] displays all the invariants of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/once-routines-and-constants.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/once-routines-and-constants.wiki
new file mode 100644
index 00000000..a02bc48f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/once-routines-and-constants.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Once routines and constants]]
+[[Property:weight|0]]
+The once view [[Image:class-features-once-icon]] displays all the [[Routines|routines]] declared as '''once''' and the constant [[Attributes|attributes]] in the current class (or in its [[Ancestors|ancestors.]] ).
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/routines.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/routines.wiki
new file mode 100644
index 00000000..8eb16b04
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/routines.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Routines]]
+[[Property:weight|-4]]
+The routines view [[Image:class-features-routine-icon]] displays all the routine signatures of the current class, including inherited routines.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Attributes|Attributes]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/suppliers.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/suppliers.wiki
new file mode 100644
index 00000000..46278b52
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/suppliers.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Suppliers]]
+[[Property:weight|-6]]
+The suppliers view [[Image:class-supliers-icon]] displays all the classes from which the current class is calling features.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] .
+
+{{seealso| '''See Also'''
+[[Clients|Clients]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-ancestor-versions.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-ancestor-versions.wiki
new file mode 100644
index 00000000..ec6f04ac
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-ancestor-versions.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Ancestor versions]]
+[[Property:link_title|Feature formatters: Ancestor versions]]
+[[Property:weight|10]]
+The ancestor view [[Image:feature-ancestors-icon]] displays all the features which the current feature is redefining.
+
+{{seealso| '''See Also'''
+[[Descendant versions|Descendant versions]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-basic-text-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-basic-text-view.wiki
new file mode 100644
index 00000000..021a4a33
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-basic-text-view.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Feature formatters: Basic text view]]
+[[Property:weight|1]]
+Basic text view [[Image:view-editor-feature-icon]] displays the text of the current feature as it is written in the enclosing class.
+It does not work with [[Breakpoints|breakpoints]] ; in order to do this the [[Feature formatters: Flat view|flat view]] has to be used.
+
+'''Note''': This view is not available to .NET features which are imported through by means of an assembly. This is because the assembly .exe or .dll exposes only the interface methods and therefore is no feature implementation to display. The feature interface may be viewed, in a clickable format using the Flat View.
+
+{{seealso| '''See Also'''
+[[Class formatters: Basic text view|Class basic text view]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callers.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callers.wiki
new file mode 100644
index 00000000..99d14e92
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callers.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Callers]]
+[[Property:link_title|Feature formatters: Callers]]
+[[Property:weight|3]]
+The callers view [[Image:feature-callers-icon]] display all the features which are calling the current feature. It is possible to choose in the preferences if callers of the descendants should be displayed too (they are by default).
+
+{{seealso| '''See Also'''
+[[Clients|Class clients view]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-descendant-versions.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-descendant-versions.wiki
new file mode 100644
index 00000000..eb4ab67f
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-descendant-versions.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Descendant versions]]
+[[Property:link_title|Feature formatters: Descendant versions]]
+[[Property:weight|11]]
+The descendant view [[Image:feature-descendents-icon]] displays all the features that redefine the current feature.
+
+{{seealso| '''See Also'''
+[[Ancestor versions|Ancestor versions]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-flat-view.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-flat-view.wiki
new file mode 100644
index 00000000..d16de744
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-flat-view.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Feature formatters: Flat view]]
+[[Property:weight|2]]
+The clickable view [[Image:view-clickable-feature-icon]] displays the feature body as it is seen at run-time (according to ancestor versions, if any). This is why it is possible to add or remove [[Breakpoints|breakpoints]] in this view.
+
+{{seealso| '''See Also'''
+[[Class formatters: Flat view|Class flat view]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-homonyms.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-homonyms.wiki
new file mode 100644
index 00000000..840cad9d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-homonyms.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Homonyms]]
+[[Property:link_title|Feature formatters: Homonyms]]
+[[Property:weight|12]]
+The homonyms view [[Image:feature-homonyms-icon]] displays all the features in the system which have the same name as the current feature.
+
+{{warning| '''Caution''': This operation may take a long time if the system has a lot of classes. }}
+
+{{seealso| '''See Also'''
+[[Implementers|Implementers]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-implementers.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-implementers.wiki
new file mode 100644
index 00000000..49517cf8
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-implementers.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Implementers]]
+[[Property:link_title|Feature formatters: Implementers]]
+[[Property:weight|9]]
+The implementers view [[Image:feature-implementers-icon]] displays all the different versions of the current feature by exploring the [[Ancestor versions|ancestor versions]] and the [[Descendant versions|descendant versions]] , and selecting among those the ones which are not inherited.
+
+{{seealso| '''See Also'''
+[[Ancestor versions|Ancestor versions]]
+[[Descendant versions|Descendant versions]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/index.wiki
new file mode 100644
index 00000000..7c67c909
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Feature views]]
+[[Property:weight|2]]
+* [[Feature formatters: Introduction|Introduction]]
+* [[Feature formatters: Basic text view|Basic text view]]
+* [[Feature formatters: Flat view|Flat view]]
+* [[Callers|Callers]]
+* [[Implementers|Implementers]]
+* [[Ancestor versions|Ancestor versions]]
+* [[Descendant versions|Descendant versions]]
+* [[Homonyms|Homonyms]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/index.wiki
new file mode 100644
index 00000000..da801f4d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Formatted information about compiled classes and features]]
+[[Property:weight|2]]
+* [[Formatters: Introduction|Introduction]]
+* [[Class views|Class views]]
+* [[Feature views|Feature views]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/index.wiki
new file mode 100644
index 00000000..b10407a0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/index.wiki
@@ -0,0 +1,23 @@
+[[Property:title|EiffelStudio Reference]]
+[[Property:weight|2]]
+* [[EiffelStudio Introduction|EiffelStudio Introduction]]
+* [[Release notes for EiffelStudio 6.2|What's new in EiffelStudio 6.2]]
+* [[EiffelStudio: General interface description|General interface description]]
+* [[Browsing tools|Browsing tools]]
+* [[EiffelStudio Editor|EiffelStudio Editor]]
+* [[EiffelStudio: Project settings window|Project settings]]
+* [[Compiler|Compiler]]
+* [[EiffelStudio Debugger|EiffelStudio Debugger]]
+* [[Error List Tool|Error List Tool]]
+* [[Diagram tool|Diagram tool]]
+* [[Metrics tool|Metrics tool]]
+* [[Console tool|Console tool]]
+* [[C Output tool|C Output tool]]
+* [[Wizards and dialogs|Wizards and dialogs]]
+* [[Formatted information about compiled classes and features|Formatted information about compiled classes and features]]
+* [[EiffelStudio Preferences|Preferences]]
+* [[Command line|Command line]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/attributes-metrics-and-measures.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/attributes-metrics-and-measures.wiki
new file mode 100644
index 00000000..5afccf8e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/attributes-metrics-and-measures.wiki
@@ -0,0 +1,37 @@
+[[Property:title|Attributes, metrics and measures]]
+[[Property:weight|1]]
+The most general notion is "attribute":
+
+{{note| '''Attribute''': An '''attribute''' is a property, qualitative or quantitative, of software products or processes. }}
+
+We may distinguish between the product and process cases:
+
+{{note| '''Product attribute, process attribute''': A '''product attribute''' is an attribute that characterizes a software product or set of products. A '''process attribute''' is an attribute that characterizes a software-related process, such as development, maintenance, documentation, management, or multiple instances of such a process. }}
+
+Examples of attributes include reliability (a product attribute, non-quantitative) and total project cost (process, quantitative).
+
+A metric is simply a quantitative attribute:
+
+{{note| '''Metric''': A '''metric''' is an attribute whose values are numbers (integers or reals), expressed relative to a certain '''unit''' specified as part of the metric definition. }}
+
+Examples of metrics include the number of source lines of a program (product) and the total cost of a project (process). The metric tool provides by default a set of metrics, they are available in the Metric Evaluation tab of the metric tool
+
+Attributes other than metrics will be called "qualitative":
+
+{{note| '''Qualitative attribute''': A '''qualitative attribute''' is an attribute other than a metric. }}
+
+An example of qualitative attribute is the reliability of a software product.
+
+The "process" vs. "product" distinction carries over to metrics:
+
+{{note| '''Product metric, process metric''': A metric is a '''product metric''' if it is a product attribute, a '''process metric''' if it is a process attribute. }}
+
+"Relevance", as defined in the previous section, suggests that the purpose of metrics is to help us gain information about attributes that are of direct interest to us. Often these will be qualitative; for example we may want to estimate the reliability of our software. Metrics provide us with numerical values that can serve to assess or predict such attributes.
+
+Applying a metric will give us measures:
+
+{{note| '''Measure''':A '''measure''' is the value of a metric for a certain process or product. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/criterion-references.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/criterion-references.wiki
new file mode 100644
index 00000000..59812ebd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/criterion-references.wiki
@@ -0,0 +1,760 @@
+[[Property:title|Criterion References]]
+[[Property:weight|12]]
+==Text Criterion==
+
+'''name_is'''
+'''Syntax:''' name_is "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will evaluate to True if name of the candidate code element matched the given pattern. For more details about matching strategy and case-sensitivity modifier, see the documentation of text criterion.
+
+'''text_is'''
+'''Syntax:''' text_is "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will evaluate to True if text of a candidate code element matches the given pattern.
+
+'''top_indexing_contain'''
+'''Syntax:''' top_indexing_contain "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if text (indexing tags are not included) of the top indexing clause in the candidate class matches the given pattern.
+
+'''top_indexing_has_tag'''
+'''Syntax:''' top_indexing_has_tag "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if tags of the top indexing clause in the candidate class matches the given pattern.
+
+'''bottom_indexing_contain'''
+'''Syntax:''' bottom_indexing_contain "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:'''This criterion will evaluate to True if text (indexing tags are not included) of the bottom indexing clause in the candidate class matches the given pattern.
+
+'''bottom_indexing_has_tag'''
+'''Syntax:''' bottom_indexing_has_tag "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:'''This criterion will evaluate to True if tags of the bottom indexing clause in the candidate class matches the given pattern.
+
+'''indexing_contain'''
+'''Syntax:''' indexing_contain "pattern", matching strategy, case-sensitivity
+'''Applicable on:'''Class
+'''Remark:'''This criterion will evaluate to True if (top or bottom) indexing clause matches the given pattern.
+
+'''indexing_has_tag'''
+'''Syntax:''' indexing_has_tag "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if tag of (top or bottom) indexing clause of the candidate class matches the given pattern.
+
+==Path Criterion==
+
+'''path_in'''
+'''Syntax:''' path_in "path"
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if path (related to the class's written in group) of the class candidate is "path" or its subdirectory. "path" is in Unix format, i.e., different sections are separated by a "/". On Windows, path matching is case-sensitive, on other platforms, it's case-sensitive.
+
+'''path_is'''
+'''Syntax:''' path_is "path"
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if path (related to the class's written in group) of the class candidate is "path". "path" is in Unix format, i.e., different sections are separated by a "/". On Windows, path matching is case-sensitive, on other platforms, it's case-sensitive.
+
+==Relation Criterion==
+
+'''ancestor_is'''
+'''Syntax:''' ancestor_is {domain}
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if candidate class (or feature) is descendant of any (if more than one are possible) of the class (or feature) specified in the criterion domain.
+For example, in a class metric,
+{{note|ancestor_is {STRING_8}}}
+
+will evaluate to True when a candidate class is a descendant of class STRING_8.
+In a class metric,
+{{note|ancestor_is {LINKED_LIST, DS_LINKED_LIST} }}
+will evaluate to True when a candidate class is a descendant of either LINKED_LIST or DS_LINKED_LIST.
+
+'''proper_ancestor_is'''
+'''Syntax:''' proper_ancestor_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if a candidate class is a proper descendant of any of the classes in criterion domain. First, let's use the following figure to demonstrate the concepts of ancestor, proper ancestor, parent and indirect parent. (Note: the hierarchy is not complete)
+
+[[Image:class-hie|class hierarchy]]
+Ancestors of STRING_32 are: STRING_32, STRING_GENERAL, INDEXABLE, COMPARABLE and PART_COMPARABLE.
+Proper ancestors of STRING_32 are STRING_GENERAL, INDEXABLE, COMPARABLE and PART_COMPARABLE.
+Parents of STRING_32 are: STRING_GENERAL and INDEXABLE
+Indirect parents of STRING_32 are: COMPARABLE and PARTCOMPARABLE
+The related concepts of descendants, proper descendants, heirs, indirect heirs follow the same rule but are in the reversed direction.
+
+
+'''descendant_is'''
+'''Syntax:''' descendant_is {domain}
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion evaluates to True if candidate class is or feature is ancestor of any (if more than one are possible) of the class or feature specified in the criterion domain.
+
+
+'''proper_descendant_is'''
+'''Syntax:''' proper_descendant_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a proper ancestor of any of the classes in criterion domain.
+
+
+'''parent_is'''
+'''Syntax:''' parent_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a heir of any of the classes in criterion domain.
+
+
+'''indirect_parent_is'''
+'''Syntax:''' indirect_parent_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a indirect heir of any of the classes in criterion domain.
+
+
+'''heir_is'''
+'''Syntax:''' heir_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a parent of any of the classes in criterion domain.
+
+
+'''indirect_heir_is'''
+'''Syntax:''' indirect_heir_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a indirect parent of any of the classes in criterion domain.
+
+
+'''client_is'''
+'''Syntax:''' client_is {domain}, directness, normally_referenced, syntactically_referenced
+'''Applicable on:''' Class
+'''Remarks:''' This criterion evaluates to True if a candidate class is supplier of any of the classes in criterion domain. Directness modifier is boolean modifier, if it's True only direct suppliers are picked, if indirect modifier is set, only indirect suppliers are picked. normally_referenced and syntactically_referenced modifiers are both boolean modifiers, they enable to specify how one class is used by another class. Let's use an example to demonstrate these ideas, for example, in class A, there is a feature foo:
+
+ foo is
+ local
+ l_str: STRING
+ l_file: FILE
+ do
+ create l_str.make_empty
+ end
+
+
+Then both STRING and FILE are suppliers of class A. STRING is normal supplier because a feature make_empty in STRING is invoked in class A, but FILE is a syntactically referenced supplier because no feature from FILE is called from A. Classes explicitly listed in inherit clause of a class are also considered as syntactically referenced suppliers.
+Concepts of direct/indirect, normally referenced/syntactically referenced clients follow the same rule expect in the other direction.
+
+
+'''supplier_is'''
+'''Syntax:''' supplier_is {domain}, directness, normally_referenced, syntactically_referenced
+'''Applicable on:''' Class
+'''Remark:'''
+This criterion evaluates to True if a candidate class is client of any of the classes in criterion domain.
+For more information of directness modifier, normally_referenced modifier and syntactically_referenced modifier, see document for relation criterion client_is
+
+
+'''callee_is'''
+'''Syntax:''' callee_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature is calling any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+
+
+'''caller_is'''
+'''Syntax:''' caller_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature is called by any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+
+
+'''assignee_is'''
+'''Syntax:''' assignee_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature assigns to any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+
+
+'''assigner_is'''
+'''Syntax:''' assigner_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature assigns to any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+
+
+'''createe_is'''
+'''Syntax:''' createe_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature creates any of the feature (must be an attribute) listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+
+
+'''creator_is'''
+'''Syntax:''' creator_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature (must be an attribute) is created by any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+
+
+'''is_exported_to'''
+'''Syntax:''' is_exported_to {domain}
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class is exported to all the classes listed in criterion domain.
+
+
+'''is_implementors_of'''
+'''Syntax:''' is_implementors_of {domain}
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an implementer of some features listed in criterion domain.
+
+
+'''return_type_is'''
+'''Syntax:''' return_type_is {domain}
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if associated class of the return type of the candidate feature is listed in criterion domain.
+
+
+==Value Criterion==
+
+''' value_of_metric_is'''
+'''Syntax:''' value_of_metric_is '''Metric''', {domain}, value_tester
+''' Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:'''The '''Metric''' modifier will be a specified metric name. This criterion will evaluate to True if the calculated metric (from metric modifier) over input domain (from criterion domain) satisfies some given value tester (from value_tester modifier).
+For example, if we want to find classes whose code is over 1000 lines, we can create the following metric and run it over input domain {Application target}:
+
+[[Image:value-of-metric-is|Actual semantic for input domain item]]
+
+[[Image:value-tester|Actual semantic for input domain item]]
+
+In the above dialog, you can customize the value_of_metric_is criterion. A metric needs to be specified as well as its input domain. Sometimes, "Delayed item" is set in the input domain meaning that no matter what the current candidate code element is, use it as input domain to the selected metric and calculate that metric to see if it's value satisfies the given value testers which are also set in this dialog.
+
+You can specify more than one value tester and they can be anded (when "Match all" is selected) or ored (when "Match any" is selected). if no value tester is set, the value_of_metric_is criterion always evaluates to True.
+
+This metric reads, for every class from application target, calculate metric '''Lines of code''' over that class (this is the usage of "Delayed item"), and if the value of '''Lines of code''' over that class is larger than 1000, that class satisfies the '''value_of_metric_is''' criterion thus it's included in the result.
+
+Let's see another example of value_of_metric_is criterion which is more complicated and involves the use of the "Use external delayed domain" option.
+
+Suppose we are to construct a metric called '''Unused features''' which can finds unused features. First, it must be a feature metric because we want features in the result. Second, for every feature candidate, we want a predicate which evaluates to True if that candidate feature is not called by any feature.
+
+And this predicate is semantically equal to say: count all callers of the candidate feature and check if the value is zero. So now, we realize that we need a metric which returns the number of callers of a given feature.
+
+We can construct this feature metric as follows:
+
+[[Image:callee-is|value criterion]]
+
+Let's call it "callee_is" (note: here callee_is is a metric name instead of a criterion name). It uses "Delayed item" because we want that "Delayed item" to be replaced by the actual candidate feature at run-time.
+
+Then we can construct our '''Unused features''' metric as follows:
+
+[[Image:unused-feature|value criterion]]
+
+[[Image:unused-feature-criterion|value criterion]]
+
+In this dialog, note that the "Use external delayed domain" option is checked. It has to be checked. Let's see why.
+
+This value_of_metric_is criterion should check this: for every candidate feature, test if the number of callers of that feature in current application target scope is zero.
+
+Suppose now a feature named foo is the candidate feature.
+
+If the "Use external delayed domain" is not checked, then the metric '''callee_is''' is calculated over input domain {application target}.
+
+So when calculate callee_is metric, every feature (let's call the current candidate feature APPLICATION.goo) from current application target is checked to see if it satisfies the criterion: callee_is {APPLICATION.goo} (the "Delayed item" is replaced by the current candidate feature). This is actually checking if a feature is called by itself.
+
+As you can see, if "Use external delayed domain" option is not checked, during the period of value_of_metric_is criterion evaluation, the current feature candidate from the '''Unused features''' metrics is never involved. This of course yields wrong result.
+
+Now we select the "Use external delayed domain" option. Recall that current candidate feature of metric '''Unused features''' is APPLICATION.foo.
+
+When the value_of_metric_is criterion is evaluated, the delayed item from metric '''callee_is''' is replaced by APPLICATION.foo. So the metric '''callee_is''' now is equal to:
+
+[[Image:fake-callee-is|value criterion]]
+
+which reads: calculate the number of callers of feature APPLICATION.foo. And the value_of_metric_is criterion is now semantically equal to: test if number of callers of APPLICATION.foo is zero. This is what we want.
+
+As we can see, when the option "Use external delayed domain" is selected, the delayed item from the criterion metric will be replaced by the current candidate code element. Otherwise, it will be replaced by the candidate element from criterion metric input domain when criterion metric is calculated.
+
+
+==Normal Criterion==
+
+'''false'''
+'''Syntax:''' false
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will always evaluate to False.
+
+
+'''has_argument'''
+'''Syntax:''' has_argument
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has arguments.
+
+
+'''has_assertion'''
+'''Syntax:''' has_assertion
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has any precondition or postcondition.
+
+
+'''has_assigner'''
+'''Syntax:''' has_assigner
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature (must be an attribute then) has assigner.
+
+
+'''has_bottom_indexing'''
+'''Syntax:''' has_bottom_indexing
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if candidate class has bottom indexing.
+
+
+'''has_comment'''
+'''Syntax:''' has_comment
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if candidate feature has header comment.
+
+
+'''has_constraint'''
+'''Syntax:''' has_constraint
+'''Applicable on:''' Generic
+'''Remark:''' This criterion will evaluate to True if the candidate generic has constraint.
+
+
+'''has_creation_constraint'''
+'''Syntax:''' has_creation_constraint
+'''Applicable on:''' Generic
+'''Remark:''' This criterion will evaluate to True if the candidate generic has creation constraint
+
+
+'''has_expression'''
+'''Syntax:''' has_expression
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion has associated expression.
+
+
+'''has_indexing'''
+'''Syntax:''' has_indexing
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature has indexing clause.
+
+
+'''has_immediate_invariant'''
+'''Syntax:''' has_immediate_invariant
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class has immediate invariant clause (not inherited invariant clause).
+
+
+'''has_local'''
+'''Syntax:''' has_local
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has locals defined in it.
+
+
+'''has_postcondition'''
+'''Syntax:''' has_postcondition
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has immediate postconditions.
+
+
+'''has_precondition'''
+'''Syntax:''' has_precondition
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has immediate preconditions.
+
+
+'''has_rescue'''
+'''Syntax:''' has_rescue
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has rescue clause.
+
+
+'''has_tag'''
+'''Syntax:''' has_tag
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate has a descriptive tag associated with it.
+
+
+'''has_top_indexing'''
+'''Syntax:''' has_top_indexing
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class has top indexing clause.
+
+
+'''is_always_compiled'''
+'''Syntax:''' is_always_compiled
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is an always compiled class. Some basic class such as INTEGER, REAL are always compiled no matter whether they are used in an application. These class will cause is_always_compiled criterion evaluate to True.
+
+
+'''is_assembly'''
+'''Syntax:''' is_assembly
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is an assembly.
+
+
+'''is_attribute'''
+'''Syntax:''' is_attribute
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an attribute.
+
+
+'''is_blank'''
+'''Syntax:''' is_blank
+'''Applicable on:''' Line
+'''Remark:''' This criterion will evaluate to True if the candidate line is blank.
+
+
+'''is_cluster'''
+'''Syntax:''' is_cluster
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is a cluster.
+
+
+'''is_command'''
+'''Syntax:''' is_command
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a command.
+
+
+'''is_comment'''
+'''Syntax:''' is_comment
+'''Applicable on:''' Line
+'''Remark:''' This criterion will evaluate to True if the candidate line is comment line.
+
+
+'''is_compiled'''
+'''Syntax:''' is_compiled
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will evaluate to True if the candidate code element is compiled. Target, group are considered to be compiled once they are referenced by the application. Class (if it is not an always-compiled class) is considered to be compiled if it's used somewhere in the application. always-compiled class are always compiled. and the compilation status of generic, feature, assertion, argument local and line are determined by the compilation status of their written in class.
+
+
+'''is_constant'''
+'''Syntax:''' is_constant
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a constant.
+
+
+'''is_creator'''
+'''Syntax:''' is_creator
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a creator feature.
+
+
+'''is_deferred'''
+'''Syntax:''' is_deferred
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is deferred
+
+
+'''is_effective'''
+'''Syntax:''' is_effective
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature is effective.
+
+
+'''is_ensure'''
+'''Syntax:''' is_ensure
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in ensure clause.
+
+
+'''is_ensure_then'''
+'''Syntax:''' is_ensure_then
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in ensure then clause.
+
+
+'''is_enum'''
+'''Syntax:''' is_enum
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is an enumeration. Only has effect on .NET platform, on other platforms, this criterion always evaluates to False.
+
+
+'''is_expanded'''
+'''Syntax:''' is_expanded
+'''Applicable on:''' Class, Generic
+'''Remark:''' This criterion will evaluate to True if the candidate class or generic is expanded.
+
+
+'''is_exported'''
+'''Syntax:''' is_exported
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is exported to ANY.
+
+
+'''is_external'''
+'''Syntax:''' is_external
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature is external.
+
+
+'''is_feature'''
+'''Syntax:''' is_feature
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is real feature. In metrics tool, invariant is treated as a special kind of feature. So if you count features in a class, it's invariant clause will be included. is_feature criterion is used to filter invariant clause out.
+
+
+'''is_from_any'''
+'''Syntax:''' is_from_any
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is from class ANY.
+
+
+'''is_frozen'''
+'''Syntax:''' is_frozen
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is frozen.
+
+
+'''is_function'''
+'''Syntax:''' is_function
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate is a function.
+
+
+'''is_generic'''
+'''Syntax:''' is_generic
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is a generic class.
+
+
+'''is_hidden'''
+'''Syntax:''' is_hidden
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is exported to NONE.
+
+
+'''is_immediate'''
+'''Syntax:''' is_immediate
+'''Applicable on:''' Feature, Assertion, Argument, Local
+'''Remark:''' This criterion will evaluate to True if the candidate code element is immediate instead of inherited.
+
+
+'''is_implementation_comment'''
+'''Syntax:''' is_implementation_comment
+'''Applicable on:''' Line
+'''Remark:''' This criterion will evaluate to True if the candidate line is implementation comment. Implementation comment is also called commented code. In Eiffel, the convention is that if the comment indicator "--" starts from the first column of a line, that line is an implementation comment line.
+
+
+'''is_infix'''
+'''Syntax:''' is_infix
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is infix.
+
+
+'''is_invariant'''
+'''Syntax:''' is_invariant
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is from invariant clause.
+
+
+'''is_invariant_feature'''
+'''Syntax:''' is_invariant_feature
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an invariant. See the description of criterion is_feature for more detail.
+
+
+'''is_library'''
+'''Syntax:''' is_library
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is a library.
+
+
+'''is_obsolete'''
+'''Syntax:''' is_obsolete
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature is obsolete.
+
+
+'''is_once'''
+'''Syntax:''' is_once
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is once.
+
+
+'''is_origin'''
+'''Syntax:''' is_origin
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is origin instead of a inherited one.
+
+
+'''is_override'''
+'''Syntax:''' is_override
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group overrides some other group.
+
+
+'''is_overriden'''
+'''Syntax:''' is_overriden
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is overridden by some other class.
+
+
+'''is_overrider'''
+'''Syntax:''' is_overrider
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class overrides some other class.
+
+
+'''is_partial'''
+'''Syntax:''' is_partial
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is partical class. Only has effect on .NET platform, on other platforms, this criterion always evaluates to False.
+
+
+'''is_postcondition'''
+'''Syntax:''' is_postcondition
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is a postcondition.
+
+
+'''is_precompiled'''
+'''Syntax:''' is_precompiled
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is precompiled.
+
+
+'''is_precondition'''
+'''Syntax:''' is_precondition
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is a precondition.
+
+
+'''is_prefix'''
+'''Syntax:''' is_prefix
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate is a prefix.
+
+
+'''is_procedure'''
+'''Syntax:''' is_procedure
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a procedure.
+
+
+'''is_query'''
+'''Syntax:''' is_query
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a query.
+
+
+'''is_read_only'''
+'''Syntax:''' is_read_only
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is read-only.
+
+
+'''is_reference'''
+'''Syntax:''' is_reference
+'''Applicable on:''' Generic
+'''Remark:''' This criterion will evaluate to True if the candidate generic is reference.
+
+
+'''is_require'''
+'''Syntax:''' is_require
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in require clause.
+
+
+'''is_require_else'''
+'''Syntax:''' is_require_else
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in require else clause.
+
+
+'''is_satisfied_by'''
+'''Syntax:''' is_satisfied_by command specification
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:'''
+This criterion will invoke external command given in command specification to decide whether current item is evaluated to True. Placeholders are used as interface between current item and the external command. The following placeholders are supported:
+
+* $class_name: this will be replaced by class name of current item
+* $directory_name: this will be replaced by the directory location of current item
+* $file: this will be replaced by file name part, i.e., without heading directory, of $path of current item
+* $file_name: this will be replaced by the path of current item
+* $f_code: this will be replaced by the F_code directory of current target, if defined
+* $group_directory: this will be replaced by the directory of the group of current item
+* $group_name: this will be replaced by the group name of current item
+* $path: same as $file_name
+* $project_directory: this will be replaced by the directory of current project, if defined
+* $target_directory: this will be replaced by the directory of current target, if defined
+* $target_name: this will be replaced by name of current target, if defined
+* $w_code: this will be replaced by the W_code directory of current target, if defined
+
+
+Command specification can be set in the dialog associated to this criterion, shown in the following picture: [[Image:is-satisfied-by|system hierarchy]]
+
+'''Command name'''
+External command is specified here.
+The command shown in the picture will test the subversion status of the current class (suppose we are running a class metric). The class path is given by "$path". And the output of the "svn stat $path" command is redirected to grep so we can check if the output starts with a letter "M" which indicates tha the class is changed locally.
+
+'''Workding directory'''
+Working directory for the command is set here.
+
+'''Input'''
+Input, if any, of the command is set here.
+If the option "As file name" is checked, the text specified is treated as a file name in which actual input is stored.
+
+'''Output'''
+Expected output, if any, of the command is set here.
+If the option "As file name" is checked, the text specified is treated as a file name in which actual output is stored.
+If the option "Enabled" is not checked, the output will be ignored.
+
+'''Error'''
+Expected error, if any, of the command is set here.
+If the option "As file name" is checked, the text specified is treated as a file name in which actual error is stored.
+If the option "Enabled" is not checked, the error will be ignored.
+If the option "Redirected to output" is checked, error of the command will be redirected to output.
+
+'''Exit code'''
+Expected exit code of the command is set here.
+If the option "Enabled" is not checked, the exit code will be ignored.
+
+
+In the above output, error, exit code sections, if more than one are enabled, they are treated as "and-ed". For example if output and exit code are enabled, this criterion is evaluated to True only if the actual output from the command matches the expected output and the exit code from the command matches the expected exit code.
+
+
+'''is_unique'''
+'''Syntax:''' is_unique
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an unique feature.
+
+
+'''is_used'''
+'''Syntax:''' is_used
+'''Applicable on:''' Local
+'''Remark:''' This criterion will evaluate to True if the candidate local is used.
+
+
+'''is_used_in_library'''
+'''Syntax:''' is_used_in_library
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is used in some library instead of only referenced by current application.
+
+
+'''is_visible'''
+'''Syntax:''' is_visible
+'''Applicable on:''' Class, Generic, Feature, Assertion, Argument, Local
+'''Remark:''' This criterion will evaluate to True if the candidate code element is visible from the input domain of current calculated metric.
+Visibility of a class means that if that element is visible from the input domain of the metric. To explains it more clearly, let's see an example:
+
+[[Image:system-hierarchy|system hierarchy]]
+
+The figure shows the group hierarchy of a Vision2 application. library base and vision2 are used by the application. And notice that library wel is used internally by vision2 library but not by the application. This means that classes defined in wel library is not visible to the application thus one cannot use those wel classes in application.
+
+And if we create the following basic metric and run it with current application target as input domain:
+
+[[Image:visible-metric|visible]]
+
+We'll get all classes in the application including those classes in wel library because every class is descendant of class ANY.
+
+But if we do things a little bit differently, we create the following metric and run it with current application target as input domain:
+
+[[Image:visible-metric2|visible]]
+
+Then we will get all visible classes in current application target. i.e., those classes in wel library (any maybe some other invisible classes as well) are filtered out.
+
+Visibility of a generic, feature, assertion, argument, local is determined by its written in class.
+
+
+'''true'''
+'''Syntax:''' true
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion always evaluates to True.
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/domains.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/domains.wiki
new file mode 100644
index 00000000..7078c9ef
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/domains.wiki
@@ -0,0 +1,63 @@
+[[Property:title|Domains]]
+[[Property:weight|9]]
+A domain is a list of code elements, it can contain different kinds of code elements. A domain is used as input to a metric, as output of a metric to review some details, and as an argument passed to some criteria. Domain is used to specify scope.
+
+==Domain Convention==
+
+Before we go to real domain examples, we introduce a simple convention to describe a domain:
+* Group element is written in lower case, for example: base, thread
+* Class element is written in UPPER case, for example: ANY, LINKED_LIST
+* Feature element is written in CLASS_NAME.feature_name, i.e, its associated class will be presented also in upper case and the feature name will be in lower case. For example, ANY.is_equal, STRING_8.is_equal
+* All items in a domain will be in curly braces
+
+For example, {ANY, STRING_8.as_lower, base} defines a domain with 3 elements, a class ANY, a feature as_lower which is in class STRING_8, and a group base.
+
+Suppose we have a basic metric called '''Classes''' which counts the number of classes. Before calculating the metric, we need to specify an input domain. This input domain tells metrics system over which scope the metric is calculated. And after calculating a basic metric, for sometimes, we not only want to know the value of that metric, but we are also interested in which are the actual items that adds up to that value. This detailed item list is also accessible for a basic metric if detailed results are specified to be kept before metric calculation, and it is called output domain.
+
+==Domain Examples==
+
+As a real example, go to Metrics tool in EiffelStudio, select Metric Evaluation panel, select metric '''Classes''' in the "Select metric" area, and set input domain in the "Setup input domain" area. See the following figure, in which the input domain is set to {base, APPLICATION}.
+
+[[Image:domain-example1|Defining an input domain]]
+
+After running the metric, you should see the following result in the Detailed Result panel shown in the following figure:
+
+[[Image:domain-example2|Metric detailed result]]
+
+{{note|Note: an element can appear more than one time in a domain, but the detailed result list show only distinct items, so it is possible that the calculated metric value is not equal to the number of items in the detailed result list.}}
+
+
+A domain can be used as an argument of a relation criterion, see the following example:
+
+[[Image:domain-example3|Domain criterion]]
+
+Here, we define a class basic metric, and in the definition area, we specify a criterion named ancestor_is which is a relation criterion. In that criterion, we set a domain {ANY} as its criterion domain. This metric reads: Count classes whose ancestor is class ANY. Put another way, this metric will find descendants of class ANY.
+
+Now, let's have a look at some examples using delayed item and input domain item.
+
+Suppose we have the following feature metric created in the following figure:
+
+[[Image:domain-example4|Delayed domain item]]
+
+When this metric is calculated over input domain {APPLICCATION}, this means that for every feature from class APPLICATIOIN, we check if it satisfies the defined criterion which is callee_is {Delayed item}. And because of this delayed item, the actual semantic is: For a feature from class APPLICATION, say foo, check if foo satisfies criterion callee_is {APPLICATION.foo}. i.e., the delayed item is replaced by the actual candidate feature.
+
+One may wonder why the concept of delayed item is useful. The answer is that it is powerful when used with other criteria, such as criterion value_of_metric_is. See documentation of value_of_metric_is for details.
+
+Now, an example of Input domain item. Suppose we created the following class basic metric in the following figure:
+
+[[Image:domain-example5|Input domain item]]
+
+And when this metric is calculated over input domain {APPLICATION}, the domain criterion Input domain in ancestor_is criterion will be replaced by the specified input domain, i.e., {APPLICATION}, and the metric will use the current application target as its input domain instead. Put another way, the metric is semantically equal to the following one shown in the following figure:
+
+[[Image:domain-example6|Actual semantic for input domain item]]
+
+{{note|Note: Only code element target, group, folder, class, feature, delayed item, input domain item and application target can be specified through domain selector in Metrics tool. And code element generic, assertion, argument, local, line cannot be specified in domain selector, but they may present in the detailed result domain list.}}
+
+
+{{seealso| '''See Also'''
+[[Units|Units]]
+[[Scopes|Scopes]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/elementary-and-composite-metrics.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/elementary-and-composite-metrics.wiki
new file mode 100644
index 00000000..7a52b742
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/elementary-and-composite-metrics.wiki
@@ -0,0 +1,35 @@
+[[Property:title|Elementary and composite metrics]]
+[[Property:weight|4]]
+Some of our metrics will be elementary and some composite. An elementary metric is measured directly from the product or a project record:
+
+{{note| '''Elementary_metric''':
+- An '''elementary product metric''' is a product metric whose values (integers) indicate the number of occurrences of a certain pattern in a product.
+- An '''elementary process metric''' is a process metric whose values reflect measurements drawn directly from project records. }}
+
+An example of elementary product metric is the number of source lines. An example of elementary process metric is the number of incremental compilations of a system.
+
+Elementary metrics are provided by default by the metric tool. There is no means to remove them or to define new ones since they are not expressed as a combination of other metrics.
+
+From these elementary metrics we may define composite ones:
+
+{{note| '''Composite metric ''': A '''composite metric''' is a metric whose values are defined by a mathematical formula involving other metrics (elementary, or previously defined composite metrics). }}
+A later section will introduce a number of operations for defining composite metrics out of elementary ones.
+Again we may distinguish between product and process:
+
+{{note| '''Composite product metric, composite process metric:'''
+- A '''composite product metric''' is a composite metric defined entirely in terms of product metrics.
+- A '''composite process metric''' is a composite metric whose definition involves one or more process metrics. }}
+
+By convention, this definition treats as process metric as a composite metric involving both product and process components.
+
+The classification introduced for metrics extends to measures, so that we may talk about an elementary product measure, a composite process measure and so on.
+
+{{seealso| '''See Also'''
+[[Attributes, metrics and measures|Metrics]]
+[[Scopes|Scopes]]
+[[Domains|Domains]]
+[[Selection Criteria|Selection criteria]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/index.wiki
new file mode 100644
index 00000000..fd01d720
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/index.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Definitions]]
+[[Property:weight|2]]
+* [[Definitions: Introduction|Introduction]]
+* [[Attributes, metrics and measures|Attributes, metrics and measures]]
+* [[Units|Units]]
+* [[Metric framework and theory|Metric frame work theory]]
+* [[Elementary and composite metrics|Elementary and composite metrics]]
+* [[Raw metrics and selection criteria|Raw metrics and selection criteria]]
+* [[Selection Criteria|Selection Criterion]]
+* [[Predefined raw metrics|Predefined raw metrics and predefined selection criteria]]
+* [[Scopes|Scopes]]
+* [[Domains|Domains]]
+* [[Measurement archive|Measurement archives]]
+* [[Under the Hood - How metrics work|Under the Hood - How Metrics Work]]
+* [[Criterion References|Selection Criteria Reference]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/measurement-archive.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/measurement-archive.wiki
new file mode 100644
index 00000000..13c4ca8e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/measurement-archive.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Measurement archive]]
+[[Property:weight|10]]
+If you want to perform measurements on a system that you are building, the scopes of interest are the first four listed: Feature, Class, Cluster and System. Information on either of these scopes will be provided by the development environment (as with EiffelStudio 5.x); alternatively, you could get it simply by parsing the source of your system. But what if you also need quantitative data on other systems, if only for purposes of seeing how your results compare to the quantitative properties of other people's work?
+
+It would be impractical in this case to require tools that have access to as much information on external systems as on your own. All we really need is a record of previous measurements on these systems. This explains the fifth scope type, Archive: beyond the scope of the current system, all we require to define a scope is a '''measurement archive''', or just "archive" for short. This is simply a file (or part of a file) that retains, in a suitable format (XML-based), the results of measurements made earlier on one system. The file can be local or accessible as a URL on the Internet.
+
+The ability to use a measurement archive as a scope means that:
+*
+A project may set up a measurement archive as the record of its measures.
+
+*
+A department or company may set up a measurement archive for all projects on which it keeps metric information.
+
+* The provider of the development environment, such as Eiffel Software, may publish a set of measurement archives giving metric information for reference projects, such as the EiffelBase library (designed in part as a showcase of Eiffel technology). Eiffle Software indeed intends to include a '''metrics''' directory, with a set of measurement archives for reference tools and libraries, in forthcoming releases of EiffelStudio and at [http://www.eiffel.com/ http://www.eiffel.com/] .
+
+The metric tool provides an easy way to create, update or compare archives in the Metric Archive tab. Simply select tab archives.
+
+The metric tool automatically creates a sub folder named "Metrics" in the current location of the loaded project. It is recommended, but not compulsory, to save created archives in that folder, since it has been provided for metric needs.
+
+We hope that once the facilities described here are available users will adopt the practice of publishing measurement archives; it's a way of providing quantitative reference information, useful to everyone, without revealing anything critical about the actual contents of the software. (For further protection one may envision an independent group that anonymizes the data after verifying the authenticity of the source.)
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/metric-framework-and-theory.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/metric-framework-and-theory.wiki
new file mode 100644
index 00000000..dce6add9
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/metric-framework-and-theory.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Metric framework and theory]]
+[[Property:weight|3]]
+You will want to rely not on a single metric but on a combination of metrics:
+
+{{note| '''Metric framework''': A '''metric framework''' is a set of definitions of metrics. }}
+
+
+
+Any metric work should be backed by a theory:
+
+{{note| '''Metric theory''': A '''metric theory''' is a combination of:
+- A metric framework
+- A set of definitions of attributes (qualitative or quantitative)
+- A mapping from the framework to the set of attributes, representing the hypothesis that each metric is a good predictor of the associated attribute }}
+
+This note does not introduce a metric theory, but defines a metric framework by introducing a number of metrics.
+
+
+
+{{seealso| '''See Also'''
+[[Attributes, metrics and measures|Attributes, metrics and measures]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/predefined-raw-metrics.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/predefined-raw-metrics.wiki
new file mode 100644
index 00000000..f40a6959
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/predefined-raw-metrics.wiki
@@ -0,0 +1,196 @@
+[[Property:title|Predefined raw metrics]]
+[[Property:weight|7]]
+The environment should make it possible, for any project, to apply the elementary metrics in the following table, each with an associated unit and a one-identifier name. Each of the major divisions of the table starts with a raw metric, for example Classes, and, when appropriate, continues with selection criteria that yield derived metrics based on that raw metric, for example Deferred_classes.
+{|
+|-
+| '''Basic Count'''
+| '''Criterion'''
+| '''What to count'''
+| '''Unit'''
+|-
+| Classes
+|
+| Classes of a cluster or system
+| Class
+|-
+| Deferred
+| Deferred classes (not completely implemented, as opposed to "effective", completely implemented).
+|-
+| Invariant equipped
+| Classes having an invariant
+|-
+| Obsolete
+| Classes marked as superseded by newer alternatives
+|-
+| Dependents
+|
+| Classes on which a class depends, directly or indirectly
+| Class
+|-
+| Clients
+| Direct clients
+|-
+| Heirs
+| Direct heirs in inheritance structure
+|-
+| Parents
+| Direct parents in inheritance structure
+|-
+| Suppliers
+| Direct suppliers
+|-
+| Indirect clients
+| Indirect clients
+|-
+| Indirect heirs
+| Indirect heirs in inheritance structure
+|-
+| Indirect parents
+| Indirect parents in inheritance structure
+|-
+| Indirect suppliers
+| Indirect suppliers
+|-
+| Self
+| The class itself (value always 1)
+|-
+| Groups
+|
+| Groups of a system or sub-clusters of a cluster
+| Group
+|-
+| Compilations
+|
+| Compilations since start of project
+| Compilation
+|-
+| All features
+|
+| Inherited and immediate features of a class
+| Feature
+|-
+| Attributes
+| Attributes (features represented by fields in instances of the class, as opposed to routines, represented by algorithms)
+|-
+| Deferred
+| Deferred routines (not implemented, as opposed to effective features, which are implemented)
+|-
+| Exported
+| Features available to all clients
+|-
+| Functions
+| Value-returning routines
+|-
+| Postcondition equipped
+| Routines having a postcondition
+|-
+| Precondition equipped
+| Routines having a precondition
+|-
+| Queries
+| Value-returning features, including both attributes and functions (routines returning a result, as opposed to procedures)
+|-
+| Inherited
+| Features obtained from a parent (possibly in a different form)
+|-
+| Immediate features
+|
+| Immediate features of a class
+| Feature
+|-
+| Attributes
+| Attributes (features represented by fields in instances of the class, as opposed to routines, represented by algorithms)
+|-
+| Deferred
+| Deferred routines (not implemented, as opposed to effective features, which are implemented)
+|-
+| Exported
+| Features available to all clients
+|-
+| Functions
+| Value-returning routines
+|-
+| Postcondition equipped
+| Routines having a postcondition
+|-
+| Precondition equipped
+| Routines having a precondition
+|-
+| Queries
+| Value-returning features, including both attributes and functions (routines returning a result, as opposed to procedures)
+|-
+| All feature assertions
+|
+| Clauses in routine's assertion, whether inherited or not
+| Assertion
+|-
+| Postcondition clauses
+| Clauses in postcondition
+|-
+| Precondition clauses
+| Clauses in precondition
+|-
+| Immediate feature assertions
+|
+| Clauses in routine's assertion, not inherited
+| Assertion
+|-
+| Postcondition clauses
+| Clauses in postcondition
+|-
+| Precondition clauses
+| Clauses in precondition
+|-
+| Invariant clauses
+|
+| Clauses in invariant
+| Assertion
+|-
+| Formal generics
+|
+| Formal generic parameters of a class
+| Generic
+|-
+| Constrained
+| Formal parameters constrained by a type other than ANY
+|-
+| All formals
+|
+| Formal argument of a routine whether inherited or not
+| Local
+|-
+| Immediate formals
+|
+| Formal argument of a routine.
+| Local
+|-
+| Lines
+|
+| Source lines
+| Line
+|-
+| All locals
+|
+| Local entities of feature whether inherited or not (excluding Result)
+| Local
+|-
+| Immediate locals
+|
+| Local entities of feature (excluding Result)
+| Local
+|}
+
+A few comments on specific entries:
+* The list of criteria for Features does not include Routines because a routine is a feature that is not an attribute; to obtain the number of routines, just count features that do not satisfy the Attributes criterion.
+* The selection criteria Attributes and Deferred for Features are, a noted earlier, not independent, since attributes may not be deferred.
+* Another case of dependency: a procedure is never part of Queries but always a command. Queries, however, include both Attributes and Functions.
+* Two more cases of dependency: Redeclared and Renamed can only be satisfied for features that are inherited. A feature that is not inherited, but introduced fresh in the enclosing class, is called immediate.
+* The Redeclared attribute has three values: a feature is redefined if it was effective in the parent, or it was deferred in the parent and the new class keeps it deferred with a different signature or contract; it is effected if it was deferred and the class makes it effective; or it may be neither of these.
+
+All metrics listed are product metrics with one exception: Compilations, the only process metric, counting the number of compilations of the project. There is room for more process metrics, such as cost estimates; this requires standard formats letting project managers enter the appropriate information, a point that future versions of the metrics policy described here may develop further.
+
+There is also room for elementary product metrics other than those in the preceding table. In fact, every syntactic construct is a candidate for an elementary metric that simply counts the number of its occurrences; but we should limit ourselves to those that we judge interesting. The metrics literature also suggests elementary metrics assessing complexity of the control structure through properties of the control graph (McCabe), or routine coherence through such properties as the number of attributes accessed by a routine; we should only add them if we can find convincing arguments for their theoretical soundness.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/raw-metrics-and-selection-criteria.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/raw-metrics-and-selection-criteria.wiki
new file mode 100644
index 00000000..fa45c5d0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/raw-metrics-and-selection-criteria.wiki
@@ -0,0 +1,47 @@
+[[Property:title|Raw metrics and selection criteria]]
+[[Property:weight|5]]
+Elementary metrics measure patterns whose occurrences (in a product or process) can be counted. We need to decompose this notion further to avoid an explosion of the number of elementary metrics. For example the features of a class can be classified along several lines:
+* Some are attributes (object fields), others are routines (algorithms).
+* Some are inherited from a parent, others immediate (defined in the class).
+* Some are exported, others secret
+
+and so on. Many combinations of these properties may be worth counting on their own: you may ask for the number of secret attributes, of exported inherited features and so on. But if we define all of these metrics independently, we will soon have too many elementary metrics, while still failing to satisfy user needs if we have omitted a particular combination.
+
+To avoid this we must identify a subset of elementary metrics as '''raw metrics''': metrics whose results are counted directly. "Number of features in a class" is a raw metric. From a raw metric, we may then derive other elementary metrics by applying '''selection criteria''' such as "Is this feature an attribute?" or "Is this feature exported?" Here are the definitions:
+
+{{note| '''Raw metric, selection criterion, derived metric:'''
+An elementary metric is either '''raw''' or '''derived'''. A '''selection criterion''' for a raw metric is a property, with a fixed set of possible values (two or more), characterizing the patterns or events being counted by the metric.
+A '''derived metric''' is an elementary metric defined from a raw metric by counting only the patterns satisfying a certain combination of its selection criteria. }}
+
+A set of raw metrics and selection criteria is provided by default by the metric tool, see [[Predefined raw metrics|predefined raw metrics and selection criteria]]
+
+To define a derived metric, we start from a raw metric, for example "number of features", and combine some of the associated selection criteria. The combination may be:
+* An "or": for example, count all the features that are attributes or exported (or both).
+* An "and": count all the features that are both attributes and exported.
+
+A selection criterion may have more than two possible values. Most, as in these examples, have just two: a feature is either an attribute or a routine; it is either exported or secret.
+
+The definition states that every derived metric is derived from a certain raw metric or from another derived metric.
+
+As a general guideline, we will try to keep the selection criteria for a given raw metric independent. For example, to distinguish the classes that inherit a given class we will use the following selection criteria:
+* Heirs: count the number of direct heirs of a class.
+* Indirect_heirs: count the number of indirect heirs.
+* Self: count only the class itself.
+
+Other interesting notions are "proper descendant", covering direct and indirect heirs, and "descendant", covering proper descendants and descendants. We do not introduce these as separate criteria, since this would result in a non-independent set of criteria: every proper descendant is a descendant, every heir (direct or indirect) is a proper descendant.
+
+Instead we limit ourselves to the three criteria listed above. If you need a finer decomposition, it is easy, with the techniques discussed below, to define Proper_descendants and Descendants as composite metrics expressed in terms of the elementary metrics Heirs, Indirect_heirs and Self.
+
+This criterion independence principle is not absolute, however, and in some cases we may find it clearer to define a new criterion even though its value is entirely determined by certain values of another. For example one criterion on features determines whether it is an attribute or a routine, another whether it is deferred or effective. An attribute is always effective, so the two criteria are not independent. Even though we could remove the dependency by using a single criterion with three values (attribute, effective routine, deferred routine), it is more convenient to keep two criteria. Of course the underlying counting mechanisms must make sure never to count an element twice even in an "or" query, as when a user asks for the number of features that are attributes or effective.
+
+A metric is either elementary or composite. An elementary metric is either a raw metric, such as "number of features", or a derived metric obtained from slicing a raw metric by selection criteria. Composite metrics are obtained from existing metrics (elementary, or previously defined composite metrics) by applying some mathematical formula.
+
+{{seealso| '''See Also'''
+[[Elementary and composite metrics|Elementary metrics]]
+[[Selection Criteria|Selection Criteria]]
+[[Criterion References|Selection criterion reference]]
+[[Defining derived metrics|Defining derived metrics]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/scopes.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/scopes.wiki
new file mode 100644
index 00000000..8e598ae2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/scopes.wiki
@@ -0,0 +1,27 @@
+[[Property:title|Scopes]]
+[[Property:weight|8]]
+Every metric has a scope:
+
+{{note| '''Scope of a metric''':
+The '''scope''' of a metric is defined as follows:
+- For a raw product metric, the type of product over which the metric is counted, such as: a feature, a class, a group, an archive built for a given system to make it possible to compare systems.
+- For a raw process metric, the type of process on which the metric is measured, such as analysis, documentation, entire project etc.
+- For a derived metric (recursively), the scope of the raw metric from which it is derived.
+- For a composite metric (recursively), the largest of the scopes of all its constituent metrics, where cluster is "larger than" class and so on. }}
+
+
+
+This notion also applies to measures:
+
+{{note| '''Scope of a measure''':
+The '''scope''' of a measure is defined as follows:
+- For an elementary measure (the application of an elementary metric, raw or derived), the set of products or processes to which the associated metric has been applied to yield the measure.
+- For a composite measure, the union of (recursively) the scopes of its constituent measures. }}
+
+For both metrics and measures, the notion of scope will help us compare our quantitative assessments to some already on record. For example you may compare the value of a certain metric, such as number of invariant clauses in each class, with the values that have been archived for your project, for a reference project such as the EiffelBase library, for the previous projects of your company, or for a global set of previous projects maintained at some central location. You may also, with appropriate permissions, update such a shared archive with the values from your own measurements.
+
+In the environment, the notion of scope will be handled by defining an input domain. If the input domain contains a duplicated elements, the computation is done twice on the duplicated elements.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/selection-criteria.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/selection-criteria.wiki
new file mode 100644
index 00000000..81f6906e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/selection-criteria.wiki
@@ -0,0 +1,119 @@
+[[Property:title|Selection Criteria]]
+[[Property:weight|6]]
+A selection criterion is used to filter out candidate code elements and only leave and count those satisfied elements. For example, criterion is_deferred in a basic class metric is only satisfied when a candidate class is deferred. A selection criterion can have modifiers which indicate how the associated criterion will perform its filtering task. There are four kinds of modifiers, shown as follows:
+* Text modifier - String text, and this text is called criterion text
+* Domain modifier - Domain, and this domain is called criterion domain
+* Metric modifier - Metric, and this metric is called criterion metric
+* Normal modifier - modifier other than text, domain and metric
+
+Let's first introduce a convention to describe selection criteria:
+* Criterion name will be followed by modifiers (separated by a comma) if any
+* Text modifier will be in double quotes
+* Domain modifier will follow the convention of domain
+* Metric modifier will be in bold
+* Normal modifier will be in normal font and face
+* Braces will be added to avoid ambiguity
+
+Some examples:
+
+is_deferred
+
+text_is "some text", identity, case-sensitive
+
+ancestor_is {ANY}
+
+value_of_metric_is '''Class''', {base}, (>0 and <100)
+
+There are several kinds of selection criteria, namely, text criterion, path criterion, relation criterion, metric value criterion and normal criterion.
+
+==Text Criterion==
+
+Text criterion uses a text modifier, two normal modifiers (one to specify matching strategy and the other to specify case sensitivity) to perform text pattern matching. Criterion such as name_is and text_is are text criteria.
+
+Let's take text criterion name_is as an example:
+
+The syntax for name_is is:
+
+name_is "pattern", matching_strategy, case_sensitive
+
+The match_strategy modifier decides how criterion text "pattern" is matched, and can choose from one of the following four values:
+*
+Identity - Pattern is matched if the text is identical to criterion text
+
+*
+Containing - Pattern is matched the text contains criterion text
+
+*
+Wildcard - Pattern is matched if it occurs in criterion text according to wildcard rules
+
+*
+Regular expression - Pattern is matched if it occurs in criterion text according to regular expression rules
+
+
+The case_sensitive modifier can be True or False, it indicates if pattern matching is case sensitive or not.
+
+In the following two figures, name_is criterion is shown. That criterion will select all classes whose name starts with a letter A (using regular expression rules) case-insensitively.
+
+[[Image:selection-cri1|Text criterion]]
+
+[[Image:selection-cri2|Text criterion]]
+
+==Path Criterion==
+
+A path criterion uses a text modifier as path to test if a candidate class is located in that path. There are two path criteria, namely, path_is and path_in.
+
+The path uses Unix format. For example, criterion path_is "/kernel" will evaluate to True if a candidate class is located in kernel folder related to the class's group. On Windows, path matching will be case-insensitive, on other platforms, path matching will be case-sensitive.
+
+The following figure shows a path criterion used to find classes which locate in "kernel" folder:
+
+[[Image:selection-cri3|Path criterion]]
+
+==Relation Criterion==
+
+A relation criterion uses a criterion domain to check if a candidate code element is of some relationship between the criterion domain. Some other modifiers may also appear in a relation criterion.
+
+Let's have look at a class relation criterion client_is shown in the following two figures where a basic class metric with relation criterion client_is is defined. This client_is criterion will match all direct normally referenced as well as only syntactically referenced suppliers of class LINKED_LIST.
+
+[[Image:selection-cri4|Relation criterion]]
+
+[[Image:selection-cri5|Relation criterion]]
+
+For more information about normally referenced and only syntactically referenced suppliers, see document of relation criterion client_is.
+
+==Value Criterion==
+
+Value criterion is used to test if calculated value of a given metric satisfies some values. There is only one criterion named value_of_metric_is in this category. Please see the document for value criterion value_of_metric_is for more information.
+
+The following figure shows the use of value_of_metric_is criterion, where a class basic metric is defined to find classes whose lines of code is over 1000:
+
+[[Image:selection-cri6|Relation criterion]]
+
+The following figure shows the result of the above metric:
+
+[[Image:selection-cri7|Relation criterion]]
+
+==Normal Criterion==
+
+All other criteria except for those described above are called normal criteria.
+
+Some examples:
+
+is_library - test if a candidate group is a library
+
+is_deferred - test if a candidate class or feature is deferred
+
+is_comment - test if a candidate line is comment
+
+==Criterion Connector==
+
+There are three criterion connectors: and, or, not. They are self-explanatory. Just a simple example, see the following figure:
+
+[[Image:selection-cri8|Relation criterion]]
+
+{{seealso| '''See Also'''
+[[Domains|Domains]]
+[[Criterion References|Selection criterion reference]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/under-hood-how-metrics-work.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/under-hood-how-metrics-work.wiki
new file mode 100644
index 00000000..ec72f475
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/under-hood-how-metrics-work.wiki
@@ -0,0 +1,51 @@
+[[Property:title|Under the Hood - How metrics work]]
+[[Property:weight|11]]
+This part explains how a product basic metric is calculated.
+
+==Domain Transformation==
+
+As you have seen, before calculating a product basic metric, two things have to be specified:
+* A metric, and every metric has a unit
+* An input domain
+
+And two facts follows:
+* the specified metric will count the number of the code elements specified by the metric unit
+* An input domain can contain any kinds of code elements
+
+For example, in the following figure, a metric as well as its input domain are specified:
+
+[[Image:hood1|Actual semantic for input domain item]]
+
+Here the selected metric is '''Compiled classes''', and the input domain is {base}, and when calculating, all compiled classes in library base will be found and counted. The result is shown in the following figure:
+
+[[Image:hood2|Actual semantic for input domain item]]
+
+But how are those compiled classes found in library base? The answer is through an operation called domain transformation.
+
+A domain transformation will transform a source domain into a destination domain with a specified product unit. This means that a product unit has to be specified to indicate what kind of code element will appear in a destination domain. A product unit can be one of the following: target, group, class, generic, feature, argument, local, assertion, line.
+
+A domain transformation is done like this: For every code element in source domain, all code elements of the destination unit that can be found (with the help of the compiler) in that source code element are put into the destination domain.
+
+Let's continue to use the above '''Compiled classes''' example. The input domain {base} is source domain, and the result domain of the metric is the destination domain here. The destination unit is class which is the unit of the specified metric '''Compiled classes'''.
+
+So for a source code element (here it is base), find all classes in that element (base), and put them in the destination domain. Now we get a destination domain which contains all candidate classes. Those classes are called candidates because we only want some of them. And the filtering is done with the specified criterion is_compiled. After that, you get the actual result domain.
+
+It's quite easy to understand the group to class transformation. But what if I want some features now? Just do consecutive transformations: from group to class first, and then from class to feature.
+
+We call a transformation from an element to another element a route, consecutive transformations a path. All possible transformation paths are shown in the following figure:
+
+[[Image:hood3|Actual semantic for input domain item]]
+
+Some remarks on the transformation paths:
+* If you go through the path from the end of an arrow to its head, you'll possibly find results, but if the transformation is done in the reversed direction, nothing will be found. For example, in any cases, the destination domain will be empty (indicating nothing is found) if you do a transformation from a line element to a class element.
+* Code element line appears in the path: Target -> Group -> Class -> Line because typically in an Eiffel class, there are some lines that do not belong to any features, such as class indexing lines or inherit clauses.
+* The shortest path will always be used. So if you transform a target element to a line element, the path: Target -> Group -> Class -> Line will be used instead of Target -> Group -> Class -> Feature -> Line
+* Paths from element to the element of the same unit are omitted. i.e., there are paths such as Target -> Target, Group -> Group, Class -> Class
+
+==Domain Filtering==
+
+After domain transformation, we get a destination domain with all candidate code elements. Then we perform a filtering operation using the specified criterion in a basic metric to get rid of all unsatisfied candidates. At last, we'll get the desired result domain. Using the above example, for every class in the destination domain, we test if that class is compiled using the specified criterion is_compiled. If it's a compiled class, keep it in the destination domain, if not, remove it from the destination domain.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/units.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/units.wiki
new file mode 100644
index 00000000..c38e0e61
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/units.wiki
@@ -0,0 +1,135 @@
+[[Property:title|Units]]
+[[Property:weight|2]]
+Metrics will be expressed in units, such as Line (numbers of source lines) or Feature (number of features).
+
+{{note| '''Unit rule:''' The definition of any metric must specify an associated unit. }}
+
+Different metrics may be marked with the same unit; for example metrics such as number of non-comment lines and number of comment lines may both be marked with the unit Line.
+
+Whenever we need to express ratios of one measurement to another, as in computing the average number of features per class by dividing the number of features by the number of classes, we will use a specific unit, Ratio:
+
+{{note| '''"Ratio unit"''': The name Ratio denotes a predefined unit, whose values are arbitrary real numbers, expressed either as numbers or in percentage style (as in 35.3%). }}
+
+As a result of this choice, we will consider every division to yield a result of unit, Ratio.
+
+The following predefined units are available in the metric tool:
+{|
+|-
+| '''Unit'''
+| '''Quantities measured'''
+| '''Kind'''
+|-
+| Class
+| Number of classes or types
+| Product
+|-
+| Generic
+| Number of class generics
+| Product
+|-
+| Feature
+| Number of features
+| Product
+|-
+| Target
+| Number of targets
+| Product
+|-
+| Group
+| Number of groups
+| Product
+|-
+| Assertion
+| Number of assertion clauses
+| Product
+|-
+| Argument
+| Number of arguments of a routine
+| Product
+|-
+| Local
+| Number of locals of a routine
+| Product
+|-
+| Line
+| Number of source lines
+| Product
+|-
+| Compilation
+| Number of compilations
+| Process
+|-
+| Ratio
+| Results of divisions
+| Product
+|}
+
+The units listed here are '''minimal''' in the sense that it is not possible to add the properties measured by any two of them; for example it makes no sense to add a number of features to a number of classes.
+
+In the future, it might be desirable to include more specific units, such as "features per class" , and an associated calculus of units (as in the physical sciences, where multiplying a quantity expressed in g /cm by one in cm yields a result in g). This has not appeared necessary for the typical uses of division envisioned in this note, answering such questions as "What percentage of routines have a header comment" can all be expressed simply as ratio.
+
+==Code Element==
+
+For most of units, an item of that unit represents a code element in a real system. For example, an item of class unit represents a class and an item of line unit represents a line of code. All supported code elements are listed as follows:
+{|
+|-
+| '''Code Element'''
+| '''Unit'''
+| '''Description'''
+|-
+| Class
+| Class
+| Represents a class
+|-
+| Generic
+| Generic
+| Represents the piece of the code related to generics definition in a class definition.
+|-
+| Feature
+| Feature
+| A feature or an invariant clause. In metrics tool, a feature can be one of two things: a traditional feature, or an invariant clause. That is to say, an invariant clause is treated as a special feature. To avoid ambiguity, we call a traditional feature a "feature" and an invariant clause an "invariant feature".
+|-
+| Target
+| Target
+| Represents a target
+|-
+| Group
+| Group
+| Represents a group in system. A group can be either a cluster, a library or an assembly
+|-
+| Assertion
+| Assertion
+| Represents an assertion
+|-
+| Argument
+| Argument
+| Represents a formal argument in features
+|-
+| Local
+| Local
+| Represents a local defined in features
+|-
+| Line
+| Line
+| Represents a line of code
+|-
+| Folder
+| -
+| Represents a physical concept to store classes. The semantic of a folder in metrics tool is equal to a list all classes which are located in that folder (not recursively). So a folder item doesn't provide new functionality, it just facilitates the operation to select a set of classes.
+|-
+| Delayed item
+| -
+| A delayed item is a place holder, it will be replaced by the candidate code element over which a domain criterion is evaluated
+|-
+| Input domain item
+| -
+| An input domain item is a place holder, it will be replaced by the domain selected as input to the metric. In the case that the input domain is presents in a basic metric definition, when that metric is calculated, the metric will use the current application target as the input domain.
+|-
+| Current application item
+| Target
+| Represents the application target of the current Eiffel system
+|}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/index.wiki
new file mode 100644
index 00000000..37a84fc4
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Metrics tool]]
+[[Property:weight|-5]]
+* [[Metric tool: Introduction|Introduction]]
+* [[Requirements|Requirements]]
+* [[Definitions|Definitions]]
+* [[User interface basics|User interface basics]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/requirements.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/requirements.wiki
new file mode 100644
index 00000000..756a36ce
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/requirements.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Requirements]]
+[[Property:weight|1]]
+All engineering disciplines other than software rely on quantitative approaches to design their products, organize the production process, and assess the results. Software engineering too can benefit from measuring relevant properties of its products and processes.
+
+Measurements are not an end in themselves; they must be related to broader goals of software engineering:
+
+The purpose of software measurements is to provide quantitative assessments or predictions of properties of software products and processes
+
+For any numerical measure that we propose we must have precise information on four properties: coverage, trustworthiness, relevance, theory.
+
+Any quantitative report on software products or processes should satisfy the following properties:
+* '''Coverage''': include a definition of what is being measured, sufficient to enable repetition of the measurements.
+* '''Trustworthiness''': include an estimate of how much the results can be believed, in particular of their precision (expected variations in case of repetition).
+* '''Relevance''': specify interesting properties of software products or processes on which the measurement may provide insight.
+* '''Theory:''' include arguments backing the statement of relevance.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/detailed-result-panel.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/detailed-result-panel.wiki
new file mode 100644
index 00000000..81e6e7fb
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/detailed-result-panel.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Detailed Result Panel]]
+[[Property:weight|1]]
+The Detailed result panel is where detailed metric result and archive comparison result are displayed. In the following two figures, a detailed metric result and an archive comparison result are shown.
+
+Detailed metric result:
+
+[[Image:interface4|Defining an input domain]]
+
+Archive comparison result:
+
+[[Image:interface5|Defining an input domain]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/index.wiki
new file mode 100644
index 00000000..3a3b6bf6
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|User interface basics]]
+[[Property:weight|3]]
+EiffelStudio includes a Metric tool based on the previously defined metric theory. This tool provides many facilities like computing measures over a project, including smaller scopes, defining new metrics according to users needs and handling archives to compare projects
+* [[Metric Evaluation Panel|Metric Evaluation panel]]
+* [[Detailed Result Panel|Detailed Result panel]]
+* [[Metric Definition Panel|Metric Definition panel]]
+* [[Metric History Panel|Metric History panel]]
+* [[Metric Archive Panel|Metric Archive panel]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-archive-panel.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-archive-panel.wiki
new file mode 100644
index 00000000..874f0f7a
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-archive-panel.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Metric Archive Panel]]
+[[Property:weight|4]]
+The metric archive panel is used to calculate and restore metric archives and to do metric archive comparison.
+
+==Metric Archiv Calculation==
+
+Let's have a look at the buttons and options related to metric archive calculataion:
+
+[[Image:metrics-tool--debug-run-icon|calculate archive]] Start metric archive calculation
+After selecting the metrics you want to archive and the input domain, use this button to start a metric archive calculation.
+
+[[Image:metrics-tool--debug-stop-icon|stop archive]] Stop metric archive calculation
+Use this button to stop a metric archive calculation.
+
+[[Image:interface22|archive file location]] Specify archive file
+The file to store metric archive results is specified here.
+
+[[Image:interface23|reset archive]] Reset archive file
+If the specified archive file already contains some archive information, this option will be sensitive. If it's enabled, the information contained in that archive file will be cleaned before new archive information is written to that file, otherwise, new archive information will be appended to that file.
+
+==Metric Archive Comparison==
+
+After you specify two archive files you can compare them, as shown in the following image:
+
+[[Image:interface24|Compare archives]]
+
+The archive comparison result is shown in the following figure:
+
+[[Image:interface25|archive comparison result]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-definition-panel.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-definition-panel.wiki
new file mode 100644
index 00000000..2be603b2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-definition-panel.wiki
@@ -0,0 +1,69 @@
+[[Property:title|Metric Definition Panel]]
+[[Property:weight|2]]
+In the metric definition panel, you can do the following:
+* Manage user-defined metrics, such as defining new metrics and modify or remove existing ones. Metrics with a small lock in their icons are predefined metrics which cannot be changed or remvoed
+* Import metrics from other systems
+* Backup user-defined metrics
+
+
+The following figure shows the layout of the metric definition panel:
+
+[[Image:interface6|Metric definition panel]]
+
+Let's have a look at the buttons in the main toolbar which is highlighted in the following figure:
+
+[[Image:interface7|Main toolbar buttons]]
+
+[[Image:metrics-tool--new-metric-icon|New metric]]
+
+[[Image:metrics-tool--new-document-icon|Clone metric]]
+
+[[Image:metrics-tool--general-remove-icon|Remove metric]]
+
+[[Image:metrics-tool--general-save-icon|Save metric]]
+
+[[Image:metrics-tool--command-send-to-external-editor-icon|External editor]]
+
+[[Image:metrics-tool--general-open-icon|Reload metrics]]
+
+[[Image:metrics-tool--metric-export-to-file-icon|import]]
+
+==Define New Metrics==
+
+To define a new metric, you need to choose the metric type and unit (for basic metric and linear metric). The following figure shows how to choose metric type and unit:
+
+[[Image:interface8|Choose metric type]]
+
+The following figure shows a new basic class metric:
+
+[[Image:interface9|basic metric]]
+
+When defining basic metrics, you can press Ctrl + Space in a cell in the criterion column (the first column in "definition" area) to get a list of all applicable criteria. You can also type "and" or "or" in that cell to get criterion connectors. And you can put "not" in front of a criterion name to get its negation. After typing the criterion name and hitting enter, if the criterion needs further setup, the property cell of that criterion will be highlighted. For domain criterion such as ancestor_is, caller_is, you can pick an item and drop it into this property cell.
+
+The following figure shows a new linear feature metric:
+
+[[Image:interface10|linear metric]]
+
+For every metric referenced in a linear metric, you need to specify a coefficient. You can pick a metric and drop it into a cell of the "Metrics" column in the "Metric Definition" area.
+
+The following figure shows a new ratio metric:
+
+[[Image:interface11|ratio metric]]
+
+For the numerator or denominator metric, you need to specify a coefficient. When the denominator part evaluates to zero, the result of the ratio metric will be "Undefined". You can pick a metric and drop it into the numerator or denominator metric area.
+
+==Import Metrics==
+
+In order to reuse metrics defined in a different system, you need to import them into current system. The following figure shows how to import metrics:
+
+[[Image:interface12|Import metrics]]
+
+==Backup User-defined Metrics==
+
+The following figure shows how to back user-defined metrics:
+
+[[Image:interface13|Backup metrics]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-evaluation-panel.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-evaluation-panel.wiki
new file mode 100644
index 00000000..4dc3d598
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-evaluation-panel.wiki
@@ -0,0 +1,38 @@
+[[Property:title|Metric Evaluation Panel]]
+[[Property:weight|0]]
+The Metric Evaluation panel is the place to do metric evaluation. After selecting a metric from the "Select metric" area and setting an input domain in the "Setup input domain" area, you can click the run button to start metric evaluation. You can start metric evaluation with and empty input domain and the result will be always zero.
+
+[[Image:interface1|Defining an input domain]]
+
+Let's first have a look at the buttons in the main toolbar, see the following figure in which the main toolbar is highlighted:
+
+[[Image:interface2|Defining an input domain]]
+
+[[Image:metrics-tool--debug-run-icon|Defining an input domain]] Start metric evaluation
+Press this button to start evaluating the currently selected metric.
+
+[[Image:metrics-tool--debug-stop-icon|Defining an input domain]] Stope metric
+Press this button to terminate a running metric evaluation.
+
+[[Image:metrics-tool--metric-send-to-archive-icon|Defining an input domain]] Send last result to metric history
+After a metric evaluation this button will be sensitive and clicking it will record the evaluated metric as well as it's input domain and result in the metric history. This faciliates to evaluate it again and let's you compare different metric runs.
+
+[[Image:metrics-tool--metric-run-and-show-details-icon|Defining an input domain]] Keep detailed result when evaluating metric
+Normally, evaluating a metric will give you a number as result, but sometimes, you want to investigate into those items which make up that value. For example, evaluating '''Classes''' metric over the base library gives you 242, which means there are 242 classes in the base library, and sometimes, you want to know which they are. With this option enabled, you'll have a detailed result listed in the detailed result panel after a metric evaluation. This option only has effect when evaluating basic metrics, because the detailed result has no meaning for derived metrics (linear or ratio metrics) in general. Suppose you have a linear metric defined as 5 * Classes, then the notion of detailed result has no meaning. Another use of this option is for performance: keeping a detailed result can be quite expensive in some cases, such as when you calculate the metric '''Lines of code''' for a large system, which may result in hundred of thousands of lines in the result. So turning it off in such as case may be a good idea.
+
+[[Image:metrics-tool--metric-filter-icon|Defining an input domain]] Filter result which is not visible from input domain
+If this option is enabled, all non visible items from the input domain will be filtered. For definition of "non visible" items, please see documentation for criterion is_visible.
+
+[[Image:metrics-tool--context-sync-icon|Defining an input domain]] Automatically go to result panel after metric evaluation
+If this option is enabled, the metric tool will switch to the detailed result panel after a metric evaluation.
+
+[[Image:metrics-tool--metric-quick-icon|Defining an input domain]] Define quick metric
+Sometimes, you want to calculate some metrics which are not defined already. For example, find a feature which is named "foo". And it may be just a one time thing, so there is no need to go to metric definition panel, define and save a metric and then go back to evaluation panel and run it. Quick metric is designed for this situation, you can defined any basic metric in the quick metric definition area. It's the same as the basic metric definition area in the metric definition panel. Just define your metric and run it.
+In the following figure, a defined quick metric is shown:
+
+[[Image:interface3|Defining an input domain]]
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-history-panel.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-history-panel.wiki
new file mode 100644
index 00000000..bdd16791
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-history-panel.wiki
@@ -0,0 +1,65 @@
+[[Property:title|Metric History Panel]]
+[[Property:weight|3]]
+The metric history panel lists all recorded metric evaluations. You can select them and reevaluate them to see the new value and if it differs from the old result.
+
+Lets have a look at the buttons in the main toolbar highlighted in the following figure:
+
+[[Image:interface14|Metric history panel]]
+
+[[Image:metrics-tool--debug-run-icon|Run history]]
+
+[[Image:metrics-tool--debug-stop-icon|Stop history]]
+
+[[Image:metrics-tool--metric-run-and-show-details-icon|Keep detailed result]]
+
+[[Image:metrics-tool--metric-unit-assertion-icon|Check warning]]
+
+[[Image:metrics-tool--general-reset-icon|Remove detailed result]]
+
+[[Image:metrics-tool--general-remove-icon|Remove history]]
+
+[[Image:metrics-tool--metric-group-icon|Show tree]]
+
+[[Image:interface16|Hide old metrics]]
+
+[[Image:select-all|select all history]]
+
+[[Image:deselect-all|deselect all history]]
+
+[[Image:select-recalculatable|select all calculatable]]
+
+[[Image:deselect-recalculatable|deselect all calculatable]]
+
+==Recalculate Metric History==
+
+To recalculate a metric history, you need to selected those items that you want to recalculate. In the following figure, a metric history item '''Uncommented features''' is selected.
+
+[[Image:interface17|Select metric history]]
+
+After recalculating the selected metric history items, the result will be highlighted, as shown in the following figure:
+
+[[Image:interface18|History recalculationg result]]
+
+In the above figure, the row '''Uncommented features''' is highlighted indicating that this item has been recalculated. And from the row, we can see that the current value is 1 while the previous value is 0, meaning that there is one uncommented feature in cluster sample now while there was no uncommented feature in cluster sample when this metric was calculated the last time.
+
+==Metric History Warning Checking==
+
+Another thing you can do in metric history is to assign a warning tester to each item. When the metric history is recalculated with metric history warning checking enabled, the warning tester will be evaluated against the metric value to see if it's condition is satisfied.
+
+Let's use an example to demonstrate the idea. Suppose we have set up a metric history warning shown in the following two figures:
+
+[[Image:interface20|warning tester]]
+
+[[Image:interface19|warning tester]]
+
+This warning means, when the metric '''Uncommented features''' is calculated over the input domain {sample}, the value should be zero, otherwise a warning should be emitted.
+
+After recalculating the metric history item, we get the following result:
+
+[[Image:interface21|warning tester]]
+
+From the above result, we can see that the value of the metric '''Uncommented features''' over the input domain {sample} is 1 while our warning says it should be 0. So we get a warning message.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/outputs-tool/external-compilation-pane.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/outputs-tool/external-compilation-pane.wiki
new file mode 100644
index 00000000..4bf93a03
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/outputs-tool/external-compilation-pane.wiki
@@ -0,0 +1,24 @@
+[[Property:title|C Output tool]]
+[[Property:link_title|External compilation pane]]
+[[Property:weight|3]]
+The C Output tool is where C compilation output is shown.
+
+[[Image:coutput1|C output tool]]
+
+If the C compiler uses a different locale than your default locale, you can select that particular locale in the "Locale" region.
+
+==Open a file mentioned in the C output==
+
+You can open a file mentioned in the C output in a specified external editor by selecting the file name and then clicking the [[Image:metrics-tool--command-send-to-external-editor-icon|C output tool]] button highlighted in the following figure:
+
+[[Image:coutput2|C output tool]]
+
+==Find C code for a class/feature==
+
+Pick the class or feature whose related C code you want to see and drop it into the [[Image:coutput4|C output tool]] button or the [[Image:coutput5|C output tool]] button. The related C code will be shown in specified editor.
+
+[[Image:coutput3|C output tool]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/error-wizard.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/error-wizard.wiki
new file mode 100644
index 00000000..50c4dd36
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/error-wizard.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Error wizard]]
+[[Property:weight|2]]
+More often than wanted, Eiffel compilations are not successful. The good point is that when an error is detected by the compiler, it will not be a problem at run-time. The bad point is that you have to fix compilation errors before being able to launch and debug your system.
+
+When an error occurs during an Eiffel compilation in EiffelStudio, the '''Output''' tab of the context tool displays a description of the error and its location, which looks more or less like this:
+
+[[Image:error-message]]
+
+In this case, the compiler tries to explain that the identifier "sessionid" is not a known identifier in the context where it was typed. This is a common error that mainly occurs when making typos in the code. Assuming the message does not make sense to you (which may happen in more complex cases), you can query more information about the encountered error.
+
+To do this:
+* [[Pick-and-drop mechanism|Pick]] the code of the error, in this case VEEN.
+* [[Pick-and-drop mechanism|Drop]] it either in the editor or on the error help button [[Image:command-error-info-icon]] .
+* A dialog is then popped up that describes extended information concerning this error type:
+
+[[Image:error-description-dialog]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/external-commands-editor-dialog.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/external-commands-editor-dialog.wiki
new file mode 100644
index 00000000..f4f5fefa
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/external-commands-editor-dialog.wiki
@@ -0,0 +1,31 @@
+[[Property:title|External commands editor dialog]]
+[[Property:weight|4]]
+From EiffelStudio, you can define up to 10 external commands. Those commands will have their output redirected in the output pane of the context tool. You can execute them through the Tools menu. A typical usage is to use those external commands to integrate with your source control management solution (e.g. CVS, Visual SourceSafe,...)
+
+To define your own command, select "External commands..." in the Tools menu. Then the following dialog will appear:
+
+[[Image:external-commands-dialog]]
+
+With this dialog you can:
+* add new commands
+* edit existing commands
+* delete existing commands
+
+To add your first command, simply click on the "Add..." button and the following command editor will appear:
+
+[[Image:external-commands-dialog-editor]]
+
+In this dialog you can give a name to the command, this name will be displayed in the Tools menu. The index is the position among the external commands of the command in the Tools menu. The command line is the command you want to execute. In order to execute correctly, the application you will execute needs to be in your PATH environment variable or if it is not you must provide an absolute path to the external command. And you can specify the workding directory for that command.
+
+In addition to the external command name, you can pass as many options as you want plus the following placeholders that will be translated before calling the external command:
+* $class_name: this will be replaced by the name in lower case of the targeted class in editor
+* $file_name: this will be replaced by the path to the targeted class in editor
+* $directory_name: this will be replaced by the directory location of the targeted class in editor
+* $group_name: this will be replaced by the group name of the targeted class in editor
+* $line: this will be replaced by the line number of the cursor of the targeted class in editor
+* $w_code: this will be replaced by the W_code directory of current system, if defined
+* $w_code: this will be replaced by the F_code directory of current system, if defined
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/index.wiki
new file mode 100644
index 00000000..82af89d3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Dialogs]]
+[[Property:weight|1]]
+* [[New feature dialog|New feature dialog]]
+* [[Error descriptor|Error descriptor]]
+* [[External commands editor dialog|External commands editor]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/index.wiki
new file mode 100644
index 00000000..b8c6ccc0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|New feature dialog]]
+[[Property:weight|0]]
+* [[New feature dialog: Introduction|Introduction]]
+* [[New feature dialog overview|Overview]]
+* [[New procedure layout|Procedure layout]]
+* [[New function layout|Function layout]]
+* [[New attribute layout|Attribute layout]]
+* [[New feature dialog: feature properties modification|Feature properties modification]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-attribute-layout.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-attribute-layout.wiki
new file mode 100644
index 00000000..cc3ae9f3
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-attribute-layout.wiki
@@ -0,0 +1,41 @@
+[[Property:title|New attribute layout]]
+[[Property:weight|4]]
+ [[Image:feature-wizard-attribute]]
+When clicking '''Attribute''', the window changes to the attribute layout. It has the following components:
+* [[Feature clauses|Feature clause selection]]
+* [[Name field|Feature name field]]
+* [[Type selection|Type selection]]
+* [[Header comment|Header comment field]]
+* [[Invariant field|Invariant field]]
+* [[Set-procedure|Set-procedure check box]]
+
+==Example==
+ [[Image:feature-wizard-attribute-example]]
+class
+ PRODUCT
+
+feature {NONE} -- Access
+
+ price: DOUBLE
+ -- Cost in dollars.
+
+feature -- Element change
+
+ set_price (a_price: DOUBLE) is
+ -- Assign `a_price' to `price'.
+ require
+ a_price_non_negative: a_price >= 0.0
+ do
+ price := a_price
+ ensure
+ price_assigned: price = a_price
+ end
+
+invariant
+ price_non_negative: price >= 0.0
+
+end -- class PRODUCT
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/argument-list.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/argument-list.wiki
new file mode 100644
index 00000000..b07722b2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/argument-list.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Argument list]]
+[[Property:weight|2]]
+For functions and procedures, you can build a formal argument list. You can do this by clicking on the '''New argument''' button as many times as you need arguments.
+
+{{note| '''Note''': Even though this dialog always shows parentheses, they are not generated if the list is empty (Eiffel's command-query separation (CQS) principle). }}
+ [[Image:feature-wizard-3-arguments]]
+{{note| '''Note''': If you add arguments to a routine, it is not possible anymore to select routine type '''once'''. }}
+
+For every attribute you selected, enter a name in the text box and a type using the [[Type selection|type selection]] .
+ [[Image:feature-wizard-1-argument]]
+The code that is generated:
+set_name (s: STRING) is
+ do
+ end
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-body.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-body.wiki
new file mode 100644
index 00000000..fd44ecfe
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-body.wiki
@@ -0,0 +1,34 @@
+[[Property:title|Feature body]]
+[[Property:weight|6]]
+What goes into the feature body field is dependent on what kind of feature you wish to generate.
+* '''do''': this is the normal procedure type. Enter in the field below '''do''' a body for your feature.
+
+do_something is
+ do
+ a := b
+ end
+
+* '''once''': this is the type for a routine that is executed once per execution. As a once routine cannot have arguments, it is disabled when you added one or more arguments.
+
+init is
+ once
+ load
+ end
+
+* '''deferred''': this creates a routine of deferred type. The local and body fields gray out as they serve no use anymore.
+
+do_something is
+ deferred
+ end
+
+* '''external''': this creates an Eiffel wrap routine around a routine written in another language. Use the body field to enter a string containing the necessary information about the routine using the external syntax.
+
+do_something is
+ external
+ "C | %"location.h%""
+ end
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-clauses.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-clauses.wiki
new file mode 100644
index 00000000..a8802f0d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-clauses.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Feature clauses]]
+[[Property:weight|0]]
+The feature you create will be inserted in the feature clause you specified. If the feature clause was not already in your class, or not in the right place, EiffelStudio adds the feature clause to the class text based on the feature clause order specified in the [[Preferences Reference|preferences]] . By default, this is the order used by the Eiffel Software libraries, such as EiffelBase.
+==Export status==
+The export status is the class the feature is accessible for. Usually, this is ANY for public features, or NONE for implementation features, but you can specify any class here.
+[[Image:feature-wizard-export]]
+
+{{note| '''Note''': In the class text, you can export a feature to more than one class but (for simplicity) not with this dialog. }}
+
+==Feature clause names==
+For feature clause names it is recommended that you pick one from the standard ones, but it is also possible to create a new one. If you have introduced a special feature clause name in your project, add it to the feature clause order list in the [[Preferences Reference|preferences]] and it will also appear in this dialog.
+[[Image:feature-wizard-clausenames]]
+
+==Generated code==
+The code that is inserted in your class as a result of the selections made for the feature clause, is of the form:
+feature {EXPORT} -- Clause name
+except if you specified ANY as export status, which is similar to having no export status.
+feature --Clause name
+
+For example, if you specified a the "Initialization" feature clause name, and specified NONE as export status, you get:
+feature {NONE} -- Initialization
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/header-comment.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/header-comment.wiki
new file mode 100644
index 00000000..d92a4b21
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/header-comment.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Header comment]]
+[[Property:weight|3]]
+In the header comment field you can type a description of the feature. For style guidelines in writing a header comment, see: [http://www.eiffel.com/doc/oosc/ Object-Oriented Software Construction, Second Edition] , paragraph 26.4. The description should be informative, clear and terse.
+
+For example, suppose you have an attribute count. You can enter the following header comment:
+ [[Image:feature-wizard-comment]]
+When clicking '''OK''' this code is generated:
+count: INTEGER
+ -- Number of students in course
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/index.wiki
new file mode 100644
index 00000000..f47fc6cf
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/index.wiki
@@ -0,0 +1,17 @@
+[[Property:title|New feature dialog: feature properties modification]]
+[[Property:weight|5]]
+* [[Feature clauses|Feature clauses]]
+* [[Name field|Name field]]
+* [[Argument list|Argument list]]
+* [[Header comment|Header comment]]
+* [[Precondition|Precondition]]
+* [[Local variable|Local variable]]
+* [[Feature body|Feature body]]
+* [[Postcondition|Postcondition]]
+* [[Type selection|Type selection]]
+* [[Invariant field|Invariant]]
+* [[Set-procedure|Set-procedure]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/invariant-field.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/invariant-field.wiki
new file mode 100644
index 00000000..72f64961
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/invariant-field.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Invariant field]]
+[[Property:weight|9]]
+When creating an attribute, you can optionally enter or select an invariant for that feature. That invariant will be added to the end of the existing invariant clause. If the invariant clause did not exist before, it is now created.
+ [[Image:feature-wizard-invariant]]
+If the attribute is of a reference type, you may select the invariant that the attribute may never be void. If it is of a basic expanded type, some other standard options may be chosen. For example, for INTEGER you may select that it should always be positive.
+ [[Image:feature-wizard-invariant-selected]]
+The example above will generate the code:
+
+ invariant
+ count_positive: count > 0
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/local-variable.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/local-variable.wiki
new file mode 100644
index 00000000..97820b60
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/local-variable.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Local variable]]
+[[Property:weight|5]]
+Enter a local variable in the local field. A local variable clause will be added to the feature:
+
+...
+local
+ n: INTEGER
+...
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/name-field.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/name-field.wiki
new file mode 100644
index 00000000..9d1513f2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/name-field.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Name field]]
+[[Property:weight|1]]
+The feature name field is a text box that lets you enter a name for the feature. For help on how to choose the right name for a feature, see: [http://www.eiffel.com/doc/oosc/ Object-Oriented Software Construction, Second Edition] , paragraph 26.2.
+
+{{warning| '''Warning''': EiffelStudio performs no validation on the name you choose. For example if you type a space in it, it will generate the code, and detect a syntax error only when compiling. }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/postcondition.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/postcondition.wiki
new file mode 100644
index 00000000..8b5e3aa2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/postcondition.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Postcondition]]
+[[Property:weight|7]]
+Enter a postcondition in the ensure field. A postcondition clause will be added to the feature:
+...
+ensure
+ n = count
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/precondition.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/precondition.wiki
new file mode 100644
index 00000000..697c5021
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/precondition.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Precondition]]
+[[Property:weight|4]]
+Enter a precondition in the require field. A precondition clause will be added to the feature:
+
+...
+require
+ n >= 0
+...
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/set-procedure.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/set-procedure.wiki
new file mode 100644
index 00000000..ac8da6f2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/set-procedure.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Set-procedure]]
+[[Property:weight|10]]
+When creating an attribute, it is common that you will also need a set-procedure for it. For example, for attribute property you need a procedure set_property to set it. This feature takes one argument of the same type as property or is anchored to it. The only thing you have to do with the feature wizard is check the button '''Generate set procedure'''.
+ [[Image:feature-wizard-setprocedure]]
+The feature that is generated in addition to the attribute itself is placed in feature clause Element change and is exported to all classes. If you have selected or entered an invariant, the precondition will protect this invariant. Example of a generated set-procedure:
+ [[Image:feature-wizard-setprocedure-example]]
+
+ feature -- Element change
+
+ set_button (a_button: EV_BUTTON) is
+ -- Assign `a_button' to `button'
+ require
+ a_button_not_void: a_button /= Void
+ do
+ button := a_button
+ ensure
+ button_assigned: button = a_button
+ end
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/type-selection.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/type-selection.wiki
new file mode 100644
index 00000000..8423a299
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/type-selection.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Type selection]]
+[[Property:weight|8]]
+Whenever you need to give a type of something in the dialog, the type selection component is used. The type selection lets you type any class name or you can pick one from the list.
+ [[Image:feature-wizard-typeselection]]
+When you select a class that is in the system and has formal generic parameters, the type selection component lets you specify an actual generic parameter in another type selection.
+ [[Image:feature-wizard-generictype]]
+{{note| '''Note''': the window might grow in size because of the added component. }}
+
+Since the actual generic type selection is also a type selection, you can select another class with generic parameters and nest them as deep as you need.
+ [[Image:feature-wizard-generictyperec]]
+You can also select the type TUPLE, which is a special class that can have zero or more generic parameters. When you select it, it has no parameters, but you can add one by clicking on the '''Add parameter''' button. Click it as often as the number of generic parameters that you need.
+ [[Image:feature-wizard-tupletype2]]
+
+{{warning| '''Warning''': if you need a very complex type, it is better not to use the dialog, as the window might grow bigger than your screen. After you completed the feature, edit it manually in the class text. }}
+
+The code generated for the selected type is quite straightforward, an example:
+ [[Image:feature-wizard-complextype]]
+
+
+ new_feature: FUNCTION [ANY, TUPLE [INTEGER], BOOLEAN]
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-overview.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-overview.wiki
new file mode 100644
index 00000000..675f7f2b
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-overview.wiki
@@ -0,0 +1,12 @@
+[[Property:title|New feature dialog overview]]
+[[Property:weight|1]]
+There are two parts in the window. The upper part allows you to choose what type of feature you want to create, a procedure, a function or an attribute.
+ [[Image:feature-wizard]]
+The rest of the window is used to set the characteristics of the new feature. Information you will be asked depends on the type you chose. For more information, click on one of the links below:
+* [[New procedure layout|New procedure layout]]
+* [[New function layout|New function layout]]
+* [[New attribute layout|New Attribute layout]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-function-layout.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-function-layout.wiki
new file mode 100644
index 00000000..e46198bd
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-function-layout.wiki
@@ -0,0 +1,36 @@
+[[Property:title|New function layout]]
+[[Property:weight|3]]
+ [[Image:feature-wizard-function]]
+When clicking '''Function''', the dialog changes to the function layout. It has the following components:
+* [[Feature clauses|Feature clause selection]]
+* [[Name field|Feature name field]]
+* [[Argument list|Argument list]]
+* [[Type selection|Type selection]]
+* [[Header comment|Header comment field]]
+* [[Precondition|Precondition field]]
+* [[Local variable|Local variable field]]
+* [[Feature body|Selection for: normal, once, deferred or external routine]]
+* [[Postcondition|Postcondition field]]
+
+==Example==
+ [[Image:feature-wizard-function-example]]
+class
+ PRODUCT
+
+feature -- Status report
+
+ order_price (quantity: INTEGER): DOUBLE is
+ -- Total price when ordering `quantity'.
+ require
+ quantity_non_negative: quantity >= 0
+ do
+ Result := quantity * price
+ ensure
+ correct: Result = quantity * price
+ end
+
+end -- class PRODUCT
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-procedure-layout.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-procedure-layout.wiki
new file mode 100644
index 00000000..32a5be30
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-procedure-layout.wiki
@@ -0,0 +1,35 @@
+[[Property:title|New procedure layout]]
+[[Property:weight|2]]
+ [[Image:feature-wizard-procedure]]
+When clicking '''Procedure''', the window changes to the procedure layout. It has the following components:
+* [[Feature clauses|Feature clause selection]]
+* [[Name field|Feature name field]]
+* [[Argument list|Argument list]]
+* [[Header comment|Header comment field]]
+* [[Precondition|Precondition field]]
+* [[Local variable|Local variable field]]
+* [[Feature body|Selection for: normal, once, deferred or external routine]]
+* [[Postcondition|Postcondition field]]
+
+==Example==
+ [[Image:feature-wizard-procedure-example]]
+class
+ PRODUCT
+
+feature {PERSON} -- Element change
+
+ place_order (person: PERSON; quantity: INTEGER) is
+ -- Mail `quantity' to `person'.
+ require
+ person /= Void and quantity > 0
+ do
+ person.mail_order (Current, quantity)
+ ensure
+ person.has_ordered (Current)
+ end
+
+end -- class PRODUCT
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/index.wiki
new file mode 100644
index 00000000..3bc4f7a0
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Wizards and dialogs]]
+[[Property:weight|0]]
+* [[Profiler Wizard|Profiler Wizard]]
+* [[Dialogs|Dialogs]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/index.wiki
new file mode 100644
index 00000000..6ad35bb5
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Profiler Wizard]]
+[[Property:weight|0]]
+* [[Profiler wizard: Introduction|Introduction]]
+* [[Profiler wizard guided tour|Profiler wizard guided tour]]
+* [[Profiler How To's|Profiler How To's]]
+* [[Profiler wizard reference|Profiler reference]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/how-set-profiler-configuration-file.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/how-set-profiler-configuration-file.wiki
new file mode 100644
index 00000000..672dd61d
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/how-set-profiler-configuration-file.wiki
@@ -0,0 +1,51 @@
+[[Property:title|How to set up a Profiler Configuration File]]
+[[Property:weight|0]]
+Once executing an instrumented system has generated the proper file, you must have a profile converter process it in order to produce the Execution Profile. The need for the converter comes from the various formats that profilers use to record run-time information during an execution; a simple Profiler Configuration File enables you to describe the format used by any particular profiler.
+
+The Profiler Configuration File is a file found in the directory $ISE_EIFFEL/studio/profiler where $ISE_EIFFEL is the location of the Eiffel installation. The name of the Profiler Configuration File in that directory is Eiffel for internal profiling and, for external profiling, the name of the profiler tool as specified in the profiler option. EiffelStudio comes with 3 preconfigured external profilers:
+* '''gprof:''' GNU's gprof
+* '''win32_ms:''' Visual C++ 5.0 or 6.0
+* '''profiler.info:''' Pure Atria's Quantify
+
+The Profiler Configuration File describes the structure of the file generated by the profiler. To create a new Profiler Configuration File for another profiler, just create a new file in the directory $ISE_EIFFEL/studio/profiler and fill it in.
+
+Here is a complete example showing the various options that maybe specified:
+number_of_columns: 7
+ -- Number of columns in the file.
+
+index_column: 1
+ -- Column where the index is stored.
+
+function_time_column: 3
+ -- Column where the time spent in the function is stored.
+
+descendent_time_column: 4
+ -- Column where the time spent in the descendents of a function is stored.
+
+number_of_calls_column: 5
+ -- Column where the number of calls to a function is stored.
+
+function_name_column: 6
+ -- Column where the name of the function is stored.
+
+percentage_column: 2
+ -- Column where the percentage of time spent in the function is stored.
+
+second_percentage_column: 0
+ -- Column where the second percentage of time spent in the function is stored.
+
+generates_leading_underscore: no
+ -- Says whether the profiler generates leading underscores (yes) or not (no).
+
+As in Eiffel, -- introduces a comment, which has no effect on the specification. If one of the xxx_column options has a value of 0, this means that the files generated by the given profiler contain no such column. The order of the options is not significant.
+
+
+
+
+{{seealso| '''See Also'''
+[[Select a Run-time information record to generate the Execution Profile|Select a Run-time information record to generate the Execution Profile]]
+[[Profiling|How to profile a system]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/index.wiki
new file mode 100644
index 00000000..c9d5cbb7
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/index.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Profiler How To's]]
+[[Property:weight|2]]
+* [[How to set up a Profiler Configuration File|How to setup a Profiler Configuration File]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/index.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/index.wiki
new file mode 100644
index 00000000..9d959dfc
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Profiler wizard guided tour]]
+[[Property:weight|1]]
+# [[Select the Compilation mode|'''First step:''' Select which version of your system you ran using the profiler: Workbench or Finalized]] .
+# [[Reuse or Generate an Execution Profile| '''Second step (only appears when an ''' ''Execution Profile'' '''has already been generated for this system)''': Select an existing ''Execution Profile'' or choose to generate a new ''Execution Profile'' from a ''Run-time information record''. ]]
+# [[Select a Run-time information record to generate the Execution Profile| '''Third step (only appears when generating a new ''' ''Execution Profile''''')''': Generate a new ''Execution Profile'' from a ''Run-time information record''. ]]
+# [[Select the information you need and formulate your query|'''Final step''': Select the information you need and formulate your query.]]
+# [[Profile query window|Profile query window]]
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|How the Profiler wizard works]]
+[[Profiling|How to profile a system]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/profile-query-window.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/profile-query-window.wiki
new file mode 100644
index 00000000..f06023e2
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/profile-query-window.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Profile query window]]
+[[Property:weight|4]]
+The profile query window displays the results of the query you have formulated in the [[Select the information you need and formulate your query|Final state]] of the Profiler wizard. It also lets you change the sub queries of the current query.
+
+To add a new sub query to the current query, fill in the text field labeled '''Define new sub query''' (type in ''calls <20'' for example) and click the '''And''' or '''Or''' button. To display the results of the new query click on the '''Update''' button.
+
+To remove an existing sub query, select it in the '''Active query''' list and click on the '''Inactivate >''' button.
+
+To activate an existing sub query, select it in the '''Inactive query''' list and click on the '''< Activate''' button.
+
+To change the operator affecting an existing sub query, select it in either the '''Active query''' or the '''Inactive query''' list and click on the '''Or''' or '''And''' button.
+
+Click on the '''Save''' button to save the currently displayed results in a text file.
+
+{{tip| '''Tip''': To visualize the result in Microsoft Excel or any other spreadsheet, select the entire text (except the first three lines where the Execution Profile file is specified), copy it and then paste it into Excel. }}
+
+ [[Image:profiler-query-window]]
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|How the Profiler wizard works]]
+[[Profiling|How to profile a system]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/reuse-or-generate-execution-profile.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/reuse-or-generate-execution-profile.wiki
new file mode 100644
index 00000000..11ead725
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/reuse-or-generate-execution-profile.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Reuse or Generate an Execution Profile]]
+[[Property:weight|1]]
+The second screen of the wizard lets you reuse a previously generated ''Execution Profile'' or generate a new ''Execution Profile'' from a ''Run-time information record''.
+
+The profiler wizard has detected that one or more ''Execution Profiles'' have already been generated for this system in this compilation mode. If you have executed your system after the generation of the existing profile, select '''Generate a profile from Run-time information record''' to create a new ''Execution Profile'' for the newly produced ''Run-time information record''.
+
+{{note| '''Note''': If you choose '''Generate a profile from Run-time information record''' the generated ''Execution Profile'' will be written into ''/EIFGENa/target_name/W_CODE/profinfo.pfi'' if you have selected '''Workbench mode''' in the first step, or ''/EIFGENs/target_name/F_CODE/profinfo.pfi'' if you have selected '''Finalized mode'''. If a file with the same name already exists its content will be destroyed and replaced. }}
+
+
+However, if you have not executed your system since the generation of the last ''Execution Profile'', there is no need to generate a new ''Execution Profile''. If you are in the latter case, select '''Use existing profile''' and choose the last ''Execution Profile'' you have generated.
+
+{{tip| '''Tip''': If you want to archive different ''Execution Profiles'' (to compare them for example), rename the ''profinfo.pfi'' file into a new name but keep the .pfi extension. The profiler wizard detects existing Execution Profiles by checking the file extensions. }}
+
+ [[Image:profiler-wizard-second-state]]
+
+
+Clicking '''Next''' will lead you to the [[Select a Run-time information record to generate the Execution Profile|Third state]] if you have selected '''Generate a profile from Run-time information record'''. On the other hand if you have selected '''Use existing profile''' you will go to the [[Select the information you need and formulate your query|Final state]] .
+
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|How the Profiler wizard works]]
+[[Profiling|How to profile a system]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-compilation-mode.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-compilation-mode.wiki
new file mode 100644
index 00000000..f00bba7e
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-compilation-mode.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Select the Compilation mode]]
+[[Property:weight|0]]
+The first screen of the wizard lets you specify the mode in which the profiled system was compiled.
+
+If you have run a finalized system under the control of the profiler then select '''Finalized mode''' and click '''Next'''. On the contrary if you have executed the system in Workbench mode then select '''Workbench mode''' and click '''Next'''.
+
+ [[Image:profiler-wizard-first-state]]
+
+
+Clicking '''Next''' will lead you to the [[Reuse or Generate an Execution Profile|Second state]] or to the [[Select a Run-time information record to generate the Execution Profile|Third state]] depending on whether an ''Execution Profile'' has already been generated for this compilation mode or not. If no ''Execution Profile'' has been generated so far (which happens the first time you execute this wizard for a specified project in a given compilation mode) you will go to the [[Select a Run-time information record to generate the Execution Profile|Third state]] , otherwise you will go to the [[Reuse or Generate an Execution Profile|Second state]] .
+
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|How the profiler wizard works]] [[Profiling|How to profile a system]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-information-you-need-and-formulate-your-query.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-information-you-need-and-formulate-your-query.wiki
new file mode 100644
index 00000000..116c1d11
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-information-you-need-and-formulate-your-query.wiki
@@ -0,0 +1,58 @@
+[[Property:title|Select the information you need and formulate your query]]
+[[Property:weight|3]]
+The final screen of the wizard lets you select the information you want to be displayed in the profile query window.
+
+==Select the information you need==
+
+Check or uncheck any of the check buttons in '''Output switches''' to select the columns you want to be displayed. Each switch turns on or off the corresponding column output. You should toggle columns on or off depending on what you would like to see in the result of the computation. Here are the explanations of each switch:
+* '''Feature name''': Display the name of the current feature.
+* '''Number of calls''': Display the number of times the current feature was called during the instrumented execution.
+* '''Function time''': Display the time spent in the current feature (not counting the time spent in features called by the current feature).
+* '''Descendant time''': Display the time spent in all features called during the execution of the current feature.
+* '''Total time''': Display the total time spent in the feature. This value is equal to ''Function time + Descendant time''.
+* '''Percentage''': Display the percentage of time spent in the current feature. This value is equal to ''Total time / Execution time''.
+
+Check or uncheck any of the check buttons in the '''Language type''' to select the type of features you want to be displayed. If you select only one language, the query result will not contain any information about routines written in the other language. The default is Eiffel only.
+* Eiffel features: Display the features written in Eiffel.
+* C functions: Display the functions written in C.
+* Recursive functions: Display recursive functions.
+
+==Formulate your query==
+
+When running a query, you are able to type a complete query. After pressing the '''Next''' button, a new window will be displayed to show the result of the query. The total query can be either a single one or a set of sub-queries separated by one of the two operators 'or' or 'and'.
+
+Each sub-query must have the following syntax 'attribute operator value' where:
+* 'attribute' is one of:
+** feature name
+** calls
+** total
+** self
+** descendants
+** percentage
+
+* 'operator' is one of: <, >, <=, >=, =, /=, in
+* 'value' is one of:
+** An integer (for calls)
+** A string (for feature name). The string may contain wild card characters: ?, standing for arbitrary characters, and *, standing for arbitrary sub-strings.
+** A real value (for other attributes)
+** An interval, of the form a-b for two values a and b.
+** max
+** min
+** avg
+
+
+
+ [[Image:profiler-wizard-fourth-state]]
+
+
+
+Clicking '''Next''' will open the [[Profile query window|Profile query window]] and display the results of the formulated query.
+
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|How the Profiler wizard works]]
+[[Profiling|How to profile a system]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-run-time-information-record-generate-execution-profile.wiki b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-run-time-information-record-generate-execution-profile.wiki
new file mode 100644
index 00000000..1caa9111
--- /dev/null
+++ b/documentation/current/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-run-time-information-record-generate-execution-profile.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Select a Run-time information record to generate the Execution Profile]]
+[[Property:weight|2]]
+The third screen of the wizard lets you generate an ''Execution Profile'' from a ''Run-time information record''. You should provide the ''Run-time information record'' produced by the profiler in the text field labeled '''Run-time information record'''. If the file provided by default is not the desired one change it by clicking on the '''Browse''' button or by directly entering it in the text field.
+
+Then, in the combo box labeled '''Profiler used to produce the above record''', select the profiler that has been used to produce the ''Run-time information record'' you have entered. If the profiler used to execute the system does not appear in the combo box, you have to add it. See [[How to set up a Profiler Configuration File|How to set up a Profiler Configuration File]] for more details on how to do so.
+
+{{note| '''Note''': ''The Run-time information record'' has to be located in the ''EIFGENs/target_name/W_code'' directory of your project. }}
+
+
+ [[Image:profiler-wizard-third-state]]
+
+
+
+Clicking '''Next''' will lead you to the [[Select the information you need and formulate your query|Final state]] if the provided ''Run-time information record'' is valid. If the ''Run-time information record'' is not valid or is not located in the ''EIFGENs/target_name/W_code'' directory of the project, you will go to the '''Run-time Information Record Error state''' as shown below.
+
+ [[Image:profiler-wizard-rtir-error-state]]
+
+
+{{seealso| '''See Also'''
+[[Profiler wizard: Introduction|How the Profiler wizard works]]
+[[Profiling|How to profile a system]]
+[[How to set up a Profiler Configuration File|How to set up a Profiler Configuration File]] }}
+
+
+
+
diff --git a/documentation/current/eiffelstudio/index.wiki b/documentation/current/eiffelstudio/index.wiki
new file mode 100644
index 00000000..0437b5cf
--- /dev/null
+++ b/documentation/current/eiffelstudio/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelStudio]]
+[[Property:weight|-9]]
+Type: Tool
+Platform: Any
+Version: 6.0
+Availability: Basic Package
+
+See:
+* [[EiffelStudio Introduction|Introduction]]
+* [[EiffelStudio: A Guided Tour|Guided Tour]]
+* [[EiffelStudio How To's|How To's]]
+* [[EiffelStudio Reference|Reference]]
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/index.wiki b/documentation/current/eiffelstudio/software-installation/index.wiki
new file mode 100644
index 00000000..c4790aab
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Software Installation]]
+[[Property:weight|-2]]
+For detailed installation instructions please follow the link for the product your are installing.
+
+==[[Software Installation for EiffelStudio 6.2|EiffelStudio 6.3]]==
+
+==[[Third Party Tools Installalation Help|Third Party Tools]]==
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-freebsd.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-freebsd.wiki
new file mode 100644
index 00000000..04241e00
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-freebsd.wiki
@@ -0,0 +1,126 @@
+[[Property:title|EiffelStudio 6.2 for FreeBSD]]
+[[Property:link_title|FreeBSD]]
+[[Property:weight|1]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| PC with 300 MHz or higher Pentium II class processor or equivalent recommended.
+|-
+| '''Operating System'''
+| FreeBSD 5.2 with either Gnome 2.6 or GTK+ 2.4.
+|-
+| '''Memory'''
+| 512 MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 400Mb uncompressed hard disk space (700Mb recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''freebsd-x86''' for x86 based CPU.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for FreeBSD|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for FreeBSD|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to freebsd-x86.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=freebsd-x86
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM freebsd-x86
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for FreeBSD|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for FreeBSD|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for FreeBSD|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for FreeBSD|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-openvms.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-openvms.wiki
new file mode 100644
index 00000000..0fdd44ac
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-openvms.wiki
@@ -0,0 +1,97 @@
+[[Property:title|EiffelStudio 6.2 for HP OpenVMS]]
+[[Property:link_title|HP OpenVMS]]
+[[Property:weight|2]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| AlphaServer.
+|-
+| '''Operating System'''
+| HP OpenVMS/Alpha version 7.3.2 with DECWindows and GTK+ 1.2.10.
+|-
+| '''C compiler'''
+| Compaq C compiler V6 or later.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 1GB free disk space on an ODS-5 formatted volume, plus an additional 1GB of free space while performing the software installation.
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 1.2.10 or above to function properly. You can check that you have this installed correctly by typing the following command:
+gtk-config --version
+The command should succeed and the version number of GTK+ should appear. If it is not 1.2.10 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 1.2.10.
+
+==Installing the Enterprise Edition==
+
+===From the Web===
+
+After downloading the '''eif62vms.zip''' installation package, unzip the distribution into temp:[dir] where where temp:[dir] is the location of a temporary directory:
+unzip eif62vms.zip temp:[dir]
+
+And use the following commands to install the files into eiffel_installation_path where eiffel_installation_path is a device:[directory] on an ODS-5 volume:
+set file/attrib=(org:seq,rfm:fix,lrl:9216) temp:[dir]eif62vms.save
+backup temp:[dir]eif62vms.save/save eiffel_installation_path
+
+===From a CD===
+
+You must mount the installation CD-ROM volume with the following qualifier:
+mount cd_dev:/media_format=cdrom/undefined_fat=fixed:cr:9216
+
+where cd_dev: is the CD-ROM device. And use the following commands to install the files into eiffel_installation_path where eiffel_installation_path is a device:[directory] on an ODS-5 volume:
+backup cd_dev:[000000]eif62vms.save/save eiffel_installation_path
+
+===Completing the installation===
+
+You must define a system-wide rooted logical name to reference the installation directory, for instance:
+define/system EIFFEL62 eiffel_installation_path:[directory.] /trans=conceal
+
+To use EiffelStudio for OpenVMS, run the setup procedure to define the environment:
+@eiffel_installation_path:[000000]setup
+This will define the logical names and DCL symbols required to run Eiffel.
+
+Once the files are copied and once the environment is setup up set, you need to register EiffelStudio. To do so type the following command:
+RUN ISE_EIFFEL:[000000]register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web broswer appears, it is most likely because netscape is not installed on your machine or is not in your path. Instead you should manually launch a new web browser and go to the page [http://activate.eiffel.com http://activate.eiffel.com] and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file ISE_EIFFEL:[install.limand].ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at ISE_EIFFEL:[install.limand] and enter your '''Username''' and '''CD Key'''.
+
+Once this is done you can jump to the next section "Using EiffelStudio."
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-tru64-unix.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-tru64-unix.wiki
new file mode 100644
index 00000000..dcc562d5
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-tru64-unix.wiki
@@ -0,0 +1,126 @@
+[[Property:title|EiffelStudio 6.2 for HP Tru64 UNIX]]
+[[Property:link_title|HP Tru64 UNIX]]
+[[Property:weight|4]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| AlphaServer.
+|-
+| '''Operating System'''
+| HP Tru64 UNIX 5.1B with GTK+ 2.4.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''alpha'''.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for HP Tru64 UNIX|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for HP Tru64 UNIX|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to alpha.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=alpha
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM alpha
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for HP Tru64 UNIX|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for HP Tru64 UNIX|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for HP Tru64 UNIX|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for HP Tru64 UNIX|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-ux.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-ux.wiki
new file mode 100644
index 00000000..ce0a2db2
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-hp-ux.wiki
@@ -0,0 +1,126 @@
+[[Property:title|EiffelStudio 6.2 for HP-UX]]
+[[Property:link_title|HP-UX]]
+[[Property:weight|3]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| HP-PA.
+|-
+| '''Operating System'''
+| HP-UX 11 with GTK+ 2.4.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''hpux-11'''.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for HP-UX|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for HP-UX|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to hpux-11.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=hpux-11
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM hpux-11
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for HP-UX|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for HP-UX|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for HP-UX|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for HP-UX|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-linux.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-linux.wiki
new file mode 100644
index 00000000..e08e235f
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-linux.wiki
@@ -0,0 +1,126 @@
+[[Property:title|EiffelStudio 6.2 for Linux]]
+[[Property:link_title|Linux]]
+[[Property:weight|5]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| PC with 300 MHz or higher Pentium II class processor or equivalent recommended.
+|-
+| '''Operating System'''
+| Fedora Core 2, Slackware 10 or any Linux system with glibc 2.3 and either Gnome 2.6 or GTK+ 2.4.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''linux-x86''' for x86 based CPU, '''linux-x86-64''' for amd64 based CPU.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for Linux|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for Linux|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to linux-x86 for the 32 bits version or linux-x86-64 for the 64 bits version. We will be using '''linux-x86''' in the examples below.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=linux-x86
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM linux-x86
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for Linux|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for Linux|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for Linux|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for Linux|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-linuxppc.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-linuxppc.wiki
new file mode 100644
index 00000000..fc79f3b1
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-linuxppc.wiki
@@ -0,0 +1,126 @@
+[[Property:title|EiffelStudio 6.2 for LinuxPPC]]
+[[Property:link_title|LinuxPPC]]
+[[Property:weight|6]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| PowerPC.
+|-
+| '''Operating System'''
+| Yellow Dog Linux 4.0 with either Gnome 2.6 or GTK+ 2.4.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''linux-ppc'''.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for LinuxPPC|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for LinuxPPC|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to linux-ppc.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=linux-ppc
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM linux-ppc
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for LinuxPPC|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for LinuxPPC|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for LinuxPPC|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for LinuxPPC|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-mac-os-x.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-mac-os-x.wiki
new file mode 100644
index 00000000..888530d5
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-mac-os-x.wiki
@@ -0,0 +1,76 @@
+[[Property:title|EiffelStudio 6.2 for Mac OS X]]
+[[Property:link_title|Mac OS X]]
+[[Property:weight|0]]
+==Requirements==
+
+{|
+|-
+| Computer/Processor
+| G4
+|-
+| Operating System
+| Mac OS X 10.4 (Tiger) or above
+|-
+| Memory
+| 512MB of RAM (1GB recommended)
+|-
+| Hard Disk
+| 400MB of hard disk space (1GB recommended)
+|-
+| Drive
+| CD-ROM or DVD drive (not required when downloading EiffelStudio)
+|-
+| Display
+| 1024 x 768 or higher resolution video adapter and monitor
+|-
+| Peripherals
+| Keyboard and mouse or compatible pointing device
+|-
+| '''ISE_PLATFORM'''
+| '''macosx-ppc''' or '''macosx-x86'''.
+|}
+
+
+==Prerequisites==
+
+Before installing EiffelStudio 6.2, it is necessary to install X11 for Mac OS X and the X11 SDK. They are available with the OS X CD. For more details check the Apple web site at:
+* [http://www.apple.com/macosx/features/x11/ http://www.apple.com/macosx/features/x11/]
+
+You also need to install the latest Apple Developer Tools (XCode) available as part of Mac OS X (Tiger or above)
+
+
+==Installing the Free Edition==
+
+After downloading the '''Eiffel62.dmg''' installation package, double click on it to mount the disk image. Then double click on the '''Eiffel62.pkg''' file to launch the installation procedure. Follow the steps indicated in the dialogs to complete the installation.
+
+==Installing the Enterprise Edition==
+
+Insert the CD into your CD-ROM drive. Open the CD-ROM contents and double click on the '''Eiffel62.pkg''' file to launch the installation procedure. Follow the steps indicated in the dialogs to complete the installation.
+
+ [[Image:56--mac-setup|Setup dialog]]
+
+Run EiffelStudio, located at /Developers/Applications/Eiffel62/EiffelStudio. Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+You now need to launch EiffelStudio to register your copy. Follow the instructions located in the '''Starting EiffelStudio''' section below. The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--mac-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web broswer appears, it is most likely because Safari is not installed on your machine or is not in your path. Instead you should manually launch a new web browser and go to the page [http://activate.eiffel.com http://activate.eiffel.com] and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--mac-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file '''/Developer/Applications/Eiffel62/EiffelStudio.app/Contents/Resources/Eiffel62/install/limand/.ec_license'''. To solve this, rerun the '''register''' program with a user account that has permissions to write at '''/Developer/Applications/Eiffel62/EiffelStudio.app/Contents/Resources/Eiffel62/install/limand''' and enter your '''Username''' and '''CD Key'''.
+
+==Starting EiffelStudio==
+
+Now everything should be properly installed and you should be able to run the compiler. You can now launch EiffelStudio from the Finder under '''/Developer/Applications/Eiffel62/'''. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-sgi-irix.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-sgi-irix.wiki
new file mode 100644
index 00000000..e7afe4d6
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-sgi-irix.wiki
@@ -0,0 +1,129 @@
+[[Property:title|EiffelStudio 6.2 for SGI Irix]]
+[[Property:link_title|SGI Irix]]
+[[Property:weight|8]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| MIPS.
+|-
+| '''Operating System'''
+| Irix 6.5 with either Gnome 2.6 or GTK+ 2.4.
+|-
+| '''C compiler'''
+| MIPSPro C compiler V2.4 or later.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''irix-mips''' for 32 bits, '''irix-mips-64''' for 64 bits.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for SGI Irix|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for SGI Irix|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to irix-mips for the 32 bits version or irix-mips-64 for the 64 bits version. We will be using '''irix-mips''' in the examples below.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=irix-mips
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM irix-mips
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for SGI Irix|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for SGI Irix|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for SGI Irix|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for SGI Irix|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-solaris.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-solaris.wiki
new file mode 100644
index 00000000..f58d171f
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/eiffelstudio-solaris.wiki
@@ -0,0 +1,126 @@
+[[Property:title|EiffelStudio 6.2 for Solaris]]
+[[Property:link_title|Solaris]]
+[[Property:weight|9]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| UltraSparc.
+|-
+| '''Operating System'''
+| Solaris 9.0 or greater for Sparc, Solaris 10 or greater for x86 with either Gnome 2.6 or GTK+ 2.4.
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended).
+|-
+| '''Drive'''
+| CD-ROM or DVD drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''solaris-sparc''' for 32 bits version of Solaris on Sparc processor, '''solaris-sparc-64''' for 64 bits versions, '''solaris-x86''' and '''solaris-x86-64''' for the Intel processor on 32 and 64 bits.
+|}
+
+
+==Checking your environment==
+
+EiffelStudio 6.2 requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command:
+pkg-config --modversion gtk+-2.0
+The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0.
+
+==Installing EiffelStudio from the Web==
+
+After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel62.tgz):
+
+cd /usr/local
+tar xvfz /tmp/Eiffel62.tgz
+
+This will install EiffelStudio 6.2 files into /usr/local/Eiffel62. Once this is done, jump to the [[EiffelStudio 6.2 for Solaris|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio.
+
+==Installing EiffelStudio from a CD-ROM==
+
+Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom):
+cd /usr/local
+cp -r /mnt/cdrom/Eiffel62 .
+
+This will install the EiffelStudio 6.2 files into /usr/local/Eiffel62. To complete the installation of EiffelStudio, jump to the next section, [[EiffelStudio 6.2 for Solaris|Setting up EiffelStudio]] .
+
+==Setting up EiffelStudio==
+
+Once the files have been installed, you should define the following environment variables in order to run EiffelStudio:
+* '''ISE_EIFFEL''' to /usr/local/Eiffel62
+* '''ISE_PLATFORM''' to solaris-sparc for the 32 bits version or solaris-sparc-64 for the 64 bits version, respectively solaris-x86 and solaris-x86-64 for Solaris on Intel processors. We will be using '''solaris-sparc''' in the examples below.
+and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable.
+
+Using sh or bash as a shell, it suffices to type the following commands:
+
+export ISE_EIFFEL=/usr/local/Eiffel62
+export ISE_PLATFORM=solaris-sparc
+export PATH=$PATH:$'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin
+
+
+Using csh or tcsh as a shell, it suffices to type the following commands:
+
+setenv ISE_EIFFEL /usr/local/Eiffel62
+setenv ISE_PLATFORM solaris-sparc
+set path = ($path $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin)
+
+
+If you are using the Enterprise edition, please follow the instructions of the next section, [[EiffelStudio 6.2 for Solaris|Registering the Enterprise Edition]] , otherwise jump to the [[EiffelStudio 6.2 for Solaris|Using EiffelStudio]] section at the end of this document.
+
+==Registering the Enterprise Edition==
+
+This step assumes you have followed the instructions in the [[EiffelStudio 6.2 for Solaris|Setting up EiffelStudio]] section. Perform the following commands to start the registration process:
+cd $ISE_EIFFEL
+./register
+
+A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below:
+
+ [[Image:56--unix-setup|Setup dialog]]
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio.
+
+The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--unix-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--unix-registration-error|Registration incomplete]]
+
+This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''.
+
+Once this is done, you can jump to the next section, [[EiffelStudio 6.2 for Solaris|Using EiffelStudio]] .
+
+==Using EiffelStudio==
+
+===Setting up the examples===
+
+Most of the examples require that you have a precompiled version of EiffelBase. To build it, simply run the script $'''ISE_EIFFEL'''/make_install after having completed all of the above steps. This script also prompts you to precompile EiffelVision which is not required to compile the examples and you can safely skip this step if you do not intend to use a precompiled of EiffelVision.
+
+===Starting EiffelStudio===
+
+Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+===EiffelStudio Appearance===
+
+EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory.
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki
new file mode 100644
index 00000000..f72b0c1d
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Software Installation for EiffelStudio 6.2]]
+[[Property:link_title|Software Installation for EiffelStudio]]
+[[Property:weight|0]]
+Select the operating system you are using for detailed installation instructions:
+
+* [[EiffelStudio 6.2 for Mac OS X|Apple Mac OS X]]
+* [[EiffelStudio 6.2 for FreeBSD|FreeBSD]]
+* [[EiffelStudio 6.2 for HP OpenVMS|HP OpenVMS]]
+* [[EiffelStudio 6.2 for HP-UX|HP-UX]]
+* [[EiffelStudio 6.2 for HP Tru64 UNIX|HP Tru64 UNIX]]
+* [[EiffelStudio 6.2 for Linux|Linux]]
+* [[EiffelStudio 6.2 for LinuxPPC|Linux PPC]]
+* [[EiffelStudio 6.2 for Windows|Microsoft Windows]]
+* [[EiffelStudio 6.2 for SGI Irix|SGI Irix]]
+* [[EiffelStudio 6.2 for Solaris|Sun Solaris]]
+
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/windows.wiki b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/windows.wiki
new file mode 100644
index 00000000..ad038bfa
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/windows.wiki
@@ -0,0 +1,72 @@
+[[Property:title|EiffelStudio 6.2 for Windows]]
+[[Property:link_title|Windows]]
+[[Property:weight|7]]
+==Requirements==
+
+{|
+|-
+| '''Computer/Processor'''
+| PC with 300 MHz or higher Pentium II class processor or equivalent recommended.
+|-
+| '''Operating System'''
+| Windows NT/2000/XP/2003/Vista (.NET support is for Microsoft Windows 2000, XP and 2003 only).
+|-
+| '''Memory'''
+| 512MB of RAM (1GB recommended).
+|-
+| '''Hard Disk'''
+| 500MB of hard disk space (1GB recommended). Hard disk space requirements will vary depending on configuration; custom installation choices may require more or less space. Space required for installation of the Microsoft .NET Framework will also be required.
+|-
+| '''Drive'''
+| CD-ROM drive (not required when downloading EiffelStudio).
+|-
+| '''Display'''
+| 1024 x 768 or higher resolution video adapter and monitor.
+|-
+| '''Peripherals'''
+| Keyboard and mouse or compatible pointing device.
+|-
+| '''ISE_PLATFORM'''
+| '''windows''' for 32 bits version of Windows, '''win64''' for 64 bits version of Windows.
+|}
+
+
+==Installing EiffelStudio from the Web==
+
+After downloading the '''Eiffel62.msi''' installation package, right click on it and select '''Install'''. This will launch the installation procedure. Follow the steps indicated in the dialogs to complete the installation.
+
+==Installing the Enterprise Edition.==
+
+Insert the CD into your CD-ROM drive. If you have the autorun facility enabled, the installation process will automatically be launched. Otherwise you can launch it by executing '''Eiffel62.msi''' located at the root of the CD. During the installation you will be asked for your '''Username''' and '''CD Key'''
+
+Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition, or that you will have received via email. Once the information is correct, the '''Next''' button will be enabled. Click '''Next''' and follow the steps indicated in the dialogs to complete the installation.
+
+Once installed, the first time you launch EiffelStudio, you will be asked for an activation key through the following dialog:
+
+ [[Image:56--windows-registration|Registration dialog]]
+
+By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy.
+
+You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation.
+
+You may receive the following dialog when launching EiffelStudio:
+
+ [[Image:56--windows-registration-error|Registration incomplete]]
+
+This probably means that EiffelStudio was not properly installed using the '''setup.exe''' program. Uninstall EiffelStudio and rerun the installation procedure by making sure to launch '''setup.exe''' and enter your '''Username''' and '''CD Key'''.
+
+==.NET Support==
+
+To enable .NET support in EiffelStudio, it is necessary to install the Microsoft .NET Framework prior to starting the installation of EiffelStudio. EiffelStudio currently supports versions 1.0 and 1.1 of the .NET Framework. Partial support for the .NET Framework 2.0 beta has been added in this version of EiffelStudio.
+
+==What about Windows 95, 98 and Me?==
+
+EiffelStudio will not run on Windows 95, 98 and Me. Contact Eiffel Software directly if you need support for those OSes. EiffelStudio generated code could run on 95, 98 and Me if no UI is being used. If the UI is used it could run but it requires installing the Microsoft Layer for Unicode.
+
+==Starting EiffelStudio==
+
+Now everything should be properly installed and you should be able to run the compiler. You can now launch EiffelStudio from the Start menu or from the EiffelStudio shortcut on your desktop. If you are a new user to EiffelStudio, we recommend that you follow [[EiffelStudio General: A Guided Tour|the guided tour]] .
+
+
+
+
diff --git a/documentation/current/eiffelstudio/software-installation/third-party-tools-installation-help.wiki b/documentation/current/eiffelstudio/software-installation/third-party-tools-installation-help.wiki
new file mode 100644
index 00000000..febf923f
--- /dev/null
+++ b/documentation/current/eiffelstudio/software-installation/third-party-tools-installation-help.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Third Party Tools Installalation Help]]
+[[Property:link_title|Third Party Tools Installation Help]]
+[[Property:weight|1]]
+Here you can find help for installing third party tools and programs which may be necessary for your Eiffel programming needs.
+*
+==[http://dev.eiffel.com/Installing_Microsoft_C_compiler Free Microsoft C Compiler ]==
+
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-agents.wiki b/documentation/current/method/eiffel-tutorial-et/et-agents.wiki
new file mode 100644
index 00000000..fd8af2a1
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-agents.wiki
@@ -0,0 +1,199 @@
+[[Property:title|11 Agents]]
+[[Property:link_title|ET: Agents]]
+[[Property:weight|-3]]
+Our last mechanism, agents, adds one final level of expressive power to the framework describe so far. Agents apply object-oriented concepts to the modeling of operations.
+
+==Objects for operations==
+
+Operations are not objects; in fact, object technology starts from the decision to separate these two aspects, and to choose object types, rather than the operations, as the basis for modular organization of a system, attaching each operation to the resulting modules -- the classes.
+
+In a number of applications, however, we may need objects that represent operations, so that we can include them in object structures that some other piece of the software will later traverse to uncover the operations and, usually, execute them. Such "operation wrapper" objects, called agents, are useful in a number of application areas such as:
+* GUI (Graphical User Interface) programming, where we may associate an agent with a certain event of the interface, such as a mouse click at a certain place on the screen, to prescribe that if the event occurs -- a user clicks there -- it must cause execution of the agent's associated operation.
+* Iteration on data structures, where we may define a general-purpose routine that can apply an arbitrary operation to all the elements of a structure such as a list; to specify a particular operation to iterate, we will pass to the iteration mechanism an agent representing that operation.
+* Numerical computation, where we may define a routine that computes the integral of any applicable function on any applicable interval; to represent that function and pass its representation to the integration routine, we will use an agent.
+
+
+Operations in Eiffel are expressed as routines, and indeed every agent will have an associated routine. Remember, however, that the fundamental distinction between objects and operations remains: an agent is an object, and it is not a routine; it represents a routine. As further evidence that this is a proper data abstraction, note that the procedure call , available on all agents to call the associated routine, is only one of the features of agents. Other features may denote properties such as the class to which the routine belongs, its precondition and postcondition, the result of the last call for a function, the number of arguments.
+
+==Building an agent==
+
+In the simplest form, also one of the most common, you obtain an agent just by writing
+
+agent r
+
+
+where r is the name of a routine of the enclosing class. This is an expression, which you may assign to a writable entity, or pass as argument to a routine. Here for example is how you will specify event handling in the style of the EiffelVision 2 GUI library:
+
+your_icon.click_actions.extend (agent your_routine)
+
+
+This adds to the end of my_icon.click_actions -- the list of agents associated with the "click" event for my_icon , denoting an icon in the application's user interface -- an agent representing your_routine . Then when a user clicks on the associated icon at execution, the EiffelVision 2 mechanisms will call the procedure call on every agent of the list, which for this agent will execute your_routine . This is a simple way to associate elements of your application, more precisely its "business model" (the processing that you have defined, directly connected to the application's business domain), with elements of its GUI.
+
+Similarly although in a completely different area, you may request the integration of a function your_function over the interval 0..1 through a call such as
+
+your_integrator.integral (agent your_function, 0, 1)
+
+
+In the third example area cited above, you may call an iterator of EiffelBase through
+
+your_list.do_all (agent your_proc)
+
+
+with your_list of a type such as LIST [YOUR_TYPE] . This will apply your_proc to every element of the list in turn.
+
+The agent mechanism is type-checked like the rest of Eiffel; so the last example is valid if and only if your_proc is a procedure with one argument of type YOUR_TYPE .
+
+==Operations on agents==
+
+An agent agent r built from a procedure r is of type PROCEDURE [T, ARGS] where T represents the class to which r belongs and ARGS the type of its arguments. If r is a function of result type RES , the type is FUNCTION [T, ARGS, RES] . Classes PROCEDURE and FUNCTION are from the Kernel Library of EiffelBase, both inheriting from ROUTINE [T, ARGS] .
+
+Among the features of ROUTINE and its descendants the most important are call , already noted, which calls the associated routine, and item , appearing only in FUNCTION and yielding the result of the associated function, which it obtains by calling call .
+
+As an example of using these mechanisms, here is how the function integral could look like in our INTEGRATOR example class. The details of the integration algorithm (straight forward, and making no claims to numerical sophistication) do not matter, but you see, in the highlighted line, the place were we evaluate the mathematical function associated with f , by calling item on f :
+
+integral (f: FUNCTION [ANY, TUPLE [REAL], REAL]; low, high: REAL): REAL is
+ -- Integral of `f' over the interval [`low', `high']
+ require
+ meaningful_interval: low <= high
+ local
+ x: REAL
+ do
+ from
+ x := low
+ invariant
+ x >= low
+ x <= high + step
+ -- Result approximates the integral over
+ -- the interval [low, low.max (x - step)]
+ until
+ x > high
+ loop
+ Result := Result + step * f.item ([x])
+ x := x + step
+ end
+ end
+
+
+Function integral takes three arguments: the agent f representing the function to be integrated, and the two interval bounds. When we need to evaluate that function for the value x , in the line
+
+Result := Result + step * f.item ([x])
+
+
+we don't directly pass x to item ; instead, we pass a one-element tuple [x] , using the syntax for manifest tuples introduced in [[10 Other Mechanisms|"Tuple types", page 90]] . You will always use tuples for the argument to call and item , because these features must be applicable to any routine, and so cannot rely on a fixed number of arguments. Instead they take a single tuple intended to contain all the arguments. This property is reflected in the type of the second actual generic parameter to f , corresponding to ARGS (the formal generic parameter of FUNCTION ): here it's TUPLE [REAL] to require an argument such as [ x] , where x is of type REAL .
+
+Similarly, consider the agent that the call seen above:
+
+your_icon.click_actions.extend (agent your_routine)
+
+
+added to an EiffelVision list. When the EiffelVision mechanism detects a mouse click event, it will apply to each element item of the list of agents, your_icon.click_actions , an instruction such as
+
+item.call ([x, y])
+
+
+where x and y are the coordinates of the mouse clicking position. If item denotes the list element agent your_routine, inserted by the above call to extend , the effect will be the same as that of calling
+
+your_routine (x, y)
+
+
+assuming that your_routine indeed takes arguments of the appropriate type, here INTEGER representing a coordinate in pixels. (Otherwise type checking would have rejected the call to extend .)
+
+==Open and closed arguments==
+
+In the examples so far, execution of the agent's associated routine, through item or call , passed exactly the arguments that a direct call to the routine would expect. You can have more flexibility. In particular, you may build an agent from a routine with more arguments than expected in the final call, and you may set the values of some arguments at the time you define the agent.
+
+Assume for example that a cartographical application lets a user record the location of a city by clicking on the corresponding position on the map. The application may do this through a procedure
+
+record_city (cn: STRING; pop: INTEGER; x, y: INTEGER)
+ -- Record that the city of name `cn' is at coordinates
+ -- `x' and `y' with population `pop'.
+
+
+Then you can associate it with the GUI through a call such as
+
+map.click_actions.extend (agent record_city (name, population, ?, ?))
+
+
+assuming that the information on the name and the population has already been determined. What the agent denotes is the same as agent your_routine as given before, where your_routine would be a fictitious two-argument routine obtained from record_city -- a four-argument routine -- by setting the first two arguments once and for all to the values given, name and population .
+
+In the agent agent record_city (name, population, ?, ?) , we say that these first two arguments, with their set values, are '''closed'''; the last two are '''open'''. The question mark syntax introduced by this example may only appear in agent expressions; it denotes open arguments. This means, by the way, that you may view the basic form used in the preceding examples, agent your_routine , as an abbreviation -- assuming your_routine has two arguments -- for agent your_routine (?, ?) . It is indeed permitted, to define an agent with all arguments open, to omit the argument list altogether; no ambiguity may result.
+
+For type checking, agent record_city (name, population, ?, ?) and agent ,your_routine are acceptable in exactly the same situations, since both represent routines with two arguments. The type of both is
+
+PROCEDURE [ANY, TUPLE [INTEGER, INTEGER]]
+
+
+where the tuple type specifies the open operands.
+
+A completely closed agent, such as agent your_routine (25, 32) or agent record_city (name, population, 25, 32) , has the type TUPLE , with no parameters; you will call it with call ([ ]) , using an empty tuple as argument.
+
+The freedom to start from a routine with an arbitrary number of arguments, and choose which ones you want to close and which ones to leave open, provides a good part of the attraction of the agent mechanism. It means in particular that in GUI applications you can limit to the strict minimum the "glue" code (sometimes called the controller in the so-called MVC, Model-View Controller, scheme of GUI design) between the user interface and "business model" parts of a system. A routine such as record_city is a typical example of an element of the business model, uninfluenced -- as it should be -- by considerations of user interface design. Yet by passing it in the form of an agent with partially open and partially closed arguments, you may be able to use it directly in the GUI, as shown above, without any "controller" code.
+
+As another example of the mechanism's versatility, we saw above an integral function that could integrate a function of one variable over an interval, as in
+
+your_integrator.integral (agent your_function (0, 1))
+
+
+Now assume that function3 takes three arguments. To integrate function3 with two arguments fixed, you don't need a new integral function; just use the same integral as before, judiciously selecting what to close and what to leave open:
+
+your_integrator.integral (agent function3 (3.5, ?, 6.0), 0, 1)
+
+
+==Open targets==
+
+All the agent examples seen so far were based on routines of the enclosing class. This is not required. Feature calls, as you remember, were either unqualified, as in f (x, y) , or qualified, as in a.g (x, y) . Agents, too, have a qualified variant as in
+
+agent a.g
+
+
+which is closed on its target a and open on the arguments. Variants such as agent a.g (x, y) , all closed, and agent a.g (?, y) , open on one argument, are all valid.
+
+You may also want to make the target open. The question mark syntax could not work here, since it wouldn't tell us the class to which feature g belongs, known in the preceding examples from the type of a . As in creation expressions, we must list the type explicitly; the convention is the same: write the types in braces, as in
+
+agent {SOME_TYPE}.g
+agent {SOME_TYPE}.g (?, ?)
+agent {SOME_TYPE}.g (?, y)
+
+
+The first two of these examples are open on the target and both operands; they mean the same. The third is closed on one argument, open on the other and on the target.
+
+These possibilities give even more flexibility to the mechanism because they mean that an operation that needs agents with certain arguments open doesn't care whether they come from an argument or an operand of the original routine. This is particularly useful for iterators and means that if you have two lists
+
+your_account_list: LIST [ACCOUNT]
+your_integer_list: LIST [INTEGER]
+
+
+you may write both
+
+your_account_list.do_all (agent deposit_one_grand)
+your_integer_list.do_all (agent add_to_n)
+
+
+even though the two procedures used in the agents have quite different forms. We are assuming here that the first one, in class ACCOUNT , is something like
+
+deposit_one_grand is
+ -- Add one thousand dollars to `balance' of account.
+ do
+ balance := balance + 1000
+ end
+
+
+so that it doesn't take an argument: it is normally called on its target, as in my_account.deposit_one_grand . In contrast, the other routine has an argument:
+
+add_to_n (x: INTEGER) is
+ -- Add `x' to the value of `total'.
+ do
+ total := total + x
+ end
+
+
+where total is an integer attribute of the enclosing class. Without the versatility of playing with open and closed arguments for both the original arguments and target, you would have to write separate iteration mechanisms for these two cases. Here you can use a single iteration routine of LIST and similar classes of EiffelBase, do_all , for both purposes:
+* Depositing money on every account in a list of accounts.
+* Adding all the integers in a list of integers.
+
+
+Agents provide a welcome complement to the other mechanisms of Eiffel. They do not conflict with them but, when appropriate -- as in the examples sketched in this section -- provide clear and expressive programming schemes, superior to the alternatives.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki
new file mode 100644
index 00000000..c67a17a0
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki
@@ -0,0 +1,324 @@
+[[Property:title|8 Design by Contract (tm), Assertions and Exceptions]]
+[[Property:link_title|ET: Design by Contract (tm), Assertions and Exceptions]]
+[[Property:weight|-8]]
+Eiffel directly implements the ideas of Design by Contract™ , which enhance software reliability and provide a sound basis for software specification, documentation and testing, as well as exception handling and the proper use of inheritance.
+
+==Design by Contract™ basics==
+
+A system -- a software system in particular, but the ideas are more general -- is made of a number of cooperating components. Design by Contract™ states that their cooperation should be based on precise specifications -- contracts -- describing each party's expectations and guarantees.
+
+An Eiffel contract is similar to a real-life contract between two people or two companies, which it is convenient to express in the form of tables listing the expectations and guarantees. Here for example is how we could sketch the contract between a homeowner and the telephone company:
+{|
+|-
+| provide_service|| style="width=10%;"
+| '''OBLIGATIONS'''|| style="width=35%;"
+| '''BENEFITS'''|| style="width=35%;"
+|-
+| '''Client'''
+| (Satisfy precondition:)
+Pay bill.
+| (From postcondition:)
+Get telephone service Supplier.
+|-
+| '''Supplier'''
+| (Satisfy precondition:)
+Provide telephone service.
+| (From postcondition:)
+No need to provide anything if bill not paid.
+|}
+
+Note how the obligation for each of the parties maps onto a benefit for the other. This will be a general pattern.
+
+The client's obligation, which protects the supplier, is called a '''precondition'''. It states what the client must satisfy before requesting a certain service. The client's benefit, which describes what the supplier must do (assuming the precondition was satisfied), is called a '''postcondition'''.
+
+In addition to preconditions and postconditions, contract clauses include '''class invariants''', which apply to a class as a whole. More precisely a class invariant must be ensured by every creation procedure (or by the default initialization if there is no creation procedure), and maintained by every exported routine of the class.
+
+==Expressing assertions==
+
+Eiffel provides syntax for expressing preconditions ( require ), postconditions ( ensure ) and class invariants ( invariant ), as well as other assertion constructs studied later (see [[10 Other Mechanisms|"Instructions", page 84]] ): loop invariants and variants, check instructions.
+
+Here is a partial update of class ACCOUNT with more assertions:
+
+indexing
+ description: "Simple bank accounts"
+
+class
+ ACCOUNT
+
+feature -- Access
+
+ balance: INTEGER
+ -- Current balance
+
+ deposit_count: INTEGER is
+ -- Number of deposits made since opening
+ do
+ ... As before ...
+ end
+
+feature -- Element change
+
+ deposit (sum: INTEGER) is
+ -- Add `sum' to account.
+ require
+ non_negative: sum >= 0
+ do
+ ... As before ...
+ ensure
+ one_more_deposit: deposit_count = old deposit_count + 1
+ updated: balance = old balance + sum
+ end
+
+feature {NONE} -- Implementation
+
+ all_deposits: DEPOSIT_LIST
+ -- List of deposits since account's opening.
+
+invariant
+ consistent_balance: (all_deposits /= Void) implies
+ (balance = all_deposits . total)
+ zero_if_no_deposits: (all_deposits = Void) implies
+ (balance = 0)
+
+end -- class ACCOUNT
+
+
+Each assertion is made of one or more subclauses, each of them a boolean expression (with the additional possibility of the old construct). The effect of including more than one sub clause, as in the postcondition of deposit and in the invariant, is the same as connecting them through an and . Each clause may be preceded by a label, such as consistent_balance in the invariant, and a colon; the label is optional and does not affect the assertion's semantics, except for error reporting as explained in the next section, but including it systematically is part of the recommended style. The value of the boolean expression a implies b is true except if a is true and b false.
+
+Because assertions benefit from the full power of boolean expressions, they may include function calls. This makes it possible to express sophisticated consistency conditions, such as " the graph contains no cycle", which would not be otherwise expressible through simple expressions, or even through first-order predicate calculus, but which are easy to implement as Eiffel functions returning boolean results.
+
+The precondition of a routine expresses conditions that the routine is imposing on its clients. Here a call to deposit is correct if and only if the value of the argument is non-negative. The routine does not guarantee anything for a call that does not satisfy the precondition. It is in fact part of the Eiffel method that a routine body should '''never''' test for the precondition, since it is the client's responsibility to ensure it. (An apparent paradox of Design by Contract™, which is reflected in the bottom-right entries of the preceding and following contract tables, and should not be a paradox any more at the end of this discussion, is that one can get more reliable software by having fewer explicit checks in the software text.)
+
+The postcondition of a routine expresses what the routine guaranteed to its clients for calls satisfying the precondition. The notation old expression , valid in postconditions ( ensure clauses) only, denotes the value that expression had on entry to the routine.
+
+The precondition and postcondition state the terms of the contract between the routine and its clients, similar to the earlier example of a human contract:
+{|
+|-
+| deposit|| style="width=10%;"
+| '''OBLIGATIONS'''|| style="width=35%;"
+| '''BENEFITS'''|| style="width=35%;"
+|-
+| '''Client'''
+| (Satisfy precondition:)
+Use a non-negative argument.
+| (From postcondition:)
+Get deposits list and balance updated.
+|-
+| '''Supplier'''
+| (Satisfy precondition:)
+Update deposits list and balance.
+| (From postcondition:)
+No need to handle negative arguments.
+|}
+
+The class invariant, as noted, applies to all features. It must be satisfied on exit by any creation procedure, and is implicitly added to both the precondition and postcondition of every exported routine. In this respect it is both good news and bad news for the routine implementer: good news because it guarantees that the object will initially be in a stable state, averting the need in the example to check that the total of all_deposits is compatible with the balance ; bad news because, in addition to its official contract as expressed by its specific postcondition, every routine must take care of restoring the invariant on exit.
+
+A requirement on meaningful contracts is that they should be in good faith: satisfiable by an honest partner. This implies a consistency rule: if a routine is exported to a client (either generally or selectively), any feature appearing in its precondition must also be available to that client. Otherwise -- for example if the precondition included require n > 0 , where n is a secret attribute -- the supplier would be making demands that a good-faith client cannot possibly check for.
+
+Note in this respect that guaranteeing a precondition does not necessarily mean, for the client, testing for it. Assuming n is exported, a call may test for the precondition
+
+if x.n > 0 then x.r end
+
+
+possibly with an else part. But if the context of the call, in the client's code, implies that n is positive -- perhaps because some preceding call set it to the sum of two squares -- then there is no need for an if or similar construct.
+
+{{note|In such a case, a check instruction as introduced later ( [[10 Other Mechanisms|"Instructions", page 84]] ) is recommended if the reason for omitting the test is non-trivial. }}
+
+==Using contracts for built-in reliability==
+
+What are contracts good for? Their first use is purely methodological. By applying a discipline of expressing, as precisely as possible, the logical assumptions behind software elements, you can write software whose reliability is built-in: software that is developed hand-in-hand with the rationale for its correctness.
+
+This simple observation -- usually not clear to people until they have practiced Design by Contract™ thoroughly on a large-scale project -- brings as much change to software practices and quality as the rest of object technology.
+
+==Run-time assertion monitoring==
+
+Contracts in Eiffel are not just wishful thinking. They can be monitored at run time under the control of compilation options.
+
+It should be clear from the preceding discussion that contracts are not a mechanism to test for special conditions, for example erroneous user input. For that purpose, the usual control structures ( if deposit_sum > 0 then ...) are available, complemented in applicable cases by the exception handling mechanism reviewed next. An assertion is instead a '''correctness condition''' governing the relationship between two software modules (not a software module and a human, or a software module and an external device). If sum is negative on entry to deposit , violating the precondition, the culprit is some other software element, whose author was not careful enough to observe the terms of the deal. Bluntly:
+
+{{note| '''Assertion Violation rule '''A run-time assertion violation is the manifestation of a bug. }}
+
+To be more precise:
+* A precondition violation signals a bug in the client, which did not observe its part of the deal.
+* A postcondition (or invariant) violation signals a bug in the supplier -- the routine -- which did not do its job.
+
+
+That violations indicate bugs explains why it is legitimate to enable or disable assertion monitoring through mere compilation options: for a correct system -- one without bugs -- assertions will always hold, so the compilation option makes no difference to the semantics of the system.
+
+But of course for an incorrect system the best way to find out where the bug is -- or just that there is a bug -- is often to monitor the assertions during development and testing. Hence the presence of the compilation options, which EiffelStudio lets you set separately for each class, with defaults at the system and cluster levels:
+* no : assertions have no run-time effect.
+* require : monitor preconditions only, on routine entry.
+* ensure : preconditions on entry, postconditions on exit.
+* invariant : like ensure , plus class invariant on both entry and exit for qualified calls.
+* all : like invariant , plus check instructions, loop invariants and loop variants ( [[10 Other Mechanisms|"Exception handling", page 46]] ).
+
+
+An assertion violation, if detected at run time under one of these options other than the first, will cause an exception ( [[8 Design by Contract (tm), Assertions and Exceptions|"Instructions", page 84]] ). Unless the software has an explicit "retry" plan as explained in the discussion of exceptions, the violation will cause produce an exception trace and cause termination (or, in EiffelStudio, a return to the environment's browsing and debugging facilities at the point of failure). If present, the label of the violated sub clause will be displayed, to help identify the problem.
+
+The default is require . This is particularly interesting in connection with the Eiffel method's insistence on reuse: with libraries such as EiffelBase, richly equipped with preconditions expressing terms of use, an error in the '''client software''' will often lead, for example through an incorrect argument, to violating one of these preconditions. A somewhat paradoxical consequence is that even an application developer who does not apply the method too well (out of carelessness, haste, indifference or ignorance) will still benefit from the presence of contracts in someone else's library code.
+
+During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with static typing and the immediate feedback of compilation techniques such as the Melting Ice Technology, this permits the development process mentioned in the section [[3 The Software Process in Eiffel|"Quality and functionality", page 10]] , where errors are exterminated at birth. No one who has not practiced the method in a real project can imagine how many mistakes are found in this way; surprisingly often, a violation will turn out to affect an assertion that was just included for goodness' sake, the developer being convinced that it could never "possibly" fail to be satisfied.
+
+By providing a precise reference (the description of what the software is supposed to do) against which to assess the reality (what the software actually does), Design by Contract™ profoundly transforms the activities of debugging, testing and quality assurance.
+
+When releasing the final version of a system, it is usually appropriate to turn off assertion monitoring, or bring it down to the require level. The exact policy depends on the circumstances; it is a trade off between efficiency considerations, the potential cost of mistakes, and how much the developers and quality assurance team trust the product. When developing the software, however, you should always assume -- to avoid loosening your guard -- that in the end monitoring will be turned off.
+
+==The contract form of a class==
+
+Another application of assertions governs documentation. Environment mechanisms, such as clicking the Form Contract icon in Eiffelstudio, will produce, from a class text, an abstracted version which only includes the information relevant for client authors. Here is the contract form of class ACCOUNT in the latest version given:
+
+indexing
+ description: "Simple bank accounts"
+
+class interface
+ ACCOUNT
+
+feature -- Access
+
+ balance: INTEGER
+ -- Current balance
+
+ deposit_count: INTEGER
+ -- Number of deposits made since opening
+
+feature -- Element change
+
+ deposit (sum: INTEGER)
+ -- Add `sum' to account.
+ require
+ non_negative: sum >= 0
+ ensure
+ one_more_deposit: deposit_count = old deposit_count + 1
+ updated: balance = old balance + sum
+
+invariant
+ consistent_balance: balance = all_deposits.total
+
+end -- class interface ACCOUNT
+
+
+The words interface class are used instead of just class to avoid any confusion with actual Eiffel text, since this is documentation, not executable software. (It is in fact possible to generate a compilable variant of the Contract Form in the form of a deferred class, a notion defined later.)
+
+Compared to the full text, the Contract Form of a class (also called its "short form") retains all its interface properties, relevant to client authors:
+* Names and signatures (argument and result type information) for exported features.
+* Header comments of these features, which carry informal descriptions of their purpose. (Hence the importance, mentioned in section [[4 Hello World|4]] , of always including such comments and writing them carefully.)
+* Preconditions and postconditions of these features (at least the subclauses involving only exported features).
+* Class invariant (same observation).
+
+
+The following elements, however, are not in the Contract Form: any information about non-exported features; all the routine bodies ( do clauses, or the external and once variants seen in [[5 The Static Picture: System Organization|"External software", page 16]] above and [[10 Other Mechanisms|"Once routines and shared objects", page 82]] below); assertion subclauses involving non-exported features; and some keywords not useful in the documentation, such as is for a routine.
+
+In accordance with the Uniform Access principle (page [[6 The Dynamic Structure: Execution Model|19]] ), the Contract Form does not distinguish between attributes and argument-less queries. In the above example, balance could be one or the other, as it makes no difference to clients, except possibly for performance.
+
+The Contract Form is the fundamental tool for using supplier classes in the Eiffel method. It enables client authors to reuse software elements without having to read their source code. This is a crucial requirement in large-scale industrial developments.
+
+The Contract Form satisfies two key requirements of good software documentation:
+* It is truly abstract, free from the implementation details of what it describes and concentrating instead on its functionality.
+* Rather than being developed separately -- an unrealistic requirement, hard to impose on developers initially and becoming impossible in practice if we expect the documentation to remain up to date as the software evolves -- the documentation is extracted from the software itself. It is not a separate product but a different view of the same product. This prolongs the '''Single Product''' principle that lies at the basis of Eiffel's seamless development model (section [[3 The Software Process in Eiffel|3]] ).
+
+
+The Contract Form is only one of the relevant views. EiffelStudio, for example, generates graphical representations of system structures, to show classes and their relations -- client, inheritance -- according to the conventions of BON (the Business Object Notation). In accordance with the principles of seamlessness and reversibility, EiffelStudio lets you both work on the text, producing the graphics on the fly, or work on the graphics, updating the text on the fly; you can alternate as you wish between these two modes. The resulting process is quite different from more traditional approaches based on separate tools: an analysis and CASE workbench, often based on UML, to deal with an initial "bubble-and-arrow" description; and a separate programming environment, to deal with implementation aspects only. In Eiffel the environment provides consistent, seamless support from beginning to end.
+
+The Contract Form -- or its variant the Flat-Contract Form, which takes account of inheritance ( [[9 Inheritance|"Flat and Flat-Contract Forms", page 72]] ) are the standard form of library documentation, used extensively, for example, in the book [http://www.eiffel.com/doc/page.html Reusable Software] (see bibliography). Assertions play a central role in such documentation by expressing the terms of the contract. As demonstrated a contrario by the widely publicized $500-million crash of the Ariane-5 rocket launcher in June of 1996, due to the incorrect reuse of a software module from the Ariane-4 project, '''reuse without a contract documentation''' is the path to disaster. Non-reuse would, in fact, be preferable.
+
+==Exception handling==
+
+Another application of Design by Contract™ governs the handling of unexpected cases. The vagueness of many discussions of this topic follows from the lack of a precise definition of terms such as "exception". With Design by Contract™ we are in a position to be specific:
+* Any routine has a contract to achieve.
+* Its body defines a strategy to achieve it -- a sequence of operations, or some other control structure involving operations. Some of these operations are calls to routines, with their own contracts; but even an atomic operation, such as the computation of an arithmetic operation, has an implicit contract, stating that the result will be representable.
+* Any one of these operations may fail , that is to say be unable to meet its contract; for example an arithmetic operation may produce an overflow (a on-representable result).
+* The failure of an operation is an '''exception''' for the routine that needed the operation.
+* As a result the routine may fail too -- causing an exception in its own caller.
+
+
+Note the precise definitions of the two key concepts, failure and exception. Although failure is the more basic one -- since it is defined for atomic, non-routine operations -- the definitions are mutually recursive, since an exception may cause a failure of the recipient routine, and a routine's failure causes an exception in its own caller.
+
+Why state that an exception "may" cause a failure? It is indeed possible to "rescue" a routine from failure in the case of an exception, by equipping it with a clause labeled rescue , as in:
+
+read_next_character (f: FILE) is
+ -- Make next character available in last_character.
+ -- If impossible, set failed to True.
+ require
+ readable: file.readable
+ local
+ impossible: BOOLEAN
+ do
+ if impossible then
+ failed := True
+ else
+ last_character := low_level_read_function (f)
+ end
+ rescue
+ impossible := True
+ retry
+ end
+
+
+This example includes the only two constructs needed for exception handling: rescue and retry . A retry instruction is only permitted in a rescue clause; its effect is to start again the execution of the routine, without repeating the initialization of local entities (such as impossible in the example, which was initialized to False on first entry). Features failed and last_character are assumed to be attributes of the enclosing class.
+
+This example is typical of the use of exceptions: as a last resort, for situations that should not occur. The routine has a precondition, file.readable , which ascertains that the file exists and is accessible for reading characters. So clients should check that everything is fine before calling the routine. Although this check is almost always a guarantee of success, a rare combination of circumstances could cause a change of file status (because a user or some other system is manipulating the file) between the check for readable and the call to low_level_read_function . If we assume this latter function will fail if the file is not readable, we must catch the exception.
+
+A variant would be
+
+local
+ attempts: INTEGER
+do
+ if attempts < Max_attempts then
+ last_character := low_level_read_function (f)
+ else
+ failed := True
+ end
+rescue
+ attempts := attempts + 1
+ retry
+end
+
+
+which would try again up to Max_attempts times before giving up.
+
+The above routine, in either variant, never fails: it always fulfills its contract, which states that it should either read a character or set failed to record its inability to do so. In contrast, consider the new variant
+
+local
+ attempts: INTEGER
+do
+ last_character := low_level_read_function (f)
+rescue
+ attempts := attempts + 1
+ if attempts < Max_attempts then
+ retry
+ end
+end
+
+
+with no more role for failed . In this case, after Max_attempts unsuccessful attempts, the routine will execute its rescue clause to the end, with no retry (the if having no else clause). This is how a routine '''fails'''. It will, as noted, pass on the exception to its caller.
+
+Such a rescue clause should, before terminating, restore the invariant of the class so that the caller and possible subsequent retry attempts from higher up find the objects in a consistent state. As a result, the rule for an absent rescue clause -- the case for the vast majority of routines in most systems -- is that it is equivalent to
+
+rescue
+ default_rescue
+
+
+where procedure default_rescue comes from ANY , where it is defined to do nothing; in a system built for robustness, classes subject to non-explicitly-rescued exceptions should redefine default_rescue (perhaps using a creation procedure, which is bound by the same formal requirement) so that it will always restore the invariant.
+
+Behind Eiffel's exception handling scheme lies the principle -- at first an apparent platitude, but violated by many existing mechanisms -- that a routine should '''either succeed or fail'''. This is in turn a consequence of Design by Contract™ principles: succeeding means being able to fulfill the contract, possibly after one or more retry ; failure is the other case, which must always trigger an exception in the caller. Otherwise it would be possible for a routine to miss its contract and yet return to its caller in a seemingly normal state. That is the worst possible way to handle an exception.
+
+Concretely, exceptions may result from the following events:
+* A routine failure ( rescue clause executed to the end with no retry ), as just seen.
+* Assertion violation, if for a system that runs with assertion monitoring on.
+* Attempt to call a feature on a void reference: x.f (...) , the fundamental computational mechanism, can only work if x is attached to an object, and will cause an exception otherwise.
+* Developer exception, as seen next.
+* Operating system signal:arithmetic overfolow; no memory available for a requested creation or clone -- even after garbage collection has rummaged everything to find some space. (But no C/C++-like "wrong pointer address", which cannot occur thanks to the statically typed nature of Eiffel.)
+
+
+It is sometimes useful, when handling exceptions in rescue clauses, to ascertain the exact nature of the exception that got the execution there. For this it is suffices to inherit from the Kernel Library class EXCEPTIONS , which provides queries such as exception , giving the code for the last exception, and symbolic names ( [[10 Other Mechanisms|"Constant and unique attributes", page 83]] ) for all such codes, such as No_more_memory . You can then process different exceptions differently by testing exception against various possibilities. The method strongly suggests, however, that exception handling code should remain simple; a complicated algorithm in a rescue clause is usually a sign that the mechanism is being misused. Class EXCEPTIONS also provides various facilities for fine-tuning the exception facilities, such as a procedure raise that will explicitly trigger a "developer exception" with a code than can then be detected and processed. Exception handling helps produce Eiffel software that is not just correct but robust, by planning for cases that should not normally arise, but might out of Murphy's law, and ensuring they do not affect the software's basic safety and simplicity.
+
+==Other applications of Design by Contract™==
+
+The Design by Contract™ ideas pervade the Eiffel method. In addition to the applications just mentioned, they have two particularly important consequences:
+* They make it possible to use Eiffel for analysis and design. At a high level of abstraction, it is necessary to be precise too. With the exception of BON, object-oriented analysis and design methods tend to favor abstraction over precision. Thanks to assertions, it is possible to express precise properties of a system ("At what speed should the alarm start sounding?") without making any commitment to implementation. The discussion of deferred classes ( [[9 Inheritance|"Applications of deferred classes", page 60]] ) will show how to write a purely descriptive, non-software model in Eiffel, using contracts to describe the essential properties of a system without any computer or software aspect.
+* Assertions also serve to control the power of inheritance-related mechanisms -- redeclaration, polymorphism, dynamic binding -- and channel them to correct uses by assigning the proper semantic limits. See [[9 Inheritance|"Inheritance and contracts", page 66]] .
+
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki b/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki
new file mode 100644
index 00000000..2d6d0b04
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki
@@ -0,0 +1,555 @@
+[[Property:title|6 The Dynamic Structure: Execution Model]]
+[[Property:link_title|ET: The Dynamic Structure: Execution Model]]
+[[Property:weight|-10]]
+A system with a certain static structure describes a set of possible executions. The run-time model governs the structure of the data ( objects ) created during such executions.
+
+The properties of the run-time model are not just of interest to implementers; they also involve concepts directly relevant to the needs of system modelers and analysts at the most abstract levels.
+
+==Objects, fields, values and references==
+
+A class was defined as the static description of a type of run-time data structures. The data structures described by a ca class are called '''instances''' of the class, which in turn is called their '''generating class''' (or just "generator"). An instance of ACCOUNT is a data structure representing a bank account; an instance of LINKED_LIST is a data structure representing a linked list.
+
+An '''object''', as may be created during the execution of a system, is an instance of some class of the system.
+
+Classes and objects belong to different worlds: a class is an element of the software text; an object is a data structure created during execution. Although is possible to define a class whose instances represent classes, this does not eliminate the distinction between a static, compile-time notion, class, and a dynamic, run-time notion, object.
+
+An object is either an atomic object (integer, real, boolean, double) or a composite object made of a number of '''fields''', represented by adjacent rectangles on the conventional run-time diagrams:
+ [[Image:tutorial-5]]
+Each field is a '''value'''. A value can be either an object or an object reference:
+* When a field is an object, it will in most cases be an atomic object, as on the figure where the first field from the top is an integer and the third a character. But a field can also be a composite object, in which case it is called a '''subobject'''.
+* A '''reference''' is either void or uniquely identifies an object, to which it is said to be '''attached'''. In the preceding figure the second field from the top is a reference -- attached in this case, as represented by the arrow, to the enclosing object itself. The bottom field is a void reference.
+
+
+==Features==
+ [[Image:tutorial-6]]
+A feature, as noted, is an operation available on instances of a class. A feature can be either an '''attribute''' or a '''routine'''. This classification, which you can follow by starting from the right on the figure above, is based on implementation considerations:
+* An attribute is a feature implemented through memory: it describes a field that will be found in all instances of the class. For example class ACCOUNT may have an attribute balance ; then all instances of the class will have a corresponding field containing each account's current balance.
+* A routine describes a computation applicable to all instances of the class. ACCOUNT may have a routine withdraw .
+* Routines are further classified into '''functions''', which will return a result, and '''procedures''', which will not. Routine withdraw will be a procedure; an example of function may be highest_deposit , which returns the highest deposit made so far to the account.
+
+If we instead take the viewpoint of the '''clients''' of a class (the classes relying on its feature), you can see the relevant classification by starting from the left on the figure:
+* '''Commands''' have no result, and may modify an object. They may only be procedures.
+* '''Queries''' have a result: they return information about an object. You may implement a query as either an attribute (by reserving space for the corresponding information in each instance of the class, a memory-based solution) or a function (a computation-based solution). An attribute is only possible for a query without argument, such as balance ; a query with arguments, such as balance_on ( d) , returning the balance at date d , can only be a function.
+
+From the outside, there is no difference between a query implemented as an attribute and one implemented as a function: to obtain the balance of an account a , you will always write a . balance . In the implementation suggested above, a is an attribute, so that the notation denotes an access to the corresponding object field. But it is also possible to implement a as a function, whose algorithm will explore the lists of deposits and withdrawals and compute their accumulated value. To the clients of the class, and in the official class documentation as produced by the environment tools, the difference is not visible.
+
+This principle of '''Uniform Access''' is central to Eiffel's goals of extendibility, reusability and maintainability: you can change the implementation without affecting clients; and you can reuse a class without having to know the details of its features' implementations. Most object-oriented languages force clients to use a different notation for a function call and an attribute access. This violates Uniform Access and is an impediment to software evolution, turning internal representation changes into interface changes that may disrupt large parts of a system.
+
+==A simple class==
+
+The following simple class text illustrates the preceding concepts
+
+indexing
+ description: "Simple bank accounts"
+
+class
+ ACCOUNT
+
+feature -- Access
+
+ balance: INTEGER
+ -- Current balance
+
+ deposit_count: INTEGER is
+ -- Number of deposits made since opening
+ do
+ if all_deposits /= Void then
+ Result := all_deposits.count
+ end
+ end
+
+feature -- Element change
+
+ deposit (sum: INTEGER) is
+ -- Add `sum' to account.
+ do
+ if all_deposits = Void then
+ create all_deposits
+ end
+
+ all_deposits.extend (sum)
+ balance := balance + sum
+ end
+
+feature {NONE} -- Implementation
+
+ all_deposits: DEPOSIT_LIST
+ -- List of deposits since account's opening.
+
+invariant
+ consistent_balance:
+ (all_deposits /= Void) implies (balance = all_deposits.total)
+ zero_if_no_deposits:
+ (all_deposits = Void) implies (balance = 0)
+
+end -- class ACCOUNT
+
+
+(The { NONE } qualifier and the invariant clause, used here to make the example closer to a real class, will be explained shortly. DEPOSIT_LIST refers to another class, which can be written separately using library classes.)
+
+It's easy to deduce, from a feature's syntactic appearance, the category to which it belongs. Here:
+* Only deposit and deposit_count , which include a do ... clause, are routines.
+* balance and all_deposits , which are simply declared with a type, are attributes. Note that even for attributes it is recommended to have a header comment.
+* Routine deposit_count is declared as returning a result (of type INTEGER ); so it is a function. Routine deposit has no such result and hence is a procedure.
+
+==Creating and initializing objects==
+
+Classes, as noted, are a static notion. Objects appear at run time; they are created explicitly. Here is the basic instruction to create an object of type ACCOUNT and attach it to x :
+
+create x
+
+
+assuming that x has been declared of type ACCOUNT . Such an instruction must be in a routine of some class -- the only place where instructions can appear -- and its effect at run time will be threefold: create a new object of type ACCOUNT ; initialize its fields to default values; and attach the value of x to it. Here the object will have two fields corresponding to the two attributes of the generating class: an integer for balance , which will be initialized to 0, and a reference for all_deposits , which will be initialized to a void reference:
+ [[Image:tutorial-7]]
+The language specifies default initialization values for all possible types:
+{|
+|-
+|
+'''Type'''
+
+|
+|
+'''Default value'''
+
+|-
+|
+INTEGER, REAL, DOUBLE
+
+|
+|
+Zero
+
+|-
+|
+BOOLEAN
+
+|
+|
+False
+
+|-
+|
+CHARACTER
+
+|
+|
+Null
+
+|-
+|
+Reference types (such as ACCOUNT and DEPOSIT_LIST)
+
+|
+|
+Void reference
+
+|-
+|
+Composite expanded types (see next)
+
+|
+|
+Same rules, applied recursively to all fields
+
+|}
+
+It is possible to override the initialization values by providing -- as in the earlier example of class HELLO -- one or more creation procedures. For example we might change ACCOUNT to make sure that every account is created with an initial deposit:
+
+indexing
+ description : "Simple bank accounts, initialized with a first deposit"
+
+class
+ ACCOUNT1
+
+create
+ make
+
+feature -- Initialization
+
+ make (sum: INTEGER) is
+ -- Initialize account with `sum' .
+ do
+ deposit (sum)
+ end
+
+ -- The rest of the class as for ACCOUNT
+
+end -- class ACCOUNT1
+
+
+A create clause may list zero or more (here just one) procedures of the class.
+
+{{info|Note the use of the same keyword, create , for both a creation clause, as here, and creation instructions such as create x . }}
+
+In this case the original form of creation instruction, create x , is not valid any more for creating an instance of ACCOUNT1 ; you must use the form
+
+create x.make (2000)
+
+known as a creation call. Such a creation call will have the same effect as the original form -- creation, initialization, attachment to -- x followed by the effect of calling the selected creation procedure, which here will call deposit with the given argument.
+
+Note that in this example all that make does is to call deposit . So an alternative to introducing a new procedure make would have been simply to introduce a creation clause of the form create deposit , elevating deposit to the status of creation procedure. Then a creation call would be of the form create x . deposit ( 2000 ) .
+
+{{info|Some variants of the basic creation instruction will be reviewed later: instruction with an explicit type; creation expressions. See [[10 Other Mechanisms|"Creation variants", page 89]] . }}
+
+==Entities==
+
+The example assumed x declared of type ACCOUNT (or ACCOUNT1 ). Such an x is an example of '''entity''', a notion generalizing the well-known concept of variable. An entity is a name that appears in a class text to represent possible run-time values (a value being, as defined earlier, an object or a reference). An entity is one of the following:
+* An attribute of the enclosing class, such as balance and all_deposits .
+* A formal argument of a routine, such as sum for deposit and make .
+* A local entity declared for the internal needs of a routine.
+* The special entity Result in a function.
+
+
+The third case, local entities, arises when a routine needs some auxiliary values for its computation. Here is an example of the syntax:
+
+deposit (sum: INTEGER) is
+ -- Add sum to account.
+ local
+ new: AMOUNT
+ do
+ create new.make (sum)
+ all_deposits.extend (new)
+ balance := balance + sum
+ end
+
+
+This example is a variant of deposit for which we assume that the elements of a DEPOSIT_LIST such as all_deposits are no longer just integers, but objects, instances of a new class, AMOUNT . Such an object will contain an integer value, but possibly other information as well. So for the purpose of procedure deposit we create an instance of AMOUNT and insert it, using procedure extend , into the list all_deposits . The object is identified through the local entity new , which is only needed within each execution of the routine (as opposed to an attribute, which yields an object field that will remain in existence for as long as the object).
+
+The last case of entity, Result , serves to denote, within the body of a function, the final result to be returned by that function. This was illustrated by the function deposit_count , which read
+
+deposit_count: INTEGER is
+ -- Number of deposits made since opening (provisional version)
+ do
+ if all_deposits /= Void then
+ Result := all_deposit.count
+ end
+ end
+
+
+The value returned by any call will be the value of the expression all_deposits . count (to be explained in detail shortly) for that call, unless all_deposits has value ensure , denoting a void reference ( / is "not equal").
+
+The default initialization rules seen earlier for attributes (see the table on page [[6 The Dynamic Structure: Execution Model|21]] ) also serve to initialize local entities and Result on routine entry. So in the last example, if all_deposits is void (as in the case on initialization with the class as given so far), Result keeps its default value of 0, which will be returned as the result of the function.
+
+==Calls==
+
+Apart from object creation, the basic computational mechanism, in the object-oriented style of computation represented by Eiffel, is feature call. In its basic form, it appears as
+
+target.feature (argument1, ...)
+
+
+where target is an entity or more generally an expression, feature is a feature name, and there may be zero or more argument expressions. In the absence of any argument the part in parentheses should be removed.
+
+We have already seen such calls. If the feature denotes a procedure, the call is an instruction, as in
+
+all_deposits.extend (new)
+
+
+If feature denotes a query (function or attribute), the call is an expression, as in the right-hand side of
+
+Result := all_deposits.count
+
+
+Following the principle of Uniform Access (page [[6 The Dynamic Structure: Execution Model|19]] ), this form is the same for calls to attributes and to functions without arguments. In this example, feature count from class DEPOSIT_LIST may indeed be implemented in either of these two ways: we can keep a count field in each list, updating it for each insertion and removal; or we can compute count , whenever requested, by traversing the list and counting the number of items.
+
+In the case of a routine with arguments -- procedure or function -- the routine will be declared, in its class, as
+
+feature (formal1: TYPE1; ...) is
+ do
+ ...
+ end
+
+
+meaning that, at the time of each call, the value of each formal will be set to the corresponding actual ( formal1 to argument1 and so on).
+
+In the routine body, it is not permitted to change the value of a formal argument, although it is possible to change the value of an attached object through a procedure call such as formal1 . some_procedure ( ... ) .
+
+==Infix and prefix notation==
+
+Basic types such as INTEGER are, as noted, full-status citizens of Eiffel's type system, and so are declared as classes (part of the Kernel Library). INTEGER , for example, is characterized by the features describing integer operations: plus, minus, times, division, less than, and so on.
+
+With the dot notation seen so far, this would imply that simple arithmetic operations would have to be written with a syntax such as i . plus ( j) instead of the usual i + j . This would be awkward. Infix and prefix features solve the problem, reconciling the object-oriented view of computation with common notational practices of mathematics. The addition function is declared in class INTEGER as
+
+infix "+" (other: INTEGER): INTEGER is
+ do
+ ...
+ end
+
+
+Such a feature has all the properties and prerogatives of a normal "identifier" feature, except for the form of the calls, which is infix, as in i + j , rather than using dot notation. An infix feature must be a function, and take exactly one argument. Similarly, a function can be declared as prefix "-" , with no argument, permitting calls of the form -3 rather than ( 3 ) . negated .
+
+Predefined library classes covering basic types such as INTEGER , CHARACTER , BOOLEAN , REAL , DOUBLE are known to the Eiffel compiler, so that a call of the form j + i , although conceptually equivalent to a routine call, can be processed just as efficiently as the corresponding arithmetic expression in an ordinary programming language. This brings the best of both worlds: conceptual simplicity, enabling Eiffel developers, when they want to, to think of integers and the like as objects; and efficiency as good as in lower-level approaches.
+
+Infix and prefix features are available to any class, not just the basic types' predefined classes. For example a graphics class could use the name infix "|-|" for a function computing the distance between two points, to be used in expressions such as point1 |-| point2 .
+
+==Type declaration==
+
+Every entity appearing in an Eiffel text is declared as being of a certain type, using the syntax already encountered in the above examples:
+
+entity_name: TYPE_NAME
+
+
+This applies to attributes, formal arguments of routines and local entities. You will also declare the result type for a function, as in the earlier example
+
+deposit_count: INTEGER is ...
+
+
+Specifying such a function result type also declares, implicitly, the type for Result as used in the function's body.
+
+What is a type? With the elements seen so far, every type is a class . INTEGER , used in the declaration of deposits_count , is, as we have seen, a library class; and the declaration all_deposits : DEPOSIT_LIST assumes the existence of a class DEPOSIT_LIST .
+
+Three mechanisms introduced below -- expanded types (page [[6 The Dynamic Structure: Execution Model|26]] ), genericity (page [[7 Genericity and Arrays|36]] ) and anchored declarations (page [[9 Inheritance|79]] ) -- will generalize the notion of type slightly. But they do not change the fundamental property that '''every type is based on a class''', called the type's '''base class'''. In the examples seen so far, each type is a class, serving as its own base class.
+
+An instance of a class C is also called "an object of type C ".
+
+==Type categories==
+
+It was noted above that a value is either an object or a reference. This corresponds to two kinds of type: reference types and expanded types.
+
+If a class is declared as just
+
+class CLASS_NAME ...
+
+
+it defines a reference type. The entities declared of that type will denote references. So in the declaration
+
+x: ACCOUNT
+
+
+the possible run-time values for x are references, which will be either void or attached to instances of class ACCOUNT .
+
+Instead of class , however, you may use the double keyword expanded class , as in the EiffelBase class definition
+
+indexing
+ description : "Integer values"
+
+expanded class
+ INTEGER
+
+feature -- Basic operations
+
+ infix "+" (other: INTEGER): INTEGER is
+ do
+ ...
+ end
+
+ ... Other feature declarations ...
+
+end -- class INTEGER
+
+
+In this case the value of an entity declared as n : INTEGER is not a reference to an object, but the object itself -- in this case an atomic object, an integer value.
+
+It is also possible, for some non-expanded class C, to declare an entity as
+
+x: expanded
+
+
+so that the values for x will be objects of type C , rather than references to such objects. This is our first example of a type -- expanded C -- that is not directly a class, although it is based on a class, C . The base type of such a type is C .
+
+Note that the value of an entity of an expanded type can never be void; only a reference can. Extending the earlier terminology, an expanded entity is always '''attached to''' an object, atomic (as in the case of n : INTEGER ) or composite (as in x : expanded ACCOUNT ).
+
+Expanded declarations make it possible to construct composite objects with subobjects, as in the following abbreviated class declaration (indexing clause and routines omitted):
+
+class CAR
+
+feature
+
+ engine: expanded ENGINE
+
+ originating_plant: PLANT
+
+end -- class CAR
+
+
+Here is an illustration of the structure of a typical instance of CAR :
+ [[Image:tutorial-8]]
+This example also illustrates that the distinction between expanded and reference types is important not just for system implementation purposes but for high-level system modeling as well. Consider the example of a class covering the notion of car. Many cars share the same originating_plant , but an engine belongs to just one car. References represent the modeling relation "knows about"; subobjects, as permitted by expanded types, represent the relation "has part", also known as aggregation. The key difference is that sharing is possible in the former case but not in the latter.
+
+==Basic operations==
+
+To assign, copy and compare values, you can rely on a number of mechanisms. Two of them, assignment and equality testing, are language constructs; the others are library features, coming from the top-level class ANY seen earlier (page [[5 The Static Picture: System Organization|15]] ).
+
+Assignment uses the symbol : . The assignment instruction
+
+x := y
+
+
+updates the value of x to be the same as that of y . This means that:
+ [[Image:tutorial-9]]
+For entities of reference types, the value of x will be a void reference if the value of y is void, and otherwise x will be attached to the same object OBJ2 as y :
+ [[Image:tutorial-9]]
+For entities of expanded types, the values are objects; the object attached to x will be overwritten with the contents of the object attached to y . In the case of atomic objects, as in n := 3 with the declaration n : INTEGER , this has the expected effect of assigning to n the integer value 3 ; in the case of composite objects, this overwrites the fields for x , one by one, with the corresponding y fields.
+
+To copy an object, use x . copy ( y ) which assumes that both x and y are non-void, and copies the contents of y 's attached object onto those of x 's. For expanded entities the effect is the same as that the of the assignment x := y .
+
+A variant of the copy operation is clone . The expression clone ( y ) produces a newly created object, initialized with a copy of the object attached to y , or a void value if y itself is void. For a reference type (the only interesting case) the returned result for non-void is y a reference to the new object. This means we may view clone as a function that performs
+
+create Result
+Result.copy (y)
+
+
+So in the assignment x := clone ( y ) , assuming both entities of reference types and y not void, will attach x to a '''new object''' identical to y 's attached object, as opposed to the assignment x := y which attaches x to the '''same object''' as y .
+
+To determine whether two values are equal, use the expression x := y . For references, this comparison will yield true if the values are either both void or both attached to the same object; this is the case in the last figure in the state after the assignment, but not before. The symbol for not equal is /= , as in x /= y .
+
+As with assignment, there is also a form that works on objects rather than references: x . is_equal ( y ) will return true when x and y are both non-void and attached to field-by-field identical objects. This can be true even when x y is not, for example, in the figure, before the assignment, if the two objects shown are field-by-field equal.
+
+A more general variant of is_equal is used under the form equal ( x , y ). This is always defined, even if x is void, returning true whenever is_equal would but also if x and y are both void. (In contrast, x . is_equal ( y ) is not defined for void x and would, if evaluated, yield an exception as explained in [[8 Design by Contract (tm), Assertions and Exceptions|"Exception handling", page 46]] below.)
+
+ Void denotes a void reference. So you can make x void through the assignment x := Void , and test whether it is void through if x = Void then ...
+
+Where assignment := and the equality operators = and /= were language constructions, copy , clone , is_equal , equal and ensure are '''library features''' coming from class ANY . The type of ensure , as declared in ANY , is NONE , the "bottom" type.
+
+Using the redefinition mechanisms to be seen in the discussion of inheritance, a class can redefine copy and is_equal to cover specific notions of copy and equality. The assertions will ensure that the two remain compatible: after x . copy ( y ), the property x . is_equal ( y ) must always be true. The effect of clone will automatically follow a redefinition of copy , and equal will follow is_equal .
+
+To guarantee the original, non-redefined semantics you may use the variants standard_copy , standard_clone , standard_equal , all defined in ANY as "frozen", that is to say non-redefinable.
+
+==Deep operations and persistence==
+
+Feature clone only duplicates one object. If some of the object's fields are references to other objects, the references themselves will be copied, not those other objects.
+
+It is useful, in some cases, to duplicate not just one object but an entire object structure. The expression deep_clone ( y ) achieves this goal: assuming non-void y , it will produce a duplicate not just of the object attached to y but of the entire object structure starting at that object. The mechanism respects all the possible details of that structure, such as cyclic reference chains. Like the preceding features, deep_clone comes from class ANY .
+
+A related mechanism provides a powerful '''persistence''' facility. A call of the form
+
+x.store (Some_file_or_network_connection)
+
+
+will store a copy of the entire object structure starting at x , under a suitable representation. Like deep_clone , procedure store will follow all references to the end and maintain the properties of the structure. The function retrieved can then be used -- in the same system, or another -- to recreate the structure from the stored version.
+
+As the name suggests, Some_file_or_network_connection can be an external medium of various possible kinds, not just a file but possibly a database or network. The EiffelNet client-server library indeed uses the store - retrieved mechanism to exchange object structures over a network, between compatible or different machine architectures, for example a Windows client and a Unix server.
+
+==Memory management==
+
+Reference reattachments x := y of the form illustrated by the figure just above can cause objects to become unreachable. This is the case for the object identified as OBJ1 on that figure (the object to which x was attached before the assignment) if no other reference was attached to it.
+
+In all but toy systems, it is essential to reclaim the memory that has been allocated for such objects; otherwise memory usage could grow forever, as a result of creation instructions create x ... and calls to clone and the like, leading to thrashing and eventually to catastrophic termination.
+
+The Eiffel method suggests that the task of detecting and reclaiming such unused object space should be handled by an automatic mechanism (part of the Eiffel run-time environment), not manually by developers (through calls to procedures such as Pascal's dispose and C/C++'s free ). The arguments for this view are:
+
+'''Simplicity''' : handling memory reclamation manually can add enormous complication to the software, especially when -- as is often the case in object-oriented development -- the system manipulates complex run-time data structures with many links and cycles.
+
+'''Reliability''' : memory management errors, such as the incorrect reclamation of an object that is still referenced by a distant part of the structure, are a notorious source of dangerous and hard-to-correct bugs.
+
+The Eiffel Software's implementation of Eiffel provides a sophisticated '''garbage collector''' which efficiently handles the automatic reclamation process, while causing no visible degradation of a system's performance and response time.
+
+==Information hiding and the call rule==
+
+The basic form of computation, it has been noted, is a call of the form target . feature ( ... ) . This is only meaningful if feature denotes a feature of the generating class of the object to which target (assumed to be non-void) is attached. The precise rule is the following:
+
+{{note|Feature Call rule A call of the form target.feature (...) appearing in a class C is only valid if feature is a feature of the base class of target 's type, and is available to C.}}
+
+The first condition simply expresses that if target has been declared as target : A then feature must be the name of one of the features of A . The second condition reflects Eiffel's application of the principles of information hiding. A feature clause, introducing one or more feature declarations, may appear not only as
+
+feature -- Comment identifying the feature category
+
+ ... Feature declaration ...
+
+ ... Feature declaration ...
+
+ ...
+
+
+but may also include a list of classes in braces, feature { A , B , ... } , as was illustrated for ACCOUNT :
+
+feature {NONE} -- Implementation
+
+ all_deposits: DEPOSIT_LIST
+ -- List of deposits since account's opening.
+
+
+This form indicates that the features appearing in that clause are only '''available''' -- in the sense of available for calls, as used in the Feature Call rule -- to the classes listed. In the example feature all_deposits is only available to NONE . Because of the global inheritance structure (page [[5 The Static Picture: System Organization|15]] ) this means it is in fact available to no useful client at all, and is equivalent in practice to feature { } with an empty class list, although the form listing NONE explicitly is more visible and hence preferred.
+
+With this specification a class text including the declaration acc : ACCOUNT and a call of the form
+
+acc.all_deposits
+
+
+violates the Feature Call rule and will be rejected by the EiffelStudio compiler.
+
+Besides fully exported features (introduced by feature ... ; without further qualification) and fully secret ones ( feature { } or feature { NONE } ), it is possible to export features selectively to some specified classes, using the specification
+
+feature {A, B, ...}
+
+
+for arbitrary classes A , B , ... This enables a group of related classes to provide each other with privileged access, without requiring the introduction of a special module category above the class level (see [[5 The Static Picture: System Organization|"Clusters", page 15]] ).
+
+Exporting features selectively to a set of classes A , B , ... also makes them available to the descendants of these classes. So a feature clause beginning with just feature is equivalent to one starting with feature { ANY } .
+
+These rules enable successive feature clauses to specify exports to different clients. In addition, the recommended style, illustrated in the examples of this chapter, suggests writing separate feature clauses -- regardless of their use for specifying export privileges -- to group features into separate categories. The standard style rules define a number of fundamental categories and the order in which they should appear; they include: Initialization for creation procedures, Access for general queries, Status report for boolean-valued queries, Status setting , Element change , Implementation (for selectively exported or secret features. Every feature in the EiffelBase library classes belongs to one of the predefined categories.
+
+The Feature Call rule is the first of the rules that make Eiffel a '''statically typed''' approach, where the applicability of operations to objects is verified at compile time rather than during execution. Static typing is one of the principal components of Eiffel's support for reliability in software development.
+
+==Execution scenario==
+
+The preceding elements make it possible to understand the overall scheme of an Eiffel system's execution.
+
+At any time during the execution of a system, one object is the '''current object''' of the execution, and one of the routines of the system, the '''current routine''', is being executed, with the current object as its target. (We will see below how the current object and current routine are determined.) The text of a class, in particular its routines, make constant implicit references to the current object. For example in the instruction
+
+balance := balance + sum
+
+
+appearing in the body of procedure deposit of class ACCOUNT , the name of the attribute balance , in both occurrences, denotes the balance field of the current object, assumed to be an instance of ACCOUNT . In the same way, the procedure body that we used for the creation procedure make in the ACCOUNT1 variant
+
+make (sum: INTEGER) is
+ -- Initialize account with sum .
+ do
+ deposit (sum)
+ end
+
+
+contains a call to the procedure deposit . Contrary to earlier calls written in dot notation as target . feature ( ... ) , the call to deposit has no explicit target; this means its target is the current object, an instance of ACCOUNT1 . Such a call is said to be '''unqualified'''; those using dot notations are '''qualified''' calls.
+
+Although most uses of the current object are implicit, a class may need to name it explicitly. The predefined expression Current is available for that purpose. A typical use, in a routine merge ( other : ACCOUNT ) of class ACCOUNT , would be a test of the form
+
+if other = Current then
+ report_error ("Error: trying to merge an account with itself!")
+else
+ ... Normal processing (merging two different account) ...
+end
+
+
+With these notions it is not hard to define precisely the overall scenario of a system execution by defining which object and routine will, at each instant, be the current object and the current routine:
+
+Starting a system execution, as we have seen, consists in creating an instance of the root class, the root object, and executing a designated creation procedure, the root procedure, with the root object as its target. The root object is the initial current object, and the root procedure is the initial current procedure.
+
+From then on only two events can change the current object and current procedure: a qualified routine call; and the termination of a routine.
+
+In a call of the form target . routine ( ... ) , target denotes a certain object TC. (If not, that is to say, if the value of target is void, attempting to execute the call will trigger an exception, as studied below.) The generating class of TC must, as per the Feature Call rule, contain a routine of name routine . As the call starts, TC becomes the new current object and routine becomes the new current routine.
+
+When a routine execution terminates, the target object and routine of the most recent non-terminated call -- which, just before just before the terminated call, were the current object and the current routine -- assume again the role of current object and current routine.
+
+The only exception to the last rule is termination of the original root procedure call; in this case the entire execution terminates.
+
+==Abstraction==
+
+The description of assignments stated that in x := y the target x must be an entity. More precisely it must be a '''writable''' entity. This notion excludes formal routine arguments: as noted, a routine r ( arg : SOME_TYPE ) may assign to arg (reattaching it to a different object), although it can change the attached objects through calls of the form arg . procedure ( ... ) .
+
+Restricting assignment targets to entities precludes assignments of the form obj . some_attribute : some_value , since the left-hand side obj . some_attribute is an expression (a feature call), not an entity: you may no more assign to obj . some_attribute than to, say, b + a -- another expression that is also, formally, a feature call.
+
+To obtain the intended effect of such an assignment you may use a procedure call of the form obj . set_attribute ( some_value ), where the base class of obj 's type has defined the procedure
+
+set_attribute (v: VALUE_TYPE) is
+ -- Set value of attribute to v.
+ do
+ attribute := v
+ end
+
+
+This rule is essential to enforcing the method. Permitting direct assignments to an object's fields -- as in C++ and Java -- would violate all the tenets of information hiding by letting clients circumvent the interface carefully crafted by the author of a supplier class. It is the responsibility of each class author to define the exact privileges that the class gives to each of its clients, in particular field modification rights. Building a class is like building a machine: you design the internals, to give yourself the appropriate mechanisms; and you design the control panel, letting users (clients) access the desired subset of these mechanisms, safely and conveniently.
+
+The levels of privilege available to the class author include, for any field:
+* Hide the field completely from clients, by exporting the corresponding attribute to NONE .
+* Export it, but in read-only mode, by not exporting any procedure that modifies it.
+* Export it for free read and write by any client, by also exporting a procedure of the set_attribute kind.
+* Export it in '''restricted-write''' mode, by exporting a procedure such as deposit of class ACCOUNT , which adds a specified amount to the balance field, rather than directly setting the balance.
+
+The last case is particularly interesting is that it allows the class designer to set the precise way in which clients will manipulate the class instances, respecting the properties of the class and its integrity. The exported routines may, through the Design by Contract mechanism reviewed later ( [[8 Design by Contract (tm), Assertions and Exceptions|8]] ), place some further restrictions on the permitted modifications, for example by requiring the withdrawn amount to be positive.
+
+These rules follow directly from the more general goals (reusability, extendibility, reliability) and principles (Uniform Access, information hiding) underlying Eiffel software design. They reflect a view that each class must denote a well-understood abstraction, defined by a set of exported features chosen by the class designer -- the "control panel".
+
+The class documentation (the contract form, see page [[8 Design by Contract (tm), Assertions and Exceptions|44]] ) makes this view clear to client authors; no violation of that interface is permitted. This approach also paves the way for future '''generalization''' -- the final step of the cluster lifecycle, seen earlier on page [[3 The Software Process in Eiffel|9]] -- of the most promising components, and their inclusion into reusable libraries.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki b/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki
new file mode 100644
index 00000000..87c69249
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-general-properties.wiki
@@ -0,0 +1,49 @@
+[[Property:title|2 General Properties]]
+[[Property:link_title|ET: General Properties]]
+[[Property:weight|-14]]
+Here is an overview of the facilities supported by Eiffel:
+* Completely ''object-oriented'' approach. Eiffel is a full-fledged application of object technology, not a "hybrid" of O-O and traditional concepts.
+* ''External interfaces''. Eiffel is a software composition tool and is easily interfaced with software written in such languages as C, C++, Java and C#.
+* ''Full lifecycle support''. Eiffel is applicable throughout the development process, including analysis, design, implementation and maintenance.
+* ''Classes'' as the basic structuring tool. A class is the description of a set of run-time objects, specified through the applicable operations and abstract properties. An Eiffel system is made entirely of classes, serving as the only module mechanism.
+* ''Consistent type system''. Every type is based on a class, including basic types such as integer, boolean, real, character, string, array.
+* ''Design by Contract''. Every system component can be accompanied by a precise specification of its abstract properties, governing its internal operation and its interaction with other components.
+* ''Assertions''. The method and notation support writing the logical properties of object states, to express the terms of the contracts. These properties, known as assertions, can be monitored at run-time for testing and quality assurance. They also serve as documentation mechanism. Assertions include preconditions, postconditions, class invariants, loop invariants, and also appear in "check" instructions.
+* ''Exception handling''. You can set up your software to detect abnormal conditions, such as unexpected operating system signals and contract violations, correct them, and recover
+* ''Information hiding''. Each class author decides, for each feature, whether it is available to all client classes, to specific clients only, or just for internal purposes.
+* ''Self-documentation''. The notation is designed to enable environment tools to produce abstract views of classes and systems, textual or graphical, and suitable for reusers, maintainers and client authors.
+* ''Inheritance''. You can define a class as extension or specialization of others.
+* ''Redefinition''. An inherited feature (operation) can be given a different implementation or signature.
+* ''Explicit redefinition''. Any feature redefinition must be explicitly stated.
+* ''Subcontracting''. Redefinition rules require new assertions to be compatible with inherited ones.
+* ''Deferred features and classes''. It is possible for a feature, and the enclosing class, to be specified -- including with assertions -- but not implemented. Deferred classes are also known as abstract classes.
+* ''Polymorphism''. An entity (variable, argument etc.) can become attached to objects of many different types.
+* ''Dynamic binding''. Calling a feature on an object always triggers the version of the feature specifically adapted to that object, even in the presence of polymorphism and redefinition.
+* ''Static typing''. A compiler can check statically that all type combinations will be valid, so that no run-time situation will occur in which an attempt will be made to apply an inexistent feature to an object.
+* ''Assignment attempt'' ("type narrowing"). It is possible to check at run time whether the type of an object conforms to a certain expectation, for example if the object comes from a database or a network.
+* ''Multiple inheritance''. A class can inherit from any number of others.
+* ''Feature renaming''. To remove name clashes under multiple inheritance, or to give locally better names, a class can give a new name to an inherited feature.
+* ''Repeated inheritance'': ''sharing and replication''. If, as a result of multiple inheritance, a class inherits from another through two or more paths, the class author can specify, for each repeatedly inherited feature, that it yields either one feature (sharing) or two (replication).
+* ''No ambiguity under repeated inheritance''. Conflicting redefinitions under repeated inheritance are resolved through a "selection" mechanism.
+* ''Unconstrained genericity''. A class can be parameterized, or "generic", to describe containers of objects of an arbitrary type.
+* ''Constrained genericity''. A generic class can be declared with a generic constraint, to indicate that the corresponding types must satisfy some properties, such as the presence of a particular operation.
+* ''Garbage collection''. The dynamic model is designed so that memory reclamation, in a supporting environment, can be automatic rather than programmer-controlled.
+* ''No-leak modular structure''. All software is built out of classes, with only two inter-class relations, client and inheritance.
+* ''Once routines''. A feature can be declared s "once", so that it is executed only for its first call, subsequently returning always the same result (if required). This serves as a convenient initialization mechanism, and for shared objects.
+* ''Standardized library''. The Kernel Library, providing essential abstractions, is standardized across implementations.
+* ''Other libraries''. Eiffel development is largely based on high-quality libraries covering many common needs of software development, from general algorithms and data structures to networking and databases.
+
+
+It is also useful, as in any design, to list some of what is '''not''' present in Eiffel. The approach is indeed based on a small number of coherent concepts so as to remain easy to master. Eiffel typically takes a few hours to a few days to learn, and users seldom need to return to the reference manual once they have understood the basic concepts. Part of this simplicity results from the explicit decision to exclude a number of possible facilities:
+* ''No global variables'', which would break the modularity of systems and hamper extendibility, reusability and reliability.
+* ''No union types'' (or record type with variants), which force the explicit enumeration of all variants; in contrast, inheritance is an open mechanism which permits the addition of variants at any time without changing existing code.
+* ''No in-class overloading'', which by assigning the same name to different features within a single context, causes confusions, errors, and conflicts with object-oriented mechanisms such as dynamic binding. (Dynamic binding itself is a powerful form of inter-class overloading, without any of these dangers.)
+* ''No goto instructions'' or similar control structures (break, exit, multiple-exit loops) which break the simplicity of the control flow and make it harder or impossible to reason about the software (in particular through loop invariants and variants).
+* ''No exceptions to the type rules''. To be credible, a type system must not allow unchecked "casts" converting from a type to another. (Safe cast-like operations are available through assignment attempt.)
+* ''No side-effect expression operators'' confusing computation and modification.
+* ''No low-level pointers, no pointer arithmetic'', a well-known source of bugs. (There is however a type ''POINTER'', used for interfacing Eiffel with C and other languages.)
+
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki b/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki
new file mode 100644
index 00000000..ee7a5e6c
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-genericity-and-arrays.wiki
@@ -0,0 +1,65 @@
+[[Property:title|7 Genericity and Arrays]]
+[[Property:link_title|ET: Genericity and Arrays]]
+[[Property:weight|-9]]
+Some of the classes that we will need, particularly in libraries, are '''container''' classes, describing data structures made of a number of objects of the same or similar types. Examples of containers include arrays, stacks and lists. The class DEPOSIT_LIST posited in earlier examples describes containers.
+
+It is not hard, with the mechanisms seen so far, to write the class DEPOSIT_LIST , which would include such features as count (query returning the number of deposit objects in the list) and put (command to insert a new deposit object).
+
+Most of the operations, however, would be the same for lists of objects other than deposits. To avoid undue replication of efforts and promote reuse, we need a way to describe '''generic''' container classes, which we can use to describe containers containing elements of many different types.
+
+==Making a class generic==
+
+The notation
+class C [G] ... The rest as for any other class declaration ...
+
+introduces a generic class. A name such as G appearing in brackets after the class name is known as a '''formal generic parameter'''; it represents an arbitrary type.
+
+Within the class text, feature declarations can freely use G even though it is not known what type G stands for. Class LIST of EiffelBase, for example, includes features
+
+first: G
+ -- Value of first list item
+
+extend (val: G) is
+ -- Add a new item of value val at end of list
+...
+
+
+The operations available on an entity such as first and val , whose type is a formal generic parameter, are the operations available on all types: use as source y of an assignment x := y , use as target x of such an assignment (although not for val , which as a formal routine argument is not writable), use in equality comparisons x = y or x /= y , and application of universal features from ANY such as clone , equal and copy .
+
+To use a generic class such as list, a client will provide a type name as '''actual generic parameter'''. So instead of relying on a special purpose class DEPOSIT_LIST , the class ACCOUNT could include the declaration
+all_deposits: LIST [DEPOSIT]
+
+using LIST as a generic class and DEPOSIT as the actual generic parameter. Then all features declared in LIST as working on values of type G will work, when called on the target all_deposits , on values of type DEPOSIT . With the target
+all_accounts: LIST [ACCOUNT]
+
+these features would work on values of type ACCOUNT .
+
+{{info|A note of terminology: to avoid confusion, Eiffel always uses the word '''argument''' for routine arguments, reserving '''parameter''' for the generic parameters of classes. }}
+
+Genericity reconciles extendibility and reusability with the static type checking demanded by reliability. A typical error, such as confusing an account and a deposit, will be detected immediately at compile time, since the call all_accounts . extend ( dep ) is invalid for dep declared of type DEPOSIT . What is valid is something like all_accounts . extend ( acc ) for acc of type ACCOUNT . In other approaches, the same effect might require costly run-time checks (as in Java, C# or Smalltalk), with the risk of run-time errors.
+
+{{info|This form of genericity is known as '''unconstrained''' because the formal generic parameter, G in the example, represents an arbitrary type. You may also want to use types that are guaranteed to have certain operations available. This is known as '''constrained''' genericity and will be studied with inheritance. }}
+
+==Arrays==
+
+An example of generic class from the Kernel Library is ARRAY [ G ] , which describes direct-access arrays. Features include:
+* put to replace an element's value, as in my_array . put ( val , 25 ) which replaces by val the value of the array entry at index 25.
+* item to access an entry, as in my_array . item ( 25 ) yielding the entry at index 25. A synonym is infix "@" , so that you may also write more tersely, for the same result, my_array @ 25 .
+* lower , upper and count : queries yielding the bounds and the number of entries.
+* The creation procedure make , as in create my_array . make ( 1, 50 ) which creates an array with the given index bounds. It is also possible to resize an array through resize , retaining the old elements. In general, the Eiffel method abhors built-in limits, favoring instead structures that resize themselves when needed, either from explicit client request or automatically.
+
+The comment made about INTEGER and other basic classes applies to ARRAY too: Eiffel compilers know about this class, and will be able to process expressions of the form my_array . put ( val , 25 ) and my_array @ 25 in essentially the same way as a C or Fortran array access -- my_array [ 25 ] in C. But it is consistent and practical to let developers treat ARRAY as a class and arrays as objects; many library classes in EiffelBase, for example, inherit from ARRAY . Once again the idea is to get the best of both worlds: the convenience and uniformity of the object-oriented way of thinking; and the efficiency of traditional approaches.
+
+A similar technique applies to another Kernel Library class, that one not generic: STRING , describing character strings with a rich set of string manipulation features.
+
+==Generic derivation==
+
+The introduction of genericity brings up a small difference between classes and types. A generic class C is not directly a type since you cannot declare an entity as being of type C : you must use some actual generic parameter T -- itself a type. C [ T ] is indeed a type, but class C by itself is only a type template.
+
+The process of obtaining a type C [ T ] from a general class C is known as a '''generic derivation'''; C [ T ] is a '''generically derived type'''. Type T itself is, recursively, either a non-generic class or again a generically derived type D [ U ] for some D and U , as in LIST [ ARRAY [ INTEGER ]] .)
+
+It remains true, however, that every type is based on a class. The base class of a generically derived type C [ T ] is C .
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki
new file mode 100644
index 00000000..15e9626b
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-hello-world.wiki
@@ -0,0 +1,78 @@
+[[Property:title|4 Hello World]]
+[[Property:link_title|ET: Hello World]]
+[[Property:weight|-12]]
+When discovering any approach to software construction, however ambitious its goals, it is reassuring to see first a small example of the big picture -- a complete program to print the famous "Hello World" string. Here is how to perform this fascinating task in the Eiffel notation.
+
+You write a class HELLO with a single procedure, say make , also serving as creation procedure. If you like short texts, here is a minimal version:
+
+class
+ HELLO
+
+create
+ make
+
+feature
+
+ make is
+ do
+ print ("Hello World%N")
+ end
+
+end
+
+
+In practice, however, the Eiffel style rules suggest a better documented version:
+
+indexing
+ description: "Root for trivial system printing a message"
+ author: "Elizabeth W. Brown"
+
+class
+ HELLO
+
+create
+ make
+
+feature
+
+ make is
+ -- Print a simple message.
+ do
+ io.put_string ("Hello World")
+ io.put_new_line
+ end
+
+end -- class HELLO
+
+
+The two versions perform identically; the following comments will cover the more complete second one.
+
+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 indexing 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 description and author .
+
+The name of the class is HELLO . Any class may contain "features"; HELLO has just one, called make . The create clause indicates that make 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 definition of make appears in a feature clause. There may be any number of such clauses (to separate features into logical categories), and each may contain any number of feature declarations. Here we have only one.
+
+The line starting with -- (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the is . As will be seen in [[8 Design by Contract (tm), Assertions and Exceptions|"The contract form of a class", page 44]] , the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation.
+
+The body of the feature is introduced by the do keyword and terminated by end . It consists of two output instructions. They both use io , a generally available reference to an object that provides access to standard input and output mechanisms; the notation io . f , for some feature f of the corresponding library class ( STD_FILES ), means "apply f to io ". Here we use two such features:
+* put_string outputs a string, passed as argument, here "Hello World" .
+* put_new_line terminates the line.
+
+Rather than using a call to put_new_line , the first version of the class simply includes a new-line character, denoted as %N , at the end of the string. Either technique is acceptable.
+
+To build the system and execute it:
+* Start EiffelStudio
+* Create a new ''Basic application'' project
+* Specify HELLO as the "root class" and make as the "root procedure".
+* You can either use EiffelStudio to type in the above class text, or you may use any text editor and store the result into a file hello.e in the current directory.
+* Click the "Compile" icon.
+* Click the "Run" icon.
+
+Execution starts and outputs Hello World on the appropriate medium: under Windows, a Console; under Unix or VMS, the windows from which you started EiffelStudio.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
new file mode 100644
index 00000000..e734bbfe
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-inheritance.wiki
@@ -0,0 +1,789 @@
+[[Property:title|9 Inheritance]]
+[[Property:link_title|ET: Inheritance]]
+[[Property:weight|-7]]
+Inheritance is a powerful and attractive technique. A look at either the practice or literature shows, however, that it is not always well applied. Eiffel has made a particular effort to tame inheritance for the benefit of modelers and software developers. Many of the techniques are original with Eiffel. Paul Dubois has written (comp.lang.python Usenet newsgroup, 23 March 1997): there are two things that [Eiffel] got right that nobody else got right anywhere else: support for design by contract, and multiple inheritance. Everyone should understand these "correct answers" if only to understand how to work around the limitations in other languages.
+
+==Basic inheritance structure==
+
+To make a class inherit from another, simply use an inherit clause:
+
+indexing ...
+
+class
+ D
+
+inherit
+ A
+ B
+ ...
+
+feature
+ ...
+
+
+This makes D an heir of A , B and any other class listed. Eiffel supports '''multiple''' inheritance: a class may have as many parents as it needs. Later sections ( [[9 Inheritance|"Multiple inheritance and renaming", page 64]] and [[9 Inheritance|"Repeated inheritance and selection", page 73]] ) will explain how to handle possible conflicts between parent features.
+
+{{note|This discussion will rely on the terminology introduced on page [[5 The Static Picture: System Organization|14]] : descendants of a class are the class itself, its heirs, the heirs of its heirs and so on. Proper descendants exclude the class itself. The reverse notions are ancestors and proper ancestors. }}
+
+By default D will simply include all the original features of A , B , ..., to which it may add its own through its feature clauses if any. But the inheritance mechanism is more flexible, allowing D to adapt the inherited features in many ways. Each parent name -- A , B , ... in the example -- can be followed by a Feature Adaptation clause, with subclauses, all optional, introduced by keywords rename , export , undefine , redefine and select , enabling the author of A to make the best use of the inheritance mechanism by tuning the inherited features to the precise needs of D . This makes inheritance a principal tool in the Eiffel process, mentioned earlier, of carefully crafting each individual class, like a machine, for the benefit of its clients. The next sections review the various Feature Adaptation subclauses.
+
+==Redefinition==
+
+The first form of feature adaptation is the ability to change the implementation of an inherited feature.
+
+Assume a class SAVINGS_ACCOUNT that specializes the notion of account. It is probably appropriate to define it as an heir to class ACCOUNT , to benefit from all the features of ACCOUNT still applicable to savings accounts, and to reflect the conceptual relationship between the two types: every savings account, apart from its own specific properties, also "is" an account. But we may need to produce a different effect for procedure deposit which, besides recording the deposit and updating the balance, may also need, for example, to update the interest.
+
+This example is typical of the form of reuse promoted by inheritance and crucial to effective reusability in software: the case of reuse with adaptation. Traditional forms of reuse are all-or-nothing: either you take a component exactly as it is, or you build your own. Inheritance will get us out of this "reuse or redo" dilemma by allowing us to reuse and redo. The mechanism is feature redefinition:
+
+indexing
+ description: "Savings accounts"
+
+class
+ SAVINGS_ACCOUNT
+
+inherit
+ ACCOUNT
+ redefine
+ deposit
+ end
+
+feature -- Element change
+
+ deposit (sum: INTEGER) is
+ -- Add sum to account.
+ do
+ ... New implementation (see below) ...
+ end
+
+ ... Other features ...
+
+end -- class SAVINGS_ACCOUNT
+
+
+Without the redefine subclause, the declaration of deposit would be invalid, yielding two features of the same name, the inherited one and the new one. The subclause makes this valid by specifying that the new declaration will override the old one.
+
+In a redefinition, the original version -- such as the ACCOUNT implementation of deposit in this example -- is called the precursor of the new version. It is common for a redefinition to rely on the precursor's algorithm and add some other actions; the reserved word Precursor helps achieve this goal simply. Permitted only in a routine redefinition, it denotes the parent routine being redefined. So here he body of the new deposit (called "implementation New" above) could be of the form
+
+Precursor (sum)
+ -- Apply ACCOUNT's version of deposit
+... Instructions to update the interest ...
+
+
+Besides changing the implementation of a routine, a redefinition can turn an argument-less function into an attribute; for example a proper descendant of ACCOUNT could redefine deposits_count , originally a function, as an attribute. The Uniform Access Principle (page [[6 The Dynamic Structure: Execution Model|19]] ) guarantees that the redefinition makes no change for clients, which will continue to use the feature under the form acc.deposits_count .
+
+==Polymorphism==
+
+The inheritance mechanism is relevant to both roles of classes: module and type. Its application as a mechanism to reuse, adapt and extend features from one class to another, as just seen, covers its role as a '''module extension''' mechanism. But it's also a '''subtyping''' mechanism. To say that D is an heir of A , or more generally a descendant of A , is to expresses that instances of D can be viewed as instances of A .
+
+'''Polymorphic assignment''' supports this second role. In an assignment x := y , the types of x and y do not have, with inheritance, to be identical; the rule is that the type of y must simply '''conform''' to the type of x . A class D conforms to a class A if and only if it is a descendant of A (which includes the case in which A and D are the same class); if these classes are generic, conformance of D [ U ] to C [ T ] requires in addition that type U conform to type T (through the recursive application of the same rules).
+
+{{note|In addition, it follows from the earlier discussion of tuples ( [[10 Other Mechanisms|"Tuple types", page 90]] ), that TUPLE [X] conforms to TUPLE , TUPLE [X, Y] to TUPLE [X] and so on. }}
+
+So with the inheritance structure that we have seen, the declarations
+
+acc: ACCOUNT
+sav: SAVINGS_ACCOUNT
+
+
+make it valid to write the assignment
+
+acc := sav
+
+
+which will assign to acc a reference attached (if not void) to a direct instance of type SAVINGS_ACCOUNT , not ACCOUNT .
+
+Such an assignment, where the source and target types are different, is said to be polymorphic. An entity such as acc , which as a result of such assignments may become attached at run time to objects of types other than the one declared for it, is itself called a polymorphic entity.
+
+For polymorphism to respect the reliability requirements of Eiffel, it must be controlled by the type system and enable static type checking. We certainly do not want an entity of type ACCOUNT to become attached to an object of type DEPOSIT . Hence the second typing rule:
+
+{{note| '''Type Conformance rule '''An assignment x := y, or the use of y as actual argument corresponding to the formal argument x in a routine call, is only valid if the type of y conforms to the the type of x . }}
+
+The second case listed in the rule is a call such as target.routine(..., y, ...) where the routine declaration is of the form routine (..., x: SOME_TYPE) . The relationship between y , the actual argument in the call, and the corresponding formal argument x , is exactly the same as in an assignment x := y : not just the type rule, as expressed by Type Conformance (the type of y must conform to SOME_TYPE ), but also the actual run-time effect which, as for assignments, will be either a reference attachment or, for expanded types, a copy.
+
+The ability to accept the assignment x := Void for x of any reference type ( [[6 The Dynamic Structure: Execution Model|"Basic operations", page 28]] ) is a consequence of the Type Conformance rule, since Void is of type NONE which by construction ( [[5 The Static Picture: System Organization|"The global inheritance structure", page 15]] ) conforms to all types.
+
+Polymorphism also yields a more precise definition of "instance". A '''direct instance''' of a type A is an object created from the exact pattern defined by the declaration of A 's base class, with one field for each of the class attributes; you will obtain it through a creation instruction of the form create x ..., for x of type A , or by cloning an existing direct instance. An '''instance''' of A is a direct instance of any type conforming to A : A itself, but also any type based on descendant classes. So an instance of SAVINGS_ACCOUNT is also an instance, although not a direct instance, of ACCOUNT .
+
+A consequence of polymorphism is the ability to define '''polymorphic data structures'''. With a declaration such as
+
+accounts: LIST [ACCOUNT]
+
+
+the procedure call accounts.extend ( acc ), because it uses a procedure extend which in this case expects an argument of any type conforming to ACCOUNT , will be valid not only if acc is of type ACCOUNT but also if it is of a descendant type such as SAVINGS_ACCOUNT . Successive calls of this kind make it possible to construct a data structure that, at run-time, might contain objects of several types, all conforming to ACCOUNT :
+ [[Image:tutorial-10]] [[Image:tutorial-11]]
+Such polymorphic data structures combine the flexibility and safety of genericity and inheritance. You can make them more or less general by choosing for the actual generic parameter, here ACCOUNT , a type higher or lower in the inheritance hierarchy. Static typing is again essential here, prohibiting for example a mistaken insertion of the form accounts.extend (dep) where dep is of type DEPOSIT , which does not conform to ACCOUNT .
+
+At the higher (most abstract) end of the spectrum, you can produce an unrestrictedly polymorphic data structure general_list: LIST [ANY] which makes the call general_list.extend (x) valid for any x . The price to pay is that retrieving an element from such a structure will yield an object on which the only known applicable operations are the most general ones, valid for all types: assignment, copy, clone, equality comparison and others from ANY . Assignment attempt, studied below, will make it possible to apply more specific operations after checking dynamically that a retrieved object is of the appropriate type.
+
+==Dynamic binding==
+
+The complement of polymorphism is dynamic binding, the answer to the question "What version of a feature will be applied in a call whose target is polymorphic?".
+
+Consider acc is of type ACCOUNT . Thanks to polymorphism, an object attached to acc may be a direct instance not just of ACCOUNT but also of SAVINGS_ACCOUNT or other descendants. Some of these descendants, indeed SAVINGS_ACCOUNT among them, redefine features such as deposit . Then we have to ask what the effect will be for a call of the form
+
+acc.deposit (some_value)
+
+
+Dynamic binding is the clearly correct answer: the call will execute the version of deposit from the generating class of the object attached to acc at run time. If acc is attached to a direct instance of ACCOUNT , execution will use the original ACCOUNT version; if acc is attached to a direct instance of SAVINGS_ACCOUNT , the call will execute the version redefined in that class.
+
+This is a clear correctness requirement. A policy of static binding (as available for example in C++ or Delphi, for non-virtual functions) would take the declaration of acc as an ACCOUNT literally. But that declaration is only meant to ensure generality, to enable the use of a single entity acc in many different cases: what counts at execution time is the object that acc represents. Applying the ACCOUNT version to a SAVINGS_ACCOUNT object would be wrong, possibly leading in particular to objects that violate the invariant of their own generating class (since there is no reason a routine of ACCOUNT will preserve the specific invariant of a proper descendant such as SAVINGS_ACCOUNT , which it does not even know about).
+
+In some cases, the choice between static and dynamic binding does not matter: this is the case for example if a call's target is not polymorphic, or if the feature of the call is redefined nowhere in the system. In such cases the use of static binding permits slightly faster calls (since the feature is known at compile time). This application of static binding should, however, be treated as a '''compiler optimization'''. The EiffelStudio compiler, under its "finalization" mode, which performs extensive optimization, will detect some of these cases and process them accordingly -- unlike approaches that make developers responsible for specifying what should be static and what dynamic (a tedious and error-prone task, especially delicate because a minute change in the software can make a static call, in a far-away module of a large system, suddenly become dynamic). Eiffel programmers don't need to worry about such aspects; they can rely on the semantics of dynamic binding in all cases, with the knowledge that the compiler will apply static binding when safe and desirable.
+
+Even in cases that require dynamic binding, the design of Eiffel, in particular the typing rules, enable compilers to make the penalty over the static-binding calls of traditional approaches very small and, most importantly, '''constant-bounded''' : it does not grow with the depth or complexity of the inheritance structure. The discovery in 1985 of a technique for constant-time dynamic binding calls, even in the presence of multiple and repeated inheritance, was the event that gave the green light to the development of Eiffel.
+
+Dynamic binding is particularly interesting for polymorphic data structures. If you iterate over the list of accounts of various kinds, accounts: LIST [ACCOUNT] , illustrated in the last figure, and at each step let acc represent the current list element, you can repeatedly apply
+
+acc.deposit (...)
+
+
+to have the appropriate variant of the deposit operation triggered for each element.
+
+The benefit of such techniques appears clearly if we compare them with the traditional way to address such needs: using multi-branch discriminating instructions of the form if "Account is a savings account " then ... elseif "It is a money market account" then ... and so on, or the corresponding case ... of ..., switch or inspect instructions. Apart from their heaviness and complexity, such solutions cause many components of a software system to rely on the knowledge of the exact set of variants available for a certain notion, such as bank account. Then any addition, change or removal of variants can cause a ripple of changes throughout the architecture. This is one of the majors obstacles to extendibility and reusability in traditional approaches. In contrast, using the combination of inheritance, redefinition, polymorphism and dynamic binding makes it possible to have a '''point of single choice''' -- a unique location in the system which knows the exhaustive list of variants. Every client then manipulates entities of the most general type, ACCOUNT , through dynamically bound calls of the form acc.some_account_feature (...) .
+
+These observations make dynamic binding appear for what it is: not an implementation mechanism, but an '''architectural technique''' that plays a key role (along with information hiding, which it extends, and Design by Contract, to which it is linked through the assertion redefinition rules seen below) in providing the modular system architectures of Eiffel, the basis for the method's approach to reusability and extendibility. These properties apply as early as analysis and modeling, and continue to be useful throughout the subsequent steps.
+
+==Deferred features and classes==
+
+The examples of dynamic binding seen so far assumed that all classes were fully implemented, and dynamically bound features had a version in every relevant class, including the most general ones such as ACCOUNT .
+
+It is also useful to define classes that leave the implementation of some of their features entirely to proper descendants. Such an abstract class is known as deferred ; so are its unimplemented features. The reverse of deferred is effective, meaning fully implemented.
+
+ LIST is a typical example of deferred class. As it describes the general notion of list, it should not favor any particular implementation; that will be the task of its effective descendants, such as LINKED_LIST (linked implementation), TWO_WAY_LIST (linked both ways) ARRAYED_LIST, (implementation by an array), all effective, and all indeed to be found in EiffelBase.
+
+At the level of the deferred class LIST , some features such as extend (add an item at the end of the list) will have no implementation and hence will be declared as deferred. Here is the corresponding form, illustrating the syntax for both deferred classes and their deferred features:
+
+indexing
+ description: "[
+ Sequential finite lists, without a commitment
+ to a representation."
+
+deferred class
+ LIST [G]
+
+feature -- Access
+
+ count: INTEGER is
+ -- Number of items in list
+ do
+ ... See below; this feature can be effective ...
+ end
+
+feature -- Element change
+
+ extend (x: G) is
+ -- Add `x' at end of list.
+ require
+ space_available: not full
+ deferred
+ ensure
+ one_more: count = old count + 1
+ end
+
+ ... Other feature declarations and invariants ...
+
+end -- class LIST
+
+
+A deferred feature (considered to be a routine, although it can yield an attribute in a proper descendant) has the single keyword deferred in lieu of the do ''Instructions'' clause of an effective routine. A deferred class -- defined as a class that has at least one deferred feature -- must be introduced by class deferred instead of just class .
+
+As the example of extend shows, a deferred feature, although it has no implementation, can be equipped with assertions. They will be binding on implementations in descendants, in a way to be explained below.
+
+Deferred classes do not have to be fully deferred. They may contain some effective features along with their deferred ones. Here, for example, we may express count as a function:
+
+count: INTEGER is
+ -- Number of items in list
+ do
+ from
+ start
+ until
+ after
+ loop
+ Result := Result + 1
+ forth
+ end
+ end
+
+
+This implementation relies on the loop construct described below ( from introduces the loop initialization) and on a set of deferred features of the class which allow traversal of a list based on moving a fictitious cursor: start to bring the cursor to the first element if any, after to find out whether all relevant elements have been seen, and forth (with precondition not after ) to advance the cursor to the next element. Procedure forth itself appears as
+
+forth is
+ -- Advance cursor by one position
+ require
+ not_after: not after
+ deferred
+ ensure
+ moved_right: index = old index + 1
+ end
+
+
+where index -- another deferred feature -- is the integer position of the cursor.
+
+Although the above version of feature count is time-consuming -- it implies a whole traversal just for the purpose of determining the number of elements -- it has the advantage of being applicable to all variants, without any commitment to a choice of implementation, as would follow for example if we decided to treat count as an attribute. Proper descendants can always redefine count for more efficiency.
+
+Function count illustrates one of the most important contributions of the method to reusability: the ability to define '''behavior classes''' that capture common behaviors (such as count) while leaving the details of the behaviors (such as start , after , forth ) open to many variants. As noted earlier, traditional approaches to reusability provide closed reusable components. A component such as LIST , although equipped with directly usable behaviors such as count, is open to many variations, to be provided by proper descendants.
+
+{{note|Some O-O languages support only the two extremes: fully effective classes, and fully deferred "interfaces", but not classes with a mix of effective and deferred features. This is an unacceptable limitation, negating the object-oriented method's support for a seamless, continuous spectrum from the most abstract to the most concrete. }}
+
+A class B inheriting from a deferred class A may provide implementations -- effective declarations -- for the features inherited in deferred form. In this case there is no need for a redefine subclause; the effective versions simply replace the inherited versions. The class is said to '''effect''' the corresponding features. If after this process there remain any deferred features, B is still considered deferred, even if it introduces no deferred features of its own, and must be declared as class deferred .
+
+In the example, classes such as LINKED_LIST and ARRAYED_LIST will effect all the deferred features they inherit from LIST -- extend , start etc. -- and hence will be effective.
+
+Except in some applications restricted to pure system modeling -- as discussed next -- the main benefit of deferred classes and features comes from polymorphism and dynamic binding. Because extend has no implementation in class LIST , a call of the form my_list.extend(...) with my_list of type LIST [T] for some T can only be executed if my_list is attached to a direct instance of an effective proper descendant of LIST , such as LINKED_LIST ; then it will use the corresponding version of extend . Static binding would not even make sense here.
+
+Even an effective feature of LIST such as count may depend on deferred features (start and so on), so that a call of the form my_list.count can only be executed in the context of an effective descendant.
+
+All this indicates that a deferred class must have '''no direct instance'''. (It will have instances, the direct instances of its effective descendants.) If it had any, we could call deferred features on them, leading to execution-time impossibility. The rule that achieves this goal is simple: if the base type of x is a deferred class, no creation instruction of target x , of the form create x... , is permitted.
+
+==Applications of deferred classes==
+
+Deferred classes cover abstract notions with many possible variants. They are widely used in Eiffel where they cover various needs:
+* Capturing high-level classes, with common behaviors.
+* Defining the higher levels of a general taxonomy, especially in the inheritance structure of a library.
+* Defining the components of an architecture during system design, without commitment to a final implementation.
+* Describing domain-specific concepts in analysis and modeling.
+
+
+These applications make deferred classes a central tool of the Eiffel method's support for seamlessness and reversibility. The last one in particular uses deferred classes and features to model objects from an application domain, without any commitment to implementation, design, or even software (and computers). Deferred classes are the ideal tool here: they express the properties of the domain's abstractions, without any temptation of implementation bias, yet with the precision afforded by type declarations, inheritance structures (to record classifications of the domain concepts), and contracts to express the abstract properties of the objects being described.
+
+Rather than using a separate method and notation for analysis and design, this apprroach integrates seamlessly with the subsequent phases (assuming the decision is indeed taken to develop a software system): it suffices to refine the deferred classes progressively by introducing effective elements, either by modifying the classes themselves, or by introducing design- and implementation-oriented descendants. In the resulting system, the classes that played an important role for analysis, and are the most meaningful for customers, will remain important; as we have seen ( [[3 The Software Process in Eiffel|"Seamlessness and reversibility", page 9]] ) this direct mapping property is a great help for extendibility.
+
+The following sketch (from the book [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] ) illustrates these ideas on theexample of scheduling the programs of a TV station. This is pure modeling of an application domain; no computers or software are involved yet. The class describes the notion of program segment.
+
+Note the use of assertions to define semantic properties of the class, its instances and its features. Although often presented as high-level, most object-oriented analysis methods (with the exception of Waldn's and Nerson's Business Object Notation) have no support for the expression of such properties, limiting themselves instead to the description of broad structural relationships.
+
+indexing
+ description: "Individual fragments of a broadcasting schedule"
+
+deferred class
+ SEGMENT
+
+feature -- Access
+
+ schedule: SCHEDULE is deferred end
+ -- Schedule to which segment belongs
+
+ index: INTEGER is deferred end
+ -- Position of segment in its schedule
+
+ starting_time, ending_time: INTEGER is deferred end
+ -- Beginning and end of scheduled air time
+
+ next: SEGMENT is deferred end
+ -- Segment to be played next, if any
+
+ sponsor: COMPANY is deferred end
+ -- Segment's principal sponsor
+
+ rating: INTEGER is deferred end
+ -- Segment's rating (for children's viewing etc.)
+
+ Minimum_duration: INTEGER is 30
+ -- Minimum length of segments, in seconds
+
+ Maximum_interval: INTEGER is 2
+ -- Maximum time (seconds) between successive segments
+
+feature -- Element change
+
+ set_sponsor (s: SPONSOR) is
+ require
+ not_void: s /= Void
+ deferred
+ ensure
+ sponsor_set: sponsor = s
+ end
+
+ ... change_next, set_rating omitted ...
+
+invariant
+ in_list: (1 <= index) and (index <= schedule.segments.count)
+ in_schedule: schedule.segments.item (index) = Current
+ next_in_list: (next /= Void) implies (schedule.segments.item (index + 1) = next)
+ no_next_if_last: (next = Void) = (index = schedule.segments.count)
+ non_negative_rating: rating >= 0
+ positive times: (starting_time > 0) and (ending_time > 0)
+ sufficient_duration: ending_time - starting_time >= Minimum_duration
+ decent_interval: (next.starting_time) - ending_time <= Maximum_interval
+
+end
+
+
+==Structural property classes==
+
+Some deferred classes describe a structural property, useful to the description of many other classes. Typical examples are classes of the Kernel Library in EiffelBase:
+
+ NUMERIC describes objects on which arithmetic operations +, -, *, / are available, with the properties of a ring (associativity, distributivity, zero elements etc.). Kernel Library classes such as INTEGER and REAL -- but not, for example, STRING -- are descendants of NUMERIC . An application that defines a class MATRIX may also make it a descendant of NUMERIC .
+
+ COMPARABLE describes objects on which comparison operations <, <=, >, >= are available, with the properties of a total preorder (transitivity, irreflexivity). Kernel Library classes such as CHARACTER , STRING and INTEGER -- but not out MATRIX example -- are descendants of NUMERIC .
+
+For such classes it is again essential to permit effective features in a deferred class, and to include assertions. For example class COMPARABLE declares infix "<" as deferred, and expresses >, >= and < effectively in terms of it.
+
+{{note|The type like Current will be explained in [[9 Inheritance|"Covariance and anchored declarations", page 79]] ; you may understand it, in the following class, as equivalent to COMPARABLE . }}
+
+indexing
+ description: "Objects that can be compared according to a total preorder relation"
+
+deferred class
+ COMPARABLE
+
+feature -- Comparison
+
+ infix "<" (other: like Current): BOOLEAN is
+ -- Is current object less than `other'?
+ require
+ other_exists: other /= Void
+ deferred
+ ensure
+ asymmetric: Result implies not (other < Current)
+ end
+
+ infix "<=" (other: like Current): BOOLEAN is
+ -- Is current object less than or equal to `other'?
+ require
+ other_exists: other /= Void
+ do
+ Result := (Current < other) or is_equal (other)
+ ensure
+ definition: Result = (Current < other) or is_equal (other)
+ end
+
+ ... Other features: infix ">", min, max, ...
+
+invariant
+ irreflexive: not (Current < Current)
+
+end -- class COMPARABLE
+
+
+==Multiple inheritance and renaming==
+
+It is often necessary to define a new class in terms of several existing ones. For example:
+
+The Kernel Library classes INTEGER and REAL must inherit from both NUMERIC and COMPARABLE .
+
+A class TENNIS_PLAYER , in a system for keeping track of player ranking, will inherit from COMPARABLE , as well as from other domain-specific classes.
+
+A class COMPANY_PLANE may inherit from both PLANE and ASSET .
+
+Class ARRAYED_LIST , describing an implementation of lists through arrays, may inherit from both LIST and ARRAY .
+
+In all such cases multiple inheritance provides the answer.
+
+Multiple inheritance can cause '''name clashes''' : two parents may include a feature with the same name. This would conflict with the ban on name overloading within a class -- the rule that no two features of a class may have the same name. Eiffel provides a simple way to remove the name clash at the point of inheritance through the rename subclause, as in
+
+indexing
+ description: "Sequential finite lists implemented as arrays"
+
+class
+ ARRAYED_LIST [G]
+
+inherit
+ LIST [G]
+
+ ARRAY [G]
+ rename
+ count as capacity,
+ item as array_item
+ end
+
+feature
+
+ ...
+
+end -- class ARRAYED_LIST
+
+
+Here both LIST and ARRAY have features called count and item . To make the new class valid, we give new names to the features inherited from ARRAY , which will be known within ARRAYED_LIST as capacity and array_item . Of course we could have renamed the LIST versions instead, or renamed along both inheritance branches.
+
+Every feature of a class has a '''final name''' : for a feature introduced in the class itself ("immediate" feature) it is the name appearing in the declaration; for an inherited feature that is not renamed, it is the feature's name in the parent; for a renamed feature, it is the name resulting from the renaming. This definition yields a precise statement of the rule against in-class overloading:
+
+{{note| '''Final Name rule''': Two different features of a class may not have the same final name. }}
+
+It is interesting to compare renaming and redefinition. The principal distinction is between features and feature names. Renaming keeps a feature, but changes its name. Redefinition keeps the name, but changes the feature. In some cases, it is of course appropriate to do both.
+
+Renaming is interesting even in the absence of name clashes. A class may inherit from a parent a feature which it finds useful for its purposes, but whose name, appropriate for the context of the parent, is not consistent with the context of the heir. This is the case with ARRAY 's feature count in the last example: the feature that defines the number of items in an array -- the total number of available entries -- becomes, for an arrayed list, the maximum number of list items; the truly interesting indication of the number of items is the count of how many items have been inserted in the list, as given by feature count from LIST . But even if we did not have a name clash because of the two inherited count features we should rename ARRAY 's count as capacity to maintain the consistency of the local feature terminology.
+
+The rename subclause appears before all the other feature adaptation subclauses -- redefine already seen, and the remaining ones export , undefine and select -- since an inherited feature that has been renamed sheds its earlier identity once and for all: within the class, and to its own clients and descendants, it will be known solely through the new name. The original name has simply disappeared from the name space. This is essential to the view of classes presented earlier: self-contained, consistent abstractions prepared carefully for the greatest enjoyment of clients and descendants.
+
+==Inheritance and contracts==
+
+A proper understanding of inheritance requires looking at the mechanism in the framework of Design by Contract, where it will appear as a form of subcontracting.
+
+The first rule is that invariants accumulate down an inheritance structure:
+
+{{note| '''Invariant Accumulation rule''': The invariants of all the parents of a class apply to the class itself. }}
+
+The invariant of a class is automatically considered to include -- in the sense of logical "and" -- the invariants of all its parents. This is a consequence of the view of inheritance as an "is" relation: if we may consider every instance of B as an instance of A , then every consistency constraint on instances of A must also apply to instances of B .
+
+Next we consider routine preconditions and postconditions. The rule here will follow from an examination of what contracts mean in the presence of polymorphism and dynamic binding.
+
+Consider a parent A and a proper descendant B (a direct heir on the following figure), which redefines a routine r inherited from A .
+ [[Image:tutorial-12]]
+As a result of dynamic binding, a call a1 . r from a client C may be serviced not by A 's version of r but by B 's version if a1 , although declared of type A , becomes at run time attached to an instance of B . This shows the combination of inheritance, redefinition, polymorphism and dynamic binding as providing a form of subcontracting; A subcontracts certain calls to B .
+
+The problem is to keep subcontractors honest. Assuming preconditions and postconditions as shown on the last figure, a call in C of the form
+
+if a1.pre then a1.r end
+
+
+or just a1.q ; a1.r where the postcondition of q implies the precondition pre of r , satisfies the terms of the contract and hence is entitled to being handled correctly -- to terminate in a state satisfying a1 . post . But if we let the subcontractor B redefine the assertions to arbitrary ''pre'' ' and ''post''', this is not necessarily the case: ''pre''' could be stronger than ''pre'', enabling B not to process correctly certain calls that are correct from A 's perspective; and ''post''' could be weaker than ''post'', enabling B to do less of a job than advertized for r in the Contract Form of A , the only official reference for authors of client classes such as C . (An assertion p is stronger than or equal to an assertion q if p implies q in the sense of boolean implication.)
+
+The rule, then, is that for the redefinition to be correct the new precondition ''pre''' must be weaker than or equal to the original ''pre'', and the new postcondition ''post''' must be stronger than or equal to the original ''post'''.
+
+Because it is impossible to check simply that an assertion is weaker or stronger than another, the language rule relies on different forms of the assertion constructs, else require and then ensure , for redeclared routines. They rely on the mathematical property that, for any assertions p and q, p implies ( p or q ) , and (p and q) implies p . For a precondition, using else require with a new assertion will perform an or , which can only weaken the original; for a postcondition, then ensure will perform an and , which can only strengthen the original. Hence the rule:
+
+{{note| '''Assertion Redeclaration rule''': In the redeclared version of a routine, it is not permitted to use a require or ensure clause. Instead you may: Introduce a new condition with require else, for or-ing with the original precondition. Introduce a new condition with ensure then, for and-ing with the original postcondition. In the absence of such a clause, the original assertions are retained. }}
+
+The last case -- retaining the original -- is frequent but by no means universal.
+
+The Assertion Redeclaration rule applies to '''redeclarations'''. This terms covers not just redefinition but also effecting (the implementation, by a class, of a feature that it inherits deferred). The rules -- not just for assertions but also, as reviewed below, for typing -- are indeed the same in both cases. Without the Assertion Redeclaration rule, assertions on deferred features, such as those on extend , count and forth in [[9 Inheritance|"Deferred features and classes", page 57]] , would be almost useless -- wishful thinking; the rule makes them binding on all effectings in descendants.
+
+From the Assertion Redeclaration rule follows an interesting technique: '''abstract preconditions'''. What needs to be weakened for a precondition (or strengthened for a postcondition) is not the assertion's concrete semantics but its abstract specification as seen by the client. A descendant can change the implementation of that specification as it pleases, even to the effect of strengthening the concrete precondition, as long as the abstract form is kept or weakened. The precondition of procedure extend in the deferred class LIST provided an example. We wrote the routine (page [[9 Inheritance|58]] ) as
+
+extend (x: G) is
+ -- Add `x' at end of list.
+ require
+ space_available: not full
+ deferred
+ ensure
+ one_more: count = old count + 1
+ end
+
+
+The precondition expresses that it is only possible to add an item to a list if the representation is not full. We may well consider -- in line with the Eiffel principle that whenever possible structures should be of unbounded capacity -- that LIST should by default make full always return false:
+
+full: BOOLEAN is
+ -- Is representation full?
+ -- (Default: no)
+ do
+ Result := False
+ end
+
+
+Now a class BOUNDED_LIST that implements bounded-size lists (inheriting, like the earlier ARRAYED_LIST , from both LIST and ARRAY ) may redefine full :
+
+full: BOOLEAN is
+ -- Is representation full?
+ -- (Answer: if and only if number of items is capacity)
+ do
+ Result := (count = capacity)
+ end
+
+
+Procedure extend remains applicable as before; any client that used it properly with LIST can rely polymorphically on the FIXED_LIST implementation. The abstract precondition of extend has not changed, even though the concrete implementation of that precondition has in fact been strengthened.
+
+Note that a class such as BOUNDED_LIST , the likes of which indeed appear in EiffelBase, is not a violation of the Eiffel advice to stay away from fixed-size structures. The corresponding structures are bounded, but the bounds are changeable. Although extend requires not full , another feature, called force in all applicable classes, will add an element at the appropriate position by resizing and reallocating the structure if necessary. Even arrays in Eiffel are not fixed-size, and have a procedure force with no precondition, accepting any index position.
+
+The Assertion Redeclaration rule, together with the Invariant Accumulation rule, provides the right methodological perspective for understanding inheritance and the associated mechanisms. Defining a class as inheriting from another is a strong commitment; it means inheriting not only the features but the logical constraints. Redeclaring a routine is bound by a similar committment: to provide a new implementation (or, for an effecting, a first implementation) of a previously defined semantics, as expressed by the original contract. Usually you have a wide margin for choosing your implementation, since the contract only defines a range of possible behaviors (rather than just one behavior), but you '''must''' remain within that range. Otherwise you would be perverting the goals of redeclaration, using this mechanism as a sort of late-stage hacking to override bugs in ancestor classes.
+
+==Join and uneffecting==
+
+It is not an error to inherit two deferred features from different parents under the same name, provided they have the same signature (number and types of arguments and result). In that case a process of '''feature join''' takes place: the features are merged into just one -- with their preconditions and postconditions, if any, respectively or-ed and and-ed.
+
+More generally, it is permitted to have any number of deferred features and at most one effective feature that share the same name: the effective version, if present will effect all the others.
+
+All this is not a violation of the Final Name rule (page [[9 Inheritance|65]] ), since the name clashes prohibited by the rule involve two different features having the same final name; here the result is just one feature, resulting from the join of all the inherited versions.
+
+Sometimes we may want to join ''effective'' features inherited from different parents, assuming again the features have compatible signatures. One way is to redefine them all into a new version; then they again become one feature, with no name clash in the sense of the Final Name rule. But in other cases we may simply want one of the inherited implementations to take over the others. The solution is to revert to the preceding case by '''uneffecting''' the other features; uneffecting an inherited effective feature makes it deferred (this is the reverse of effecting, which turns an inherited deferred feature into an effective one). The syntax uses the undefine subclause:
+
+class D
+
+inherit
+ A
+ rename
+ g as f
+ -- g was effective in A
+ undefine
+ f
+ end
+
+ B
+ undefine
+ f
+ -- f was effective in B
+ end
+
+ C
+ -- C also has an effective feature f , which will serve as
+ -- implementation for the result of the join.
+
+feature
+ ...
+
+
+
+Again what counts, to determine if there is an invalid name clash, is the final name of the features. In this example to of the joined features were originally called f ; the one from A was called g , but in D it is renamed as f , so without the undefinition it would cause an invalid name clash.
+
+Feature joining is the most common application of uneffecting. In some non-joining cases, however, it may be useful to forget the original implementation of a feature and let it start a new life devoid of any burden from the past.
+
+==Changing the export status==
+
+Another Feature Adaptation subclause, export , makes it possible to change the export status of an inherited feature. By default -- covering the behavior desired in the vast majority of practical cases -- an inherited feature keeps its original export status (exported, secret, selectively exported). In some cases, however, this is not appropriate:
+
+A feature may have played a purely implementation-oriented role in the parent, but become interesting to clients of the heir. Its status will change from secret to exported.
+
+In implementation inheritance (for example ARRAYED_LIST inheriting from ARRAY ) an exported feature of the parent may not be suitable for direct use by clients of the heir. The change of status in this case is from exported to secret.
+
+You can achieve either of these goals by writing
+
+class D inherit
+ A
+ export {X, Y, ...} feature1, feature2, ... end
+
+ ...
+
+
+This gives a new export status to the features listed (under their final names since, as noted, export like all other subclauses comes after rename if present): they become exported to the classes listed. In most cases this list of classes, X , Y , ..., consists of just ANY , to re-export a previously secret feature, or NONE , to hide a previously exported feature. It is also possible, in lieu of the feature list, to use the keyword all to apply the new status to all features inherited from the listed parent. Then there can be more than one class-feature list, as in
+
+class ARRAYED_LIST [G] inherit
+
+ ARRAY [G]
+ rename
+ count as capacity, item as array_item, put as array_put
+ export
+ {NONE} all
+ {ANY} capacity
+ end
+
+ ...
+
+
+where any explicit listing of a feature, such as capacity , takes precedence over the export status specified for all . Here most features of ARRAY are secret in ARRAYED_LIST , because the clients should not permitted to manipulate array entries directly: they will manipulate them indirectly through list features such as extend and item , whose implementation relies on array_item and array_put . But ARRAY 's feature count remains useful, under the name capacity , to the clients of ARRAYED_LIST .
+
+==Flat and Flat-Contract Forms==
+
+Thanks to inheritance, a concise class text may achieve a lot, relying on all the features inherited from direct and indirect ancestors.
+
+This is part of the power of the object-oriented form of reuse, but can create a comprehension and documentation problem when the inheritance structures become deep: how does one understand such a class, either as client author or as maintainer? For clients, the Contract Form, entirely deduced from the class text, does not tell the full story about available features; and maintainers must look to proper ancestors for much of the relevant information.
+
+These observations suggest ways to produce, from a class text, a version that is equivalent feature-wise and assertion-wise, but has no inheritance dependency. This is called the '''Flat Form''' of the class. It is a class text that has no inheritance clause and includes all the features of the class, immediate (declared in the class itself) as well as inherited. For the inherited features, the flat form must of course take account of all the feature adaptation mechanisms: renaming (each feature must appear under its final name), redefinition, effecting, uneffecting and export status change. For redeclared features, else require clauses are or-ed with the precursors' preconditions, and then ensure clauses are and-ed with precursors' postconditions. For invariants, all the ancestors' clauses are concatenated. As a result, the flat form yields a view of the class, its features and its assertions that conforms exactly to the view offered to clients and (except for polymorphic uses) heirs.
+
+As with the Contract Form ( [[8 Design by Contract (tm), Assertions and Exceptions|"The contract form of a class", page 44]] ), producing the Flat Form is the responsibility of tools in the development environment. In EiffelStudio, you will just click the "Flat" icon.
+
+The Contract Form of the Flat Form of a class is known as its '''Flat-Contract Form'''. It gives the complete interface specification, documenting all exported features and assertions -- immediate or inherited -- and hiding implementation aspects. It is the appropriate documentation for a class.
+
+==Repeated inheritance and selection==
+
+An inheritance mechanism, following from multiple inheritance, remains to be seen. Through multiple inheritance, a class can be a proper descendant of another through more than one path. This is called repeated inheritance and can be indirect, as in the following figure, or even direct, when a class D lists a class A twice in its inherit clause.
+ [[Image:tutorial-13]]
+The figure's particular example is in fact often used by introductory presentations of multiple inheritance, which is a pedagogical mistake: simple multiple inheritance examples (such as INTEGER inheriting from NUMERIC and COMPARABLE , or COMPANY_PLANE from ASSET and PLANE ) should involve the combination of '''separate abstractions'''. Repeated inheritance is an advanced technique; although invaluable, it does not arise in elementary uses and requires a little more care.
+
+In fact there is only one non-trivial issue in repeated inheritance: what does a feature of the repeated ancestor, such as change_address and computer_account , mean for the repeated descendant, here TEACHING_ASSISTANT ? (The example features chosen involve a routine and an attribute; the basic rules will be the same.)
+
+There are two possibilities: sharing (the repeatedly inherited feature yields just one feature in the repeated descendant) and duplication (it yields two). Examination of various cases shows quickly that a fixed policy, or one that would apply to all the features of a class, would be inappropriate.
+
+Feature change_address calls for sharing: as a teaching assistant, you may be both teacher and student, but you are just one person, with just one official domicile.
+
+If there are separate accounts for students' course work and for faculty, you may need one of each kind, suggesting that computer_account calls for duplication.
+
+The Eiffel rule enables, once again, the software developer to craft the resulting class so as to tune it to the exact requirements. Not surprisingly, it is based on names, in accordance with the Final Name rule (no in-class overloading):
+
+{{note| '''Repeated Inheritance rule'''
+* A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant.
+* A feature inherited multiply under different names will be replicated, yielding as many variants as names.
+}}
+
+So to tune the repeated descendant, feature by feature, for sharing and replication it suffices to use renaming.
+
+Doing nothing will cause sharing, which is indeedthe desired policy in most cases (especially those cases of unintended repeated inheritance: making D inherit from A even though it also inherits from B , which you forgot is already a descendant of A ).
+
+If you use renaming somewhere along the way, so that the final names are different, you will obtain two separate features. It does not matter where the renaming occurs; all that counts is whether in the common descendant, TEACHING_ASSISTANT in the last figure, the names are the same or different. So you can use renaming at that last stage to cause replication; but if the features have been renamed higher you can also use last-minute renaming to avoid replication, by bringing them back to a single name.
+
+The Repeated Inheritance rule gives the desired flexibility to disambiguate the meaning of repeatedly inherited features. There remains a problem in case of redeclaration and polymorphism. Assume that somewhere along the inheritance paths one or both of two replicated versions of a feature f , such as computer_account in the example, has been redeclared; we need to define the effect of a call a.f ( a.computer_account in the example) if a is of the repeated ancestor type, here UNIVERSITY_PERSON , and has become attached as a result of polymorphism to an instance of the repeated descendant, here TEACHING_ASSISTANT . If one or more of the intermediate ancestors has redefined its version of the feature, the dynamically-bound call has two or moreversions to choose from.
+
+A select clause will resolve the ambiguity, as in
+
+class TEACHING_ASSISTANT
+
+inherit
+ TEACHER
+ rename
+ computer_account as faculty_account
+ select
+ faculty_account
+ end
+
+ STUDENT
+ rename
+ computer_account as student_account
+ end
+
+ ...
+
+
+We assume here that that no other renaming has occurred -- TEACHING_ASSISTANT takes care of the renaming to ensure replication -- but that one of the two parents has redefined computer_account , for example TEACHER to express the special privileges of faculty accounts. In such a case the rule is that one (and exactly one) of the two parent clauses in TEACHING_ASSISTANT '''must''' select the corresponding version. Note that no problem arises for an entity declared as
+
+ta: TEACHING_ASSISTANT
+
+
+since the valid calls are of the form ta.faculty_account and ta.student_account , neither of them ambiguous; the call ta.computer_account would be invalid, since after the renamings class TEACHING_ASSISTANT has no feature of that name. The select only applies to a call
+
+up.computer_account
+
+
+with up of type UNIVERSITY_PERSON , dynamically attached to an instance of TEACHING_ASSISTANT ; then the select resolves the ambiguity by causing the call to use the version from TEACHER .
+
+So if you traverse a list computer_users: LIST [UNIVERSITY_PERSON] to print some information about the computer account of each list element, the account used for a teaching assistant is the faculty account, not the student account.
+
+You may, if desired, redefine faculty_account in class TEACHING_ASSISTANT , using student_account if necessary, to take into consideration the existence of another account. But in all cases we need a precise disambiguation of what computer_account means for a TEACHING_ASSISTANT object known only through a UNIVERSITY_PERSON entity.
+
+The select is only needed in case of replication. If the Repeated Inheritance rule would imply sharing, as with change_address, and one or both of the shared versions has been redeclared, the Final Name rule makes the class invalid, since it now has '''two different features''' with the same name. (This is only a problem if both versions are effective; if one or both are deferred there is no conflict but a mere case of feature joining as explained in [[9 Inheritance|"Join and uneffecting", page 70]] .) The two possible solutions follow from the previous discussions:
+
+If you do want sharing, one of the two versions must take precedence over the other. It suffices to '''undefine''' the other, and everything gets back to order. Alternatively, you can redefine both into a new version, which takes precedence over both.
+
+If you want to keep both versions, switch from sharing to replication: rename one or both of the features so that they will have different names; then you must select one of them.
+
+==Constrained genericity==
+
+Eiffel's inheritance mechanism has an important application to extending the flexibility of the '''genericity''' mechanism. In a class SOME_CONTAINER [G] , as noted (section [[7 Genericity and Arrays|7]] ), the only operations available on entities of type G , the formal generic parameter, are those applicable to entities of all types. A generic class may, however, need to assume more about the generic parameter, as with a class SORTABLE_ARRAY [G ...] which will have a procedure sort that needs, at some stage, to perform tests of the form
+
+if item (i) < item (j) then ...
+
+
+where item (i) and item (j) are of type G . But this requires the availability of a feature infix "<" in all types that may serve as actual generic parameters corresponding to G . Using the type SORTABLE_ARRAY [INTEGER] should be permitted, because INTEGER has such a feature; but not SORTABLE_ARRAY [COMPLEX] if there is no total order relation on COMPLEX .
+
+To cover such cases, declare the class as
+
+class SORTABLE_ARRAY [G -> COMPARABLE]
+
+
+making it '''constrained generic'''. The symbol -> recalls the arrow of inheritance diagrams; what follows it is a type, known as the generic constraint. Such a declaration means that:
+
+Within the class, you may apply the features of the generic constraint -- here the features of COMPARABLE : infix "<" , infix "<" etc. -- to expressions of type G .
+
+A generic derivation is only valid if the chosen actual generic parameter conforms to the constraint. Here you can use SORTABLE_ARRAY [INTEGER] since INTEGER inherits from COMPARABLE , but not SORTABLE_ARRAY [COMPLEX] if COMPLEX is not a descendant of COMPARABLE .
+
+A class can have a mix of constrained and unconstrained generic parameters, as in the EiffelBase class HASH_TABLE [G, H -> HASHABLE] whose first parameter represents the types of objects stored in a hash table, the second representing the types of the keys used to store them, which must be HASHABLE . As these examples suggest, structural property classes such as COMPARABLE , NUMERIC and HASHABLE are the most common choice for generic constraints.
+
+Unconstrained genericity, as in C [G] , is defined as equivalent to C [G -> ANY] .
+
+==Assignment attempt==
+
+The Type Conformance rule ( [[9 Inheritance|"Polymorphism", page 53]] ) ensures type safety by requiring all assignments to be from a more specific source to a more general target.
+
+Sometimes you can't be sure of the source object's type. This happens for example when the object comes from the outside -- a file, a database, a network. The persistence storage mechanism( [[6 The Dynamic Structure: Execution Model|"Deep operations and persistence", page 30]] ) includes, along with the procedure store seen there, the reverse operation, a function retrieved which yields an object structure retrieved from a file or network, to which it was sent using store . But retrieved as declared in the corresponding class STORABLE of EiffelBase can only return the most general type, ANY ; it is not possible to know its exact type until execution time, since the corresponding objects are not under the control of the retrieving system, and might even have been corrupted by some external agent.
+
+In such cases you cannot trust the declared type but must check it against the type of an actual run-time object. Eiffel introduces for this purpose the '''assignment attempt''' operation, written
+
+x ?= y
+
+
+with the following effect (only applicable if x is a writable entity of reference type):
+
+If y is attached, at the time of the instruction's execution to an object whose type conforms to the type of x , perform a normal reference assignment.
+
+Otherwise (if y is void, or attached to a non-conforming object), make x void.
+
+Using this mechanism, a typical object structure retrieval will be of the form
+
+x ?= retrieved
+
+if x = Void then
+ "We did not get what we expected"
+else
+ "Proceed with normal computation, which will typically involve calls of the form x.some_feature "
+end
+
+
+As another application, assume we have a LIST [ACCOUNT] and class SAVINGS_ACCOUNT , a descendant of ACCOUNT , has a feature interest_rate which was not in ACCOUNT . We want to find the maximum interest rate for savings accounts in the list. Assignment attempt easily solves the problem:
+
+local
+ s: SAVINGS_ACCOUNT
+do
+ from account_list.start until account_list.after loop
+ s ?= acc_list.item
+ -- item from LIST yields the element at
+ -- cursor position
+ if s /= Void and then s.interest_rate > Result then
+ -- Using and then (rather than and) guarantees
+ -- that s.interest_rate is not evaluated
+ -- if s = Void is true.
+ Result := s.interest_rate
+ end
+ account_list.forth
+ end
+end
+
+
+Note that if there is no savings account at all in the list the assignment attempt will always yield void, so that the result of the function will be 0, the default initialization.
+
+Assignment attempt is useful in the cases cited -- access to external objects beyond the software's own control, and access to specific properties in a polymorphic data structure. The form of the instruction precisely serves these purposes; not being a general type comparison, but only a verification of a specific expected type, it does not carry the risk of encouraging developers to revert to multi-branch instruction structures, for which Eiffel provides the far preferable alternative of polymorphic, dynamically-bound feature calls.
+
+==Covariance and anchored declarations==
+
+The final property of Eiffel inheritance involves the rules for adapting not only the implementation of inherited features (through redeclaration of either kind, redeclaration and redefinition, as seen so far) and their contracts (through the Assertion Redeclaration rule), but also their types. More general than type is the notion of a feature's '''signature''', defined by the number of its arguments, their types, the indication of whether it has a result (that is to say, is a function or attribute rather than a procedure) and, if so, the type of the result.
+
+In many cases the signature of a redeclared feature remains the same as the original's. But in some cases you may want to adapt it to the new class. Assume for example that class ACCOUNT has features
+
+owner: HOLDER
+
+set_owner (h: HOLDER) is
+ -- Make `h' the account owner.
+ require
+ not_void: h /= Void
+ do
+ owner := h
+ end
+
+
+We introduce an heir BUSINESS_ACCOUNT of ACCOUNT to represent special business accounts, corresponding to class BUSINESS inheriting from HOLDER :
+ [[Image:tutorial-14]]
+Clearly, we must redefine owner in class BUSINESS_ACCOUNT to yield a result of type BUSINESS ; the same signature redefinition must be applied to the argument of set_owner . This case is typical of the general scheme of signature redefinition: in a descendant, you may need to redefine both results and arguments to types conforming to the originals. This is reflected by a language rule:
+
+{{note| '''Covariance rule''': In a feature redeclaration, both the result type if the feature is a query (attribute or function) and the type of any argument if it is a routine (procedure or function) must conform to the original type as declared in the precursor version. }}
+
+The term "covariance" reflects the property that all types -- those of arguments and those of results -- vary together in the same direction as the inheritance structure.
+
+If a feature such as set_owner has to be redefined for more than its signature -- to update its implementation or assertions -- the signature redefinition will be explicit. For example set_owner could do more for business owners than it does for ordinary owners. Then the redefinition will be of the form
+
+set_owner (b: BUSINESS) is
+ -- Make b the account owner.
+ do
+ ... New routine body ...
+ end
+
+
+In other cases, however, the body will be exactly the same as in the precursor. Then explicit redefinition would be tedious, implying much text duplication. The mechanism of '''anchored redeclaration''' solves this problem. The original declaration of set_owner in ACCOUNT should be of the form
+
+set_owner (h: like owner) is
+ -- Make h the account owner.
+ -- The rest as before:
+ require
+ not_void: h /= Void
+ do
+ owner := h
+ end
+
+
+A like ''anchor'' type, known as an anchored type, may appear in any context in which ''anchor'' has a well-defined type; ''anchor'' can be an attribute or function of the enclosing class, or an argument of the enclosing routine. Then, assuming T is the type of ''anchor'', the type like ''anchor'' means the following:
+
+In the class in which it appears, like ''anchor'' means the same as T . For example, in set_owner above, the declaration of h has the same effect as if h had been declared of type HOLDER , the type of the anchor owner in class ACCOUNT .
+
+The difference comes in proper descendants: if a type redefinition changes the type of ''anchor'', any entity declared like ''anchor'' will be considered to have been redefined too.
+
+This means that anchored declaration are a form of of implicit covariant redeclaration.
+
+In the example, class BUSINESS_ACCOUNT only needs to redefine the type of owner (to BUSINESS ). It doesn't have to redefine set_owner except if it needs to change its implementation or assertions.
+
+It is possible to use Current as anchor; the declaration like Current denotes a type based on the current class (with the same generic parameters if any). This is in fact a common case; we saw in [[9 Inheritance|"Structural property classes", page 62]] , that it applies in class COMPARABLE to features such as
+
+infix "<" (other: like Current): BOOLEAN is ...
+
+
+since we only want to compare two comparable elements of compatible types -- but not, for example, integer and strings, even if both types conform to COMPARABLE . (A "balancing rule" makes it possible, however, to mix the various arithmetic types, consistently with mathematical traditions, in arithmetic expressions such as 3 + 45.82 or boolean expressions such as 3 < 45. 82 .)
+
+Similarly, class ANY declares procedure copy as
+
+copy (other: like Current) is ...
+
+
+with the argument anchored to the current object. Function clone , for its part, has signature clone (other: ANY): like other , with both argument and result anchored to the argument, so that for any x the type of clone (x) is the same as the type of x .
+
+A final, more application-oriented example of anchoring to Current is the feature merge posited in an earlier example (page [[6 The Dynamic Structure: Execution Model|13]] ) with the signature merge (other: ACCOUNT) . By using instead merge (other: like Current) we can ensure that in any descendant class -- BUSINESS_ACCOUNT , SAVINGS_ACCOUNT , MINOR_ACCOUNT ... -- an account will only be mergeable with another of a compatible type.
+
+Covariance makes static type checking more delicate; mechanisms of "system validity" and "catcalls" address the problem, discussed in detail in the book [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] (see the bibliography).
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki b/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki
new file mode 100644
index 00000000..2db84030
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-learn-more.wiki
@@ -0,0 +1,13 @@
+[[Property:title|13 To Learn More]]
+[[Property:link_title|ET: To Learn More]]
+[[Property:weight|-1]]
+Beyond this introduction, you will find the following two books essential to a mastery of the method and language:
+* [http://eiffel.com/doc/oosc/ Object-Oriented Software Construction] , Bertrand Meyer, Prentice Hall, 2nd edition 1997. (Make sure to get the second edition.) About object technology in general; presents the method behind Eiffel.
+* [http://eiffel.com/doc/ Eiffel: The Language] , Bertrand Meyer, Prentice Hall, 1992. Language manual and reference.
+
+
+Numerous other books are available on Eiffel and Eiffel-related topics. See an extensive list at [http://www.eiffel.com/doc/ http://www.eiffel.com/doc/documentation.html] , from which you can order most of the titles listed. They include university textbooks, general introductions, presentations of Eiffel projects, descriptions of libraries and other applications, books on BON and object-oriented methodology.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki b/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki
new file mode 100644
index 00000000..d390ede7
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki
@@ -0,0 +1,104 @@
+[[Property:title|12 Lexical Conventions and Style Rules]]
+[[Property:link_title|ET: Lexical Conventions and Style Rules]]
+[[Property:weight|-2]]
+Eiffel software texts are free-format: distribution into lines is not semantically significant, and any number of successive space and line-return characters is equivalent to just one space. The style rules suggest indenting software texts as illustrated by the examples in this chapter.
+
+Successive declarations or instructions may be separated by semicolons. Eiffel's syntax has been so designed, however, that (except in rare cases) '''the semicolon is optional'''. Omitting semicolons for elements appearing on separate lines lightens text and is the recommended practice since semicolons, as used by most programming languages, just obscure the text by distracting attention from the actual contents. Do use semicolons if you occasionally include successive elements on a single line.
+
+63 names -- all unabbreviated single English words, except for elseif which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list:
+{|
+|-
+| agent
+| alias
+| all
+| and
+| as
+| assign
+| check
+|-
+| class
+| convert
+| create
+| Current
+| debug
+| deferred
+| do
+|-
+| else
+| elseif
+| end
+| ensure
+| expanded
+| export
+| external
+|-
+| False
+| feature
+| from
+| frozen
+| if
+| implies
+| indexing
+|-
+| infix
+| inherit
+| inspect
+| invariant
+| is
+| like
+| local
+|-
+| loop
+| not
+| obsolete
+| old
+| once
+| or
+| prefix
+|-
+| Precursor
+| pure
+| redefine
+| reference
+| rename
+| require
+| rescue
+|-
+| Result
+| retry
+| separate
+| then
+| True
+| TUPLE
+| undefine
+|}
+
+Since this tutorial has covered all the essential mechanisms, you may ignore the keywords not encountered; they are reserved for future use.
+
+Most of the reserved words are keywords, serving only as syntactic markers, and written in boldface in typeset texts such as the present one: class , feature , inherit . The others, such as Current , directly carry a semantic denotation; they start with an upper-case letter and are typeset in boldface.
+
+These conventions about letter case are only style rules. Eiffel is case-insensitive, since it is foolish to assume that two identifiers denote two different things just on the basis of a letter written in lower or upper case. The obvious exception is manifest character constants (appearing in single quotes, such as 'A' ) and manifest character strings (appearing in double quotes, such as "UPPER and lower" ).
+
+The style rules, however, are precise, and any serious Eiffel project will enforce them; the tools of EiffelStudio also observe them in the texts they output (although they will not mess up with your source text unless you ask them to reformat it). Here are the conventions, illustrated by the examples of this tutorial:
+* Class names in upper case, as ACCOUNT .
+* Non-constant feature names and keywords in lower case, as balance and class .
+* Constant features and predefined entities and expressions with an initial upper case, as Avogadro and Result .
+
+In typeset documents including Eiffel texts, the standard for font styles is also precise. You should use bold face for keywords and italics for all other Eiffel elements. Comments, however, are typeset in roman . This lets a software element, such as an identifier, stand out clearly in what is otherwise a comment text expressed in English or another human language, as in the earlier example
+
+-- Add `sum' to account.
+
+
+which makes clear that sum is a software element, not the English word.
+
+There is also an Eiffel style to the choice of identifiers. For features, stay away from abbreviations and use full words. In multi-word identifiers, separate the constituents by underscores, as in LINKED_LIST and set_owner . The competing style of no separation but mid-identifier upper-case, as in linkedList or setOwner , is less readable and not in line with standard Eiffel practices.
+
+Features of reusable classes should use consistent names. A set of standard names -- put for the basic command to add or replace an element, count for the query that returns the number of element in a structure, item to access an element -- is part of the style rules, and used systematically in EiffelBase. Use them in your classes too.
+
+For local entities and formal arguments of routines, it is all right to use abbreviated names, since these identifiers only have a local scope, and choosing a loud name would give them too much pretense, leading to potential conflicts with features.
+
+The complete set of style rules applied by ISE is available on the web in both [http://www.eiffel.com/doc/manuals/language/style/ HTML] and [http://www.eiffel.com/doc/manuals/language/style/style.pdf PDF] forms. These rules are an integral part of the Eiffel method; in quality software, there is no such thing as a detail. Applying them systematically promotes consistency between projects in the Eiffel world, enhances reusability, and facilitates everyone's work.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki
new file mode 100644
index 00000000..83649f51
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-other-mechanisms.wiki
@@ -0,0 +1,262 @@
+[[Property:title|10 Other Mechanisms]]
+[[Property:link_title|ET: Other Mechanisms]]
+[[Property:weight|-4]]
+We now examine a few important mechanisms that complement the preceding picture: shared objects; constants; instructions; and lexical conventions.
+
+==Once routines and shared objects==
+
+The Eiffel's method obsession with extendibility, reusability and maintainability yields, as has been seen, modular and decentralized architectures, where inter-module coupling is limited to the strictly necessary, interfaces are clearly delimited, and all the temptations to introduce obscure dependencies, in particular global variables, have been removed. There is a need, however, to let various components of a system access common objects, without requiring their routines to pass these objects around as arguments (which would only be slightly better than global variables). For example various classes may need to perform output to a common "console window", represented by a shared object.
+
+Eiffel addresses this need through an original mechanism that also takes care of another important issue, poorly addressed by many design and programming approaches: initialization. The idea is simple: if instead of do the implementation of an effective routine starts with the keyword once , it will only be executed the first time the routine is called during a system execution (or, in a multi-threaded environment, the first time in each thread), regardless of what the caller was. Subsequent calls from the same caller or others will have no effect; if the routine is a function, it will always return the result computed by the first call -- object if an expanded type, reference otherwise.
+
+In the case of procedures, this provides a convenient initialization mechanism. A delicate problem in the absence of a once mechanism is how to provide the users of a library with a set of routines which they can call in any order, but which all need, to function properly, the guarantee that some context had been properly set up. Asking the library clients to precede the first call with a call to an initialization procedure setup is not only user-unfriendly but silly: in a well-engineered system we will want to check proper set-up in every of the routines, and report an error if necessary; but then if we were able to detect improper set-up we might as well shut up and set up ourselves (by calling setup ). This is not easy, however, since the object on which we call setup must itself be properly initialized, so we are only pushing the problem further. Making setup a once procedure solves it: we can simply include a call
+
+setup
+
+
+at the beginning of each affected routine; the first one to come in will perform the needed initializations; subsequent calls will have, as desired, no effect.
+
+Once functions will give us shared objects. A common scheme is
+
+console: WINDOW is
+ -- Shared console window
+ once
+ create Result.make (...)
+ end
+
+
+Whatever client first calls this function will create the appropriate window and return a reference to it. Subsequent calls, from anywhere in the system, will return that same reference. The simplest way to make this function available to a set of classes is to include it in a class SHARED_STRUCTURES which the classes needing a set of related shared objects will simply inherit.
+
+For the classes using it, console , although a function, looks very much as if it were an attribute -- only one referring to a shared object.
+
+The "Hello World" system at the beginning of this discussion (section [[4 Hello World|4]] ) used an output instruction of the form io . put_string ( Some string ) . This is another example of the general scheme illustrated by console . Feature io , declared in ANY and hence usable by all classes, is a once function that returns an object of type STANDARD_FILES (another Kernel Library class) providing access to basic input and output features, one of which is procedure put_string . Because basic input and output must all work on the same files, io should clearly be a once function, shared by all classes that need these mechanisms.
+
+==Constant and unique attributes==
+
+The attributes studied earlier were variable: each represents a field present in each instance of the class and changeable by its routines.
+
+It is also possible to declare constant attributes, as in
+
+Solar_system_planet_count: INTEGER is 9
+
+
+These will have the same value for every instance and hence do not need to occupy any space in objects at execution time. (In other approaches similar needs would be addressed by symbolic constants, as in Pascal or Ada, or macros, as in C.)
+
+What comes after the is is a manifest constant: a self-denoting value of the appropriate type. Manifest constants are available for integers, reals (also used for doubles), booleans ( True and False ), characters (in single quotes, as 'A' , with special characters expressed using a percent sign as in '%N' for new line, '%B' for backspace and '%U' for null).
+
+For integer constants, it is also possible to avoid specifying the values. A declaration of the form
+
+a, b, c, ... n : INTEGER is unique
+
+
+introduces a , b , c , ... n as constant integer attributes, whose value are assigned by the Eiffel compiler rather than explicitly by the programmer. The values are different for all unique attributes in a system; they are all positive, and, in a single declaration such as the above, guaranteed to be consecutive (so that you may use an invariant property of the form code > a and code < n to express that code should be one of the values). This mechanism replaces the "enumerated types" found in many languages, without suffering from the same problems. (Enumerated types have an ill-defined place in the type system; and it is not clear what operations are permitted.)
+
+You may use Unique values in conjunction with the inspect multi-branch instruction studied in the next section. They are only appropriate for codes that can take on a fixed number of well-defined values -- not as a way to program operations with many variants, a need better addressed by the object-oriented technique studied earlier and relying on inheritance, polymorphism, redeclaration and dynamic binding.
+
+Manifest constants are also available for strings, using double quotes as in
+
+User_friendly_error_message: STRING is "Go get a life !"
+
+
+with special characters again using the % codes. It is also possible to declare manifest arrays using double angle brackets:
+
+<<1, 2, 3, 5, 7, 11, 13, 17, 19>>
+
+
+which is an expression of type ARRAY [INTEGER] . Manifest arrays and strings are not atomic, but denote instances of the Kernel Library classes STRING and ARRAY , as can be produced by once functions.
+
+==Instructions==
+
+Eiffel has a remarkably small set of instructions. The basic computational instructions have been seen: creation, assignment, assignment attempt, procedure call, retry. They are complemented by control structures: conditional, multi-branch, loop, as well as debug and check.
+
+A conditional instruction has the form if ... then ... elseif ... then ... else ... end . The elseif ... then ... part (of which there may be more than one) and the else ... part are optional. After if and elseif comes a boolean expression; after then , elseif and else come zero or more instructions.
+
+A multi-branch instruction has the form
+
+inspect
+ ''exp''
+when ''v1'' then
+ ''inst1''
+when ''v2'' then
+ ''inst2''
+...
+else
+ ''inst0''
+end
+
+
+where the else ''inst0'' part is optional, exp is a character or integer expression, ''v1'', ''v1'', ... are constant values of the same type as exp , all different, and ''inst0'', ''inst1'', ''inst2'', ... are sequences of zero or more instructions. In the integer case, it is often convenient to use unique values ( [[10 Other Mechanisms|"Constant and unique attributes", page 83]] ) for the ''vi''
+
+The effect of such a multi-branch instruction, if the value of exp is one of the ''vi'', is to execute the corresponding ''insti''. If none of the ''vi'' matches, the instruction executes ''inst0'', unless there is no else part, in which case it triggers an exception.
+
+{{note|Raising an exception is the proper behavior, since the absence of an else indicates that the author asserts that one of the values will match. If you want an instruction that does nothing in this case, rather than cause an exception, use an else part with an empty ''inst0''. In contrast, if c then ''inst'' end with no else part does nothing in the absence of an else part, since in this case there is no implied claim that c must hold. }}
+
+The loop construct has the form
+
+from
+ ''initialization''
+until
+ ''exit''
+invariant
+ ''inv''
+variant
+ ''var''
+loop
+ ''body''
+end
+
+
+where the invariant ''inv'' and variant ''var'' parts are optional, the others required. ''initialization'' and ''body'' are sequences of zero or more instructions; ''exit'' and ''inv'' are boolean expressions (more precisely, ''inv'' is an assertion); ''var'' is an integer expression.
+
+The effect is to execute ''initialization'', then, zero or more times until ''exit'' is satisfied, to execute ''body''. (If after ''initialization'' the value of ''exit'' is already true, ''body'' will not be executed at all.) Note that the syntax of loops always includes an initialization, as most loops require some preparation. If not, just leave ''initialization''> empty, while including the from since it is a required component.
+
+The assertion ''inv'', if present, expresses a '''loop invariant''' (not to be confused with class invariants). For the loop to be correct, ''initialization'' must ensure ''inv'', and then every iteration of ''body'' executed when ''exit'' is false must preserve the invariant; so the effect of the loop is to yield a state in which both ''inv'' and ''exit'' are true. The loop must terminate after a finite number of iterations, of course; this can be guaranteed by using a '''loop variant''' ''var''. It must be an integer expression whose value is non-negative after execution of ''initialization'', and decreased by at least one, while remain non-negative, by any execution of ''body'' when ''exit'' is false; since a non-negative integer cannot be decreased forever, this ensures termination. The assertion monitoring mode, if turned on at the highest level, will check these properties of the invariant and variant after initialization and after each loop iteration, triggering an exception if the invariant does not hold or the variant is negative or does not decrease.
+
+An occasionally useful instruction is debug ( ''Debug_key'', ... ) ''instructions'' end where ''instructions'' is a sequence of zero or more instructions and the part in parentheses is optional, containing if present one or more strings, called debug keys. The EiffelStudio compiler lets you specify the corresponding debug compilation option: yes , no , or an explicit debug key. The ''instructions''will be executed if and only if the corresponding option is on. The obvious use is for instructions that should be part of the system but executed only in some circumstances, for example to provide extra debugging information.
+
+The final instruction is connected with Design by Contract™. The instruction check ''Assertion'' end , where ''Assertion'' is a sequence of zero or more assertions, will have no effect unless assertion monitoring is turned on at the Check level or higher. If so it will evaluate all the assertions listed, having no further effect if they are all satisfied; if any one of them does not hold, the instruction will trigger an exception.
+
+This instruction serves to state properties that are expected to be satisfied at some stages of the computation -- other than the specific stages, such as routine entry and exit, already covered by the other assertion mechanisms such as preconditions, postconditions and invariants. A recommended use of check involves calling a routine with a precondition, where the call, for good reason, does not explicitly test for the precondition. Consider a routine of the form
+
+r (ref: SOME_REFERENCE_TYPE) is
+ require
+ not_void: ref /= Void
+ do
+ ref.some_feature
+ ...
+ end
+
+
+Because of the call to some_feature , the routine will only work if its precondition is satisfied on entry. To guarantee this precondition, the caller may protect it by the corresponding test, as in
+
+if x /= Void then a.r (x) end
+
+
+but this is not the only possible scheme; for example if an create x appears shortly before the call we know x is not void and do not need the protection. It is a good idea in such cases to use a check instruction to document this property, if only to make sure that a reader of the code will realize that the omission of an explicit test (justified or not) was not a mistake. This is particularly appropriate if the justification for not testing the precondition is less obvious. For example x could have been obtained, somewhere else in the algorithm, as clone (y) for some y that you know is not void. You should document this knowledge by writing the call as
+
+check
+ x_not_void: x /= Void end
+ -- Because x was obtained as a clone of y,
+ -- and y is not void because [etc.]
+end
+a.r (x)
+
+
+{{note|Note the recommended convention: extra indentation of the check part to separate it from the algorithm proper; and inclusion of a comment listing the rationale behind the developer's decision not to check explicitly for the precondition. }}
+
+In production mode with assertion monitoring turned off, this instruction will have no effect. But it will be precious for a maintainer of the software who is trying to figure out what it does, and in the process to reconstruct the original developer's reasoning. (The maintainer might of course be the same person as the developer, six months later.) And if the rationale is wrong somewhere, turning assertion checking on will immediately uncover the bug.
+
+==Obsolete features and classes==
+
+One of the conditions for producing truly great reusable software is to recognize that although you should try to get everything right the first time around you won't always succeed. But if "good enough" may be good enough for application software, it's not good enough, in the long term, for reusable software. The aim is to get ever closer to the asymptote of perfection. If you find a better way, you must implement it. The activity of generalization, discussed as part of the lifecycle, doesn't stop at the first release of a reusable library.
+
+This raises the issue of backward compatibility: how to move forward with a better design, without compromising existing applications that used the previous version?
+
+The notion of obsolete class and feature helps address this issue. By declaring a feature as obsolete , using the syntax
+
+enter (i: INTEGER; x: G) is
+ obsolete
+ "Use ` put (x, i)' instead "
+ require
+ ...
+ do
+ put (x, i)
+ end
+
+
+you state that you are now advising against using it, and suggest a replacement through the message that follows the keyword obsolete , a mere string. The obsolete feature is still there, however; using it will cause no other harm than a warning message when someone compiles a system that includes a call to it. Indeed, you don't want to hold a gun to your client authors' forehead (''"Upgrade now or die !"''); but you do want to let them know that there is a new version and that they should upgrade at their leisure.
+
+Besides routines, you may also mark classes as obsolete.
+
+The example above is a historical one, involving an early change of interface for the EiffelBase library class ARRAY ; the change affected both the feature's name, with a new name ensuring better consistency with other classes, and the order of arguments, again for consistency. It shows the recommended style for using obsolete :
+* In the message following the keyword, explain the recommended replacement. This message will be part of the warning produced by the compiler for a system that includes the obsolete element.
+* In the body of the routine, it is usually appropriate, as here, to replace the original implementation by a call to the new version. This may imply a small performance overhead, but simplifies maintenance and avoids errors.
+
+
+It is good discipline not to let obsolete elements linger around for too long. The next major new release, after a suitable grace period, should remove them.
+
+The design flexibility afforded by the obsolete keyword is critical to ensure the harmonious long-term development of ambitious reusable software.
+
+==Creation variants==
+
+The basic forms of creation instruction, and the one most commonly used, are the two illustrated earlier ( [[6 The Dynamic Structure: Execution Model|"Creating and initializing objects", page 20]] ):
+
+create x.make (2000)
+create x
+
+
+the first one if the corresponding class has a create clause, the second one if not. In either form you may include a type name in braces, as in
+
+create {SAVINGS_ACCOUNT} x.make (2000)
+
+
+which is valid only if the type listed, here SAVINGS_ACCOUNT , conforms to the type of x , assumed here to be ACCOUNT . This avoids introducing a local entity, as in
+
+local
+ xs: SAVINGS_ACCOUNT
+do
+ create xs.make (2000)
+ x := xs
+ ...
+
+
+and has exactly the same effect. Another variant is the '''creation expression''', which always lists the type, but returns a value instead of being an instruction. It is useful in the following context:
+
+some_routine (create {ACCOUNT}.make (2000))
+
+
+which you may again view as an abbreviation for a more verbose form that would need a local entity, using a creation instruction:
+
+local
+ x: ACCOUNT
+do
+ create x.make (2000)
+ some_routine (x)
+ ...
+
+
+Unlike creation instructions, creation expressions must always list the type explicitly, {ACCOUNT} in the example. They are useful in the case shown: creating an object that only serves as an argument to be passed to a routine. If you need to retain access to the object through an entity, the instruction create x ... is the appropriate construct.
+
+The creation mechanism gets an extra degree of flexibility through the notion of default_create . The simplest form of creation instruction, create x without an explicit creation procedure, is actually an abbreviation for create x.default_create , where default_create is a procedure defined in class ANY to do nothing. By redefining default_create in one of your classes, you can ensure that create x will take care of non-default initialization (and ensure the invariant if needed). When a class has no create clause, it's considered to have one that lists only default_create . If you want to allow create x as well as the use of some explicit creation procedures, simply list default_create along with these procedures in the create clause. To disallow creation altogether, include an empty create clause, although this technique is seldom needed since most non-creatable classes are deferred, and one can't instantiate a deferred class.
+
+One final twist is the mechanism for creating instances of formal generic parameters. For x of type G in a class C [G] , it wouldn't be safe to allow create x , since G stands for many possible types, all of which may have their own creation procedures. To allow such creation instructions, we rely on constrained genericity. You may declare a class as
+
+[G -> T create cp end]
+
+
+to make G constrained by T , as we learned before, and specify that any actual generic parameter must have cp among its creation procedures. Then it's permitted to use create x.cp , with arguments if required by cp , since it is guaranteed to be safe. The mechanism is very general since you may use ANY for T and default_create for cp . The only requirement on cp is that it must be a procedure of T , not necessarily a creation procedure; this permits using the mechanism even if T is deferred, a common occurrence. It's only descendants of T that must make cp a creation procedure, by listing it in the create clause, if they want to serve as actual generic parameters for C .
+
+==Tuple types==
+
+The study of genericity described arrays. Another common kind of container objects bears some resemblance to arrays: sequences, or "tuples", of elements of specified types. The difference is that all elements of an array were of the same type, or a conforming one, whereas for tuples you will specify the types we want for each relevant element. A typical tuple type is of the form
+
+TUPLE [X, Y, Z]
+
+
+denoting a tuple of least three elements, such that the type of the first conforms to X , the second to Y , and the third to Z .
+
+You may list any number of types in brackets, including none at all: TUPLE , with no types in brackets, denotes tuples of arbitrary length.
+
+{{info|The syntax, with brackets, is intentionally reminiscent of generic classes, but TUPLE is a reserved word, not the name of a class; making it a class would not work since a generic class has a fixed number of generic parameters. You may indeed use TUPLE to obtain the effect of a generic class with a variable number of parameters. }}
+
+To write the tuples themselves -- the sequences of elements, instances of a tuple type -- you will also use square brackets; for example
+
+[x1, y1, z1]
+
+
+with x1 of type X and so on is a tuple of type TUPLE [X, Y, Z] .
+
+The definition of tuple types states that TUPLE [X1 ... Xn] denotes sequences of at least n elements, of which the first n have types respectively conforming to X1, ..., Xn . Such a sequence may have more than n elements.
+
+Features available on tuple types include count: INTEGER , yielding the number of elements in a tuple, item (i: INTEGER): ANY which returns the i -th element, and put which replaces an element.
+
+Tuples are appropriate when these are the only operations you need, that is to say, you are using sequences with no further structure or properties. Tuples give you "anonymous classes" with predefined features count , item and put . A typical example is a general-purpose output procedure that takes an arbitrary sequence of values, of arbitrary types, and prints them. It may simply take an argument of type TUPLE , so that clients can call it under the form
+
+write ([ ''your_integer'' , ''your_real'', ''your_account''])
+
+
+As soon as you need a type with more specific features, you should define a class.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-overview.wiki b/documentation/current/method/eiffel-tutorial-et/et-overview.wiki
new file mode 100644
index 00000000..2913de55
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-overview.wiki
@@ -0,0 +1,24 @@
+[[Property:title|1 Overview]]
+[[Property:link_title|ET: Overview]]
+[[Property:weight|-15]]
+Eiffel is a method and language for the efficient description and development of quality systems.
+
+As a language, Eiffel is more than a programming language. It covers not just programming in the restricted sense of implementation but the whole spectrum of software development:
+* ''Analysis, modeling and specification'', where Eiffel can be used as a purely descriptive tool to analyze and document the structure and properties of complex systems (even non-software systems).
+* ''Design and architecture'', where Eiffel can be used to build solid, flexible system structures.
+* ''Implementation'', where Eiffel provides practical software solutions with an efficiency comparable to solutions based on such traditional approaches as C and Fortran.
+* ''Maintenance'', where Eiffel helps thanks to the architectural flexibility of the resulting systems.
+* ''Documentation'', where Eiffel permits automatic generation of documentation, textual and graphical, from the software itself, as a partial substitute for separately developed and maintained software documentation.
+
+
+Although the language is the most visible part, Eiffel is best viewed as a '''method''', which guides system analysts and developers through the process of software construction. The Eiffel method is focused on both productivity (the ability to produce systems on time and within budget) and quality, with particular emphasis on the following quality factors:
+* ''Reliability:'' producing bug-free systems, which perform as expected.
+* ''Reusability:'' making it possible to develop systems from prepackaged, high-quality components, and to transform software elements into such reusable components for future reuse.
+* ''Extendibility:'' developing software that is truly soft -- easy to adapt to the inevitable and frequent changes of requirements and other constraints.
+* ''Portability:'' freeing developers from machine and operating system peculiarities, and enabling them to produce software that will run on many different platforms.
+* ''Maintainability:'' yielding software that is clear, readable, well structured, and easy to continue enhancing and adapting.
+
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki
new file mode 100644
index 00000000..dab68dc5
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-software-process-eiffel.wiki
@@ -0,0 +1,54 @@
+[[Property:title|3 The Software Process in Eiffel]]
+[[Property:link_title|ET: The Software Process in Eiffel]]
+[[Property:weight|-13]]
+Eiffel, as noted, supports the entire lifecycle. The underlying view of the system development lifecycle is radically different not only from the traditional "Waterfall" model (implying a sequence of discrete steps, such as analysis, global design, detailed design, implementation, separated by major changes of method and notation) but also from its more recent variants such as the spiral model or "rapid prototyping", which remain predicated on a synchronous, full-product process, and retain the gaps between successive steps.
+
+Clearly, not everyone using Eiffel will follow to the letter the principles outlined below; in fact, some highly competent and successful Eiffel developers may disagree with some of them and use a different process model. In the author's mind, however, these principles fit best with the language and the rest of the method, even if practical developments may fall short of applying their ideal form.
+
+==Clusters and the cluster model==
+
+Unlike earlier approaches, the Eiffel model assumes that the system is divided into a number of subsystems or '''clusters'''. It keeps from the Waterfall a sequential approach to the development of each cluster (without the gaps), but promotes '''concurrent engineering''' for the overall process, as suggested by the following picture:
+ [[Image:tutorial-2]]
+The Eiffel techniques developed below, in particular information hiding and Design by Contract, make the concurrent engineering process possible by letting the clusters rely on each other through clearly defined interfaces, strictly limiting the amount of knowledge that one must acquire to use the cluster, and permitting separate testing. When the inevitable surprises of a project happen, the project leader can take advantage of the model's flexibility, advancing or delaying various clusters and steps through dynamic reallocation of resources.
+
+Each of the individual cluster life cycles is based on a continuous progression of activities, from the more abstract to the more implementation-oriented:
+ [[Image:tutorial-3]]
+You may view this picture as describing a process of accretion (as with a stalactite), where each steps enriches the results of the previous one. Unlike traditional views, which emphasize the multiplicity of software products -- analysis document, global and detailed design documents, program, maintenance reports... --, the principle is here to treat the software as a '''single product''' which will be repeatedly refined, extended and improved. The Eiffel language supports this view by providing high-level notations that can be used throughout the lifecycle, from the most general and software-independent activities of system modeling to the most exacting details of implementation tuned for optimal run-time performance.
+
+These properties make Eiffel span the scope of both "object-oriented methods", with their associated notations such as UML and supporting CASE tools (whereas most such solutions do not yield an executable result), and "programming languages" (whereas most such languages are not suitable for design and analysis).
+
+==Seamlessness and reversibility==
+
+The preceding ideas define the '''seamless approach''' embodied by Eiffel. With seamlessness goes '''reversibility''': the ability to go back, even late in the process, to earlier stages. Because the developers work on a single product, they can take advantages of bouts of late wisdom -- such as a great idea for adding a new function, discovered only at implementation time -- and integrate them in the product. Traditional approaches tend to discourage reversibility because it is difficult to guarantee that the analysis and design will be updated with the late changes. With the single-product principle, this is much easier to achieve.
+
+Seamlessness and reversibility enhance extendibility by providing a direct mapping from the structure of the solution to the structure of the problem description, making it easier to take care of customers' change requests quickly and efficiently. They promote reliability, by avoiding possible misunderstandings between customers' and developers' views. They are a boost to maintainability. More generally, they yield a smooth, consistent software process that helps both quality and productivity.
+
+==Generalization and reuse==
+
+The last step of the cluster, Generalization, is unheard of in traditional models. Its task is to prepare the results of a cluster for reuse across projects by looking for elements of general applicability, and transform them for inclusion in libraries.
+
+Recent object-oriented literature has used the term "refactoring" to describe a process of continuous improvement of released software. Generalization includes refactoring, but also pursues a more ambitious goal: helping turn program elements (software modules useful only as part of a certain program) into software components -- reusable parts with a value of their own, ready to be used by diverse programs that can benefit from their capabilities.
+
+Of course not all companies using the method will be ready to include a Generalization phase in their. But those which do will see the reusability of their software greatly improved.
+
+==Constant availability==
+
+Complementing the preceding principles is the idea that, in the cluster lifecycle, the development team (under the responsibility of the project leader) should at all times maintain a current working demo which, although covering only a part of the final system, works well, and can be demonstrated or -- starting at a suitable time -- shipped as an early release. It is not a "prototype" in the sense of a meant to be thrown away, but an initial iteration towards the final product; the successive iterations will progress continuously towards until they become that final product.
+
+==Compilation technology==
+
+The preceding goals benefit from the ability to check frequently that the current iteration is correct and robust. Eiffel supports efficient compilation mechanisms through such mechanisms as the '''Melting Ice Technology''' in EiffelStudio. The Melting Ice achieves immediate recompilation after a change, guaranteeing a recompilation time that's a function of the size of the changes, not of the system's overall size. Even for a system of several thousand classes and several hundred thousand lines, the time to get restarted after a change to a few classes is, on a typical modern computer, a few seconds.
+
+Such a "melt" (recompilation) will immediately catch (along with any syntax errors) the type errors -- often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors have been corrected, the developers should start testing the new functionalities, relying on the power of '''assertions''' -- explained in [[8 Design by Contract (tm), Assertions and Exceptions|"Design By Contract™ Assertions, Exceptions", page 38 ]] -- to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the "current demo" is trustworthy and will eventually yield a correct and robust product.
+
+==Quality and functionality==
+
+Throughout the process, the method suggests maintaining a constant '''quality''' level: apply all the style rules, put in all the assertions, handle erroneous cases (rather than the all too common practice of thinking that one will "make the product robust" later on), enforce the proper architecture. This applies to all the quality factors except possibly reusability (since one may not know ahead of time how best to generalize a component, and trying to make everything fully general may conflict with solving the specific problem at hand quickly). All that varies is '''functionality''': as the project progresses and clusters come into place, more and more of the final product's intended coverage becomes available. The project's most common question, "Can we ship something yet?", translates into "Do we cover enough?", not "Is it good enough?" (as in "Will it not crash?").
+
+Of course not everyone using Eiffel can, any more than in another approach, guarantee that the ideal just presented will always hold. But it is theoretical scheme to which the method tends. It explains Eiffel's emphasis on getting everything right: the grandiose and the mundane, the structure and the details. Regarding the details, the Eiffel books cited in the bibliography include many rules, some petty at first sight, about such low-level aspects as the choice of names for classes and features (including their grammatical categories), the indentation of software texts, the style for comments (including the presence or absence of a final period), the use of spaces. Applying these rules does not, of course, guarantee quality; but they are part of a quality-oriented process, along with the more ambitious principles of design. In addition they are particularly important for the construction of quality libraries, one of the central goals of Eiffel.
+
+Whenever they are compatible with the space constraints, the present chapter and the rest of this book apply these rules to their Eiffel examples.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki
new file mode 100644
index 00000000..68822659
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/et-static-picture-system-organization.wiki
@@ -0,0 +1,72 @@
+[[Property:title|5 The Static Picture: System Organization]]
+[[Property:link_title|ET: The Static Picture: System Organization]]
+[[Property:weight|-11]]
+We now look at the overall organization of Eiffel software.
+
+References to Eiffel Software's libraries appearing in subsequent examples include: '''EiffelBase''', the fundamental open-source library covering data structures and algorithms; the '''kernel library''', a subset of EiffelBase covering the most basic notions such as arrays and strings; and '''EiffelVision 2''', an advanced graphics and GUI library providing full compatibility across platforms (Unix, Windows, VMS) with native look-and-feel on each.
+
+==Systems==
+
+An Eiffel system is a collection of classes, one of which is designated as the root class. One of the features of the root class, which must be one of its creation procedures, is designated as the root procedure.
+
+To execute such a system is to create an instance of the root class (an object created according to the class description) and to execute the root procedure. In anything more significant than "Hello World" systems, this will create new objects and apply features to them, in turn triggering further creations and feature calls.
+
+For the system to make sense, it must contains all the classes on which the root '''depends''' directly or indirectly. A class B depends on a class A if it is either a '''client''' of A , that is to say uses objects of type A , or an '''heir''' of A , that is to say extends or specializes A . (These two relations, client and inheritance, are covered below.)
+
+==Classes==
+
+The notion of class is central to the Eiffel approach. A class is the description of a type of run-time data structures (objects), characterized by common operations features) and properties. Examples of classes include:
+* In a banking system, a class ACCOUNT may have features such as deposit , adding a certain amount to an account, all_deposits , yielding the list of deposits since the account's opening, and balance , yielding the current balance, with properties stating that deposit must add an element to the all_deposits list and update balance by adding the sum deposited, and that the current value of balance must be consistent with the lists of deposits and withdrawals.
+* A class COMMAND in an interactive system of any kind may have features such as execute and undo , as well as a feature undoable which indicates whether a command can be undone, with the property that undo is only applicable if undoable yields the value true.
+* A class LINKED_LIST may have features such as put , which adds an element to a list, and count , yielding the number of elements in the list, with properties stating that put increases count by one and that count is always non-negative.
+
+We may characterize the first of these examples as an analysis class, directly modeling objects from the application domain; the second one as a design class, describing a high-level solution; and the third as an implementation class, reused whenever possible from a library such as EiffelBase. In Eiffel, however, there is no strict distinction between these categories; it is part of the approaches seamlessness that the same notion of class, and the associated concepts, may be used at all levels of the software development process.
+
+==Class relations==
+
+Two relations may exist between classes:
+* You can define a class C as a '''client''' of a class A to enable the features of C to rely on objects of type A .
+* You may define a class B as an '''heir''' of a class A to provide B with all the features and properties of A , letting B add its own features and properties and modify some of the inherited features if appropriate.
+
+If C is a client of A , A is a '''supplier''' of C . If B is an heir of A , A is a '''parent''' of B . A '''descendant''' of A is either A itself or, recursively, a descendant of an heir of A ; in more informal terms a descendant is a direct or indirect heir, or the class itself. To exclude A itself we talk of '''proper descendant'''. In the reverse direction the terms are '''ancestor''' and '''proper ancestor'''.
+
+The client relation can be cyclic; an example involving a cycle would be classes PERSON and HOUSE , modeling the corresponding informal everyday "object" types and expressing the properties that every person has a home and every home has an architect. The inheritance (heir) relation may not include any cycle.
+
+In modeling terms, client roughly represents the relation "has" and heir roughly represents "is". For example we may use Eiffel classes to model a certain system and express that every child has a birth date (client relation) and is a person (inheritance).
+
+Distinctive of Eiffel is the rule that lasses can only be connected through these two relations. This excludes the behind-the-scenes dependencies often found in other approaches, such as the use of global variables, which jeopardize the modularity of a system. Only through a strict policy of limited and explicit inter-class relations can we achieve the goals of reusability and extendibility.
+
+==The global inheritance structure==
+
+An Eiffel class that you write does not come into a vacuum but fits in a preordained structure, shown in the figure and involving two library classes: ANY and NONE .
+ [[Image:tutorial-4]]
+Any class that does not explicitly inherit from another is considered to inherit from ANY , so that every class is a descendant, direct or indirect, of ANY . ANY introduces a number of general-purpose features useful everywhere, such as copying, cloning and equality testing operations (page [[6 The Dynamic Structure: Execution Model|28]] ) and default input-output. The procedure print used in the first version of our "Hello World" (page [[4 Hello World|11]] ) comes from ANY .
+
+ NONE inherits from any class that has no explicit heir. Since inheritance has no cycles, NONE cannot have proper descendants. This makes it useful, as we will see, to specify non-exported features, and to denote the type of void values. Unlike ANY , class NONE doesn't have an actual class text; instead, it's a convenient fiction.
+
+==Clusters==
+
+Classes are the only form of module in Eiffel. As will be explained in more detail, they also provide the basis for the only form of type. This module-type identification is at the heart of object technology and of the fundamental simplicity of the Eiffel method.
+
+Above classes, you will find the concept of cluster. A cluster is a group of related classes. Clusters are a property of the method, enabling managers to organize the development into teams. As we have already seen (section [[3 The Software Process in Eiffel|3]] ) they also play a central role in the lifecycle model. Clusters are an organizational concept, not a form of module, and do not require an Eiffel language construct.
+
+==External software==
+
+The subsequent sections will show how to write Eiffel classes with their features. In an Eiffel system, however, not everything has to be written in Eiffel: some features may be '''external''' , coming from languages such as C, C++, Java, C# Fortran and others. For example a feature declaration may appear (in lieu of the forms seen later) as
+
+file_status (filedesc: INTEGER): INTEGER is
+ -- Status indicator for filedesc
+ external
+ "C" alias "_fstat"
+ end
+
+
+to indicate that it is actually an encapsulation of a C function whose original name is fstat _ . The alias clause is optional, but here it is needed because the C name, starting with an underscore, is not valid as an Eiffel identifier.
+
+Similar syntax exists to interface with C++ classes. EiffelStudio includes a tool called Legacy++ which will automatically produce, from a C++ class, an Eiffel class that encapsulates its facilities, making them available to the rest of the Eiffel software as bona fide Eiffel features.
+
+These mechanisms illustrate one of the roles of Eiffel: as an system architecturing and software composition tool, used at the highest level to produce systems with robust, flexible structures ready for extendibility, reusability and maintainability. In these structures not everything must be written in the Eiffel language: existing software elements and library components can play their part, with the structuring capabilities of Eiffel (classes, information hiding, inheritance, clusters, contracts and other techniques seen in this presentation) serving as the overall wrapping mechanism.
+
+
+
+
diff --git a/documentation/current/method/eiffel-tutorial-et/index.wiki b/documentation/current/method/eiffel-tutorial-et/index.wiki
new file mode 100644
index 00000000..1138629a
--- /dev/null
+++ b/documentation/current/method/eiffel-tutorial-et/index.wiki
@@ -0,0 +1,38 @@
+[[Property:title|An Eiffel Tutorial]]
+[[Property:link_title|Tutorial]]
+[[Property:weight|2]]
+==Interactive Software Engineering==
+
+[[MANUAL IDENTIFICATION AND COPYRIGHT: Tutorial|MANUAL IDENTIFICATION AND COPYRIGHT]]
+
+{{note|This is '''not''' an introduction to the EiffelStudio development environment. See the [[Getting started with Eiffel|list of introductory documents]] for a Guided Tour of EiffelStudio and a detailed Eiffel Tutorial. }}
+
+==[[1 Overview|1 OVERVIEW]]==
+
+==[[2 General Properties|2 GENERAL PROPERTIES]]==
+
+==[[3 The Software Process in Eiffel|3 THE SOFTWARE PROCESS IN EIFFEL]]==
+
+==[[4 Hello World|4 HELLO WORLD]]==
+
+==[[5 The Static Picture: System Organization|5 THE STATIC PICTURE: SYSTEM ORGANIZATION]]==
+
+==[[6 The Dynamic Structure: Execution Model|6 THE DYNAMIC STRUCTURE: EXECUTION MODEL]]==
+
+==[[7 Genericity and Arrays|7 GENERICITY AND ARRAYS]]==
+
+==[[8 Design by Contract (tm), Assertions and Exceptions|8 DESIGN BY CONTRACT TM, ASSERTIONS, EXCEPTIONS]]==
+
+==[[9 Inheritance|9 INHERITANCE]]==
+
+==[[10 Other Mechanisms|10 OTHER MECHANISMS]]==
+
+==[[11 Agents|11 AGENTS]]==
+
+==[[12 Lexical Conventions and Style Rules|12 LEXICAL CONVENTIONS AND STYLE RULES]]==
+
+==[[13 To Learn More|13 TO LEARN MORE]]==
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki
new file mode 100644
index 00000000..596dab70
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-classes.wiki
@@ -0,0 +1,104 @@
+[[Property:title|4 Classes]]
+[[Property:link_title|I2E: Classes]]
+[[Property:weight|-11]]
+A class, it was said above, is an implementation of an abstract data type. This means that it describes a set of run-time objects, characterized by the ''' features''' (operations) applicable to them, and by the formal properties of these features.
+
+Such objects are called the '''direct instances''' of the class. Classes and objects should not be confused: "class" is a compile-time notion, whereas objects only exist at run time. This is similar to the difference that exists in classical programming between a program and one execution of that program, or between a type and a run-time value of that type.
+
+{{info|"Object-Oriented" is a misnomer; "Class-Oriented Analysis, Design and Programming" would be a more accurate description of the method. }}
+
+To see what a class looks like, let us look at a simple example, ACCOUNT , which describes bank accounts. But before exploring the class itself it is useful to study how it maybe used by other classes, called it's '''clients'''.
+
+A class X may become a client of ACCOUNT by declaring one or more '''entities''' of type ACCOUNT . Such a declaration is of the form:
+acc: ACCOUNT
+
+The term "entity" generalizes the more common notion of "variable". An entity declared of a reference type, such as acc, may at any time during execution become " '''attached to''' " an object; the type rules imply that this object must be a direct instance of ACCOUNT -- or, as seen below, of a "descendant" of that class.
+ [[Image:invitation-2]]
+An entity is said to be void if it is not attached to any object. By default, entities are void at initialization. To obtain objects at run-time, a routine r appearing in the client class X may use a '''creation instruction''' of the form
+
+create acc
+
+
+which creates a new direct instance of ACCOUNT , attaches acc to that instance, and initializes all its fields to default values. A variant of this notation, studied below, makes it possible to override the default initializations.
+
+Once the client has attached acc to an object, it may call on this object the features defined in class ACCOUNT . Here is an extract with some feature calls using acc as their target:
+acc.open ("Jill")
+acc.deposit (5000)
+if acc.may_withdraw (3000) then
+ acc.withdraw (3000)
+ print (acc.balance)
+end
+
+These feature calls use dot notation, of the form target . feature_name , possibly followed by a list of arguments in parentheses. Features are of two kinds:
+* '''Routines''', such as open , deposit , may_withdraw , withdraw , represent computations applicable to instances of the class.
+* '''Attributes''' represent data items associated with these instances.
+
+Routines are further divided into '''procedures''' (commands, which do not return a value) and '''functions''' (queries, returning a value). Here may_withdraw is a function returning a boolean; the other three-routines called are procedures.
+
+{{info|A note on syntax: you may separate instructions by semicolons, and indeed you should when, as on the next-to-last line of the example, two or more instructions appear on a line. But the language's syntax has been designed so that the semicolon is almost always optional, regardless of the layout. Indeed the practice is to omit it between instructions or declarations on separate lines, as this results in lighter, clearer software texts. }}
+
+In class ACCOUNT , is feature balance an attribute, or is it a function with no argument? The above extract of the client class X doesn't say, and this ambiguity is intentional. A client of ACCOUNT must not need to know how class ACCOUNT delivers an account's balance when requested: by looking up a field present in each account object, or by calling a function that computes the balance from other fields. Choosing between these techniques is the business of class ACCOUNT , not anybody else's. Because such implementation choices are often changed over the lifetime of a project, it is essential to protect clients against their effects. This is known as the '''Uniform Access Principle''', stating that the choice between representing a property through memory (an attribute) or through an algorithm (function) shall not affect how clients use it.
+
+So much for how client classes will typically use ACCOUNT. Below is a first sketch of how class ACCOUNT itself might look. Line segments beginning with -- are comments. The class includes two feature clauses, introducing its features. The first begins with just the keyword feature , without further qualification; this means that the features declared in this clause are available (or "exported") to all clients of the class. The second clause is introduced by feature { NONE } to indicate that the feature that follows, called add , is available to no client. What appears between the braces is a list of client classes to which the corresponding features are available; NONE is a special class of the Kernel Library, which has no instances, so that add is in effect a secret feature, available only locally to the other routines of class ACCOUNT . So in a client class such as X , the call acc . add ( -3000 ) would be invalid.
+class ACCOUNT
+
+feature
+
+ balance: INTEGER
+ owner: PERSON
+ minimum_balance: INTEGER is 1000
+
+ open (who: PERSON) is
+ -- Assign the account to owner who.
+ do
+ owner := who
+ end
+
+ deposit (sum: INTEGER) is
+ -- Deposit sum into the account.
+ do
+ add (sum)
+ end
+
+ withdraw (sum: INTEGER) is
+ -- Withdraw sum from the account.
+ do
+ add (-sum)
+ end
+
+ may_withdraw (sum: INTEGER): BOOLEAN is
+ -- Is there enough money to withdraw sum?
+ do
+ Result := (balance >= sum + minimum_balance)
+ end
+
+feature {NONE}
+
+ add (sum: INTEGER) is
+ -- Add sum to the balance
+ do
+ balance := balance + sum
+ end
+
+end -- ACCOUNT
+
+
+Let us examine the features in sequence. The is ... do ... end distinguishes routines from attributes. So here the class has implemented balance as an attribute, although, as noted, a function would also have been acceptable. Feature owner is also an attribute.
+
+The language definition guarantees automatic initialization, so that the initial balance of an account object will be zero after a creation instruction. Each type has a default initial value: zero for INTEGER and REAL , false for BOOLEAN , null character for CHARACTER , and a void reference for reference types. The class designer may also provide clients with different initialization options, as will be seen below in a revised version of this example.
+
+The other public features, withdraw deposit, open, and may_withdraw are straight-forward routines. The special entity Result , used in may_withdraw , denotes the function result; it is initialized on function entry to the default value of the function's result type. You may only use Result in functions.
+
+The secret procedure add serves for the implementation of the public procedures deposit and withdraw ; the designer of ACCOUNT judged it too general to be exported by itself. The clause is 1000 introduces minimum_balance as a constant attribute, which will not occupy any space in instances of the class; in contrast, every instance has a field for every non-constant attribute such as balance .
+
+In Eiffel's object-oriented programming style any operation is relative to a certain object. A client invoking the operation specifies this object by writing the corresponding entity on the left of the dot, as acc in acc . open ( "Jill" ). Within the class, however, the "current" instance to which operations apply usually remains implicit, so that unqualified feature names, such as owner in procedure open or add in deposit , mean "the owner attribute or add routine relative to the current instance".
+
+If you need to denote the current object explicitly, you may use the special entity Current . For example the unqualified occurrences of add appearing in the class text above are equivalent to Current . add .
+
+In some cases, infix or prefix notation will be more convenient than dot notation. For example, if a class VECTOR offers an addition routine, most people will feel more comfortable with calls of the form v + w than with the dot-notation call v . plus ( w ). To make this possible it suffices to give the routine a name of the form infix "+" rather than plus ; internally, however, the operation is still a normal routine call. Prefix operators are similarly available.
+
+The above simple example has shown the basic structuring mechanism of the language: the class. A class describes objects accessible to clients through an official interface comprising some of the class features. Features are implemented as attributes or routines; the implementation of exported features may rely on other, secret ones.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki
new file mode 100644
index 00000000..44d57810
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki
@@ -0,0 +1,30 @@
+[[Property:title|12 Combining Genericity and Inheritance]]
+[[Property:link_title|I2E: Combining Genericity and Inheritance]]
+[[Property:weight|-3]]
+Genericity and inheritance, the two fundamental mechanisms for generalizing classes, may be combined in two fruitful ways.
+
+The first technique yields '''polymorphic data structures'''. Assume that in the generic class LIST [ G ] the insertion procedure put has a formal argument of type G , representing the element to be inserted. Then with a declaration such as
+pl: LIST [POLYGON]
+
+the type rules imply that in a call pl . put ( "p" ) the permitted types for the argument p include not just POLYGON , but also RECTANGLE (an heir of POLYGON ) or any other type conforming to POLYGON through inheritance.
+
+The basic conformance requirement used here is the inheritance-based type compatibility rule: V conforms to T if V is a descendant of T .
+
+Structures such as pl may contain objects of different types, hence the name "polymorphic data structure". Such polymorphism is, again, made safe by the type rules: by choosing an actual generic parameter ( POLYGON in the example) based higher or lower in the inheritance graph, you extend or restrict the permissible types of objects in pl . A fully general list would be declared as
+LIST [ANY]
+
+where ANY , a Kernel Library class, is automatically an ancestor of any class that you may write.
+
+The other mechanism for combining genericity and inheritance is '''constrained genericity'''. By indicating a class name after a formal generic parameter, as in
+VECTOR [T -> NUMERIC]
+
+you express that only descendants of that class (here NUMERIC ) may be used as the corresponding actual generic parameters. This makes it possible to use the corresponding operations. Here, for example, class VECTOR may define a routine infix "+" for adding vectors, based on the corresponding routine from NUMERIC for adding vector elements. Then by making VECTOR itself inherit from NUMERIC , you ensure that it satisfies its own generic constraint and enable the definition of types such as VECTOR [ VECTOR [ T ]] .
+
+As you have perhaps guessed, unconstrained genericity, as in LIST [ G ] , may be viewed as an abbreviation for genericity constrained by ANY , as in
+LIST [G -> ANY]
+
+Something else you may have guessed: if ANY , introduced in this session, is the top of the inheritance structure -- providing all classes with universal features such as equal to compare arbitrary objects and clone to duplicate objects -- then NONE , seen earlier in the notation feature { NONE } , is its bottom. NONE indeed conceptually inherits from all other classes. NONE is, among other things, the type of ensure , the void reference.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki
new file mode 100644
index 00000000..116a8073
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki
@@ -0,0 +1,58 @@
+[[Property:title|13 Deferred Classes and Seamless Development]]
+[[Property:link_title|I2E: Deferred Classes and Seamless Development]]
+[[Property:weight|-2]]
+The inheritance mechanism includes one more major notion: deferred features and classes.
+
+Declaring a feature f as deferred in a class C expresses that there is no default implementation of f in C ; such implementations will appear in eventual descendants of C . A class that has one or more deferred routines is itself said to be deferred. A non-deferred routine or class -- like all those seen until now -- is said to be '''effective'''.
+
+For example, a system used by a Department of Motor Vehicles to register vehicles might include a class of the form
+
+deferred class
+ VEHICLE
+
+feature
+
+ dues_paid (year: INTEGER): BOOLEAN is
+ do ... end
+
+ valid_plate (year: INTEGER): BOOLEAN is
+ do ... end
+
+ register (year: INTEGER) is
+ -- Register vehicle for year.
+ require
+ dues_paid (year)
+ deferred
+ ensure
+ valid_plate (year)
+ end
+
+ ... Other features, deferred or effective ...
+
+end -- VEHICLE
+
+
+This example assumes that no single registration algorithm applies to all kinds of vehicle; passenger cars, motorcycles, trucks etc. are all registered differently. But the same precondition and postcondition apply in all cases. The solution is to treat register as a deferred routine, making VEHICLE a deferred class. Descendants of class VEHICLE, such as CAR or TRUCK, effect this routine, that is to say, give effective versions. An effecting is similar to a redefinition; only here there is no effective definition in the original class, just a specification in the form of a deferred routine. The term '''redeclaration''' covers both redefinition and effecting.
+ [[Image:invitation-5]]
+ Whereas an effective class described an implementation of an abstract data types, a deferred class describes a set of possible implementations. You may not instantiate a deferred class: create v is invalid if v is declared of type VEHICLE. But you may assign to v a reference to an instance of an effective descendant of VEHICLE. For example, assuming CAR and TRUCK provide effective definitions for all deferred routines of VEHICLE, the following will be valid:
+
+v: VEHICLE; c: CAR; t: TRUCK
+... create c; create t ...
+if "Some test" then
+ v := c
+else
+ v := t
+end
+v.register (2003)
+
+This example fully exploits polymorphism: depending on the outcome of "Some test", v will be treated as a car or a truck, and the appropriate registration algorithm will be applied. Also, "Some test" may depend on some event whose outcome is impossible to predict until run-time, for example the user clicking with the mouse to select one among several vehicle icons displayed on the screen.
+
+Deferred classes are particularly useful at the design stage. The first version of a module may be a deferred class, which will later be refined into one or more effective classes. Eiffel's Design by Contract™ mechanisms are essential here: you may a precondition and a postcondition with a routine even though it is a deferred routine (as with register above), and an invariant with a class even though it is a deferred class. This enables you, as a designer, to attach precise semantics to a module at the design stage long before you will make any implementation choices.
+
+Beyond design and implementation, these techniques extend to the earliest stage of development, analysis. Deferred classes written at that stage describe not software objects, but objects from the external world being modeled -- documents, airplanes, investments. Here again the presence of contracts to express constraints, and the language's other structuring facilities, provide an attractive combination.
+
+Eiffel appears here in its full role of a lifecycle approach, covering areas traditionally considered separate: program implementation, the traditional province of development environments; system modeling and architecture, the traditional province of CASE tools based on UML or similar notations disconnected from the rest of the lifecycle. Eiffel instead emphasizes the fundamental unity of the software process and the usefulness of a single set of notations, concepts and tools applicable throughout. Such a seamless approach is indispensable to support the inevitable reversals that occur during the process of building software, such as detecting at implementation time a problem that leads to a change in the system's functionality, set at analysis time. The use of separate tools and notations, such as UML on one side and a programming language on the other, makes such round-trips difficult at best and often leads to monolithic, hard-to-change software. Eiffel lets you focus on the issues, without interposing artificial barriers between different software development activities. You'll use the fundamental problem-solving techniques -- data abstraction through classes, precise specification through contracts, modularity through information hiding, rational organization through inheritance, decentralized architecture through dynamic binding, parameterization of the solution through genericity, reusability through all these techniques -- all along; only the level of abstraction changes.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki
new file mode 100644
index 00000000..e8888ddb
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki
@@ -0,0 +1,140 @@
+[[Property:title|6 Design by Contract and Assertions]]
+[[Property:link_title|I2E: Design by Contract and Assertions]]
+[[Property:weight|-9]]
+If classes are to deserve their definition as abstract data type implementations, they must be known not just by the available operations, but also by the formal properties of these operations, which did not yet appear in the preceding example.
+
+==The role of assertions==
+
+Eiffel encourages software developers to express formal properties of classes by writing '''assertions''', which may in particular appear in the following roles:
+* Routine '''preconditions''' express the requirements that clients must satisfy whenever they call a routine. For example the designer of ACCOUNT may wish to permit a withdrawal operation only if it keeps the account's balance at or above the minimum. Preconditions are introduced by the keyword require .
+* Routine '''postconditions''', introduced by the keyword ensure , express conditions that the routine (the supplier) guarantees on return, if the precondition was satisfied on entry.
+* A class '''invariant''' must be satisfied by every instance of the class whenever the instance is externally accessible: after creation, and after any call to an exported routine of the class. The invariant appears in a clause introduced by the keyword invariant , and represents a general consistency constraint imposed on all routines of the class.
+
+
+With appropriate assertions, the class ACCOUNT becomes:
+class ACCOUNT
+create
+ make
+
+feature
+ ... Attributes as before:
+ balance , minimum_balance , owner , open ...
+
+ deposit (sum: INTEGER) is
+ -- Deposit sum into the account.
+ require
+ sum >= 0
+ do
+ add (sum)
+ ensure
+ balance = old balance + sum
+ end
+
+ withdraw (sum: INTEGER) is
+ -- Withdraw sum from the account.
+ require
+ sum >= 0
+ sum <= balance - minimum_balance
+ do
+ add (-sum)
+ ensure
+ balance = old balance - sum
+ end
+
+ may_withdraw ... -- As before
+
+feature {NONE}
+
+ add ...
+
+ make (initial: INTEGER) is
+ -- Initialize account with balance initial.
+ require
+ initial >= minimum_balance
+ do
+ balance := initial
+ end
+
+invariant
+ balance >= minimum_balance
+
+end -- ACCOUNT
+
+
+The notation old expression is only valid in a routine postcondition. It denotes the value the expression had on routine entry.
+
+==Creation procedures==
+
+In its last version above, the class now includes a creation procedure, make . With the first version, clients used creation instructions such as create acc1 to create accounts; but then the default initialization, setting balance to zero, violated the invariant. By having one or more creation procedures, listed in the create clause at the beginning of the class text, a class offers a way to override the default initializations. The effect of
+create acc1.make (5_500)
+
+is to allocate the object (as with the default creation) and to call procedure make on this object, with the argument given. This call is correct since it satisfies the precondition; it will ensure the invariant.
+
+{{info|The underscore _ in the integer constant 5_500 has no semantic effect. The general rule is that you can group digits by sets of three from the right to improve the readability of integer constants. }}
+
+Note that the same keyword, create , serves both to introduce creation instructions and the creation clause listing creation procedures at the beginning of the class.
+
+A procedure listed in the creation clause, such as make , otherwise enjoys the same properties as other routines, especially for calls. Here the procedure make is secret since it appears in a clause starting with feature { NONE } ; so it would be invalid for a client to include a call such as
+acc.make (8_000)
+
+To make such a call valid, it would suffice to move the declaration of make to the first feature clause of class ACCOUNT , which carries no export restriction. Such a call does not create any new object, but simply resets the balance of a previously created account.
+
+==Design by Contract™==
+
+Syntactically, assertions are boolean expressions, with a few extensions such as the old notation. Also, you may split an assertion into two or more clauses, as here with the precondition of withdraw ; this is as if you had separated the clauses with an and , but makes the assertion clearer, especially if it includes many conditions.
+
+Assertions play a central part in the Eiffel method for building reliable object-oriented software. They serve to make explicit the assumptions on which programmers rely when they write software elements that they believe are correct. Writing assertions amounts to spelling out the terms of the '''contract''' which governs the relationship between a routine and its callers. The precondition binds the callers; the postcondition binds the routine.
+
+The underlying theory of Design by Contract™, the centerpiece of the Eiffel method, views software construction as based on contracts between clients (callers) and suppliers (routines), relying on mutual obligations and benefits made explicit by the assertions.
+
+==The Contract Form==
+
+Assertions are also an indispensable tool for the documentation of reusable software components: one cannot expect large-scale reuse without a precise documentation of what every component expects (precondition), what it guarantees in return (postcondition) and what general conditions it maintains (invariant).
+
+Documentation tools in EiffelStudio use assertions to produce information for client programmers, describing classes in terms of observable behavior, not implementation. In particular the '''Contract Form''' of a class, also called its "short form", which serves as its interface documentation, is obtained from the full text by removing all non-exported features and all implementation information such as do clauses of routines, but keeping interface information and in particular assertions. Here is the Contract Form of the above class:
+
+class interface ACCOUNT
+
+create
+ make
+
+feature
+
+ balance: INTEGER
+ ...
+
+ deposit (sum: INTEGER) is
+ -- Deposit sum into the account.
+ require
+ sum >= 0
+ ensure
+ balance = old balance + sum
+
+ withdraw (sum: INTEGER) is
+ -- Withdraw sum from the account.
+ require
+ sum >= 0
+ sum <= balance - minimum_balance
+ ensure
+ balance = old balance - sum
+
+ may_withdraw ...
+
+end -- ACCOUNT
+
+
+This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( interface class rather than class ). In accordance with the Uniform Access Principle (page [[4 Classes|7]] ), the output for balance would be the same if this feature were a function rather than an attribute.
+
+You will find in EiffelStudio automatic tools to produce the Contract Form of a class. You can also get the '''Flat Contract''' form, based on the same ideas but including inherited features along with those introduced in the class itself. EiffelStudio can produce these forms, and other documentation views of a class, in a variety of output formats including HTML, so that collaborative projects can automatically post the latest versions of their class interfaces on the Internet or an Intranet.
+
+==Contracts for testing and debugging==
+
+Under EiffelStudio you may also set up compilation options, for the whole system or specific classes only, to evaluate assertions at run time, to uncover potential errors ("bugs"). EiffelStudio provides several levels of assertion monitoring: preconditions only, postconditions etc. When monitoring is on, an assertion which evaluates to true has no further effect on the execution. An assertion that evaluates to false will trigger an exception, as described next; unless you have written an appropriate exception handler, the exception will cause an error message and termination with a precise message and a call trace.
+
+This ability to check assertions provides a powerful testing and debugging mechanism, in particular because the classes of the EiffelBase Libraries, widely used in Eiffel software development, are protected by carefully written assertions.
+
+Run-time monitoring, however, is only one application of assertions, whose role as design and documentation aids, as part of theory of Design by Contract™, exerts a pervasive influence on the Eiffel style of software development.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki
new file mode 100644
index 00000000..768b0638
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-design-principles.wiki
@@ -0,0 +1,22 @@
+[[Property:title|2 Design Principles]]
+[[Property:link_title|I2E: Design Principles]]
+[[Property:weight|-13]]
+The aim of Eiffel is to help specify, design, implement and modify quality software. This goal of quality in software is a combination of many factors; the language design concentrated on the three factors which, in the current state of the industry, are in direct need of improvements: reusability, extendibility and reliability. Also important were other factors such as efficiency, openness and portability.
+
+'''Reusability''' is the ability to produce components that may serve in many different applications. Central to the Eiffel approach is the presence of predefined libraries such as EiffelBase, and the language's support for the production of new libraries.
+
+'''Extendibility''' is the ability to produce easily modifiable software. "Soft" as software is supposed to be, it is notoriously hard to modify software systems, especially large ones.
+
+Among quality factors, reusability and extendibility play a special role: satisfying them means having less software to write -- and hence more time to devote to other important goals such as efficiency, ease of use or integrity.
+
+The third fundamental factor is '''reliability, ''' the ability to produce software that is correct and robust -- that is to say, bug-free. Eiffel techniques such as static typing, assertions, disciplined exception handling and automatic garbage collection are essential here.
+
+Three other factors are also part of Eiffel's principal goals:
+* The language enables implementers to produce high '''efficiency''' compilers, so that systems developed with Professional Eiffel may run under speed and space conditions similar to those of programs written in lower-level languages.
+* Ensuring '''openness''', so that Eiffel software may cooperate with programs written in other languages.
+* Guaranteeing '''portability''' by a platform-independent language definition, so that the same semantics may be supported on many different platforms.
+
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki
new file mode 100644
index 00000000..640bf506
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki
@@ -0,0 +1,41 @@
+[[Property:title|8 Event-Driven Programming and Agents]]
+[[Property:link_title|I2E: Event-Driven Programming and Agents]]
+[[Property:weight|-7]]
+The division of roles in object technology is clear: of the two principal constituents of a system, object types and operations, the first dominates. Classes, representing object types, determines the structure of the software; every routine, representing an operations, belongs to a class.
+
+In some circumstances it is useful to define an object that denotes an operation. This is especially useful if you want to build an object structure that refers to operations, so that you can later traverse the structure and execute the operations encountered. A typical application is '''event-driven programming''' for Graphical User Interfaces (GUI), including Web programming. In GUI programming you will want to record properties of the form
+
+"When the user clicks this OK button, the system must update the file"
+
+
+each involves a '''control''' (here the OK button), an '''event''' (mouse click) and an '''operation''' (update the file). This can be programmed by having an "event loop", triggered for each event, which performs massive decision-making ( if "The latest event was `left mouse click on button 23'" then "Appropriate instructions" else if ... and so on with many branches); but this leads to bulky software architectures where introducing any new control or event requires updating a central part of the code. It's preferable to let any element of the system that encounters a new control-event-operation association
+
+[control, event, operation]
+
+
+store it as a triple of objects into an object structure, such as an array or a list. Triples in that structure may come from different parts of the system; there is no central know-it-all structure. The only central element is a simple mechanism which can explore the object structure to execute each operation associated with a certain control and a certain event . The mechanism is not just simple; it's also independent of your application, since it doesn't need to know about any particular control, event or operation (it will find them in the object structure). So it can be programmed once and for all, as part of a library such as EiffelVision 2 for platform-independent graphics.
+
+To build an object structure, we need objects. A control , an event are indeed objects. But an operation is not: it's program code -- a routine of a certain class.
+
+Agents address this issue. An agent is an object that represents a routine, which can then be kept in an object structure. The simplest form of agent is written agent r , where r is a routine. This denotes an object. If your_agent is such an agent object, the call
+
+your_agent.call ([a, b])
+
+
+where a and b are valid arguments for r , will have the same effect as a direct call to r with arguments a and b . Of course, if you know that you want to call r with those arguments, you don't need any agents; just use the direct call r ( a, b ) . The benefit of using an agent is that you can store it into an object structure to be called '''later''', for example when an event-driven mechanism finds the agent in the object structure, associated with a certain control and a certain event. For this reason agents are also called '''delayed calls'''.
+
+{{info|The notation [ a, b ] denotes a sequence of elements, or '''tuple'''. The reason call needs a tuple as argument, whereas the direct call r ( a, b ) doesn't, is that call is a general routine (from the EiffelBase class ROUTINE , representing agents) applicable to any agent, whereas the direct call refers explicitly to r and hence requires arguments a and b of specific types. The agent mechanism, however, is statically typed like the rest of the language; when you call call , the type checking mechanism ensures that the tuple you pass as argument contains elements a and b of the appropriate types. }}
+
+A typical use of agents with EiffelVision 2 is
+
+ok_button.select_actions.extend (agent your_routine)
+
+which says: "add your_routine to the list of operations to be performed whenever a select event (left click) happens on ok_button ". ok_button . select_actions is the list of agents associated with the button and the event; in list classes, procedure extend adds an item at the end of a list. Here, the object to be added is the agent.
+
+This enables the EiffelVision event-handling mechanism to find the appropriate agent when it processes an event, and call call on that agent to trigger the appropriate routine. EiffelVision doesn't know that it's your_routine ; in fact, it doesn't know anything about your application. It simply finds an agent in the list, and calls call on it. For your part, as the author of a graphical application, you don't need to know how EiffelVision handles events; you simply associate the desired agents with the desired controls and events, and let EiffelVision 2 do the rest.
+
+Agents extend to many areas beyond GUIs. In '''numerical computation''', you may use an agent to pass to an "integrator" object a numerical function to be integrated over a certain interval. In yet another area, you can use agents (as in the iteration library of EiffelBase) to program '''iterators''' : mechanisms that repetitively apply an arbitrary operation -- represented by an agent -- to every element of a list, tree or other object structure. More generally, agent embody properties of the associated routines, opening the way to mechanism for '''reflection''', also called "introspection": the ability, during software execution, to discover properties of the software itself.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki
new file mode 100644
index 00000000..a7189d16
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-exceptions.wiki
@@ -0,0 +1,47 @@
+[[Property:title|7 Exceptions]]
+[[Property:link_title|I2E: Exceptions]]
+[[Property:weight|-8]]
+Whenever there is a contract, the risk exists that someone will break it. This is where exceptions come in.
+
+Exceptions -- contract violations -- may arise from several causes. One is an assertion violation, if you've selected run-time assertion monitoring. Another is a signal triggered by the hardware or operating system to indicate an abnormal condition such as arithmetic overflow, or an attempt to create a new object when there's not enough memory available.
+
+Unless a routine has made specific provision to handle exceptions, it will '''fail''' if an exception arises during its execution. This in turn provides one more source of exceptions: a routine that fails triggers an exception in its caller.
+
+A routine may, however, handle an exception through a rescue clause. This optional clause attempts to "patch things up" by bringing the current object to a stable state (one satisfying the class invariant). Then it can terminate in either of two ways:
+* The rescue clause may execute a retry instruction, which causes the routine to restart its execution from the beginning, attempting again to fulfill its contract, usually through another strategy. This assumes that the instructions of the rescue clause, before the retry , have attempted to correct the cause of the exception.
+* If the rescue clause does not end with retry , then the routine fails: it returns to its caller, immediately triggering an exception. (The caller's rescue clause will be executed according to the same rules.)
+
+
+The principle is that '''a routine must either succeed or fail''': it either fulfills its contract, or not; in the latter case it must notify its caller by triggering an exception.
+
+Usually, only a few routines of a system will explicitly include a rescue clause. A routine that doesn't have an explicit rescue is considered to have an implicit one, which calls a routine default_rescue that by default does nothing, so that an exception will cause the routine to fail immediately, propagating the exception to the caller.
+
+An example using the exception mechanism is a routine attempt_transmission that tries to transmit a message over a phone line. The actual transmission is performed by an external, low-level routine transmit ; once started, however, transmit may abruptly fail, triggering an exception, if the line is disconnected. Routine attempt_transmission tries the transmission at most 50 times; before returning to its caller, it sets a boolean attribute successful to True or False depending on the outcome. Here is the text of the routine:
+
+attempt_transmission (message: STRING) is
+ -- Try to transmit message, at most 50 times.
+ -- Set successful accordingly.
+ local
+ failures: INTEGER
+ do
+ if failures < 50 then
+ transmit (message)
+ successful := True
+ else
+ successful := False
+ end
+ rescue
+ failures := failures + 1
+ retry
+ end
+
+
+Initialization rules ensure that failures , a local entity, is set to zero on entry.
+
+This example illustrates the simplicity of the mechanism: the rescue clause never attempts to achieve the routine's original intent; this is the sole responsibility of the body (the do clause). The only role of the rescue clause is to clean up the objects involved, and then either to fail or to retry.
+
+This disciplined exception mechanism is essential for software developers, who need protection against unexpected events, but cannot be expected to sacrifice safety and simplicity to pay for this protection.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki
new file mode 100644
index 00000000..9525baf5
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-genericity.wiki
@@ -0,0 +1,26 @@
+[[Property:title|9 Genericity]]
+[[Property:link_title|I2E: Genericity]]
+[[Property:weight|-6]]
+Building software components (classes) as implementations of abstract data types yields systems with a solid architecture but does not in itself ensure reusability and extendibility. Two key techniques address the problem: generosity (unconstrained or constrained) and inheritance. Let us look first at the unconstrained form.
+
+To make a class generic is to give it '''formal generic parameters''' representing as unknown types, as in these examples from EiffelBase, an open-source library covering basic data structures and algorithms:
+ARRAY [G]
+LIST [G]
+LINKED_LIST [G]
+
+These classes describe data structures -- arrays, lists without commitment to a specific representation, lists in linked representation -- containing objects of a certain type. The formal generic parameter G denotes this type.
+
+A class such as these doesn't quite yet describe a type, but a type template, since G itself denotes an unknown type. To derive a directly usable list or array type, you must provide a type corresponding to G , called an '''actual generic parameter'''; this may be either an expanded type, including basic types such as INTEGER , or a reference type. Here are some possible generic derivations:
+il: LIST [INTEGER]
+aa: ARRAY [ACCOUNT]
+aal: LIST [ARRAY [ACCOUNT]]
+
+As the last example indicates, an actual generic parameter may itself be generically derived.
+
+It would not be possible, without genericity, to have static type checking in a realistic object-oriented language.
+
+A variant of this mechanism, constrained genericity, will enable a class to place specific requirements on possible actual generic parameters. Constrained genericity will be described after inheritance.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki
new file mode 100644
index 00000000..6c7cc202
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-inheritance.wiki
@@ -0,0 +1,68 @@
+[[Property:title|10 Inheritance]]
+[[Property:link_title|I2E: Inheritance]]
+[[Property:weight|-5]]
+Inheritance, the other fundamental generalization mechanism, makes it possible to define a new class by combination and specialization of existing classes rather than from scratch.
+
+The following simple example, from the Data Structure Library in EiffelBase, is typical. LIST , as noted, describes lists in any representation. One such representation if the lists have a fixed number of elements uses an array. We may define the corresponding class by combination of LIST and ARRAY , as follows:
+
+class ARRAYED_LIST [G]
+ inherit
+ LIST [G]
+ ARRAY [G]
+
+ export ... See below ... end
+
+feature
+ ... Specific features of fixed-size lists ...
+
+end -- ARRAYED_LIST
+
+
+The inherit ... clause lists all the "parents" of the new class, which is said to be their "heir". (The "ancestors" of a class include the class itself, its parents, grandparents etc.; the reverse term is "descendant".) Declaring ARRAYED_LIST as shown ensures that all the features and properties of lists and arrays are applicable to arrayed lists as well. Since the class has more than one parent, this is a case of multiple inheritance.
+
+Standard graphical conventions -- drawn from the Business Object Notation or BON, a graphical object-oriented notation based on concepts close to those of Eiffel, and directly supported by EiffelStudio -- illustrate such inheritance structures:
+ [[Image:invitation-4]]
+An heir class such as ARRAYED_LIST needs the ability to define its own export policy. By default, inherited features keep their export status (publicly available, secret, available to selected classes only); but this may be changed in the heir. Here, for example, ARRAYED_LIST will export only the exported features of LIST , making those of ARRAY unavailable directly to ARRAYED_LIST 's clients. The syntax to achieve this is straightforward:
+
+class ARRAYED_LIST [G]
+ inherit
+ LIST [G]
+ ARRAY [G]
+
+ export {NONE} all end
+
+ ... The rest as above ...
+
+
+Another example of multiple inheritance comes from a windowing system based on a class WINDOW , close to actual classes in EiffelVision 2. Windows have '''graphical''' features: a height, a width, a position, routines to scale windows, move them, and other graphical operations. The system permits windows to be nested, so that a window also has '''hierarchical''' features: access to sub windows and the parent window, adding a sub window, deleting a sub window, attaching to another parent and so on. Rather than writing complex class that would contain specific implementations for all of these features, it is preferable to inherit all hierarchical features from TREE (a class in EiffelBase describing trees), and all graphical features from a class RECTANGLE .
+
+Inheritance complements the "client" relation by providing another form of reuse that yields remarkable economies of effort -- for analysis, design, implementation, evolution -- and has a profound effect on the entire software development process.
+
+The very power of inheritance demands adequate means to keep it under control. Multiple inheritance, in particular, raises the question of name conflicts between features inherited from different parents; this case will inevitably arise in practice, especially for classes contributed by independent developers. You may remove such a name conflict through '''renaming''', as in
+
+class C
+ inherit
+ A
+ rename
+ x as x1,
+ y as y1
+ end
+
+ B
+ rename
+ x as x2,
+ y as y2
+ end
+
+feature ...
+
+
+Here, if both A and B have features named x and y , class C would be invalid without the renaming.
+
+Renaming also serves to provide more appropriate feature names in descendants. For example, class WINDOW may inherit a routine insert_subtree from TREE . For clients of WINDOW , however, such a routine name is no longer appropriate. An application that uses this class needs coherent window terminology, and should have to concern itself with the inheritance structure that led to the class. So you may wish to rename insert_subtree as add_subwindow in the inheritance clause of WINDOW .
+
+As a further protection against misusing multiple inheritance, the invariants of all parent classes automatically apply to a newly defined class. So classes may not be combined if their invariants are incompatible.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki
new file mode 100644
index 00000000..6b00f809
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki
@@ -0,0 +1,65 @@
+[[Property:title|11 Polymorphism and Dynamic Binding]]
+[[Property:link_title|I2E: Polymorphism and Dynamic Binding]]
+[[Property:weight|-4]]
+Inheritance is not just a module combination and enrichment mechanism. It also enables the definition of flexible entities that may become attached to objects of various forms at run time, a property known as polymorphism.
+
+This remarkable facility must be reconciled with static typing. The language convention is simple: an assignment of the form a : b is permitted not only if a and b are of the same type, but more generally if a and b are of reference types A and B , based on classes A and B such that B is a descendant of A .
+
+This corresponds to the intuitive idea that a value of a more specialized type may be assigned to an entity of a less specialized type -- but not the reverse. (As an analogy, consider that if you request vegetables, getting green vegetables is fine, but if you ask for green vegetables, receiving a dish labeled just "vegetables" is not acceptable, as it could include, say, carrots.)
+
+What makes this possibility particularly powerful is the complementary facility: '''feature redefinition'''. A class may redefine some or all of the features which it inherits from its parents. For an attribute or function, the redefinition may affect the type, replacing the original by a descendant; for a routine it may also affect the implementation, replacing the original routine body by a new one.
+
+Assume for example a class POLYGON , describing polygons, whose features include an array of points representing the vertices and a function perimeter which computes a polygon's perimeter by summing the successive distances between adjacent vertices. An heir of POLYGON may begin as:
+
+class RECTANGLE
+ inherit
+ POLYGON
+ redefine
+ perimeter
+ end
+
+feature -- Specific features of rectangles, such as:
+
+ side1: REAL
+ side2: REAL
+
+ perimeter: REAL is
+ -- Rectangle-specific version
+ do
+ Result := 2 * (side1 + side2)
+ end
+
+... Other RECTANGLE features ...
+
+
+Here it is appropriate to redefine perimeter for rectangles as there is a simpler and more efficient algorithm. Note the explicit redefine sub clause (which would come after the rename if present).
+
+Other descendants of POLYGON may also have their own redefinitions of perimeter . The version to use in any call is determined by the run-time form of the target. Consider the following class fragment:
+p: POLYGON; r: RECTANGLE
+... create p; create r ...
+if c then
+ p := r
+end
+print (p.perimeter)
+
+The polymorphic assignment p := r is valid because of the above rule. If condition c is false, p will be attached to an object of type POLYGON for the computation of p . perimeter , which will thus use the polygon algorithm. In the opposite case, however, p will be attached to a rectangle; then the computation will use the version redefined for RECTANGLE . This is known as '''dynamic binding'''.
+
+Dynamic binding provides a high degree of flexibility. The advantage for clients is the ability to request an operation (such as perimeter computation) without explicitly selecting one of its variants; the choice only occurs at run-time. This is essential in large systems, where many variants may be available; dynamic binding protects each component against changes in other components.
+
+This technique is particularly attractive when compared to its closest equivalent in traditional approaches, where you would need records with variant components, or union types (C), together with case (switch) instructions to discriminate between variants. This means that every client must know about every possible case, and that any extension may invalidate a large body of existing software.
+
+The combination of inheritance, feature redefinition, polymorphism and dynamic binding supports a development mode in which every module is open and incremental. When you want to reuse an existing class but need to adapt it to a new context, you can define a new descendant of that class (with new features, redefined ones, or both) without any change to the original. This facility is of great importance in software development, an activity that -- by design or circumstance -- is invariably incremental.
+
+The power of these techniques demands adequate controls. First, feature redefinition, as seen above, is explicit. Second, because the language is typed, a compiler can check statically whether a feature application a . f is correct. In contrast, dynamically typed object-oriented languages defer checks until run-time and hope for the best: if an object "sends a message" to another (that is to say, calls one of its routines) one just expects that the corresponding class, or one of its ancestors, will happen to include an appropriate routine; if not, a run-time error will occur. Such errors will not happen during the execution of a type-checked Eiffel system.
+
+In other words, the language reconciles dynamic binding with static typing. Dynamic binding guarantees that whenever more than one version of a routine is applicable the right version (the one most directly adapted to the target object) will be selected. Static typing means that the compiler makes sure there is at least one such version.
+
+This policy also yields an important performance benefit: in contrast with the costly run-time searches that may be needed with dynamic typing (since a requested routine may not be defined in the class of the target object but inherited from a possibly remote ancestor), the EiffelStudio implementation always finds the appropriate routine in constant-bounded time.
+
+Assertions provide a further mechanism for controlling the power of redefinition. In the absence of specific precautions, redefinition may be dangerous: how can a client be sure that evaluation of p . perimeter will not in some cases return, say, the area? Preconditions and postconditions provide the answer by limiting the amount of freedom granted to eventual redefiners. The rule is that any redefined version must satisfy a weaker or equal precondition and ensure a stronger or equal postcondition than in the original. This means that it must stay within the semantic boundaries set by the original assertions.
+
+The rules on redefinition and assertions are part of the Design by Contract™ theory, where redefinition and dynamic binding introduce subcontracting. POLYGON , for example, subcontracts the implementation of perimeter to RECTANGLE when applied to any entity that is attached at run-time to a rectangle object. An honest subcontractor is bound to honor the contract accepted by the prime contractor. This means that it may not impose stronger requirements on the clients, but may accept more general requests: weaker precondition; and that it must achieve at least as much as promised by the prime contractor, but may achieve more: stronger postcondition.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki
new file mode 100644
index 00000000..df1e3b33
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-putting-system-together.wiki
@@ -0,0 +1,34 @@
+[[Property:title|14 Putting a System Together]]
+[[Property:link_title|I2E: Putting a System Together]]
+[[Property:weight|-1]]
+We have now studied the constituents of Eiffel software. It remains to see how you can combine these elements into executable '''systems''' (the Eiffel concept closest to the traditional notion of program) and libraries.
+
+How do you get an executable system? All you need is to
+* Provide a set of classes, called a '''universe'''.
+* Designate one of these classes as the '''root class'''.
+* Designate one of its creation procedures as the '''root procedure'''.
+
+
+This defines what it means to execute the system: create one direct instance of the root class (the execution's '''root object'''); and call the root procedure on it. That's all.
+
+In any practical case, the root procedure will create other objects, call other routines on them, leading to further creations and calls.
+
+For the system to be valid, it must include all the classes which the root '''needs''' directly or indirectly; a class "needs" another if it is one of its heirs or clients.
+
+For a library we don't need to specify a root. If we want to make sure that every class in a library compiles fine we can specify that we want all classes to be the root.
+
+The Eiffel method suggests grouping related classes (typically 5 to 40 classes) into collections called '''clusters'''. A universe is then a set of clusters. For example the EiffelBase library is divided into clusters corresponding each to a major category of data structure: lists , tables , iteration and so on. You can nest clusters, using for example EiffelBase, with its own subclusters as listed, as a cluster of your system.
+
+How will you specify a universe? Any Eiffel implementation can use its own conventions. EiffelStudio applies a simple policy:
+* Store each class in a single file, called its class file, with a name of the form name . e . For clarity, name should be the lower-case version of the class name, although this is a style rule, not a requirement.
+* Put all the class files of a cluster into a single directory (folder on Windows), called its cluster directory.
+{{note|It is desirable for clarity, as a style rule, to separate clusters that directly contain classes ("terminal clusters") from those that have subclusters. Cluster directories will then contain class files or cluster subdirectories, but not both. }}
+
+* To specify a system, it suffices to provide a list of cluster directories, along with the name of the root class and root procedure. The universe consists of the classes contained in all the class files in the listed cluster directories.
+
+
+Such a system specification is written in an ecf (eiffel configuration file) which is an xml based file format. It can be created by using the project settings in EiffelStudio.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki
new file mode 100644
index 00000000..da20602c
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-types.wiki
@@ -0,0 +1,20 @@
+[[Property:title|5 Types]]
+[[Property:link_title|I2E: Types]]
+[[Property:weight|-10]]
+Eiffel is strongly typed for readability and reliability. Every entity is declared of a certain type, which may be either a reference type or an expanded type.
+
+Any type T is based on a class, which defines the operations that will be applicable to instances of T . The difference between the two categories of type affects the semantics of an entity x declared of type T : for a reference type, the most common case, possible values for x are references to objects; for an expanded type, the values are objects. In both cases, the type rules guarantee that the objects will be instances of T .
+
+A non-expanded class such as ACCOUNT yields a reference type. As a result, an entity of type ACCOUNT , such as acc in the earlier client example (see the declaration of acc and the accompanying picture as given on page [[Invitation to Eiffel|6]] ), denotes possible run-time references to objects of type ACCOUNT .
+
+In contrast, the value of an entity acc declared of type expanded ACCOUNT is an object such as the one shown on the figure below, with no reference. The only difference with the earlier figure is that the value of acc is now an ACCOUNT object, not a reference to such an object. No creation instruction is needed in this case. (The figure does not show the PERSON object to which the owner field of the ACCOUNT object -- itself a reference -- is attached.)
+ [[Image:invitation-3]]
+An important group of expanded types, based on library classes, includes the basic types CHARACTER, DOUBLE, REAL, INTEGER and BOOLEAN . Clearly, the value of an entity declared of type INTEGER should be an integer, not a reference to an object containing an integer value. Operations on these types are defined by prefix and infix operators such as "+" and "<".
+
+As a result of these conventions, the type system is uniform and consistent: all types, including the basic types, are defined from classes, either as reference types or as expanded types.
+
+In the case of basic types, for obvious reasons of efficiency, the compilation mechanism implements the standard arithmetic and boolean operations directly through the corresponding machine operations, not through routine calls. But this is only a compiler optimization, which does not hamper the conceptual homogeneity of the type edifice.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki b/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki
new file mode 100644
index 00000000..debd18fe
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki
@@ -0,0 +1,10 @@
+[[Property:title|1 What Must I Know First?]]
+[[Property:link_title|I2E: What Must I Know First?]]
+[[Property:weight|-14]]
+This Invitation assumes that you have some experience of software development, but that's all. Previous exposure to object technology is not required. If you've had it, it will help; but if it has all been to notations like UML or programming languages like C++ and Java, you should not let it guide your study of this Invitation. Although Eiffel shares a number of properties with these other approaches, it takes a fresh path to object technology, based on a small number of simple, far-reaching concepts.
+
+Once you are familiar with the basic ideas you may want to try them with EiffelStudio, which provides a direct implementation of the Eiffel concepts, available in a completely portable way across Windows, Linux, many versions of Unix and VMS.
+
+
+
+
diff --git a/documentation/current/method/invitation-eiffel-i2e/index.wiki b/documentation/current/method/invitation-eiffel-i2e/index.wiki
new file mode 100644
index 00000000..abd053c4
--- /dev/null
+++ b/documentation/current/method/invitation-eiffel-i2e/index.wiki
@@ -0,0 +1,39 @@
+[[Property:title|Invitation to Eiffel]]
+[[Property:weight|-15]]
+==Interactive Software Engineering==
+
+[[MANUAL IDENTIFICATION AND COPYRIGHT: Invitation|MANUAL IDENTIFICATION AND COPYRIGHT]]
+
+{{note| This is '''not''' an introduction to the EiffelStudio development environment. See the [[Getting started with Eiffel| list of introductory documents ]] for a Guided Tour of EiffelStudio and a detailed Eiffel Tutorial. }}
+
+==[[1 What Must I Know First?|1 WHAT MUST I KNOW FIRST?]]==
+
+==[[2 Design Principles|2 DESIGN PRINCIPLES]]==
+
+==[[3 Object-Oriented Design|3 OBJECT-ORIENTED DESIGN]]==
+
+==[[4 Classes|4 CLASSES ]]==
+
+==[[5 Types|5 TYPES ]]==
+
+==[[6 Design by Contract and Assertions|6 DESIGN BY CONTRACT AND ASSERTIONS]]==
+
+==[[7 Exceptions|7 EXCEPTIONS]]==
+
+==[[8 Event-Driven Programming and Agents|8 EVENT-DRIVEN PROGRAMMING AND AGENTS]]==
+
+==[[9 Genericity|9 GENERICITY]]==
+
+==[[10 Inheritance|10 INHERITANCE ]]==
+
+==[[11 Polymorphism and Dynamic Binding|11 POLYMORPHISM AND DYNAMIC BINDING ]]==
+
+==[[12 Combining Genericity and Inheritance|12 COMBINING GENERICITY AND INHERITANCE ]]==
+
+==[[13 Deferred Classes and Seamless Development|13 DEFERRED CLASSES AND SEAMLESS DEVELOPMENT]]==
+
+==[[14 Putting a System Together|14 PUTTING A SYSTEM TOGETHER]]==
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/index.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/index.wiki
new file mode 100644
index 00000000..61cff1ae
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/index.wiki
@@ -0,0 +1,17 @@
+[[Property:title|EiffelCOM Content]]
+[[Property:link_title|EiffelCOM Interface Content]]
+[[Property:weight|-2]]
+The EiffelCOM library includes the following clusters:
+* A [[ref:libraries/com/reference/index|Constants]] cluster provides standard COM constants and enumerations.
+* A [[Interfaces|Interfaces]] cluster includes wrappers for standard interfaces that the EiffelCOM wizard does not generate and deferred classes: [[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]] , [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]] , and [[ref:libraries/com/reference/ecom_stub_chart|ECOM_STUB]] .
+* A [[Structures|Structures]] cluster includes wrappers for COM structures and additional data structures.
+* A [[ref:libraries/com/reference/index|Support]] cluster provides access to helper classes.
+
+{{seealso| '''See Also'''
+[[EiffelCOM|The Component Object Model]]
+[[EiffelCOM Wizard|EiffelCOM wizard]] }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/interfaces.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/interfaces.wiki
new file mode 100644
index 00000000..a595aa24
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/interfaces.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Interfaces]]
+[[Property:weight|0]]
+COM interfaces have several facets. First, an interface is a deferred, or an abstract, class. This means that an interface is a specification of a type. Second, an interface pointer represents a COM object, which is callable by a client application. An object can expose several interfaces, or represent several types.
+
+==ECOM_INTERFACE==
+
+For each interface listed in a type library, the EiffelCOM wizard generates a deferred class and two effective classes: a proxy of an interface pointer, or a client side class, and a stub of an interface pointer, or a server side class. The deferred interface class inherits from [libraries/com/reference/ecom_interface_chart.xml| ECOM_INTERFACE ] and has a deferred feature per each interface function. Both effective classes, or implemented interfaces, inherit from the deferred class and implement its functions. The functions of the interface proxy calls the underlying C layer, which in turn calls the COM component while the functions of the interface stub implement the component functionality.
+
+[[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]] holds a pointer to the underlying COM interface.
+
+==ECOM_QUERIABLE==
+
+Different languages handle type coercion in different ways. C uses type cast; C++ introduces several type casting mechanisms; Eiffel uses assignment attempt, etc. Every COM interface exposes the QueryInterface function which allows clients to query the COM component for a pointer to another interface. Querying a component for an interface pointer is similar to using an assignment attempt in Eiffel. The Eiffel implementation of the assignment attempt relies on the runtime data. Since changing the Eiffel runtime and the implementation of the assignment attempt was not an option, EiffelCOM introduces a library class [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]] , which has the creation routine
+
+ make_from_other (other: ECOM_INTERFACE)
+
+which queries a COM component internally. Every interface proxy class inherits from [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]] . The one difference between this mechanism versus using assignment attempt is that upon failure an exception will be raised. An assignment attempt that fails simply returns Void.
+
+==ECOM_STUB==
+
+[[ref:libraries/com/reference/ecom_stub_chart|ECOM_STUB]] inherits from [[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]] , and exposes the feature [[ref:libraries/com/reference/ecom_stub_chart|create_item]] which allows creating the underlying COM object.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/structures.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/structures.wiki
new file mode 100644
index 00000000..8ae66993
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/structures.wiki
@@ -0,0 +1,114 @@
+[[Property:title|Structures]]
+[[Property:weight|1]]
+The [[ref:libraries/com/reference/index|Structures]] cluster includes wrappers for data structures useful when using the COM technology.
+
+==ECOM_ARRAY==
+
+ECOM_ARRAY is a multidimensional, resizable array. It is converted to SAFEARRAY at the COM runtime level. Most languages only support SAFEARRAYs of OLE automation types.
+
+==ECOM_EXCEPTION==
+
+ECOM_EXCEPTION provides support for triggering and catching exceptions. According to the COM specification, every feature of a COM interface should return a status code of type HRESULT. HRESULT is a 32 bit integer. The COM specification defines possible exception codes and corresponding human-readable descriptions.
+
+The status code is mapped by the EiffelCOM runtime to Eiffel exceptions. To raise COM-specific exceptions, the class ECOM_EXCEPTION provides the feature trigger:
+
+ trigger (code: INTEGER)
+ -- Raise exception with code `code'.
+ -- See class ECOM_EXCEPTION_CODES for possible values.
+
+
+The class also has several features that help analyzing exceptions and error codes received from the COM runtime.
+
+ hresult: INTEGER
+ -- Original HRESULT.
+ require
+ applicable: is_developer_exception
+
+ hresult_code: INTEGER
+ -- Status code.
+ require
+ applicable: is_developer_exception
+
+ hresult_facility: INTEGER
+ -- Facility code.
+ require
+ applicable: is_developer_exception
+
+ hresult_message: STRING
+ -- Error message.
+ require
+ applicable: is_developer_exception
+
+
+Every call to COM should be wrapped into a rescue clause as follows:
+
+ some_feature is
+ local
+ retried: BOOLEAN
+ ...
+ do
+ if not retried then
+ -- Call to COM.
+ end
+ rescue
+ if is_developer_exception then
+ -- Compare `hresult' to some predefined value
+ -- and handle various cases,
+ -- or display a dialog box with an error message
+ -- `hresult_message'.
+ end
+ retried := True
+ retry
+ end
+
+
+==ECOM_STRUCTURE==
+
+ECOM_STRUCTURE is a deferred class which inherits from WEL_STRUCTURE. All wrappers of COM structures inherit from ECOM_STRUCTURE.
+
+==ECOM_VARIANT==
+
+ECOM_VARIANT is a wrapper of the VARIANT structure. VARIANT is the Visual Basic equivalent to Eiffel's ANY. In Visual Basic all variable types conform to VARIANT. Since the semantics and runtime architecture of Visual Basic are different from those of Eiffel, there is no simple way to map VARIANT to ANY. Instead, EiffelCOM provides an Eiffel wrapper around the VARIANT structure.
+
+This wrapper exposes the feature
+
+ variable_type: INTEGER
+ -- Variable type. See class ECOM_VAR_TYPE for possible values.
+
+
+which specifies the actual type of the variant. The class has multiple features for typed access and setting of variables.
+
+==ECOM_VARIANT_ACCESS==
+
+ECOM_VARIANT_ACCESS provides the feature:
+
+ missing: ECOM_VARIANT
+ -- Value representing the default value of a COM optional argument.
+ -- Equivalent to an omitted VB argument, or C++ vtMissing, or .NET System.Reflection.Missing.
+
+
+Many COM Automation servers have routines that take arguments with default values. This is very common, for example, in Microsoft Office applications such as Excel and Word. In Visual Basic, such arguments are optional and, when omitted, the server uses the default value. In languages that cannot omit arguments, a special VARIANT value representing the omitted argument must be passed. EiffelCOM applications can pass missing for this purpose.
+
+For example, the following adds a new workbook to Excel. The default argument tells Excel to decide for itself how many worksheets to put in the new workbook:
+
+ class
+ MY_EXCEL_APPLICATION
+
+ inherit
+ APPLICATION_PROXY
+
+ ECOM_VARIANT_ACCESS
+
+ feature
+
+ add_workbook is
+ local
+ workbook: WORKBOOK_PROXY
+ do
+ workbook := workbooks.add (missing, 0)
+ end
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/index.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/index.wiki
new file mode 100644
index 00000000..d7f00a0c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-library/index.wiki
@@ -0,0 +1,19 @@
+[[Property:title|EiffelCOM Library]]
+[[Property:weight|8]]
+Type: Library
+Platform: Windows
+
+
+See:
+* [[EiffelCOM Introduction|Introduction]]
+* [[EiffelCOM Content|Content]]
+* [[ref:libraries/com/reference/index|Reference]]
+
+{{seealso| '''See Also'''
+[[EiffelCOM|The Component Object Model]]
+[[EiffelCOM Wizard|EiffelCOM wizard]] }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/access-type.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/access-type.wiki
new file mode 100644
index 00000000..35ddcf1a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/access-type.wiki
@@ -0,0 +1,227 @@
+[[Property:title|Access Type]]
+[[Property:weight|5]]
+Regardless of its location, a COM components can be accessed either directly through interface's virtual table or through OLE Automation.
+==Automation==
+Accessing a COM component through Automation means using a well known interface to access to a group of methods and properties. This interface is called IDispatch, and it includes the method invoke that allows to call a method, set or get a property on the Automation server. One advantage of that approach is that the interface has a known virtual table layout. As a result, Windows can include a built-in marshaler for that interface (See [[Deeper into COM|Marshaling]] for information on what a marshaler is). The supported types (known as Automation types) and their Eiffel equivalents are listed in the following table:
+{|
+|-
+|
+COM Type
+
+|
+Eiffel equivalent
+
+|
+Description
+
+|-
+|
+VARIANT_BOOL
+
+|
+BOOLEAN
+
+|
+Standard boolean
+
+|-
+|
+unsigned char
+
+|
+CHARACTER
+
+|
+Standard character
+
+|-
+|
+double
+
+|
+DOUBLE
+
+|
+Standard double
+
+|-
+|
+float
+
+|
+REAL
+
+|
+2 bytes real
+
+|-
+|
+int
+
+|
+INTEGER
+
+|
+Standard integer
+
+|-
+|
+long
+
+|
+INTEGER
+
+|
+Standard integer
+
+|-
+|
+short
+
+|
+INTEGER
+
+|
+2 bytes integer
+
+|-
+|
+BSTR
+
+|
+STRING
+
+|
+Standard string
+
+|-
+|
+CURRENCY
+
+|
+ECOM_CURRENCY
+
+|
+Currency value
+
+|-
+|
+DATE
+
+|
+DATE_TIME
+
+|
+Standard date
+
+|-
+|
+SCODE
+
+|
+INTEGER
+
+|
+Return status
+
+|-
+|
+Interface IDispatch *
+
+|
+ECOM_INTERFACE
+
+|
+Automation interface
+
+|-
+|
+Interface IUnknown *
+
+|
+ECOM_INTERFACE
+
+|
+Generic interface
+
+|-
+|
+dispinterface
+
+|
+ECOM_INTERFACE
+
+|
+Automation interface
+
+|-
+|
+Coclass Typename
+
+|
+TYPE_NAME
+
+|
+Component main class
+
+|-
+|
+SAFEARRAY(TypeName)
+
+|
+ECOM_ARRAY [TypeName]
+
+|
+Array
+
+|-
+|
+TypeName*
+
+|
+CELL [TypeName]
+
+|
+Pointer to type
+
+|-
+| VARIANT
+| ECOM_VARIANT
+| Variant value
+|-
+| enum
+| INTEGER
+| Enumeration
+|-
+|
+Decimal
+
+|
+ECOM_DECIMAL
+
+|
+Decimal value
+
+|}
+The other advantage is a more dynamic discovery of the methods and properties of a component at runtime. Indeed the IDispatch interface also includes methods to check whether a method or property is available and, in that case, get its identifier. This process is called late binding and allows component to discover at runtime what are other components functionality.
+This approach has also a lot of drawbacks: first, late binding is not an efficient way of calling a function on an interface since its identifier must first be requested and then the function called. That's two round trips which can be expensive in a distributed environment. Second, since the marshaler is built-in, it has to know in advance all the possible types that a function can accept to be able to marshal the corresponding data. There are consequently a limitation on the number of types that one can use in signatures of functions on an Automation compatible interface. The set of available types is called Variant and cover most of the standard types. It does not allow however the passing of complex user defined data types. For these reasons Automation is mostly used in scripting environments (where speed is not an important factor) to accomplish simple tasks.
+
+==Direct Access==
+Direct interface access is the preferred way to access remote servers where speed becomes a concern and data types are specific to the application. The first interface pointer on the component is obtained through the class object (see [[Coclass|Class Object]] ). Other interfaces on the component are obtained by calling the QueryInterface function.
+As information on any interface cannot be accessed dynamically, the description of the interfaces must be provided to tools that need to handle the components such as the EiffelCOM wizard. The official way of describing components and interfaces is through IDL. Once an IDL file has been written to describe a component it can be compiled with MIDL to generate both a type library and the code for the marshaller specific to that interface.
+
+==EiffelCOM==
+The idea in EiffelCOM is the way a component is accessed is implementation detail that the user should not have to deal with. Of course he should be able to choose what kind of access he wants to use but this choice should have no impact on the design of the Eiffel system itself. For that reason, the Eiffel code generated by the wizard follows the same architecture independently of the choice made for interface access and marshalling. The difference lies in the runtime where the actual calls to the components are implemented.
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[EiffelCOM: Introduction| Introduction]]
+[[Generalities|Generalities]]
+[[COM Interfaces| COM Interfaces]]
+[[Coclass| Coclasses]]
+[[The Component Location| Component Location]]
+[[Deeper into COM| Deeper into COM]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki
new file mode 100644
index 00000000..b46c07f4
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Coclass]]
+[[Property:weight|3]]
+We have seen that interfaces can be perceived as views of a component. This conceptual representation actually maps the implementation of an EiffelCOM component since the coclass inherits from the interfaces and implements their deferred features. Indeed, interfaces are deferred classes with all features accessible from outside deferred. The coclass is an Eiffel class that inherits from these interfaces and implements all the features. This design is not specific to Eiffel though and can be found in other languages as well. The coclass defines the behavior of the interface functions.
+
+==Class Object==
+ We have seen that interfaces are accessed through interface pointers. But how does a client get hold on one of these?
+The answer lies in the class object. The name of this module should really be coclass factory since its goal is to spawn instances of the coclass on request. Class objects are accessed by COM whenever a client request a new instance of the associated component. COM loads the class object and asks it to provide the interface pointer requested by the client.
+
+The way a class object is loaded in memory (this process is called activation) depends on the location of the component (See [[The Component Location|Location]] for a description of the possible locations of a component). If the component is an in-process server then the class object is called directly through the functions exported from the DLL. If the component is an out-of-process server then it provides COM with a pointer to the class object. In both cases, once the component is loaded, COM has access to the class object and can call it would a client request a new instance of a component.
+ [[Image:com-1|Component Creation]]
+The code for the class object is generated by the EiffelCOM wizard so that Eiffel programmers will not have to worry about it.
+
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[EiffelCOM: Introduction| Introduction]]
+[[Generalities|Generalities]]
+[[COM Interfaces| COM Interfaces]]
+[[The Component Location| Component Location]]
+[[Access Type| Access Type]]
+[[Deeper into COM| Deeper into COM]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki
new file mode 100644
index 00000000..114e76f7
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Generalities]]
+[[Property:link_title|COM Concepts]]
+[[Property:weight|1]]
+COM is a binary standard that describes how the component can communicate with the outer-world. The component communicates through well defined interfaces. Each interface is a specification of a group of properties and methods, and it does not contain the implementation of these routines but only their specification (signatures). The actual implementation lies in the coclass. There can be different implementations of a same interface in different coclasses. Finally, each coclass can be instantiated using a class object or class factory. These three notions will be discussed further in the forthcoming paragraphs.
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[EiffelCOM: Introduction| Introduction]]
+[[COM Interfaces| COM Interfaces]]
+[[Coclass| Coclasses]]
+[[The Component Location| Component Location]]
+[[Access Type| Access Type]]
+[[Deeper into COM| Deeper into COM]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki
new file mode 100644
index 00000000..635117c0
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki
@@ -0,0 +1,23 @@
+[[Property:title|COM Interfaces]]
+[[Property:weight|2]]
+Interfaces are at the heart of any COM component. Interfaces are described in the definition file of a component. They consist of a group of semantically related functions that can be accessed by the clients of the component. Although they are a specification, they also have a physical representation. A client can request a pointer on an interface and access the component functions through that pointer. Interfaces are the only possible way to access functions from a component. They enforce information hiding by providing only the public functions to the client.
+
+Interfaces also define the type of a component. Each interface corresponds to a specific view of the component. It can be compared to polymorphism in the Object Oriented world. Whenever an interface from a component is requested, only the functions defined on that interface are accessible as if the component was polymorphically cast into an object of the type of that interface.
+
+The COM specification requires that any interface provides access to all interfaces on the same component. All interfaces should include a specific function called '''QueryInterface''' that will provide a pointer on any other interface of the component. Interfaces are identified with a globally unique identifier (GUID) guaranteed to be unique in time and space. Since this function has to be on every interface, it has been abstracted into a specific interface called '''IUnknown''' which all other interfaces must inherit from.
+
+The two other functions exposed by '''IUnknown''' are '''AddRef''' and '''Release'''. These functions should be called respectively when a client gets a reference on an interface or when it discards that reference. These two functions define the lifetime of the component: each interface keeps track of clients keeping a reference on them and when no clients have references anymore, the component can be unloaded from memory. You might start worrying thinking that this business of reference counting will imply lots of headaches, memory leaks, etc. and you would be right should you choose a low-level language to implement your components. Fortunately, you will never have to implement or use these functions in Eiffel: all the processing related to IUnknown is provided by the EiffelCOM runtime. Calls to '''QueryInterface''' are done "behind the scene" and only when needed. The lifetime of the component is also taken care of by the EiffelCOM runtime.
+
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[EiffelCOM: Introduction| Introduction]]
+[[Generalities|Generalities]]
+[[Coclass| Coclasses]]
+[[The Component Location| Component Location]]
+[[Access Type| Access Type]]
+[[Deeper into COM| Deeper into COM]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki
new file mode 100644
index 00000000..5cab58d0
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki
@@ -0,0 +1,24 @@
+[[Property:title|The Component Location]]
+[[Property:weight|4]]
+
+==Types of Components==
+ ActiveX, DirectX, OCX, COM+, ADO+, ASP etc. who never heard of these technologies? They all represent yet another use of the COM standard. This paragraph will focus on categorizing COM components according to their own properties as well as the context in which they are used. The categorization will define how the EiffelCOM wizard should be used to wrap or create a component.
The first criteria that defines the type of component is from where it will be accessed: will the component be loaded in the client process or will the component be a remote server for a distributed application? In the former case, the component is compiled as a Dynamic Link Libraries (DLL) while in the latter case it is a standard executable.
+==In-process Components==
+Typical instances of DLL components are found in technologies such as OCX, ActiveX, or ASP. These are small, downloadable binaries that will be loaded and executed in a container. The container acts as a client of the component. The EiffelCOM wizard provides the ability to wrap such components by providing access to its interface to any Eiffel container. It is also possible to create a new In-process component in Eiffel.
+One main difference with out-of-process components (other than the nature of the module, DLL versus executable) is the way in-process components are activated. In the case of out-of-process components, the component will specify COM when it is ready to receive calls from client. In the case of an in-process server the call is coming directly from COM: COM first loads the DLL into the client process and then calls the exported function DllGetClassObject to access the component class object. The other three exported functions of an in-process component are DllRegister to register the component in the Windows registry, DllUnregister to unregister the component from the registry and finally DllCanUnloadNow which gets called by COM whenever it tries to unload the component from memory. These four functions must be accessible from outside the DLL for the in-process component to work properly.
+
+==Out-of-process Components==
+These components are standard executable acting as servers that can be accessed locally or over a network. Typically used in a three tier client server architecture, the major difference with in-process servers (other than the module type - executable instead of DLL) is their lifetime. In-process components are typically loaded to achieve a specific task and unloaded just after while out-of-process components are servers supposed to run continuously. The EiffelCOM wizard allows to build clients for such servers in Eiffel. It also provides the ability to create such servers.
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[EiffelCOM: Introduction| Introduction]]
+[[Generalities|Generalities]]
+[[COM Interfaces| COM Interfaces]]
+[[Coclass| Coclasses]]
+[[Access Type| Access Type]]
+[[Deeper into COM| Deeper into COM]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki
new file mode 100644
index 00000000..b2533acb
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki
@@ -0,0 +1,21 @@
+[[Property:title|EiffelCOM: Introduction]]
+[[Property:weight|0]]
+This chapter covers enough information about COM for Eiffel developers to use the EiffelCOM wizard in an effective way. It does not cover all of COM since it would require an entire book but presents the main concepts needed to understand how to build an EiffelCOM system.
+
+Briefly said, the Component Object Model is a Microsoft binary standard that establishes how two binary units can access each other at runtime. Such binary units can run in the same process, in different processes on the same machine, or even on different machines. Components can be implemented in any language as long as the compiler produces COM standard compliant binaries.
+
+The advantages of such an approach include an increased reusability (binary reuse), a better version management (COM standard implies that new component versions are compatible with the older ones) and a built-in runtime environment. The binary reuse aspect of COM added with the source reuse ability of Eiffel offer the developer an ideal platform to increase considerably their productivity.
+
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]]
+[[Generalities| Generalities]]
+[[COM Interfaces| COM Interfaces]]
+[[Coclass| Coclasses]]
+[[The Component Location| Component Location]]
+[[Access Type| Access Type]]
+[[Deeper into COM| Deeper into COM]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki
new file mode 100644
index 00000000..4c42cbed
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki
@@ -0,0 +1,18 @@
+[[Property:title|EiffelCOM]]
+[[Property:link_title|COM and Eiffel]]
+[[Property:weight|-15]]
+* [[EiffelCOM: Introduction|Introduction]]
+* [[Generalities|Generalities]]
+* [[COM Interfaces|Interfaces]]
+* [[Coclass|Coclasses]]
+* [[The Component Location|Component Location]]
+* [[Access Type|Access Type]]
+* [[Deeper into COM|Deeper into COM]]
+
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library| EiffelCOM library]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/accessing-com-component.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/accessing-com-component.wiki
new file mode 100644
index 00000000..71771e20
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/accessing-com-component.wiki
@@ -0,0 +1,34 @@
+[[Property:title|Accessing a COM component]]
+[[Property:link_title|Accessing a COM Component]]
+[[Property:weight|2]]
+The third tutorial describes how to access a COM component. It will build a client of the StringManipulator component built in the first tutorial.
+==Step by step instructions==
+# In '''Project''', in the '''Current project''' input field, type in ''string_manipulator_client'' and press '''enter'''.
+# In '''Project Type''', choose ''Access an existing COM component''.
+# In '''Component Information''', click the browse button (the button with '''...''') and open the file ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\string_manipulator.idl'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio installation directory.
+# Click '''Next'''.
+# In '''Component Type''', choose ''In-process (*.dll)''.
+# In '''Generation Options''', click the browse button and select the directory where the project should be created (later referenced as ''destination folder''). Choose ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\client'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio directory.
+# Make sure both '''Compile C code''' and '''Compile Eiffel code''' are checked.
+# Select '''Overwrite existing files'''.
+# Click '''Generate'''.
+# Wait until the wizard is done.
+
+==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 STRING_MANIPULATOR_PROXY. 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 StringManipulator 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 MY_STRING_MANIPULATOR inherits from the generated STRING_MANIPULATOR_PROXY 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. }}
+
+==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 MY_STRING_MANIPULATOR includes has some assertions.: Comment them out. Now the contract of the [[ref:libraries/base/reference/string_8_chart|replace_substring]] 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.
+{{seealso| '''See Also'''
+[[Creating a new COM component|Creating a new COM component]]
+[[Creating a new component from an Eiffel project|Creating a new component from an Eiffel Project]] }}
+
+
+
+
+
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
new file mode 100644
index 00000000..fed91737
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki
@@ -0,0 +1,44 @@
+[[Property:title|Creating a new COM component]]
+[[Property:link_title|Creating a New COM Component]]
+[[Property:weight|0]]
+This first tutorial describes creating a COM component from a COM definition file that is either an IDL file or a Type Library. The tutorial focuses on creating an in-process (DLL) component, called StringManipulator. The component exposes one interface IString that includes the functions ReplaceSubstring and PruneAll corresponding respectively to the features [[ref:libraries/base/reference/string_8_chart|replace_substring]] and [[ref:libraries/base/reference/string_8_chart|prune_all]] of the class [[ref:libraries/base/reference/string_8_chart| STRING ]] from the EiffelBase library. IString also exposes the property String which represents the manipulated string. The property can be set or read.
+==Step by step instructions==
+# In '''Project''', in the '''Current project''' input field, type in ''string_manipulator_server'' and press '''enter'''.
+# In '''Project Type''', choose ''Create a new COM component''.
+# In '''Component Information''', click the browse button (the button with '''...''') and open the file ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\string_manipulator.idl'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio installation directory.
+# Make sure '''Generate and use marshaller DLL''' is not checked.
+# Click '''Next'''.
+# In '''Component Type''', choose ''In-process (*.dll)''.
+# In '''Generation Options''', click the browse button and select the directory where the project should be created (later referenced as ''destination folder''). Choose ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio directory.
+# Make sure both '''Compile C code''' and '''Compile Eiffel code''' are checked.
+# Make sure '''Clean destination folder prior to generation''' is selected.
+# Click '''Generate'''.
+# Wait until the wizard is done.
+
+==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.
+
+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.
+==Running the component==
+The component needs to be registered prior to being loaded. Register an out-of-process component using the following syntax:
+
+system_name.exe -Regserver
+where ''system_name'' is the name of the component executable file. Register an in-process component using the ''regsvr32'' utility using the following syntax:
+
+regsvr32 system_name.dll
+where ''system_name'' is the name of the dll (e.g. string_manipulator). So to register the StringManipulator component, run:
+
+cd $ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component\server\EIFGENs\default\W_code
+regsvr32 string_manipulator.dll
+Once registered, follow the steps described in [[Accessing a COM component|Accessing a COM component]] to build the component's client.
+{{seealso| '''See Also'''
+[[Creating a new component from an Eiffel project|Creating a new component from an Eiffel Project]]
+[[Accessing a COM component|Accessing a COM component.]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-component-eiffel-project.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-component-eiffel-project.wiki
new file mode 100644
index 00000000..9e66b345
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-component-eiffel-project.wiki
@@ -0,0 +1,43 @@
+[[Property:title|Creating a new component from an Eiffel project]]
+[[Property:weight|1]]
+The second tutorial describes creating a COM component from an Eiffel system. The tutorial example String is almost identical to StringManipulator of the previous tutorial. In the StringManipulator example the wizard starts from an IDL file and builds an Eiffel System; in contrast, the String example takes an Eiffel system and generates an IDL file and the required plumbing code to make the Eiffel project accessible to COM.
+
+==Step by step instructions==
+# Create a new Eiffel project in the directory ''$ISE_EIFFEL\examples\com\wizard\e2idl\eproject'' where $ISE_EIFFEL represents the path to the EiffelStudio installation directory.
+# Select the ECF file located in the same directory and compile.
+# Start the EiffelCOM Wizard
+# In '''Project''', in the '''Current project''' input field, type in ''string'' and press '''enter'''.
+# In '''Project Type''', choose ''Add a COM interface to an existing Eiffel project''.
+# In the field under '''Path to Eiffel project location''' enter ''$ISE_EIFFEL\examples\com\wizard\e2idl\eproject''.
+# Click the browse button under '''Path to system's configuration file (*.ecf)''' and open the file ''$ISE_EIFFEL\examples\com\wizard\e2idl\eproject\string.ecf''.
+# In the text field under '''Target to use''', enter: ''string''.
+# In the text field under '''Name of Eiffel facade class''', enter: string_manipulator.
+# In the text field under '''Name of Eiffel facade class cluster''', enter: root_cluster.
+# Click '''Next'''.
+# In '''Component Type''', choose ''In-process (*.dll)''.
+# In '''Generation Options''', click the browse button and select the directory where the project should be created. Choose ''$ISE_EIFFEL\examples\com\wizard\e2idl\generated''.
+# Make sure both '''Compile C code''' and '''Compile Eiffel code''' are checked.
+# Make sure '''Clean destination folder prior to generation''' is selected.
+# Click '''Generate'''.
+# Wait until the wizard is done.
+
+==First look at the generated code==
+
+The generated Eiffel classes include:
+* ISTRING_MANIPULATOR_INTERFACE: This class represents the only interface exposed by the COM component.
+* STRING_MANIPULATOR_PROXY_IMP: This class implements the coclass, it inherits from the interface and implements its members.
+* ECOM_STRING_REGISTRATION: 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''':
+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'''
+[[Creating a new COM component|Creating a new COM component]]
+[[Accessing a COM component|Accessing a COM component.]] }}
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/index.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/index.wiki
new file mode 100644
index 00000000..28981ac8
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|EiffelCOM Wizard Guided Tour]]
+[[Property:weight|-13]]
+This chapter explains how to use the EiffelCOM wizard to create COM components and to access existing components.
+* [[Creating a new COM component|Creating a new COM component]] .
+* [[Creating a new component from an Eiffel project|Creating a new component from an Eiffel Project.]]
+* [[Accessing a COM component|Accessing a COM component.]]
+
+
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard Introduction|Introduction]]
+[[EiffelCOM Wizard Reference|EiffelCOM wizard reference]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-introduction.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-introduction.wiki
new file mode 100644
index 00000000..6896f85d
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-introduction.wiki
@@ -0,0 +1,19 @@
+[[Property:title|EiffelCOM Wizard Introduction]]
+[[Property:weight|-14]]
+The COM standard allows software components written in different languages to communicate with each other. However, building COM compliant applications requires the development of a large amount of code only dedicated to supporting the technology. The EiffelCOM wizard was designed to free Eiffel developers from having to write the plumbing code.
+
+The EiffelCOM wizard is a powerful tool that enables the fast development of COM components in Eiffel and accessing COM components from Eiffel systems. It consists of a series of input fields, which ask about the component's characteristics. The wizard needs the data to produce an Eiffel system skeleton, the code to access or create a component, and the component-specific runtime libraries.
+
+The wizard allows Eiffel developers with little COM knowledge to develop and reuse COM components. The design of the generated code follows the Eiffel standards and will be familiar to experienced Eiffel users. The only prerequisite to use the EiffelCOM wizard is an understanding of the '''Interface Definition Language'''. '''IDL''' describes a component. Compilers can generate '''Type Libraries''' from IDL files. Tools that need information on a given component, such as the EiffelCOM wizard, Visual Basic, etc. will analyze the Type Libraries. The IDL syntax is very close to C so should be easy to learn for developers that are familiar with this language.
+
+The wizard generates code from a Type Library and additional information given by the user. The generated code consists of Eiffel classes, C/C++ files, and library files. The wizard automatically produces library files from generated C and C++ code. You do not need to modify generated C/C++ code to build your EiffelCOM system.
+
+==Code Generation Process==
+ [[Image:introduction]]
+The wizard can automatically compile the generated C and Eiffel code. To produce a Type Library corresponding to a given IDL file the wizard relies on '''MIDL''', the Microsoft IDL compiler. You may also provide the wizard with a Type Library directly. The wizard can also be used to add a COM interface to an existing Eiffel project. For the rest of the manual a '''COM Definition File''' will refer to the input file given to the wizard (either an IDL file, a Type Library or an Eiffel project file).
+
+{{seealso| '''See Also''': [[EiffelCOM Wizard Guided Tour|Guided Tour]] , [[EiffelCOM Wizard Reference|EiffelCOM wizard reference]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/building-com-component.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/building-com-component.wiki
new file mode 100644
index 00000000..81b766bb
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/building-com-component.wiki
@@ -0,0 +1,70 @@
+[[Property:title|Building a COM Component]]
+[[Property:weight|5]]
+The EiffelCOM wizard allows for the development of both in-process (DLLs) and out-of-process (EXEs) COM components in Eiffel.
+
+==Using the Generated Code==
+
+If the project consists of adding a COM interface to an existing Eiffel project then the wizard will generate (and optionally compile) everything required to implement the COM component. No extra work is required.
+
+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. }}
+
+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 ECOM__REGISTRATION. If the component is in-process then this class includes the four functions that need to be exported from an in-process COM component ( DllRegisterServer, DllUnregisterServer, DllGetClassObject, and DllCanUnloadNow). If the component is out-of-process then the registration class includes a feature initializing the component and its graphical user interface.
+
+The architecture of the generated code is similar to the one used by the code generated to access an existing component: classes corresponding to the component's coclasses inherit from classes corresponding to the component's interfaces and implement all the deferred features. There is however a major difference: the classes corresponding to the component's coclasses should '''not''' be inherited from. Instead their implementation should be completed. Putting the implementation in a heir class would cause a runtime failure since the EiffelCOM generated code will instantiate the class corresponding to the component's coclass when being called rather than any descendant that would actually contain the implementation. The classes corresponding to the component's coclasses are all suffixed with _COCLASS_IMP.
+
+==Component's GUI==
+
+In the case of an out-of-process server, the component might need a Graphical User Interface. There are two different scenarios in which the component can be activated: either its user launched it explicitly (e.g. by double clicking the executable icon) or it was launched by the COM runtime to satisfy a client request. In some cases it might be required for the component to have a different behavior in these two cases (for example the GUI could only be necessary when the component was launched explicitly by the user but should be hidden when launched by the COM runtime). The generated registration class for an out-of-process server includes the feature:
+
+main_window: WEL_FRAME_WINDOW
+
+This feature is a once function that can return the class corresponding to the component window. By default, this window is displayed only if COM does not start the component. When COM loads an out-of-process component, it appends the command line parameter "-embedding" to the executable. The generated registration class looks for this option and if it is part of the process argument list then it sets the default window appearance to hidden. Of course this default implementation may be modified if needed.
+
+==Exceptions==
+
+The COM standard specifies that each COM routine should return a status code to the client. The status code is encoded in a HRESULT value. Such behavior goes against the Command Query Separation Principle in Eiffel. The EiffelCOM generated system should use exceptions instead of returning HRESULT values to the client. By default the EiffelCOM runtime will always return S_OK 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 ECOM_EXCEPTION using the feature trigger from the same class. The EiffelCOM runtime will catch the exception and send the corresponding HRESULT back to the client. Here is what the Eiffel code for a COM component should look like:
+
+indexing
+ description: "Eiffel coclass server example"
+class
+ ECOM_SERVER_COCLASS_IMP
+
+inherit
+ ECOM_SERVER_COCLASS -- Generated by the wizard
+
+ ECOM_EXCEPTION
+ export
+ {NONE} all
+ end
+
+feature -- Basic Operations
+
+ coclass_feature (an_argument: ARGUMENT_TYPE) is
+ -- Example of a coclass feature
+ do
+ if not is_valid (an_argument) then
+ trigger (E_invalidargument)
+ else
+ -- Normal processing
+ end
+ end
+
+feature {NONE} -- Implementation
+
+ is_valid (an_argument: ARGUMENT_TYPE): BOOLEAN is
+ -- Is an_argument a valid argument?
+ do
+ -- Test of validity of an_argument
+ end
+
+end -- class ECOM_SERVER_COCLASS_IMP
+
+This class inherits from the generated Eiffel coclass and from ECOM_EXCEPTION. It redefines the feature coclass_feature from the generated coclass. This feature is part of the interface functions that can be called by clients of the component. Its implementation uses the featuretrigger from ECOM_EXCEPTION to raise exceptions in case the feature cannot be executed normally (invalid argument). The EiffelCOM runtime catches the exception and maps it into an HRESULT that is sent back to the client.
+
+{{seealso| '''See Also''': [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[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]] , [[Wizards: Command Line Options|Command Line Options]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/class-hierarchy.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/class-hierarchy.wiki
new file mode 100644
index 00000000..4b528b74
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/class-hierarchy.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Class Hierarchy]]
+[[Property:weight|2]]
+The generated Eiffel code reflects the architecture of the component described in the definition file. Each interface corresponds to a deferred Eiffel class that includes one deferred feature per interface function. The deferred features are implemented in heirs of the interface class. Classes inheriting from these interfaces implement either a coclass or an implemented interface (that is an interface whose instance might be used as an argument on one of the component interfaces functions).
+ [[Image:interface-inheritance]]
+In a project accessing an existing component, the Eiffel classes corresponding to component coclasses inherit from the class [[ref:libraries/com/reference/ecom_queriable_chart| ECOM_QUERIABLE ]] , which is part of the EiffelCOM library. This class includes the feature make_from_other which allows initializing the component from another instance of [[ref:libraries/com/reference/ecom_interface_chart| ECOM_INTERFACE ]] .
+ [[Image:interface-inheritance-server]]
+In a project implementing a new component, the Eiffel classes corresponding to component coclasses inherit from the class [[ref:libraries/com/reference/ecom_stub_chart| ECOM_STUB ]] , which is part of the EiffelCOM library. This class includes the feature [[ref:libraries/com/reference/ecom_stub_chart]] which allows initializing the component.
+
+The '''Interface_proxy''' folder includes Eiffel classes wrapping interfaces that may be returned by functions on other interfaces. These classes inherit from both the deferred interface class located in '''Common\Interfaces''' and [[ref:libraries/com/reference/ecom_queriable_chart| ECOM_QUERIABLE ]] .
+ [[Image:implemented-interface]]
+The '''Interface_stub''' folder includes Eiffel classes implementing interfaces that may be given to the component as an argument. These classes inherit from both the deferred interface class and [[ref:libraries/com/reference/ecom_stub_chart| ECOM_STUB ]] .
+ [[Image:implemented-interface-server]]
+{{seealso| '''See Also''': [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[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]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/eiffel-project-processing.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/eiffel-project-processing.wiki
new file mode 100644
index 00000000..7c6c04a1
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/eiffel-project-processing.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Eiffel Project Processing]]
+[[Property:weight|3]]
+The EiffelCOM Wizard can be used to add a COM interface to an existing Eiffel project. The advantage of that approach is that it doesn't require any knowledge about IDL. The EiffelCOM Wizard will take care of generating the IDL from the Eiffel facade class. The generated IDL will define one coclass containing one interface that corresponds to the contract view of the facade class.
+
+==Designing the Facade Class==
+
+The facade class should be designed so that it exposes the functionality of the Eiffel system that needs to be accessed from clients of the component. Only the public routines will be exported to the IDL and thus to clients (the class should not have any public attributes, see the list of requirements below).
+
+There are some rules that the facade class must follow for the COM wizard to be able to generate correct IDL:
+* The facade class must have a creation procedure called make that does not take any argument. This is the procedure that will be called by the EiffelCOM runtime to initialize the Eiffel object when a COM call arrives from a client.
+* The arguments and objects returned by the public routines of the facade class must be of one of the following types: [[ref:libraries/base/reference/character_8_chart| CHARACTER_8 ]] , [[ref:libraries/base/reference/integer_32_chart| INTEGER_32 ]] , [[ref:libraries/base/reference/real_32_chart| REAL_32 ]] , [[ref:libraries/base/reference/real_64_chart| REAL_64 ]] , [[ref:libraries/base/reference/boolean_chart| BOOLEAN ]] , [[ref:libraries/base/reference/integer_32_ref_chart| INTEGER_32_REF ]] , [[ref:libraries/base/reference/boolean_ref_chart| BOOLEAN_REF ]] , [[ref:libraries/base/reference/real_32_ref_chart| REAL_32_REF ]] , [[ref:libraries/base/reference/character_8_ref_chart| CHARACTER_8_REF ]] , [[ref:libraries/base/reference/real_64_ref_chart| REAL_64_REF ]] , [[ref:libraries/base/reference/string_8_chart| STRING_8 ]] , [[ref:libraries/com/reference/ecom_currency_chart| ECOM_CURRENCY ]] , [[ref:libraries/com/reference/ecom_decimal_chart| ECOM_DECIMAL ]] , [[ref:libraries/com/reference/ecom_interface_chart]] , or [[ref:libraries/com/reference/ecom_array_chart]] . Features with arguments or return objects that are of a type not in this list are excluded from the generated IDL file and are not accessible to clients.
+* The facade class should not contain any public attribute, only routines can be exported to COM clients.
+* The facade class must belong to a successfully compiled Eiffel project.
+
+{{seealso| '''See Also''': [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Accessing a COM component|Accessing a COM Component]] , [[Reusing a COM Component|Reusing a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/generated-files.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/generated-files.wiki
new file mode 100644
index 00000000..0e11ef44
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/generated-files.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Generated Files]]
+[[Property:weight|1]]
+The EiffelCOM Wizard generates code into the specified destination folder. The file hierarchy is the following:
+ [[Image:folders]]
+* The '''Client''' folder includes all the files used to access a COM component. The subfolders '''Clib''' and '''Include''' contain respectively the C++ source files and header files. The subfolder '''Component''' contains the Eiffel classes corresponding to the component's coclasses. Finally the subfolder '''Interface_proxy''' contains classes wrapping interfaces that may be returned by functions of the component. These classes may be of interest for systems implementing a new COM component as well. The '''Client''' folder also contains a ECF file that can be used to precompile the generated Eiffel classes if the project consists of accessing an existing component. It is also possible to directly use the ECF file as a library in an existing project.
+* The '''Common''' folder includes classes that are useful both when accessing and implementing a COM component. It includes the usual C++ folders as well as the '''Interfaces''' and '''Structures''' folders. The '''Interfaces''' folder contains Eiffel classes corresponding to COM interfaces. These are deferred classes that only define the signature of the COM interfaces members. The '''Structures''' folder contains Eiffel classes wrapping any structure defined in the COM definition file (IDL or type library).
+* Optionally, the EiffelCOM Wizard may generate a '''idl''' folder which contains the IDL file generated from the Eiffel facade class if the project consists of adding a COM interface to an existing Eiffel project.
+* The '''Server''' folder includes files used to implement a COM component. Apart from the usual C++ folders, it also includes a '''Component''' folder which contains Eiffel classes corresponding to the component's coclasses and a '''Interface_stub''' folder which contains Eiffel classes wrapping interfaces that may be given as argument to the component. This last folder may also be useful when accessing a COM component. The '''Server''' folder also includes a ECF file which can be used to compile the generated system if the project consists of creating a new component.
+
+{{seealso| '''See Also''': [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[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]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/how-eiffelcom-wizard-works.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/how-eiffelcom-wizard-works.wiki
new file mode 100644
index 00000000..07dfd137
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/how-eiffelcom-wizard-works.wiki
@@ -0,0 +1,19 @@
+[[Property:title|How the EiffelCOM Wizard works]]
+[[Property:weight|0]]
+Depending on the project settings there are between 2 and 6 major steps involved when generating the Eiffel system:
+* '''IDL Generation''': If the project consists of adding a COM interface to an existing Eiffel project, the first step accomplished by the EiffelCOM Wizard consists of generating an IDL file from the specified facade class (see [[Eiffel Project Processing|Adding a COM interface to an Eiffel project]] for additional details).
+* '''IDL Compilation''': If the project uses an IDL file (whether it was specified or the result of processing a facade class from an existing Eiffel project), the EiffelCOM Wizard then compiles it into a type library.
+* '''Type Library Parsing''': The EiffelCOM Wizard then analyzes the type library (whether it was specified in the settings or is the result of an IDL file compilation) and stores the information it needs to generate the code into an internal representation.
+* '''Code Generation''': The EiffelCOM wizard generates both the Eiffel and C/C++ code from the information gathered during the previous step (see [[Generated Files|Generated Files]] for a list of generated files)
+* '''C/C++ Compilation''': If specified in the project settings, the EiffelCOM Wizard then compiles the generated C and C++ code into object files and libraries that will be linked into the Eiffel system.
+* '''Eiffel Compilation''': If the project consists of accessing an existing component then the EiffelCOM Wizard compiles the generated Eiffel code into a precompiled library that contains all the generated classes. If the project consists of creating a new component then the EiffelCOM Wizard compiles the generated Eiffel code into a standard project using the registration class as root class.
+
+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. }}
+
+{{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]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/index.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/index.wiki
new file mode 100644
index 00000000..de5eafae
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/index.wiki
@@ -0,0 +1,18 @@
+[[Property:title|EiffelCOM Wizard Reference]]
+[[Property:weight|-12]]
+The EiffelCOM Wizard allows the creation of Eiffel projects implementing or reusing COM components.
+* [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard works]] describes the steps followed by the wizard when creating the Eiffel project.
+* [[Generated Files|Generated Files]] describes the list of generated files and their usage.
+* [[Class Hierarchy|Class Hierarchy]] describes the class hierarchy of the generated Eiffel project.
+* [[Eiffel Project Processing|Eiffel Project Processing]] covers how to add a COM interface to an existing EiffelStudio project.
+* [[Reusing a COM Component|Accessing a COM Component]] describes how to reuse an existing COM component.
+* [[Building a COM Component|Building a COM Component]] describes how to build a new COM component.
+* [[Wizards: Command Line Options|Command Line Options]] describes using the wizard from the command line.
+
+{{seealso| '''See Also'''
+[[EiffelCOM Wizard Introduction|Introduction]]
+[[EiffelCOM Wizard Guided Tour|Guided Tour]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/reusing-com-component.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/reusing-com-component.wiki
new file mode 100644
index 00000000..4f18c3f8
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/reusing-com-component.wiki
@@ -0,0 +1,93 @@
+[[Property:title|Reusing a COM Component]]
+[[Property:weight|4]]
+The wizard generates the necessary code to access the existing component. The plumbing is already done so that instantiating an Eiffel class corresponding to one of the component's coclasses automatically calls the right COM initialization APIs.
+
+==Using the Generated Code==
+
+Calling a feature on an Eiffel class corresponding to one of the component's coclasses forwards the call to the member on the corresponding interface. The data types of the function arguments are either Eiffel types defined in Eiffel data structure libraries, standard data types defined in the EiffelCOM library, or custom data types declared in the COM definition file. For example, from the following IDL line:
+
+HRESULT Function ([in] int a, [out, retval] MyStruct * b)
+
+The wizard generates the following feature:
+
+function (a: INTEGER): MY_STRUCT_RECORD
+
+where MY_STRUCT_RECORD is a generated Eiffel wrapper around the IDL defined structure MyStruct. Structures represent one case of custom data types, interfaces represent another so for the following IDL:
+
+HRESULT Function ([in] ISomething * pInterface)
+
+The wizard generates the following Eiffel feature:
+
+function (p_interface: ISOMETHING_INTERFACE)
+
+where ISOMETHING_INTERFACE is a generated deferred class corresponding to the ISomething interface. Calling function requires passing an instance of a type that implements ISOMETHING_INTERFACE. The '''stubs''' implementing such interfaces can be found in '''Server\Interfaces_stub'''. In our example the Eiffel class would be named ISOMETHING_INTERFACE_IMPL_STUB. The default implementation of the stub is empty and should be completed to implement the wanted behavior. This is how callbacks can be implemented using EiffelCOM.
+
+==Contracts==
+
+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 Void Eiffel objects as well as null 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 True. They can be redefined to implement the correct behavior:
+
+function (a: INTEGER): MY_STRUCT is
+ -- Example of a generated Eiffel coclass feature
+ require
+ function_user_precondition: function_user_precondition
+ do
+ ...
+ ensure
+ non_void_my_struct: Result /= Void
+ end
+
+So the complete class hierarchy for an Eiffel client coclass is the following:
+ [[Image:client-inheritance]]
+==Exceptions==
+
+The COM standard requires that any interface function returns a status value (known as a HRESULT). This means that any function which adheres to the COM standard actually corresponds to a side effect feature which the Eiffel methodology tries to avoid according to the ''Command Query Separation Principle''. The workaround used in EiffelCOM systems consists in mapping these return values to Eiffel exceptions. So if the component returns an HRESULT corresponding to an error code, the EiffelCOM runtime raises an Eiffel exception that needs to be caught by the client.
+ [[Image:exception-raising]]
+As a result, any feature in the client making calls to the Eiffel classes corresponding to the component's coclasses should include a rescue clause. The processing done in this clause might depend on the nature of the exception. All the standard COM exceptions can be found in the library class ECOM_EXCEPTION_CODES, which is inherited from by ECOM_EXCEPTION. The later also inherits from the kernel class EXCEPTIONS and can consequently be used by the coclass client to catch the exceptions.
+
+The following code snippet illustrates how a client can process exceptions raised by a call to an Eiffel class representing a component's coclass:
+
+indexing
+ description: "Eiffel coclass client example"
+
+class
+ COCLASS_CLIENT
+
+inherit
+ ECOM_EXCEPTION
+ export
+ {NONE} all
+ end
+
+feature -- Basic Operations
+
+ coclass_feature_client is
+ -- Example of a coclass feature caller
+ local
+ retried: BOOLEAN
+ coclass: EIFFEL_COCLASS_PROXY
+ do
+ if not retried then
+ create coclass.make
+ coclass.coclass_feature -- Actual call
+ end
+ rescue
+ if hresult = E_notimpl then
+ -- Process non implemented function error.
+ retried := True
+ retry
+ elseif hresult = E_invalidarg then
+ -- Process invalid argument error.
+ retried := True
+ retry
+ else
+ -- Forward exception to caller.
+ end
+ end
+
+end -- class COCLASS_CLIENT
+
+{{seealso| '''See Also''': [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Building a COM Component|Reusing a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/wizards-command-line-options.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/wizards-command-line-options.wiki
new file mode 100644
index 00000000..43a4dfd6
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/wizards-command-line-options.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Wizards: Command Line Options]]
+[[Property:weight|6]]
+The EiffelCOM Wizard can be used from the command line for example in batch scripts. The command line utility is com_wizard.exe and is located in $ISE_EIFFEL\wizards\com. Each command line option has both a long and a short name. The long names are all prefixed with -- while the short names are all prefixed with -. Options that take an argument should have the argument directly following the option with a space or a = sign in between the option name and the argument as in:
+
+--ace="mysystem.ecf"
+this option is equivalent to:
+
+-a "mysystem.ecf"
+
+The list of options is the following:
+* '''--client, -c''' : Build client to access COM component described by .
+* '''--server, -s''' : Build new COM component as described by .
+* '''--eiffel, -e''' : Add COM interface to Eiffel project with project file (*.epr) .
+* '''--ace, -a''' : Path to ecf file of Eiffel project to be added a COM interface. Use together with '--eiffel'.
+* '''--facade, -f''' >FACADE_CLASS>: Name of facade class to generate IDL from. Use together with '--eiffel'.
+* '''--cluster, -u''' >CLUSTER>: Name of facade class cluster. Use together with '--eiffel'.
+* '''--outofprocess, -o''': Access or build out of process component. By default access or build in-process component (DLL).
+* '''--compilec, -i''': Compile generated C code.
+* '''--compileeiffel, -l''': Compile generated Eiffel code. Implies '--compilec'.
+* '''--marshaller, -m''': Build marshaller DLL, can only be used with '--server' and if definition file is an IDL file.
+* '''--destination, -d''' : Generate files in folder. By default files are generated in current folder.
+* '''--cleanup, -p''': Cleanup destination folder prior to generation. This option cannot be used together with '--backup'.
+* '''--backup, -b''': Backup overriden files by adding extension '.bac'. This option cannot be used together with '--cleanup'.
+* '''--graphical, -g''': Launch GUI, all other options are ignored.
+* '''--nologo, -n''': Do not display copyright information.
+* '''--version, -v''': Print version information.
+* '''--help, -h''': Display help on how to use the EiffelCOM Wizard command line utility.
+
+{{seealso| '''See Also''': [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[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]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/index.wiki b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/index.wiki
new file mode 100644
index 00000000..4ae2a3de
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/com/eiffelcom-wizard/index.wiki
@@ -0,0 +1,18 @@
+[[Property:title|EiffelCOM Wizard]]
+[[Property:weight|4]]
+Type: Wizard
+Platform: Windows
+
+See:
+* [[EiffelCOM Wizard Introduction|Introduction]]
+* [[EiffelCOM Wizard Guided Tour|Guided Tour]]
+* [[EiffelCOM Wizard Reference|Reference]]
+
+
+{{seealso| '''See Also'''
+[[EiffelCOM|The Component Object Model]]
+[[EiffelCOM Library|EiffelCOM library]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/building-net-application.wiki b/documentation/current/platform-specifics/microsoft-windows/net/building-net-application.wiki
new file mode 100644
index 00000000..15c8e470
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/building-net-application.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Building a .NET application]]
+[[Property:weight|1]]
+Eiffel for .NET has some specific functionality meant to leverage necessary aspects of the .NET Framework.
+
+For that reason, the [[EiffelStudio: Project settings window|project settings]] for Eiffel for .NET introduces new options. These options include:
+* Specifying whether the generated assembly should be an EXE or a DLL.
+* Choosing between generating verifiable or non verifiable IL code. Non verifiable IL code executes faster but requires high trust settings.
+
+The Eiffel for .NET compiler generates a single assembly whose name is the name of the system as given in the [[System Options|project settings]] .
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/eiffel-codedom-provider-manager.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/eiffel-codedom-provider-manager.wiki
new file mode 100644
index 00000000..77edbf4a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/eiffel-codedom-provider-manager.wiki
@@ -0,0 +1,38 @@
+[[Property:title|Eiffel CodeDom Provider Manager]]
+[[Property:weight|-1]]
+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. }}
+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.
+* '''Log server''': Server where events should be logged. By default events are logged on the machine running the CodeDom Provider, the corresponding value is a dot ("."). Consult the [[Logging|Logging]] section for additional information on logging.
+* '''Log level''': By default only errors are written to the log. It might be useful for debugging purposes to log additional information and/or warnings. This setting also allows to disable logging in case it is not required. Consult the [[Logging|Logging]] section for additional information on logging.
+
+==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. }}
+
+* '''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. }}
+
+{{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). }}
+
+* '''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.
+
+==Assembly Prefixes==
+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. }}
+
+==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.
+==Configuration Properties==
+Double clicking on the configuration name in the configurations list, clicking the ''Properties'' button or choosing the ''Properties'' menu entry in the ''File'' menu will open the Configuration Properties dialog. This dialog gives the dates of creation and last modification of the configuration as well as the list of applications that use it if it's not the default configuration.
+{{seealso| '''See also:''' [[Configuration|Configuration]] , [[Logging|Logging]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/esplitter.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/esplitter.wiki
new file mode 100644
index 00000000..599f531f
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/esplitter.wiki
@@ -0,0 +1,44 @@
+[[Property:title|eSplitter]]
+[[Property:weight|0]]
+This tool comes in two flavors: a command line only utility ''esplit.exe'' and a graphical tool ''esplitter.exe''. Both applications achieve the same goal: to produce standard Eiffel source files ('''.e''' files) from Eiffel CodeDom Provider generated source files ('''.es''' files).
+==Command Line Utility (esplit.exe)==
+This utility is located in the ''Codedom\bin'' subfolder of the Eiffel for ASP.NET directory. The command line syntax is:
+
+Usage: esplit -f=FOLDER [-s -d=DESTINATION -v -h -m=REGEXP -n]
+ -d, --destination=DESTINATION
+ Folder where generated Eiffel class files should be created.
+ If not specified, creates Eiffel class files in same folder as
+ corresponding Eiffel multi-class file.
+ -f, --folder=FOLDER
+ Folder containing Eiffel multi-class files.
+ -h, --help
+ Help on using this program.
+ -m, --match=REGEXP
+ Regular expression that file name must match to be processed, by default matches all files with extension '.es'.
+ -n, --nologo
+ Do not display copyright notice.
+ -s, --subfolders
+ Also process files in subfolders.
+ -v, --version
+ Version information.
+So running:
+
+esplit -f .
+will generate Eiffel source files from all the files with extension '.es' in the current folder and running:
+
+esplit -f "source" -m "C.*\.es" -d "destination" -s
+will generate Eiffel source files from all the files with extension '.es' and whose filename starts with a 'C' located in the 'source' folder and all its subfolders. The Eiffel source files will be generated in the 'destination' folder.
+==Graphical Utility (esplitter.exe)==
+The graphical utility includes two panes. The first pane allows setting different parameters:
+* '''Folder containing Eiffel multi-class file(s)''': this field gives the path to the folder which contains the files to be processed. The button to the right of the field allows to browse for the folder. This field corresponds to the '-f' parameter of the command line utility.
+* '''Only process files whose filename matches the following regular expression''': this field corresponds to the '-m' parameter of the command line utility.
+* '''Also process files in subfolder''': if this check box is checked then the utility will search for files whose filenames match the regular expression in the destination folder as well as in its subfolders. This check box corresponds to the '-s' switch of the command line utility.
+* '''Generate Eiffel class files in the same folder as the Eiffel multi-class files''': checking this radio button is equivalent to not providing a '-d' parameter to the command line utility.
+* '''Generate Eiffel class files in the following folder''': The content of the field below this radio button corresponds to the '-d' parameter of the command line utility.
+Clicking on the '''Generate''' button switches to the output pane and starts the Eiffel class file generation. The output pane contains the text output resulting from the execution of the tool. It also contains two buttons:
+* '''Open Folder''': clicking on this button will open Windows Explorer in the folder where the Eiffel source files were generated.
+* '''Exit''': clicking this button will close the application.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/index.wiki
new file mode 100644
index 00000000..7364e763
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|Eiffel for ASP.NET Tools and Administration]]
+[[Property:weight|2]]
+The Eiffel for ASP.NET delivery comes together with several tools:
+* [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] allows administering the Eiffel CodeDom Provider.
+* [[eSplitter|ESplitter]] allows generating standard Eiffel source files ('''.e''' files) from Eiffel CodeDom Provider generated files ('''.es''') files.
+* [[Name Mapper|Name Mapper]] allows retrieving the Eiffel identifier corresponding to a .NET type or type member.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/name-mapper.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/name-mapper.wiki
new file mode 100644
index 00000000..51c6a546
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/name-mapper.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Name Mapper]]
+[[Property:weight|2]]
+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| '''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]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/about-code-document-object-model-codedom.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/about-code-document-object-model-codedom.wiki
new file mode 100644
index 00000000..347996a1
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/about-code-document-object-model-codedom.wiki
@@ -0,0 +1,10 @@
+[[Property:title|About the Code Document Object Model (CodeDom)]]
+[[Property:weight|0]]
+CodeDom stands for the '''Code Document Object Model'''. CodeDom allows for representing source code in an abstract data structure. Such a representation is called a '''CodeDom tree''' as the underlying data structure uses a tree paradigm. This abstract representation can then be generated into different programming languages. Each language vendor provides its implementation of the CodeDom interfaces, this implementation is called a '''CodeDom Provider'''. Programmers can then build tools that can work with many different languages without having to know about each one, instead they just delegate code generation to each CodeDom Provider.
+The CodeDom interfaces also expose types and methods that allow for parsing source code and creating the corresponding CodeDom. The current implementation of the Eiffel CodeDom Provider does not support parsing. Code generation is a much more popular useage of the CodeDom and the current version focuses on this aspect of the technology.
+
+{{seealso| '''See also:''' [[Installation|Installation]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/common-scenarios.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/common-scenarios.wiki
new file mode 100644
index 00000000..4b60353c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/common-scenarios.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Common Scenarios]]
+[[Property:weight|7]]
+==ASP.NET==
+Probably the most common use of the CodeDom technology is via Internet Information Services (IIS) and ASP.NET. The installation of the Eiffel for ASP.NET will configure the machine so ASP.NET pages can be written in Eiffel. Consult the [[Eiffel for ASP.NET Installation|Eiffel for ASP.NET documentation]] for details on how to write ASP.NET Eiffel pages.
+==WSDL==
+Another use of the CodeDom technology is via the WSDL utility. This utility is part of the .NET Framework SDK and is a common line application that can be used to automatically generate stub source code for any Web Service described by a Web Service Description Language (WSDL) file. It is possible to tell the utility which CodeDom Provider to use via the command line as follows:
+
+Wsdl /language:"EiffelSoftware.CodeDom.CodeDomProvider, EiffelSoftware.CodeDom, Version=2.0.1.1402, Culture=neutral, PublicKeyToken=def26f296efef469"
+http://api.google.com/GoogleSearch.wsdl
+
+{{note| '''Note:''' The vesion number used above might differ depending on the version of the Eiffel CodeDom Provider dll installed on your system. }}
+
+{{note| '''Note:''' The example above uses the Google web service, the corresponding URL is correct at the time of writing but there is no guarentee it won't change (or be removed) in the future. }}
+This will generate a file with the extension '''.es''' which contains multiple Eiffel class definitions. Compiling this file will require using the CodeDom compiler (programmatically via the CodeDom ICodeCompiler interface) or using the [[eSplitter|eSplitter]] tool to generate standard Eiffel source files ('''.e''' files) that can then be compiled by the standard Eiffel compiler.
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/configuration.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/configuration.wiki
new file mode 100644
index 00000000..77123710
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/configuration.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Configuration]]
+[[Property:weight|3]]
+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. }}
+
+{{seealso| '''See also:''' [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , [[Logging|Logging]] , [[Required Permissions|Required permissions]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/eiffel-implementation.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/eiffel-implementation.wiki
new file mode 100644
index 00000000..f96c310a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/eiffel-implementation.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Eiffel Implementation]]
+[[Property:weight|7]]
+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. }}
+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. }}
+
+==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. }}
+
+==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.
+{{seealso| '''See also:''' [[eSplitter|eSplitter]] , [[Configuration|Configuration]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/index.wiki
new file mode 100644
index 00000000..a21773bf
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|The Eiffel CodeDom Provider]]
+[[Property:weight|0]]
+The Eiffel CodeDom Provider provides an implementation of the CodeDom Provider generation and compilation interfaces defined in the System.CodeDom namespace of the .NET Framework. This documentation includes the following sections:
+* [[About the Code Document Object Model (CodeDom)|About CodeDom]] introduces the basic concepts behing the CodeDom technology.
+* [[Installation|Installation]] describes the steps involved in installing the Eiffel CodeDom Provider.
+* [[Supported Constructs|Supported constructs]] lists the CodeDom constructs supported by the Eiffel CodeDom Provider.
+* [[Configuration|Configuration]] describes how to administer the Eiffel CodeDom Provider.
+* [[Logging|Logging]] describes the logging functionality of the Eiffel CodeDom Provider.
+* [[Required Permissions|Required permissions]] describes the permissions that must be granted to the process using the Eiffel CodeDom Provider.
+* [[Common Scenarios|Secnarios]] shows how the Eiffel CodeDom Provider can be used with different applications.
+* [[Eiffel Implementation|Eiffel implementation]] describes a few points of the Eiffel CodeDom Provider implementation that are specific to the Eiffel language.
+* [[Limitations|Limitations]] lists the limitations of the current Eiffel CodeDom Provider implementation.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/installation.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/installation.wiki
new file mode 100644
index 00000000..f72de739
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/installation.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Installation]]
+[[Property:weight|1]]
+For certain tools (including ASP.NET) to detect the availability of a CodeDom Provider, the corresponding assembly name must be listed in the .NET machine wide configuration file typically located in:
+%SYSTEM_DRIVE%\Windows\Microsoft.NET\Framework\vx.x.xxxx\CONFIG\machine.config
+(where vx.x.xxxx corresponds to the .NET Framework version number). The available CodeDom Providers are listed under the '''' XML node. The Eiffel CodeDom Provider implements a.NET Installer class so that should you need to add the Eiffel CodeDom Provider to the machine configuration file, simply run the .NET SDK command line utility ''InstallUtil'' as follows:
+InstallUtil EiffelSoftware.Codedom.dll
+Conversely, should the Eiffel Codedom Provider not be required anymore, running the following command line will remove it from the ''machine.config'' file:
+InstallUtil /u EiffelSoftware.Codedom.dll
+
+{{note| '''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]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/limitations.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/limitations.wiki
new file mode 100644
index 00000000..a074cfdf
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/limitations.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Limitations]]
+[[Property:weight|8]]
+==Generation Only==
+The current implementation of the Eiffel CodeDom Provider does not support parsing Eiffel source code to produce a CodeDom tree. Only code generation and compilation are supported in the current release.
+==Managed Code Only==
+Only managed code can be generated or compiled by the Eiffel CodeDom Provider. This means that the CodeDom tree being compiled cannot include snippet members which use or define Eiffel external clauses. If the system requires access to external methods, they should be defined in a precompiled library (see [[Configuration|Configuration]] ).
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/logging.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/logging.wiki
new file mode 100644
index 00000000..e68ec172
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/logging.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Logging]]
+[[Property:weight|4]]
+The Eiffel CodeDom Provider may be configured (via the [[Eiffel CodeDom Provider Manager|Eiffel Codedom Provider Manager]] ) to log information, warnings and/or errors in the Windows Event Log. Logging may be useful for a number of reasons, some of them are:
+* To detect which CodeDom interface method is called and when it's called. This is particularly useful when the source code for the CodeDom consumer (e.g. ASP.NET) is not available.
+* To locate the source of a problem when the code generated by the Eiffel CodeDom Provider is incomplete or incorrect. This may happen if the CodeDom tree given to the Eiffel CodeDom Provider uses one of the unsupported constructs as listed in the topic [[Supported Constructs|Supported Constructs]] .
+* To detect a problem in a CodeDom tree. The logs will help in locating the location of the problem as they include contextual information on the node where the error occurred.
+
+==Log Details==
+There are three types of events that can be logged: information events, warnings and errors:
+* Information events include calls to CodeDom interface methods and other events that will not affect the execution of the Eiffel CodeDom Provider
+* Warnings include events that will not prevent the CodeDom Provider from running but that may affect the results. For example if a CodeDom tree element references a .NET entity that the Eiffel CodeDom Provider cannot find then it will generate a default Eiffel name by running the default formatting algorithm. This may produce code that does not compile if the Eiffel name of the entity does not correspond to the formatted .NET name (for example if the entity is a type and the type's assembly has a non-empty prefix).
+* Errors include events that will force the execution of the Eiffel CodeDom Provider to stop. By default the Eiffel CodeDom Provider simply stops and returns an error, it is possible however to configure it so that an exception is raised.
+
+==Log Location==
+All the Eiffel CodeDom Provider events are logged into the Windows '''System''' Log. This log can be viewed via the Windows administrative tool ''Event Viewer''. The source for the events raised by the Eiffel CodeDom Provider is ''Eiffel CodeDom Provider''. By default all the events are logged on the machine running the Eiffel CodeDom Provider but it is possible to change its configuration so that the events are logged on a different machine (see [[Required Permissions|Required permissions]] ).
+{{seealso| '''See also''': [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , [[Supported Constructs|Supported constructs]] , [[Required Permissions|Required permissions]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/required-permissions.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/required-permissions.wiki
new file mode 100644
index 00000000..37cee212
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/required-permissions.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Required Permissions]]
+[[Property:weight|6]]
+The account running the Eiffel CodeDom Provider might have restricted permissions such as when used through ASP.NET. This section aims at defining the security permissions required for the execution of the Eiffel CodeDom Provider.
+==Eiffel Metadata Cache==
+Both when generating and compiling source code, the Eiffel CodeDom Provider needs to read and write from and to the Eiffel Metadata Cache. This repository stores the mapping information between .NET and Eiffel names for both types and their members. By default the Eiffel Metadata Cache is located in the ''Assemblies'' subfolder of the Eiffel CodeDom Provider directory.
+{{note| '''Note:''' The Eiffel for ASP.NET installation program will grant read and write access to the Eiffel Metadata Cache folder for the ''ASPNET'' (default ASP.NET worker process account on Windows XP Professional) and the ''IIS_WPG'' (default ASP.NET worker process account on Windows Server 2003) accounts. }}
+The path to the Eiffel Metadata Cache folder might be changed via the [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , make sure the new folder can be read from and written to by the account running the process that uses the Eiffel CodeDom Provider.
+==Precompile Cache==
+The same requirements apply to the Precompile Cache folder. By default the Precompile Cache folder is located in the ''Precompile'' subfolder of the Eiffel CodeDom directory.
+{{note| '''Note:''' The Eiffel for ASP.NET installation program will grant read and write access to the Precompile Cache folder for the ''ASPNET'' (default ASP.NET worker process account on Windows XP Professional) and the ''IIS_WPG'' (default ASP.NET worker process account on Windows Server 2003) accounts. }}
+As with the Eiffel Metadata Cache folder, it is possible to change the location of the Precompile Cache folder but the process running the Eiffel CodeDom Provider must always have read and write access to the folder.
+==Logging==
+Logging requires registry read access as well as event log write access. By default, the ASP.NET worker process does not have these permissions. The easiest way to grant the required permissions to the ASP.NET worker process is by using ASP.NET impersonation. This mechanism allows the ASP.NET worker process to run under a different account. This is done by providing a ''web.config'' file in the root folder of the ASP.NET application. The content of the configuration file needs to include the following declaration:
+
+
+
+
+
+
+where Username is the name of an account which has all the required permissions and Password the corresponding password. Refer to the .NET Framework SDK documentation for additional information on ASP.NET impersonation.
+The solution described above might not be acceptable on a production web server. However, it is possible to configure the Eiffel CodeDom Provider to log events on a different machine (see [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] ). The log machine should grant the appropriate permissions to the impersonated account for logging and could only be accessible through the web server. This setting would avoid having to grant additional permissions to the ASP.NET worker process account on the web server while still enabling logging.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/supported-constructs.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/supported-constructs.wiki
new file mode 100644
index 00000000..d39b4c9f
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/supported-constructs.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Supported Constructs]]
+[[Property:weight|2]]
+Since not every language might support all the constructs CodeDom can represent, there needs to be a way for the CodeDom Provider to specify which constructs are supported and which ones are not. This is done through the System.Codedom.Compiler.ICodeGenerator interface using method Supports.
+This method takes a flag corresponding to the CodeDom contruct the caller is interested in and returns a boolean value indicating whether or not the construct is supported. In the Eiffel CodeDom Provider implementation there is a third category of constructs which will be reported as supported since the provider will generate valid Eiffel code for them but that should be distinguished from other "truly" supported constructs as the generated code will not correspond to the .NET equivalent of the construct.
+Let's take an example: Enum declarations are supported by the Eiffel CodeDom Provider because the generated Eiffel code will correctly make use of the values defined in the enum. However there is no such thing as an enum type in Eiffel so there won't be a corresponding .NET enum type in the generated assembly. Such constructs are said to be "non-roundtripable" because even if the Eiffel CodeDom Provider supported parsing source code, the corresponding CodeDom tree would not include the constructs like the initial CodeDom did.
+The lists of supported, supported without roundtrip and unsupported constructs for the Eiffel CodeDom Provider are as follows:
+
+'''Supported constructs''':
+* Arrays of arrays
+* Assembly attributes
+* Complex expressions
+* Declare value types
+* Entry point method
+* Multiple interface members
+'''Supported constructs (no roundtrip)''':
+* Declare enums
+* Declare events
+* Declare interfaces
+* Nested types
+* Public static members
+* Reference parameters
+* Try catch statements
+'''Unsupported constructs''':
+* Chained constructor arguments
+* Declare delegates
+* Goto statements
+* Multidimensional arrays
+* Parameter attributes
+* Return type attributes
+* Static constructors
+* Win32 resources
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/index.wiki
new file mode 100644
index 00000000..64ef8f8b
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Eiffel for ASP.NET Documentation]]
+[[Property:weight|6]]
+CodeDom is a Microsoft .NET technology which allows representing source code programatically so that it may be rendered in different languages. The Eiffel CodeDom Provider is installed through Eiffel for ASP.NET which is available for download for free on the Eiffel Software web site ( [http://www.eiffel.com http://www.eiffel.com] ).
+The following documents cover different aspects of the Eiffel CodeDom Provider:
+* [[Writing ASP.NET pages in Eiffel|Writing ASP.NET pages in Eiffel]] covers topics related to writing Eiffel pages in ASP.NET.
+* The [[The Eiffel CodeDom Provider|Eiffel CodeDom Provider]] documentation focuses on the Eiffel CodeDom Provider per se. Read this documentation if you intend on using the Eiffel CodeDom Provider via a different mean than ASP.NET (e.g. to generate Web Services stubs using Microsoft's WSDL utility).
+* Finally, [[Eiffel for ASP.NET Tools and Administration|Eiffel for ASP.NET Tools and Administration]] covers the Eiffel CodeDom Provider Manager, the eSplitter and the Name Mapper tools that are included in the Eiffel for ASP.NET delivery.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/codedom-getting-started.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/codedom-getting-started.wiki
new file mode 100644
index 00000000..62fd0ce3
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/codedom-getting-started.wiki
@@ -0,0 +1,15 @@
+[[Property:title|CodeDom: Getting Started]]
+[[Property:weight|0]]
+==Prerequesites==
+Before you start writing ASP.NET pages in Eiffel, you should be familiar with the ASP.NET technology itself. If you haven't already, it is strongly recommended that you follow the ASP.NET quickstarts available online at [http://samples.gotdotnet.com/quickstart/aspplus/ http://samples.gotdotnet.com/quickstart/aspplus/] . Apart from a few Eiffel specific points described in [[Using Eiffel (to write ASP.NET pages)|Using Eiffel]] , writing ASP.NET pages in Eiffel follows the same rules as writing ASP.NET pages in any other language.
+Writing ASP.NET pages in Eiffel also requires to be familiar with the Eiffel language itself. There are no changes in the language when using it to write ASP.NET pages: the same parser and compiler are used to parse and compile standard Eiffel source code and ASP.NET generated source code. Documentation on the Eiffel language can be found on the [http://docs.eiffel.com Eiffel documentation web site] .
+
+==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. }}
+
+{{seealso| '''See also:''' [[Using Eiffel (to write ASP.NET pages)|Using Eiffel]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/eiffel-aspnet-installation.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/eiffel-aspnet-installation.wiki
new file mode 100644
index 00000000..748d2baf
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/eiffel-aspnet-installation.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Eiffel for ASP.NET Installation]]
+[[Property:weight|-1]]
+Eiffel for ASP.NET is available for downloading for free at [http://www.eiffel.com http://www.eiffel.com] . Simply run the file and follow the installer instructions. It is recommended that Internet Information Services (IIS) be deployed on the machine prior to installing Eiffel for ASP.NET. If IIS is not deployed then the installation program will display a warning message box. Click '''ignore''' to keep installing the product.
+Without IIS, ASP.NET pages cannot be loaded and thus the samples will not be installed. It might still be useful to install Eiffel for ASP.NET without IIS if the Eiffel CodeDom Provider is going to be used through other [[Common Scenarios|scenarios]] . If IIS is available then the installer will open an Eiffel ASP.NET page at the end of the installation process. This page contains links to the documentation and samples. The installer will also put links to these documents in the ''Start'' menu under 'Programs\Eiffel for ASP.NET x.x' where 'x.x' corresponds to the version number of Eiffel for ASP.NET.
+==System Requirements==
+* Windows 2000 Server or Advanced Server with Service Pack 2, Windows XP Professional or 64-Bit Edition, or one of the Windows Server 2003 family products.
+* .NET Framework (1.0 or 1.1)
+* Internet Information Services with ASP.NET (optional see above)
+
+==ASP.NET Installation==
+Please consult the corresponding documentation (available online at [http://msdn.microsoft.com/asp.net/ http://msdn.microsoft.com/asp.net/] ) for configuring ASP.NET properly. In particular, be aware that by default ASP.NET is disabled on Windows 2003 Server.
+
+{{seealso| '''See also:''' [[CodeDom: Getting Started|Getting Started]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/index.wiki
new file mode 100644
index 00000000..1a988ccb
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Writing ASP.NET pages in Eiffel]]
+[[Property:weight|-1]]
+Eiffel for ASP.NET allows running ASP.NET pages written in Eiffel. It should be installed on both the web server and the developer's machine. This documentation includes the following sections:
+* [[Eiffel for ASP.NET Installation|Installation]] describes the steps involved in installing Eiffel for ASP.NET.
+* [[CodeDom: Getting Started|Getting started]] lists resources that will help getting started with Eiffel for ASP.NET.
+* [[Using Eiffel (to write ASP.NET pages)|Using Eiffel]] lists a few points that are specific to using Eiffel for writing ASP.NET pages.
+* [[Names Mappings|Names mapping]] explains how to retrieve Eiffel identifiers from .NET ones.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/names-mappings.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/names-mappings.wiki
new file mode 100644
index 00000000..2471bc03
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/names-mappings.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Names Mappings]]
+[[Property:weight|4]]
+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. }}
+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:
+System.Xml.NameTable -> NameTable
+
+# Underscores are introduced in between words (prior to upper case letters other than the first character):
+NameTable -> Name_Table
+
+# Eiffel class names are always upper case:
+Name_Table -> NAME_TABLE
+
+# If the assembly containing the type is associated with a prefix in the Eiffel system then the prefix gets prepended to the name:
+NAME_TABLE -> XML_NAME_TABLE
+
+The steps to follow to retrieve the Eiffel identifier corresponding to a .NET member are simpler:
+# For property getters, the "get_" prefix is removed:
+get_MaxOccursString -> MaxOccursString
+
+# Underscores are introduced in between words (prior to upper case letters other than the first character):
+MaxOccursString -> Max_Occurs_String
+
+# Eiffel feature names are always lower case:
+Max_Occurs_String -> max_occurs_string
+
+Although these simplified steps will work in most cases there are certain .NET identifiers that require additional manipulation to be translated into Eiffel. The [[Name Mapper|Name Mapper]] utility should be used when such cases arise.
+{{seealso| '''See also:''' [[Name Mapper|Name Mapper]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/using-eiffel-write-aspnet-pages.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/using-eiffel-write-aspnet-pages.wiki
new file mode 100644
index 00000000..41a88b97
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/using-eiffel-write-aspnet-pages.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Using Eiffel (to write ASP.NET pages)]]
+[[Property:weight|3]]
+==Inheritance==
+Eiffel handles inheritance in a different way than most languages. In C# or VB.NET the behavior of a newly introduced member in a class hierarchy is defined as part of the member declaration itself (for example C# will precede the member declaration with the keyword ''override'' to accomplish the same result as an Eiffel ''redefine'' clause). In Eiffel, classes are equipped with an inheritance clause which centralizes all the feature adaptations.
+As a result, Eiffel for ASP.NET introduces '''inheritance snippets'''. Each Eiffel ASP.NET page may include at most one inheritance snippet. Such a snippet must start with the '''inherit''' keyword and may then list any valid Eiffel feature adaptation.
+
+==String and Array Manifest Constants==
+The Eiffel language supports using '''manifest constants''' in source code. The type of these constants is inferred by the Eiffel compiler. There are two manifest constant types that require special attention on .NET: string and array. Because the Eiffel and the .NET types differ, writing code using string or array manifest constants requires additional care.
+* '''Strings''': Eiffel strings cannot be mapped directly to .NET strings because Eiffel strings are ''mutable'': an Eiffel string can be resized while the size of a .NET string is set for the lifetime of the object. However, the Eiffel class STRING defines conversion features that will automatically convert to and from a .NET string. So when the compiler expects an object of type ''System.String'' where an object of type STRING is used, it will automatically call the right conversion routine.
+However if an instance of STRING is passed as an argument to an overloaded .NET function that can accept both an instance of ''System.Object'' or an instance of ''System.String'' then the compiler will produce an error since it has no means to know which type the Eiffel object should be converted to (any Eiffel object converts to ''System.Object''). When this happens, the conversion function to_cil must be explicitely called.
+* '''Arrays''': The exact same problem also arises with arrrays. Instances of the Eiffel class ARRAY are different from instances of NATIVE_ARRAY which correspond to the .NET array type. There are however features in ARRAY that will convert to and from .NET arrays. If an overloaded .NET function can take an argument of type ''System.Object'' or ''System.Array'', any instance of ARRAY given to it must first be converted explicitly to a .NET array by calling the to_cil function.
+
+==Compilation and Timeouts==
+Eiffel compilations can take longer than the default timeouts set in ASP.NET. In particular ASP.NET will run batch compilations on the entire directory that is being accessed by IIS each time the time stamp of that directory changes. If the batch compilation takes longer than the ''batchTimeout'' property defined in the machine wide configuration file (''machine.config'') then ASP.NET will start another compilation just for the requested file. This can be quite resource intensive for the Web server and thus it might be beneficial to increase the default value of 15 seconds for ''batchTimeout''.
+{{seealso| '''See also:''' [[Names Mappings|Names Mapping]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki
new file mode 100644
index 00000000..576d6c60
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki
@@ -0,0 +1,47 @@
+[[Property:title|Constructors and Creation Procedures]]
+[[Property:weight|4]]
+This section deals with what happens when objects, that is runtime instances of types, get created and initialized. When a new instance is created, there is an opportunity to initialize the state of the instance. This is done with a constructor in .NET, and with a creation procedure in Eiffel.
+
+==Eiffel Creation Procedures==
+
+Eiffel creation procedures are features of a class which can be used to initialize instances. Classes can have more than one creation procedure available. However, each creation procedure must ensure that the class invariant holds when the procedure completes execution. In other words, the creation procedure is there to initialize a newly created instance, and the class invariant guarantees that a newly initialized instance is actually valid.
+
+There is nothing special about creation procedures themselves, they are just ordinary procedures (although by convention their names usually begin with the word " make "). What makes them creation procedures is the fact that their names are listed as creation procedures in the class text.
+
+In Eiffel, a creation procedure can be applied to an instance at any time (not just at object creation). This is done sometimes to reinitialize existing instances.
+
+==Constructors in .NET==
+
+Like creation procedures in Eiffel, .NET constructors are used to initialize new instances of types. Constructors manifest themselves differently depending upon which .NET language you use. In C#, constructors always appear as a method having the same name as the class on which they are implemented. In Visual Basic .NET, they always appear as a Sub with the name New . Once compiled into an assembly, the metadata labels constructors as . ctor .
+
+Constructors can have multiple versions by overloading. That is, each version would have a different set of argument types.
+
+Constructors can only be applied when a new instance is created.
+
+===Constructors as Eiffel Creation Procedures===
+
+When types from .NET assemblies are made available to Eiffel systems, the constructors are presented as creation procedures. Just as constructors show up in the C# and VB.NET environments with names appropriate to those languages, so it is with Eiffel for .NET. Always, constructors will have feature names which begin with the word " make ", the convention for creation procedure naming in Eiffel.
+
+If there is only one version of the constructor, that version will be mapped to a single feature named make . However, if there are overloaded versions of the constructor, then these versions given names starting with " make_from_ " and then followed with the argument names from the assembly metadata separated with the conjunction " _and_ ". Let's look at an example.
+
+The .NET type System.Drawing.Size has an overloaded constructor with two versions. In the System.Drawing assembly metadata, these two constructor versions look like this:
+
+void .ctor(int32 width, int32 height)
+void .ctor(System.Drawing.Point pt)
+
+
+So the argument names for the first version are width and height . For the second version there is only one argument named pt . The constructor versions as presented to Eiffel programmers as creation procedures look like this:
+
+make_from_width_and_height (width: INTEGER; height: INTEGER)
+make_from_pt (pt: DRAWING_POINT)
+
+
+Presenting the names in this format handles the conflicts of overloading and provides reasonably intuitive names that comply with Eiffel naming conventions.
+
+===Eiffel Creation Procedures as Constructors?===
+
+Eiffel creation procedures do not map to constructors when Eiffel classes are compiled into assemblies. Rather, they are actually manifested as functions on a factory class in the namespace Create in the assembly. These functions return an initialized instance. In the section Type Organization there is more information about the organization of the types in assemblies built with Eiffel for .NET, along with an example of using types from such an assembly.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki
new file mode 100644
index 00000000..f64a759e
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki
@@ -0,0 +1,217 @@
+[[Property:title|Eiffel Class and Feature Names]]
+[[Property:weight|2]]
+Certain naming conventions are respected by Eiffel programmers. Although Eiffel is not case-sensitive, convention dictates the use of upper and lower case in particular situations. When you program in EiffelEnvision, you create new Eiffel classes, but you also use types from .NET assemblies. These .NET types are presented to you in a view that is consistent with Eiffel conventions.
+
+==Eiffel Class Names==
+
+Convention dictates that Eiffel class names are always all upper case characters with words separated by the underscore ("_") character. Eiffel classes are not qualified by "namespace" as in some other languages. This means that Eiffel class names must be unique with in a system. It also means that any types from existing .NET assemblies will have their names mapped to conventional Eiffel class names in order to be used by Eiffel classes in EiffelEnvision
+
+Here are some class names and their descriptions from the Eiffel Base Library. These class names comply with the Eiffel class naming convention.
+
+STRING
+
+ Sequences of characters, accessible through integer indices in a contiguous range.
+
+RANDOM
+
+ Pseudo-random number sequence, linear congruential method.
+
+ARRAYED_LIST
+
+ Lists implemented by resizable arrays.
+
+LINKED_QUEUE
+
+ Unbounded queues implemented as linked lists.
+
+
+
+Now here are some type names from the .NET mscorlib as they appear as conventional Eiffel class names (i.e. , in the form in which they become available to Eiffel for .NET programmers), followed by their full .NET type and their Summary from the .NET library. names.
+
+SYSTEM_STRING
+
+System.String
+
+ Represents an immutable series of characters.
+
+SYSTEM_RANDOM
+
+System.Random
+
+ Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness.
+
+ARRAY_LIST
+
+System.Collections.ArrayList
+
+ Implements the System.Collections.IListinterface using an array whose size is dynamically increased as required.
+
+SYSTEM_QUEUE
+
+System.Collections.Queue
+
+ Represents a first-in, first-out collection of objects.
+
+
+
+In summary, Eiffel class names and type names from .NET assemblies made available to Eiffel programmers will be all upper case, with words separated by the underscore character.
+
+===Eiffel Names for .NET Types===
+
+How Eiffel compliant names are derived from .NET type names is fairly simple in most cases. The "simple" class name, that is, the word following the rightmost dot in the full class name, is converted to an Eiffel compliant name by making it upper case and separating in embedded words by underscore. In the example above, System.Collection.ArrayList becomes ARRAY_LIST .
+
+The other cases in the example are not quite so simple. If the basic derivation produces a name which conflicts with a classname in the Eiffel Base Library, then it will be disambiguated. The simple derivation of System.String would be STRING, but this would conflict with Eiffel's STRING class, so System.String becomes available to Eiffel for .NET programmers as SYSTEM_STRING.
+
+Sometimes it is better to disambiguate an entire assembly rather than handling individual exceptions to the simple derivation. This is done by specifying a common prefix for all types in the assembly. For example, EiffelEnvision uses a prefix of " DATA_" for all classes in the .NET assembly System.Data. As a result, the type System.Data.Constraint is available in Eiffel as class DATA_CONSTRAINT.
+
+You'll see a little more about namespaces, assemblies, and Eiffel clusters in [[Type Organization|Type Organization]] .
+
+===Similar Types from Both Libraries===
+
+You may have noticed a similarity in the names and descriptions from the Eiffel Base Library and those from the .NET "mscorlib" library. This is not by accident. The Eiffel class STRING is a different class from the .NET type System.String , which Eiffel programmers see represented as Eiffel class SYSTEM_STRING . There is more on this subject in [[Similar Types Occurring in Both Libraries|Similar Types Occurring in Both Libraries]] .
+
+==Eiffel Feature Names==
+
+By convention, feature names in Eiffel use all lower case characters, and like class names, words are separated by underscore. Also as with class names, the names of members from .NET assemblies will be represented in a form that complies with the Eiffel convention.
+
+Let's look at some simple examples. First some feature names from the Eiffel Base Library.
+
+to_upper
+
+ From class STRING: Converts to upper case.
+
+item_double
+
+ From class RANDOM: The current random number as a double between 0 and 1
+
+
+
+Now check out these member names from the .NET "mscorlib" type library. These have been made available to Eiffel for .NET programmers in the Eiffel convention. Following the Eiffel name, you see their .NET member name and type name.
+
+to_upper
+
+ Member ToUpper from typeSystem.String
+
+ Returns a new System.String with the same content as the target, except all upper case.
+
+next_double
+
+ Member NextDouble from type System.Random
+
+ A double-precision floating point number greater than or equal to 0.0, and less than 1.0.
+
+
+
+So, Eiffel feature names, and the names of .NET members made available to Eiffel for .NET programmers, are all lower case with words separated by underscores.
+
+==Overloaded .NET Member Names==
+
+The .NET object model allows overloading of function names. This means that a .NET type can support multiple functions with the same name, that vary only by the types of the arguments they accept. For example, the .NET type System. Text. StringBuilder supports nineteen overloaded versions of the Append function. Here are a couple of examples, in their .NET forms:
+
+.NET function signature: Append(System.String)
+
+Member of type System.Text.StringBuilder
+
+ Appends a copy of the specified string to the end of this instance.
+
+.NET function signature: Append(System.Char)
+
+Member of type System.Text.StringBuilder
+
+ Appends the string representation of a specified Unicode character to the end of this instance.
+
+
+
+The Eiffel language does not allow overloading routine names. That means that you cannot code multiple routines with the same name in a single class. That in itself is not a problem. But it also means that to work in the .NET environment, where overloading is allowed some compromise has to be made. So, what happens is this: if you are programming in Eiffel for .NET and you are using types from a .NET assembly, those types will be presented to you as if they are Eiffel classes. We have already seen that the type and feature names will be shown in the Eiffel naming convention. With overloaded feature names, the presentation will use name augmentation to disambiguate the overloaded versions. What you see is a distinct feature name for each overloaded version. The basic feature name is augmented by adding the types of its respective arguments, separated by underscore.
+
+Let's look again at the two Append functions from System.Text.StringBuilder .
+
+.NET function signature: Append(System.String)
+
+Known to Eiffel as: append_string (value: SYSTEM_STRING)
+
+Member of type System.Text.StringBuilder, known to Eiffel as STRING_BUILDER
+
+ Appends a copy of the specified string to the end of this instance.
+
+.NET function signature: Append(System.Char)
+
+Known to Eiffel as: append_character (value: CHARACTER)
+
+Member of type System.Text.StringBuilder, known to Eiffel as STRING_BUILDER
+
+ Appends the string representation of a specified Unicode character to the end of this instance.
+
+
+
+The overloading story does not end quite yet. The .NET object model allows the overloading of constructors. This issue will be discussed in the section Constructors and Creation Procedures.
+
+==.NET Properties as Eiffel Features==
+
+Properties in .NET provide:
+* the opportunity to '''strengthen encapsulation,''' because values cannot be receive assignment without executing the property's "set" code
+* '''uniform access ''' queries because properties are queries, but unlike previous C-style OO languages in which properties did not exist, if a property is used in programming a client class, the programmer does not need to know whether the data provided by the property was done so from memory or through computation. This leaves the producer of the class with the property the latitude to change the implementation without breaking existing clients.
+
+In Eiffel, the same goals are fulfilled, but a little differently. Simple attributes are well-encapsulated, because the Eiffel language does not allow direct assignment to them from outside the control of their class. So any assignment of the form x . f := y is not valid in Eiffel. To allow client to set values of the attribute f , the producer of the class of which x is an instance would have built a command (a " set_ " procedure) to do so. Then the code in a client to set f would look like this: x . set_f ( y ).
+
+Uniform access is achieved in Eiffel through the way in which clientssee features which are queries. The code " print ( x . count )" applies the query count to the object attached to x and prints the result. You cannot tell by looking at this code whether count is an attribute or a function, that is, whether the count is returned from memory or through computation. In fact, it could be either, but that is a matter for its producer to deal with. As reuse consumers the implementation of count is not important to us ...but the fact that the producer can change the implementation without causing our code to need modification is very important to us.
+
+Because Eiffel does not support properties directly, the propertiesof typeswhich Eiffel for .NET programmers usefrom .NET assemblies have to be mapped to Eiffel features.
+
+In order to ask for the property's current value (technically, receiving the result of the property's get routine), a query feature is generated for the property. The query will be namedthe Eiffel name of the property.
+
+As noted above, setting the value of a property cannot be done in Eiffel as it is done in C# and VB.NET because Eiffel disallows assignments of the form x . f := y . So, for each writable property, an Eiffel command feature is available to set the value of the property. The name for this command will be set_ followed by the Eiffel name for the property.
+
+As a result, the code for using a .NET property looks very much like the code to use an Eiffel attribute. In the following code fragment, an instance of the type System.Windows.Forms.Form which is available in Eiffel for .NET as WINFORMS_FORM is used by an Eiffel client. System.Windows.Forms.Form has a property Text which is of type System.String . Here the Text property is being set using the set_text feature, and then being recalled by using the query text .
+
+ local
+ my_window: WINFORMS_FORM
+ my_string: SYSTEM_STRING
+ do
+ create my_window.make
+ my_window.set_text (my_window_title) -- Set Text property
+ my_string := my_window.text -- Query Text property
+ .
+ .
+ end
+
+
+==Static Features in .NET==
+
+In the .NET object model it is possible for certain members of a type to be "static". When these members are used, they are used without an instance of the class as a target. In essence, they are called on the class itself.
+
+In Eiffel for .NET, these staticmembers will made available with feature names derivedusing the same conventions as ordinary features, but applying them will be a bit different.
+
+There is not a concept analogous to static members in Eiffel. The model for object-oriented computation in Eiffel specifies that whenever feature application takes place, there must be an object, i.e. an instance of some class, that serves as a target.
+
+In order to use .NET types that include static members, a special syntax has been added into Eiffel for .NET. The following example uses this syntax to call a static function:
+
+ local
+ my_window: WINFORMS_FORM
+ do
+ create my_window.make
+ my_window.set_text (my_window_title)
+ .
+ .
+ feature {WINFORMS_APPLICATION}.run_form (my_window)
+ end
+
+
+
+The type System.Windows.Forms.Application is used here. It is available to Eiffel under the name WINFORMS_APPLICATION . The static member being used is Run , in particular the overloaded version of Run which takes an argument of type System.Windows.Forms.Form . That version is available in Eiffel under the name run_form .
+
+The important thing to see here is that when you need to apply a static member, you introduce the call with the keyword feature . Then enclose the type name in braces and apply the feature as if it were targeted to an object. This isfairly close to the way that the call would be made in C#, where the feature name would be applied to the type name, versus a target object:
+
+{
+ Form my_window;
+ my_window = new Form();
+ my_window.Text = "Hello World!";
+ .
+ .
+ Application.Run(my_window); // This is C#
+}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-net-terminology.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-net-terminology.wiki
new file mode 100644
index 00000000..a42ebcd1
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-net-terminology.wiki
@@ -0,0 +1,171 @@
+[[Property:title|Eiffel for .NET Terminology]]
+[[Property:weight|1]]
+==Eiffel Terminology Defined for C# and VB.NET Programmers==
+
+Eiffel programmers feel that it is important to have a set of precise terms with which to communicate about our method of software development. Like everything else in Eiffel, the use of certain terms is not accidental. They were chosen carefully to impart particular meaning. Many of the Terms that Eiffel programmers use are different from those used by developers using other object-oriented languages. But that does not mean that their meanings will be foreign to you. If you have some understanding of object-oriented technology, you will find that in many cases the Eiffel terms describe concepts with which you were already familiar, just under different names, and possibly with slightly different meanings.
+
+The intention of this glossary is to give you a list of these terms with extended definitions that will relate the Eiffel terms to language with which you may be more familiar. Also, you will find an occasional term which comes from other programming cultures but is not used in Eiffel.
+{|
+|-
+| Term
+| Definition
+|-
+| Ancestors
+| The set of Classes from which a particular Class Inherits, including the Class itself. Somewhat analogous to Bases and Interfaces in C# and VB.NET (see Proper Ancestors).
+|-
+| Argument
+| An object which is passed to a routine. Called a Parameter in C# and VB.NET.
+|-
+| Assertion
+| A declaritive expression that evaluates to true or false. Assertions in Eiffel are of different types and are used primarily for expressing software specification to potential Reuse Consumers and ensuring that executing software complies with specification. Any violation of an assertion causes an exception, and is generally indicative of a defect in the software system.
+|-
+| Attribute
+| A Feature which represents storage used in every instance of a class. Used like a Field member in C#.
+|-
+| Class
+| Software text which is the static definition of a Type (or the pattern for a Type in the case of a Generic Class). Used in very nearly the same way as in C#. In C# Classes are used for reference types and Structures for value types. In Eiffel, Classes are used for both, but see Expanded Class.
+|-
+| Class invariant
+| An Assertion on a Class which defines the valid or stable state for objects which are instances of the Class. All instances of the Class must comply with the Class Invariant at any time that they are accessible to Clients.
+|-
+| Client
+| A Class whose role is that of Client in a Client/Supplier Relationship with another Class.
+|-
+| Client/Supplier relationship
+| One of the two Relationships that can exist between Classes. Client/Supplier is characterized by a situation in which one Class, called the Client, has or uses, instances of the other Class, called the Supplier. For example, if class "X" declares an entity "y" of type STRING, then Class X becomes a Client to Class STRING as a result. At the same time, Class STRING becomes a Supplier to class X.
+|-
+| Cluster
+| A group of classes (or recursively, clusters) which share some criteria which justifies their being grouped together. Classes are usually clustered together because they model similar entities or have similar functionality. For example, in the Eiffel Base Library, there is a cluster called "structures" which contains clusters for data structures. One cluster is "list" which contains classes like LINKED_LIST and TWO_WAY_LIST. Another "structures" cluster is "dispensers" which contains classes like "ARRAYED_STACK" and "PRIORITY_QUEUE". When .NET assemblies are made available to Eiffel programmers, each assembly is viewed as a cluster.
+|-
+| Command
+| A Class Feature which can change the state of the instance to which it is applied, and does not return a result. It is the Reuse Consumer's view of a Procedure.
+|-
+| Contract
+| Like a contract between human parties, a software Contract is a formal agreement between software components, Classes in the case of Eiffel. The contract is written in the Assertions of a Supplier Class and specifies in precise terms those conditions with which potential Clients may interact with the Supplier. The contract for a particular Class is composed of the contracts for each Exported Routine of the Class as well as the Class Invariant.
+|-
+| Creation Procedure
+| A Procedure which can be used to initialize and instance of a Class. Similar to a Constructor in C# or VB.NET, but slightly different. A Creation Procedure can be applied when an object is being created, but can also be applied later to reinitialize an existing object (such is not the case with Constructors). Also, Creation Procedures are responsible for ensuring that newly created objects comply with their Class Invariants.
+|-
+| Deferred Class
+| A class which has at least one Deferred Feature. The term "Deferred" is used in the Eiffel culture like the term "Abstract" in .NET. Like an abstract class in C# or VB.NET, it is not possible to make direct runtime instances of a Deferred Class.
+|-
+| Deferred feature
+| A Class Feature which has not implementation. Like a virtual method in C#. Can apply to Commands or Queries.
+|-
+| Descendents
+| The set of all Classes which Inherit from a particular Class, including the Class itself. Somewhat analogous to subclasses in C# and VB.NET (see Proper Descendants).
+|-
+| Design by contract
+| A method of developing software in which a System is composed of a set of interacting Classes which cooperate based upon precisely defined Contracts.
+|-
+| Direct instance
+| A runtime Object of some type, based directly on the definition from a specific Effective Class. See Instance for more information. Usually used in conjunction with the class name, e.g. "an instance of class POLYGON".
+|-
+| Effective class
+| A Class which has no Deferred Features. Only if a Class is Effective can it have direct runtime instances. Effective classes are called Concrete Classes in some programming cultures.
+|-
+| Eiffel Metadata Consumer
+| Applicable to Eiffel for .NET only, this is a mechanism that works behind the scenes to make Types from .NET assemblies available to Eiffel programmers. The Metadata Consumer reconciles the differences between the naming conventions of Eiffel and .NET by providing an Eiffel compliant view of the Types in .NET assemblies.
+|-
+| Expanded Class
+| Like a value type in C#, but with some restrictions. .NET value types are viewed to Eiffel programmers as Expanded Classes. For reference types, an object field holds a reference to a runtime object (or is Void). For value types, the object field holds the fields of the runtime object. A Type based on an Expanded Class is an Expanded Type.
+|-
+| Exported feature
+| A Feature which is available to Client Classes. Analogous to "public" in C# and VB.NET. However, Exporting in Eiffel has fine granularity. It is possible to make certain Features available to Clients of all types or only to Clients which conform to certain named Classes (vs Public, Protected, Private)
+|-
+| Feature
+| Any of a Class's Attributes or Routines. Used similarly to the term Member as in C#. In Eiffel class features can be only Attributes or Routines.
+|-
+| Feature Application
+| The process of using the Class Features on instances of the Class. The model for Feature Application is "x.f(a,...)" where "x" is an entity which will be attached to some object at runtime, "f" is some Feature of the Class on which x is based, and "a,..." is an optional list of arguments which may be appropriate for some Routines. Feature "f" is "applied" to the object attached to "x". Feature Application may involve calling Routines, or may only involve returning the value of an Attribute from memory. Feature application is sometimes called "feature call".
+|-
+| Function
+| A Routine that returns a result. In C# function results can be typed as "void", meaning that there is no result returned. Eiffel functions cannot be typed "void" (see Procedure). All Functions must specify a result type. Of course, if the result type is a reference type, there could be cases in which the reference resulting from some specific call might be Void.
+|-
+| Generic Class
+| A Class which is written using parameters to represent other Classes or Types to enhance its reusability. For example, the Class LINKED_LIST [G] is a generic class in which "G" represents some other Class. So, LINKED_LIST is written independent of the items an instance of the list will hold. We cannot declare a LINKED_LIST without specifiying a Class to substitute for "G". If we want a list of cats we can declare one by using the Type: LINKED_LIST [CAT]. Generic Classes are not currently implemented in .NET, so there's no corresponding concept in C#.
+|-
+| Inheritance
+| One of the two Relationships that can exist between Classes. If Class B inherits from Class A, then every feature in Class A is potentially available to instances of Class B. Also, when ever an instance of Class A is required, an instance of Class B will suffice. Inheritance is used in Eiffel much the same as in C#. The Eiffel model allows full, controlled multiple inheritance, though. Eiffel Classes may inherit from multiple Concrete Classes and name clashes are handled through a process called Feature Adaptation.
+|-
+| Heir
+| The adjacent Proper Descendants of a Class. If class C inherits from class B and class B inherits from class A, then class A's Proper Descendants include B and C, but A's Heirs only include B.
+|-
+| Instance
+| A runtime Object of some type, based on the definition from a Class. Usually used in conjunction with the class name, e.g. "an instance of class POLYGON". In contrast with Direct Instance, an Instance of class POLYGON is a Direct Instance of POLYGON or any Proper Descendant of POLYGON such, perhaps, as RECTANGLE. So it its possible to have Objects which are Instances of Deferred Classes, but it is impossible to have Objects which are Direct Instances of Deferred Classes.
+|-
+| Interface
+| Not supported as such in Eiffel. Used in C# and VB.NET, Interfaces provide sets of specific Class Features which must be effected by any Concrete Class that "implements" the Interface. There is no concept of Interface in Eiffel that is separate from the concept of Class. So, Interfaces from .NET appear to Eiffel programmers to be completely Deferred (abstract) Classes.
+|-
+| Manifest string
+| A quoted string used in source code, for example the "Hello World!" in:
+my_string := "Hello World!"
+This is often called a "literal" string in other languages. In Eiffel, the quoted string "Hello World!" above is, by virtue of its presence, an instance of the Eiffel STRING class. In Eiffel there are manifest constants of other types as well, like numbers coded explicitly in software text, and the keywords True and False as the manifest booleans.
+|-
+| Module
+| A syntactical grouping of software text. Source code is divided into Modules in order to help organize it in some meaningful way or to achieve some goal.
+|-
+| Object
+| An instance of a Class during system execution. As such, Objects only exist at runtime.
+|-
+| Overloading
+| Not supported in Eiffel. Overloading is the ability to have more than one Feature with the same name, varying only by the Types of its Arguments. Overloading is supported by the underlying object model in .NET. As a result many classes in .NET assemblies have overloaded methods. The Eiffel Metadata Consumer disambiguates the overloaded names so that by the time you see them in the Eiffel context they appear no longer to be overloaded.
+|-
+| Parent
+| The adjacent Proper Ancestors of a Class. If class C inherits from class B and class B inherits from class A, then class C's Proper Ancestors include A and B, but C's Parents only include B.
+|-
+| Postcondition
+| An assertion coded on a Routine which defines the conditions will be true upon successful completion of the Routine. It is the responsibility of the Routine to ensure that the Postcondition holds after the Routine executes.
+|-
+| Precondition
+| An assertion coded on a Routine which defines the conditions under which the Routine can complete successfully. It is the responsibility of the Client to ensure that the Precondition holds before attempting to call the Routine.
+|-
+| Procedure
+| A Routine that does not return a result. Much like a "void" function in C#.
+|-
+| Proper ancestors
+| The set of all Classes from which a particular Class Inherits, excluding the Class itself.
+|-
+| Proper descendents
+| The set of all Classes which Inherit from a particular Class, excluding the Class itself.
+|-
+| Query
+| A Class Feature which returns information from the instance to which it is applied. Queries are the Reuse Consumer's view of Attributes and Functions.
+|-
+| Reference type
+| A type whose instances are accessed via a reference. For reference types, an object field holds a reference to a runtime object (or is Void). This is in contrast to value types, in which case, the object field holds the fields of the runtime object. In Eiffel, reference types are based on reference classes, i.e., any class which is not an Expanded Class.
+|-
+| Relationship
+| An association between two classes. There are only two types of Relationships that can exist between classes: Client/Supplier and Inheritance.
+|-
+| Reuse consumer
+| The role a software engineer assumes when in the process of making use of Classes or Types already in existence. As a reuse consumer, the engineer is interested primarily in the specification of those Classes or Types being used, rather than their implementation.
+|-
+| Reuse producer
+| The role a software engineer assumes when in the process or creating a new Class. In this role the engineer attempts to produce a product which will be reusable by him or herself and other engineers in the future. In the Eiffel culture, whenever a software engineer creates a class, it is as a Reuse Producer, and with the thought that each new class has the potential to become reusable.
+|-
+| Root class
+| For any System, the Class which will be instantiated to start the system. Specified by project settings.
+|-
+| Root procedure
+| A Creation Procedure of the Root Class of a System which will be applied to an initial instance of the Root Class at System startup. Similar to Main() in C# and VB.NET, but with the important difference that the fact that a particular Creation Procedure is the Root Procedure for a System is not define in the Class itself as with Main(). Rather, it is specified outside the Class in project settings. This helps Reuse Producers keep Classes more autonomous and therefore potentially more reusable.
+|-
+| Routine
+| A computational Class Feature which is either a Function or Procedure. Routines are the executable parts of a Class. Routines are similar to Methods in C#.
+|-
+| Software specification
+| A statement of how a software element is to be used and what it will do when executed. Ideally, this is stated in terms that do not betray how the software does what it does.In Eiffel, specification is included in the code, rather than a separate document. For a routine, it consists of its call signature and its contract. For a class, it consists of the signatures and contracts for all public features.
+|-
+| Supplier
+| A Class whose role is that of Supplier in a Client/Supplier Relationship with another Class.
+|-
+| System
+| A set of Classes related by the two Relationships which can be compiled to produce an executable.
+|-
+| Type
+| The description of a set of Objects equipped with certain Features.
+|}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-reserved-words.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-reserved-words.wiki
new file mode 100644
index 00000000..8f6ba4ba
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-reserved-words.wiki
@@ -0,0 +1,76 @@
+[[Property:title|Eiffel Reserved Keywords]]
+[[Property:link_title|Eiffel reserved words]]
+[[Property:weight|6]]
+There are 56 language keywords in Eiffel which cannot be used as developer defined identifiers in Eiffel class code.
+
+==Eiffel Reserved Keywords==
+{|
+|-
+| agent
+| alias
+| all
+| and
+| as
+| assign
+| check
+|-
+| class
+| convert
+| create
+| Current
+| debug
+| deferred
+| do
+|-
+| else
+| elseif
+| end
+| ensure
+| expanded
+| export
+| external
+|-
+| False
+| feature
+| from
+| frozen
+| if
+| implies
+| indexing
+|-
+| infix
+| inherit
+| inspect
+| invariant
+| is
+| like
+| local
+|-
+| loop
+| not
+| obsolete
+| old
+| once
+| or
+| prefix
+|-
+| Precursor
+| pure
+| redefine
+| reference
+| rename
+| require
+| rescue
+|-
+| Result
+| retry
+| separate
+| then
+| True
+| TUPLE
+| undefine
+|}
+
+
+
+
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
new file mode 100644
index 00000000..371461d8
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Conventions]]
+[[Property:weight|1]]
+* [[Eiffel for .NET Conventions|Introduction]]
+* [[Eiffel for .NET Terminology|Terminology]]
+* [[Eiffel Class and Feature Names|Conventions and Name Handling]]
+* [[Type Organization|Type Organization]]
+* [[Constructors and Creation Procedures|Constructors and Creation Procedures]]
+* [[Similar Types Occurring in Both Libraries|Similar Types Occurring in Both Libraries]]
+* [[Eiffel Reserved Keywords|Eiffel Language Reserved Keywords]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki
new file mode 100644
index 00000000..4a274916
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki
@@ -0,0 +1,76 @@
+[[Property:title|Similar Types Occurring in Both Libraries]]
+[[Property:weight|5]]
+==Whose String is it anyway?==
+
+Over the last 15 years or so, the Eiffel class libraries have been a source for reusable software components for developers.
+
+The Eiffel Base library contains classes for commonly used objects like different kinds of numbers, strings, files, and data structures.
+
+But there are also libaries of Eiffel classes for sophisticated purposes like lexical analysis and parsing, data access, and graphical user interface development.
+
+Likewise .NET is delivered with assemblies containing thousands of powerful types with similar purposes.
+
+===Working in Both Worlds===
+
+When we build software that has access to both the rich Eiffel libraries and the many useful .NET types, we inevitably run into types from both worlds that have similar names and purposes, but are still different types with different semantics.
+
+===The Case of Strings===
+
+The example of these similar types which will almost certainly get in your face is the string types. You may remember that we looked briefly at the case of the string types in Naming Conventions and Name Handling.
+
+The Eiffel Base Library contains class STRING ; the .NET assembly contains type System.String , which Eiffel for .NETusers see as SYSTEM_STRING . At an abstract level both of these model sequences of characters. But they are not the same type. In fact, they are different in some important ways. For example, instances of System.String are immutable. So you cannot append to an instance of System.String . If you want to build a string by appending, you should use an instance of System.Text.StringBuilder to do the appending, then extract the instance of System.String from it. With STRING it is permissible to append, so you don't need a helper like the System.Text.StringBuilder type.
+
+So the two types are similar at an abstract level, but different semantically. There are reasonable arguments for the design of each.
+
+Many types in the delivered assemblies have properties which are strings or methods which return or take strings as arguments. In all these cases, the strings in question are instances of System.String .
+
+Many classes in the delivered Eiffel libraries have features involving strings, that is attributes which are strings or routines which return or take strings as arguments. In all these cases, the strings are instances of STRING (except for those designed for .NET compliance).
+
+In C# and VB.NET, if you specify a quoted string like "Hello World!" in your code, that string will conform to type System.String . If you do the same in Eiffel, then "Hello World!" will be an instance of STRING . In Eiffel terminology, "Hello World!" appearing in source code is a manifest string.
+
+What all this means to you is that you cannot use an instance of System.String when an instance of STRING is called for, and vice versa. Three out of four of the executable lines in the following code sample are invalid:
+
+ local
+ my_string: STRING
+ my_system_string: SYSTEM_STRING
+ do
+ my_system_string := "Hello World!" -- Invalid
+ my_string := "Hello World!" -- Valid
+ my_string := my_system_string -- Invalid
+ my_system_string := my_string -- Invalid
+ .
+ .
+ end
+
+
+To handle this issue, the Eiffel for .NET class STRING has two features which can be used when a string of the other type is needed.
+
+The first of these features is a query to_cil which returns an object of type System.String which has a sequence of characters equivalent to that of the STRING to which to_cil is applied. The to_cil can be applied to manifest strings by enclosing the manifest string in parentheses.
+
+The other feature is a creation procedure named make_from_cil which takes as an argument an instance of System.String and initializes its target STRING with a sequence of characters equivalent to that of the argument.
+
+In the following sample, we use these features of STRING to make all the lines from the previous sample valid.
+
+ local
+ my_string: STRING
+ my_system_string: SYSTEM_STRING
+ do
+ my_system_string := ("Hello World!").to_cil -- Valid
+ my_string := "Hello World!" -- Valid
+ my_string.make_from_cil (my_system_string) -- Valid
+ my_system_string := my_string.to_cil -- Valid
+ .
+ .
+ end
+
+
+{{note| '''Note:''' As shown in the above example, it is necessary to apply to_cil to a manifest string if you are assigning it to a System.String or passing it as an argument where a System.String is called for.
+This is expected to change in a future release. It shall become unnecesary to apply to_cil to manifest strings. Instead, whether a STRING or System.String is needed will be determined by the context in which the manifest string is being used, and the proper type of object will be generated. }}
+
+===Other Similar Types===
+
+There are many other cases of types available from the .NET assemblies which have similar purpose and semantics to those found in the Eiffel libraries. Fortunately, there is none that you will have to deal with as often as strings.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/type-organization.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/type-organization.wiki
new file mode 100644
index 00000000..1af97921
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/type-organization.wiki
@@ -0,0 +1,55 @@
+[[Property:title|Type Organization]]
+[[Property:weight|3]]
+In any comprehensive object-oriented system, the act of programming results in creation of new data types. There must be a way of organizing these types and/or their static representation as classes. This section tells you how classes are organized in Eiffel and in .NET, and how these organization methods are used together.
+
+==Eiffel Clusters==
+
+Eiffel classes are grouped in clusters. These clusters of classes ordinarily share some commonality of functionality or purpose. In other words,the classes in a particular cluster may provide the same sorts of capabilities or relate to a single software model. In the Eiffel Base Library there is a cluster called list which contains classes which implement different types of lists, for example, ARRAYED_LIST , LINKED_LIST , SORTED_TWO_WAY_LIST , TWO_WAY_CIRCULAR . At an abstract level all these classes are related to the software model of the notion of "list".
+
+The cluster list is actually a subcluster of the cluster structures which contains clusters other than list related to data structures other than lists. Eiffel convention dictates that a cluster should either contain classes or subclusters, but not both.
+
+So clusters serve both to categorize and locate classes. So, class LINKED_LIST can be described as a basic library class implementing a data structure, more particularly a list. As such, it can be found in the Base Library, in cluster structures in subcluster list .
+
+==.NET Namespaces and Assemblies==
+
+In .NET, types (the language independent, compiled form of classes) are stored in "assemblies". So, we locate a type we want to use by referencing the assembly in which it resides.
+As .NET programmers, we think of types as being categorized by namespace. For example, we view the type System.Windows.Forms.TextBox as the TextBox type in the context of the windows forms namespace ( System.Windows.Forms ). Particularly, this is in contrast to type System.Web.UI.TextBox which is a TextBox for web forms. As it relates to making .NET types usable by Eiffel, the important thing to understand is that the real .NET type name is the fully qualified type name, including the namespace. Namespaces are simply a bit of "syntactic sugar" that keeps us from having to repeat the entire type name every time we use it in source code.
+===.NET Assemblies Available to Eiffel===
+When types from .NET assemblies are made available to Eiffel programmers, each assembly is mapped to a cluster. So all the types in an assembly appear as if they were Eiffel classes in a cluster which corresponds to the .NET assembly.
+To summarize, as you learned in Naming Conventions and Name Handling, unambiguous Eiffel-style names are made available for the.NET types in an assembly. The assembly is represented to Eiffel for .NET programmers as a cluster of classes. The process of name derivation is based upon a portion of the .NET type name, possibly augmented with a prefix to ensure uniqueness.
+
+===Assemblies Built with Eiffel===
+
+The object model for which Eiffel was designed differs in some ways from the .NET object model. Importantly, Eiffel supports the facilties of full, controllable multiple inheritance, and genericity, among other things, that the inherent .NET object model does not. That does not mean that these things cannot work in .NET. Indeed they can, and they make Eiffel for .NET very powerful. But, they do make things look a little different.
+
+When you compile Eiffel for .NET, the result is a .NET assembly; either an executable system, or a library of potentially reusable data types. Because the object model for Eiffel is different from that of .NET, the assembly resulting from a compile is different in some ways.
+
+First an assembly built using Eiffel for .NET will likely contain lots of types and interfaces. This is because as you use a class from the Eiffel libraries, say class STRING , all the classes upon which STRING depends ( STRING 's suppliers and ancestors) must also be included in the assembly. That's because the Eiffel libraries, unlike the Microsoft .NET libraries like mscorlib and System.Data , are not distributed as shared type libraries.
+
+Another thing you may notice is that each Eiffel class you produce is represented by three entities in the assembly ... two classes and an interface. So, if you produce a class called GUARD_DOG , then in the assembly you'd see an interface called GuardDog , a class called Impl.GuardDog , and a class called Create.GuardDog . Again, this is done for reasons that concern the differences in the object models between Eiffel and .NET.
+
+The GuardDog interface is what you use when you declare an entity or variable of that type. The objects attached to that entity at runtime will be of the type Impl.GuardDog . You create an instance of Impl.GuardDog and attach it to an entity of type GuardDog by calling a routine in the factory class Create.GuardDog . The factory routines will almost always have names that begin with the word " Make ", and represent the creation routines of Eiffel the classes. So in the case of using an instance of GuardDog from a C# class, the code would like this:
+
+{
+ GuardDog aGuardDog = Create.GuardDog.Make(); //Create an instance
+ aGuardDog.RollOver(); // Apply a feature
+}
+
+
+This object creation model accounts for some of the differences between constructors in .NET and creation procedures in Eiffel. These differences will be discussed in more detail in Constructors and Creation Procedures.
+
+Another advantage is that it provides a syntax that is similar to that used to create objects in Eiffel. An Eiffel for .NET client to the class GUARD_DOG might use the following code to create and use an instance.
+
+ local
+ a_guard_dog: GUARD_DOG -- Declare an entity of the type
+ do
+ create a_guard_dog.make -- Create an instance and attach to entity
+ a_guard_dog.roll_over -- Apply a feature
+ end
+
+
+You may have noticed in these examples that even though the type GuardDog was compiled from an Eiffel class, when the C# client uses GuardDog , it uses what would be considered the .NET naming convention for the type GuardDog (vs. GUARD_DOG ) and the method name RollOver (vs roll_over ). What happens here is that when assemblies are produced from Eiffel classes, by default .NET naming standards are used in the assembly.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki
new file mode 100644
index 00000000..bb5ac50f
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki
@@ -0,0 +1,69 @@
+[[Property:title|Eiffel for .NET Limitations]]
+[[Property:link_title|Eiffel for .NET Integration]]
+[[Property:weight|3]]
+==Differences between Eiffel and Eiffel for .NET==
+
+===Limitation of Eiffel for .NET in version 5. 5===
+
+Most of the Eiffel mechanisms are supported in 5. 5. All missing features listed below are planned for addition in future releases:
+* No creation of Eiffel expanded class support
+* Partial implementation of generic conformance (same as what was supported up to and including the 4.2 release of the Eiffel development environment).
+
+Eiffel for .NET supports:
+* Multiple Inheritance
+* Design By Contract
+* Exception handling
+* Genericity
+* Covariance
+* Compilation of any existing Eiffel libraries as long as it does not include C externals that call into the Eiffel Software C runtime
+
+===Added to Eiffel and Eiffel for .NET===
+
+The following syntax can be used to declare .NET custom attributes on Eiffel entities (features and classes):
+
+ empty: BOOLEAN is
+ indexing
+ description: "Is Current empty?"
+ attribute: create {OBSOLETE_ATTRIBUTE}.make_obsoleteattribute_1 ("Use `is_empty' instead") end
+ obsolete
+ "Use is_empty instead"
+ do
+ Result := is_empty
+ end
+
+
+The previous example shows the declaration of the obsolete feature empty . The custom attribute defined by OBSOLETE_ATTRIBUTE is used to ensure that any consumer of the resulting assembly will see the feature as being obsolete. The custom attribute is defined in the indexing clause attribute . The definition consists of a creation expression that creates the custom attribute with the right parameters.
+
+==Differences between Eiffel for .NET and .NET==
+
+===Covariance===
+
+The CLR (Common Language Runtime) does not support covariance due to the type safety issue that full covariance implies (known as polymorphic CATCALLS in Eiffel). Although very rare, CATCALLS are not suitable to .NET where safety is one of the primary goals.
+
+Eiffel for .NET implements a safe variant of covariance that will always perform a check on the types to avoid a CATCALL. So when a CATCALL is going to be performed a `Invalid Cast Exception' will be raised by the CLR instead of an unexpected behavior as it is currently done in Eiffel.
+
+Another advantage of Eiffel for .NET's implementation of covariance is that it can be easily understood by CLS compliant consumer tools. These tools will actually benefit from the Eiffel for .NET covariance.
+
+===Genericity===
+
+The CLR does not support generics at all, so that the following Eiffel for .NET classes:
+* LIST [ANY]
+* LIST [INTEGER]
+
+will actually be generated as:
+* LIST_ANY
+* LIST_Int32
+
+Meaning that if one wants to reuse an Eiffel generic class from another language than Eiffel for .NET, one has to use either LIST_ANY or LIST_Int32 .
+
+===Enum types===
+
+Eiffel for .NET supports .NET enum types implicitly. From the point of view of Eiffel, they are just considered as expanded classes. The only difference is in the code generation. Eiffel for .NET cannot declare new enum types yet.
+
+===ByRef===
+
+Eiffel does not have the notion of `byref' argument passing. At the moment, Eiffel for .NET cannot call nor can it redefine a feature that has a byref argument.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/adding-class-features.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/adding-class-features.wiki
new file mode 100644
index 00000000..3cfbda16
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/adding-class-features.wiki
@@ -0,0 +1,531 @@
+[[Property:title|Adding Class Features]]
+[[Property:weight|2]]
+The features of a class make it useful. They are the things that objects which are instances of the class have and can do.
+
+It is during the process of adding class features that we relate a class we are producing to other classes via the client/supplier relationship.
+
+It is when we add features to a class that we can build the executable code that makes things happen.
+
+==Categorizing Features==
+
+In Eiffel, we have several ways of thinking abstractly about features and categorizing them. As you saw in [[Eiffel Classes|Eiffel Classes]] the feature clause gives us a way to group features in the software text. We have ways to group features more generally, too. Here are some.
+
+===Source===
+
+You remember the example class from [[Eiffel Classes|Eiffel Classes]] :
+
+indexing
+ description: Objects that model lists
+ revision: $Revision: 1.5 $
+
+class
+ OLD_FASHIONED_LIST [G]
+
+obsolete "This class is obsolete, use LINKED_LIST [G] instead"
+
+inherit
+ DYNAMIC_LIST [G]
+
+create
+ make
+
+feature -- Initialization
+
+ make is
+ -- Create an empty list.
+ do
+ before := True
+ ensure is_before: before
+ end
+
+feature -- Access
+
+ item: G is
+ -- Current item
+ do
+ Result := active.item
+ end
+
+ first: like item is
+ -- Item at first position
+ do
+ Result := first_element.item
+ end
+ (other features omitted)
+
+invariant
+ before_constraint: before implies (active = first_element)
+ after_constraint: after implies (active = last_element)
+end
+
+
+
+The example shows three of the features ( make , item , and first ) coded directly in the class. These features (and the ones omitted from the example in the interest of brevity) may not be the only features of the class OLD_FASHIONED_LIST . In fact we can just about guarantee that there are other features of this class. Remember the inheritance part of the class:
+
+ inherit
+ DYNAMIC_LIST [G]
+
+
+This means that every feature in DYNAMIC_LIST will be a feature of OLD_FASHIONED_LIST . So one way we can think of features is by their source.
+* Immediate features are those that are introduced by a class itself.
+* Inherited features are those that come to the class from its proper ancestors.
+
+We will see more about this in [[Inheritance|Inheritance]] .
+
+===Implementation Type===
+
+Whenever we are building a class in Eiffel, we are potential reuse producers. As such, we can categorize the features of a class based on the three types of feature implementation:
+* Attribute
+* Function
+* Procedure
+
+Attributes are those features which occupy storage in an instance. When you code an attribute in a class that you are producing, that class becomes a client to the class of the attribute. This is the most common way to establish a client/supplier relationship between the classses. Client/supplier is one of the two relationships that can exist between classes.
+
+Functions and procedures are the computation features, that is they are features that involve executable code. Functions and procedures together are themselves categorized as routines.
+
+Also, from the producer standpoint we may view features as whether they work from memory or through computation:
+* Memory
+** Attribute
+
+* Computation
+** Function
+** Procedure
+
+
+This view can be valuable when a producer is considering performance issues. For example, if there is some class function called count , a producer might investigate whether it is better to leave count as a function, computing it each time the feature is applied, or to change it to an attribute and compute it less often.
+
+===Usage===
+
+A times we find it appropriate to categorize features by how we use them. Specifically, as:
+* Query
+** Attribute
+** Function
+
+* Command
+** Procedure
+
+
+Queries are features that, when applied to an instance, provide a value in response. Commands instruct an intance to take some action, but do not return a value. Seeing features as either queries or commands is of primary interest to reuse consumers. But as producers there are important reasons for ensuring that when we implement a feature, we implement it as a query or as a command, but not both. We will see more about this in [[Design by Contract and Assertions|Design by Contract and Assertions]] .
+
+==General Syntax of Features==
+
+===More Sample Features===
+
+Here is another example class. Again this class contrived, so it does not do anyhing worthwhile except show you what different types of features look like. This class has an attribute and a constant attribute, and functions and procedures both with and without arguments.
+
+class
+ SOME_CLASS
+
+create
+ make,
+ make_with_arguments
+
+feature -- Initialization
+
+ make is
+ -- Creation procedure
+ do
+ an_attribute := 5
+ end
+
+ make_with_arguments (hour: INTEGER; minute: INTEGER; second: INTEGER) is
+ -- Another creation procedure
+ do
+ an_attribute := second + (minute * 60) + (hour * 3600)
+ end
+
+feature -- Access
+
+ an_attribute: INTEGER
+ -- An attribute of type INTEGER
+
+ another_attribute: INTEGER is 46
+ -- A constant attribute
+
+ a_function: STRING is
+ -- A function without arguments
+ do
+ Result := an_attribute.out
+ end
+
+ another_function (an_int: INTEGER): INTEGER is
+ -- A function with arguments
+ do
+ Result := an_attribute + an_int
+ end
+
+feature -- Basic Operations
+
+ a_procedure is
+ -- A procedure with no arguments
+ do
+ an_attribute := an_attribute + 5
+ end
+
+ another_procedure (an_int: INTEGER; another_int: INTEGER) is
+ -- A procedure with arguments
+ do
+ an_attribute := an_attribute + an_int + another_int
+ end
+
+end -- Class SOME_CLASS
+
+
+===Feature Declaration===
+
+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. }}
+
+* 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)
+* The actual value of the feature (in the case of a constant attribute)
+* The implementation code (in the case of a function or procedure)
+
+Let's dissect one feature and identify its parts:
+
+ another_function (an_int: INTEGER): INTEGER is
+ -- A function with arguments
+ do
+ Result := an_attribute + an_int
+ end
+
+
+In this feature:
+* "another_function" is the feature's name.
+* "(an_int: INTEGER)" is the argument list.
+** "an_int" is the name of the first argument
+** "INTEGER" is the type "an_int"
+
+* "INTEGER" (after the argument list) is the feature's type.
+* "do " introduces the implementation code.
+* "Result := an_attribute + an_int" is an instruction.
+{{warning| '''Note:'''This feature is a function. As a consequence the computation uses the keyword "Result" as an entity name for the value to be returned by the function }}
+
+* "end" ends the feature declaration
+
+==General Structure of Routines==
+
+As you can imagine, the possibilities for coding routines are more complex than those for coding attributes. Routines always contain the keyword "is" after the first part of the feature declaration. The part after the "is" is called the routine part.
+
+The routine part is made up of the following sections:
+* [[#Header Comment|Header Comment]]
+* [[#obsolete|Obsolete]]
+* [[#Precondition|Precondition]]
+* [[#Local Declarations|Local Declarations]]
+* [[#Routine Body|Routine Body]]
+* [[#Postcondition|Postcondition]]
+* [[#Rescue|Rescue]]
+
+All of the sections except the Routine Body are optional.
+
+Here is another feature, a routine, which has all of these except obsolete and rescue.
+
+ insert_text_header_item (a_label: STRING;
+ a_width, a_format: INTEGER; insert_after_item_no: INTEGER) is
+ -- Insert a text item to the header control
+ -- after the `insert_item_item_no' item.
+ require
+ exists: exists
+ label_not_void: a_label /= Void
+ insert_after_item_no_positive: insert_after_item_no >= 0
+ local
+ hd_item: WEL_HD_ITEM
+ do
+ create hd_item.make
+ hd_item.set_text (a_label)
+ hd_item.set_width (a_width)
+ hd_item.set_format (a_format)
+ insert_header_item (hd_item, insert_after_item_no)
+ ensure
+ item_count_increased: item_count = old item_count + 1
+ end
+
+
+Using this example, let's identify and discuss the different sections.
+
+===Header Comment===
+
+ -- Insert a text item to the header control
+ -- after the `insert_item_item_no' item.
+
+
+Although the feature's header comment is optional, most Eiffel programmers and their technical managers feel that it should never be omitted. Header comments are included by some language processing tools in specialized views of classes. Header comments are almost always short, usually no more than a few lines. Header comments serve to provide a natural language description of what the feature will do (in the case of features that are commands) or what information it provides (in the case of queries).
+
+===Obsolete===
+
+The feature insert_text_header_item is not obsolete ... but if it were it would include an obsolete clause. This works much like the obsolete part for classes that we saw in [[Eiffel Classes|Eiffel Classes]] : the keyword " obsolete " followed by a manifest string which bears a message to potential reuse consumers:
+
+===Precondition===
+
+ require
+ exists: exists
+ label_not_void: a_label /= Void
+ insert_after_item_no_positive: insert_after_item_no >= 0
+
+
+The precondition part of a feature is introduced by the keyword " require ". It contains a set of assertions which define the state necessary for the correct execution of a routine. We will see more about assertions in [[Design by Contract and Assertions|Design by Contract and Assertions]] .
+
+===Local Declarations===
+
+ local
+ hd_item: WEL_HD_ITEM
+
+
+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, hd_item is available as type WEL_HD_ITEM during the computation of feature insert_text_header_item .
+
+{{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. }}
+
+===Routine Body===
+
+ do
+ create hd_item.make
+ hd_item.set_text (a_label)
+ hd_item.set_width (a_width)
+ hd_item.set_format (a_format)
+ insert_header_item (hd_item, insert_after_item_no)
+
+
+This is the routine body for a fairly typical effective, internal routine. It contains the instructions that get the job done for the feature. You may notice that experienced Eiffel programmers rarely write routine bodies that are more than a few lines long. The reason for this is more that just intuitive. This phenomenon will be explained in the section [[Design by Contract and Assertions|Design by Contract and Assertions]] .
+
+There are other forms that a routine body can take. Here are some examples of some others:
+
+====External Routines====
+
+ cwin_tooltips_class: POINTER is
+ external
+ "C [macro ] : EIF_POINTER"
+ alias
+ "TOOLTIPS_CLASS"
+ end
+
+
+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]] . }}
+
+====Once Routines====
+
+ once
+ Result := some_computation
+
+
+This is the routine body of a "once" routine, specifically a "once function". A once routine is introduced by the keyword " once " rather than do . It contains an computational body that executes only the first time it is called. Upon subsequent calls it has no effect.
+
+Once procedures are useful for doing things that for some reason should not be done multiple times.
+
+If the once routine is a function (as the example above), it computes the resulting object on the first call, then on subsequent calls, it returns the object it originally created without executing the computation. Once functions facilitate shared objects which helps us in avoiding globals. A class containing a once function can be inherited by many other classes. The first object to apply the once function causes the resulting object to be created and initialized. Subsequent applications by any other object accesses the originally created instance.
+
+====Deferred Routines====
+
+ deferred
+
+
+The body for a deferred routine is simply the keyword " deferred ". Below is the deferred routine body in the context of an entire feature.
+
+ set_position (new_position: INTEGER) is
+ -- Set `position' with `new_position'
+ require
+ exists: exists
+ valid_minimum: new_position >= minimum
+ valid_maximum: new_position <= maximum
+ deferred
+ ensure
+ position_set: position = new_position
+ end
+
+
+As we learned in [[Eiffel Classes|Eiffel Classes]] a deferred routine has specification, but no implementation. We will investigate deferred classes and features further in [[Inheritance|Inheritance]] .
+
+===Postcondition===
+
+ ensure
+ item_count_increased: item_count = old item_count + 1
+
+
+The postcondition part of a routine is introduced by the keyword " ensure ". The postcondition is a group of assertions which describe the state that must be satisfied upon the successful completion of the routine. We will see more about assertions in [[Design by Contract and Assertions|Design by Contract and Assertions]] .
+
+===Rescue===
+
+Our example feature does not have an explicitly coded rescue part. The rescue, introduced by the keyword " rescue ", provides a routine with a chance to do additional processing in the case that it incurs an exeption during normal processing. We will learn about the rescue clause in the section [[Exception Mechanism|Exception Mechanism]] . Until then, you can see what a rescue part looks like in the feature below.
+
+ bind is
+ -- Bind socket to local address in `address'.
+ require
+ socket_exists: exists
+ valid_local_address: address /= Void
+ local
+ ext: ANY
+ retried: BOOLEAN
+ do
+ if not retried then
+ ext := address.socket_address
+ c_bind (descriptor, $ext, address.count)
+ is_open_read := True
+ end
+ rescue
+ if not assertion_violation then
+ is_open_read := False
+ retried := True
+ retry
+ end
+ end
+
+
+==Making Features Available to Clients==
+
+Remember that when we build classes in Eiffel, we keep in mind the possibility that these classes may eventually become valued, reusable software components. As a result we have a responsibility to make sure that our classes allow clients to use them in a safe and productive fashion. We make available those features that it is appropriate for clients to use, and we hide the rest. In Eiffel we say that a feature that is available to clients is "exported".
+
+Control of the export of features inherited from ancestors is done by using the "export" keyword. Export of inherited features will be discussed in Inheritance.
+
+Control of the export of immediate features (those features introduced in the text of a class) is done with the "feature" clause. We have encountered the feature clause already:
+
+feature -- Access
+
+ an_attribute: INTEGER
+ -- An attribute of type INTEGER
+
+ another_attribute: INTEGER is 46
+ -- A constant attribute
+
+ a_function: STRING is
+ -- A function without arguments
+ do
+ Result := an_attribute.out
+ end
+
+ another_function (an_int: INTEGER): INTEGER is
+ -- A function with arguments
+ do
+ Result := an_attribute + an_int
+ end
+
+feature -- Basic Operations
+
+ a_procedure is
+ -- A procedure with no arguments
+ do
+ an_attribute := an_attribute + 5
+ end
+
+ another_procedure (an_int: INTEGER; another_int: INTEGER) is
+ -- A procedure with arguments
+ do
+ an_attribute := an_attribute + an_int + another_int
+ end
+
+
+A feature clause like the ones in the example above means that all the features that follow, until the next feature clause are exported to clients based on any class. Techically, this
+
+ feature -- Basic Operations
+
+
+is equivalent to
+
+ feature {ANY} -- Basic Operations
+
+
+which means that the following features are available to clients which conform to class ANY . And in Eiffel, ANY is the class from which all other classes inherit. As a consequence all classes conform to ANY .
+
+Inside the braces is a list of classes which are eligible as clients.
+
+ feature {STRING_HANDLER} -- Implementation
+
+
+Features following this example from class STRING will be available to client class STRING_HANDLER and all its proper descendants.
+
+As stated above, you can put a list of class names in the braces:
+
+ feature {CLASS_A, CLASS_B, CLASS_C} -- Semi-private features
+
+
+Often features which are solely for implementation should not be seen or used by clients of any type. You can ensure this by exporting to class NONE , the class from which no other class can inherit:
+
+ feature {NONE} -- Implementation
+
+
+==Eiffel Instructions and Control Structures==
+
+When you begin to write routines in Eiffel, you will need to understand how to write instructions. Fortunately, the set of instruction types you can code is fairly small. Here we will look the most common of these. You will see some more in other topics.
+
+===Creation===
+
+ create hd_item.make
+
+
+We discussed creation procedures and the process of bringing new objects into being in [[Eiffel Classes|Eiffel Classes]] . A creation instruction starts with the keyword " create ". It creates a new object, initialize its fields, may apply a creation procedure, and attaches the object to an entity.
+
+===Procedure Call===
+
+ hd_item.set_text (a_label)
+
+
+The application of a feature to an object constitutes an instruction if the feature is a procedure.
+
+===Assignment===
+
+In Eiffel, assignment syntax is simple. But depending upon the types involved, what actually happens may need some explanation. Assume here that is_open_read is an attribute declared as type BOOLEAN :
+
+ is_open_read := False
+
+
+In this instruction, an attribute of type BOOLEAN named is_open_read is being assigned the value of the manifest boolean " False ". The attribute is_open_read is based on an expanded class BOOLEAN , so that means that the value for False is held in the field for is_open_read . This is in contrast to what happens with reference types.
+
+ my_string := some_other_string
+
+
+In this assignment, we will assume that both entities are type STRING . Because STRING is a reference type, the field for my_string will hold either a reference to an instance of STRING , or it will be Void . When the assignment above executes, then whatever was in the field for my_string is replaced with a reference to the same object that some_other_string refers to.
+
+In summary, for objects based on expanded classes, assignment means assignment of value. For objects based on reference classes, assignment means assignment of reference.
+
+====Conformance====
+
+There is an important rule about assignment in Eiffel. The rule exists to ensure type safety. Consider the following assignment which we would read as " x receives y " or " x gets y ".
+
+ x := y
+
+
+then the rule says that this assignment is valid only if the type of y conforms to the type of x .
+
+The rule is clear enough ... if you know what "conform" means. In the presence of mechanisms like expanded types, inheritance, and genericity, a precise definition of conformance is lengthy.
+
+But we can get by for a while with much less. For now let us be satisfied with this:
+
+Consider the classes in the declarations for x and y .
+
+You might be tempted to say that to achieve "conformance", the classes would have to be the same. And for the case in which the declarations for x and y are expanded classes, you'd be correct. They conform only if they are the same class.
+
+But for reference types, that constraint is unnecessarily restrictive. So, for reference types, the class of y conforms to that x if it is the same class or a proper descendant of that class. This facilitates a powerful idea known as polymorphic attachment that we will see more closely in the section on [[Inheritance|Inheritance]] .
+
+===Conditional===
+
+ if l_c.is_digit then
+ l_state := 2
+ elseif l_c = '-' or l_c = '+' then
+ l_state := 1
+ else
+ l_state := 3
+ end
+
+
+Conditionals in Eiffel use at a minimum the keywords " if ", " then ", and end ".Optionally, they may use the keywords " elseif " and " else ".
+
+===Loop===
+
+ from
+ i := lower
+ until
+ i > upper
+ loop
+ if item (i) /= Void and then v.is_equal (item (i)) then
+ Result := Result + 1
+ end
+ i := i + 1
+ end
+
+
+There is only one structure for loops in Eiffel. In its typical form it uses the four keywords " from ", " until ", " loop ", and " end ". The instructions following the from keyword do any initialization necessary for the loop. After until is a boolean expression which is the exit condition. The loop body after loop is a list of instructions that are executed for every iteration. As you can imagine, something in the loop body should most likely cause the exit condition eventually to become true.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki
new file mode 100644
index 00000000..2382144a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki
@@ -0,0 +1,322 @@
+[[Property:title|Design by Contract and Assertions]]
+[[Property:weight|5]]
+==Motivation: Concerning Correctness==
+
+When you produce an element of software, how do you know that what you produced is correct?
+
+This is a difficult question for anyone to answer. Informally speaking, correct software is software that does what it is supposed to do. That is what makes answering the question so tricky. Before you can have any idea whether the software is correct, you must be able to express what it is supposed to do ... and that proves to be quite difficult itself.
+
+In conventional software engineering, a document called a software specification is written in order to describe what it is that a piece of software is supposed to do. Writers of software specifications tend to pursue one of two approaches: the informal or the formal.
+
+Informal specifications attempt to describe software behavior in the natural languages with which humans communicate on a daily basis. There are problems with this approach. Natural language is not precise. Informal specifications are subject to interpretation and affected by the ambiguities, noise, and contradiction inherent in natural language.
+
+In order to avoid these problems, proponents of formal methods of specification turn to the most precise language they know: mathematics. It may be no exaggeration that the study of formal methods has produced more PhD's in Computer Science than it has well-specified software systems. Still the idea that the precision of mathematics can be brought to bear on the problem of specifying software is quite appealing. But, problems lurk here as well. Formal specifications are difficult and time-consuming to construct and verify against themselves, and most software engineers do not have a working knowledge of the mathematics required to work with formal specifications.
+
+There is one more significant problem with both of these approaches. Even if you have a very precise specification, expressed in elegant text and graphics, and placed carefully in an expensive ring binder, how do you know that the software product actually reflects that specification and vice versa? If either is changed, the other must be as well. This is the document synchronization problem.
+
+===Design by Contract to the Rescue===
+
+Design by Contract (DbC) begins as an implementation of some of the ideas from formal methods and matures into a powerful way of thinking about software. And it does it in a way that is easy for programmers and managers to understand. DbC also puts the software specification into the software document itself which makes it checkable at runtime and eliminates the document synchronization problem.
+
+==Model for Software Correctness==
+
+Design by Contract is built around a model for software correctness that is really pretty simple.
+
+Suppose there is software routine called s . If we were going to test s , we would probably devise some test inputs or test values to be in place when s starts and then observe what things look like after s completes. If they look the way we think they should then that leads us to believe that S is working correctly for those test inputs.
+
+We can generalize and formalize that process a bit, taking it back from testing an into design. If indeed we know what it means for s to be correct, then we should be able to make a statement of any conditions that must be true prior to executing s . That is, we will state the conditions required for it to be possible for s to run correctly. We call this statement of preconditions for success s 's precondition.
+
+Likewise we should be able to make a statement of the conditions that will be true always if s works correctly. This we call s 's postcondition.
+
+As an example, suppose s accepted an argument of type REAL and returned another REAL which was the square root of the argument. The precondition for s would be that the argument could not be less that zero, as there is no real square root for negative numbers. s 's postcondition would be that the result multiplied by itself would yield the value of the original argument (give or take a little to allow for floating point error).
+
+==Assertions in Eiffel==
+
+Each Eiffel feature which is a routine, i.e. a function or procedure, can support one assertion for a precondition and one for a postcondition. We saw where precondition and postcondition fit into the structure of the routine in [[Adding Class Features|Adding Class Features]] . An assertion is expressed as one or more assertion clauses which are logically and -ed together to produce the assertion. Assertions clauses are boolean expressions that evaluate to true or false.
+
+Let's look at another example. Assume you need to produce a class to model a time of day. Each instance of TIME_OF_DAY would hold some particular time of day accurate to the second between 00:00:00 and 23:59:59 inclusive.
+
+As a producer, you would be faced with a decision concerning how to maintain the time internally in each instance. For the purpose of our example, let us consider two alternatives:
+# Keep three instance of INTEGER . One each for hour, minute, and second.
+# Keep one instance of INTEGER representing the time of day as the number of seconds since 00:00:00.
+
+This would be an implementation issue for the producer, because it would not affect the services that TIME_OF_DAY could offer clients. If we have a query called minute the first alternative allows us simply to provide the value from storage. Whereas the second alternative will likely cause us to compute minute each time it is requested. But the service looks and works the same for the client in either alternative.
+
+For now let us assume that we are using the first design alternative. In that case we would code class features for hour , minute , and second .
+
+feature -- Access
+
+ hour: INTEGER
+ -- Hour expressed as 24-hour value
+
+ minute: INTEGER
+ -- Minutes past the hour
+
+ second: INTEGER
+ -- Seconds past the minute
+
+
+Below is the code for a procedure set_second which receives an argument of type INTEGER and sets the value of the second feature to the argurment.
+
+ set_second (s: INTEGER) is
+ -- Set the second from `s'
+ do
+ second := s
+ end
+
+
+The routine is simple enough, but there is a problem with it. Suppose a client calls set_second with an argument whose value is invalid, say 3574. Our routine would just stuff this value into second and we would end up with an instance of TIME_OF_DAY which is invalid. In the days before Design by Contract, as soon as we recognized that this problem exists, we would go into "defensive programming" mode and code some " if " statements inside the routine to validate the argument, before acting.
+
+Consider though what we can do with Design by Contract. We will add a precondition assertion to set_second that expresses the need for valid arguments.
+
+ set_second (s: INTEGER) is
+ -- Set the second from `s'
+ require
+ valid_argument_for_second: 0 <= s and s <= 59
+ do
+ second := s
+ end
+
+
+The precondition is introduced by the keyword " require ". The text " valid_argument_for_second " is the label for the assertion clause. The boolean expression "0 <= s and s <= 59" says that a good value for s will be between 0 and 59 inclusive.
+
+Remember that the precondition specifies those things that must be true if set_second has a chance of working correctly. As such, upon execution, the body of this routine will never be executed if an attempt is made to call it in a state that does not meet its precondition. Instead, the caller will incur a precondition violation exception. We will investigate more about what exceptions mean further in [[Exception Mechanism|Exception Mechanism]] .
+
+So, what about a postcondition? We noted earlier that a postcondition should make a statement of what will be true in the case that the routine does its work correctly. For set_second this means that after it finishes, the query second should have the same value as the argument that was received from the caller. Below is the feature with the postcondition added.
+
+ set_second (s: INTEGER) is
+ -- Set the second from `s'
+ require
+ valid_argument_for_second: 0 <= s and s <= 59
+ do
+ second := s
+ ensure
+ second_set: second = s
+ end
+
+
+The postcondition is introduced by the keyword " ensure ". Here the expression " second = s " makes certain that the routine did actually do the necessary work to ensure that the value of second matches the value of the argument received.
+
+As you look at the postcondition, you may be tempted to think that the one-line body of the routine is so simple as to make the postconditon unnecessary. To answer this concern we need to look again for a moment at software specification.
+
+===Specification of a Routine===
+
+If we remove the instructions from a routine and leave its signature, header comment and assertions, we have a specification for the routine.
+
+ set_second (s: INTEGER) is
+ -- Set the second from `s'
+ require
+ valid_argument_for_second: 0 <= s and s <= 59
+ ensure
+ second_set: second = s
+ end
+
+
+This specification of set_second tells us what is required of reuse consumers if they wish to use set_second and what set_second promises to do for them. Importantly, it does that without revealing how it does it does what it does.
+
+So, this specification view, officially called the contract view, is how consumers of class TIME_OF_DAY would view the feature.
+
+If this is the specification, then haven't we put the cart before the horse? The answer is yes. We have done so to illustrate the problems that assertion-based specification can help solve.
+
+Instead of starting with a routine and adding a specification, we really want to start in accepted software engineering fashion with specification first, and then add implementation. Therefore, the specification you see above would exist before the implementation.
+
+Now back to the concern over whether the postcondition is redundant for this simple one-line routine. Obviously, if this specification exists first, then the postcondition must be there, and it would be silly to remove it later. But, more importantly, suppose that when the producer of the class decided on an implementation, he or she chose the second design alternative we mentioned above. This would mean that the internal state of an instance of TIME_OF_DAY would be only one INTEGER with the number of seconds since midnight. That would mean that the query second would probably be a function that computed seconds from that one INTEGER instead of an attribute.
+
+What would change in the specification of set_second ? Nothing. The implementation for the routine would be more complex, but what it does, setting the second in an instance of TIME_OF_DAY , would stay the same.
+
+In summary, the precondition and postcondition ensure for use that the routine will only execute if called in a state in which the precondition is true, and then will either complete in a state in which the postcondition is true, or cause a postcondition violation exception.
+
+===The Contract for a Routine===
+
+Having assertions on its routines forms a contract between the TIME_OF_DAY class and all potential reuse consumers. The contract is much like a contract in business, with obligations and benefits for both parties.
+* The client's benefits are outlined in the postcondition.
+* The client's obligations come from the precondition.
+* The supplier's obligations are in the postcondition.
+* The supplier's benefits come from the precondition.
+
+We can see the specifics of these by using set_second as an example.
+* The client gets the desired value for seconds set in the instance.
+* The client must provide an argument that is valid for seconds.
+* The supplier must update the instance successfully.
+* The supplier need not risk disaster attempting to process in an invalid state nor waste time validating the argument received from the client.
+
+===Valid State for Instances===
+
+Assertions on TIME_OF_DAY 's routines gives us specification for each routine and guarantees that if the specification of a routine gets violated at runtime we will be served immediately with an exception. This will go a long way toward preventing invalid instances from going unnoticed in a running system and fouling up lots of other stuff.
+
+What will help even more is something called a class invariant. Using the class invariant we are able to state what it means for an instance of a class to be valid, or as it is sometimes put, in a stable state.
+
+The class invariant is an assertion like precondition and postcondition, but there is only one per class. Check [[Eiffel Classes|Eiffel Classes]] to see how the class invariant fits into the class structure.
+
+How would we code the class invariant for TIME_OF_DAY ? An instance would be valid if its hour were between 0 and 23 inclusive, minute were between 0 and 59 inclusive, and its second were between 0 and 59 inclusive. We can code the invariant as shown below.
+
+ invariant
+
+ hour_valid: 0 <= hour and hour <= 23
+ minute_valid: 0 <= minute and minute <= 59
+ second_valid: 0 <= second and second <= 59
+
+
+The name invariant implies that the assertion can never be false ... and that's true up to a point. It's really more like, "it must be true at times when it really counts".
+
+At runtime the invariant must be true for an instance at anytime that the instance is available to clients. In general, this means that the invariant must be true before and after the execution of every exported routine.
+
+As with the assertions on routines, if ever the invariant is not true when it should be, then a class invariant violation occurs.
+
+Remember in the example above, that the features hour , minute , and second are queries, but they could be either attributes or functions.
+
+==The Contract for a Class==
+
+Earlier we saw the contract for a routine. Now we can define the contract for a class as the aggregation of the contracts for all its exported features, plus its class invariant.
+
+In Design by Contract we design based on these contracts. They are the specifications for the modules in our system. We work in a reuse-oriented world. Whenever we produce a class, we produce it with a comprehensive contract which serves as its specification. We build each class with the thought that it may eventually become reusable.
+
+When we are in our reuse consumer role, using existing classes, we tend not to look at the implementations for the classes we use. Instead we look at their contract views. It is there that we find the obligations and benefits of using each class.
+
+==Contracts and Debugging==
+
+We saw earlier that having contracts in the code tends to expose bugs at an early stage of development. It is possible selectively to turn off and on the runtime checking of assertions by changing project settings. Checking assertions does involve processing. More about turn off assertion checking in a moment.
+
+Having contracts on a class gives another advantage when the contract gets broken. The contract tells us whose fault it is. Whenever there is a violation of a precondition, postcondition, or class invariant then the software is out of specification. This situation is called a defect, or bug.
+
+Whose fault is it? If a precondition was violated, then a client class attempted to call a routine in a supplier, but made the call in a state that did not satisfy the supplier's precondition. Therefore the bug is in the client.
+
+If a postcondition was violated, then a client made a call in a state that did satisfy the supplier's precondition, but the supplier was unable to complete the work as agreed. Therefore the fault lies with the supplier.
+
+If a class invariant was violated, then the instance has been placed in an invalid state during the execution of a routine, and left that way when the processing completed. This caused the invariant violation. As with the postcondition violation, because the problem occurred while executing routines in the supplier, preconditions must have been met. The supplier then is to blame.
+
+Based on this knowledge, we can say that it is most practical first to turn off runtime checking of postconditions and invariants as we gain confidence in a class. Meaning of course, that we feel confident that any calls that meet preconditions will be properly processed. Then our only worry is that some deranged client will, with total disregard for our carefully crafted preconditions, make calls to our routines from invalid states. So, maybe we will leave precondition checking turned on for a while.
+
+==Contracts and Inheritance==
+
+In the section titled [[Inheritance|Inheritance]] you saw that it was possible through inheritance to produce a new class that has all the features of an existing one. This is a very powerful notion, and could be dangerous. What would keep descendants from redefining inherited features with semantics that were totally different from those intended by the producer of the original class? Nothing if it were not for the contract.
+
+Simply speaking assertions on a parent class, preconditions, postconditions, and class invariants, all are inherited by the class's proper descendants.
+
+For class invariants, if any new invariants are coded in an heir, they will be added to those inherited from the parent, using a non-strict version of logical "and" (We will define non-strict booleans in Writing Assertions below).
+
+That is simple enough. And the situation is also simple for effective routines inherited and left unchanged ... the contracts stand as written.
+
+From our example above you may have gotten the idea that contracts are really useful only for effective routines. Such is not the case. In fact, specifying a contract on a deferred routine is really a powerful notion. It says not only that effective descendants must provide an implementation for this routine, but also that there is a contract that must be satisfied. Effecting or redefining a routine in a descendant class will not make the contract go away. Here is an feature from the Base Library deferred class ACTIVE which models data structures with a current item, and is an ancestor to many effective container type classes.
+
+feature -- Element change
+
+ replace (v: G) is
+ -- Replace current item by `v'.
+ require
+ writable: writable
+ deferred
+ ensure
+ item_replaced: item = v
+ end
+
+
+Feature replace carries the semantics necessary for replacing an item in an ACTIVE . It does not, however provide an implementation. All implementers must produce versions of replace that satisfy the contract specified here.
+
+It actually is possible to alter a feature assertion in an effected or redefined version(technically its a replacement of the original version):
+* The precondition can only become weaker than in the inherited contract.
+* The postcondition can only become stronger than in the inherited contract.
+
+These rules are imposed as a consequence of the effect of effected or redefined routines on polymorphism and dynamic binding. But, you can understand them from an intuitive viewpoint, if you reconsider the business contract analogy. Suppose a contractor makes a deal with a client to do certain work (represented by the postcondition). Part of the deal might be that the client agrees to have a site ready by a certain date (represented by the precondition). The contractor represents the parent class in the analogy. Now suppose the contractor brings in a subcontractor (representing the heir class) to do a portion of the work. The subcontractor cannot force the client to change the date that the site is to be ready to an earlier date (no strengthing of the precondition). The deal with the client was made by the contractor and so no new or stronger requirements can be imposed by the subcontractor. Likewise the subcontractor must provide at least as much work as was bargained for by the contractor, but may promise to provide more if appropriate (strengthing of postcondition is allowed.)
+
+In Writing Assertions below you will see the syntax for weaking preconditions and strengthening postconditions.
+
+==Unfinished Business==
+
+In the section [[Adding Class Features|Adding Class Features]] , we promised to explain two issues during this discussion of Design by Contract.
+
+===Short Routines===
+
+One of these is the tendency of mature Eiffel programmers to write routines that are quite short. It should be clear by now that we wish to build a contract on each routine. The contract describes the semantics of the routine in a declarative fashion. In other words, it tells what the routine does, without giving an indication of how it does it.
+
+Try to imagine giving a declarative description of a routine that was 50 lines long. Hardly possible. So decomposition of complex computations into chunks small enough to describe with assertions is what gets done.
+
+===Command/Query Separation===
+
+In [[Adding Class Features|Adding Class Features]] , we saw that we can categorize features as either queries or commands. A query will ask a question or make an observation about an instance. A command will tell the instance to take some action which may result in changing the instances internal state.
+
+We said that when program routines, that those routines should either be commands or queries but not both. Importantly, asking a question about an instance should not change the instance. Likewise, taking an action that changes the state of an instance should not return a result.
+
+Here's the rationale. In a routines postcondition we use boolean expressions to ensure that the routine has done its job properly. Likewise, class invariants, which define the valid state for instances, are written as boolean expressions. In both cases we may use the features of the class which are queries to ask about an instances current state.
+
+If a query that we use in an assertion were to change the state of the instance, then the result we received would be invalid as soon as we received it.
+
+Therein lies the primary reasoning behind command/query separation. You cannot reason about the integrity of an object if the act of asking a question changes the object.
+
+==Writing Assertions==
+
+You have seen fairly typical assertions written in the examples above. Study the classes in the libraries to see some excellent working examples. There are a couple of things that need to be covered.
+
+===Non-Strict Booleans===
+
+One is that, as you can probably imagine, it is not a good thing to cause an exception during the process of checking an assertion. One of the most common ways to cause such an exception is to apply a feature to a Void reference.
+
+The way to avoid this is to use the non-strict booleans " and then " and " or else ". These forms of " and " and " or " do not force the checking of all conditions. As soon as a determination can be made, they stop checking. It is typical to see " and then " used to avoid applying a feature to a void reference in preconditons. Below is a creation procedure that uses a non-strict boolean in its precondition.
+
+ make (a_nm: STRING; a_offset: INTEGER) is
+ -- Initalize with name `a_nm' and utcoffset `a_offset'
+ require
+ name_not_empty: a_nm /= Void and then not a_nm.is_empty
+ offset_valid: a_offset >= -12 and a_offset <= 12
+ do
+ name := clone (a_nm)
+ utcoffset := a_offset
+ ensure
+ name_initialized: name.is_equal (a_nm)
+ utcoffset_initialized: utcoffset = a_offset
+ end
+
+
+===Replacing Inherited Feature Assertions===
+
+To replace a precondition on a feature you are effecting or redefining, you use the " require else " keywords to introduce new conditions. These conditions will be logically " or -ed" with the original precondition to form an new one.
+
+Likewise use "and then " to add conditions to a postcondition. The added conditions will be " and -ed" to the original.
+
+Below is an example of weakening a precondition. The first feature shown is from class DYNAMIC_CHAIN in the Base Library.
+
+ remove_left is
+ -- Remove item to the left of cursor position.
+ -- Do not move cursor.
+ require
+ left_exists: index > 1
+ deferred
+ ensure
+ new_count: count = old count - 1
+ new_index: index = old index - 1
+ end
+
+
+The next feature is from DYNAMIC_LIST , a proper descendant of DYNAMIC_CHAIN . DYNAMIC_LIST weakens the precondition it inherited from DYNAMIC_CHAIN . Originally in DYNAMIC_CHAIN , " index > 1" was required for remove_left . In DYNAMIC_LIST either " index > 1" or " not before " (or both) will suffice.
+
+ remove_left is
+ -- Remove item to the left of cursor position.
+ -- Do not move cursor.
+ require else
+ not_before: not before
+ deferred
+ end
+
+
+==Not Writing Assertions==
+
+Let's close this discussion of Design by Contract with one more interesting and point to make about assertions. The precondition and postcondition parts of a routine are optional, as you may remember from [[Adding Class Features| Adding Class Features]] . Suppose you write a routine and do not code either precondition or postcondition. You might be tempted to think that you have simply written a routine that has no contract. But, that would not be the case.
+
+The contract exists, even though you do not code it explicitly. If it were written out, it would look as follows.
+
+ my_routine is
+ -- My descriptive header comment
+ require
+ True
+ ensure
+ True
+ end
+
+
+What does this mean? It means that you have selected the weakest possible precondition and postcondition for your routine. Of course, this may be perfectly valid under some circumstances.
+
+Just understand that if your routine could speak, it would be telling you, "I can always work successfully without any particular guarantees from you at all. On the other hand, I won't promise you any particular results when I get done."
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki
new file mode 100644
index 00000000..d6e51f19
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki
@@ -0,0 +1,227 @@
+[[Property:title|Eiffel Classes]]
+[[Property:weight|1]]
+The unit of software reuse in Eiffel is the class.
+
+The unit of modularity in Eiffel is the class.
+
+The unit of type modeling in Eiffel is the class.
+
+All Eiffel code must exist within the context of a class.
+
+In Eiffel, application systems, or simply systems, are created by assembling a set of related classes. The classes in a system will be related only by one or both of the two allowable relationships in object-oriented design.
+
+Having read the above, you should be convinced that the concept of class is important and far-reaching. The fact that we have precise rules about classes simplifies life a lot. The only kind of module in Eiffel is a class. Each class exists in one source file (which contains only that class), and contains the code necessary to provide a static definition of a data type. Every runtime entity, i.e. every object, must be an instance of a class. Because we can depend upon these things in Eiffel, we have consistency and predictabililty in the inherently complex world of software development.
+
+Let's take a look at how classes are structured.
+
+==Structure of a Class==
+
+The code that makes up an Eiffel class is divided into the following parts:
+* [[#indexing|Indexing]]
+* [[#class header|Class header]]
+* [[#formal generics|Formal generics]]
+* [[#obsolete|Obsolete]]
+* [[#inheritance|Inheritance]]
+* [[#creators|Creators]]
+* [[#features|Features]]
+* [[#invariant|Invariant]]
+
+All of the above, except Class header, are optional. So the simplest Eiffel class you could build would look like this:
+
+class
+ SIMPLE
+end
+
+
+Okay, so class SIMPLE is only interesting in its simplicity. Let's look at a more useful example:
+
+indexing
+ description: Objects that model lists
+ revision: $Revision: 1.4 $
+
+class
+ OLD_FASHIONED_LIST [G]
+
+obsolete "This class is obsolete, use LINKED_LIST [G] instead"
+
+inherit
+ DYNAMIC_LIST [G]
+
+create
+ make
+
+feature -- Initialization
+
+ make is
+ -- Create an empty list.
+ do
+ before := True
+ ensure
+ is_before: before
+ end
+
+feature -- Access
+
+ item: G is
+ -- Current item
+ do
+ Result := active.item
+ end
+
+ first: like item is
+ -- Item at first position
+ do
+ Result := first_element.item
+ end
+ (other features omitted)
+
+invariant
+ before_constraint: before implies (active = first_element)
+ after_constraint: after implies (active = last_element)
+
+Here is a class that, although somewhat contrived, utilizes all of the required and optional parts of the class. Let's look at each part individually.
+===Indexing===
+
+indexing
+ description: Objects that model lists
+ revision: $Revision: 1.4 $
+
+
+The indexing part of a class is there to allow you as a producer to record information of your choice which will help you or other reuse consumers at some later time to locate understand the class. This important in Eiffel because we try to treat every class as if someday it will become reusable.
+
+Information in indexing does not change the semantics of the class.
+
+The indexing in the class above is typical. It is introduced with the language keyword indexing , and contains two index clauses, each of which is comprised of an index and a single index value. You can code index clauses with indexes that you devise yourself, so there is nothing inherently special about " description " and " revision " as used above. But, these indexes could be special to tools which analyze libraries of classes use them. Although these clauses have only one index value each, it is permissible to put more, separated by commas.
+
+===Class Header===
+
+class
+ OLD_FASHIONED_LIST [G]
+
+
+The class header is introduced by the keyword "class", which in turn can be preceded by one of three keywords which mark the class as deferred , expanded , or external . In our example, the class has none of these markings, so it is an effective class whose instances are access by reference.
+
+The keyword class is followed by the class name, in this case " OLD_FASHIONED_LIST ".
+
+Of the three keywords for header marks, the one which you will encounter most often is deferred . A class is deferred if it contains one or more features that are deferred, that is, features which have been specified in the class but for which no implementation has been provided. Proper descendants of a deferred class will provide implementations for its deferred features.
+
+===Formal Generics===
+
+class
+ OLD_FASHIONED_LIST [G]
+
+
+In this example the class name is followed by the specification of one formal generic parameter " G ". The presence of one or more formal generic parameters will designate a class as a generic class. The formal generic parameter is a place holder for a class name which will be provided by reuse consumers. For example if we wrote a class which was a client to OLD_FASHIONED_LIST we would substitute the class name for the type of objects that we would want to build an OLD_FASHIONED_LIST of. We might make this declaration:
+
+ my_list_of_cats: OLD_FASHION_LIST [CAT]
+
+
+The entity my_list_of_cats could then be attached at runtime to an OLD_FASHIONED_LIST of objects of type CAT . So the class CAT becomes an actual generic parameter and substitutes for G in the declaration.
+
+Of course formal generic parameters cannot be the same name as a class name in the same universe. If multiple formal generic parameters are used, they are separated by commas.
+
+You will learn more about generic classes in the section titled [[Genericity|Genericity]] .
+
+===Obsolete===
+
+obsolete "This class is obsolete, use LINKED_LIST [G] instead"
+
+
+ OLD_FASHION_LIST s are obsolete ... and the class is marked as such by include the line above. The manifest string contains an explanation, instructions, and/or recommended alternatives. Compilers and other language tools can deliver this message to potential reuse consumers. As with indexing, obsolete has no effect on the semantics of the class.
+
+Obsolete is rarely used because of the nature of certain elements of the Eiffel methodology. For example, if implementations are well-hidden behind implementation-independent specifications, then those implementations may be changed to adapt the class to changing execution environments in such a way that clients are unaffected.
+
+===Inheritance===
+
+inherit
+ DYNAMIC_LIST [G]
+
+
+One of the two possible relationships between classes, inheritance is also a powerful software reuse mechanism. In this example class OLD_FASHIONED_LIST declares itself to be a proper descendant of class DYNAMIC_LIST .
+
+There will be more in the section called . For now though, be aware of two important implications of this declaration:
+* Every feature of DYNAMIC_LIST is available to OLD_FASHIONED_LIST and potentially available to its clients.
+* Whenever an instance of DYNAMIC_LIST is called for, then an instance of OLD_FASHIONED_LIST will suffice.
+
+===Creators===
+
+create
+ make
+
+
+The creators part of a class declares a procedure as being a creation procedure. In this case the procedure in question is the one named make . By convention, creation procedure names begin with the word " make ".
+
+Let's take a quick look at object creation. Consider this declaration:
+
+ my_list_of_cats: OLD_FASHION_LIST [CAT]
+
+
+Here the entity my_list_of_cats can be attached to an object of type OLD_FASHION_LIST [ CAT ] at runtime. The process of converting my_list_of_cats from holding a void reference to holding a reference to a object modeling a list of cats, starts when a creation instruction is executed. The creation instruction creates the instance and may apply a creation procedure to initialize the instance. A creation instruction for the declaration above would look like this:
+
+ create my_list_of_cats.make
+
+
+The create keyword is used to introduce a creation instruction. This instruction causes the following four things to happen:
+* A shell of a new instance of OLD_FASHION_LIST [ CAT ] is created in memory with a memory field for every attribute
+* Each field is initialized with standard default values
+** False for type BOOLEAN
+** Null character for type CHARACTER
+** The appropriate form of zero for number types
+** Void for reference types
+
+* Attach the new instance to the entity my_list_of_cats
+* Apply the creation procedure make
+
+Once these steps complete successfully, my_list_of_cats will be attached to a valid instance (i.e., an instance in which the class invariant is true) of OLD_FASHIONED_LIST [ CAT ].
+
+===Features===
+
+feature -- Initialization
+
+ make is
+ -- Create an empty list.
+ do
+ before := True
+ ensure is_before: before
+ end
+
+feature -- Access
+
+ item: G is
+ -- Current item
+ do
+ Result := active.item
+ end
+
+ first: like item is
+ -- Item at first position
+ do
+ Result := first_element.item
+ end
+
+
+The features part of a class is the area in which we feel that most of the "programming" is done. It is here that we define those things that instances of a class have and can do. We will learn more about features in the next section [[Adding Class Features|Adding Class Features]] .
+
+Until then let's just take a quick look at how features fit into a class. Notice that in our example the features part is introduced by the keyword " feature ". In fact there are two occurrences of feature in this example, each followed by a comment.
+
+You may declare multiple feature statements. This helps you group features in a manner that makes sense. Here we see the first group contains those features which are listed as creation procedures in the creators part of the class. The second group of features labeled " Access " contains a set of queries available to clients of the class.
+
+Although the words " Initialization " and " Access " are actually in comments after the feature 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 feature 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. }}
+
+
+===Invariant===
+
+invariant
+ before_constraint: before implies (active = first_element)
+ after_constraint: after implies (active = last_element)
+
+
+Here's the last word in a class definition ... both literally and figuratively. The invariant part, introduced not surprisingly by the keyword " invariant ", is that portion of the class in which we can state what it means for an object to be a valid instance of this class.
+
+We will learn more about class invariants in the section titled [[Design by Contract and Assertions|Design by Contract and Assertions]] .
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-net-compliance.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-net-compliance.wiki
new file mode 100644
index 00000000..9b57f324
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-net-compliance.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Eiffel for .NET Compliance]]
+[[Property:weight|9]]
+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?] }}
+
+==Applicability==
+
+The CLS states a number of rules .NET tools have to abide by to be CLS-compliant. These rules relate to both a .NET producer, generally a compiler generating .NET code, and a consumer, which is generally a compiler that consumes .NET assemblies for reuse. Eiffel-Compliance relates only to consumption of .NET assemblies.
+
+==What is Eiffel-Compliant?==
+
+As already state, anything CLS-compliant is Eiffel-compliant. Eiffel-Compliancy merely allows for exceptions so that non-CLS-compliant assemblies, types and members can be used in Eiffel for .NET.
+
+The following list outlines the supported non-CLS-compliant types:
+* All unsigned numerical basic types such as System.UInt32 as System.UInt64, represented by NATURAL_xx.
+* Native pointers (System.IntPtr), represented by POINTER
+
+
+Typically assemblies, types or members are marked with the System.CLSCompliantAttribute attribute to explicitly indicate if they are CLS-compliant or not. The Eiffel for .NET compiler will now ignore this attribute and instead infer if they are Eiffel-Compliant. With such an inference engine at hand, Eiffel for .NET opens itself up to extended support for COM/Legacy interop as well support assemblies not adhering to CLS-compliant rules, for one reason or another.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki
new file mode 100644
index 00000000..596e1197
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki
@@ -0,0 +1,196 @@
+[[Property:title|Event Programming with Agents]]
+[[Property:weight|7]]
+In Eiffel there is a facility referred to as agents.
+
+The implementation of agents is an advanced topic, but you do not have to understand the details of the implementation of agents to put agents to work for you. That is what you will learn in this section.
+
+==Objects that Represent Operations==
+
+Object technology is based on the idea that when we model real world objects, we model them based on the things that they have and what they can do ... their properties and their operations. The operations in Eiffel are the routines, i.e., the functions and procedures, of classes. Operations are not objects.
+
+Having said that, it is sometimes desirable for us to model operations. We do this in the same fashion that we model other concepts: statically as classes, and as objects at runtime.
+
+An object that represents an operation is called an agent.
+
+If we can have a runtime object that represents an operation, then we can place the object in the structure of another object, where at some later time, a client can cause the associated operation to execute.
+
+This is a very desirable model for event driven processing, like graphical user interfaces. The operations that are executed when a user take some action like clicking on a button, could be represented by agents. When the user interface element is initialized, agents that represent the action routines are stored within the interface element. Then at the time that an event, say a button click, occurs, the agents for that event are retrieved and their associated operations are executed.
+
+Another area in which agents are commonly used is in traversing data structures. Many of the data structure classes in the Base Library include routines which take agents as there arguments. For example, the feature do_all takes an agent which represents some procedure and will apply the procedure to every item in the structure.
+
+==Classes to Model Operations==
+
+We know that there are two types of routines in Eiffel, functions and procedures.
+
+Not surprisingly, the implementation of agents relies on three classes in the Base Library. Class ROUTINE , and its heirs FUNCTION and PROCEDURE .
+
+When you use an agent from a client routine, you will be building an instance of either FUNCTION or ROUTINE . This happens implicitly as you will see.
+
+==Using Agents==
+
+Below is an instruction which passes an agent as an argument to a procedure.
+
+ button.select_actions.extend (agent gauge.step_forward)
+
+
+In this example, the producer wants to add the action of stepping the gauge forward in the event that a button is clicked. The keyword " agent " is used to indicate that at runtime an object of type PROCEDURE should be created which represents applying the feature step_forward to the object attached to gauge . It is the object of type PROCEDURE that is passed as the argument.
+
+It is important to understand that step_forward does not get applied at the point that the instruction above is executed. Rather the procedure object that represents step_forward is given to the button to hold in reserve. Then at the point that the button click event takes place, the button will go through its list of select_actions executing their associated routines. Only then does step_forward get applied to gauge .
+
+===Agents with Arguments===
+
+In this example, the routine " step_forward " on which the agent is based takes no arguments. If you drilled down into the workings of this example you would find that class that implements the feature extend is class EV_NOTIFY_ACTION_SEQUENCE . You would also see that the signature for the feature extend is as essentially as follows.
+
+ extend (v: PROCEDURE [ANY, TUPLE])
+
+
+We don't have to know too much about the workings of agents to see that " extend " takes an argument v which is of type PROCEDURE . It turns out that the actual generic parameter TUPLE represents the set of "open" arguments. In this case, extend is expecting an agent which has no open arguments.
+
+===Open and Closed Arguments===
+
+It is this business of open and closed arguments which really makes agents remarkable. To get a feel for it, let's simplify the example some. Instead of considering an agent passed as an argument let's look at it as a simple assignment within a class.
+
+Suppose a class has a feature declared as shown below.
+
+ my_procedure: PROCEDURE [ANY, TUPLE]
+
+
+Then what can be assigned to my_procedure ?. An agent, of course. Say the class has procedures as follows.
+
+ no_argument_procedure is
+ -- A procedure with no arguments
+ do
+ print ("No argument here!%N")
+ end
+
+ two_argument_procedure (an_int: INTEGER; another_int: INTEGER) is
+ -- A procedure with two arguments
+ do
+ print ("My arguments are: " + an_int.out + " and " + another_int.out + "%N")
+ end
+
+
+Then the following assignment is valid.
+
+ my_procedure := agent no_argument_procedure
+
+
+What this means is that the agent created and associated with the procedure no_argument_procedure must conform to the type PROCEDURE [ ANY , TUPLE ]. The feature my_procedure (which is of type PROCEDURE ) can be attached at runtime to an agent representing a procedure with no open arguments, which indeed is what no_argument_procedure is.
+
+Now let's turn our attention to the other procedure two_argument_procedure . You might think that because it takes two arguments, that you would not be able to build an agent from it which could be assigned to the attribute my_procedure . But you can do it by closing the two arguments at the time that the agent is created, as in the following.
+
+ my_procedure := agent two_argument_procedure (1, 2) -- Is Valid
+
+
+What happens here is that values are fixed for those arguments at the time that the agent, an object of type PROCEDURE [ ANY , TUPLE ] is created.
+
+So this is the wonderful thing about agents. A routine which will be represented as an agent does not have to be an exact fit for the expected signature. By closing some arguments at agent creation, you have effectively produced a new and conforming routine.
+
+The advantange of this is that you can sometimes avoid building specialized routines for the sole purpose of having a routine which conforms to the agent signature.
+
+To leave an argument open, you hold its place with a question mark. If you intend for all arguments to be open, then you may make them all question marks, or leave off the arguments entirely.
+
+ my_procedure := agent two_argument_procedure (?, 2) -- Argument 1 left open
+ my_procedure := agent two_argument_procedure (?, ?) -- Both arguments left open
+ my_procedure := agent two_argument_procedure -- Both arguments left open
+
+
+If an argument is open, then it means that a value is not provided for that argument at the time that the agent is created. The implication is that the value must be provided at some time prior to the time that the agent's associated routine gets executed. A precondition to executing a routine associated with an agent is that the agent has a valid set of arguments (called operands within the ROUTINE classes) for the call. If you were to leave one or both of the arguments to two_argument_procedure open as in the examples above, the assignment would still work due to the rules governing TUPLE conformance. But, at runtime unless the other arguments had been provided, the " valid operands " precondition would be violated.
+
+Let's see an example in which we leave a target open. Suppose we have a class that has a feature coded as below
+
+ my_strings: LINKED_LIST [STRING]
+
+
+and some code to put some strings in my_strings :
+
+ create my_things.make
+ my_strings.extend ("Hello")
+ my_strings.extend ("World!")
+
+
+Our class also has a feature called print_on_new_line which we created to print a string preceded by a new line character.
+
+ print_on_new_line (s: STRING) is
+ -- Print `s' preceded by a new line
+ do
+ print ("%N" + s)
+ end
+
+
+Now suppose we want to print the values of all the strings in my_strings each on a separate line by invoking print_on_new_line . Traditionally, we would do it by traversing the LINKED_LIST and printing each item. Like this:
+
+ from
+ my_list.start
+ until
+ my_list.exhausted
+ loop
+ print_on_new_line (my_list.item)
+ my_list.forth
+ end
+
+
+The availability of agents gives us new options. LINKED_LIST has a feature do_all which comes to it from its ancestor LINEAR . The do_all feature's signature looks like this:
+
+ do_all (action: PROCEDURE [ANY, TUPLE [G]])
+
+
+As an argument do_all takes an agent based on a procedure with one open argument which is the same type as the list items (in this class, G is the formal generic parameter representing the type of the items being stored). Then it traverses the list executing the routine associated with that agent and roviding the current list item to satisfy the open argument.
+
+Instead of coding the loop shown above, we can code this instruction:
+
+ my_list.do_all (agent print_on_new_line (?))
+
+
+we leave the argument to print open, and do_all will provide it as a reference to the current list item as it traverses the list.
+
+===Targets for Agents' Routines===
+
+In Eiffel every routine must be applied against a target object. In our model for computation, x . f ( a , ...), x is the target of the application of feature f . In the case of an agent, the agent must account for objects for each of the arguments and an object for the target of the routine.
+
+Let's identify the targets in the examples shown. First:
+
+ button.select_actions.extend (agent gauge.step_forward)
+
+
+Here the target is the object attached to the entity "gauge" which is (although you cannot determine it from this line taken out of context) an object of type EV_GAUGE .
+
+How about this:
+
+ my_procedure := agent two_argument_procedure (1, 2)
+
+
+Here, since there was no qualification, then the target is the current instance. Same with this:
+
+ my_list.do_all (agent print_on_new_line (?))
+
+
+Again, consider the fact that the agent must account for objects for each of the arguments to a routine, and an object for the target. So, in the examples we've seen so far, the target is close, that is provided at the time of the creation of the agent.
+
+But we can actually leave the target open as well. Now we cannot use the question mark notation to do that, because if we did, there would be no way to know of which class the routine is a feature. So instead, we mark an open target with the class name in braces.
+
+Suppose in our list of strings example, we wanted to print the strings, then convert them to lower case, then print them again. Remember that "do_all" has one open argument, which will be provided as the current list item during the traversal.
+
+ my_list.do_all (agent print_on_new_line (?))
+ my_list.do_all (agent {STRING}.to_lower)
+ my_list.do_all (agent print_on_new_line (?))
+
+
+In between printing the list two times, we provide do_all with an agent that representing the STRING class's feature to_lower which will convert each string in the list to lower case. Notice that to_lower does not take an argument of type STRING as print_on_new_line did. Rather it gets applied to an instance of STRING , so it is targeted to a string. So we leave its target open and do_all provides the current list item as the target.
+
+Agents for Functions
+
+So far all the agents that we have coded have created instances of PROCEDURE . But functions are routines and can be represented as agents as well. The difference is that functions have a return value.
+
+Let's extend the string example by using an agent that represents a function. Suppose we wanted to print only those strings which contain a particular character, say the exclamation point.
+
+Here again we'll use a feature of the LINKED_LIST class. There is a feature called do_if which takes two agents as arguments. One is an action procedure like the argument that do_all takes, and the other is a function which returns a boolean and used as a test. As each list item is current, the test is applied first. If the result is true, then the action is applied with the current item.
+
+ my_list.do_if (agent print_on_new_line(?), agent {STRING}.has('!'))
+
+
+The agent for the action is the same as we used earlier. We've added an agent for the test. It represents applying the has feature of the STRING class. Here the target is left open, because we want each of the strings in the list to be the target of has .
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/exception-mechanism.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/exception-mechanism.wiki
new file mode 100644
index 00000000..aabbf861
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/exception-mechanism.wiki
@@ -0,0 +1,65 @@
+[[Property:title|Exception Mechanism]]
+[[Property:weight|6]]
+==Motivation: Concerning Robustness==
+
+The notion of software correctness that we saw in [[Design by Contract and Assertions|Design by Contract and Assertions]] is half of the formula for software reliability. Correctness covers what the software is supposed to do, that is, its specification.
+
+Of course,there is always a potential for things to go out of the bounds of the specification. This happens, for exampleif a client makes a call to a routine from a state in which the routine's precondition is not true.
+
+How well software responds to situations which outside specification is called robustness. Together correctness and robustness define software reliability.
+
+==Consequences of Contracts==
+
+In the presence of Design by Contract, what happens to running software boils down to a simple rule:
+
+A routine callcan complete in one of only two ways:
+# The routine fulfills its contract.
+# The routine fails to fulfill its contract.
+
+As a follow-on, we can add that:
+* Any routine that fails to fulfill its contract must cause an exception in its caller.
+
+==Reacting to Exceptions==
+
+Again, because of Design by Contract, we can state the following rule for dealing with exceptions:
+
+A routine that incurs an exeception can react in one of only two ways:
+# It can return the instance to a stable state and retry the entire routine with the same or a different strategy.
+# It can fail, causing an exception in its caller.
+
+There is an Eiffel mechanism called the rescue clause which facilitates the first alternative.
+
+===The Rescue Clause===
+
+The rescue clause is part of the routine structure we saw in [[Adding Class Features|Adding Class Features]] . The rescue clause is a sequence of instructions introduced by the keyword " rescue ". At the point that an exception occurs, the processing of the normal instructions in the routine body will cease, and the instructions in the rescue clause will be executed instead.
+
+If the instructions in the rescue clause can set things up so that it mightprove fruitful to attempt to retry the routine, it can do so by issuing a retry instruction. When the retry instruction is executed, the routine is restarted from its beginning, although local entities are not re-initialized. You will see why inthe example below.
+
+If the rescue clause exits without issuing a retry instruction, then the routine fails.
+
+It should be noted that rescue clauses and retry instructions are not something that are used commonly. Out of the approximately 2000 class in the delivered Eiffel libraries, there are only 16 occurrences. Many of these are oriented toward network and database operations for which some reasonable recovery might be possible.
+
+ transmit: (p: PACKET)
+ -- Transmit packet `p'
+ require
+ packet_not_void: p /= Void
+ local
+ current_retries: INTEGER
+ r: RANDOM_NUMBER_GENERATOR
+ do
+ line.send (p)
+ rescue
+ if current_retries < max_retries then
+ r.next
+ wait_millisecs (r.value_between (20, 500))
+ current_retries := current_retries + 1
+ retry
+ end
+ end
+
+
+In the example above, rescue is used to recover from a situation in which an exception occurs in trying to send a packet. When the exception occurs the rescue clause will, if the maximum number of retries has not been reached, wait for some random length of time. Then, after having updated the number of retries, it will issue the retry instruction. If the maximum number of retries is reached, the rescue clause will exit without executing the retry, constituting a failure.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/genericity.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/genericity.wiki
new file mode 100644
index 00000000..fc2d229b
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/genericity.wiki
@@ -0,0 +1,158 @@
+[[Property:title|Genericity]]
+[[Property:weight|4]]
+We got a very short introduction to generic classes when we were looking at the formal generic part of class structure in [[Eiffel Classes|Eiffel Classes]] . That discussion left to the imagination the motivation and benefits for creating generic classes.
+
+You will see that most of the generic classes model containers for multiple items and at least one of their formal generic parameters represents the type of items that are to be stored in the container. Some generic classes, like LINKABLE , care for only one instance of the type represented by their formal generic parameter.
+
+==Motivation==
+
+Imagine that a software producer is planning to build a class which would represent a list of things. Some one might ask "What kinds of things?" To which the producer would reply, "Just things. I want my list to be usable for all kinds of things."
+
+Using the idea of polymorphic attachment that we learned in [[Inheritance|Inheritance]] , the producer could build such a class. It might have a query item which would return the thing from the list to which a cursor currently points. It might have a command put which would enter some new thing into the list.
+
+What would be the type of item ? And what would be the type of the argument to put ?
+
+If the producer wants the class to handle all kinds of things, then the answer must be class ANY , the class from which all others inherit.
+
+class
+ LIST_OF_THINGS
+ .
+ .
+
+feature -- Access
+
+ item: ANY
+ -- The thing currently pointed to by cursor
+
+ .
+
+feature -- Element change
+
+ put (new_item: ANY)
+ -- Add `new_item' at the end of the list
+ .
+ .
+
+
+This will work, but has some definite disadvantages. Suppose you choose to use this class to maintain a list of cats in one of your classes. You might make this declaration:
+
+ my_cats: LIST_OF_THINGS
+ -- A list of my cats
+
+
+Then you could add individual instances to the list:
+
+ fluffy, twinkie: CAT
+ .
+ .
+ my_cats.put (fluffy)
+ my_cats.put (twinkie)
+
+
+One problem with this type of list is that the type system will not help you keep from doing something pathological like:
+
+ fluffy, twinkie: CAT
+ thor: PSYCHOTIC_HYDROPHOBIC_CAT_HATING_DOG
+ .
+ .
+ my_cats.put (fluffy)
+ my_cats.put (twinkie)
+ my_cats.put (thor)
+
+
+Another problem is that to do any CAT things with an item in the list, you must reattach it to a CAT entity. The following is invalid.
+
+ my_cats.item.purr -- Is invalid
+
+
+This is because "item" is type ANY and although it may be currently attached to an instance of CAT, the static typing system cannot guarantee that. So you must use assignment attempt as we saw in the polymorphism example in [[Inheritance|Inheritance]] .
+
+ some_cat: CAT
+ .
+ .
+ some_cat ?= my_cats.item
+ if some_cat /= Void then
+ some_cat.purr
+ end
+
+
+You can see that this type of list has its drawbacks. Of course you could build a LIST_OF_CATS class in which item and the argument for put would be of type CAT . This would let you purr a cat without pulling it out of the list, and it would also prevent you from accidently letting old Thor in with the cats. But, every time you needed a list to hold a different type of object, you have to write a new class.
+
+Indeed, this is how things are done in environements without facilities genericity.
+
+What we would like to have is a way to produce the text of the list class once. Then only when we make declarations do we add the additional information about the particular types we want allowed in the list.
+
+==Basic Genericity==
+
+In Eiffel this is accomplished through generic classes. Generic classes are written relative not to a specific class but to a kind of phony class name called a formal generic parameter. With genericity, the LIST_OF_THINGS class might become a class called LIST which is a list of items of type G . In class LIST we would declare item as type G, as well as the argument to put .
+
+class
+ LIST [G]
+ .
+ .
+feature -- Access
+ item: G
+ -- The item currently pointed to by cursor
+ .
+feature -- Element change
+ put (new_item: G)
+ -- Add `new_item' at the end of the list
+ .
+ .
+
+
+We could declare feature my_cats as a LIST of items of type CAT . By doing so we are providing CAT as an "actual generic parameter" in the declaration. Then we are free to treat the features of LIST as if the class name CAT had been substituted for every occurrence of the formal generic parameter G .
+
+ my_cats: LIST [CAT]
+ -- A list of my cats
+ fluffy, twinkie: CAT
+ .
+ .
+ my_cats.put (fluffy)
+ my_cats.put (twinkie)
+ .
+ my_cats.item.purr -- Valid now
+
+
+The following would no longer be valid:
+
+ my_cats: LIST [CAT]
+ -- A list of my cats
+
+ thor: PSYCHOTIC_HYDROPHOBIC_CAT_HATING_DOG
+
+ .
+ .
+
+ my_cats.put (thor) -- Is invalid
+
+
+==Constrained Genericity==
+
+The generic class LIST illustrated above is perfectly useful for making typed lists of any type of object. The features of the LIST will not attempt to use the objects in the list in any way. Sometimes though, it is important for a class to be guaranteed more about the nature of the types that can be substituted for its formal generic parameter.
+
+Take for example the case of a class called SORTED_LIST . A SORTED_LIST is a list, of course, but it is special in that it acts upon the elements that it holds to keep them in order.
+
+A SORTED_LIST needs to be able to order its elements. So, it must be able to apply queries to those elements to determine which should sort high than which. The elements themselves must respond to ordering operations.
+
+If SORTED_LIST were defined like we did LIST
+
+class
+ SORTED_LIST [G]
+
+
+there would be no guarantee that ordering operations, like "<" and ">" could be applied to all types that could be listed. An Eiffel facility called "constrained genericity" will solve this problemfor us. In the case of SORTED_LIST , we would add to the formal generic part as follows.
+
+class
+ SORTED_LIST [G -> COMPARABLE]
+
+
+You may remember from [[Inheritance|Inheritance]] that if we make instances of a class comparable with each other, then we make the class inherit from COMPARABLE and effect the feature "<".
+
+Here, constrained genericity does two things for us.
+* First, it states that any candidate for substitution for G must conform to class COMPARABLE . Typically this means it must inherit from COMPARABLE .
+* Second, it allows, within the features of SORTED_LIST , the features of COMPARABLE to be applied to any item which has a type of G .
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/index.wiki
new file mode 100644
index 00000000..21a982ae
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/index.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Eiffel for .NET]]
+[[Property:weight|2]]
+* [[Eiffel for.NET Language|Introduction]]
+* [[Eiffel Classes|Eiffel Classes]]
+* [[Adding Class Features|Adding Class Features]]
+* [[Inheritance|Inheritance]]
+* [[Genericity|Genericity]]
+* [[Design by Contract and Assertions|Design by Contract]]
+* [[Exception Mechanism|Exception Mechanism]]
+* [[Event Programming with Agents|Event Programming with Agents]]
+* [[Using Referenced Assemblies|Using Referenced Assemblies]]
+* [[Eiffel for .NET Compliance|Eiffel for .NET Compliance]]
+* [[Referenced Assembly Type and Feature Name Conversion|Referenced Assembly Type and Feature Name Conversion]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki
new file mode 100644
index 00000000..723b9848
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki
@@ -0,0 +1,352 @@
+[[Property:title|Inheritance]]
+[[Property:weight|3]]
+Inheritance, along with client/supplier, are the two relationships that can exist between classes.
+
+Inheritance lets us mirror in software the types of abstractions that are common in many problem domains, i.e., the more general to the more specialized.
+
+Inheritance also gives a way us to combine these abstractions.
+
+Inheritance allows us to make extensions and adaptations to existing software, while at the same time, leaving the original software unaltered.
+
+==The Eiffel Inheritance Model==
+
+If class B inherits from class A , then:
+* Every feature of A is also a feature of B
+* In any case in which an instance of A is called for, then an instance of B will suffice.
+
+Flexibility and adaptability are key qualities of the Eiffel inheritance model. On an informal level, this means that, except as prevented by certain constraints, a class can inherit from a set of classes containing just about any other classes.
+
+Eiffel classes can be effective or deferred. If a class is effective, then it is completely implemented. As a result, it is possible to create and use direct instances of an effective class at runtime.
+
+If a class is deferred, then it is not completely implemented. A class is deferred if it contains at least one deferred feature. So, it is possible for you to mark a feature (and by consequence also its class) as deferred when you code it. This means that the specification for this class dictates that such a feature exists, but there is no implementation for the feature included in the class. As a result, there can be no direct instances of deferred classes at runtime. However, a class that inherits from a deferred class can implement, or effect, the deferred features. This results in an effective descendant to the deferred class. And it is possible to create direct instances of this effective descendant. Such instances would also be instances (albeit not direct instances) of the original deferred class.
+
+What this means to us as software producers, is that in any development effort, we have available a great number of classes which can serve as potential starting points. That is, classes that we could make parents to the classes we produce. And, those classes do not have to chosen from a strict dichotomy of classes which are either completely abstract or completely implemented. Inheritance from classes that are deferred but have some implemented features is both possible and encouraged. It reuses existing software and it reduces the opportunity for error.
+
+Consider the deferred class COMPARABLE from the Eiffel Base Library. A portion of COMPARABLE is shown below:
+
+deferred class
+ COMPARABLE
+
+feature -- Comparison
+
+ infix "<" (other: like Current): BOOLEAN is
+ -- Is current object less than `other'?
+ deferred
+ end
+
+ infix "<=" (other: like Current): BOOLEAN is
+ -- Is current object less than or equal to `other'?
+ do
+ Result := not (other < Current)
+ end
+
+ infix ">" (other: like Current): BOOLEAN is
+ -- Is current object greater than `other'?
+ do
+ Result := other < Current
+ end
+
+ infix ">=" (other: like Current): BOOLEAN is
+ -- Is current object greater than or equal to `other'?
+ do
+ Result := not (Current < other)
+ end
+
+ is_equal (other: like Current): BOOLEAN is
+ -- Is `other' attached to an object of the same type
+ -- as current object and identical to it?
+ do
+ Result := (not (Current < other) and not (other < Current))
+ end
+
+
+If you are producing a class that you wish to support basic comparison operators, like "<" and ">", you can have that class inherit from COMPARABLE , which has features which correspond to those operators. The text for COMPARABLE contains eight features. Seven of these are effective and one is deferred.
+
+So through inheritance from COMPARABLE , your class, let's call it WHATZIT , would now have these features available. But how would the features of COMPARABLE know what it means to compare WHATZIT s?
+
+Of course, it would have no way of knowing, so you must show it. And you do that by writing the implementation for "<", the one deferred feature that WHATZIT inherits from the COMPARABLE class.
+
+When you look closely at the effective features of COMPARABLE , you see that their implementations are ultimately based on "<". If we were not able to inherit from multiple partially implemented classes, then we would be forced to implement many more features, a process which invites error, or, in the case of comparison, to move to a less appealing model.
+
+==The Inheritance Part of Classes in Eiffel==
+
+Because the inheritance model has such flexibility, it must also have adaptability. A consequence of inheriting from multiple classes is that it would be possible to inherit multiple features with the same name ... and you remember from [[Adding Class Features|Adding Class Features]] that a class is not allowed to have more than one feature with the same name. A process called feature adaptation allows us to resolve these issues in an heir. Feature adaptation is also done for reasons other than resolving name clashes as well.
+
+Feature adaptation is an enabling capability, but it is also one that takes some study to understand fully.
+
+We will look at the types of feature adaptation that will serve most useful to you as you begin to produce Eiffel software.
+
+In [[Eiffel Classes|Eiffel Classes]] you saw where the inheritance part fits into the class structure. Shown below is a portion of class LINKED_QUEUE from the Eiffel libraries. LINKED_QUEUE is an effective class which implements the abstract notion of a QUEUE (a deferred class) with an implementation based on the services provided by LINKED_LIST (an effective class).
+
+class
+ LINKED_QUEUE [G]
+inherit
+ QUEUE [G]
+ undefine
+ is_empty,
+ copy,
+ is_equal
+ redefine
+ linear_representation,
+ prune_all,
+ extend
+ select
+ item,
+ put
+ end
+ LINKED_LIST [G]
+ rename
+ item as ll_item,
+ remove as ll_remove,
+ make as ll_make,
+ remove_left as remove,
+ put as ll_put
+ export
+ {NONE}
+ all
+ {ANY}
+ writable,
+ extendible,
+ wipe_out,
+ readable
+ undefine
+ fill,
+ append,
+ prune,
+ readable,
+ writable,
+ prune_all,
+ extend,
+ force,
+ is_inserted
+ redefine
+ duplicate,
+ linear_representation
+ select
+ remove
+ end
+
+
+Okay ... now calm down ... please. This is an example from a very highly-evolved and sophisticated library which is replete with software reuse. LINKED_QUEUE has two parents and uses considerable feature adaptation. In fact, it uses every feature adaptation option available. The benefit is obvious, though. LINKED_QUEUE class has only seven features actually coded. In total there are only 26 lines of instructions!
+
+In practice you can use inheritance, even multiple inheritance, to do some quite productive programming in Eiffel without having to write anything that looks like the inheritance part of LINKED_QUEUE above.
+
+Regardless, let's break LINKED_QUEUE 's inheritance part into chunks and take a look at some of them.
+
+===Rename===
+
+ rename
+ item as ll_item,
+ remove as ll_remove,
+ make as ll_make,
+ remove_left as remove,
+ put as ll_put
+
+
+As you might have already guessed, the rename part, introduced oddly enough by the keyword " rename ", is used to rename features.
+
+Specifically, it is used when an heir wants to use a feature from a parent, but wants to use it under a different name than that by which the parent knows it. So in the example, the feature known as item in LINKED_LIST is perfectly usable in LINKED_QUEUE , but must be applied as ll_item .
+
+This is common when your class inherits two different features with the same name from two different parents and you want to be able to use them both. Because you can only have one feature with a given name, then rename one of the features.
+
+===New Exports===
+
+ export
+ {NONE}
+ all
+ {ANY}
+ writable,
+ extendible,
+ wipe_out,
+ readable
+
+
+The new exports part is introduced by the keyword " export ". This section allows you to change the export status of inherited features. Remember from [[Adding Class Features|Adding Class Features]] that features become available (or not) to clients by their export status. Export status of immediate features is controlled in the feature clause. But here we are dealing with inherited features, so we control their status in the export part of the class's inheritance section. Any feature not mentioned will have the same export status as it did in the parent class.
+
+In this example, the keyword " all " is used first to say that all features inherited form LINKED_LIST are unavailable to any clients (export to class NONE ). This is typical for a class like LINKED_QUEUE in which the features important to the client come from the deferred parent, in this case QUEUE , and the class LINKED_LIST is used only for implementation. But, it seems that also in this case, the producer felt differently about the features writable , extendible , wipe_out , and readable , and decided the allow clients of ANY type to utilize these features inherited from LINKED_LIST .
+
+===Undefine===
+
+ undefine
+ is_empty,
+ copy,
+ is_equal
+
+
+Next, undefine ... it's probably not what you think. You might assume that undefine is a way to banish forever any inherited features that you just do not want to deal with. But what happens to features whose names are listed in an undefine clause is that they become deferred features in the heir.
+
+Undefine is useful if you inherit two different features of the same name from different parents, a situation you cannot live with. If you like one and you don't like the other, then you can undefine the one you don't like. The the only version you get is the one you like.
+
+Another way you might use undefine is in the case in which you actually want a feature to be deferred in an heir that was effective in a parent.
+
+===Redefine===
+
+ redefine
+ linear_representation,
+ prune_all,
+ extend
+
+
+The redefine part lists the names of effective features for which the producer of the heir class would like to provide implementations that replace the inherited implementations.
+
+So, in this example the implementation for linear_representation , for example, that LINKED_QUEUE would have inherited from QUEUE will not be used. Instead LINKED_QUEUE implements its own version of linear_representation .
+
+{{note| '''Note:''' When a class implements a version of an inherited feature which was deferred in its parent, this is known as "effecting" the feature. Because features being effected are getting their first implementation, it is not necessary to list their names in the redefine part, or anywhere else in the inheritance part of the heir. }}
+
+===Select===
+
+ select
+ remove
+
+
+The select part is used only under special circumstances. The case in which select is required involves a situation called "repeated" inheritance. Repeated inheritance occurs when an heir inherits more than once from the same ancestor. Usually this means it has two or more parents who have a common proper ancestor (but it can occur directly). The features from the common ancestor are inherited by each of the parents and passed on to the heir. The rules and effects of repeated inheritance occupy an entire chapter in the official Eiffel language reference and will not be reproduced here. Justunderstand at this point that it is sometimes necessary to use select to provide the dynamic binding system with an unambiguous choice of features in the presence of polymorphic attachment.
+
+You should note also that repeated inheritance can and does occur often without causing any problem at all. In fact it happens in every case of multiple inheritance, due to the fact that all classes inherit from class ANY and receive its features as a result. The reason it is not a problem is that in the case that any feature makes it from the original common ancestor along multiple paths to the heir with its name and implementation still intact, it will arrive as only one feature heir. This is called sharing and nothing special needs to be done to make it happen.
+
+==Polymorphism==
+
+It is time now to see another way in which inheritance helps build more extendible software.
+
+Assume that we have to build classes that model different types of polygons. We would do this by building a class for polygon which would model a garden-variety polygon, a multi-sided closed figure. But when we consider that there are specialized types of polygons, like triangles and rectangles, we realize that to support these specializations, we need classes for them as well. And this is an obvious opportunity for inheritance. All triangles and rectangles are polygons. So, we start with class POLYGON and its proper descendants TRIANGLE and RECTANGLE .
+
+So we can make declarations like:
+
+ my_polygon: POLYGON
+ your_polygon: POLYGON
+ my_triangle: TRIANGLE
+ my_rectangle: RECTANGLE
+ another_rectangle: RECTANGLE
+
+
+Assume these declarations are in force for all the examples this section on polymorphism.
+
+We saw in [[Adding Class Features|Adding Class Features]] that we can say that one class conforms to another if it is the same class or one of its proper descendants. Therefore POLYGON conforms to POLYGON . Also, TRIANGLE and RECTANGLE conform to POLYGON . But, importantly, POLYGON does not conform to TRIANGLE or RECTANGLE . This makes sense intuitively, because we know all rectangles and triangles are polygons ... and we also know that not all polygons are rectangles.
+
+===Polymorphic Attachment===
+
+These facts affect how assignments can work. Using the declarations above:
+
+ my_polygon := your_polygon -- Is valid
+ your_polygon :=my_polygon -- Is valid
+ my_polygon :=my_rectangle -- Is valid
+ my_polygon := my_triangle -- Is valid
+
+
+but
+
+ my_rectangle := my_polygon -- Is not valid
+ my_triangle := my_polygon -- Is not valid
+
+
+and of course
+
+ my_rectangle := my_triangle -- Is not valid
+
+
+Consider now the assignment below which is valid.
+
+ my_polygon := my_rectangle
+
+
+After an assignment like this executes the entity my_polygon will be holding at runtime a reference to an instance of a type which is not a direct instance of its declared type POLYGON . But conformance ensures us that, although it may not be a direct instance, it will indeed by an instance. (all rectangles are polygons).
+
+Depending upon how many different types of polygons get modeled in classes, the entity " my_polygon " could be attached objects of may different types ... it could take on many forms. This in fact is the basis for the term "polymorphism"; having many forms. So we speak of "polymorphic attachment" as the process by which at runtime entities can hold references to objects which are not of the entity's declared type ... but they are of conforming types.
+
+Now let's see how we get some value from this.
+
+===Dynamic Binding===
+
+Suppose that one of the features of POLYGON is a query perimeter which returns an instance's perimeter. The producer of POLYGON may have implemented perimeter as a function that computes the perimeter by adding up the lengths of all the sides. This approach is guaranteed to work for all polygons, and we can apply the perimeter feature to any polygon. Let's print some perimeters:
+
+ print (my_polygon.perimeter)
+ print (my_triangle.perimeter)
+ print (my_rectangle.perimeter)
+
+
+ TRIANGLE and RECTANGLE might have properties, expressed as queries, which as a part of their specialization, distinguish them from run-of-the-mill polygons. Two features of rectangles are width and height the lengths of the sides.
+
+Armed with these RECTANGLE -specific features, the producer of RECTANGLE may say,"Now I no longer have to depend upon that crude implementation of perimeter that is inherited from POLYGON . I can build an efficient RECTANGLE -specific implementation of perimeter , based on the knowledge that for all RECTANGLE s perimeter = 2*(width+height)"
+
+To implement this specialized version of perimeter , the producer of RECTANGLE must add the feature to the class, but also must list its name in the " redefine " part of the RECTANGLE 's inheritance clause.
+
+class RECTANGLE
+inherit
+ POLYGON
+ redefine
+ perimeter
+ end
+ .
+ .
+feature
+ perimeter: REAL is
+ -- Sum of lengths of all sides
+ do
+ Result := 2 * (width + height)
+ end
+
+
+You would expect then, that this version of perimeter would be executed in the following context:
+
+ print (my_rectangle.perimeter)
+
+
+But what makes this interesting is that even in the context below
+
+ my_polygon := my_rectangle
+ print (my_polygon.perimeter)
+
+
+in which perimeter is being applied to a entity declared as POLYGON , the specialized version of perimeter from RECTANGLE is being used. It would be impossible to ensure at compile time which version of perimeter is most appropriate. So it must be done at runtime. This ability to choose the best version of a feature to apply, just at the moment it needs to be applied, is called "dynamic binding".
+
+Static typing tells us at compile time that it is safe to apply perimeter to my_polygon No matter which of the types of polygons is attached to my_polygon , there will be a perimeter feature that will work.
+
+Dynamic binding tells us that when we apply perimeter , we know that the most appropriate version of the feature will get applied at runtime.
+
+===Assignment Attempt===
+
+Now let's add another situation. Consider the code below:
+
+ my_polygon := my_rectangle
+ print (my_polygon.perimeter)
+ print (my_polygon.width) -- Is invalid
+
+
+We could apply perimeter to my_polygon and everything is fine ... we even get RECTANGLE 's specialized version of the feature. But it is invalid for us to try to apply width to my_polygon even though we feel (with rather strong conviction) that at this point in execution, my_polygon will be attached to an object of type RECTANGLE , and we know that width is a valid query on RECTANGLE s.
+
+The reason follows. When we declared my_polygon as type POLYGON , we made a deal that says that the only features that can be applied to my_polygon are the features of POLYGON . Remember that static typing guarantees us at compile time that at runtime there will be at least one version of the feature available that can be applied.
+
+ print (my_polygon.width) -- Is invalid
+
+
+But in the case above, the guarantee cannot be made. my_polygon is declared with class POLYGON which has no width feature, despite the fact that some of its proper descendants might.
+
+Does this mean that we can never do RECTANGLE things with this instance again, once we have attached it to my_polygon ?
+
+No. There is a language facility called the "assignment attempt" which will come to our rescue. The assignment attempt will allow us safely to attach our instance back to an entity typed as RECTANGLE . After doing so, we are free use RECTANGLE features.
+
+ my_polygon := my_rectangle
+ print (my_polygon.perimeter)
+ another_rectangle ?= my_polygon
+ print (another_rectangle.width)
+
+
+The assignment attempt uses the syntax "?=", versus the ":=" of assignment.
+
+This is significant ... as is the name assignment attempt. The reason is that it is possible in some context that my_polygon will be attached to something other than a rectangle when we do this:
+
+ another_rectangle ?= my_polygon
+
+
+If it were true that my_polygon were attached to an instance of say TRIANGLE when the assignment attempt above was executed, then another_rectangle would be left as a Void reference. As a consequence, it is prudent to check to see if the attachment has actually been made before trying to apply features. Applying a feature to a Void reference will cause an exception. Almost always, assignment attempt will be used in the following manner:
+
+ my_polygon := my_rectangle
+ print (my_polygon.perimeter)
+ another_rectangle ?= my_polygon
+ if another_rectangle /= Void then -- Make sure assignment happened
+ print (another_rectangle.width)
+ end
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki
new file mode 100644
index 00000000..1912aee1
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki
@@ -0,0 +1,48 @@
+[[Property:title|Referenced Assembly Type and Feature Name Conversion]]
+[[Property:weight|10]]
+The [[The Eiffel for .NET language|Eiffel for .NET language]] is Eiffel. It is not a variant of Eiffel that spawned a new language, as is '''C#''', or a dramatic evolution of Eiffel, such as '''Visual Basic .NET''' is to '''VB6'''. As Eiffel stands today, and will probably remain, Eiffel's conventions for class names and features names do not match that of the Pascal and Camel-casing conventions recommended by Microsoft. Eiffel also does not support the notion of full quantified type names. The period (''''.'''') between namespace and type names is not valid Eiffel syntax. These naming convention rules pose a problem for maintaining the Eiffel language. To address this issue, when referencing .NET assemblies, all referenced assembly type names and feature names are converted into "Eiffel-case" when using Eiffel.
+
+==What is Eiffel-Case?==
+
+Eiffel-casing is almost the same for both class and class feature names, all words are separated using underscores (''''_''''). The differences between them are class names are always in uppercase and feature names always in lowercase.
+
+MY_CLASS is an example of an Eiffel-cased class name.
+my_feature is an example of an Eiffel-cased feature name.
+
+There are complex rules to ensure that the automatic formatting of .NET name, type, method, property and otherwise are formatted to the most readable name possible, given their casing convention. One absolute is that the Eiffel compilation process will remove the namespace from the fully qualified type name and format just the type name.
+
+For example System.Windows.Forms.Border3DStyle would yield BORDER_3D_STYLE.
+
+Stripping the namespace from the name is essential to keep type names short and usable, who wants to use SYSTEM_WINDOWS_FORMS_BORDER_3D_STYLE? Dropping the namespace does present a potential problem; assemblies may have two type that are of the same name but are located in different namespaces. A resolution to this comes in the form of assembly prefixes. For every assembly a class name prefix can be specified. Eiffel Software have reserved a set of assembly prefix pairs which should not be change as they are used by the Eiffel class libraries. For example, ''System.Windows.Forms.dll'' contains a commonly used type called System.Windows.Forms.Form. During the compilation process ''System.Windows.Forms.dll'' will be evaluated and System.Windows.Forms.Form will yield the FORM Eiffel class name. ''System.Windows.Forms.dll'' has been assigned the 'WINFORMS_' prefix, so FORM would actually be WINFORMS_FORM instead.
+
+==Reserved Prefixes==
+
+The following table displays the fixed assembly class name prefixes, assigned by Eiffel Software, for the Microsoft Foundation Class Libraries:
+{|
+|-
+| mscorlib.dll
+| No Prefix
+|-
+| System.dll
+| SYSTEM_DLL_
+|-
+| System.XML.dll
+| XML_
+|-
+| System.Data.dll
+| DATA_
+|-
+| System.Web.dll
+| WEB_
+|-
+| System.EnterpriseServices.dll
+| ENTERPRISE_
+|-
+| System.Windows.Forms.dll
+| WINFORMS_
+|}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/using-referenced-assemblies.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/using-referenced-assemblies.wiki
new file mode 100644
index 00000000..237413fc
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/using-referenced-assemblies.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Using Referenced Assemblies]]
+[[Property:weight|8]]
+Eiffel for.NET is a first class citizen in the Microsoft.NET programming world. This means that if you are programming in Eiffel for.NET, say with ENViSioN!, you have full access to the thousands of software components in the .NET type libraries. But, that's not all. You also have full access to the thousands of components in the traditional Eiffel class libraries. And even that's not all. You have the ability to build software components which comply with.NET standards, so that they can be used by programmers using any other .NET language. Still not all. When you use Eiffel, you can choose to build software that will run under Microsoft.NET, but will be portable to other popular operating systems as well.
+
+Being an Eiffel for.NET programmer obviously put you in a very powerful position. How do you take advantage of it?
+
+To use.NET software components from Eiffel for.NET requires you to have some understanding of both.NET and Eiffel and how their respective object models differ. If you have read the rest of the help topics in [[Eiffel for.NET Language| this section]] then you have a pretty good idea of what the Eiffel method and language are all about.
+
+When you begin to build software in Eiffel for.NET, you will likely find a need to reuse types from the.NET libraries. These libraries are called assemblies. When you reference a assembly using Eiffel for.NET, the types in the assembly become available to you in a form that makes them look like so many Eiffel classes. The names for types and members will conform to Eiffel conventions. The same thing happens when you are programming against assemblies in Visual Basic.NET or Visual C#.NET.
+
+The section called [[Eiffel for .NET Conventions|Conventions]] covers the details the Eiffel conventions and how the.NET types are made available to Eiffel for.NET programmers.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/index.wiki
new file mode 100644
index 00000000..6cd9a528
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|The Eiffel for .NET language]]
+[[Property:weight|2]]
+* [[Eiffel for .NET: Introduction|Introduction]]
+* [[Eiffel for .NET Conventions|Using Eiffel on .NET]]
+* [[Eiffel for .NET|Summary of the Eiffel Language]]
+* [[Eiffel for .NET Limitations|Difference between Eiffel and Eiffel for .NET]]
+* [[Known issues|Known issues with Eiffel for .NET compiler]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/known-issues.wiki b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/known-issues.wiki
new file mode 100644
index 00000000..74e0118d
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/eiffel-net-language/known-issues.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Known issues]]
+[[Property:weight|4]]
+==Eiffel issues==
+* Check here first for the [[Eiffel for .NET Limitations|Difference between Eiffel and Eiffel for .NET]] .
+* The root creation routine of the root class must not take any arguments. You can access the command line given to the application via the class ARGUMENTS.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/index.wiki
new file mode 100644
index 00000000..2220948e
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|.NET]]
+[[Property:weight|-15]]
+* [[.NET Installation instructions|Installation instructions]]
+* [[Building a .NET application|Building a .NET application]]
+* [[The Eiffel for .NET language|Eiffel for .NET language description]]
+* [[Samples|Samples]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/net-installation-instructions.wiki b/documentation/current/platform-specifics/microsoft-windows/net/net-installation-instructions.wiki
new file mode 100644
index 00000000..eca0ed42
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/net-installation-instructions.wiki
@@ -0,0 +1,7 @@
+[[Property:title|.NET Installation instructions]]
+[[Property:weight|0]]
+Before installing the .NET components for Eiffel for .NET you need to install either the .NET Framework, the .NET Framework SDK or Visual Studio .NET. If you do not have any of those installed, the installation program will prompt you with a warning because no .NET features support will be installed.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/ado-net-samples/adonet-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/ado-net-samples/adonet-sample.wiki
new file mode 100644
index 00000000..8797e3a3
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/ado-net-samples/adonet-sample.wiki
@@ -0,0 +1,64 @@
+[[Property:title|ADO.NET Sample]]
+[[Property:weight|0]]
+This sample consist of a command line showing how to interact with a database.
+
+The DataReader object is somewhat synonymous with a read-only/forward-only cursor over data. The DataReader API supports flat as well as hierarchical data. A DataReader object is returned after executing a command against a database. The format of the returned DataReader object is different from a recordset. For example, you might use the DataReader to show the results of a search list in a web page.
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Select '''Use existing Ace (control file)''' and click '''OK'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\ado\ado3\''
+# Choose the Ace file for the version of the .net framework you are running
+# Choose the directory where the project will be compiled, by default the same directory containing the Ace file.
+# Click '''OK'''.
+
+
+==Running==
+
+After you launch the sample, the following output appears:
+
+Customer ID Company Name
+ALFKI Alfreds Futterkiste
+ANATR Ana Trujillo Emparedados y helados
+ANTON Antonio Moreno Taquera
+AROUT Around the Horn
+BERGS Berglunds snabbkp
+BLAUS Blauer See Delikatessen
+BLONP Blondesddsl p`re et fils
+BOLID Blido Comidas preparadas
+BONAP Bon app'
+BOTTM Bottom-Dollar Markets
+BSBEV B's Beverages
+CACTU Cactus Comidas para llevar
+CENTC Centro comercial Moctezuma
+CHOPS Chop-suey Chinese
+COMMI Comrcio Mineiro
+CONSH Consolidated Holdings
+DRACD Drachenblut Delikatessen
+DUMON Du monde entier
+EASTC Eastern Connection
+... ... ...
+WILMK Wilman Kala
+WOLZA Wolski Zajazd
+
+
+When the display is finished, the application wait for you to pressed the return key to finish the application.
+
+==Under the Hood==
+
+This application shows how to interact with a database. First the connection to the database is open ( create my_sql_connection . make_from_connection_string ( ''my_database'')), then a request to the database is made (create my_sql_command. make_from_cmd_text_and_connection ( ''my_command'', my_sql_connection )). Finally, the result of the request is displayed.
+
+This sample contains the following class:
+* SQL_DATA_READER
+* SQL_CONNECTION
+* SQL_COMMAND
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\howto\samples\adoplus subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/ado-net-samples/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/ado-net-samples/index.wiki
new file mode 100644
index 00000000..086bfe41
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/ado-net-samples/index.wiki
@@ -0,0 +1,7 @@
+[[Property:title|ADO .NET Samples]]
+[[Property:weight|0]]
+* [[ADO.NET Sample|Ado]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/console-samples/calculator-console.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/console-samples/calculator-console.wiki
new file mode 100644
index 00000000..384cfc4c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/console-samples/calculator-console.wiki
@@ -0,0 +1,101 @@
+[[Property:title|Calculator: console]]
+[[Property:weight|0]]
+=The Calculator Sample=
+
+This sample consists of a command line reverse Polish notation (RPN) calculator.
+{{note| '''Note:''' A RPN calculator works slightly differently from standard calculators. It consists of a stack of numbers. Operations are applied to the two numbers on top of the stack. The result is then put on top of the stack so that it can be used in the next operation. This sample refers to the top of the stack as ''Accumulator''. }}
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\base\calculator\''
+# Choose ''calculator.ecf''
+# Change the target from classic to dotnet
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After you launch the sample, the following text appears in a console:
+
+*********************************
+Calculator in reverse Polish form
+*********************************
+Allowable operations are:
+ '/': Divide top two numbers on the stack.
+ '0': Empty the stack.
+ 'a': Enter operand onto stack.
+ '?': Help.
+ '*': Multiply top two numbers on the stack.
+ '+': Add top two numbers on the stack
+ 'q': Quit.
+ '-': Subtract top two numbers on the stack.
+Enter a number, followed by :
+
+
+Enter the first number to be put onto the stack, for example 3 .
+
+'''Note:''' Failing to enter a number at this stage will cause the sample to stop. This sample was designed to showcase the use of EiffelBase data structures and is not protected against unexpected entries.
+
+You may then add another number on the stack by entering the character a :
+
+*********************************
+Calculator in reverse Polish form
+*********************************
+Allowable operations are:
+ '/': Divide top two numbers on the stack.
+ '0': Empty the stack.
+ 'a': Enter operand onto stack.
+ '?': Help.
+ '*': Multiply top two numbers on the stack.
+ '+': Add top two numbers on the stack
+ 'q': Quit.
+ '-': Subtract top two numbers on the stack.
+Enter a number, followed by : 3
+
+Accumulator = 3
+
+Next operation? a
+Enter a number, followed by :
+
+
+Enter a second number, for example 2 . You can then apply any operation to the two operands such as minus:
+
+...
+Next operation? a
+Enter a number, followed by : 2
+
+Accumulator = 2
+
+Next operation? -
+
+Accumulator = 1
+
+Next operation?
+
+
+You may use the operation 0 to clear the stack at any time. You may use q to quit the program.
+
+{{tip| '''Tip:''' You can use the command ? to display the list of available operations. }}
+
+==Under the Hood==
+
+This sample shows how to leverage EiffelBase data structures in a simple Eiffel system. The root class CALCULATOR first instantiates all ''state'' objects, each corresponding to one possible operation. The state classes all inherit from STATE. They are:
+* PLUS: Add stack's two top numbers.
+* MINUS: Substract stack's two top numbers.
+* MULTIPLY: Multiply stack's two top numbers.
+* DIVIDE: Divide stack's two top numbers.
+* EMPTY: Empty stack.
+* HELP: Prints available commands.
+* QUESTION: Get number from user.
+* QUIT: Close application.
+Each of these classes implement the feature do_one_state from STATE which performs the operation associated with the state.The initial state is QUESTION which asks for the initial number to put in the ''accumulator''. Following states depend on the user input.Every descendant of STATE implement the feature operation which performs the corresponding stack transformation.
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/console-samples/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/console-samples/index.wiki
new file mode 100644
index 00000000..3f3bf410
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/console-samples/index.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Console Samples]]
+[[Property:weight|1]]
+* [[Calculator: console|Calculator]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/index.wiki
new file mode 100644
index 00000000..e7737bc9
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/index.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Samples]]
+[[Property:weight|3]]
+In this chapter you will find a series of examples that will permit to you to understand the bases of programming with Dotnet.
+
+However, you should be familiar with Object-Oriented programming model. Almost all other examples can also be built for .NET if the dotnet target is choosen instead of classic.
+
+==Console sample==
+* [[Calculator: console|Calculator]]
+
+==Threads Samples==
+* [[Pools|Pools]]
+* [[Timers|Timers]]
+
+==ADO.NET sample==
+* [[ADO.NET Sample|ADO.NET]]
+
+==Windows Form samples==
+
+The following samples are classified from the easiest to the most complex one. So, some notions are introduced in the few first samples and will not be explained again in the complex samples!
+* [[Simple Hello world form sample|Hello world form]]
+* [[Message Box|Message box]]
+* [[Date Time Picker|Calendar and dates]]
+* [[Progress bar sample|Progress bar]]
+* [[Menus|Adding Menu to a Form]]
+* [[MDI|Writing MDI Applications]]
+* [[Tree view|Tree view]]
+* [[Calculator: winform|Calculator]]
+* [[GDI plus - text|Text (gdi plus)]]
+* [[Simple data binding|Simple data binding]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/index.wiki
new file mode 100644
index 00000000..a72c0f6f
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Threads Samples]]
+[[Property:weight|2]]
+* [[Pools|Pools]]
+* [[Timers|Timers]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/pools.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/pools.wiki
new file mode 100644
index 00000000..ff4dcc90
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/pools.wiki
@@ -0,0 +1,43 @@
+[[Property:title|Pools]]
+[[Property:weight|0]]
+This sample demonstrates use of the THREAD_POOL (ThreadPool) class. The sample queues up an asynchronous method call that is executed by a thread from the thread pool managed by the Common Language Runtime. The method "does some work" and then sets an event indicating that the work has finished. The main thread waits on the event and then exits.
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Select '''Use existing Ace (control file)''' and click '''OK'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\threading\pools\''
+# Choose the Ace file for the version of the .net framework you are running
+# Choose the directory where the project will be compiled, by default the same directory containing the Ace file.
+# Click '''OK'''.
+
+
+==Running==
+
+After you launch the sample, the following output appears:
+
+Main thread: Queuing an asynchronous operation.
+Main thread: Performing other operations.
+WorkItem thread: Performing asynchronous operation
+Main thread: Waiting for asynchronous operation to complete.
+
+
+When the display is finished, the application wait for you to pressed the return key to finished the application.
+
+==Under the Hood==
+
+This application shows how to use the thread THREAD_POOL. An asynchronous thread is launched ( feature { THREAD_POOL}. queue_user_work_item_wait_callback_object( create { WAIT_CALLBACK}. make ( Current , $ my_async_operation), l_async_operation_done )) and is associated to the local variable l_async_operation_done. Both threads perform simultaneously some operations. The main thread wait for the asynchronous thread to complete his own operations ( l_async_operation_done . wait_one) to close the application.
+
+This sample contains the following class:
+* THREAD_POOL
+* WAIT_CALLBACK
+* AUTO_RESET_EVENT
+
+==Notes==
+
+This sample is translated from the example located in the Samples\Technologies\Threading\Pools subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/timers.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/timers.wiki
new file mode 100644
index 00000000..088e2801
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/threads-samples/timers.wiki
@@ -0,0 +1,46 @@
+[[Property:title|Timers]]
+[[Property:weight|1]]
+This sample consist in a command line demonstrating the use of the TIMER (Timer) class to generate a periodic callback to a method. The sample creates a TIMER object and passes to it a delegate object. When the TIMER fires, the delegate is invoked, and a static method is called asynchronously by a worker thread in the thread pool.
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examplesdotnet\threading\timers\''
+# Choose ''timers.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After you launch the sample, the following output appears:
+
+Checking for status updates every two seconds
+
+Checking Status.
+Checking Status.
+Checking Status.
+Checking Status.
+Checking Status.
+...
+
+
+When the display is finished, the application wait for you to pressed the return key to finished the application.
+
+==Under the Hood==
+
+This application shows how to use the thread TIMER. The timer is launched ( create my_timer . make_with_callback ( create { TIMER_CALLBACK}. make (Current, $ check_status), Void, 0, 2000)) and call the feature check_status that displays the message "Checking Status." every two seconds.
+
+This sample contains the following class:
+* TIMER
+* TIMER_CALLBACK
+
+==Notes==
+
+This sample is translated from the example located in the Samples\Technologies\Threading\Timers subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/calculator-winform.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/calculator-winform.wiki
new file mode 100644
index 00000000..cd2e6205
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/calculator-winform.wiki
@@ -0,0 +1,51 @@
+[[Property:title|Calculator: winform]]
+[[Property:weight|-8]]
+
+[[Image:calculator|Calculator]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Select '''Use existing Ace (control file)''' and click '''OK'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\applications\world_calc''
+# Choose the Ace file for the version of the .net framework you are running
+# Choose the directory where the project will be compiled, by default the same directory containing the Ace file.
+# Click '''OK'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. This is a really simple calculator that can take only two operands. So you should enter the first operand, then enter an operator, then the second operand. Click the "Calculate" button to generate the result.
+
+
+
+==Under the Hood==
+
+The application uses two local external assemblies, math.dll and parserutils.dll.
+
+parserutils parses the command line entered, and checks if it is of the form operand1 operator operand2. math.dll calculates the actual result of the command line.
+
+For the parserutils.dll, we have been obliged to introduce the prefix "parser_" to avoid conflicts between name classes.
+
+This sample contains the following classes:
+* FORM
+* BUTTON
+* TEXT_FIELD
+* LABEL
+
+==Notes==
+
+This sample is translated from the example located in the Tutorials\resources and localization\worldcalc subdirectory of the.NET Framework SDK samples directory of Microsoft Visual Studio.NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/date-time-picker.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/date-time-picker.wiki
new file mode 100644
index 00000000..ee709806
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/date-time-picker.wiki
@@ -0,0 +1,57 @@
+[[Property:title|Date Time Picker]]
+[[Property:weight|1]]
+
+[[Image:date-time-picker|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\control_reference\date_time_picker_ctrl\''
+# Choose ''date_time_picker_ctrl.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. On the left side of the main window a date is displayed in a COMBO_BOX. Clicking on this COMBO_BOX and a CALENDAR control will appear showing the same date as in the COMBO_BOX. On the right side of the main window are the controls for selecting the format of the displayed date and the style of the CALENDAR control.
+
+Clicking on the "Change font" button and a change font dialog box will appear. [[Image:change-font-dialog|change font dialog box]] .
+
+Clicking on the "Change color" button and a dialog_box will appear. [[Image:dotnet-samples--date-time-picker-change-color-dlg|dialog box]] It will permit you to customize the color appearance of the calendar though a color dialog box [[Image:dotnet-samples--date-time-picker-change-color-dlg|color dialog box]] .
+
+
+
+==Under the Hood==
+
+This application uses several different controls, but tend to show how to parameter the CALENDAR control using the FONT_DIALOG and COLOR_DIALOG.
+
+When one of the buttons "Change font" or "Change color" is pressed, an event is launched and open the corresponding dialog box.
+
+When the entry in the COMBO_BOX format changes, an event is launched and modify the format of the displayed date.
+
+This sample contains the following classes:
+* CALENDAR
+* COMBO_BOX
+* BUTTON
+* LABEL
+* GROUP_BOX
+* CHECK_BOX
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\controlReference\dateTimePicker sub-directory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/gdi-plus-text.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/gdi-plus-text.wiki
new file mode 100644
index 00000000..b675421a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/gdi-plus-text.wiki
@@ -0,0 +1,44 @@
+[[Property:title|GDI plus - text]]
+[[Property:weight|-7]]
+
+[[Image:text|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\gdi_plus\text\''
+# Choose ''text.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above.
+
+
+
+==Under the Hood==
+
+This sample show how to draw some text in a window, using different brushes, different fonts, different style and different colors.
+
+This sample contains the following class:
+* FORM
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\gdiplus subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/index.wiki
new file mode 100644
index 00000000..663598fd
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Winform Samples]]
+[[Property:weight|3]]
+The following examples are classified from the easiest to the most complex one. So, some notions are introduced in the few first examples and will not be explained again in the complex examples!
+==Getting started==
+* [[Simple Hello world form sample|Hello world form]]
+* [[Message Box|Message box]]
+* [[Menus|Adding Menu to a Form]]
+* [[MDI|Writing MDI Applications]]
+
+==Building applications==
+* [[Calculator: winform|Calculator]]
+* [[GDI plus - text|Text (gdi plus)]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/index.wiki
new file mode 100644
index 00000000..583ad5e3
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/index.wiki
@@ -0,0 +1,50 @@
+[[Property:title|MDI]]
+[[Property:weight|-9]]
+
+[[Image:mdi|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\mdi\''
+# Choose ''mdi.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. The main window contains a menu with three entries (File, Format and Window). This menu can merge with its child windows (Document).
+
+In the "File" entry, you can add a child window (Document),display the active child window, and exit the program.
+
+You can change the format of the text displayed in the child windows using the entry "Format" in the menu.
+
+You can choose the organization (cascade, title horizontal or title vertical) of the child windows using the entry "Window" in the menu.
+
+
+
+==Under the Hood==
+
+This application demonstrates how to create a multiple document interface. More information regarding the use of a MDI, is available [[MDI Details|here]] .
+
+This sample contains the following class:
+* FORM
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\MDI subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/mdi-details.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/mdi-details.wiki
new file mode 100644
index 00000000..10763740
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/mdi-details.wiki
@@ -0,0 +1,51 @@
+[[Property:title|MDI Details]]
+[[Property:weight|0]]
+Multiple Document Interface (MDI) applications have a single, primary window (the parent window) that contains a set of windows within its client region (child windows). Each child window is a form that is constrained to appear only within the parent. Children typically share the menu bar, tool bar, and other parts of the parent's interface. Secondary windows like dialog boxes are not constrained to the parent window's client region.
+
+==Creating an MDI Application==
+
+You can create an MDI application by following these steps:
+# Create a '''Form''' ( '''MainForm''') that represents the MDI parent window and set its '''IsMdiContainer''' property to '''True'''. The following code demonstrates how to set this property.
+set_is_mdi_container (True)
+
+# Create child forms and set the '''MdiParent''' property of each form to reference the parent form. The following code demonstrates setting the MDI parent for an instance of a child form.
+doc.set_mdi_parent (Current)
+
+
+If you have different types of data to display, you can have multiple types of child forms. To display a child form, create an instance of the child form and call its '''Show''' method.
+
+
+
+==Standard MDI Menus==
+
+Typically, an MDI application has a '''Windows''' menu that allows the user to arrange the open child windows through tiling or cascading. The '''Windows''' menu also allows you to navigate to any of the open child windows. To create a '''Windows''' menu, add the menu items for tiling and cascading to a '''Windows''' menu in your parent form and set the '''MdiList''' property to '''True''' for the top-level '''Windows''' menu. The following code demonstrates how to create a '''Windows''' menu in an MDIapplication.
+mi_window: WINFORMS_MENU_ITEM
+
+mi_window := main_menu.get_menu_items.add (("&Window").to_cil)
+dummy := mi_window.get_menu_items.add_string_event_handler (("&Cascade").to_cil, create {EVENT_HANDLER}.make (Current, $window_cascade_clicked))
+dummy := mi_window.get_menu_items.add_string_event_handler (("Tile &Horizontal").to_cil, create {EVENT_HANDLER}.make (Current, $window_tile_h_clicked))
+dummy := mi_window.get_menu_items.add_string_event_handler (("Tile &Vertical").to_cil, create {EVENT_HANDLER}.make (Current, $window_tile_v_clicked))
+mi_window.set_mdi_list (True) -- Adds the MDI Window List to the bottom of the menu
+
+
+
+
+
+
+==Child Window Activation==
+
+If you want your parent form to be notified when a child window is activated by the user, you can register an event-handling method for the '''MdiChildActivate''' event. You can determine which child window is active by using the '''ActiveMdiChild''' property of the '''Form''' class. For example, the following code updates a '''StatusBar''' control on the parent form with the name of the child window.
+
+...
+add_mdi_child_activate (create {EVENT_HANDLER}.make (Current, $mdi_child_activated))
+...
+mdi_child_activated (sender: SYSTEM_OBJECT; e: EVENT_ARGS) is
+ do
+ status_bar.set_text (active_mdi_child.get_text)
+ end
+...
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/index.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/index.wiki
new file mode 100644
index 00000000..62f8a26a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/index.wiki
@@ -0,0 +1,42 @@
+[[Property:title|Menus]]
+[[Property:weight|-10]]
+
+[[Image:menu-principal|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. The main window contains a main menu with two entries (File and Format).
+
+The main window also has a blue LABEL that contains a context menu, that is the clone of "Format" in the main menu. Right click on the LABEL and a context menu will appear [[Image:menu-contextuel|context menu]] .
+
+
+
+==Under the Hood==
+
+This application shows how to create a main menu and how to associate a context menu to a control (here to a LABEL). More information regarding the use of menus, is available [[Menu Details|here]] .
+
+This sample contains the following class:
+* FORM
+* CONTEXT_MENU
+* MAIN_MENU
+* MENU_ITEM
+* EVENT_HANDLER
+* LABEL
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\menus subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/menu-details.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/menu-details.wiki
new file mode 100644
index 00000000..9ee94f76
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/menu-details.wiki
@@ -0,0 +1,143 @@
+[[Property:title|Menu Details]]
+[[Property:weight|0]]
+Windows Forms supports menus and context menus. Main menus are displayed on a menu bar that is located immediately below the title bar of a form. The menu bar contains top-level menu items that are used to group related submenu items. For example, by clicking a '''File''' top-level menu item, you can display menu items that are related to file operations. Menu items typically appear as commands for your application (such as '''New''' and '''Open'''),but they can also appear as separator bars and submenu items. You can display a check mark next to a menu item to display the state of a command or a the state of a feature in your application. In Windows Forms, main menus are represented by the '''MainMenu''' control.
+
+Context menus can be displayed for a specific control or area of your form. They are typically accessed by clicking the right mouse button. In Windows Forms, context menus are represented by the '''ContextMenu''' control.
+
+'''ContextMenu''' and '''MainMenu''' derive from '''Menu'''. They share many properties, methods, and events.
+
+==Adding a MainMenu to a Form==
+
+The following code demonstrates how to add a '''MainMenu''' to a form.
+
+ main_menu: WINFORMS_MAIN_MENU
+
+
+ create main_menu.make
+ set_menu (main_menu)
+
+
+==Adding a Context Menu to a Control==
+
+The following code demonstrates how to create a '''ContextMenu''' and assign it to a control.
+
+ label_1: WINFORMS_LABEL
+ label_1_context_menu: WINFORMS_CONTEXT_MENU
+
+
+ create label_1.make
+ create label_1_context_menu.make
+ label_1.set_context_menu (label_1_context_menu)
+
+
+==Adding Menu Items==
+
+In the following example, a '''File''' menu item is added to the '''MainMenu'''. The '''File''' menu item contains submenu items called '''Open''' and '''Exit'''.
+
+ mi_file: WINFORMS_MAIN_MENU
+
+
+ mi_file := main_menu. get_menu_items.add (("&File").to_cil )
+ dummy := mi_file. get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text (("&Open...").to_cil ))
+ dummy := mi_file. get_menu_items.add (("-").to_cil ) -- Gives us a separator
+ dummy := mi_file. get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text(("E&xit").to_cil )
+
+
+
+
+
+The following code demonstrates how to handle the '''Click''' event for both the '''Open''' and '''Exit''' menu items created in the previous code example.
+
+ mi_file := main_menu.get_menu_items.add (("&File").to_cil)
+ dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut
+ (("&Open...").to_cil, create {EVENT_HANDLER}.make (Current, $FileOpen_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_O))
+ dummy := mi_file.get_menu_items.add (("-").to_cil) -- Gives us a separator
+ dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut
+ (("E&xit").to_cil, create {EVENT_HANDLER}.make (Current, $FileExit_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_X))
+
+
+
+
+
+The following example demonstrates how to define shortcut keys for the menu items created in the previous example.
+
+ mi_file := main_menu.get_menu_items.add (("&File").to_cil)
+ dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut
+ (("&Open...").to_cil, create {EVENT_HANDLER}.make (Current, $FileOpen_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_O))
+ dummy := mi_file.get_menu_items.add (("-").to_cil) -- Gives us a separator
+ dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut
+ (("E&xit").to_cil, create {EVENT_HANDLER}.make (Current, $FileExit_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_X))
+
+
+
+
+==Adding Submenus==
+
+The following example demonstrates how to create submenus.
+
+ mi_format: WINFORMS_MAIN_MENU
+
+
+ -- Add Format Menu
+ mi_format := main_menu.get_menu_items.add (("F&ormat").to_cil)
+
+ -- Font Face sub-menu
+ create mmi_sans_serif.make_from_text_and_on_click ((("").to_cil).concat_string_string (("&1. ").to_cil,
+ sans_serif_font_family.get_name), create {EVENT_HANDLER}.make (Current, $FormatFont_Clicked))
+ mmi_sans_serif.set_checked (True)
+ mmi_sans_serif.set_default_item (True)
+ create mmi_serif.make_from_text_and_on_click ((("").to_cil).concat_string_string(("&2. ").to_cil,
+ serif_font_family.get_name), create {EVENT_HANDLER}.make (Current, $FormatFont_Clicked))
+ create mmi_mono_space.make_from_text_and_on_click ((("").to_cil).concat_string_string(("&3. ").to_cil,
+ mono_space_font_family.get_name), create {EVENT_HANDLER}.make (Current, $FormatFont_Clicked))
+
+ create l_array_menu_item.make (3)
+ l_array_menu_item.put (0, mmi_sans_serif)
+ l_array_menu_item.put (1, mmi_serif)
+ l_array_menu_item.put (2, mmi_mono_space)
+ dummy := mi_format.get_menu_items.add_string_menu_item_array (("Font &Face").to_cil, l_array_menu_item)
+
+
+
+
+==Adding Default Menu Items==
+
+The following example demonstrates how to specify a default menu item.
+
+ mmi_sans_serif: WINFORMS_MAIN_MENU
+
+
+ create mmi_sans_serif.make_from_text_and_on_click ((("").to_cil).concat_string_string (("&1 ").to_cil,
+ sans_serif_font_family.get_name), create {EVENT_HANDLER}.make (Current, $format_font_clicked))
+ mmi_sans_serif.set_checked (True)
+
+
+
+
+
+
+==Adding Check Marks to Menu Items==
+
+The following example demonstrates how to display a check mark next to a menu item. The code also demonstrates how to track which item is checked.
+
+ mi_medium: WINFORMS_MAIN_MENU
+
+
+ create mi_medium.make_from_text_and_on_click (("&Medium").to_cil, create {EVENT_HANDLER}.make (Current, $format_size_clicked))
+ mi_medium.set_checked (True)
+
+
+
+
+
+==Cloning Menus==
+
+In many cases, the context menu for a control is a subset of the main menu. You cannot add the same menu items to multiple menus, but you can clone a menu item or set of menu items. The following code demonstrates how to clone the '''Format''' menu created previously and add it to the context menu of a '''Label'''.
+ mmy := label_1_context_menu.get_menu_items.add_menu_item (mi_format.clone_menu)
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/message-box.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/message-box.wiki
new file mode 100644
index 00000000..a5d2045f
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/message-box.wiki
@@ -0,0 +1,56 @@
+[[Property:title|Message Box]]
+[[Property:weight|-11]]
+
+[[Image:hello-world|Hello world form]]
+ [[Image:message-box|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\hello_world_dlg\''
+# Choose ''hello_world_dlg.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above.
+
+Click on the BUTTON "Click Me!" and a message box will appear with the text that you have entered in the TEXT_FIELD.
+
+
+
+==Under the Hood==
+
+The application shows how to use the very useful MESSAGE_BOX control.
+
+An event ( EVENT_HANDLER) is associated to a control (here to the BUTTON). So the line '
+my_button.add_click (create {EVENT_HANDLER}.make (Current, $on_my_button_clicked ))
+associates a click to my_button to the feature on_my_button_clicked. So every time the BUTTON my_button is clicked, the feature on_my_button_clicked is executed.
+
+The feature my_button_clicked displays a MESSAGE_BOX ( feature { WINFORMS_MESSAGE_BOX}. show ( ''msg'')) with the text contained in TEXT_FIELD ( ''msg'' := my_text_field. text).
+
+This sample contains the following classes:
+* FORM
+* BUTTON
+* TEXT_FIELD
+* EVENT_HANDLER
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\accessible subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/progress-bar-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/progress-bar-sample.wiki
new file mode 100644
index 00000000..ba417e5c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/progress-bar-sample.wiki
@@ -0,0 +1,47 @@
+[[Property:title|Progress bar sample]]
+[[Property:weight|6]]
+
+[[Image:progress-bar|Hello world form]]
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\control_reference\progress_bar_ctl\''
+# Choose ''progress_bar_ctl.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. On the left of the form you have the PROGRESS_BAR control, and on the right you have some controls to configure the PROGRESS_BAR.
+
+
+
+==Under the Hood==
+
+The application shows how to configure a PROGRESS_BAR.
+
+The feature on_load is redefined and launch a thread (THREAD_START) that simulates the progression of a process.
+
+This sample contains the following classes:
+* PROGRESS_BAR
+* GROUP_BOX
+* TRACK_BAR
+* COMBO_BOX
+* LABEL
+* THREAD_START
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\controlReference\ProgressBar sub-directory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-data-binding.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-data-binding.wiki
new file mode 100644
index 00000000..bf19bfed
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-data-binding.wiki
@@ -0,0 +1,54 @@
+[[Property:title|Simple data binding]]
+[[Property:weight|7]]
+
+[[Image:simple-data-binding|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\data\simple_binding\''
+# Choose ''simple_binding.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above.
+
+This is a list of five customers you can parse, and we display the details of the current customer in the list.
+
+Clicking on the left button (|<) will bring you on the first customer of the list.
+
+Clicking on the left button (<) will bring you on the precedent customer in the list.
+
+Clicking on the right button (>) will bring you on the next customer in the list.
+
+Clicking on the right button (>|) will bring you on the last customer of the list.
+
+
+
+==Under the Hood==
+
+
+
+This sample contains the following class:
+* FORM
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\dataBinding subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-hello-world-form-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-hello-world-form-sample.wiki
new file mode 100644
index 00000000..5dc18550
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-hello-world-form-sample.wiki
@@ -0,0 +1,49 @@
+[[Property:title|Simple Hello world form sample]]
+[[Property:weight|-12]]
+
+[[Image:simple-hello-world|Hello world form]]
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\hello_world\''
+# Choose ''hello_world.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. This is the simplest windows form we can display. We have just set the title with "HelloWorld".
+
+
+
+==Under the Hood==
+
+The application shows how to display a Windows Form under the windows environment. The application inherits the FORM class, and just set the title with "Hello world" with the inherited feature set_title.
+
+ set_title (("Hello world").to_cil)
+
+
+The application is launched in a PROCESS with this command line:
+
+ feature {WINFORMS_APPLICATION}.run_form (Current).
+
+
+This sample contains the following classes:
+* FORM
+* WINFORMS_APPLICATION
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\simple hello world subdirectory of the.NET Framework SDK samples directory of Microsoft Visual Studio.NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/tree-view.wiki b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/tree-view.wiki
new file mode 100644
index 00000000..e850e150
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/net/samples/winform-samples/tree-view.wiki
@@ -0,0 +1,48 @@
+[[Property:title|Tree view]]
+[[Property:weight|9]]
+
+[[Image:tree-view|Hello world form]]
+
+
+
+
+
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\control_reference\tree_view_ctl\''
+# Choose ''tree_view_ctl.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. On the left of the form you have the TREE_VIEW control, and on the right you have some controls to configure the TREE_VIEW.
+
+
+
+==Under the Hood==
+
+The application shows how to use a TREE_VIEW and what are all its different configurations.
+
+This sample contains the following classes:
+* TREE_VIEW
+* GROUP_BOX
+* CHECK_BOX
+* COMBO_BOX
+* LABEL
+
+==Notes==
+
+This sample is translated from the example located in the QuickStart\winforms\samples\ControlReference\TreeView subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/resourcebench/features.wiki b/documentation/current/platform-specifics/microsoft-windows/resourcebench/features.wiki
new file mode 100644
index 00000000..76d1c3a3
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/resourcebench/features.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Features]]
+[[Property:weight|0]]
+* Parse any resource file (created by Microsoft Developer Studio or Borland Resource Workshop).
+* Show resources by using a tree view control.
+* Display some resource's informations.
+* Open and Save a Project (projects are not compatible with upcoming version of ResourceBench).
+* Generate both Eiffel Classes and resource file.
+* Let you specify which part of your resource file will be generated.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/resourcebench/index.wiki b/documentation/current/platform-specifics/microsoft-windows/resourcebench/index.wiki
new file mode 100644
index 00000000..2b62e2c4
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/resourcebench/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|ResourceBench]]
+[[Property:weight|1]]
+Type: Tool
+Platform: Any
+Version: 5.4
+Availability: Basic Package
+
+See:
+* [[Features|What does ResourceBench do?]]
+* [[Tour|How to use ResourceBench]]
+* [[Troubleshooting|Troubleshooting]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/resourcebench/tour.wiki b/documentation/current/platform-specifics/microsoft-windows/resourcebench/tour.wiki
new file mode 100644
index 00000000..db4e81e7
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/resourcebench/tour.wiki
@@ -0,0 +1,38 @@
+[[Property:title|Tour]]
+[[Property:weight|1]]
+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]]
+
+
+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.
+First, there is the preprocessing of the resource file:
+[[Image:prepro]]
+Then you have the analysis phase:
+[[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).
+[[Image:collaps]]
+You can expand the tree view to see associated resources for each resource's type.
+[[Image:expand]]
+At this point you are able to:
+* Select some properties for the Eiffel code generation
+* Save a project file
+* Generate Eiffel Code
+* Regenerate the same resource file (the third point is very useful when you have a Resource Bench Project and do not have the original resource file that permits its creation).
+
+
+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:
+[[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.
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/resourcebench/troubleshooting.wiki b/documentation/current/platform-specifics/microsoft-windows/resourcebench/troubleshooting.wiki
new file mode 100644
index 00000000..91d24e67
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/resourcebench/troubleshooting.wiki
@@ -0,0 +1,6 @@
+[[Property:title|Troubleshooting]]
+[[Property:weight|2]]
+If you have problems when you parse a resource file, you can first try to remove the grammar file (its name is "rb.gram"), and then re-launch Resource Bench. It creates again the grammar file to allow parsing resource files (on a Pentium 120 it takes less than one minute).
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/index.wiki
new file mode 100644
index 00000000..d209e6fa
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL Library]]
+[[Property:link_title|WEL]]
+[[Property:weight|-13]]
+Type: Library
+Platform: Windows
+
+See:
+* [[WEL Interface Content|Content]]
+* [[WEL Samples|Samples]]
+* [[ref:libraries/wel/reference/index|Reference]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki
new file mode 100644
index 00000000..164f0d3c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Common message hooks]]
+[[Property:weight|4]]
+Each WEL library component implements a set of routines for processing the most common messages that a component receives. For example, looking at [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , you will see that there are many features which begin `on_'. Each of these features enable the user to know when a specific event has occurred, and to perform the appropriate processing as a result of this event. Most of the time, you will only be interested in a small subset of these, necessary to your program. For example, below is the code for on_paint:
+
+ on_paint (paint_dc: WEL_PAINT_DC; invalid_rect: WEL_RECT) is
+ --Draw a centered text
+ do
+ end
+
+
+
+An on_paint message corresponds to the Wm_paint message generated by Windows whenever it needs to re-paint a window, and if you look at the feature, you can see that the arguments are a [[ref:libraries/wel/reference/wel_paint_dc_chart|WEL_PAINT_DC]] and a[[ref:libraries/wel/reference/wel_rect_chart| WEL_RECT]] . which are relevant to this message. By redefining this feature (and others as required), your code will be able to respond appropriately to windows events.
+{{note| '''Note'''. See [[Tutorial Step 2|step2]] in the [[Tutorial|tutorial]] for a simple demonstration involving the re-definition of on_left_button_down. }}
+
+
+For different messages received by a control, the arguments will differ (sometimes there are none), but those arguments will always be relevant to the message. For example, on_menu_command from [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] has an INTEGER as an argument, the value of which is a unique menu identifier.
+
+{{note| '''Note'''. Not all windows events have a corresponding `on_' message hook defined in WEL. If you wish to process a Windows message that does not correspond to one of the available features, you will need to redefine process_message.
+}}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/index.wiki
new file mode 100644
index 00000000..3e6308d6
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|WEL Common Concepts]]
+[[Property:weight|0]]
+Some useful WEL concepts are listed below:
+* [[Inheriting WEL_APPLICATION|Inheriting WEL_APPLICATION]]
+* [[Redefining main_window|Redefining main_window]]
+* [[Redefining `init_application'|Redefining init_application]]
+* [[Common message hooks|Common message hooks]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/inheriting-wel-application.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/inheriting-wel-application.wiki
new file mode 100644
index 00000000..afa46b61
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/inheriting-wel-application.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Inheriting WEL_APPLICATION]]
+[[Property:weight|1]]
+For most WEL applications that you write, you will need to inherit [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] .
+
+{{note| '''Note'''. See [[Tutorial Step 1|step1]] in the [[Tutorial|tutorial]] for a simple demonstration of how to do this }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-init-application.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-init-application.wiki
new file mode 100644
index 00000000..1c523584
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-init-application.wiki
@@ -0,0 +1,7 @@
+[[Property:title|Redefining `init_application']]
+[[Property:weight|2]]
+[[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] contains a feature init_application which does nothing by default, but is called before the application is started. This can be redefined to execute tasks that must be performed before the application is running. A common redefinition is to allow the loading of common dll's, see [[List View|list_view]] sample for a demonstration of this technique.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki
new file mode 100644
index 00000000..42a72665
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Redefining main_window]]
+[[Property:weight|1]]
+When you inherit [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] , you will need to implement the deferred feature main_window as a once function. This will be the main window of your application, and can be any descendent of [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] .
+
+{{note| '''Note'''. See [[Tutorial Step 2|step2]] in the [[Tutorial|tutorial]] for a simple demonstration of how to do this. }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/index.wiki
new file mode 100644
index 00000000..0101b3d1
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/index.wiki
@@ -0,0 +1,54 @@
+[[Property:title|Controls]]
+[[Property:link_title|controls cluster]]
+[[Property:weight|1]]
+==Overview==
+
+A Control is a window which provides a means of interacting with the application. For example, the [[ref:libraries/wel/reference/wel_edit_chart|WEL_EDIT]] control provides a user with the means of entering and modifying text. There are many common controls available within this cluster, each with a specific use.
+
+{{note| '''Note:''' Each control inherits from [[ref:libraries/wel/reference/wel_control_chart|WEL_CONTROL]] which is a descendent of [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] This provides the control with a large number of general features (including full window functionality). Each control also provides its own feature set which give access to specific properties of that control. }}
+
+==Creating controls==
+
+Each type of control generally has its own creation procedure that is specific to the type of control. For example, [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] has two creation procedures; make_vertical and make_horizontal. Depending on which of these two creation procedures used, you will get a scroll bar aligned vertically or horizontally.
+
+==Control types==
+
+The following effective controls are available within this cluster:
+* [[ref:libraries/wel/reference/wel_bitmap_button_chart|WEL_BITMAP_BUTTON]]
+* [[WEL_CHECKBOX|WEL_CHECK_BOX]]
+* [[WEL_CHECK_BOX_3_STATE|WEL_CHECK_BOX_3_STATE]]
+* [[ref:libraries/wel/reference/wel_drop_down_combo_box_chart|WEL_DROP_DOWN_COMBO_BOX]]
+* [[ref:libraries/wel/reference/wel_drop_down_combo_box_ex_chart|WEL_DROP_DOWN_COMBO_BOX_EX]]
+* [[ref:libraries/wel/reference/wel_drop_down_list_combo_box_chart|WEL_DROP_DOWN_LIST_COMBO_BOX]]
+* [[ref:libraries/wel/reference/wel_drop_down_list_combo_box_ex_chart|WEL_DROP_DOWN_LIST_COMBO_BOX_EX]]
+* [[ref:libraries/wel/reference/wel_flat_tool_bar_chart|WEL_FLAT_TOOL_BAR]]
+* [[WEL_GROUP_BOX|WEL_GROUP_BOX]]
+* [[ref:libraries/wel/reference/wel_header_control_chart|WEL_HEADER_CONTROL]]
+* [[ref:libraries/wel/reference/wel_imagelist_tool_bar_chart|WEL_IMAGE_LIST_TOOL_BAR]]
+* [[WEL_LIST_VIEW|WEL_LIST_VIEW]]
+* [[WEL_MULTIPLE_LINE_EDIT|WEL_MULTIPLE_LINE_EDIT]]
+* [[WEL_MULTIPLE_SELECTION_LIST_BOX|WEL_MULTIPLE_SELECTION_LIST_BOX]]
+* [[ref:libraries/wel/reference/wel_owner_draw_button_chart|WEL_OWNER_DRAW_BUTTON]]
+* [[WEL_PROGRESS_BAR|WEL_PROGRESS_BAR]]
+* [[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]]
+* [[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]]
+* [[ref:libraries/wel/reference/wel_rebar_chart|WEL_REBAR]]
+* [[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]]
+* [[WEL_SCROLL_BAR|WEL_SCROLL_BAR]]
+* [[ref:libraries/wel/reference/wel_selectable_button_chart|WEL_SELECTABLE_BUTTON]]
+* [[ref:libraries/wel/reference/wel_simple_combo_box_chart|WEL_SIMPLE_COMBO_BOX]]
+* [[WEL_SINGLE_LINE_EDIT|WEL_SINGLE_LINE_EDIT]]
+* [[WEL_SINGLE_SELECTION_LIST_BOX|WEL_SINGLE_SELECTION_LIST_BOX]]
+* [[ref:libraries/wel/reference/wel_static_chart|WEL_STATIC]]
+* [[ref:libraries/wel/reference/wel_static_bitmap_chart|WEL_STATIC_BITMAP]]
+* [[ref:libraries/wel/reference/wel_status_window_chart|WEL_STATUS_WINDOW]]
+* [[ref:libraries/wel/reference/wel_tab_control_chart|WEL_TAB_CONTROL]]
+* [[ref:libraries/wel/reference/wel_tool_bar_chart|WEL_TOOL_BAR]]
+* [[WEL_TOOLTIP|WEL_TOOLTIP]]
+* [[WEL_TRACK_BAR|WEL_TRACK_BAR]]
+* [[ref:libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]]
+* [[WEL_UP_DOWN_CONTROL|WEL_UP_DOWN_CONTROL]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-check-box-3-state.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-check-box-3-state.wiki
new file mode 100644
index 00000000..1bf4d3d0
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-check-box-3-state.wiki
@@ -0,0 +1,21 @@
+[[Property:title|WEL_CHECK_BOX_3_STATE]]
+[[Property:weight|1]]
+[[ref:libraries/wel/reference/wel_check_box_3_state_chart| A WEL_CHECK_BOX_3_STATE]] control can take three states, checked, indeterminate or unchecked.
+
+==Appearance==
+A [[ref:libraries/wel/reference/wel_check_box_3_state_chart|WEL_CHECK_BOX_3_STATE]]
+ [[Image:wel-check-box-3-state-unchecked|wel_check_box_3_state_unchecked]]
+
+A checked [[ref:libraries/wel/reference/wel_check_box_3_state_chart|WEL_CHECK_BOX_3_STATE]]
+ [[Image:wel-check-box-3-state-checked|wel_check_box_3_state_checked]]
+
+A indeterminate [[ref:libraries/wel/reference/wel_check_box_3_state_chart|WEL_CHECK_BOX_3_STATE]]
+ [[Image:wel-check-box-3-state-indeterminate|wel_check_box_3_state_indeterminate]]
+
+
+{{seealso| '''See also'''
+[[WEL_CHECKBOX|WEL_CHECK_BOX]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-checkbox.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-checkbox.wiki
new file mode 100644
index 00000000..e9252e6d
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-checkbox.wiki
@@ -0,0 +1,16 @@
+[[Property:title|WEL_CHECKBOX]]
+[[Property:weight|0]]
+A [[ref:libraries/wel/reference/wel_check_box_chart|WEL_CHECK_BOX]] control can take two states, checked or unchecked.
+
+==Appearance==
+A [[ref:libraries/wel/reference/wel_check_box_chart|WEL_CHECK_BOX]]
+ [[Image:wel-check-box-unchecked|wel_check_box_unchecked]]
+
+A checked [[ref:libraries/wel/reference/wel_check_box_chart|WEL_CHECK_BOX]]
+ [[Image:wel-check-box-checked|wel_check_box_checked]]
+{{seealso| '''See also'''
+[[WEL_CHECK_BOX_3_STATE|WEL_CHECK_BOX_3_STATE]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-down-control.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-down-control.wiki
new file mode 100644
index 00000000..1392cc8c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-down-control.wiki
@@ -0,0 +1,8 @@
+[[Property:title|WEL_UP_DOWN_CONTROL]]
+[[Property:weight|15]]
+A [[ref:libraries/wel/reference/wel_up_down_control_chart|WEL_UP_DOWN_CONTROL]] consists of a pair of arrows which are used to increment or decrement a value. Using set_buddy_window, a window of type [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] can be linked to this control, and is commonly used to display the current value.
+==Appearance==
+ [[Image:wel-up-down-control|wel_up_down_control]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-group-box.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-group-box.wiki
new file mode 100644
index 00000000..8a89a077
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-group-box.wiki
@@ -0,0 +1,9 @@
+[[Property:title|WEL_GROUP_BOX]]
+[[Property:weight|2]]
+A [[ref:libraries/wel/reference/wel_group_box_chart|WEL_GROUP_BOX]] is used to enclose other controls, and certain controls such as a [[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]] have special behavior when parented in a [[ref:libraries/wel/reference/wel_group_box_chart|WEL_GROUP_BOX]] .
+
+==Appearance==
+ [[Image:wel-group-box|wel_group_box]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-list-view.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-list-view.wiki
new file mode 100644
index 00000000..2f7d6c68
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-list-view.wiki
@@ -0,0 +1,18 @@
+[[Property:title|WEL_LIST_VIEW]]
+[[Property:weight|3]]
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] control is an encapsulation of the Windows List View control and provides several ways of displaying a collection of items. Each item can consist of a text and an icon. Certain styles allow additional information to be displayed in columns to the right of the icon and label.
+==Appearance==
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_report style.
+ [[Image:wel-list-view-style-lvs-report|list_view_style_lvs_report]]
+
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_list style.
+ [[Image:wel-list-view-style-lvs-list|list_view_style_lvs_list]]
+
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_icon style.
+ [[Image:wel-list-view-style-lvs-icon|list_view_style_lvs_icon]]
+
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_smallicon style.
+ [[Image:wel-list-view-style-lvs-small-icon|list_view_style_lvs_icon_small]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-line-edit.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-line-edit.wiki
new file mode 100644
index 00000000..3841ada0
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-line-edit.wiki
@@ -0,0 +1,9 @@
+[[Property:title|WEL_MULTIPLE_LINE_EDIT]]
+[[Property:weight|4]]
+A [[ref:libraries/wel/reference/wel_multiple_line_edit_chart|WEL_MULTIPLE_LINE_EDIT]] is used to display multiple lines of text. Using set_read_only, the text can be made non-editable.
+
+==Appearance==
+ [[Image:wel-multiple-line-edit|wel_multiple_line_edit]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-selection-list-box.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-selection-list-box.wiki
new file mode 100644
index 00000000..6f22b9ad
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-selection-list-box.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_MULTIPLE_SELECTION_LIST_BOX]]
+[[Property:weight|5]]
+A [[ref:libraries/wel/reference/wel_multiple_selection_list_box_chart|WEL_MULTIPLE_SELECTION_LIST_BOX ]] is a control used to display a list of STRING. Multiple items may be selected at once.
+
+==Appearance==
+ [[Image:wel-multiple-selection-list-box|wel_multiple_selection_list_box]]
+
+
+{{seealso| '''See also'''
+[[WEL_SINGLE_SELECTION_LIST_BOX|WEL_SINGLE_SELECTION_LIST_BOX]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-owner-draw-button.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-owner-draw-button.wiki
new file mode 100644
index 00000000..5000badd
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-owner-draw-button.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_OWNER_DRAW_BUTTON]]
+[[Property:weight|6]]
+A [[ref:libraries/wel/reference/wel_owner_draw_button_chart|WEL_OWNER_DRAW_BUTTON]] is a control that the user can click to provide notification to the application, and behaves in a similar fashion to [[ref:libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] except that on_paint must be implemented to give the button the desired appearance.
+
+==Appearance==
+
+There is no sample appearance for this control.
+
+{{seealso| '''See also'''
+[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-progress-bar.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-progress-bar.wiki
new file mode 100644
index 00000000..10ab9949
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-progress-bar.wiki
@@ -0,0 +1,12 @@
+[[Property:title|WEL_PROGRESS_BAR]]
+[[Property:weight|7]]
+A [[ref:libraries/wel/reference/wel_progress_bar_chart|WEL_PROGRESS_BAR]] control is an encapsulation of the Win32 progress bar. It can be used to display the progress of a lengthy operation.
+
+{{note| '''Note:''' By specifying the style Pbs_vertical, the progress bar will be displayed vertically. }}
+
+==Appearance==
+A [[ref:libraries/wel/reference/wel_progress_bar_chart|WEL_PROGRESS_BAR]] .
+ [[Image:wel-progress-bar-half|wel_progress_bar_half]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-push-button.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-push-button.wiki
new file mode 100644
index 00000000..c5c1e239
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-push-button.wiki
@@ -0,0 +1,8 @@
+[[Property:title|WEL_PUSH_BUTTON]]
+[[Property:weight|8]]
+A [[ref:libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] is a control that the user can click to provide notification to the application.
+==Appearance==
+ [[Image:wel-push-button|wel_push_button]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-radio-button.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-radio-button.wiki
new file mode 100644
index 00000000..7e032145
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-radio-button.wiki
@@ -0,0 +1,13 @@
+[[Property:title|WEL_RADIO_BUTTON]]
+[[Property:weight|9]]
+A [[ref:libraries/wel/reference/wel_radio_button_chart|WEL_RADIO_BUTTON]] control can take two states, checked or unchecked. By placing more than one of these in a [[ref:libraries/wel/reference/wel_group_box_chart|WEL_GROUP_BOX]] , they will become grouped, and only one may be checked at once.
+
+==Appearance==
+A [[ref:libraries/wel/reference/wel_radio_button_chart|WEL_RADIO_BUTTON]]
+ [[Image:wel-radio-button-unchecked|wel_radio_button_unchecked]]
+
+A checked [[ref:libraries/wel/reference/wel_radio_button_chart|WEL_RADIO_BUTTON]]
+ [[Image:wel-radio-button-checked|wel_radio_button_checked]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-scroll-bar.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-scroll-bar.wiki
new file mode 100644
index 00000000..01be9cfa
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-scroll-bar.wiki
@@ -0,0 +1,13 @@
+[[Property:title|WEL_SCROLL_BAR]]
+[[Property:weight|10]]
+A [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] control is an encapsulation of the Windows scroll bar control and is often used to specify which portion of a large control that cannot be viewed completely, is currently visible.
+
+==Appearance==
+A [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] created with make_horizontal.
+ [[Image:wel-scroll-bar-horizontal|wel_scroll_bar_horizontal]]
+
+A [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] created with make_vertical.
+ [[Image:wel-scroll-bar-vertical|wel_scroll_bar_vertical]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-line-edit.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-line-edit.wiki
new file mode 100644
index 00000000..6e2969de
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-line-edit.wiki
@@ -0,0 +1,8 @@
+[[Property:title|WEL_SINGLE_LINE_EDIT]]
+[[Property:weight|11]]
+A [[ref:libraries/wel/reference/wel_single_line_edit_chart|WEL_SINGLE_LINE_EDIT]] is a control used to input a single line of text.
+==Appearance==
+ [[Image:wel-single-line-edit|wel_single_line_edit]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-selection-list-box.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-selection-list-box.wiki
new file mode 100644
index 00000000..73e30ebd
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-selection-list-box.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_SINGLE_SELECTION_LIST_BOX]]
+[[Property:weight|12]]
+A [[ref:libraries/wel/reference/wel_single_selection_list_box_chart|WEL_SINGLE_SELECTION_LIST_BOX]] is a control used to display a list of STRING. Only one item may be selected at once.
+
+==Appearance==
+ [[Image:wel-single-selection-list-box|wel_single_selection_list_box]]
+
+
+{{seealso| '''See also'''
+[[WEL_MULTIPLE_SELECTION_LIST_BOX|WEL_MULTIPLE_SELECTION_LIST_BOX]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-tooltip.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-tooltip.wiki
new file mode 100644
index 00000000..4cee355a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-tooltip.wiki
@@ -0,0 +1,8 @@
+[[Property:title|WEL_TOOLTIP]]
+[[Property:weight|13]]
+A [[ref:libraries/wel/reference/wel_tooltip_chart|WEL_TOOLTIP]] is an encapsulation of the Win32 tooltip control, and controls pop-up windows which display text. Each tooltip may control multiple pop-up windows, which are added to the tooltip using add_tool.
+==Appearance==
+ [[Image:wel-tooltip|wel_tooltip]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-track-bar.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-track-bar.wiki
new file mode 100644
index 00000000..968f62bf
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-track-bar.wiki
@@ -0,0 +1,13 @@
+[[Property:title|WEL_TRACK_BAR]]
+[[Property:weight|14]]
+A [[ref:libraries/wel/reference/wel_track_bar_chart|WEL_TRACK_BAR]] control has a sliding pointer and optional tick marks.
+
+==Appearance==
+A [[ref:libraries/wel/reference/wel_track_bar_chart|WEL_TRACK_BAR]] created with make_horizontal.
+ [[Image:wel-track-bar-horizontal|wel_track_bar_horizontal]]
+
+A [[ref:libraries/wel/reference/wel_track_bar_chart|WEL_TRACK_BAR]] created with make_vertical.
+ [[Image:wel-track-bar-vertical|wel_track_bar_vertical]]
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/index.wiki
new file mode 100644
index 00000000..96a68a73
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/index.wiki
@@ -0,0 +1,21 @@
+[[Property:title|WEL Interface Content]]
+[[Property:weight|1]]
+WEL is an encapsulation of the Win32 Application Programming Interface (API), and provides users with a powerful means of creating Win32 Applications.
+
+==Components==
+
+The WEL library includes the following clusters:
+* [[Wel: Windows|windows]] cluster containing classes representing available windows types
+* [[Controls|controls]] cluster containing classes representing available controls
+* [[Standard Dialogs|stddlgs]] cluster containing classes representing standard Win32 dialogs
+* consts cluster which contains constants used by WEL
+* gdi cluster which contains classes allowing access to WIN32 Graphics Device Interfaces
+* gdistock cluster which contains standard Graphic Device Interfaces used by WEL
+* messages cluster which contains classes encapsulating windows messages
+* shared cluster which contains classes encapsulating system wide shared
+* structs cluster which contains classes for data structures required by Win32
+* support cluster which contains many supporting classes
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/index.wiki
new file mode 100644
index 00000000..6bce09b2
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Standard Dialogs]]
+[[Property:link_title|stddlgs cluster]]
+[[Property:weight|2]]
+This cluster contains different standard dialogs provided by WEL as listed below:
+* [[WEL_CHOOSE_COLOR_DIALOG|WEL_CHOOSE_COLOR_DIALOG]]
+* [[WEL_CHOOSE_FOLDER_DIALOG|WEL_CHOOSE_FOLDER_DIALOG]]
+* [[WEL_CHOOSE_FONT_DIALOG|WEL_CHOOSE_FONT_DIALOG]]
+* [[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+* [[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]]
+* [[WEL_SAVE_FILE_DIALOG|WEL_SAVE_FILE_DIALOG]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-color-dialog.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-color-dialog.wiki
new file mode 100644
index 00000000..75cc9367
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-color-dialog.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_CHOOSE_COLOR_DIALOG]]
+[[Property:weight|0]]
+The [[ref:libraries/wel/reference/wel_choose_color_dialog_chart|WEL_CHOOSE_COLOR_DIALOG]] is an encapsulation of the Win32 choose color dialog, and provides a means of selecting standard colors or creating custom colors.
+
+==Appearance==
+ [[Image:wel-choose-color-dialog|wel_choose_color_dialog]]
+
+
+{{seealso| '''See also'''
+[[Standard Dialogs|Standard dialogs]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-folder-dialog.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-folder-dialog.wiki
new file mode 100644
index 00000000..d0cd963a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-folder-dialog.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_CHOOSE_FOLDER_DIALOG]]
+[[Property:weight|1]]
+The [[ref:libraries/wel/reference/wel_choose_folder_dialog_chart|WEL_CHOOSE_FOLDER_DIALOG]] allows the directory structure to be viewed and a folder selected.
+
+==Appearance==
+ [[Image:wel-choose-folder-dialog|wel_choose_folder_dialog]]
+
+
+{{seealso| '''See also'''
+[[Standard Dialogs|Standard dialogs]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-font-dialog.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-font-dialog.wiki
new file mode 100644
index 00000000..8e140699
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-font-dialog.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_CHOOSE_FONT_DIALOG]]
+[[Property:weight|2]]
+The [[ref:libraries/wel/reference/wel_choose_font_dialog_chart|WEL_CHOOSE_FONT_DIALOG]] is an encapsulation of the Win32 choose font dialog, and provides a means of selecting a font available on the system.
+
+==Appearance==
+ [[Image:wel-choose-font-dialog|wel_choose_font_dialog]]
+
+
+{{seealso| '''See also'''
+[[Standard Dialogs|Standard dialogs]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-open-file-dialog.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-open-file-dialog.wiki
new file mode 100644
index 00000000..c5d38865
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-open-file-dialog.wiki
@@ -0,0 +1,15 @@
+[[Property:title|WEL_OPEN_FILE_DIALOG]]
+[[Property:weight|3]]
+The [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] is an encapsulation of the Win32 open file dialog, and provides a means of specifying a file to be opened.
+
+==Appearance==
+ [[Image:wel-open-file-dialog|wel_open_file_dialoG]]
+
+
+{{seealso| '''See also'''
+[[Standard Dialogs|Standard dialogs]]
+[[WEL_SAVE_FILE_DIALOG|WEL_SAVE_FILE_DIALOG]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-print-dialog.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-print-dialog.wiki
new file mode 100644
index 00000000..483bcc05
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-print-dialog.wiki
@@ -0,0 +1,14 @@
+[[Property:title|WEL_PRINT_DIALOG]]
+[[Property:weight|4]]
+The [[ref:libraries/wel/reference/wel_print_dialog_chart|WEL_PRINT_DIALOG]] is an encapsulation of the Win32 print dialog and provides a means of specifying print preferences.
+
+==Appearance==
+ [[Image:wel-print-dialog|wel_print_dialog]]
+
+
+{{seealso| '''See also'''
+[[Standard Dialogs|Standard dialogs]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-save-file-dialog.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-save-file-dialog.wiki
new file mode 100644
index 00000000..a7c44671
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-save-file-dialog.wiki
@@ -0,0 +1,15 @@
+[[Property:title|WEL_SAVE_FILE_DIALOG]]
+[[Property:weight|5]]
+The [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] is an encapsulation of the Win32 save file dialog, and provides a means of specifying a file name and location for saving.
+
+==Appearance==
+ [[Image:wel-save-file-dialog|wel_save_file_dialoG]]
+
+
+{{seealso| '''See also'''
+[[Standard Dialogs|Standard dialogs]]
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki
new file mode 100644
index 00000000..2d87a136
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki
@@ -0,0 +1,21 @@
+[[Property:title|Wel: Windows]]
+[[Property:link_title|windows cluster]]
+[[Property:weight|-1]]
+This cluster contains the different types of windows available to a [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] .
+
+The following effective window types are available:
+* [[ref:/libraries/wel/reference/wel_popup_window_chart|WEL_POPUP_WINDOW]]
+* [[ref:/libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]]
+* [[ref:/libraries/wel/reference/wel_modeless_dialog_chart|WEL_MODELESS_DIALOG]]
+* [[ref:/libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]]
+* [[ref:/libraries/wel/reference/wel_mdi_client_window_chart|WEL_MDI_CLIENT_WINDOW]]
+* [[ref:/libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]]
+* [[ref:/libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]]
+* [[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]]
+* [[ref:/libraries/wel/reference/wel_control_window_chart|WEL_CONTROL_WINDOW]]
+
+{{note| '''Note:''' A WEL application must contain at least one window. See the WEL [[Tutorial|Tutorial]] for details of how to set up your first window within a [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/bmpview.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/bmpview.wiki
new file mode 100644
index 00000000..0e93daf3
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/bmpview.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Bmpview]]
+[[Property:weight|-15]]
+[[Image:bmpview|bmpview]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\bmpview\''.
+* Choose ''bmpview.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed as illustrated above, although no child windows will be present. Selecting "Open" from the "File" menu will allow you to browse for a .BMP file to view. Multiple files may be opened and each opens in a new child window. The options on the "Window" menu provide features for positioning the child windows. Selecting "Close" will close the currently selected child window, while selecting "Exit" or closing the window manually will exit the program.
+==Under the Hood==
+MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] and redefines on_menu_command to handle the menu selections. CHILD_WINDOW inherits [[ref:libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] and implements make to load a named bitmap, while on_paint has been redefined to re-draw the bitmap. A [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] is used to select files for viewing.
+This sample contains the following classes:
+* BMP_VIEW
+* MAIN_WINDOW
+* CHILD_WINDOW
+* APPLICATION_IDS
+
+{{seealso| '''See Also'''
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+[[MDI (Multiple Document Interface)|Mdi sample]] }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/brushes.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/brushes.wiki
new file mode 100644
index 00000000..d966d313
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/brushes.wiki
@@ -0,0 +1,34 @@
+[[Property:title|Brushes]]
+[[Property:weight|-14]]
+[[Image:brushes|brushes]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\brushes\''.
+* Choose ''brushes.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program you will see a window displayed containing three push buttons marked "Brushes", "Rectangles" and "3D". Clicking "Brushes" will open a new window demonstrating different brushes available. Clicking "Rectangles" will open a new window within which many different shaped and colored rectangles will be drawn. Clicking"3D" will open a new window demonstrating the use of multiple bitmaps for animation.
+==Under the Hood==
+Each of the three windows that are opened from the programs MAIN_WINDOW inherit [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] and contains code for generating their output. BRUSHES_DEMO redefines idle_action to force a re-draw on the applicable windows.
+{{note| '''Note'''. If enable_idle_action is not called, then idle_action is never executed. }}
+
+This sample contains the following classes:
+* APPLICATION_IDS
+* BRUSH_DEMO
+* BRUSHES_DEMO
+* DEMO_3D
+* MAIN_WINDOW
+* PROJECTION
+* RECTANGLE_DEMO
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/commands.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/commands.wiki
new file mode 100644
index 00000000..54011665
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/commands.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Commands]]
+[[Property:weight|-12]]
+[[Image:commands|commands]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\commands\''.
+* Choose ''commands.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, you will see a window displayed with a similar appearance to the one illustrated above. Please follow the instructions displayed in the window.
+==Under the Hood==
+MAIN_DIALOG inherits [[ref:libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] which provides the feature put_command, used to associate a [[ref:libraries/wel/reference/wel_command_chart|WEL_COMMAND]] to a Windows message received by the window. A [[ref:libraries/wel/reference/wel_command_chart|WEL_COMMAND]] contains a deferred feature, execute which is executed when the command is fired. SHOW_COMMAND_INFORMATION, SHOW_MOUSE_BUTTON_INFORMATION and SHOW_MOVE_INFORMATION all inherit [[ref:libraries/wel/reference/wel_command_chart|WEL_COMMAND]] .
+{{note| '''Note '''execute has an argument of type ANY which is used to pass any additional information required. }}
+
+This sample contains the following classes:
+* APPLICATION_IDS
+* COMMANDS_DEMO
+* MAIN_DIALOG
+* SHOW_COMMAND_INFORMATION
+* SHOW_MOUSE_BUTTON_INFORMATION
+* SHOW_MOVE_INFORMATION
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/common-controls.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/common-controls.wiki
new file mode 100644
index 00000000..520c07d2
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/common-controls.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Common Controls]]
+[[Property:weight|-13]]
+[[Image:comctrls|comctrls]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\comctrls\''.
+* Choose ''comctrls.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file. If you select another directory than the default one, please copy icons (*.ico) and resource files (*.rc) from the default directory (the one containing the ecf file) to the new one.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as illustrated above. Selecting "Progress bar demonstration" from the "File" menu will update the progress bar to a full state. Leaving the mouse stationary above the track bar, progress bar or toolbar buttons will cause a tooltip control to be displayed.
+
+==Under the Hood==
+
+There is one [[ref:libraries/wel/reference/wel_tooltip_chart|WEL_TOOLTIP]] used for all the controls, but each control adds a new [[ref:libraries/wel/reference/wel_tool_info_chart|WEL_TOOL_INFO]] to provide different output for each control. The feature on_notify has been redefined to handle the Ttn_needtext notification which is posted by a control, and received by the controls parent, when a control needs to display a tooltip. The feature on_menu_select has been redefined to output the text of the selected menu item in the [[ref:libraries/wel/reference/wel_status_window_chart|WEL_STATUS_WINDOW]] located at the bottom of MAIN_WINDOW.
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* COMCTRLS_DEMO
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki
new file mode 100644
index 00000000..cd313540
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki
@@ -0,0 +1,44 @@
+[[Property:title|Wel Sample: Controls]]
+[[Property:link_title|Controls Sample]]
+[[Property:weight|-11]]
+[[Image:controls|controls]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\controls\''.
+* Choose ''controls.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, an empty window will be displayed. There are numerous menus in the window, each relating to a different type of [[Controls|control]] . Each menu has "Create" and "Delete" along with a other options specific to each control. By selecting these menu options, controls will be created and modified as demonstrated in the above illustration.
+
+==Under the Hood==
+
+Each menu is an instance of [[ref:libraries/wel/reference/wel_menu_chart|WEL_MENU]] and on_menu_command has been redefined in MAIN_WINDOW to perform the appropriate actions.
+This sample contains the following classes:
+* APPLICATION_IDS
+* CONTROLS
+* MAIN_WINDOW
+
+{{seealso| '''See Also'''
+[[WEL_LIST_VIEW|WEL_LIST_VIEW]]
+[[ref:/libraries/wel/reference/wel_combo_box_chart|WEL_COMBO_BOX]]
+[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]]
+[[ref:/libraries/wel/reference/wel_edit_chart|WEL_EDIT]]
+[[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]]
+[[WEL_PUSH_BUTTON|WEL_CHECK_BUTTON]]
+[[WEL_MULTIPLE_LINE_EDIT|WEL_MULTIPLE_LINE_EDIT]]
+[[WEL_SCROLL_BAR|WEL_SCROLL_BAR]] }}
+
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/ctlcolor.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/ctlcolor.wiki
new file mode 100644
index 00000000..61455e71
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/ctlcolor.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Ctlcolor]]
+[[Property:weight|-10]]
+[[Image:ctlcolor|ctlcolor]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\ctlcolor\''.
+* Choose ''ctlcolor.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, you will see a window displayed as above. Clicking on the "Foreground color" button will display a color dialog which allows you to select a new foreground color for the controls. Clicking on the "Background color" button will display a color dialog which allows you to select a new background color for the controls.
+
+==Under the Hood==
+
+A [[ref:libraries/wel/reference/wel_color_control_chart|WEL_COLOR_CONTROL]] is used to retrieve the color selection of the user through the feature rgb_result which returns an object of type [[ref:libraries/wel/reference/wel_color_ref_chart|WEL_COLOR_REF]] .
+
+This sample contains the following classes:
+* CTLCOLOR_DEMO
+* MAIN_WINDOW
+* MY_BUTTON
+* PRECOMP_MAIN_WINDOW
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/cursors.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/cursors.wiki
new file mode 100644
index 00000000..5e9eb7da
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/cursors.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Cursors]]
+[[Property:weight|-9]]
+[[Image:cursors|cursors]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\cursors\''.
+* Choose ''cursors.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as illustrated above. Selecting one of the cursor types from the "Cursors" menu will cause the selected cursor to be displayed when the mouse pointer is over the client area of the window.
+
+==Under the Hood==
+
+The feature on_menu_command has been redefined in MAIN_WINDOW to create the appropriate cursor when a menu selection is made, while on_set_cursor has been redefined to update the style of the displayed cursor.
+
+This sample contains the following classes:
+* CURSORS_DEMO
+* MAIN_WINDOW
+* APPLICATION_IDS
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/disk-space.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/disk-space.wiki
new file mode 100644
index 00000000..3ecc6a28
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/disk-space.wiki
@@ -0,0 +1,30 @@
+[[Property:title|Disk Space]]
+[[Property:weight|-8]]
+[[Image:diskspace|diskspace]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\diskspace\''.
+* Choose ''diskspace.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the application, you will see text output showing the size and amount of free space available on each of your local drives.
+
+==Under the Hood==
+
+DISCSPACE_DEMO contains a once feature, diskspace which returns an instance of [[ref:libraries/wel/reference/wel_disk_space_chart|WEL_DISK_SPACE]] , used to query the local drives.
+
+This sample contains only one class:
+* DISKSPACE_DEMO
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/fontenum.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/fontenum.wiki
new file mode 100644
index 00000000..d2b44d98
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/fontenum.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Fontenum]]
+[[Property:weight|-7]]
+[[Image:fontenum|fontenum]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\fontenum\''.
+* Choose ''fontenum.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file. If you select another directory than the default one, please copy icons (*.ico) and resource files (*.rc) from the default directory (the one containing the ecf file) to the new one.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as illustrated above. Selecting one of the available fonts (Listed on the left hand side) will cause a sample text to be displayed in the currently entered font size. Clicking the button marked "Close" will cause the program to end.
+
+==Under the Hood==
+
+MAIN_DIALOG inherits from [[ref:libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] and also WEL_FONT_FAMILY_ENUMERATOR. MAIN_DIALOG implements action which was deferred from WEL_FONT_ENUMERATOR and executed every an enumeration finds a new font. This new implementation is used to display the available fonts in the [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]]
+
+This sample contains the following classes:
+* APPLICATION_IDS
+* FONTENUM_DEMO
+* MAIN_DIALOG
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/fun.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/fun.wiki
new file mode 100644
index 00000000..b4548073
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/fun.wiki
@@ -0,0 +1,31 @@
+[[Property:title|Fun]]
+[[Property:weight|-6]]
+[[Image:fun|fun]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\fun\''.
+* Choose ''fun.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed as illustrated above. Clicking the push button marked "Maze" will open a new window and draw a maze within this window. Clicking the push button marked "Artist" will open a new window, and display output dependent on the movement of the mouse pointer within the client area of that window. Clicking the push button marked "Fun" will open a new window which contains a fake error message and a close push button which moves when you try to move the mouse pointer over it.
+==Under the Hood==
+Both FUN_DIALOG and ARTIST redefine on_mouse_move to track the actions of the mouse pointer and respond accordingly.
+This sample contains the following classes:
+* APPLICATION_IDS
+* ARTIST
+* FUN_DEMO
+* FUN_DIALOG
+* MAIN_WINDOW
+* MAZE
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki
new file mode 100644
index 00000000..ea11a021
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Header Control]]
+[[Property:weight|-5]]
+[[Image:header-ctrl|header_ctrl]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\header_ctrl\''.
+* Choose ''header_ctrl.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file. If you select another directory than the default one, please copy icons (*.ico) and resource files (*.rc) from the default directory (the one containing the ecf file) to the new one.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as shown above. By manipulating the header control, you will see notification of the events that occur displayed in the [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] situated below.
+
+==Under the Hood==
+
+HEADER_CONTROL inherits [[ref:libraries/wel/reference/wel_header_control_chart|WEL_HEADER_CONTROL]] and redefines many of the `on_' notification features to display the output.
+
+This sample contains the following classes:
+* APPLICATION_IDS
+* HEADER_CONTROL
+* HEADER_CONTROL_DEMO
+* MAIN_WINDOW
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki
new file mode 100644
index 00000000..5b933f56
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki
@@ -0,0 +1,45 @@
+[[Property:title|Hello World]]
+[[Property:link_title|Hello World!]]
+[[Property:weight|-4]]
+[[Image:hello|hello]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\hello\''.
+* Choose ''hello.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After you launch the sample, You should see a window displayed as illustrated above. You will have full control over the window, and the program will quit when you close the window.
+
+==Under the Hood==
+
+MAIN_WINDOW inherits WEL_FRAME_WINDOW. In this example, we have redefined on_paint as shown below:
+
+on_paint (paint_dc: WEL_PAINT_DC; invalid_rect: WEL_RECT) is
+ --Draw a centered text
+ is
+ paint_dc.draw_centered_text("Hello, World!", client_rect)
+ end
+
+
+{{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. }}
+
+This sample contains the following classes:
+* HELLO_DEMO
+* MAIN_WINDOW
+
+
+{{seealso| '''See Also'''
+[[Tutorial Step 3|Tutorial Step3]]
+[[Common message hooks|Common message hooks]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/index.wiki
new file mode 100644
index 00000000..90ee112c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/index.wiki
@@ -0,0 +1,45 @@
+[[Property:title|WEL Samples]]
+[[Property:weight|4]]
+There are a large number of samples provided with the WEL library, each designed to demonstrate different functionality. The samples available are listed below:
+* [[Tutorial|Tutorial]]
+{{note| '''Note''': If you are new to WEL programming, this is the recommended place to start. }}
+** [[Tutorial Step 1|Step1]]
+** [[Tutorial Step 2|Step2]]
+** [[Tutorial Step 3|Step3]]
+** [[Tutorial Step 4|Step4]]
+** [[Tutorial Step 5|Step5]]
+** [[Tutorial Step 6|Step6]]
+** [[Tutorial Step 7|Step7]]
+** [[Tutorial Step 8|Step8]]
+
+* [[Hello World|Hello]]
+* [[Bmpview|Bmpview]]
+* [[Brushes|Brushes]]
+* [[Common Controls|Comctrls]]
+* [[Commands|Commands]]
+* [[Wel Sample: Controls|Controls]]
+* [[Ctlcolor|Ctlcolor]]
+* [[Cursors|Cursors]]
+* [[Disk Space|Diskspace]]
+* [[Fontenum|Fontenum]]
+* [[Fun|Fun]]
+* [[Header Control|Header_ctrl]]
+* [[List View|List_view]]
+* [[Magnify|Magnify]]
+* [[MDI (Multiple Document Interface)|Mdi]]
+* [[Wel Sample: Menus|Menus]]
+* [[Minimal|Minimal]]
+* [[Pizza|Pizza]]
+* [[Printer|Printer]]
+* [[Rich Edit|Richedit]]
+* [[Split Area|Split Area]]
+* [[Wel Sample: Standard Dialogs|Stddlgs]]
+* [[Timer|Timer]]
+* [[Wel Sample: Tree View|Tree_view]]
+* [[Wel Sample: Windows|Windows]]
+* [[Xcell|Xcell]]
+* [[XY Co-ordinates|Xy]]
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki
new file mode 100644
index 00000000..9955dfb9
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki
@@ -0,0 +1,38 @@
+[[Property:title|List View]]
+[[Property:weight|-3]]
+[[Image:list-view|list_view]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\list_view\''.
+* Choose ''list_view.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed containing a pair of [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] . Clicking the button marked "style" will modify the style of the lower list view. If you click the mouse within this lower list view, you will see notification of events appearing in the upper list view.
+==Under the Hood==
+
+LISTVIEW_DEMO redefines init_application in order to load the [[ref:libraries/wel/reference/wel_common_controls_dll_chart|WEL_COMMON_CONTROLS_DLL]] and the [[ref:libraries/wel/reference/wel_rich_edit_dll_chart|WEL_RICH_EDIT_DLL]] .
+
+LISTVIEW redefines many of the `on_' features inherited from [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] in order to generate output for the user.
+
+The style of the LISTVIEW_DEMO is changed by calling set_style with the required new style.
+
+This sample contains the following classes:
+* LISTVIEW
+* MAIN_WINDOW
+* LISTVIEW_DEMO
+* APPLICATION_IDS
+
+{{seealso| '''See Also'''
+WEL_LIST_VIEW }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/magnify.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/magnify.wiki
new file mode 100644
index 00000000..d979447c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/magnify.wiki
@@ -0,0 +1,30 @@
+[[Property:title|Magnify]]
+[[Property:weight|-2]]
+[[Image:magnify|MAGNIFY]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\magnify\''.
+* Choose ''magnify.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the application, you will see a window displayed with a similar appearance to the one above. Selecting "Quick reference..." from the "Help" menu will display the full instructions for using this application.
+==Under the Hood==
+
+In order to be able to control the output of the sample, MAIN_WINDOW redefines many features from [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . The feature draw_zoom_rectangle is used to display the output and on_menu_command handles the notifications sent to the window when a menu_selection has been made.
+
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* MAGNIFY_DEMO
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/mdi-multiple-document-interface.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/mdi-multiple-document-interface.wiki
new file mode 100644
index 00000000..b0cacb01
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/mdi-multiple-document-interface.wiki
@@ -0,0 +1,31 @@
+[[Property:title|MDI (Multiple Document Interface)]]
+[[Property:weight|-1]]
+[[Image:mdi--mdi|mdi]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\mdi\''.
+* Choose ''mdi.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed as illustrated above. Selecting "New" from the "File" menu will create a new child window, while selecting "Close" will close the currently selected child window. The options available on the "Window" menu allow positioning of the child windows. Selecting "Exit" from the "File" menu or closing the window manually will exit the program.
+==Under the Hood==
+MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] to provide the multiple document interface behavior while each child window is of type [[ref:libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] . When "Close" is selected from the "File" menu, the feature active_window from [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] is used to select the window that must be closed.
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* MDI_DEMO
+
+{{seealso| '''See Also'''
+[[Bmpview|Bmpview]] }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki
new file mode 100644
index 00000000..79f5eb96
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki
@@ -0,0 +1,30 @@
+[[Property:title|Minimal]]
+[[Property:weight|1]]
+[[Image:minimal|minimal]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\minimal\''.
+* Choose ''minimal.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed as illustrated above. There is no other functionality, but clicking on the close icon (Cross in top right hand corner), will close the window.
+==Under the Hood==
+MINIMAL_DEMO inherits [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] and redefines main_window in order to display a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] .
+This sample contains only one class:
+* MINIMAL_DEMO
+
+
+{{seealso| '''See Also'''
+[[Tutorial Step 1|tutorial step 1]]
+[[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/pizza.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/pizza.wiki
new file mode 100644
index 00000000..e774ddf4
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/pizza.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Pizza]]
+[[Property:weight|2]]
+=Pizza Sample=
+ [[Image:pizza|pizza]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\pizza\''.
+* Choose ''pizza.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed titled "WEL Pizza" If you select "Order" from the "Pizza" menu, a new window will appear (Illustrated above), which allows you to enter details of a new pizza order. When the order is completed, clicking the "ok" button will display the details of the order that was entered. Selecting "Exit from the "Pizza" menu or closing the original window will exit the program.
+
+==Under the Hood==
+MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] while DIALOG inherits [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] . DIALOG demonstrates the use of a selection of common controls to build a custom user interface.
+This sample contains the following classes:
+* APPLICATION_IDS
+* DIALOG
+* MAIN_WINDOW
+* PIZZA_DEMO
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/printer.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/printer.wiki
new file mode 100644
index 00000000..652a3dba
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/printer.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Printer]]
+[[Property:weight|3]]
+[[Image:printer|printer]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\printer\''.
+* Choose ''printer.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as illustrated above. Selecting "Print" from the "File" menu will open a print dialog which will allow you to specify a printer and additional print information before printing the contents of the window.
+
+==Under the Hood==
+MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] and the feature on_paint has been redefined to display the output in the client area. A [[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]] is used to retrieve the print options before the printing occurs through the interface provided by a [[ref:libraries/wel/reference/wel_printer_dc_chart|WEL_PRINTER_DC]] .
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* PRINTER_DEMO
+
+{{seealso| '''See Also'''
+[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]] }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki
new file mode 100644
index 00000000..ba492589
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki
@@ -0,0 +1,42 @@
+[[Property:title|Rich Edit]]
+[[Property:weight|4]]
+[[Image:richedit|richedit]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\richedit\''.
+* Choose ''richedit.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as shown above. The program is a simple text editor which allows you to load and save files; select fonts and colors; and print files. The operations are accessible through the menu bar and/or the tool bar.
+
+==Under the Hood==
+
+Both the menu items and the tool bar buttons are handled by on_menu_command which has been redefined in MAIN_WINDOW.
+
+Four of the [[Standard Dialogs|standard dialogs]] provided by WEL are used to receive input from the user.
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* RICHEDIT_DEMO
+
+{{seealso| '''See Also'''
+[[ref:/libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]]
+[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]]
+[[WEL_SAVE_FILE_DIALOG|WEL_SAVE_FILE_DIALOG]]
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+[[WEL_CHOOSE_COLOR_DIALOG|WEL_CHOOSE_COLOR_DIALOG]]
+[[WEL_CHOOSE_FONT_DIALOG|WEL_CHOOSE_FONT_DIALOG]] }}
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki
new file mode 100644
index 00000000..84c7df1e
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki
@@ -0,0 +1,33 @@
+[[Property:title|Split Area]]
+[[Property:weight|5]]
+[[Image:splitarea|splitarea]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\splitarea\''.
+* Choose ''split_area.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed containing a pair of [[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] in a split area. Clicking the mouse on the split area (between the two rich edits) and dragging the mouse, will adjust the split area and its content accordingly.
+==Under the Hood==
+
+There is no split area class provided with WEL, but WEL_SPLIT_AREA was created for this sample to illustrate how new controls can be built when required. Redefining some of the `on_' features inherited from [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] in WEL_SPLIT_AREA shows how the control over the contents of the split area is achieved.
+
+This sample contains the following classes:
+* APPLICATION
+* SPLIT_AREA_DEMO
+* WEL_SPLIT_AREA
+
+
+{{seealso| '''See Also'''
+[[ref:/libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/standard-dialogs-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/standard-dialogs-sample.wiki
new file mode 100644
index 00000000..15951aba
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/standard-dialogs-sample.wiki
@@ -0,0 +1,35 @@
+[[Property:title|Wel Sample: Standard Dialogs]]
+[[Property:link_title|Standard Dialogs Sample]]
+[[Property:weight|6]]
+[[Image:stddlgs|stddlgs]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\stddlgs\''.
+* Choose ''stddlgs.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will displayed with a menu allowing you to select some of the standard dialogs provided by WEL.
+==Under the Hood==
+on_menu_command has been redefined in MAIN_WINDOW to display a different standard dialog when each of the menu items is selected.
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* STDDLG_DEMO
+
+{{seealso| '''See Also'''
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+[[WEL_CHOOSE_FONT_DIALOG|WEL_CHOOSE_FONT_DIALOG]]
+[[WEL_CHOOSE_COLOR_DIALOG|WEL_CHOOSE_COLOR_DIALOG]]
+[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]] }}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/timer.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/timer.wiki
new file mode 100644
index 00000000..957302a8
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/timer.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Timer]]
+[[Property:weight|7]]
+[[Image:timer|timer]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\timer\''.
+* Choose ''timer.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, a window will be displayed as illustrated above. Clicking on any of the push buttons marked "Start Timer" will start a timer running, and the hatched area immediately above the push button will change its appearance to reflect the interval of the timer.
+==Under the Hood==
+A [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] supports multiple timers, set by set_timer which takes a unique id for each timer. The on_timer feature is called every time a timer interval is reached with an argument corresponding to the id of the timer. Within MAIN_WINDOW, on_timer has been redefined to update the appearance of the hatched areas.
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* TIMER
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki
new file mode 100644
index 00000000..f25d25a7
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki
@@ -0,0 +1,37 @@
+[[Property:title|Wel Sample: Tree View]]
+[[Property:link_title|Tree View Sample]]
+[[Property:weight|8]]
+[[Image:tree-view--tree-view|tree_view]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tree_view\''.
+* Choose ''tree_view.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as illustrated above. Selecting or expanding one of the tree items will cause notification to be displayed in the list at the top of the window. Various other notifications are also displayed, such as pressing a key in the tree.
+
+==Under the Hood==
+
+TREEVIEW inherits [[ref:libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] and redefines make to initialize items within the tree. A [[ref:libraries/wel/reference/wel_tree_view_insert_struct_chart|WEL_TREE_VIEW_INSERT_STRUCT]] is used to insert each [[ref:libraries/wel/reference/wel_tree_view_item_chart|WEL_TREE_VIEW_ITEM]] while a [[ref:libraries/wel/reference/wel_image_list_chart|WEL_IMAGE_LIST]] is used to reference images within the tree.
+This sample contains the following classes:
+* TREEVIEW
+* MAIN_WINDOW
+* TREEVIEW_DEMO
+* APPLICATION_IDS
+
+{{seealso| '''See Also'''
+[[ref:/libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] }}
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/unicode-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/unicode-sample.wiki
new file mode 100644
index 00000000..7ddc966d
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/unicode-sample.wiki
@@ -0,0 +1,43 @@
+[[Property:title|Wel Sample: Unicode]]
+[[Property:link_title|Unicode Sample]]
+[[Property:weight|9]]
+[[Image:unicode|unicode]]
+
+
+==Requirements==
+
+This sample demonstrates Unicode compatibility. It therefore assumes a fully Unicode compatible operating system and recommends the system has more than one input locale installed. The system used to generate the above screenshot shows the sample running on Windows 2000 with the Korean IME installed. Since Windows 95/98/Me does not provide full built-in support for Unicode please refer to "Compiling WEL for Unicode on Windows 95/98/Me" before attempting to run this example.
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\unicode\''.
+* Choose ''unicode.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will be displayed as illustrated above. Selecting the input locale combo box will allow you to switch to a new input locale. To add new input locales to your system do the following:
+* Click on '''Start''' -> '''Settings''' -> '''Control Panel''' -> '''Regional Options'''
+* Select the ''' Input Locale''' tab and click '''Add'''.
+* Select the input locale then click '''OK'''
+* To test the new input locale restart the Unicode sample.
+Selecting an input locale allows entry of the chosen input locale characters into the rich-edit control to right. Clicking the "Apply to Controls" button will update the controls in the pane below to display the same text as the rich-edit control. If the selected input locale is associated with an Input Method Editor (IME), the details for this will be displayed in the "Input Method Editor" group box and IME specific options will be made available from the "IME Options" menu.
+
+==Under the Hood==
+
+There is one MAIN_WINDOW class used for all the controls. The feature init_locale_list is used to determine the systems available input locales and populate the corresponding "Input Locales" combo box. The features 'change_font' and 'change_control' are used to change the applications font (in case the currently selected font does not correctly display Unicode characters), and to set the text property of all controls to the same as that in the rich-edit box.
+This sample contains the following classes:
+* UNICODE_DEMO
+* MAIN_WINDOW
+* DISPLAY_TEXT
+* APPLICATION_IDS
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/wel-sample-menus.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/wel-sample-menus.wiki
new file mode 100644
index 00000000..e23ace55
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/wel-sample-menus.wiki
@@ -0,0 +1,27 @@
+[[Property:title|Wel Sample: Menus]]
+[[Property:weight|0]]
+[[Image:menus|menus]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\menus\''.
+* Choose ''menus.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the program, you will see a window displayed with a similar appearance to the one displayed above. If you right click in the client area of the window, a menu will pop up at the cursor position. The same menu is also accessible from the "File" menu. Selecting any of the menu options will display a notification of which option was selected.
+==Under the Hood==
+A [[ref:libraries/wel/reference/wel_menu_chart|WEL_MENU]] is used for the menu's in this sample. The feature show_track is used to display the menu at the cursor position and a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] is used to display the notification when a menu selection has occurred.
+This sample contains the following classes:
+* MAIN_WINDOW
+* MENUS_DEMO
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/windows-sample.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/windows-sample.wiki
new file mode 100644
index 00000000..8a9304cc
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/windows-sample.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Wel Sample: Windows]]
+[[Property:link_title|Windows Sample]]
+[[Property:weight|10]]
+[[Image:windows|windows]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\windows\''.
+* Choose ''windows.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the program, a window will appear with a custom ON_OFF_CONTROL control displayed. Clicking on this control will cause its state to change. If you select one of the options from the "Windows" menu, that type of window will be displayed.
+==Under the Hood==
+
+The ON_OFF_CONTROL inherits [[ref:libraries/wel/reference/wel_control_window_chart|WEL_CONTROL_WINDOW]] and demonstrates how to build your controls. The classes MODAL and MODELESS inherit [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] and [[ref:libraries/wel/reference/wel_modeless_dialog_chart|WEL_MODELESS_DIALOG]] respectively.
+
+This sample contains the following classes:
+* APPLICATION_IDS
+* MAIN_WINDOW
+* MODAL
+* MODELESS
+* ON_OFF_CONTROL
+* WINDOWS_DEMO
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/xcell.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/xcell.wiki
new file mode 100644
index 00000000..63ed491b
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/xcell.wiki
@@ -0,0 +1,35 @@
+[[Property:title|Xcell]]
+[[Property:weight|11]]
+[[Image:xcell|xcell]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\xcell\''.
+* Choose ''xcell.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+After launching the program, a window will be displayed. Selecting "New" from the "Game" menu or pressing F2, will cause a new game to start and the window should take a similar appearance to the above illustration. Selecting "How to play..." from the "Help" menu will display the instructions for playing the game.
+==Under the Hood==
+
+This sample contains the following classes:
+* APP_CONSTANTS
+* CARD
+* COLUMN
+* GAME
+* GAME_CONSTANTS
+* GAME_MANAGER
+* MAIN_WINDOW
+* SELECT_GAME_NUMBER_DIALOG
+* SELECT_NUMBER_OF_CARDS_DIALOG
+* XCELL_DEMO
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki
new file mode 100644
index 00000000..6da9b80a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki
@@ -0,0 +1,34 @@
+[[Property:title|XY Co-ordinates]]
+[[Property:weight|12]]
+[[Image:xy|xy]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\xy\''.
+* Choose ''xy.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. If you click the left mouse button in the client area of the window, the coordinates of the click (Relative to the top left of the client area), will be displayed. Clicking the [[ref:/libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] marked "Clear" will clear the client area of the window.
+==Under the Hood==
+
+A [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] is used to display output in the client area of the window during the execution of on_left_button_down which has been redefined in MAIN_WINDOW.
+
+This sample contains the following classes:
+* XY_DEMO
+* MAIN_WINDOW
+
+
+{{seealso| '''See Also'''
+[[Tutorial Step 3|tutorial_step3]]
+[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]]
+}}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/index.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/index.wiki
new file mode 100644
index 00000000..078274f8
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Tutorial]]
+[[Property:link_title|WEL Tutorial]]
+[[Property:weight|2]]
+WEL is shipped with a tutorial among its sample programs. This tutorial shows you how to develop a simple WEL application and contains eight different samples listed below:
+* [[Tutorial Step 1|Step1]] - A Basic WEL Application.
+* [[Tutorial Step 2|Step2]] - Responding to an event.
+* [[Tutorial Step 3|Step3]] - Displaying output on a WEL_CLIENT_DC.
+* [[Tutorial Step 4|Step4]] - A very basic drawing program.
+* [[Tutorial Step 5|Step5]] - Using a WEL_MODAL_DIALOG.
+* [[Tutorial Step 6|Step6]] - Re-drawing a window by redefining on_paint.
+* [[Tutorial Step 7|Step7]] - Adding menus.
+* [[Tutorial Step 8|Step8]] - Using a WEL_OPEN_FILE_DIALOG and a WEL_SAVE_FILE_DIALOG.
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki
new file mode 100644
index 00000000..e6579e2f
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki
@@ -0,0 +1,35 @@
+[[Property:title|Tutorial Step 1]]
+[[Property:weight|0]]
+This sample shows you how to set up your first [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] consisting of a single [[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . This is one of the simplest WEL applications you can write, and the output is shown below:
+ [[Image:step1|step1]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step1\''.
+* Choose ''tutorial_step1.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+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. }}
+
+==Under the Hood==
+
+Although this system does nothing except create and display a [[ref:/libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , it shows how to set up your first [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] .
+
+This sample only contains one class, TUTORIAL_STEP1 which inherits [[ref:/libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] and redefines main_window
+
+{{seealso| '''See Also'''
+[[Inheriting WEL_APPLICATION|Inheriting WEL application]]
+[[Redefining main_window|Redefining main_window]] }}
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-2.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-2.wiki
new file mode 100644
index 00000000..3097558a
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-2.wiki
@@ -0,0 +1,38 @@
+[[Property:title|Tutorial Step 2]]
+[[Property:weight|1]]
+This sample shows you how to respond to an event occurring within your application. It also demonstrates the use of a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] control and a redefinition of closeable from [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] .
+ [[Image:step2|step2]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step2\''.
+* Choose ''tutorial_step2.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. If you click the left mouse button in the client area of the window, a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] will appear, notifying you of your click.
+
+==Under the Hood==
+
+This system is a demonstration of how to connect an event to one of the common message hooks available within WEL. See [[WEL Common Concepts|Common message hooks]] for more information. In this example, on_left_button_down has been redefined from [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] to display a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] containing notification of the event occurring.
+
+If you look at closeable from MAIN_WINDOW, you will see that it has been redefined to display a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] and the result from this message box is used to generate the return value of closeable. If this Result is True, the window will be closed.
+This sample contains the following classes:
+* TUTORIAL_STEP2
+* MAIN_WINDOW
+
+
+{{seealso| '''See Also'''
+[[WEL Common Concepts|Common message hooks]]
+}}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-3.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-3.wiki
new file mode 100644
index 00000000..6de11a16
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-3.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Tutorial Step 3]]
+[[Property:weight|2]]
+This sample demonstrates the use of a [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] to display output in the MAIN_WINDOW. The output is shown below:
+ [[Image:step3|step3]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step3\''.
+* Choose ''tutorial_step3.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed . If you click the left mouse button in the client area of the window, the coordinates of the click (Relative to the top left of the client area), will be displayed. Clicking the right mouse button in the client area will clear the window.
+==Under the Hood==
+
+This system is a demonstration of how to gain access to the client area of a window using a [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] . The creation procedure of the DC takes a WEL_WINDOW as an argument, and in this sample, we pass the MAIN_WINDOW. Using this DC, it is a simple step to output the position of the mouse which is provided as arguments to on_left_button_down.
+
+on_right_button_down has also been redefined to call invalidate which clears the client area of the window.
+This sample contains the following classes:
+* TUTORIAL_STEP3
+* MAIN_WINDOW
+
+
+{{seealso| '''See Also'''
+[[Common message hooks|Common message hooks]]
+}}
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-4.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-4.wiki
new file mode 100644
index 00000000..be077563
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-4.wiki
@@ -0,0 +1,30 @@
+[[Property:title|Tutorial Step 4]]
+[[Property:weight|3]]
+This sample builds on the knowledge learned in the previous tutorials ( [[Tutorial Step 1|1]] , [[Tutorial Step 2|2]] and [[Tutorial Step 3|3]] ) and again demonstrates the use of a [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] .
+ [[Image:step4|step4]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step4\''.
+* Choose ''tutorial_step4.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client area of the window. Pressing the right mouse button within the window will clear the client area of the window.
+==Under the Hood==
+
+This system is an improvement over tutorial [[Tutorial Step 3|step3]] and only uses WEL techniques demonstrated in previous [[Tutorial|tutorials]] to allow you to draw on the client DC of the window.
+
+This sample contains the following classes:
+* TUTORIAL_STEP4
+* MAIN_WINDOW
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-5.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-5.wiki
new file mode 100644
index 00000000..b9797b07
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-5.wiki
@@ -0,0 +1,34 @@
+[[Property:title|Tutorial Step 5]]
+[[Property:weight|4]]
+The sample builds on tutorial [[Tutorial Step 4|step 4]] and also demonstrates the use of a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] . The output is shown below:
+ [[Image:step5|step5]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step5\''.
+* Choose ''tutorial_step5.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. If you press the right mouse button, a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] will pop up which allows you to enter the thickness of the line that is drawn.
+
+==Under the Hood==
+
+This system builds on tutorial [[Tutorial Step 4|step 4]] by adding a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] . The class LINE_THICKNESS_DIALOG inherits [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] and uses a WEL_SINGLE_LINE_EDIT to input the desired line width.
+This sample contains the following classes:
+* TUTORIAL_STEP5
+* MAIN_WINDOW
+* LINE_THICKNESS_DIALOG
+* APPLICATION_IDS
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-6.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-6.wiki
new file mode 100644
index 00000000..a1c82c8c
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-6.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Tutorial Step 6]]
+[[Property:weight|5]]
+This sample builds on tutorial [[Tutorial Step 5|step 5]] by preventing the loss of the drawing when Windows re-draws the client area of the [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . The output is shown below:
+ [[Image:step6|step6]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step6\''.
+* Choose ''tutorial_step6.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. If you press the right mouse button, a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] will pop up which allows you to enter the thickness of the line that is drawn. If you re-size the window, then the drawing will be re-drawn.
+
+==Under the Hood==
+
+This system uses a redefined on_paint to re-draw the contents of the window. A LINKED_LIST of LINES is used to store all the lines that have been drawn and during on_paint, this list is traversed in order to re-draw each line.
+This sample contains the following classes:
+* TUTORIAL_STEP6
+* MAIN_WINDOW
+* LINE_THICKNESS_DIALOG_CHART
+* APPLICATION_IDS
+* POINT
+* LINE
+
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-7.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-7.wiki
new file mode 100644
index 00000000..4ab4e382
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-7.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Tutorial Step 7]]
+[[Property:weight|6]]
+This sample builds on tutorial [[Tutorial Step 6|step 6]] , and also demonstrates the use of a [[ref:libraries/wel/reference/wel_menu_chart|WEL_MENU]] . The output is shown below:
+ [[Image:step7|step7]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step7\''.
+* Choose ''tutorial_step7.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. Selecting "Line_thickness" from the "Line" menu, will bring up a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] which allows you to change the thickness of the line that is drawn. If you select "Exit" from the "File" menu, you will be prompted if you wish to exit the application. Selecting "New" from the "File" menu will clear the window. The other menu options on the "File" menu do nothing in this example.
+
+==Under the Hood==
+
+During the creation of MAIN_WINDOW, the menu is assigned to the window and on_menu_command is redefined to allow processing of the menu selections.
+
+This sample contains the following classes:
+* TUTORIAL_STEP7
+* MAIN_WINDOW
+* LINE_THICKNESS_DIALOG_CHART
+* APPLICATION_IDS
+* POINT
+* LINE
+
+
+
+
+
diff --git a/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki
new file mode 100644
index 00000000..8ca8c075
--- /dev/null
+++ b/documentation/current/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki
@@ -0,0 +1,39 @@
+[[Property:title|Tutorial Step 8]]
+[[Property:weight|7]]
+This sample builds on tutorial [[Tutorial Step 7|step 7]] , and also demonstrates the use of a [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] and a [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] . The output is shown below:
+ [[Image:step8|step8]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step8\''.
+* Choose ''tutorial_step8.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. Selecting "Line_thickness" from the "Line" menu, will display a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] which allows you to change the thickness of the line that is drawn. If you select "Exit" from the "File" menu, you will be prompted if you wish to exit the application. Selecting "New" from the "File" menu will clear the window. Selecting "Save" from the "File" menu will display a [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] which allows you to specify the filename and location of the picture you have drawn. Selecting "Open" from the "File" menu will display a [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] which allows you to specify a previously saved drawing to open.
+
+==Under the Hood==
+The [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] and the [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] are both activated from the redefinition of on_menu_command. A new class, LINES is now used to store the lines drawn by the user and this inherits [[ref:/libraries/base/reference/storable_chart|STORABLE]] which allows it to be easily stored and retrieved.
+This sample contains the following classes:
+* TUTORIAL_STEP6
+* MAIN_WINDOW
+* LINE_THICKNESS_DIALOG_CHART
+* APPLICATION_IDS
+* POINT
+* LINES
+* LINE
+
+{{seealso| '''See Also'''
+[[ref:/libraries/wel/reference/wel_save_file_dialog_chart|Save file dialog]]
+[[ref:/libraries/wel/reference/wel_open_file_dialog_chart|Open file dialog]] }}
+
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki
new file mode 100644
index 00000000..39ed9239
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki
@@ -0,0 +1,101 @@
+[[Property:title|EiffelBase Sample: Calculator]]
+[[Property:weight|0]]
+This sample consists of a command line reverse Polish notation (RPN) calculator.
+
+{{note| '''Note:''' A RPN calculator works slightly differently from standard calculators. It consists of a stack of numbers. Operations are applied to the two numbers on top of the stack. The result is then put on top of the stack so that it can be used in the next operation. This sample refers to the top of the stack as ''Accumulator''.
+==Compiling==
+
+To compile the example:
+# Launch EiffelStudio.
+# Click '''Add project'''
+# Browse to ''$ISE_EIFFEL\examples\base\calculator\''
+# Choose ''calculator.ecf''
+# Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+# Click '''Open'''.
+
+==Running==
+
+After you launch the sample, the following text appears in a console:
+
+*********************************
+Calculator in reverse Polish form
+*********************************
+
+Allowable operations are:
+ '/': Divide top two numbers on the stack.
+ '0': Empty the stack.
+ 'a': Enter operand onto stack.
+ '?': Help.
+ '*': Multiply top two numbers on the stack.
+ '+': Add top two numbers on the stack
+ 'q': Quit.
+ '-': Subtract top two numbers on the stack.
+Enter a number, followed by :
+
+
+Enter the first number to be put onto the stack, for example 3.
+
+{{note| '''Note:''' Failing to enter a number at this stage will cause the sample to stop. This sample was designed to showcase the use of EiffelBase data structures and is not protected against unexpected entries. }}
+
+You may then add another number on the stack by entering the character a:
+
+*********************************
+Calculator in reverse Polish form
+*********************************
+Allowable operations are:
+ '/': Divide top two numbers on the stack.
+ '0': Empty the stack.
+ 'a': Enter operand onto stack.
+ '?': Help.
+ '*': Multiply top two numbers on the stack.
+ '+': Add top two numbers on the stack
+ 'q': Quit.
+ '-': Subtract top two numbers on the stack.
+Enter a number, followed by : 3
+
+Accumulator = 3
+
+Next operation? a
+Enter a number, followed by :
+
+
+Enter a second number, for example 2. You can then apply any operation to the two operands such as minus:
+
+...
+Next operation? a
+Enter a number, followed by : 2
+
+Accumulator = 2
+
+Next operation? -
+
+Accumulator = 1
+
+Next operation?
+
+
+You may use the operation 0 to clear the stack at any time. You may use q to quit the program.
+
+{{tip| '''Tip:''' You can use the command ? to display the list of available operations. }}
+
+==Under the Hood==
+
+This sample shows how to leverage EiffelBase data structures in a simple Eiffel system. The root class CALCULATOR first instantiates all ''state'' objects, each corresponding to one possible operation. The state classes all inherit from STATE. They are:
+* PLUS: Add stack's two top numbers.
+* MINUS: Substract stack's two top numbers.
+* MULTIPLY: Multiply stack's two top numbers.
+* DIVIDE: Divide stack's two top numbers.
+* EMPTY: Empty stack.
+* HELP: Prints available commands.
+* QUESTION: Get number from user.
+* QUIT: Close application.
+Each of these classes implement the feature do_one_state from STATE which performs the operation associated with the state. The initial state is QUESTION which asks for the initial number to put in the ''accumulator''. Following states depend on the user input.
+Every descendant of STATE implement the feature operation which performs the corresponding stack transformation.
+
+See the reference for the class interfaces.
+}}
+
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki
new file mode 100644
index 00000000..a4b5969f
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki
@@ -0,0 +1,14 @@
+[[Property:title|EiffelBase, Abstract Container Structures: The Taxonomy]]
+[[Property:weight|0]]
+A container data structure (or container in the sequel) is an object which serves to store and access collections of objects, called the '''items''' of the container. All classes describing containers are descendants of the deferred class [[ref:libraries/base/reference/container_chart|CONTAINER]] .
+
+A container can be studied from three viewpoints: access, storage and traversal.
+* The '''access''' criterion affects how the clients of a container can access its items. For example, in a stack or queue, only one item is accessible at any given time, and clients do not choose that item; in contrast, clients of an array or hash table must provide an index, or more generally a key, to access an item.
+* The '''storage''' criterion affects how the items are put together. For example some containers are finite, others potentially infinite; among finite structures, some are bounded, others unbounded.
+* The '''traversal''' criterion affects how, if in any way, the items of a container can be traversed. A traversal is a mechanism which makes it possible to examine each item of a container once, in a clearly specified order. For example some containers can be traversed sequentially, in one direction or two; tree structures lend themselves to preorder, postorder and breadth-first traversals.
+
+For each of these criteria the Base library offers a single-inheritance hierarchy of deferred classes. The top of the access hierarchy is class [[ref:libraries/base/reference/collection_chart|COLLECTION]] ; the top of the storage hierarchy is class [[ref:/libraries/base/reference/box_chart|BOX]] ; the top of the traversal hierarchy is class [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] . These three classes are heirs of the most general class [[ref:libraries/base/reference/container_chart|CONTAINER]] .
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki
new file mode 100644
index 00000000..36201b8f
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki
@@ -0,0 +1,351 @@
+[[Property:title|EiffelBase Data Structures, Lists]]
+[[Property:weight|1]]
+Many applications need sequential structures, also called linear structures, in particular lists and circular chains. Apart from three classes describing individual list cells, all the classes involved are descendants of class [[ref:/libraries/base/reference/linear_chart|LINEAR]] , one of the deferred classes describing general traversal properties and introduced in the chapter that described the general data structure taxonomy. More precisely, all but one of the classes of interest for the present discussion are descendants, direct or indirect, from a class called [[ref:/libraries/base/reference/chain_chart|CHAIN]] which describes general sequential structures possessing a cursor as well as insertion properties. The exception is class [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] , which describes infinite structures; all the others describe finite structures.
+[[ref:/libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] , which describes a more general notion of sequence. [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] is a descendant of [[ref:/libraries/base/reference/linear_chart|LINEAR]] . There are two main categories of sequential structures: some, called circular chains, are cyclic; others, called lists, are not. Another distinction exists between dynamic structures, which may be extended at will, and fixed ones, which have a bounded capacity.
+In all of the structures under review you may insert two or more occurrences of a given item in such a way that the occurrences are distinguishable. In other words, the structures are bags rather than just sets, although it is possible to use them to implement sets.
+
+=Higher Level Traversal Classes=
+
+The list and chain classes are characterized, for their traversal properties, as being linear and, more precisely, bilinear. In the traversal hierarchy, the relevant deferred classes are [[ref:/libraries/base/reference/linear_chart|LINEAR]] and [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , introduced in the [[EiffelBase, Abstract Container Structures: The Taxonomy|discussion]] of the general taxonomy.
+
+==Linear structures==
+
+[[ref:/libraries/base/reference/linear_chart|LINEAR]] describes sequential structures that may be traversed one way. It introduces in particular the following features, illustrated on the figure below:
+* after, a boolean-valued query which determines whether you have moved past the last position (a more precise specification is given below).
+* off, a boolean-valued query which is false if and only if there is no item at the current position; for [[ref:/libraries/base/reference/linear_chart|LINEAR]] this is the same as:
+is_empty and not after
+
+* item, a query which returns the item at the current position - provided of course there is one, as expressed by the precondition:
+not off
+
+* start, a command to move to the first position if any (if is_empty is true the command has no effect).
+* forth, a command to advance by one position; the precondition is not after.
+* finish, a command to move to the last position; the precondition is:
+not is_empty
+
+ [[Image:linear|fig.1: Linear Structure]]
+There is also a procedure search with one argument, which determines whether the value of that argument appears in the structure at or after the current position, and if not makes after become true. This procedure is internally used by the default implementation of the has function (the general membership test) for linear structures. Like has for all containers, search uses object or reference equality depending on the value set for object_comparison.
+
+An invariant property of [[ref:/libraries/base/reference/linear_chart|LINEAR]] structures is that the current position may go off one step past the last item if any, but no further. The precondition of forth - not after - helps ensure this. The first item (if any) being at position 1, the maximum allowable position is count + 1, where count is the number of items.
+
+==Bilinear structures==
+
+[[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] describes linear structures which may be traversed both ways. It inherits from [[ref:/libraries/base/reference/linear_chart|LINEAR]] and extends it with two new features which ensure complete symmetry between the two directions of movement:
+* before, a boolean-valued query which determines whether you have moved to the left of the first position (a more precise specification is given below).
+* back, a command to move backward by one position; the precondition is not before.
+
+For bilinear structures the position can range between 0 (not just 1) and count + 1. Query off is accordingly redefined so as to yield the value of after or before.
+ [[Image:bilinear|fig.2: Bilinear Structure]]
+==Invariant properties for after, before and off==
+
+The redefinition of off illustrates a general methodological advice about invariants: be careful about not over-constraining the invariant by including properties that may be made more general in descendants. It might have been tempting to include in [[ref:/libraries/base/reference/linear_chart|LINEAR]] an invariant clause of the form
+off = is_empty or after
+
+This property, however, would be too constraining. More precisely, it is always true that the right-hand side implies the left-hand-side: if a linear structure is either empty or after, then it is off. But the converse is not true, since certain kinds of linear structure, for example bilinear ones, may be off but neither empty nor after.
+The actual invariant for class [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] is obtained in three stages. In class [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] the feature off is deferred and a basic property of that feature is expressed by the invariant clause
+empty_constraint:is_empty implies off
+
+In [[ref:/libraries/base/reference/linear_chart|LINEAR]] , feature off is effected through an implementation which returns the value of the expression is_empty or after. The class adds an invariant clause which, however, says less than the implementation to leave some room for variation:
+after_constraint:after implies off
+
+Finally [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , an heir of [[ref:/libraries/base/reference/linear_chart|LINEAR]] , redefines off to return the value of the expression
+before or after
+
+and adds the invariant clause
+before_constraint: before implies off
+
+The new implementation of off
+after or before
+
+would not guarantee the invariant clause inherited from [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] were it not for another clause introduced in [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] :
+empty_property: is_empty implies (after or before )
+
+which indicates that an empty bilinear structure must always be after or before but not both, however, as stated by the last new clause, the reason for which is discussed in detail below:
+not_both: not(after and before)
+
+The flat-short form of [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] shows the complete reconstructed invariant:
+
+not_both: not (after and before)
+empty_property: is_empty implies (after or before)
+before_constraint: before implies off
+after_constraint: after implies off
+empty_constraint: is_empty implies off
+
+==Iteration patterns==
+
+For a more general form of this scheme, applicable to circular chains as well as other linear structures, replace off by exhausted. With the features shown above, a typical iteration mechanism on a non-empty linear structure 'lin' is of the form:
+
+from
+ lin.start
+ some_optional_initializing_operation (lin)
+until
+ lin.off
+loop
+ lin.some_action (lin.item)
+ lin.forth
+end
+
+The value of lin . off is always true for an empty structure, so in this case the loop will, correctly, execute only its initialization actions if present.
+This is a very common pattern, which you will find in the library classes themselves (for example has is implemented in this way) and many application clients. The iterator classes corresponding to linear structures ([[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ) turn this pattern and several related ones into actual reusable routines.
+For bilinear structures there is another traversal mechanism going backward rather than forward; it is the same as above except that finish replaces start and back replaces finish. The exit condition remains off since before, like after, implies off.
+
+==A precise view of after and before==
+
+Getting the specification of after and before right, so that it will handle all cases properly, requires some care.
+For every one of the structures under discussion there is a notion of current position, which we may call the cursor position even though for the moment the cursor is a virtual notion only. (Actual cursor objects will come later when we combine [[ref:/libraries/base/reference/linear_chart|LINEAR]] , [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] and other classes from the traversal hierarchy with [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] and other classes from the collection hierarchy.) The informal definition is that after is true if and only if the cursor - in this informal sense of a fictitious marker signaling the current position - is one position after the last item, if any, and that before is true if and only if the cursor is one position before the first item. When the cursor is on any of the items, after and before are false; after holds when the cursor is to the right of the last item, and before when it is to the left of the first item. This leaves open the question of what conventions to take for an empty structure. If iteration schemes of the above type are to work, then after must be true for an empty structure. For a bilinear structure, however, we should have total symmetry between the two pairs of features
+* start, forth, after.
+* finish, back, before.
+
+So for an empty list both before and after should be true. This scheme was used in early version of the Base libraries. It has some disadvantages, however; in particular it is not compatible with the simple, symmetric properties:
+after = (index = count + 1)
+before = (index = 0)
+
+which express elementary definitions for after and before in terms of index, the current position, and count, the number of items (items being numbered from 1 to count). For an empty structure count is zero, so if we want after and before to be both true in this case we have to sacrifice one of the above properties, since the first would imply index to 1 and the second to 0. But again symmetry reigns supreme: we should either keep both properties or renounce both. The solution was to renounce both and replace them by slightly more complicated ones:
+after = (is_empty or (index = count + 1))
+before = (is_empty or (index = 0))
+
+When a structure is created, some initializations will have to be made; the default initializations will usually lead to a value of 0 rather than 1 for index, although this dissymetry is not apparent in the assertions. Although acceptable, this solution leads to small but unpleasant complications, in particular frequent conditional instructions of the form
+if after and not is_empty then...
+
+The solution finally retained for the Base libraries uses a different technique, which has turned out to be preferable. The idea is to replace the conceptual picture by one in which there are always two fictitious sentinel items. The two sentinel items are only present conceptually. They are of course not taken into account for the computation of count and, although it is possible to conceive of an implementation which would actually reserve space for them (for example in an array representation), none of the implementations used in Base for the classes of this documentation and other descendants of [[ref:/libraries/base/reference/linear_chart|LINEAR]] do. The only purpose of the sentinels is to provide two valid theoretical cursor positions, which exist regardless of the number of actual (non-sentinel) items in the structure.
+The sentinel items always appear at positions 0 and count + 1; this property is true even if the structure is empty of items, in which case count is zero. As a result, the following properties are part of the invariant:
+0 <= index
+index <= count + 1
+before = (index = 0)
+after = (index = count + 1)
+not (after and before)
+
+The last property given indicates that a structure can never be both after and before, since even in an empty structure the two sentinels are still present, with the cursor on one of them. For an empty structure, index will be zero by convention, so that before will be true and after false. But this property is not reflected in any of the invariant clauses.
+
+==Some lessons==
+
+This discussion has illustrated some of the important patterns of reasoning that are frequently involved in serious object-oriented design. Among the lessons are four ideas which you may find useful in many different cases. First, consistency is once again the central principle. Throughout the design of a class library we must constantly ask ourselves:
+* How do I make my next design decision compatible with the previous ones?
+* How do I take my next design decision so that it will be easy - or at least possible - to make future ones compatible with it?
+
+Another frequent concern, partly a consequence of consistency, is symmetry. To mathematicians and physicists, symmetry considerations are often important in guiding the search for a solution to a problem; if the problem exhibits a certain symmetry, a candidate solution will be rejected if it does not satisfy that symmetry. Such was the situation here: since the structure's specification is symmetric with respect to the two possible directions of traversal, so too should the feature design be.
+The third lesson is also well-known in mathematics and physics: the usefulness of looking at limit cases. To check that a design is sound it is often useful to examine what becomes of it when it is applied to extreme situations - in particular, as was done in this example, empty structures.
+Finally, the only way to make delicate design decisions is to express the issues clearly through assertions, most notably invariants. To analyze the properties under discussion, and weigh the various alternatives, we need the precision of mathematical logic. Once again note that without assertions it would be impossible to build a good library; we would have no way to know precisely what we are talking about.
+
+=Sequences And Chains=
+
+Still deferred, classes [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] and[[ref:/libraries/base/reference/chain_chart|CHAIN]] provide the basis for all list and chain classes, as well as for many trees and for dispensers.
+SEQUENCE is constructed with the full extent of the technique described in the discussion of the taxonomy: using multiple inheritance to combine one class each from the access, traversal and storage hierarchy. [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] indeed has three parents:
+* [[ref:/libraries/base/reference/active_chart|ACTIVE]] gives the access properties. A sequence is an active structure with a notion of current item. Remember that active structures are a special case of bags.
+* [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , as studied above, indicates that a sequence may be traversed both ways.
+* FINITE, from the storage hierarchy, indicates that the class describes finite sequences. (A class [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] is also present, as described below.)
+
+To the features of [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] principally adds features for adding, changing and removing items. A few procedures in particular serve to insert items at the end:
+* s .put ( v ) adds v at the end of a sequence s .
+* extend and force, at the [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] level, do the same as put.
+* s .append ( s1 ) adds to the end of s the items of s1 (another sequence), preserving their s1 order.
+
+Other procedures work on the current position:
+* s . remove removes the item at current position.
+* s .replace ( v ) replaces by v the item at current position.
+
+SEQUENCE, however, does not provide a procedure to insert an item at the current position, since not all implementations of sequences support this possibility; you will find it in descendants of [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] seen below.
+Yet another group of features are based on the first occurrence of a certain item, or on all occurrences:
+* s .prune ( v ) removes the first occurrence of v in s , if any.
+* s .prune_all ( v ) removes all occurrences of v .
+
+These procedures have various abstract preconditions: s .extendible for additions, s .writable for replacements, s . prunable for removals. Properties extendible and prunable characterize general categories of container structures rather than individual instances; for example extendible is always true for the 'dynamic' structures seen below. In contrast, writable depends on the current status of each instance. In general writable will be true if there is an item at the current position.
+
+==Chains==
+
+Chains are sequences with a few more properties: items may be accessed through their indices, and it is possible to define cursor objects attached to individual items.
+Class [[ref:/libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] . It gets its access properties from [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] (which adds the notion of cursor to the features of [[ref:/libraries/base/reference/active_chart|ACTIVE]] , already present in [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] ) and is also an heir of [[ref:/libraries/base/reference/indexable_chart|INDEXABLE]] . This ancestry implies in particular the presence of the following features:
+* cursor, from [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which makes it possible to keep a reference to an item of the structure.
+* i_th and put_i_th from [[ref:/libraries/base/reference/table_chart|TABLE]] , via [[ref:/libraries/base/reference/indexable_chart|INDEXABLE]] , which make it possible to access and replace the value of an item given by its integer index.
+
+These features were called item and put in [[ref:/libraries/base/reference/table_chart|TABLE]] , but are renamed here to remove the conflict with homonymous features from [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] .
+Procedure put for chains is the version obtained from [[ref:/libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which has the same effect as replace - replacing the value of the item at cursor position. The put procedure from [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] is renamed sequence_ put. This feature is not exported by [[ref:/libraries/base/reference/chain_chart|CHAIN]] , however, since its effect (adding an item at the end) may be obtained through the simpler name extend.
+
+==Dynamic chains==
+
+By default, chains can only be extended at the end, through extend and sequence_put. Of particular interest are those chains where clients can insert and remove items at any position. Such chains are said to be dynamic, and described by [[ref:/libraries/base/reference/chain_chart|CHAIN]] 's heir [[ref:/libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] . The new features are predictable:
+* Procedure put_front adds an item before the first. (As noted, the procedures to add an item after the last are already available in chains.)
+* Procedures put_left and put_right add an item at the left and right of the cursor position.
+* Procedures remove_left and remove_right remove an item at the left and right or the cursor position.
+* Procedures merge_left and merge_right are similar to put_left and put_right but insert another dynamic chain rather than a single item. As the word 'merge' suggests, the merged structure, passed as argument, does not survive the process; it is emptied of its items. To preserve it, perform a clone or copy before the merge operation.
+
+The class also provides implementations of prune, prune_all and wipe_out from [[ref:libraries/base/reference/collection_chart]] . To make these implementations useful, it defines queries extendible and prunable so that they return the value true.
+
+=Lists And Circular Structures=
+
+A chain is a finite sequential structure. This property means that items are arranged in a linear order and may be traversed from the first to the last. To do this you may use a loop of the form shown above, based on procedures start and forth.
+This property leaves room for several variants. In particular chains may be straight or circular.
+* A straight chain, which from now on will be called a list, has a beginning and an end.
+* A circular chain, as represented by class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] and its descendants, has a much more flexible notion of first item. It is organized so that every item has a successor.
+
+This representation is conceptual only; in fact the implementations of circular chains found in the Base libraries are based on lists, implemented in one of the ways described below (in particular linked and arrayed).
+The major originality of circular chains is that unless the structure is empty procedure forth is always applicable: it will cycle past the last item, coming back to the
+first. The symmetric property applies to back. The cyclic nature of forth and back for circular chains is expressed precisely by the assertions. The version of forth for class [[ref:/libraries/base/reference/chain_chart|CHAIN]] , which comes from [[ref:/libraries/base/reference/linear_chart|LINEAR]] , has precondition
+not after
+
+Similarly, the precondition for back is
+not before
+
+For lists, after becomes true when the cursor moves past the last item. For circular chains, however, after and before are never true except for an empty structure; this is expressed by the invariant clauses of class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] :
+not before
+
+For a non-empty circular chain, then, you can circle forever around the items, using forth or back.
+
+==Choosing the first item==
+
+For a list, the first and last items are fixed, and correspond to specific places in the physical representation.
+A circular chain also needs a notion of first item, if only to enable a client to initiate a traversal through procedure start. Similarly, there is a last item - the one just before the first in a cyclic traversal. (If the chain has just one item, it is both first and last.)
+For circular chains, however, there is no reason why the first item should always remain the same. One of the benefits that clients may expect from the use of a circular
+structure is the ability to choose any item as the logical first. Class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] offers for that purpose the procedure set_start which designates the current cursor position as the first in the circular chain. Subsequent calls to start will move the cursor to this position; calls to finish will move the cursor to the cyclically preceding position. With most implementations, there will then be two notions of first position: the logical first, which clients may freely choose through calls to set_start; and the physical first, which results from the implementation. In a representation using an array with indices from 1 to capacity, for example, the physical first is position 1, and the logical first may be any index in the permitted range. In a linked representation, there will be a cell first element corresponding to the physical first, but the logical first is any cell in the chain.
+In such cases the circular chain classes have features called standard_first, standard_last, standard_start and so on, which are not exported (so that you will not see them in the flat-short forms) but serve to implement visible features such as first, last and forth. For example a possible implementation of forth for circular chains is
+forth is
+ -- Move cursor to next item, cyclically.
+ do
+ standard_forth
+ if standard_after then
+ standard_start
+ end
+ if isfirst then
+ exhausted := True
+ end
+ end
+
+==Traversing a list or circular chain==
+
+The properties of forth for circular chains imply that a traversal loop written as
+from
+ lin.start
+until
+ lin.off
+loop
+ ...
+ lin.forth
+end
+
+would not work if lin is a non-empty circular structure: off would never become true, so that the loop would forever cycle over the structure's items. The same would apply to a loop using finish and back instead of start and forth. This behavior is the natural result of the semantics defined for off , forth and back for circular structures. But it prevents us from using these features to perform a single traversal which will visit every item once.
+Using exhausted in lieu of off solves this problem. In class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] , exhausted is an attribute which is set to false by start and finish, and is set to true by forth when advancing from the last item to the first and by back when backing up from the first item to the last. So you should write the loop as
+from
+ lin.start
+ some_optional_initializing_operation (lin)
+until
+ lin.exhausted
+loop
+ ...
+ lin.some_action (lin.item)
+ lin.forth
+end
+
+This form is applicable to all linear structures, circular or not, since exhausted is introduced in class [[ref:/libraries/base/reference/linear_chart|LINEAR]] as a function which returns the same value as off .Its redefinition into an attribute, modified by start, finish, forth and back, does not occur until class [[ref:/libraries/base/reference/circular_chart|CIRCULAR]] .
+Because exhausted is more general than off , the iteration scheme just given (and its equivalent going backwards) is preferable to the earlier one using off , especially if there is any chance that the iteration might one day be applied to a lin structure that is circular. Classes of the Iteration library, in particular [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , rely on this scheme for iterating over linear structures.
+
+==Dynamic structures==
+
+For both lists and circular chains, the most flexible variants, said to be dynamic, allow insertions and deletions at any position.
+The corresponding classes are descendants of [[ref:/libraries/base/reference/dynamic_list_chart|DYNAMIC_LIST]] and [[ref:/libraries/base/reference/dynamic_circular_chart|DYNAMIC_CIRCULAR]] , themselves heirs of [[ref:/libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] studied above.
+
+
+==Infinite sequences==
+
+Class [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCES]] , built by inheritance from [[ref:/libraries/base/reference/countable_chart|COUNTABLE]] , [[ref:/libraries/base/reference/linear_chart|LINEAR]] and [[ref:/libraries/base/reference/active_chart|ACTIVE]] , is similar to [[ref:/libraries/base/reference/sequence_chart|SEQUENCE]] but describes infinite rather than finite sequences.
+
+=Implementations=
+
+We have by now seen the concepts underlying the linear structures of the Base libraries, especially lists and circular chains. Let us look at the techniques used to implement them.
+
+==Linked and arrayed implementations==
+
+Most of the implementations belong to one of four general categories, better described
+as two categories with two subcategories each:
+* Linked implementations, which may be one-way or two-way.
+* Arrayed implementations, which may be resizable or fixed.
+
+A linked implementation uses linked cells, each containing an item and a reference to the next cell. One-way structures are described by classes whose names begin with LINKED_, for example [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . Two-way structures use cells which, in addition to the reference to the next cell, also include a reference to the previous one. Their names begin with TWO_WAY_.
+An arrayed implementation uses an array to represent a linear structure. If the array is resizable, the corresponding class name begins with ARRAYED_, for example
+[[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] ; if not, the prefix is FIXED_.
+
+==Linked structures==
+
+A linked structure requires two classes: one, such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , describes the list proper; the other, such as [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , describes the individual list cells. The figure should help understand the difference; it describes a linked list, but the implementation of linked circular chains is similar.
+ [[Image:linked-list|fig.3: Linked list and linked cells]]
+The instance of type [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] shown at the top contains general information about the list, such as the number of items (count) and a reference to the first element (first). Because lists are active structures with a notion of current position, there is also a reference active to the cell at the current position. An entity declared as
+my_list: LINKED_LIST [SOME_TYPE]
+
+will have as its run-time value (if not void) a reference to such an object, which is really a list header. The actual list content is given by the [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] instances, each of which contains a value of type SOME_TYPE and a reference to the next item, called right.
+Clearly, a header of type [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] [ SOME_TYPE ] will be associated with cells of type [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] [ SOME_TYPE ] .
+Features such as active and first are used only for the implementation; they are not exported, and so you will not find them in the flat-short specifications, although the figures show them to illustrate the representation technique.
+A similar implementation is used for two-way-linked structures such as two-way lists and two-way circular chains.
+ [[Image:two-way-list|fig.4: Two way linked list]]
+==Linked cells==
+
+The classes describing list cells are descendants of a deferred class called [[ref:/libraries/base/reference/cell_chart|CELL]] , whose features are:
+* item, the contents of the cell.
+* put ( v : like item ) , which replaces the contents of the cell by a new value.
+
+Class [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] is an effective descendant of [[ref:/libraries/base/reference/cell_chart|CELL]] , used for one-way linked structures. It introduces features right, a reference to another cell to which the current
+cell will be linked. Two-way linked structures use [[ref:/libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] , an heir of [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] which to the above features adds left, a reference to the preceding cell in the structure.
+
+{{warning| '''Caution''': Do not confuse the item feature of [[ref:/libraries/base/reference/cell_chart|CELL]] and its descendants, such as [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , with the item feature of the classes describing linear structures, such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . For a linked list, item returns the item at cursor position. }}
+
+It may be implemented as
+item: G is
+ -- Current item
+ do
+ Result := active.item
+ end
+
+using the item feature of [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , applied to active.
+
+==One-way and two-way linked chains==
+
+If you look at the interfaces of one-way and two-way linked structures, you will notice that they are almost identical. This is because it is possible to implement features such as back for one-way structures such as described by [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:/libraries/base/reference/linked_circular_chart|LINKED_CIRCULAR]] . A simple implementation of back stores away a reference to the current active item, executes start, and then performs forth until the item to the right of the cursor position is the previous active.
+Although correct, such an implementation is of course rather inefficient since it requires a traversal of the list. In terms of algorithmic complexity, it is in O (count), meaning that its execution time is on the average proportional to the number of items in the structure. In contrast, forth is O (1), that is to say, takes an execution time bounded by a constant.
+
+{{warning| '''Caution''': As a consequence, you should not use one-way linked structures if you need to execute more than occasional back operations (and other operations requiring access to previous items, such as remove_left). }}
+
+Two-way linked structures, such as those described by [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:/libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] , treat the two directions symmetrically, so that back will be just as efficient as forth. Hence the following important advice: If you need to traverse a linked structure both ways, not just left to right, use the TWO_WAY_ classes, not the LINKED_ versions. The TWO_WAY_ structures will take up more space, since they use [[ref:/libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] rather than [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] cells, but for most applications this space penalty is justified by the considerable gains in time that will result if right-to-left operations are frequently needed.
+
+==Arrayed chains==
+
+Arrayed structures as described by [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] and [[ref:/libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] use arrays for their implementations. A list or circular chain of count items may be stored in positions 1 to count of an array of capacity items, where capacity >= count.
+An instance of [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] , as the name suggests, has a fixed number of items. In particular:
+* Query extendible has value false for [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] : you may replace existing items, but not add any, even at the end. A [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] is created with a certain number of items and retains that number.
+* As a result, [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] joins the deferred feature count of [[ref:/libraries/base/reference/list_chart|LIST]] with the feature count of ARRAY, which satisfies the property count = capacity.
+* Query prunable has value false too: it is not possible to remove an item from a fixed list.
+
+In contrast, [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] has almost the same interface as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] . In particular, it is possible to add items at the end using procedure extend; if the call causes the list to grow beyond the current array's capacity, it will trigger a resizing. This is achieved by using the procedure force of class ARRAY to implement extend. [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] even has the insertion procedures (put_front, put_left, put_right) and removal procedures (prune, remove, remove_left, remove_right) that apply to arbitrary positions and appear in the linked implementations. These procedures, however, are rather inefficient, since they usually require moving a whole set of array items, an O (count) operation. (Procedure extend does not suffer from this problem, since it is easy to add an item to the end of an array, especially if there is still room so that no resizing is necessary.)
+
+{{warning| '''Caution''': The situation of these features in [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] is similar to the situation of back in classes describing one-way linked structures: it is convenient to include them because they may be needed once in a while and an implementation exists; but using them more than occasionally may result in serious inefficiencies. If you do need to perform arbitrary insertions and removal, use linked structures, not arrayed ones. }}
+
+Arrayed structures, however, use up less space than linked representations. So they are appropriate for chains on which, except possibly for insertions at the end, few insertion and removal operations or none at all are expected after creation. [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] offers few advantages over [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] . [[ref:/libraries/base/reference/fixed_list_chart|FIXED_LIST]] may be useful, however, for cases in which the fixed number of items is part of the specification, and any attempt to add more items must be treated as an error. For circular chains only one variant is available, [[ref:/libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] , although writing a FIXED_ version would be a simple exercise.
+
+==Multi-arrayed lists==
+
+For lists one more variant is available, combining some of the advantages of arrayed and linked implementations: [[ref:/libraries/base/reference/multi_array_list_chart|MULTI_ARRAY_LIST]] . With this implementation a list is
+divided into a number of blocks. Each block is an array, but the successive arrays are linked.
+
+=Sorted Linear Structures=
+
+The class [[ref:/libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , an heir of [[ref:/libraries/base/reference/bilinear_chart|BILINEAR]] , is declared as
+deferred class
+ COMPARABLE_STRUCT [G -> COMPARABLE]
+ inherit
+ BILINEAR
+ feature
+ ...
+
+As indicated by the constrained generic parameter it describes bilinear structures whose items may be compared by a total order relation.
+
+{{warning| '''Caution''': Note that the class name, chosen for brevity's sake, is slightly misleading: it is not the structures that are comparable but their items. }}
+
+COMPARABLE_STRUCT introduces the features min and max, giving access to the minimum and maximum elements of a structure; these are always present for a finite
+structure with a total order relation. [[ref:/libraries/base/reference/sorted_struct_chart|SORTED_STRUCT]] , an heir of [[ref:/libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , describes structures that can be sorted; it introduces the query sorted and the command sort.
+The deferred class [[ref:/libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] describes lists whose items are kept ordered in a way that is compatible with a partial order relation defined on them. The class is declared as
+deferred class
+ PART_SORTED_LIST [G -> COMPARABLE]...
+
+An implementation based on two-way linked lists is available through the effective heir [[ref:/libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] .
+The deferred class [[ref:/libraries/base/reference/sorted_list_chart|SORTED_LIST]] , which inherits from [[ref:/libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] , assumes that the order relation on G is a total order. As a result, the class is able to introduce features min, max and median. Here too a two-way linked list implementation is available, through the effective class [[ref:/libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] .
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki
new file mode 100644
index 00000000..8490a545
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki
@@ -0,0 +1,35 @@
+[[Property:title|EiffelBase, Dispensers]]
+[[Property:weight|2]]
+A dispenser is called that way because of the image of a vending machine (a dispenser) of a rather primitive nature, in which there is only one button. If you press the button and the dispenser is not empty, you get one of its items in the exit tray at the bottom, but you do not choose that item: the machine does. There is also an input slot at the top, into which you may deposit new items; but you have no control over the order in which successive button press operations will retrieve these items.
+
+The deferred class [[ref:/libraries/base/reference/dispenser_chart|DISPENSER]] provides the facilities which will be shared by all specialized classes. In fact, the interface of all dispenser classes is nearly identical, with the exception of a few extra possibilities offered by priority queues. Many kinds of dispenser are possible, each defined by the relation that the machine defines between the order in which items are inserted and the order in which they arereturned. The Base libraries support three important categories - stacks, queues, and priority queues:
+* A stack is a dispenser with a last-in, first-out (LIFO) internal policy: items come out in the reverse order of their insertion. Each button press returns the last deposited item.
+* A queue is a dispenser with a first-in, first-out (FIFO) internal policy: items come out in the order of their insertion. Each button press returns the oldest item deposited and not yet removed.
+* In a priority queue, items have an associated notion of order; the element that comes out at any given time is the largest of those which are in the dispenser.
+
+==Stacks==
+
+Stacks - dispensers with a LIFO retrieval policy - are a ubiquitous structure in software development. Their most famous application is to parsing (syntactic analysis), but many other types of systems use one or more stacks. Class STACK describes general stacks, without commitment to a representation. This is a deferred class which may not be directly instantiated. The fundamental operations are put (add an element at end of queue), item (retrieve the oldest element, non-destructively), remove (remove the oldest element), is_empty (test for empty queue).
+Three effective heirs are provided:
+* [[ref:/libraries/base/reference/linked_stack_chart|LINKED_STACK]] : stacks implemented as linked lists, with no limit on the number of items (count).
+* [[ref:/libraries/base/reference/bounded_stack_chart|BOUNDED_STACK]] : stacks implemented as arrays. For such stacks, the maximum number of items (capacity) is set at creation time.
+* [[ref:/libraries/base/reference/arrayed_stack_chart|ARRAYED_STACK]] : also implemented as arrays, but in this case there is no limit on the number of items; the interface is the same as [[ref:/libraries/base/reference/linked_stack_chart|LINKED_STACK]] except for the creation procedure. If the number of elements exceeds the initially allocated capacity, the array will simply be resized.
+
+==Queues==
+
+Class [[ref:/libraries/base/reference/queue_chart|QUEUE]] describes general queues, without commitment to a representation. This is a deferred class which may not be directly instantiated. Three non-deferred heirs are also provided, distinguished by the same properties as their stack counterparts:
+* [[ref:/libraries/base/reference/linked_queue_chart|LINKED_QUEUE]]
+* [[ref:/libraries/base/reference/bounded_queue_chart|BOUNDED_QUEUE]]
+* [[ref:/libraries/base/reference/arrayed_queue_chart|ARRAYED_QUEUE]]
+
+==Priority Queues==
+
+In a priority queue, each item has an associated priority value, and there is an order relation on these values. The item returned by item or removed by remove is the element with the highest priority.The most general class is [[ref:/libraries/base/reference/priority_queue_chart|PRIORITY_QUEUE]] , which is deferred. Two effective variants are provided:
+* [[ref:/libraries/base/reference/linked_priority_queue_chart|LINKED_PRIORITY_QUEUE]] , a linked list implementation.
+* [[ref:/libraries/base/reference/heap_priority_queue_chart|HEAP_PRIORITY_QUEUE]] which is more efficient and is to be preferred in most cases. A heap is organized like a binary tree, although physically stored in an array; elements with a high priority percolate towards the root.
+
+Because it must be possible to compare priorities, the type of the items must conform to [[ref:/libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . Constrained genericity ensures this; all the priority queue classes have a formal generic parameter constrained by [[ref:/libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] .
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki
new file mode 100644
index 00000000..09e34670
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki
@@ -0,0 +1,572 @@
+[[Property:title|EiffelBase, Iteration]]
+[[Property:weight|6]]
+The classes of the Iteration cluster encapsulate control structures representing common traversal operations.
+
+=Iterators and Agents=
+
+The recent introduction of the agents mechanism in Eiffel offers an attractive alternative to the Iterator cluster of EiffelBase.
+
+=The Notion of iterator=
+
+Let us first explore the role of iterators in the architecture of a system.
+
+==Iterating over data structures==
+
+Client software that uses data structures of a certain type, for example lists or trees, often needs to traverse a data structure of that type in a predetermined order so as to apply a certain action to all the items of the structure, or to all items that satisfy a certain criterion. Such a systematic traversal is called an iteration.
+Cases of iteration can be found in almost any system. Here are a few typical examples:
+* A text processing system may maintain a list of paragraphs. In response to a user command, such as a request to resize the column width, the system will iterate over the entire list so as to update all paragraphs.
+* A business system may maintain a list of customers. If the company decides that a special promotion will target all customers satisfying a certain criterion (for example all customers that have bought at least one product over the past six months), the system will iterate over the list, generating a mailing for every list item that satisfies the criterion.
+* An interactive development environment for a programming language may maintain a syntax tree. In response to a program change, the system will traverse the tree to determine what nodes are affected by the change and update them.
+
+These examples illustrate the general properties of iteration. An iteration involves a data structure of a known general type and a particular ordering of the structure's items. For some structures, more than one ordering will be available; for example a tree iteration may use preorder, postorder or breadth-first (as defined below). The iteration involves an operation, say item_action, to be applied to the selected items. It may also involve a boolean-valued query, say item_test, applicable to candidate items. Finally, it involves a certain policy, usually based on item_test, as to which items should be subjected to item_action. Typical example policies are:
+* Apply item_action to all the items in the structure. (In this case item_test is not relevant).
+* Apply item_action to all items that satisfy item_test.
+* Apply item_action to all items up to the first one that satisfies item_test.
+
+The Iteration library provides many more, covering in particular all the standard control structures.
+
+==Iterations and control structures==
+
+You can perform iterations without any special iteration classes. For example if customers is declared as
+customers: LIST [CUSTOMER]
+
+then a class SPECIAL_PROMOTION of a text processing system may include in one of its routines a loop of the form
+
+ from
+ customers.start
+ until
+ customers.exhausted
+ loop
+ if recent_purchases.has (customers.item>) then
+ target_list.put (customers.item>)
+ end
+ customers.forth
+ end
+
+Such schemes are quite common. But it is precisely because they occur frequently that it is useful to rely on library classes to handle them. One of the principal tasks of object-oriented software development is to identify recurring patterns and build reusable classes that encapsulate them, so that future developers will be able to rely on ready-made solutions.
+The classes of the Iteration library address this need. Using them offers two benefits:
+* You avoid writing loops, in which the definition of sub-components such as exit conditions, variants and invariants is often delicate or error-prone.
+* You can more easily adapt the resulting features in descendant classes. The rest of this chapter shows how to obtain these benefits.
+
+=Simple Examples=
+
+To get a first grasp of how one can work with the Iteration library, let us look at a typical iteration class and a typical iteration client.
+
+==An example iterator routine==
+
+Here, given with its full implementation, is a typical Iteration library routine: the procedure until_do from [[ref:libraries/base/reference/linear_iterator_chart]] , the class defining iteration mechanisms on linear (sequential) structures.
+
+until_do is
+ -- Apply action to every item of target,
+ -- up to but excluding first one satisfying test.
+ -- (Apply to full list if no item satisfies test.)
+ require
+ traversable_exists: target /= Void
+ do
+ from
+ target.start
+ invariant
+ ''invariant_value''
+ until
+ target.exhausted or else test
+ loop
+ action
+ target.forth
+ end
+ ensure
+ achieved: target.exhausted or else test
+ invariant_satisfied: ''invariant_value''
+ end
+
+The precise form of the procedure in the class relies on a call to another procedure, until_continue, and on inherited assertions. Here everything has been unfolded for illustration purposes.
+This procedure will traverse the linear structure identified by target and apply the procedure calledaction on every item up to but excluding the first one satisfying test.
+The class similarly offers do_all, do_while, do_for, do_if and other procedures representing the common control structures. It also includes functions such as exists and forall, corresponding to the usual quantifiers.
+These iteration schemes depend on the procedure action, defining the action to be applied to successive elements, and on the function test, defining the boolean query to be applied to these elements. These features are declared in class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] (the highest-level deferred class of the Iteration library); here is test:
+
+test: BOOLEAN is
+ -- Test to be applied to item at current position in
+ -- target (default: value of item_test on item)
+ require
+ traversable_exists: target /= Void
+ not_off: not target.off
+ do
+ Result := item_test (target.item>)
+ ensure
+ not_off: not target.off
+ end
+
+This indicates that the value of the boolean function test will be obtained by applying item_test to the item at the current position in the target structure. In [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , function item_test always return ; descendant classes will redefine it so as to describe the desired test. Similarly, action is declared in class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] as a call to item_action. Descendants will redefine item_action, which as initially declared in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] is a procedure with a null body.
+Going through item_action and item_test provides an extra degree of flexibility. Normally the action and test performed at each step apply to target . item>, so that it suffices to redefine the item_features. This is the case with all examples studied in this chapter. In a more general setting, however, you might need to redefine action and test themselves.
+
+==An example use of iteration==
+
+Here now is an example illustrating the use of these mechanisms. The result will enable us to resize all the paragraphs of a text up to the first one that has been modified - as we might need to do, in a text processing system, to process an interactive user request. Assume a class TEXT that describes lists of paragraphs with certain additional features. The example will also assume a class PARAGRAPH with a procedure resize, and a boolean-valued attribute modified which indicates whether a paragraph has been modified. Class TEXT inherits from [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] and so is a descendant of [[ref:/libraries/base/reference/linear_chart|LINEAR]] :
+
+class
+ TEXT
+
+inherit
+ LINKED_LIST [PARAGRAPH]
+ ...
+feature
+ ...
+end
+
+In a class TEXT_PROCESSOR, you can use an iteration procedure to write a very simple procedure resize_ paragraphs that will resize all paragraphs up to but excluding the first one that has been modified:
+
+class
+ TEXT_PROCESSOR
+
+inherit
+ LINEAR_ITERATOR [PARAGRAPH]
+ redefine
+ item_action, item_test
+ end
+
+feature
+
+ resize_paragraphs (t: TEXT) is
+ -- Resize all the paragraphs of t up to but excluding
+ -- the first one that has been modified.
+ do
+ set (t)
+ until_do
+ end
+
+feature {NONE}
+
+ item_test (p PARAGRAPH): BOOLEAN is
+ -- Has p been modified?
+ do
+ Result := p.modified
+ end
+
+ item_action (p: PARAGRAPH) is
+ -- Resize p.
+ do
+ p.resize
+ end
+ ...
+end
+
+Thanks to the iteration mechanism, the procedure resize_paragraphs simply needs two procedure calls:
+* To set its argument t as the iteration target, it uses procedure set. (This procedure is from class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] which passes it on to all iterator classes.)
+* Then it simply calls until_do as defined above.
+
+Procedure item_action is redefined to describe the operation to be performed on each successive element. Function item_test is redefined to describe the exit test.
+As presented so far, the mechanism seems to limit every descendant of an iteration class to just one form of iteration. As shown later in this chapter, it is in fact easy to generalize the technique to allow a class to use an arbitrary number of iteration schemes.
+What is interesting here is that the redefinitions of item_test and item_action take care of all the details. There is no need to write any loop or other control structure. We are at the very heart of the object-oriented method, enjoying the ability to encapsulate useful and common software schemes so that client developers will only need to fill in what is specific to their application.
+
+=Using the Iteration Library=
+
+Let us now explore the classes of the Iteration library and the different ways of using them.
+
+==Overview of the classes==
+
+There are only four Iteration classes, whose simple inheritance structure appeared at the beginning of this chapter.
+* [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , a deferred class which describes the most general notion.
+* [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating over linear structures and chains.
+* [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] , a repeated heir of [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating in either direction over a bilinear structure.
+* [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , for iterating over trees.
+
+As you will remember from the [[EiffelBase, Abstract Container Structures: The Taxonomy|presentation]] of the abstract overall taxonomy, the traversal hierarchy describes how data structures can be traversed; its most general class is [[ref:/libraries/base/reference/two_way_list_chart|TRAVERSABLE]] .
+Each one of the iterator classes is paired with a traversal class (or two in one case):
+{|
+|-
+| [[ref:/libraries/base/reference/iterator_chart|ITERATOR]]
+| [[ref:/libraries/base/reference/two_way_list_chart|TRAVERSABLE]]
+|-
+| [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]]
+| [[ref:/libraries/base/reference/linear_chart|LINEAR]]
+|-
+| [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]]
+| [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]]
+|-
+| [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]]
+| [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] , [[ref:/libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]]
+|-
+| [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]]
+| [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE]]
+|}
+
+Each iterator class relies on the corresponding traversal class to provide the features for traversing the corresponding data structures, such as start, forth and exhausted for linear structures.
+Of course the data structure class used in connection with a given iterator class does not need to be the iterator's exact correspondent as given by the above table; it may be any one of its descendants. For example you may use [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] to iterate over data structures described not just by [[ref:/libraries/base/reference/linear_chart|LINEAR]] but also by such descendants as [[ref:/libraries/base/reference/list_chart|LIST]] , [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , or even [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] if you do not need the backward iteration features (for which you will have to use [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ).
+
+==General iteration facilities==
+
+Class [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] defines the features that apply to all forms of iterator.
+An iterator will always apply to a certain target structure. The target is introduced in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] by the feature target: [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] [G]
+Both the iterator classes and the traversal classes are generic, with a formal generic parameter G. The actual generic parameters will be matched through the choice of iteration target: for a generic derivation of the form SOME_ITERATOR [ ACTUAL_TYPE] the target can only be of type SOME_TRAVERSABLE [ ACTUAL_TYPE] for the same ACTUAL_TYPE, where SOME_TRAVERSABLE is the traversal class matching SOME_ITERATOR according to the preceding table ([[ref:/libraries/base/reference/linear_chart|LINEAR]] for [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] and so on), or one of its proper descendants.
+Each of the proper descendants of [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] redefines the type of target to the matching proper descendant of [[ref:/libraries/base/reference/traversable_chart|TRAVERSABLE]] , to cover more specific variants of the iteration target, For example in [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] the feature is redefined to be of type [[ref:/libraries/base/reference/linear_chart|LINEAR]] . [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] also introduces the procedure for selecting a target:
+
+ set (s: like target) is
+ -- Make s the new target of iterations.
+ require
+ s /= Void
+ do
+ target := s
+ ensure
+ target = s
+ target /= Void
+ end
+
+Next [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] introduces the routines describing the elementary action and test that will be applied to items of the iteration targets:
+
+ action is
+ -- Action to be applied to item at current position in
+ -- target.
+ -- (default: item_action on item at current position.)
+ -- Note: for iterators to work properly, redefined
+ -- versions of this feature should not change the
+ -- traversable structure.
+ require
+ traversable_exists: target /= Void
+ not_off: not target.off
+ invariant_satisfied: invariant_value
+ do
+ item_action (target.item>)
+ ensure
+ not_off: not target.off
+ invariant_satisfied: invariant_value
+ end
+
+ test: BOOLEAN is
+ -- Test to be applied to item at current position in
+ -- target (default: value of item_test on item)
+ require
+ traversable_exists: target /= Void
+ not_off: not target.off
+ do
+ Result := item_test (target.item>)
+ ensure
+ not target.off
+ end
+
+These routines rely on two others, item_action and item_test, which both take an argument of type G, the formal generic parameter. The reason, already noted above, is that in a vast majority of cases the iterated action and test solely depend, at each step of the traversal, on the item (of type G) at the current position. To define an iteration process, then, it suffices to redefine item_action and item_test in a descendant of the appropriate iteration class. Only in complex cases will it be necessary to redefine action and test themselves.
+If you encounter such a case, note the caveat about action changing the target's structure. Understandably enough, an iterator that attempts to change the data structure while traversing it may engage in strange behavior. No such risk exists if you only redefine item_action, which may change the contents of items but not the structure itself.
+Another feature introduced in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] is the query invariant_value, describing invariant properties that must be ensured at the beginning of any iteration and preserved by every iteration step. As declared in [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] this query always returns true, but proper descendants can redefine it to describe more interesting invariant properties.
+Finally, [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] introduces in deferred form the general iteration routines applicable to all iteration variants. They include two queries corresponding to the quantifiers of first-order predicate calculus:
+* for_all will return true if all items of the target structure satisfy test.
+* exists will return true if at least one item satisfies test.
+
+The other routines are commands which will traverse the target structure and apply action to items selected through test:
+* do_all applies action to all items.
+* do_if, to those items which satisfy test.
+* until_do, to all items up to but excluding the first one that satisfies test.
+* do_until, to all items up to and including the first one that satisfies test.
+* while_do and do_while, to all items up to the first one that does not satisfy test. (This can also be achieved with until_do or do_until by choosing the opposite test.)
+
+All these features, and most of the other iteration features introduced in proper descendants of [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] and described next, have no argument. Information about the target of iteration comes from feature target, set by procedure set; information about what needs to be done for each item of the target structure comes from item_action and item_test.
+
+==Linear and chain iteration==
+
+[[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , an effective class, refines the iteration mechanisms for cases in which the target is a linear structure, such as a list in any implementation or a circular chain.
+The class effects all the deferred features inherited from [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , taking advantage of the linear traversal mechanisms present in the corresponding traversal class, [[ref:/libraries/base/reference/linear_chart|LINEAR]] . Here for example is the effecting of do_if:
+
+ do_if is
+ -- Apply action to every item of target satisfying
+ -- test.
+ do
+ from
+ target.start
+ invariant
+ invariant_value
+ until
+ target.exhausted
+ loop
+ if test then
+ action
+ end
+ forth
+ end
+ end
+
+This routine text relies on features start, forth and exhausted which, together with off, have for convenience been carried over to [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] from their counterparts in [[ref:/libraries/base/reference/linear_chart|LINEAR]] , with feature declarations such as
+
+ off: BOOLEAN is
+ -- Is position of target off?
+ require
+ traversable_exists: target /= Void
+ do
+ Result := target.off
+ end
+
+and similarly for the others.
+In addition to effecting the general iteration features from [[ref:/libraries/base/reference/iterator_chart|ITERATOR]] , class [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] introduces iteration features that apply to the specific case of linear structures:
+* search ( b :BOOLEAN) moves the iteration to the first position satisfying test if b is true, or not satisfying test if b is false. This use of a boolean argument to switch between two opposite semantics is not part of the recommended style, and you will find few if any other examples in the Base libraries. Here, however, it was deemed preferable to the alternative, which would have involved four separate procedures (if together with search we consider continue_search discussed next).
+* With a linear structure we can implement an iteration corresponding to the 'for' loop of traditional programming languages, defined by three integers: the starting position, the number of items to be traversed, and the step between consecutive items. This is provided by procedure do_for ( starting , number , step :INTEGER).
+* Since with a linear target the iterator can advance the cursor step by step, the basic iteration operations are complemented by variants which pick up from the position reached by the last call: continue_until, until_continue, continue_while, while_continue, continue_search, continue_for.
+
+==Two-way iteration==
+
+Class [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] has all the features of [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , to which it adds features for iterating backward as well as forward.
+The class introduces commands finish and back, applying the corresponding operations to the two-way target. It also has a backward variant for every iteration feature. The name of each such variant is the name of the forward feature followed by ''_back'': do_all_back, until_do_back and so on.
+An alternative design would have kept just one set of features and added two features: a command reverse to reverse the direction of future iteration operations, and a query backward to find out the direction currently in force.
+Contrary to what one might at first imagine, class [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] is extremely short and simple; its Feature clause only contains the declarations of two features, finish and back.
+The trick is to use repeated inheritance. [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] inherits twice from [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] ; the first inheritance branch yields the forward iteration features, the second yields those for backward iteration. There is no need for any explicit declaration or redeclaration of iteration features. Here is the entire class text that yields this result:
+
+class
+ TWO_WAY_CHAIN_ITERATOR [G]
+
+inherit
+ LINEAR_ITERATOR [G]
+ redefine
+ target
+ select
+ start,
+ forth,
+ do_all,
+ until_do,
+ do_until,
+ do_if,
+ do_for,
+ search,
+ forall,
+ exists,
+ until_continue,
+ continue_until,
+ continue_for,
+ continue_search
+ end
+
+ LINEAR_ITERATOR [G]
+ rename
+ start as finish,
+ forth as back,
+ do_all as do_all_back,
+ until_do as until_do_back,
+ do_until as do_until_back,
+ do_if as do_if_back,
+ do_for as do_for_back,
+ search as search_back,
+ forall as forall_back,
+ exists as exists_back,
+ until_continue as until_continue_back,
+ continue_until as continue_until_back,
+ continue_for as continue_for_back,
+ continue_search as continue_search_back
+ redefine
+ target
+ end
+
+feature -- Status report
+
+ target: BI_LINEAR [G]
+ -- The structure to which iteration features will
+ -- apply
+
+feature -- Cursor movement
+
+ finish is
+ -- Move cursor of target to last position.
+ do
+ target.finish
+ end
+
+ back is
+ -- Move cursor of target backward one position.
+ do
+ target.back
+ end
+end
+
+
+This class provides a good example of the economy of expression that the full inheritance mechanism affords through the combination of renaming, redefinition, repeated inheritance rules and selection, without sacrificing clarity and maintainability.
+
+==Tree iteration==
+
+Tree iterations, provided by class [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , work on trees of the cursor tree form; only with this form of tree are traversal operations possible. Three forms of iteration are provided: preorder, postorder and breadth-first. They correspond to the three traversal policies described in the discussion of trees. Here too it would seem that a rather lengthy class is needed, but repeated inheritance works wonders.
+[[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] simply inherits three times from [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , renaming the features appropriately in each case:
+* pre_do_all, pre_until and so on.
+* post_do_all, post_until and so on.
+* breadth_do_all, breadth_until and so on.
+
+All it needs to do then is to redefine the type of target to be [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] [ G ] , and to redefine six features: the three renamed start ( pre_start etc.) and the three forth ( pre_ forth and so on). These seven redefinitions give us a full-fledged battery of tree iteration mechanisms.
+
+=Building and Using Iterators=
+
+To conclude this discussion, let us now put together the various mechanisms studied so far, to see how authors of client software can use the Iteration library to perform possibly complex iterations on various data structures without ever writing a single loop or test. The basic ideas were sketched above but now we have all the elements for the full view.
+An application class may use one of the iteration classes in either of two ways: as a descendant (single or repeated) or as a client. The descendant technique is extremely simple but less versatile.
+
+==The single descendant technique==
+
+Assume an application class PROCESSOR that is a proper descendant of one of the effective iteration classes studied in this chapter. Then a routine of PROCESSOR, say iterate, may iterate a certain action over a data structure, subject to a certain test. First, class PROCESSOR must specify the action by redefining item_action and item_test (or, in the most general case, action and test). Then routine iterate must specify the target data structure through a call of the form set ( t ) where t represents the selected target data structure. The type of t must correspond tothe iteration class selected as ancestor of PROCESSOR: for [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] it must be a descendant of [[ref:/libraries/base/reference/linear_chart|LINEAR]] (such as [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:/libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , LINKED_CIRCULAR or any other list or circular chain classes); for [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] it must be a descendant of [[ref:/libraries/base/reference/linear_chart|BILINEAR]] such as [[ref:/libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] or [[ref:/libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] ; for [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] it must be a descendant of [[ref:/libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] . In all cases the actual generic parameters of the iterator class and ofthe data structure class must be compatible. Then the iteration proper is obtained simply by calling the appropriate procedure, without any qualification or arguments, for example: do_ if
+It is hard to imagine a simpler scheme: no loops, no initialization, no arguments. Feature item_action may need to rely on some variable values. Because it does not take any argument, such values will have to be treated as attributes, with the corresponding set_... procedures to set and change their values. This also applies to the two schemes set next.
+The single descendant technique has one drawback: it provides the iterating class, PROCESSOR, with only one set of iteration particulars. This limitation does not affect the number of targets: you may use as many targets as you wish, as long as they are of compatible types, by calling a routine such as iterate several times, or calling several such routines, each call being preceded by a call to set to define a new target. The limitation also does not affect the iterating scheme: one iteration could use do_if, the next do_all and so on. But it does require the action and test to be the same in all cases.
+The next two techniques will remove this limitation.
+
+==Using repeated inheritance==
+
+One way to obtain several iteration schemes is a simple extension to the single descendant technique. You can use repeated inheritance to provide two or more variants. We have in fact already encountered the technique when studying how to derive [[ref:/libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] and [[ref:/libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] from [[ref:/libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] . The general pattern, applied here to just two iteration schemes but easily generalized to more, is straightforward:
+
+class
+ DUAL_PROCESSOR
+
+inherit
+ LINEAR_ITERATOR [SOME_TYPE]
+ rename
+ item_action as action1,
+ item_test as test1,
+ do_if as do_if1,
+ redefine
+ action1, test1
+ select
+ action1, test1
+ end
+
+ LINEAR_ITERATOR [SOME_TYPE]
+ rename
+ item_action as action2,
+ item_test as test2,
+ do_if as do_if2,
+ redefine
+ action2, test2
+ end
+
+feature
+
+ action1 is
+ -- Action for the first scheme
+ do
+ ...
+ end
+
+ test1: BOOLEAN is
+ -- Test for the first scheme
+ do
+ ...
+ end
+
+ action2 is
+ -- Action for the second scheme
+ do
+ ...
+ end
+
+ test2: BOOLEAN is
+ -- Test for the second scheme
+ do
+ ...
+ end
+
+ iterate1 is
+ -- Execute iteration of first kind.
+ do
+ set (...)
+ do_if1
+ end
+
+ iterate2 is
+ -- Execute iteration of second kind.
+ do
+ set (...)
+ do_if2
+ end
+
+ ...
+end
+
+
+The repeated inheritance machinery takes care of the rest.
+
+==Using explicit iterator objects==
+
+To obtain maximum flexibility, classes that need iteration facilities should be clients rather than descendants of the iteration classes. The resulting scheme is completely dynamic: to perform iterations you use iterator objects as discussed earlier.
+The following example illustrates the technique. Consider a deferred class FIGURE describing the notion of graphical figure, with many effective descendants ( POLYGON, CIRCLE and so on). It is useful to define COMPLEX_FIGURE, describing figures that are recursively composed of sub-figures. This is a remarkable example of multiple inheritance:
+
+class
+ COMPLEX_FIGURE
+
+inherit
+ FIGURE,
+ LINKED_LIST [FIGURE]
+
+feature
+ ...
+end
+
+
+In the feature clause we want to provide the appropriate effectings for the deferred features of class FIGURE: display, hide, translate and all other basic figure operations.
+We can use loops for that purpose, for example
+
+ display is
+ -- Recursively display all components of the complex
+ -- figure
+ do
+ from
+ start
+ until
+ exhausted
+ loop
+ item.display
+ forth
+ end
+ end
+
+
+Although acceptable and even elegant, this scheme will cause significant duplication: all the FIGURE features - not just display but also hide, rotate, move and others - will have the same structure, with a loop. We can use iterators to avoid this duplication. The repeated inheritance technique would work, but given the large number of FIGURE features the amount of repeated inheritance that would be needed seems unwieldy. It is also not very desirable to have to change the inheritance structure of the system just to add a new feature to FIGURE. The more dynamic approach using iterator objects seems preferable.
+To implement this approach, define a class for iterating on complex figures:
+
+class
+ COMPLEX_FIGURE_ITERATOR
+
+inherit
+ LINEAR_ITERATOR
+ redefine
+ target
+ end
+
+create
+ set
+
+feature
+
+ target: COMPLEX_FIGURE
+
+end
+
+
+Then for each operation to be iterated define a small class. For example:
+
+class
+ FIGURE_DISPLAYER
+
+inherit
+ COMPLEX_FIGURE_ITERATOR
+ redefine
+ item_action
+ end
+
+create
+ set
+
+feature
+
+ item_action (f: FIGURE) is
+ -- Action to be applied to each figure: display
+ -- it.
+ do
+ f.display
+ end
+end
+
+
+Similarly, you may define FIGURE_HIDER, FIGURE_MOVER and others. Then the features of COMPLEX_FIGURE are written almost trivially, without any explicit loops; for example:
+
+ display is
+ -- Recursively display all components of the complex
+ -- figure
+ local
+ disp: FIGURE_DISPLAYER
+ do
+ create disp.set (Current)
+ disp.do_all
+ end
+
+
+and similarly for all the others.
+Note the use of set as creation procedure, which is more convenient than requiring the clients first to create an iterator object and then to call set. This is also safer, since with set as a creation procedure the client cannot forget to initialize the target. (If a class C has a creation clause, the creation instruction create C.)
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-sets.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-sets.wiki
new file mode 100644
index 00000000..4bc85314
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-sets.wiki
@@ -0,0 +1,32 @@
+[[Property:title|EiffelBase, Sets]]
+[[Property:weight|4]]
+Sets are containers where successive occurrences of the same item are not distinguished: inserting the same item twice has the same observable effect as inserting it once.
+
+==Deferred classes==
+
+The most general class describing sets is [[ref:libraries/base/reference/set_chart|SET]] . The usual operations of set theory such as union and intersection have been relegated to [[ref:libraries/base/reference/subset_chart|SUBSET]] , an heir of [[ref:libraries/base/reference/set_chart|SET]] . This enables a class to inherit from [[ref:libraries/base/reference/set_chart|SET]] without having to effect these operations if it satisfies the basic set property but has no convenient implementation of the subset operations.
+
+==Sets without a notion of order==
+
+[[ref:libraries/base/reference/linked_set_chart|LINKED_SET]] provides a basic implementation of [[ref:libraries/base/reference/set_chart|SET]] by linked lists.
+
+==Sets of comparable elements and sorted sets==
+
+The deferred class [[ref:libraries/base/reference/comparable_set_chart|COMPARABLE_SET]] , declared as
+
+ deferred class
+ [[ref:libraries/base/reference/comparable_set_chart|COMPARABLE_SET]] [G -> [[ref:libraries/base/reference/comparable_chart|COMPARABLE]] ]
+
+ inherit
+ [[ref:libraries/base/reference/subset_chart|SUBSET]] [G]
+ [[ref:/libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] [G]
+ ...
+
+
+describes sets whose items may be compared by a total order relation. The class has the features [[ref:libraries/base/reference/comparable_set_chart|min]] and [[ref:libraries/base/reference/comparable_set_chart|max]] .
+Two implementations of [[ref:libraries/base/reference/comparable_set_chart|COMPARABLE_SET]] are provided. One, [[ref:libraries/base/reference/two_way_sorted_set_chart|TWO_WAY_SORTED_SET]] , uses sorted two-way lists. The other, [[ref:libraries/base/reference/binary_search_tree_set_chart|BINARY_SEARCH_TREE_SET]] , uses binary search trees.
+If the items are partially rather than totally ordered, you may use the class [[ref:libraries/base/reference/part_sorted_set_chart|PART_SORTED_SET]] [G -> [[ref:libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] ], which uses a two-way sorted list implementation.
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki
new file mode 100644
index 00000000..88cbf3e3
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki
@@ -0,0 +1,57 @@
+[[Property:title|EiffelBase, Tables]]
+[[Property:weight|5]]
+Hash tables are a convenient mechanism tostore and retrieve objects identified by unique keys.
+==Why use hash tables?==
+The main advantage of hash tables is the efficiency of the basic operations: store ( [[ref:libraries/base/reference/hash_table_chart|put]] ) and retrieve ( [[ref:libraries/base/reference/hash_table_chart|item]] , [[ref:libraries/base/reference/hash_table_chart|remove]] ).
+The idea behind hash tables is to try to emulate the data structure that provides the ultimate in efficiency: the array. On an array a, for some integer i whose value lies within the bounds of a, the basic operations are
+
+a.put (x, i)
+x := a.item (i)
+x := a @ i
+
+The first causes the value of a at index i to be x; the second (and the third, which is simply a syntactical variant) access the value at index i and assign it to x. With the usual computer architectures, these operations are very fast: because arrays items are stored contiguously in memory, a computer will need just one addition (base address plus index) and one memory access to perform a put or item.
+Not only are the operation times small; they are constant (or more precisely bounded by a constant). This is a great advantage over structures such as lists or trees which you must traverse at least in part to retrieve an item, so that access and modification times grow with the number of items. With an array, disregarding the influence of other factors such as memory paging, the time for a put or item is for all practical purposes the same whether the array has five items or five hundred thousand. These properties make arrays excellent data structures for keeping objects. Unfortunately, they are only applicable if the objects satisfy three requirements:
+* '''A1'''. For each object there must be an associated integer, which for the purpose of this discussion we may call the object's index (since it will serve as index for the object in the array.)
+* '''A2'''. No two objects may have the same index.
+* '''A3'''. If we want to avoid wasting huge amount of storage, all the indices must lie in a contiguous or almost contiguous range.
+
+Hash tables may be viewed as a rehabilitation mechanism for objects that do not naturally possess these three properties. If we are unable to find a natural index, we can sometimes devise an artificial one. To do so we must be able to find a key. Each key must uniquely identify the corresponding object; this is the same as property '''A2''', making keys similar to indices. But keys are not necessarily integers (violating property '''A1'''), although it must be possible to associate an integer with each key. The mechanism that maps keys to integers is called the hashing function.
+Thanks to the hashing mechanism we will indeed be able to store suitable objects into arrays, approaching the optimal efficiency of this data structure. The efficiency will not be quite as good, however, for two reasons:
+* We must pay the price of computing the hash function whenever we store or retrieve an object.
+* Different keys may hash into the same integer value, requiring extra processing to find an acceptable index.
+
+With good implementations, however, it is possible to use hash tables with a performance that is not much worse than that of arrays and, most importantly, may be treated as if the time for a put, an item or a remove were constant. This will mean that you can consider operations such as
+h.put (x, k)
+h := a.item (k)
+
+where h is a hash-table and k is a key (for example a string) as conceptually equivalentto the array operations mentioned above.
+The quality of a hashed implementation will depend both on the data structure that will store the objects, and on the choice of hashing function. Class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] attempts to address the first concern; for the second, client developers will be responsible for choosing the proper hashing function, although Base provides a few predefined functions, in particular for class [[ref:/libraries/base/reference/string_8_chart|STRING]] .
+
+==When hash tables are appropriate==
+
+You may keep objects in a hash table if for each one of these objects you can find a key that uniquely identifies it. The objects and their keys may be of many possible kinds:
+* '''H1'''. In a simple example, the objects are integers; each integer serves as its own key. (More precisely we will use its absolute value, since it is convenient to have non-negative keys only.) This case is of more than theoretical interest, since it makes hash tables appropriate for storing a set of integers with widely scattered values, for which simple array storage would be a waste of space (see requirement '''A3''' above).
+* '''H2'''. Frequently, the objects will be composite, that is to say, instances of a developer-defined class, and one of the attributes of that class, of type [[ref:/libraries/base/reference/string_8_chart|STRING]] , can serve as the key. For example if you were writing an Eiffel compiler you would probably need to keep a data structure that includes information about classes of the system. Each class is represented by an object with several fields describing the properties of the class; one of these fields, the class name, corresponding to an attribute of type [[ref:/libraries/base/reference/string_8_chart|STRING]] , will serve as key.
+* '''H3'''. Instead of being the full object (as in case '''H1''') or one of the object's fields (as in case '''H2'''), the key may have to be computed through a function of the generating class, which will take into account several attributes of the class (that is to say, for each object, several fields).
+
+What this practically means is that in all cases you will need, in the generating class of the objects to be stored, a query (attribute or function) that gives the key. The type of the key is highly variable but must in all cases be a descendant of [[ref:/libraries/base/reference/hashable_chart|HASHABLE]] . This is true of both [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] (case '''H1''') and [[ref:/libraries/base/reference/string_8_chart|STRING]] (case '''H2'''). The requirements for being a [[ref:/libraries/base/reference/hashable_chart|HASHABLE]] are not harsh: all you need is a function hash_code that returns a non-negative integer.>
+
+==Using hash tables==
+
+Class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] takes two generic parameters:
+
+class HASH_TABLE [G, H -> HASHABLE] ...
+
+G represents the type of the objects to be stored in the hash table, H the type of their keys.
+When viewed as an implementation of containers, [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] , in a strict sense, represents bags rather than sets: unlike the other classes in this chapter, it allows an object to have two or more distinct occurrences in a single container. But this is only true if we consider a hash table as a repository of objects of type G. In reality each item of the table is identified by a pair of values, one from G and one from H. Because the keys must uniquely identify objects, the hash table viewed as a container of such pairs is indeed a set. The creation procedure make takes an integer argument, as in
+create my_table.make (n)
+
+The value of n indicates how many items the hash table is expected to have to accommodate. This number of items is not a hardwired size, just information passed to the class. In particular:
+* The actual size of the underlying array representation will be higher than n since efficient operation of hash table algorithms require the presence of enough breathing space - unoccupied positions.
+* If the number of items in the table grows beyond the initial allocation, the table will automatically be resized.
+
+It is useful, however, to use a reasonable upon creation: not too large to avoid wasting space, but not too small to avoid frequent applications of resizing, an expensive operation.
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki
new file mode 100644
index 00000000..ed96a7bf
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki
@@ -0,0 +1,117 @@
+[[Property:title|EiffelBase, Trees]]
+[[Property:weight|3]]
+Trees and their immediate generalization, forests, are useful for any system that manipulates hierarchically organized information. The range of applications is broad, from abstract syntax trees in compilers through document structures in text processing systems to company organization charts in business software.
+Trees, in particular binary trees and their variants, also provide convenient implementations of container data structures.
+
+==Basic Terminology==
+
+A tree consists of a set of nodes. Each node may have zero or more children, other nodes of which it is the parent. Each node has at most one parent, although it may have an arbitrary number of children.
+ [[Image:tree|tree]]
+A node with no parent, such as the node marked ''A'' on the figure, is called a root; a node with no children, such as ''E'', ''F'', ''G'', ''H'' and ''I'', is called a leaf. The length of a path from the root to a leaf (that is to say, the number of nodes on the path minus one) is the height of the tree; the average length of all such paths is the average height. On the figure the height is 2 and the average height is 11/6 since of the six paths five have length 2 and one has length 1.
+
+The children of a common node are called siblings. For example ''G'', ''H'' and ''I'' are siblings on the figure. The siblings of a node are usually considered to be ordered; the order corresponds to the direction from left to right on conventional figures such as this one.
+
+The descendants of a node are the node itself and, recursively, the descendants of its children. The ancestors of a node are the node itself and, recursively, the ancestors of its parent. For example the descendants of ''A'' are all the tree's nodes; and the ancestors of ''I'' are ''A'', ''D'' and ''I''.
+
+To obtain a tree rather than a more general kind of graph, there is an extra requirement: in we start from an arbitrary node, go to the parent, to the parent's parent and so on (for as long as there is a parent), we will never find the starting node again. In more precise terms the condition is that the 'parent' relation must not have any cycles. (That relation is in fact a partial function, since every node has zero or one parent.) If we consider infinite as well as finite trees the above condition must be restated to express that if we start from an arbitrary node and repeatedly go to the parent we will eventually hit a root. This discussion, however, will only consider finite trees (those with a finite number of nodes), for which the two statements are equivalent.
+
+The definition given so far properly defines forests rather than trees. ''A'' tree is a forest with at most one root (that is to say, with exactly one root unless it is empty), such as the example on the last figure. The discussion and the library classes will handle trees rather than forest, but this is not a very important difference since by using an obvious device you can treat any forest as a tree: simply add an extra node, and make it the parent of all the forest's roots.
+
+Another important observation is that there is a one-to-one correspondence between trees and nodes. To any node N of a tree T we can associate a tree: take T, remove all nodes that are not descendants of N, and use N as the new root. Conversely, to any tree we can associate a node - its root. This correspondence enables us to treat the two concepts of tree and node as essentially the same.
+
+==Recursive Trees==
+
+The closeness of the notions of tree and node yields an elegant definition of trees in terms of lists. If we look at trees or, equivalently, at tree nodes, we can consider each node as being both:
+* A list: the list of its children.
+* A list cell (similar to a [[ref:libraries/base/reference/linkable_chart|LINKABLE ]] or [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] for one-way and two-way linked lists), paired with the node's siblings.
+
+This yields a simple definition of trees by multiple inheritance from [[ref:libraries/base/reference/list_chart|LIST]] and [[ref:libraries/base/reference/cell_chart|CELL]] .
+
+===Dynamic recursive trees===
+
+An example of dynamic tree structure is provided by class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , an heir of both [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] . There is also [[ref:libraries/base/reference/linked_tree_chart|LINKED_TREE]] , which inherits from [[ref:/libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:/libraries/base/reference/linkable_chart|LINKABLE]] , but [[ref:libraries/base/reference/two_way_tree_chart|TWO_WA Y_TREE]] is generally preferable since children of a node often needs to be traversed both ways; the notion of order is usually less significant here than for lists. Such a form of definition is a particularly effective way of conveying the profoundly recursive nature of trees. The corresponding classes are useful in many different areas such as graphics, text processing and compilation. To create a one-way or two-way linked tree, use
+create my_tree.make (root_value)
+
+This will attach my_tree to a new one-node tree, with root_value at the root node. Here my_tree must be declared of type [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] [MY_TYPE] for some type MY_TYPE, and root_value must be of type MY_TYPE.
+A class with a similar interface but using arrays rather than lists to represent nodes is also available: [[ref:libraries/base/reference/arrayed_tree_chart|ARRAYED_TREE ]] . This class is more efficient in both time and space for trees whose nodes have many children that are accessed randomly, if relatively few child insertions occur after node creation. Here the creation procedure indicates the initial number of children:
+create my_tree.make (max_estimated_children, root_value)
+
+The integer argument max_estimated_children only serves for the initial allocation; the array will be resized if the number of children grows beyond the initial size. As with the previous kinds of tree, the newly created node initially has no children.
+
+===Fixed trees===
+
+[[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] is useful for fully dynamic trees, in which a node may get new children at any time. For some applications, the number of children of a tree, although still arbitrary, is set for each node when the node is created, and will not change after that. Of course, some children may be absent; the corresponding entries will be void references. Class [[ref:libraries/base/reference/fixed_tree_chart|FIXED_TREE]] provides the basic mechanism; as you may have guessed, the implementation associates with each node an array of its children, arrays usually being the right structure when a collection of objects is known not to change size after creation. To create a fixed tree, use
+create my_tree.make (how_many_children, root_value)
+
+The root will have the associated value root value and will have how_many_ children children, all initially void. Unlike the argument max_estimated_children for the creation procedure of [[ref:libraries/base/reference/arrayed_tree_chart|ARRAYED_TREE]] , the value of how_many_children is the final arity of the newly created node; since it set separately for each node on creation, the various nodes of a tree can have different arities, as illustrated on the above figure.
+
+===Properties of recursive trees===
+
+Whether fixed or dynamic, recursive trees fully enjoy their dual origin. This means in particular that each node is viewed as a list of its children, and can apply to this list the features inherited from [[ref:libraries/base/reference/list_chart|LIST]] , appropriately renamed; for example:
+[[ref:libraries/base/reference/dynamic_tree_chart|child_put_left]]
+[[ref:libraries/base/reference/dynamic_tree_chart|child_forth]]
+[[ref:libraries/base/reference/dynamic_tree_chart|child_put]]
+and so on. Feature [[ref:libraries/base/reference/dynamic_tree_chart|count]] , inherited from [[ref:libraries/base/reference/list_chart|LIST]] , indicates the number of children; it is renamed arity to conform to accepted tree terminology. (The word is a substantived form of the 'ary' adjective ending, as in 'ternary', 'quaternary' and so on, which yielded the expression 'n-ary'.)
+
+==Binary Trees==
+
+Binary trees are a special case of fixed trees in which nodes always have two children, although either or both of these children may be void.
+
+===Basic binary trees===
+
+Class [[ref:libraries/base/reference/binary_tree_chart|BINARY_TREE]] describes binary trees.
+
+ [[Image:binary-tree|binary_tree]]
+
+The children are represented by features [[ref:libraries/base/reference/binary_tree_chart|left_child]] and [[ref:libraries/base/reference/binary_tree_chart|right_child]] . Queries [[ref:libraries/base/reference/binary_tree_chart|has_left]] and [[ref:libraries/base/reference/binary_tree_chart|has_right]] indicate whether any of these is non-void; arity is redefined to yield the number of non-void children (0, 1 or 2).
+
+===Binary representations of trees===
+
+For any ordinary tree, there exists a standard representation as a binary tree, which is useful in some applications. The correspondence is one-to-one, so that the original tree may be reconstructed without ambiguity. It actually applies to forests rather than trees and works as follows, ''fr'' being the first root in a forest: the binary tree's root corresponds to ''fr''; its left subtree is obtained recursively from the forest made by the subtrees of ''fr''; and its right subtree is obtained recursively from the original forest deprived of the tree rooted at ''fr''. If you start from a tree rather than a forest the binary tree's root will have no right child.
+Function [[ref:libraries/base/reference/tree_chart|binary_representation]] , in [[ref:libraries/base/reference/tree_chart|TREE]] , creates a binary tree representation (the function's result) obtained from the current tree.
+Procedure [[ref:libraries/base/reference/dynamic_tree_chart|fill_ from_binary]] , in [[ref:libraries/base/reference/dynamic_tree_chart|DYNAMIC_TREE]] , reconstructs a tree from a binary tree representation passed as argument.
+
+===Binary search trees===
+
+Class [[ref:libraries/base/reference/binary_search_tree_chart|BINARY_SEARCH_TREE]] describes binary search trees, an implementation ofbags which is appropriate for comparable items.
+Binary search trees rely for insertion on a policy whereby any item less than the root is inserted (recursively) into the left subtree, and any item greater than the root into the right subtree. So if the insertion order is reasonably random the items will distribute evenly among the various branches, This means that the average height of the tree will be not much more than the optimal: [log2 n] where n is the number of nodes and [x], for any x, is the integer part of x.
+Since search operations will follow the same principle (search left if smaller than the root, and so on), the time to find an item or ascertain that it is not there is proportional to the average height. In normal cases this means about [log2 n] basic operations, rather than n with a linear structure such as a list, and hence much better performance for large n.
+
+==Cursor Trees==
+
+Recursive trees, as described so far, are not active data structures: even though each node has its own cursor to traverse the list of its children, there is no global cursor on the tree as a whole. It is not hard to see that the notion of recursive tree is in fact incompatible with the presence of a global cursor. In situations where you need such a cursor, enabling you to move freely from a node to its children, siblings and parents, you may use class [[ref:libraries/base/reference/cursor_tree_chart]] and its descendants.
+
+===The conceptual model===
+
+With cursor trees the model is different from what we have seen earlier in this chapter: there is a clear distinction between the nodes and the tree itself. The manipulated object is a tree, and the notion of node is merely implicit. In the various operations presented below and illustrated on the following figure, 'up' means towards the root and 'down' towards the leaves. This, of course, is the reverse of the properties of trees of the other kind - those which grow towards the sun and serve to print books about software.
+
+===Operations on cursor trees===
+
+The cursor supported by instances of [[ref:libraries/base/reference/cursor_tree_chart]] has a position referring to a node of the tree, which is then considered to be the active node, or is off the tree. The different off positions are: [[ref:libraries/base/reference/cursor_tree_chart|above]] (above the root), [[ref:libraries/base/reference/cursor_tree_chart|below]] (below a leaf), [[ref:libraries/base/reference/cursor_tree_chart|before]] (before a leftmost sibling), [[ref:libraries/base/reference/cursor_tree_chart|after]] (after a rightmost sibling.) As with linear structures, fictitious sentinel elements are assumed to be present to the left, right, top and bottom.
+Various procedures are available to move the cursor in all directions:
+* [[ref:libraries/base/reference/cursor_tree_chart|down (i)]] moves the cursor down to the i -th child of the active node. If i is equal to 0 the cursor ends up before; if i is equal to the arity of the current parent plus 1, the cursor ends up [[ref:libraries/base/reference/cursor_tree_chart|after]] . Calling [[ref:libraries/base/reference/cursor_tree_chart|down (i)]] when the cursor is on a leaf node results in setting [[ref:libraries/base/reference/cursor_tree_chart|below]] and [[ref:libraries/base/reference/cursor_tree_chart|before]] to true if i is equal to 0, or [[ref:libraries/base/reference/cursor_tree_chart|below]] and [[ref:libraries/base/reference/cursor_tree_chart|after]] to true if is equal to arity+1.
+* [[ref:libraries/base/reference/cursor_tree_chart|forth]] and [[ref:libraries/base/reference/cursor_tree_chart|back]] move the cursor forward and backward between siblings and can cause the cursor to end up [[ref:libraries/base/reference/cursor_tree_chart|after]] or [[ref:libraries/base/reference/cursor_tree_chart|before]] .
+* [[ref:libraries/base/reference/cursor_tree_chart|up]] moves the cursor up one level. The call may be made even when the cursor is [[ref:libraries/base/reference/cursor_tree_chart|after]] or [[ref:libraries/base/reference/cursor_tree_chart|before]] . If the cursor is on the root of the tree or below in an empty tree, the cursor ends up [[ref:libraries/base/reference/cursor_tree_chart|above]] .
+
+You can move the cursor in any one direction ( [[ref:libraries/base/reference/cursor_tree_chart|up]] , [[ref:libraries/base/reference/cursor_tree_chart|down]] , [[ref:libraries/base/reference/cursor_tree_chart|forth]] , [[ref:libraries/base/reference/cursor_tree_chart|back]] ), repeatedly, until it is [[ref:libraries/base/reference/cursor_tree_chart|off]] ( [[ref:libraries/base/reference/cursor_tree_chart|above]] , [[ref:libraries/base/reference/cursor_tree_chart|below,]] [[ref:libraries/base/reference/cursor_tree_chart|after]] , [[ref:libraries/base/reference/cursor_tree_chart|before]] respectively), but once it is [[ref:libraries/base/reference/cursor_tree_chart|off]] , further movement in the same direction is prohibited. For example the precondition of [[ref:/libraries/base/reference/cursor_tree_chart|put_left]] requires [[ref:libraries/base/reference/cursor_tree_chart|before]] to be false, and the precondition of [[ref:/libraries/base/reference/cursor_tree_chart|put_right]] requires [[ref:libraries/base/reference/cursor_tree_chart|after]] to be false.
+It is possible to move down from an [[ref:libraries/base/reference/cursor_tree_chart|above]] position; in an empty tree this brings the cursor [[ref:libraries/base/reference/cursor_tree_chart|below]] . Similarly, it is possible to move up from [[ref:libraries/base/reference/cursor_tree_chart|below]] , left from [[ref:libraries/base/reference/cursor_tree_chart|after]] , right from [[ref:libraries/base/reference/cursor_tree_chart|before]] .
+The sentinel element above the tree's root is considered to be the root of a forest containing just one tree. This view justifies the convention for the result of arity when the cursor is above: 0 if the tree [[ref:libraries/base/reference/cursor_tree_chart|is_empty]] , 1 if it has a root (viewed as the child of the fictitious sentinel element).
+
+===Manipulating the cursor explicitly===
+
+The cursor attached to a cursor tree is not just a conceptual notion but an actual object, of type [[ref:libraries/base/reference/cursor_chart|CURSOR]] . You may use the query cursor to obtain a reference to the current cursor. Procedure [[ref:libraries/base/reference/cursor_tree_chart|go_to]] takes a cursor as argument and brings the tree's cursor to the node identified by the value of that argument.
+
+===Traversals===
+
+A useful notion associated with trees and particularly applicable to cursor trees is that of traversal.
+A traversal is a certain policy for ordering all the nodes in a tree - usually to apply an operation to all these nodes in the resulting order. [[ref:libraries/base/reference/cursor_tree_chart]] and its descendants support three forms of traversal: preorder, postorder and breadth-first. They correspond to the most commonly used traversal policies on trees, illustrated on the figure (where the children of each node are assumed to be ordered from left to right):
+ [[Image:tree|tree]]
+* Preorder is the traversal that visits the root first, then (recursively) traverses each subtree in order. On the figure we will visit node ''A'' first then, recursively, the subtrees rooted at ''B'' (which implies visiting ''E'' and ''F''), ''C'' and ''D''. The resulting order is: ''A B E F C D G H I''.
+* Postorder first traverses (recursively) the subtrees, then visits the root. On the example this gives: '' E F B C G H I D A''.
+* Breadth-first visits the nodes level by level, starting with the root: first the root, then all its children, then all their children and so on. Here the resulting order is: ''A B C D E F G H I''.
+
+For each of the traversals, procedures are available to move the cursor accordingly, for example [[ref:libraries/base/reference/cursor_tree_chart|breadth_start]] and [[ref:libraries/base/reference/cursor_tree_chart|breadth_ forth]] for breadth-first, and similar names for the others.
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki
new file mode 100644
index 00000000..6769db29
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki
@@ -0,0 +1,21 @@
+[[Property:title|EiffelBase Data Structures Overview]]
+[[Property:weight|1]]
+The data structures cluster of EiffelBase includes classes that cover a wide range of data structures classes for you to reuse in your systems. The cluster is divided into a number of subclusters. Each subcluster contains one or more '''deferred''' classes, which provide the general high-level abstractions; other classes in the cluster inherit from the deferred ones.
+
+The highest-level class is [[ref:libraries/base/reference/container_chart| CONTAINER]] , with the following heirs:
+* [[ref:libraries/base/reference/collection_chart|COLLECTION]] , which describes containers through their access properties (defining how to access a container's items, forexample through an index or according to a last-in, first-out policy).
+* [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] , which considers their traversal properties, such as sequential or hierarchical.
+* [[ref:libraries/base/reference/box_chart|BOX]] , which describes their storage properties, such as being bounded or unbounded.
+
+The documentation further discusses:
+* The [[EiffelBase, Abstract Container Structures: The Taxonomy|taxonomy]] of the abstract container structures.
+* The [[EiffelBase Data Structures, Lists|list-based structures hierarchy]] .
+* The [[EiffelBase, Dispensers|dispenser-based structures hierarchy]] .
+* The [[EiffelBase, Trees|tree-based structures hierarchy]] .
+* The [[EiffelBase, Sets|set-based structures hierarchy]] .
+* The [[EiffelBase, Tables|table-based structures hierarchy]] .
+* The [[EiffelBase, Iteration|iteration mechanisms]] .
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki
new file mode 100644
index 00000000..37040cfe
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel.wiki
@@ -0,0 +1,465 @@
+[[Property:title|EiffelBase, The Kernel]]
+[[Property:weight|0]]
+In addition to basic concepts close to the language level, the Kernel covers such common needs as '''input''' and '''output''', '''storage''' and '''retrieval''' of objects on persistent storage, fine control over '''exception handling''' and '''memory management''', and access to '''operating system facilities'''. The kernel can be divided into 5 logical clusters of classes:
+* The first cluster contains the universal class defining facilities accessible to all other classes: [[ref:/libraries/base/reference/any_chart|ANY]] . Every developer-defined class is a descendant of this class.
+* The second cluster includes classes whose facilities are directly related to language concepts:
+** Classes describing the basic types: [[ref:/libraries/base/reference/boolean_chart|BOOLEAN]] , [[ref:/libraries/base/reference/character_8_chart|CHARACTER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/real_32_chart|REAL]] and [[ref:/libraries/base/reference/real_64_chart|DOUBLE]]
+** Arrays: class [[ref:/libraries/base/reference/array_chart|ARRAY]]
+** Tuples: class [[ref:/libraries/base/reference/tuple_chart|TUPLE]]
+** Strings: class [[ref:/libraries/base/reference/string_8_chart|STRING]]
+** Basic facilities: class [[ref:/libraries/base/reference/basic_routines_chart|BASIC_ROUTINES]]
+
+* The third cluster provides input and output facilities:
+** [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] offers basic mechanisms, sufficient for simple input and output.
+** [[ref:/libraries/base/reference/file_chart|FILE]] describes the notion of sequential file, viewed as a sequence of characters and fully integrated in the data structure library.
+** [[ref:/libraries/base/reference/directory_chart|DIRECTORY]] gives properties of directories (files serving as collections of other files).
+
+* The next cluster, through class [[ref:/libraries/base/reference/storable_chart|STORABLE]] , makes it possible to store object structures on persistent storage and retrieve them later. This facility can also be used to transmit object structures through pipes or over a network.
+* The last cluster provides access to internal properties of the compiler and environment, useful for applications that need some fine-tuning of the basic mechanisms:
+** Class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] (complemented by [[ref:/libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] for Unix-type platforms) provides control over the exception handling mechanism, in particular for applications that need to handle different types of exception in different ways.
+** Similarly, classes [[ref:/libraries/base/reference/memory_chart|MEMORY]] and [[ref:/libraries/base/reference/gc_info_chart|GC_INFO]] provide ways to control the garbage collector and tailor it to specific needs.
+** Class ARGUMENTS gives access to the command-line arguments.
+
+
+=Universal Class and its Features=
+
+The Eiffel inheritance mechanism is set up in such a way that every class is a descendant of a Kernel Library class called [[ref:/libraries/base/reference/any_chart|ANY]] . The features of this class provide a number of generally applicable facilities covering such needs as comparison, copying and rudimentary input and output.
+
+==The structure of universal classes==
+
+Every class which has no inheritance clause is understood to have an inheritance clause of the form
+
+inherit
+ ANY
+
+
+As a result, every developer-defined class is a descendant of [[ref:/libraries/base/reference/any_chart|ANY]] . You may introduce your own project specific features in [[ref:/libraries/base/reference/any_chart|ANY]] so that all the classes of your system will be able to use these features.
+
+==Using the universal classes==
+
+If you need to rename or redefine a feature inherited from one of the universal classes, you should include an explicit inheritance clause, as in
+
+class
+ C
+inherit
+ ANY
+ rename
+ out as basic_out
+ redefine
+ print
+ end
+ ...
+feature
+ ...
+end
+
+
+The features of [[ref:/libraries/base/reference/any_chart|ANY]] are usable in both qualified and unqualified form. For example, the argumentless function out, which produces a printable representation of any object, may be called under either of the forms
+
+x := out
+x := a.out
+
+
+The first call yields a printable representation of the current object; the second, which assumes that a is not void, yields a printable representation of the object attached to a.
+
+==Input and output features==
+
+Some of the features of [[ref:/libraries/base/reference/any_chart|ANY]] cover common input and output needs.
+Feature io, of type [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] , gives access to standard input and output facilities. For example, io . input is the standard input file and io.new_line will print a line feed on the standard output. Feature io is declared as a once function which, when first called, returns the value of an instance of [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] that provides access to the standard input, the standard output and the error output. As a result, io is never void, so that operations such as io . new_line are always possible.
+Function out, of type [[ref:/libraries/base/reference/string_8_chart|STRING]] , is a universal mechanism for obtaining a simple external representation of any object. For non-void x of any type, the string x . out is a printable representation of x . This works for x of all types, reference or expanded. For example, if x is an integer expression, x . out is its string representation, such as -897 ; if n is a non-void reference, x . out is (recursively) the concatenation of the result of applying out to the successive fields of the attached object, each labeled by the name of the corresponding attribute. You may redefine out in any class to specify any suitable format for displaying instances of the class. To obtain the default representation regardless of any redefinition of out, use tagged_out, declared as a frozen synonym of the original out.
+The call print ( x ) will output the value of x . out on the default output if x is not void, and do nothing otherwise.
+
+==Copy and comparison routines==
+
+Procedure copy copies the fields of an object onto those of another. It is used under the form
+
+target.copy (source)
+
+
+Here both target and source must be non-void; this means that copy is only good for copying onto an object that already exists. If you need both to allocate a new object and to initialize it as a copy of another, use the function clone. For non-void source, the assignment
+
+target := clone (source)
+
+
+starts by creating a new object. If source is void, target will be made void too. The boolean function equal compares two objects for field-by-field equality. This is different from the equality operators = and /= which, in the case of reference types, compare references, not objects.
+The function deep_clone produces a duplicate of an entire object structure. The boolean function deep_equal determines whether two object structures are recursively identical. These routines are the ''deep'' counterparts of the shallow copy and equality tests provided by clone and equal.
+A class that needs a specific notion of equality and the corresponding copy semantics may redefine copy and is_equal (from which equal follows, since equal ( a , b ) is defined as a . is_equal ( b ) for non-void a ). You will find such redefinitions in a number of classes of the Base libraries. For example an instance of [[ref:/libraries/base/reference/string_8_chart|STRING]] is a string descriptor containing a reference to the actual character sequence, not that sequence itself, so that what the default equal compares and the default copy copies is the descriptor, not the string. Class [[ref:/libraries/base/reference/string_8_chart|STRING]] redefines these routines to yield the semantics normally expected by string clients; the frozen variants standard_copy and standard_equal, originally declared as synonyms to equal and copy, remain available with the default semantics.
+The function clone is defined in terms of copy, and so will follow any redefinition of copy. This makes it impossible to change the semantics of one but not of the other, which would be a mistake. The variant standard_clone is defined in terms of standard_copy.
+
+==Type information==
+
+The string-valued query generator, applied to any object, returns the name of the object's generating class: the class of which it is an instance. The boolean function conforms_to makes it possible to test dynamically whether the type of an object conforms to that of another - that is to say whether the first one's generator is a descendant of the second one's.
+These two features enable clients to ascertain the dynamic type of an entity at runtime. They are only useful for low-level components; the normal mechanism for type-dependent operations is dynamic binding.
+
+==Miscellaneous==
+
+The query Void, of type NONE, denotes a reference that is always void - not attached to any object.
+Procedure do_nothing does what its name implies.
+Function default also has an empty body; its result type is like Current , so what it returns is the default value of the current type. This is mostly interesting for expanded types, since for reference types the default value is simply a void reference.
+
+=Language-related Facilities=
+
+A number of classes offer facilities which are very close to the language level. Here too the book ''Eiffel: The Language'' covers the classes in detail, so we can satisfy ourselves with a quick summary; the flat-short forms appear in part C.
+
+==Basic types==
+
+The basic types [[ref:/libraries/base/reference/boolean_chart|BOOLEAN]] , [[ref:/libraries/base/reference/character_8_chart|CHARACTER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/real_32_chart|REAL]] and [[ref:/libraries/base/reference/real_64_chart|DOUBLE]] are defined by classes of the Kernel library.
+In reading the class specifications for the numeric types [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/real_32_chart|REAL]] and [[ref:/libraries/base/reference/real_64_chart|DOUBLE]] , you might think that the type declarations are too restrictive. For example the addition operation in class [[ref:/libraries/base/reference/real_32_chart|REAL]] reads
+
+infix "+" (other: REAL): REAL
+
+
+but there is actually no problem here. A language convention applicable to all arithmetic expressions, the Balancing rule, states that in any such expression all operands are considered to be converted to the heaviest type, where [[ref:/libraries/base/reference/real_64_chart|DOUBLE]] is heavier than [[ref:/libraries/base/reference/real_32_chart|REAL]] and [[ref:/libraries/base/reference/real_32_chart|REAL]] is heavier than [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] . So mixed-type arithmetic, consistent with common practice, is possible and indeed frequent.
+
+==Arrays==
+
+To create and manipulate one-dimensional arrays, use class [[ref:/libraries/base/reference/array_chart|ARRAY]] of the Kernel Library. Arrays are not primitive language elements; instead, they are handled through class [[ref:/libraries/base/reference/array_chart|ARRAY]] . This class is 'normal' in the sense that it may be used just as any other class by client and descendant classes. It is also somewhat special, however, in that the Eiffel compiler knows about it and uses this knowledge to generate efficient code for array operations.
+To create an instance of [[ref:/libraries/base/reference/array_chart|ARRAY]] , use the creation instruction
+
+create my_array.make (1, u)
+
+
+where the arguments indicate the lower and upper bounds. These bounds will then be accessible as my_array . lower and my_array . upper. The number of items is my_array . count; feature capacity is a synonym for count. The class invariant expresses the relation between count, lower and upper.
+To access and change the item at index ''i'' in array a, you may use features item and put, as in
+
+x := my_array.item (i)
+my_array.put (new_value, i)
+
+
+Function item has an infix synonym, infix " @ " , so that you may also write the first assignment above more concisely as
+
+x := my_array @ i
+
+
+Features item, infix " @ " and put have preconditions requiring the index ( i in the above calls) to be within the bounds of the array. This means that you can detect bounds violations (which correspond to bugs in the client software) by using a version of class [[ref:/libraries/base/reference/array_chart|ARRAY]] compiled with precondition checking on. The bounds of an array may be changed dynamically through procedure resize. Previously entered elements are retained. Rather than an explicit resize, you may use calls to procedure force which has the same signature as put but no precondition; if the index is not within the current bounds force will perform a resize as necessary.
+==Optimizing array computations==
+
+''' CAUTION''': Although [[ref:/libraries/base/reference/array_chart|ARRAY]] benefits from an efficient implementation, its more advanced facilities such as resizing do not come for free. For extensive computations on large arrays, an optimization may be desirable, bypassing these facilities. The technique yields loops that run at about the same speed as the corresponding loops written in C or Fortran (the usual references for array computations). It is of interest for advanced uses only, so that you may safely skip this section on first reading unless your domain of application is numerical computation or some other area requiring high-performance array manipulations.
+
+The optimization relies on the class SPECIAL, used internally by [[ref:/libraries/base/reference/array_chart|ARRAY]] but of no direct interest to client developers in most common uses. With the declarations
+
+my_array: ARRAY [SOME_TYPE]
+direct_access: SPECIAL [SOME_TYPE]
+
+
+you may use direct_access in lieu of 'my_array' within a critical loop, provided none of the operations may resize the array. Typically, the operations should only include put and item. In such a case you can use the following scheme:
+
+direct_access:= my_array.area
+
+ -- The critical loop:
+from
+ some_initialization
+ index := some_initial_index
+until
+ index = some_final_index
+loop
+ ...
+ x := direct_access.item (index)
+ ...
+ direct_access.put (some_value, index)
+ ...
+end
+
+
+This replaces an original loop where the operations were on my_array . Feature area of [[ref:/libraries/base/reference/array_chart|ARRAY]] gives direct access to the special object, an instance of SPECIAL, containing the array values. Features put and item are available in SPECIAL as in [[ref:/libraries/base/reference/array_chart|ARRAY]] , but without the preconditions; in other words, you will not get any bounds checking. Instances of SPECIAL are always indexed from zero, in contrast with arrays, whose lower bound is arbitrary, 1 being the most common value. But rather than performing index translations (that is to say, subtracting my_array . lower from index throughout the loop) it is preferable to use the following simple technique: if the lower bound 'lb' of my_array is 1 or another small integer, use 0 as lower bound instead when creating my_array , but only use the positions starting at 'lb'. You will waste a few memory positions (0 to lb-1), but will not have to change anything in your algorithm and will avoid costly subtractions.
+It is important to note that this optimization, if at all necessary, should at most affect a few loops in a large system. You should always begin by writing your software using the normal [[ref:/libraries/base/reference/array_chart|ARRAY]] facilities; then once you have the certainty that the software is correct, if you detect that a large array computation is hampering the efficiency of the system, you may apply the above technique to get the fastest performance out of that computation. The change to the software will be minimal - a few lines - and will be easy to undo if necessary.
+
+==Tuples==
+
+A new Kernel Library class is introduced: [[ref:/libraries/base/reference/tuple_chart|TUPLE]] .
+Alone among all classes, class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] has a variable number of generic parameters. [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [X], [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [X, Y], [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [X, Y, Z] and so on are all valid types, assuming valid types X, Y, Z and so on.
+Conformance rules:
+[CONF1]
+ For n >= 0
+ TUPLE [U1, U2, ..., Un, Un+1] conforms to
+ TUPLE [U1, U2, ..., Un]
+
+(and hence to [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] if each of the U i conforms to each of the T i for 1 <= i <= n.)
+
+In particular all tuple types conform to [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , with no parameter.
+[CONF2]
+ For n >= 0 If *every* one of the types T1, T2, ..., Tn conforms
+ to a type T, then TUPLE [T1, T2, ..., Tn] conforms
+ to [[ref:/libraries/base/reference/array_chart|ARRAY]] [T].
+
+Definition: a "tuple type" is any type based on class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , i.e. any type of the form [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] for any n (including 0, for which there is no generic parameter).
+
+{{note|(Note 1: CONF1 should be understood in terms of the underlying mathematical model. Mathematically, [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] is the set TUPLE n of all partial functions f from N+ (the set of non-negative integers) to T 1 U T 2 U ... T n, such that:
+* The domain of f contains the interval 1..n (in other words, f is defined for any i such that 1 <= i <= n).
+* For 1 <= i <= n, f (i) is a member of T i.
+}}
+
+With this definition, TUPLE n is indeed a subset of TUPLE n+1, and in particular TUPLE 0, the empty set, is a subset of TUPLE n for any n.)
+
+Semantics: an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n] is a tuple whose first element is an instance of T 1, the second element being an instance of T 2 etc. (The precise definition is the mathematical one given in note 1.) Note that there can be more than n elements to the tuple: for example a tuple with first element 5 and second element "FOO" is an instance of all of the following tuple types: [[ref:/libraries/base/reference/tuple_chart|TUPLE]] ; [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] ]; [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/string_8_chart|STRING]] ].
+
+It may seem restrictive at first to permit only one class, [[ref:/libraries/base/reference/tuple_chart|TUPLE]] , to have an arbitrary number of actual generic parameters. Why not have a general mechanism for declaring any class C so that all of C [X], C [X, Y] etc. are valid? But in fact this is not really a restriction. To obtain this effect without any complicated language convention, just declare C as
+C [G -> TUPLE]
+
+and then use the generic derivations
+
+C [TUPLE [X]]
+C [TUPLE [X, Y]]
+and so on. This also makes it possible to have the effect of some fixed parameters and some variable ones, as in
+C [G, H, I -> TUPLE]
+
+so we have all the necessary flexibility.)
+
+==Tuple expressions==
+
+Let e 1, e 2, ..., e n be expressions of respective types T 1, T 2, ..., T n. Then the expression
+
+[e 1, e 2, ..., e n]
+
+denotes an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, ..., T n], whose first element is e 1, the second element being e 2 etc.
+Tuple expressions can be nested: whereas
+
+[1, 2, 3]
+
+is a tuple with three elements (representing an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] ]),
+
+[1, [2, 3]]
+
+is a tuple with two elements, the second one itself a tuple; the overall expression represents an instance of [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [[[ref:/libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:/libraries/base/reference/integer_32_chart|INTEGER]] ].
+As a special case of tuple expression syntax, the delimiters [ and ] are replaced by parentheses for the tuple representing the actual argument list of a routine call (see section 4).
+
+==Tuple features==
+
+The exact specification of class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] will be described in an addition to ELKS. The principal features are:
+* [[ref:/libraries/base/reference/tuple_chart|count]] (number of significant elements)
+* [[ref:/libraries/base/reference/tuple_chart|item]] (i), with the obvious precondition: the i-th element, of type [[ref:/libraries/base/reference/any_chart]] (since the value of i is not known at compile time); also first, second, third, fourth and fifth, of the appropriate types.
+* [[ref:/libraries/base/reference/tuple_chart|put]] (x, i), with the obvious precondition: replace i-th element with x. If argument x is not of the appropriate type T i there is no effect.
+* [[ref:/libraries/base/reference/tuple_chart|is_equal]] : redefined to consider only the first n elements, where n is the smaller length.
+
+Other features under consideration include:
+* stripped (i): a tuple of type [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [T 1, T 2, T i-1, T i+1, ..., T n], derived from the current one by removing the i-th component, again with the obvious precondition.
+* wedged (x, i): a tuple with one more element, inserted at position i.
+* '''infix''' "+": tuple concatenation
+* '''infix''' "++": element concatenation; t ++ x is the same thing as t.wedged (x, t.count + 1).
+
+==What have we gained?==
+
+First we have solved the only case in the Eiffel language in which an expression has no precisely defined type: polymorphic manifest arrays. We don't have manifest arrays any more, but manifest tuples, with a precisely defined type. No incompatibility is introduced thanks to rule CONF2. The original syntax for manifest arrays, Result := <1, e 2, ..., e n>>, will continue to be supported.
+Second, we can define functions that return multiple results. This is a quite significant increase in expressive power. No common language has that. (You have to go to Lisp and functional languages.) Just define [[ref:/libraries/base/reference/tuple_chart|TUPLE]] [...] as the result type; in the function, you will write things like
+
+Result := [e 1, e 2, ..., e n]
+
+Also, from a theoretical viewpoint, feature calls are simpler and more homogeneous: every feature takes exactly one tuple as argument and returns exactly one tuple as a result. (Either of these tuples may be empty: the first for a feature with no argument, the second for a procedure.) The syntax for a call becomes
+Feature Arguments
+
+with Arguments defined as
+Tuple_expression
+
+where the Tuple_expression uses the form given in section 2 but with the outermost [ and ] delimiters replaced by parentheses to conform to usual practice. So the call
+f (a, b, c)
+
+which we continue to think of as having three arguments a, b and c, formally has only one tuple argument [a, b, c]. This is of course not to be confused with a call of the form
+g ([a, b, c])
+
+which has one argument (a tuple with three elements) in both the ordinary and the formal sense.
+
+==Active, iterators, numerical applications, introspection==
+
+For a set of important applications of tuples see the book chapter on [[EiffelBase, Iteration|agents and iterators]] which also covers aspects of numerical software and related topics following from the tuple mechanism.
+
+==Temporary limitations==
+
+The implementation of tuples has the following limitations:
+* Conformance of [[ref:/libraries/base/reference/array_chart|ARRAY]] types to [[ref:/libraries/base/reference/tuple_chart|TUPLE]] types is not yet fully supported.
+* Class [[ref:/libraries/base/reference/tuple_chart|TUPLE]] does not have features such as first and second. You must use item and, in most cases, an assignment attempt.
+
+==Strings==
+
+Strings are handled by class [[ref:/libraries/base/reference/string_8_chart|STRING]] , similar in many respects to [[ref:/libraries/base/reference/array_chart|ARRAY]] . Strings are of arbitrary size. The make creation procedure takes an integer argument, as in:
+
+s, s1, s2, s3: STRING
+ ...
+create s.make (30)
+
+The argument indicates the number of characters for the initial allocation. This is not an absolute limit: the string will automatically grow or shrink as a result of future operations. You may always request a resizing explicitly by calling procedure resize.
+
+==String descriptor==
+
+The object attached at run-time to an entity such declared of type [[ref:/libraries/base/reference/string_8_chart|STRING]] is not the actual sequence of characters but a string descriptor, which contains a reference to the actual string contents.
+
+As a result, four assignment or assignment-like operations are possible:
+* '''A1''' s1 := s
+* '''A2''' s2 . share ( s )
+* '''A3''' s3 := clone ( s )
+* '''A4''' s4 . copy ( s )
+
+As illustrated below, ''' A1''' is a reference assignment: s1 will be attached to the same descriptor as s. ''' A2''' keeps the descriptors distinct, but make them refer to the same sequence of characters. ''' A3''' uses the redefinition of clone for class [[ref:/libraries/base/reference/string_8_chart|STRING]] : s3 will be attached to a new string, completely distinct from the string attached to s1 although made of identical characters. ''' A4''' has almost the same effect as '''A3''', but is only applicable if s4 was not void, and will override the existing descriptor rather than creating a new one.
+ [[Image:strings]]
+fig. 1: Effect of string assignment and copy operations
+
+[[ref:/libraries/base/reference/basic_routines_chart|BASIC_ROUTINES]] provides a number of conversion functions, such as charconv.
+
+=Files, Input, Output=
+
+A few classes of the Kernel Library support file manipulation, input and output: [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] , FILE, [[ref:/libraries/base/reference/directory_chart|DIRECTORY]] and [[ref:/libraries/base/reference/unix_file_info_chart|UNIX_FILE_INFO]] . For simple applications it suffices to use [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] , but to understand the concepts better it is preferable to look first at the other two.
+
+==General files==
+
+FILE describes the notion of sequential file viewed as a data structure which fits in the general taxonomy of EiffelBase.
+The class declaration defines files as unbounded sequences of characters. This means that you will find in FILE all the operations on sequential data structures that you have come to know and love by reading this documentation - at least, all that apply. Just as stacks and linked lists, files have put, extend, has, item and so on. More specific to files are the typed input and output operations. For output, you will find put_character, put_integer, put_real, put_double and put_string, as well as new_line. For input you will find read_integer and its co-conspirators.
+
+{{warning| '''Caution''': Note the application to input features of the command-query separation principle.
+The input features such as read_integer do not by themselves return a result; they set the values of queries such as last_integer. So the normal way to read is through two operations:
+
+ my_file . read_integer
+ new_value := my_file . last_integer }}
+
+Queries are available to determine the status of a file, in particular exists, is_readable, is_executable, is_writable, is_creatable, is_closed, is_open_read and so on.
+
+{{warning| '''Caution''': You will notice in the flat-short form that all these queries except the first have exists as a precondition. This precondition is good for efficiency since it saves an existence test - a relatively expensive operation - when you know that a certain file exists. But it also means that if you have any doubt about the file's existence you must use the queries in the style
+
+ if my_file . exists and then my_file . is_readable then ... }}
+
+FILE is a deferred class. Various implementations are possible. A quite detailed one is PLAIN_TEXT_FILE, which adds many features for accessing reading and writing data from/to a file.
+[[ref:/libraries/base/reference/unix_file_info_chart|UNIX_FILE_INFO]] describes objects that contain internal information, such as protection mode and size, about a file.
+The class [[ref:/libraries/base/reference/directory_chart|DIRECTORY]] describes those files which are directories - nodes in the tree describing the file structure.
+
+==Basic input and output==
+
+Regardless of the operating system that you use, for simple input and output [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] is sufficient. You may inherit from that class to gain direct access to its features; or you may declare an entity of type [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] . But remember that a feature of this type is always available: io, from class [[ref:/libraries/base/reference/any_chart|ANY]] . Thanks to this feature you may include simple input and output in any class, with instructions such as
+io.put_string ("My message")
+
+[[ref:/libraries/base/reference/std_files_chart|STD_FILES]] defines three default files through features input, output and error. These features are Once functions, so that the first reference to any one of them will automatically create the corresponding file descriptor and open the associated file.
+To simplify the writing of common input and output operations, the most frequently used features of class FILE - for reading and writing integers, reals and so on, as discussed next - have been repeated in [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] so as to apply to the default input and output. Procedure put_string in the example at the beginning of this section is typical: it writes its output on the standard output. More generally, [[ref:/libraries/base/reference/std_files_chart|STD_FILES]] has all the put_xxx, read_xxx and last_xxx features of FILE.
+
+=PERSISTENCE, STORAGE AND RETRIEVAL=
+
+Most object-oriented applications need the ability to store object structures on persistent storage for later retrieval, and to transfer such object structures to other applications.
+Class [[ref:/libraries/base/reference/storable_chart|STORABLE]] addresses this need.
+
+==Persistence completeness==
+
+A fundamental requirement on object persistence mechanisms is the '' Persistence Completeness'' rule, stated as follows in ''Eiffel: The Language'':
+Whenever a routine of class [[ref:/libraries/base/reference/storable_chart|STORABLE]] stores an object into an external file, it stores with it the dependents of that object. Whenever one of the associated retrieval routines retrieves a previously stored object, it also retrieves all its dependents.
+Storing an object just by itself would usually result in wrong semantics: most objects contain references to other objects, which must also be stored and retrieved with it. The persistence completeness rule ensures that this is always the case. It also means, of course, that the features of [[ref:/libraries/base/reference/storable_chart|STORABLE]] must do much more than simple input and output; they must perform complete traversals of object structures.
+
+==Using the storage and retrieval facilities==
+
+Class [[ref:/libraries/base/reference/storable_chart|STORABLE]] is meant to be used as ancestor. You can use its features in any descendant C; for example a routine of C may contain a call of the form basic_store ( my_descriptor ) .
+The effect of this call will be to store the current object and all its dependents into the file denoted by my_descriptor.
+Although basic_store and other procedures of [[ref:/libraries/base/reference/storable_chart|STORABLE]] will in general process objects of many different types, only the generating class of the structure's initial object, C in our example, needs to be a descendant of [[ref:/libraries/base/reference/storable_chart|STORABLE]] .
+
+==Varieties of store operations==
+
+Two variants of the store operation are supported: basic store and general store. Basic store produces more compact structures in the resulting files, and is slightly faster; but the resulting structure is dependent on the system which executes the store operation ('System' is taken here, as elsewhere in this documentation, in its Eiffel sense of an executable assembly of classes, compiled together with the help of a configuration file.) This means that you can use procedure basic_store to store an object structure during an execution of a system if you will only retrieve it later in that execution, or in a
+subsequent execution of the same system. If you need to store objects from a certain system and then retrieve them from a different system, possibly running on a different computer, use general_store. The result of general_store is still platform-dependent; the representation of numbers, in particular, is determined by the underlying machine architecture. A third variant called independent_store will be added in the future to [[ref:/libraries/base/reference/storable_chart|STORABLE]] , using an entirely platform-independent storage format; then a system running on a computer with a certain architecture will be able to retrieve, without any explicit conversion operation, object structures stored by a system running on a machine of a completely different architecture. With general_store the storing and retrieving computers must have compatible architectures.
+
+==Retrieval==
+
+You only need to be aware of the difference between basic and general store at storage time. The stored structure will always be available through feature retrieved; this feature will figure out, from the format of the stored structure, whether it was stored by basic_store or general_store, and will decode it accordingly.
+Feature retrieved returns a result of type [[ref:/libraries/base/reference/storable_chart|STORABLE]] and is typically used through an assignment attempt of the form
+x ?= retrieved (my_descriptor)
+
+
+The assignment attempt is necessary because retrieved returns a result of type [[ref:/libraries/base/reference/storable_chart|STORABLE]] whereas the type of x will be based on a proper descendant of [[ref:/libraries/base/reference/storable_chart|STORABLE]] . If the structure in the file has been corrupted and retrieved is unable to do its job, it will trigger an exception. The code for that exception in class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] (which inherits it from EXCEP_CONST and is discussed in the next section, together with the notion of exception code) is Retrieve_exception.
+
+==Recoverable storable==
+
+Sometime you will be in a position where the schema of a class will have changed between the time you stored your object and the time you are trying to retrieve it. Such changes include:
+* class name changed
+* attributes have been added or removed
+* attributes have been renamed
+* attributes type have changed
+
+The storable mechanism allows you to retrieve the old version of the object only if it was saved using the independent_store facility. Each time you retrieve an object of a certain base class whose schema has changed, the feature correct_mismatch will be called. This feature is defined in [/libraries/base/reference/any_chart.xml|ANY] and by default will raise an exception. To handle the mismatch, you need to redefine correct_mismatch in the base class whose schema has been changed. For example in EiffelBase, [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE] has changed between version 5.1 and version 5.2 to use SPECIAL rather than [/libraries/base/reference/array_chart.xml|ARRAY]for its internal data storage. To retrieve a 5.1 version of [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE], you need to define correct_mismatch as following:
+
+correct_mismatch is
+ -- Attempt to correct object mismatch during retrieve using `mismatch_information'.
+ local
+ array_content: ARRAY [G]
+ array_keys: ARRAY [H]
+ array_marks: ARRAY [BOOLEAN]
+ do
+ -- In version 5.1 and earlier, `content', `keys' and `deleted_marks'
+ -- where of base class [[ref:/libraries/base/reference/array_chart|ARRAY]] . In 5.2 we changed it to be a SPECIAL for
+ -- efficiency reasons. In order to retrieve an old [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]] we
+ -- need to convert those [[ref:/libraries/base/reference/array_chart|ARRAY]] instances into SPECIAL instances.
+
+ -- Convert `content' from [[ref:/libraries/base/reference/array_chart|ARRAY]] to SPECIAL
+ array_content ?= mismatch_information.item ("content")
+ if array_content /= Void then
+ content := array_content.area
+ end
+
+ -- Convert `keys' from [[ref:/libraries/base/reference/array_chart|ARRAY]] to SPECIAL
+ array_keys ?= mismatch_information.item ("keys")
+ if array_keys /= Void then
+ keys := array_keys.area
+ end
+
+ -- Convert `deleted_marks' from [[ref:/libraries/base/reference/array_chart|ARRAY]] to SPECIAL
+ array_marks ?= mismatch_information.item ("deleted_marks")
+ if array_marks /= Void then
+ deleted_marks := array_marks.area
+ end
+
+ if content = Void or keys = Void or deleted_marks = Void then
+ -- Could not retrieve old version of [[ref:/libraries/base/reference/hash_table_chart|HASH_TABLE]] . We throw an exception.
+ Precursor {TABLE}
+ end
+ end
+
+
+Note the use of mismatch_information, this is a once feature of [/libraries/base/reference/any_chart.xml|ANY] of type MISMATCH_INFORMATION which behaves like a [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE]. The keys of the table are the names of the attributes on which a mismatch occurred and the values are the corresponding object fields as they were originally stored. In this particular case of [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE] we know that the previous version was an [/libraries/base/reference/array_chart.xml|ARRAY], so we do an assignment attempt and if it succeeds we assign its area to the corresponding attribute of [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE].
+
+If a class name changed, then you need to create an instance of CLASS_NAME_TRANSLATIONS, it behaves like a [/libraries/base/reference/hash_table_chart.xml|HASH_TABLE] where the keys represent the old name, and the value the new name. This instance needs to be created before the call to retrieved.
+
+=Access To Internal Properties=
+
+In some applications you may need to fine-tune the exception handling and memory management mechanisms. You may also need a simple way to access command-line arguments. In less common cases you may require low-level access to internal properties of objects.
+
+==Exception handling==
+
+Class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] enables you to control the handling of exceptions. [[ref:/libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] , discussed next, complements it for the special case of fine-grain signal handling on Unix or Unix-like platforms. Both are meant to be inherited by any class that needs their facilities.
+The basic exception mechanism treats all exceptions in the same way. In some cases it may be useful to discriminate in a Rescue clause between the various possible causes.
+Class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] provides the features to do this. Each kind of exception has an integer code, which you can use through several features:
+* The integer-valued query exception which gives the code of the latest exception.
+* Queries which determine the general nature of the latest exception: is_signal which determines whether the exception was an operating system signal; is_developer_exception which determines whether it was explicitly caused by a raise, as explained next; assertion_violation.
+* Query recipient_name which gives the name of the exception's recipient - the routine that was interrupted by the exception.
+
+The class also provides a set of constant integer-valued attributes which denote the various possible codes, such as No_more_memory, Routine_ failure and Precondition_violation. So you can test the value of exception against these codes if you need to ascertain the precise nature of an exception. To keep [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] simple these constant attributes are declared in a class EXCEP_CONST, of which [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] is an heir.
+Another occasional requirement is for a mechanism to trigger an exception explicitly. Procedure raise answers this needs; the argument, a string, is the tag chosen for the exception. The code in this case is Developer_exception; the query is_developer_exception will return true; and the tag is accessible through feature tag_name.
+You will notice in the interface specification for [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] that for some properties of the latest exception there are two features, one with a name such as exception or recipient_name as seen above and the other with a name prefixed by original_: original_exception, original_recipient_name.
+
+{{warning| ''' CAUTION''': The reason for the presence of these pairs is that the immediately visible cause of a routine interruption may not be the real one. Assume that routine r from class C, which has a Rescue clause, calls s from D with no Rescue clause, and that some call executed by s causes a precondition violation. Because s has no Rescue clause of its own, s will fail. Up the call chain, the first routine that has a Rescue clause - r itself, or one of its own direct or indirect callers - may process the exception; but if it examines the exception code through attribute exception it will get the value of Routine_failure. This may be what you want; but to handle the situation in a finer way you will usually need to examine the code for the original exception, the one that interrupted s. This code will be accessible through the attribute original_exception, which in this case will have the value of Precondition, the exception code for precondition violations. So you have the choice between exploring the properties of the original exception, or those of the resulting routine failures. Just make sure you know what you are looking for. }}
+
+As you will see from the header comments in the flat-short form of class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] , the queries that return detailed information about an exception, such as assertion_violation, all give an answer determined by original_exception rather than exception, since when the two are different (that is to say, when you handle the exception in a routine other than the original recipient) the value of exception is always Routine_failure and there is nothing more to say about it.
+
+==Signal handling==
+
+The features of class [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] enable you to determine whether a certain exception is a signal - an operating system event such as may result from a child process that disappears, a window that is resized, a user that hits the Break key and many others. But they do not give you more details because the exact set of possible signals is highly platform-dependent.
+Class [[ref:/libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] complements EXCEP_CONST by providing codes for the signals of Unix and similar systems, such as Sigkill for the 'kill' signal and Sigbus for bus error.
+Query is_defined ( some_signal ) , where some_signal is an integer code, will determine whether some_signal is supported on the platform.
+A class whose routines need to perform specific processing depending on the nature of signals received should inherit from [[ref:/libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] , or a similar class for another platform.
+Because signal codes are platform-dependent, the features of [[ref:/libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] are implemented as once functions - computed on the first call - rather than constants, although this makes no difference to clients.
+
+==Memory management==
+
+Class [[ref:/libraries/base/reference/memory_chart|MEMORY]] , like [[ref:/libraries/base/reference/exceptions_chart|EXCEPTIONS]] , is meant to be used as an ancestor by classes that need its facilities. It offers a number of features for controlling memory management and fine-tuning the garbage collection mechanism, a key component of the Eiffel Software environment.
+One of the most useful features in this class is dispose. This procedure describes actions to be applied to an unreachable object just before the garbage collector reclaims it. By default, as declared in [[ref:/libraries/base/reference/memory_chart|MEMORY]] , the procedure does nothing; but you may redefine it in a proper descendant of [[ref:/libraries/base/reference/memory_chart|MEMORY]] to describe dispose actions. Normally such actions will involve freeing external resources: for example a class describing file descriptors may redefine dispose so that whenever a descriptor object is garbage-collected the corresponding file will be closed.
+
+{{warning| '''Caution''': This example is typical of proper uses of dispose.In a dispose procedure you should not include any instruction that could modify the Eiffel object structure, especially if some objects in that structure may themselves have become unreachable: these instructions could conflict with the garbage collector's operations and cause catastrophic behavior. The legitimate use of dispose redefinitions is for disposing of non-Eiffel resources. }}
+
+Other features of [[ref:/libraries/base/reference/memory_chart|MEMORY]] provide direct control over the operation of the garbage collector. You can in particular stop garbage collection through a call to collection_off, and restart it through a call to collection_on. By default, garbage collection is always on (a testimony to its authors' trust in its efficiency). Garbage collection is normally incremental, so as not to disrupt the application in a perceptible way. To start a complete garbage collection mechanism - reclaiming all unused objects - call procedure full_collect. The remaining features of [[ref:/libraries/base/reference/memory_chart|MEMORY]] enable finer control of the collection mechanism and are useful in special cases only. You will even find a free procedure providing brave (and competent) developers with a mechanism for reclaiming individual objects manually.
+MEM_INFO, the result type for query memory_statistics in [[ref:/libraries/base/reference/memory_chart|MEMORY]] , describes objects containing information collected about memory usage. The features of [[ref:/libraries/base/reference/gc_info_chart|GC_INFO]] provide statistics about the garbage collector's operation.
+
+==Command-line arguments==
+
+Writing, assembling and compiling a system yields an executable command. The system's users will call that command with arguments. These are normally provided in textual form on the command line, as in
+'''your_system''' arg1 arg2 arg3
+
+although one may conceive of other ways of entering the command arguments, such as tabular or graphical form-filling. In any case the software must be able to access the values passed as command arguments.
+A language mechanism is available for that purpose: the Root Class rule indicates that the creation procedure of the root class may have a single argument (in the Eiffel sense of argument to a routine) of type [[ref:/libraries/base/reference/array_chart|ARRAY]] [[[ref:/libraries/base/reference/string_8_chart|STRING]] ] . The corresponding array of strings will be initialized at the beginning of the system's execution with the values entered as arguments to that execution of the command.
+Although this facility suffices in many cases, it is not always convenient if you suddenly need to access the command arguments in a class that is far-away from the root. An alternative mechanism, class ARGUMENTS, is available. Once again, this is a class from which you should inherit if you need its facilities. It has just two exported features:
+* argument_count, a non-negative integer, is the number of command arguments.
+* argument (i), a string, is the i-th command argument. Here i must be between 0 and argument_count; the convention is that for i = 0 the result is the name of the command itself.
+
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki
new file mode 100644
index 00000000..6326884c
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki
@@ -0,0 +1,30 @@
+[[Property:title|EiffelBase Support Cluster]]
+[[Property:weight|2]]
+The support cluster offers some commonly needed functionality that do not belong to the kernel.
+
+==Conversions, mathematical properties and ASCII characters==
+
+A few utility classes complement the [[EiffelBase, The Kernel|kernel]] facilities. [[ref:/libraries/base/reference/primes_chart|PRIMES]] , [[ref:/libraries/base/reference/random_chart|RANDOM]] and [[ref:/libraries/base/reference/fibonacci_chart|FIBONACCI]] are part of the data structure taxonomy; the others are meant to be used as ancestors by classes needing their features.
+
+Two classes provide basic mathematical functions such as logarithms and trigonometric functions: [[ref:/libraries/base/reference/single_math_chart|SINGLE_MATH]] for single precision and [[ref:/libraries/base/reference/double_math_chart|DOUBLE_MATH]] for the double-precision variants. [[ref:/libraries/base/reference/math_const_chart|MATH_CONST]] contains mathematical constants: p , the square root of two, Euler's constant e .
+
+[[ref:/libraries/base/reference/primes_chart|PRIMES]] , [[ref:/libraries/base/reference/random_chart|RANDOM]] and [[ref:/libraries/base/reference/fibonacci_chart|FIBONACCI]] are data structure classes - heirs of [[ref:/libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] . In all of these classes function i_th takes an integer argument i and will return the i-th element of the sequence under consideration - prime numbers, pseudo-random numbers or Fibonacci numbers. These sequences are active structures, on which forth will advance the current position and item will return the value at the current position. A few other features are specific to each case: for example [[ref:/libraries/base/reference/random_flatshort|higher_prime]] will yield the smallest prime greater than or equal to a certain value, and [[ref:/libraries/base/reference/random_flatshort|set_seed]] will define the seed to be used for starting the pseudo-random sequence.
+
+==Internal object structures==
+
+Class [[ref:/libraries/base/reference/internal_chart|INTERNAL]] provides low-level access to internal object structures. It, too, is meant to be used as ancestor by classes needing its features.
+Here are some of the most useful calls and what they yield, obj being an entity attached to an object O and i an integer:
+* [[ref:/libraries/base/reference/internal_flatshort|class_name]] (obj): the name of the generator class for O.
+* [[ref:/libraries/base/reference/internal_flatshort|dynamic_type ]] ( obj ) : the integer code for the type of O, where each type in a system is identified by a unique code.
+* [[ref:/libraries/base/reference/internal_flatshort|field_count ]] ( obj ) : the number of fields in O.
+* [[ref:/libraries/base/reference/internal_flatshort|physical_size ]] ( obj ) : the space occupied by O, in bytes.
+* field_xx ( i, obj ) where xx is name or offset: name or offset of the i-th field of O.
+* [[ref:/libraries/base/reference/internal_flatshort|field ]] ( i, obj ) : the value of the i-th field of , if a reference; declared of type ANY in the class.
+* yy_field ( i, obj ) where yy is boolean, character, integer, real or double: the value of the i-th field of O, if of the corresponding type; each declared of the appropriate type in the class.
+* [[ref:/libraries/base/reference/internal_flatshort|is_special ]] ( obj ) , a boolean query which indicates whether O is a special object (the sequence of values representing the elements of an array or the characters of a string).
+
+{{warning| '''CAUTION:''' Only very special cases justify the use of this class. Unless you are writing the lowest level of an interface between an Eiffel application and external tools (such as a database management system), and this requires passing to those tools information about the internals of Eiffel objects, you almost certainly should not use [[ref:/libraries/base/reference/internal_chart|INTERNAL]] . }}
+
+
+
+
diff --git a/documentation/current/solutions/basic-computing/eiffelbase/ifell.wiki b/documentation/current/solutions/basic-computing/eiffelbase/ifell.wiki
new file mode 100644
index 00000000..fc605e3f
--- /dev/null
+++ b/documentation/current/solutions/basic-computing/eiffelbase/ifell.wiki
@@ -0,0 +1,106 @@
+[[Property:title|IFELL]]
+[[Property:weight|4]]
+ (This license describes the terms applicable to the open-source EiffelBase libraries. For the EiffelStudio and other libraries license terms, please refer to the Eiffel Software end-user license.)
+On August 4, 1998 -- as part of the Eiffel Summit at TOOLS USA '98 -- Interactive Software Engineering (Eiffel Software) officially made its flagship [[EiffelBase Library|EiffelBase library ]] available for free to any organization that wants to use it, for either commercial or non-profit purposes.
+
+The terms of the new EiffelBase license are given below. Changes since the original version are recorded in the [[#changes|changes section]] .
+
+We hope that others will be inspired by this example to release their own reusable Eiffel components to the public.
+==Preamble==
+(This Preamble is not part of the license.)
+
+EiffelBase is one of the principal contributions of Eiffel: a library of fundamental structures and algorithms covering the basics of computing, and resulting from a "Linnaean" effort at a general-purpose taxonomy of computing structures. We believe that EiffelBase is one of the most carefully designed and extensively used libraries in the object-oriented industry. The library and its design principles are described in detail in the book [http://www.eiffel.com/doc/ ''Reusable Software: The Base Object-Oriented Component Libraries'' ] .
+
+EiffelBase is at the center of Eiffel Software's Eiffel and has been among the major factors attracting users to the technology. In spite of this competitive advantage, Eiffel Software officially announced in June of 1998 that it would release the library to the public in source form, under the terms of the license below. There are two main reasons for this initiative:
+* As the software industry seems poised to adopt the idea of reusable components, we feel that EiffelBase provides an ideal basis and are happy to contribute it to the community.
+* We are impressed by the quality of some public-domain software and the effectiveness of the "open source" movement. We hope that the public availability of EiffelBase in source form will encourage many people to take a close look at the classes of EiffelBase, criticize its weaker points, provide improvements, and add their own high-quality contributions.
+
+===About the license===
+
+After considering existing license contracts for publicly available software, we felt that the GPL (Gnu Public License) as well as LGPL, its variant for libraries, while useful and interesting, were not adequate since they are too restrictive.
+
+In particular a crucial requirement was that the license should allow commercial companies to use EiffelBase (and other libraries that may use this license in the future) in for-profit developments without any fear (justified or not) that GPL-like requirements could cause proprietary elements of their products to come under the open source umbrella themselves.
+
+The closest model was that of the Perl Artistic License, which significantly influenced the terms of the agreement as shown below. It too, however, was not applicable verbatim. EiffelBase was initially designed as a commercial product and then released as free software, a different situation from that of software that was never commercial.
+
+You will note that there are few restrictions on the use of EiffelBase in the license given below. You can use EiffelBase in your academic work and re-publish the source; you can produce a commercial software product using EiffelBase and not owe a cent to Eiffel Software.
+
+===Ownership===
+
+EiffelBase remains an Eiffel Software product and will continue to be distributed as such to Eiffel Software customers. This means in particular that there is no o lessening of our maintenance and support responsibility to our customers under maintenance. In fact, the increased scrutiny and outside contributions will mean an increase of our commitment to develop EiffelBase and of the quality of the product.
+
+==The License Text==
+
+This is the official license text.
+
+===Definitions===
+"Eiffel Software" refers to Interactive Software Engineering Inc.
+"The Library" refers to the collection of software texts in the Eiffel language, originally written by Eiffel Software, and constituting the EiffelBase library of fundamental computing science structures, as well as any derivatives of these texts as may be created through textual modification (by people) or through translation to lower-level languages (by programs such as compilers).
+
+"Standard Version" refers to the version of the Library maintained by Eiffel Software and distributed by Eiffel Software to its customers under maintenance.
+
+"You" means any person interested in using, modifying or distributing the Library.
+
+"Source form" means the text of the Library's classes, in the Eiffel language.
+
+"Object form" means the translation, as performed by a compiler or other program, of the Library or part of the Library into another, usually lower-level code (such as C, assembly language or machine language) intended for execution by a machine.
+
+"Reference implementation" means the latest officially released version of Eiffel Software's implementation of the Eiffel language.
+
+===Statement of copyright and ownership===
+
+'''1.''' The Library is the property of Eiffel Software and bears Eiffel Software's copyright. Any use you make of the Library must respect Eiffel Software's proprietary rights.
+
+===Right of use===
+'''2.''' Eiffel Software hereby grants you permission to do any of the following without payment to Eiffel Software, under the conditions of sections 3 to 7 of this Agreement:
+* '''2.1.''' Use the Library, in source form or object form, as part of any software you develop and distribute to other parties.
+* '''2.2.''' Distribute the source of the Library to other parties.
+
+===Conditions===
+
+'''3.''' If you use (2.1) or distribute (2.2) the Library, you are encouraged, but not required,to provide to Eiffel Software and the rest of the Library's user community any bug fixes or other improvements that you make to the existing classes of the Library.
+
+'''4.'''If you produce new classes based on the Library or extending the Library, you are encouraged, but not required, to make them available in the same way.
+
+'''5.''' If you use the Library (2.1) in source or object form for producing software that you distribute, you are encouraged, but not required, to include the following mention (or its translation into the language of the rest of the distribution, if other than English) in the documentation of your software, including textual documentation as well as online documentation such as "About..." entries:
+* ''This product includes EiffelBase software from Interactive Software Engineering, used according to the terms of the Eiffel Software Free Eiffel Library License (IFELL). ''See [http://eiffel.com/ http://eiffel.com] and, for the license terms, [http://eiffel.com/products/base/license.html http://eiffel.com/products/base/license.html] .
+
+
+'''6.''' If you distribute the source code of part or all of the Library (2.2) you must:
+* Distribute entire classes, not just extracts.
+* Retain, in the distributed version, the entire copyright notice of these classes.
+* If you need to make any modification to the classes, mark those modifications clearly in the class texts.
+* Ensure that the text remains valid Eiffel. Note that this license does not authorize you to distribute versions of the Library restated in other programming, analysis or design languages, except if mechanically translated from the source form by an Eiffel compiler, in which case they fall under "object form". For any non-mechanical adaptation to other languages you must obtain authorization from Eiffel Software. "Valid Eiffel" includes the language described in the latest edition or printing of the book [http://www.eiffel.com/services/training/books.html ''Eiffel: The Language'' ] (Prentice Hall), plus any changes or extensions that have been approved by the Nonprofit International Consortium for Eiffel (NICE) or have been accepted for discussion by the Language Committee of NICE, provided they are accepted by the reference implementation.
+* If Eiffel Software releases a new version of the Library, you must, no later than six months after the release of that version, either: (A) update your distribution to the new version; (B) add the following notice to all files in your distribution:" ''This is an obsolete version of EiffelBase. The latest version is available from http://eiffel.com''"; or (C) cease distributing your version.
+
+
+You may not charge any fee for the distribution of the Library (source or binary), although you may charge for software that includes the Library in whole or in part as per the other provisions of this Agreement.
+
+'''7.''' You may not use the name of Eiffel Software to endorse or promote products derived from the Library without specific prior written permission.
+
+'''8.''' THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+
+==Changes==
+(This list of changes is not part of the license.)
+'''General note on changes''': as usage of free EiffelBase grows and more people contribute to it, some terms of the license text may occasionally have to be changed in light of this accumulated experience and of comments received from users and contributors. It is our intention to ensure that
+* (1) Any such changes will be minor, affecting the details of the licensing rather than the spirit of IFELL.
+* (2) If they affect the substance of the license in any way, they go in the general direction of extending, not restricting, the rights of users of EiffelBase.
+
+
+Should a question arise regarding use of EiffelBase, the terms to be applied are those in effect at the time of use, disregarding any later change.
+
+'''28 June 2000''': in response to comments by Joachim Durchholz through Patrick Schoenbach, replacement of most occurrences of the word "EiffelBase" by"the Library" to facilitate application to other libraries.
+
+'''7 May 1999''': in response to comments by David Broadfoot on the Eiffel Software user list, rewording of the [[#contamination|explanation]] of why we are applying more liberal terms than GPL-style licenses. regarding fears of [[#contamination|contamination]] with the Gnu Public License.
+
+'''6 May 1999''': following comments by Ed Avis and Alexander Kjeldaas, we now permit distribution maintainers to continue distributing an old version as long as they [[#obsolete_version|mention clearly that it's obsolete ]] .
+
+'''7 April 1999''': following comments by Loryn Jenkins and Ed Avis, removal of the requirement that bug fixes and improvements be provided back to the maintainers of the library. This requirement has been changed to a mere [[#encourage_bug_reports|encouragement ]] , facilitating use of the library. Of course it is in everyone's interest to report bugs and improvements.
+
+'''7 April 1999''': following comments by Loryn Jenkins, loosening of the [[#valid_eiffel|definition of "valid Eiffel"]] . This change also caused addition of the notion of [[#reference_implementation|reference implementation]] . The purpose is to avoid crippling EiffelBase by preventing it from utilizing innovative language constructs and corrections in the language contributions. Such language extensions are OK as long as they have been accepted for discussion by NICE and are supported by the reference implementation.
+
+'''1 April 1999''': following some comments by Richard Stallman,addition of a qualification (" ''justified or not''") to the notes regarding fears of [[#contamination|contamination ]] with the Gnu Public License. Our intention is not to criticize the GPL but simply to note that the GPL does cause some fears, "justified or not", among commercial developers.
+
+
+
+
diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/compilation-multithreaded-systems.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/compilation-multithreaded-systems.wiki
new file mode 100644
index 00000000..227de9d1
--- /dev/null
+++ b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/compilation-multithreaded-systems.wiki
@@ -0,0 +1,42 @@
+[[Property:title|Compilation of multithreaded systems]]
+[[Property:weight|3]]
+==Settings==
+* Set the option multithreaded in the project settings under Advanced.
+* Do not use a non-multi-threaded precompiled library. The corresponding multi-threaded libraries of base, WEL and Vision2 should be located in $ISE_EIFFEL/precomp/spec/$PLATFORM/ with the mt prefix.
+* You may want to include the thread library (located at "$ISE_EIFFEL/library/thread") to your project. This setting can be done in [[Group Options| the groups section of the project settings window]] .
+* When using external C libraries, be sure that they are MT-safe: on the platforms where the Eiffel Threads are available. For example [[WEL Library|Wel]] and [[EiffelNet Library|Net]] multi-threaded libraries can be recognized by the `mt' prefix.
+
+==Compilation==
+
+Just launch the compilation: the Eiffel compiler will generate and link the multi-threaded executable. If the project was already compiled, clean the project and recompile it from scratch.
+
+==External C files==
+
+The C files that you link with a multi-threaded Eiffel application must be compiled in multi-threaded mode. In addition, you should follow some basic guidelines, which you can find in any documentation on threads. Here are the main requirements:
+* Check what you are importing is safe: you cannot arbitrarily enter non-threaded code in a multi-threaded program. Check your include files and libraries you use for the linking to decide if they can be used in multi-threaded mode.
+* If you are using CECIL in multi-threaded mode, you must compile your C files with the same defined symbols as those used to compile the generated C-code in multi-threaded mode.
+* Threaded code can safely refer to unsafe code ONLY from the initial thread.
+
+{{note|'''Note''': if you use the libraries Net and MEL in multi-threaded mode, you should use libmtnet. a and libmtmel. a. When using MEL, you have to be aware that Motif 1. 2 is not threaded-safe (i.e not reentrant). Motif 2. x is threaded-safe.}}
+
+==Thread Safe Eiffel libraries==
+
+Most libraries are not thread safe. This means that even though you can use them in a multi-threaded environment, you will need to add the necessary protection to ensure that objects are accessed only by one thread at a time.
+
+Most of the issues is related to the use of EiffelBase containers which have been designed at a time where threads where not present. In the future we will certainly provide a version of EiffelBase which will be designed to be thread safe, in the meantime, you have to use basic protection mechanism such a mutexes to guarantee a safe execution of your programs.
+
+Here is a summary of what you need to include in your project settings when using our libraries:
+
+- EiffelBase: not thread safe, no externals required
+
+- WEL: partly thread safe regarding creation of graphical objects that belongs to two different threads, but since it relies on EiffelBase, be aware of what has been said. Other libraries have the same dependency on EiffelBase and this warning will not be repeated.
+
+- MEL: you have to be aware that Motif 1. 2 is not thread safe and that Motif 2.x is. Therefore you can use MEL in a multi-threaded program only if you have Motif 2.x. In this case, you need to include libmtmel.a instead of libmel.a
+
+- EiffelNet: thread safe with above limitation on EiffelBase.
+
+- COM: not thread safe.
+
+
+
+
diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/multithread-faq.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/multithread-faq.wiki
new file mode 100644
index 00000000..44e6d5aa
--- /dev/null
+++ b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/multithread-faq.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Multithread FAQ]]
+[[Property:weight|6]]
+===I've launched several threads and they do not seem to be executed:===
+
+The thread that launched the several threads may be dead before its children.
+
+===Two threads can lock the same mutex, however none of them unlocks it:===
+
+Same problem as above. Maybe the first thread that locked the shared mutex died before the second tried to lock it: thus, the first one automatically unlocked it when it died. You should put a join_all or an infinite loop in the parent thread.
+
+===I've added the option multithreaded in the project settings and it crashes:===
+
+If you have already compiled your system in non-MT mode, you cannot change the mode of compilation and simply relaunch your compilation (the generated C-code would be incompatible). Delete all your object files in your W_code or F_code directory and freeze or finalize the system again.
+
+===My once function changed during my MT-Eiffel-program:===
+
+The once functions are once per thread in Multithreaded mode. Hence, each once function is thread-specific and is initialized the first time it is called in a thread.
+
+You can create a once per process by following [[Once features in multithreaded mode|these instructions]] .
+
+
+
+
diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki
new file mode 100644
index 00000000..dbd76374
--- /dev/null
+++ b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki
@@ -0,0 +1,49 @@
+[[Property:title|Once features in multithreaded mode]]
+[[Property:weight|4]]
+==Manipulating Once features in multithreaded mode==
+
+Eiffel introduced the powerful mechanism of once routines. A once routine has a body that will be executed only once, at the first call. Subsequent calls will have no further effect and, in the case of a function, will return the same result as the first. This provides a simple way of sharing objects in an object-oriented context.
+
+For multithreaded applications, the appropriate semantics is that once routines must be called once per thread (rather than once per process). This is the semantics supported by EiffelThread.
+
+Then the once feature is not initialized once per process but once per thread. Your once feature will be called again in any new thread execution.
+
+==Once per Process/Thread==
+
+Current once features in Eiffel are once per thread. This means that when a once feature is called in a thread, the Eiffel run-time will check whether it has been already computed in this thread. If not, the once feature will be initialized and computed. This seems to be a relevant way of managing once features in multithreaded mode: most of the time, a once called in a thread is not likely to share its result.
+
+However, in some case, we need to share once features.
+
+Moreover, an Eiffel programmer should be able to have an alternative between a once per thread or per process implementation.
+
+==Using Once per process/thread features in EIFFEL==
+
+Here is what you will do to implement a once per process feature:
+
+class
+ TEST_ONCE_PER_PROCESS
+
+ feature
+
+ object_per_thread: OBJECT is
+ -- Once per thread.
+ once
+ create Result.make
+ end
+
+ object_per_process: OBJECT is
+ -- New 'object' (once per process)
+ -- that could be shared between threads
+ -- without reinitializing it.
+ indexing
+ once_status: global
+ once
+ create Result.make
+ end
+
+ end -- class TEST_ONCE_PER_PROCESS
+
+You can do the same with once procedures.
+
+
+
diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki
new file mode 100644
index 00000000..eb8f67c5
--- /dev/null
+++ b/documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki
@@ -0,0 +1,158 @@
+[[Property:title|Thread library overview]]
+[[Property:weight|1]]
+This is only a quick overview of the [[EiffelThread Library|Thread library]] . The reference of this library should give all its content.
+
+==Creating and launching threads: the class THREAD (deferred)==
+
+The class of the thread object you want to create should inherit the THREAD class.
+Your thread is represented by a class which inherits from THREAD (deferred class).
+
+
+ class
+ MY_THREAD
+
+ inherit
+ THREAD
+ ...
+
+ feature
+
+ execute is
+ -- define the deferred feature from THREAD.
+ do
+ ...
+ end
+ ...
+
+ end -- class MY_THREAD
+
+Creating a thread is like creating an Eiffel object:
+
+ my_thread: MY_THREAD
+ -- MY_THREAD inherits from THREAD and defines
+ -- the deferred procedure `execute'
+
+ create my_thread
+
+
+{{note| '''Note''': You have created a thread object but have not started the thread itself yet.
+To run the thread, use the feature launch from THREAD. }}
+ my_thread.launch
+On the Eiffel side, the procedure execute will be launched. This procedures deferred in class THREAD, you have to define it in MY_THREAD.
+On the C side, a C thread will be created and launched.
+{{warning| '''Caution''': you may call join_all and the end of the execution of the parent thread if you do not want it to die before its child, otherwise they may prematurely terminate.
+==The class MUTEX==
+
+The implementation of the class MUTEX is mapped on the C standard thread library. An instance of class MUTEX can be shared between different thread.
+my_mutex.pointer is the pointer to the nested C mutex of my_mutex.
+* Declaration of the mutex:
+ my_mutex: MUTEX
+
+* Creation of mutex:
+ create my_mutex.make
+
+* Locking the mutex:
+ my_mutex.lock
+
+* Unlocking the mutex:
+ my_mutex.unlock
+
+* try_lock: if it is not locked yet, lock the mutex and return True, otherwise it returns False.
+ my_mutex.lock
+
+* Is my mutex initialized?
+ my_mutex.is_set
+
+
+{{note| '''Note''': on Windows: The MUTEX objects on Windows are recursive while they are not on Unix. A recursive mutex can be locked twice by the same thread. }}
+
+{{warning| '''Caution''': be sure that a mutex is unlocked when it is disposed. }}
+
+==The class SEMAPHORE==
+
+Like MUTEX, the features of this class are mapped on the C thread library. An instance of class SEMAPHORE can be shared between thread.
+* Declaration of the semaphore :
+ my_sem: SEMAPHORE
+
+Creation of semaphore: initialize semaphore with nb_tokens, it requires nb_tokens > = 0
+ create my_sem.make (nb_tokens)
+
+* Wait for a token:
+ my_sem.wait
+
+* Give back a token:
+ my_sem.post
+
+* try_wait, similar to try_lock from MUTEX, if a token is available, take it and return True , otherwise return False .
+ my_sem.try_wait
+
+
+{{warning| '''Caution''': be sure that a semaphore does not wait for a token when it is disposed }}
+
+==The class CONDITION_VARIABLE==
+
+This class allows to use condition variables in Eiffel. An instance of class CONDITION_VARIABLE can be shared between threads.
+* Declaration of the condition variable
+ my_cond: CONDITION_VARIABLE
+
+* Creation:
+ create my_cond.make
+
+* Wait for a signal (send by signal). You need to use a mutex.
+
+ my_mutex: MUTEX
+
+ create my_mutex.make
+
+
+ my_mutex must be locked by the calling thread so as wait can be called. wait atomically unlocks my_mutex and waits for the condition variable my_mutex to receive a signal. As soon as it received a signal, my_cond locks my_mutex ;
+
+ my_mutex.lock
+ -- You must lock `my_mutex' before calling wait.
+
+ my_cond.wait (my_mutex)
+ -- Here the critical code to execute when `my_cond' received a signal.
+
+ my_mutex.unlock
+ -- Unlock the mutex at the end of the critical section.
+
+
+
+* Send a signal one thread blocked on the condition variable `my_cond'.
+ my_cond.signal
+
+* Send a signal to all the threads blocked on the condition variable `my_cond'.
+ my_cond.broadcast
+
+*
+{{warning| '''Caution''': be sure that a condition variable is unblocked when it is disposed. }}
+
+
+==Miscellaneous classes==
+
+class THREAD_ATTRIBUTES: defines the attributes of an Eiffel Thread regarding the thread scheduling policy and priority.
+==Controlling execution: THREAD_CONTROL==
+* yield: the calling thread yields its execution in favor of an other thread of same priority.
+* join_all: the calling thread waits for all other threads to finished (all its children).
+* A parent thread can wait for the termination of a child process through the feature join of class THREAD_CONTROL (inherited by THREAD):
+
+ thr: MY_THREAD
+ ...
+ thr.launch
+ ...
+ thr.join
+
+
+
+
+
+
+
+}}
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/concurrent-computing/eiffelthread/index.wiki b/documentation/current/solutions/concurrent-computing/eiffelthread/index.wiki
new file mode 100644
index 00000000..eaaa2e2c
--- /dev/null
+++ b/documentation/current/solutions/concurrent-computing/eiffelthread/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|EiffelThread]]
+[[Property:weight|0]]
+The EiffelThread library includes the main components needed to build multithreaded systems.
+See:
+* [[EiffelThread: Introduction|Introduction]]
+* [[Thread library overview|Library description]]
+* [[Multithread FAQ|FAQ]]
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/esql-sample.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/esql-sample.wiki
new file mode 100644
index 00000000..b09d2603
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/esql-sample.wiki
@@ -0,0 +1,65 @@
+[[Property:title|Esql Sample]]
+[[Property:weight|0]]
+This sample consists of a command line SQL parser. SQL statements are filtered through a monitor and sent to the RDBMS.
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\store\esql\''.
+* Choose ''esql.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Choose the targe according to the installed DBMS.
+* Click '''OK'''.
+
+==Running==
+
+This sample lets you interact with your database through a console.
+
+First you have to enter the database connection information:
+* For ODBC:
+
+Database user authentication:
+Data Source Name: handson
+Name: smith
+Password: mypass
+
+
+{{note| '''Note:''' '' Name'' and ''Password'' are no required with ODBC. If you don't need ''Name'' and ''Password'', you can simply hit '''Return''' when prompted ''.'' }}
+
+* For Oracle:
+
+Database user authentication:
+Name: smith@HANDSON
+Password: mypass
+
+
+{{note| '''Note:''' you have to specify the Oracle User Name and Net Service Name with the syntax ''@ ''where '''' stands for the User Name and '''' stands for the Net Service Name. }}
+
+
+Then you can enter standard SQL queries to interact with your database, for instance:
+
+SQL> select firstname, lastname from CONTACTS where lastname = 'Smith'
+John Smith
+SQL>
+
+
+{{note| '''Note:''' enter ''exit'' to quit the application. }}
+
+==Under the Hood==
+
+This sample showcases the use of the 3 basic classes to interact with your database:
+* [[ref:libraries/store/reference/db_control_chart|DB_CONTROL]] to connect and disconnect to your database.
+* [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] to perform 'select' queries.
+* [[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] to perform SQL queries that output no result.
+
+The whole sample code is contained in the root class:
+* ESQL for Oracle.
+* ESQL_ODBC for ODBC.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/inserter-sample.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/inserter-sample.wiki
new file mode 100644
index 00000000..eefcfd2e
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/inserter-sample.wiki
@@ -0,0 +1,80 @@
+[[Property:title|Inserter Sample]]
+[[Property:weight|2]]
+This sample lets the user insert a DB_BOOK object in your database using EiffelStore insertion facilities.
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\store\insert\''.
+* Clicking open loads the selected project
+* Choose inserter.ecf
+* Select the target according to the installed DBMS
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+This sample lets you interact with your database through a console.
+
+First you have to enter the database connection information:
+* For ODBC:
+
+Database user authentication:
+
+Data Source Name: handson
+
+Name: smith
+
+Password: mypass
+
+
+{{note| '''Note:''' '' Name'' and ''Password'' are no required with ODBC. If you don't need ''Name'' and ''Password'', you can simply hit '''Return''' when prompted ''.'' }}
+
+* For Oracle:
+
+Database user authentication:
+
+Name: smith@HANDSON
+
+Password: mypass
+
+
+{{note| '''Note:''' you have to specify the Oracle User Name and Net Service Name with the syntax ''@ ''where '''' stands for the User Name and '''' stands for the Net Service Name. }}
+
+
+Then you can insert a book in the database, for instance:
+
+What new book should I create?
+
+Author? John Smith
+
+Title? My book
+
+Quantity? 1
+
+Price? 50
+
+Year? 2001
+
+Double value? 12.675
+
+Object inserted
+
+
+{{note| '''Note:''' if your database does not contain a DB_BOOK table, this example will create it. }}
+
+==Under the Hood==
+
+This sample showcases the use of the [[ref:libraries/store/reference/db_store_chart|DB_STORE]] class to [[Data Object Coupling| perform database insertions]] where the SQL language is totally abstracted.
+
+The whole sample code is contained in the root class:
+* INSERTER for Oracle.
+* INSERTER_ODBC for ODBC.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/selector-sample.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/selector-sample.wiki
new file mode 100644
index 00000000..cc086d24
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-samples/selector-sample.wiki
@@ -0,0 +1,95 @@
+[[Property:title|Selector Sample]]
+[[Property:weight|1]]
+This sample creates a DB_BOOK table in your database, enters sample data in it and lets you select rows from this table with author's name.
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\store\select\''.
+* Clicking open loads the selected project
+* Choose select.ecf
+* Select the target according to the installed DBMS
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+Before running this sample, one must do link a specific file to data.sql as follows:
+
+With Oracle:
+
+''ln data.sql.oracle data.sql''
+
+With ODBC:
+
+''ln data.sql.odbc data.sql''
+
+{{warning| '''Caution:''' the ''data.sql'' file must be available in the sample application current directory. If you run the sample from EiffelStudio, this directory should be the ''EIFGENs/target/W_CODE/'' directory of your project (where target is one of the installed DBMS). }}
+
+This sample lets you interact with your database through a console.
+
+First you have to enter the database connection information:
+* For ODBC:
+
+Database user authentication:
+Data Source Name: handson
+Name: smith
+Password: mypass
+
+
+{{note| '''Note:''' '' Name'' and ''Password'' are no required with ODBC. If you don't need ''Name'' and ''Password'', you can simply hit '''Return''' when prompted. }}
+
+* For Oracle:
+
+Database user authentication:
+Name: smith@HANDSON
+Password: mypass
+
+
+{{note| '''Note:''' you have to specify the Oracle User Name and Net Service Name with the syntax ''@ ''where '''' stands for the User Name and '''' stands for the Net Service Name. }}
+
+
+Then you can select rows from this table with author's name, for instance:
+
+Author? ('exit' to terminate):Bertrand Meyer
+Seeking for books whose author's name match: Bertrand Meyer
+
+Author:Bertrand Meyer
+Title:Eiffel The Libraries
+Quantity:11
+Price:20
+double_value:435.60000610351562
+First publication:07/01/1994 12:00:00.0 AM
+
+
+Author:Bertrand Meyer
+Title:Eiffel The Language
+Quantity:9
+Price:51
+double_value:775.22998046875
+First publication:07/01/1992 12:00:00.0 AM
+
+
+
+Author? ('exit' to terminate):
+
+
+{{note| '''Note:''' enter ''exit'' to quit the application. }}
+
+==Under the Hood==
+
+This sample showcases the use of the [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] class to perform smart ''select'' queries, using:
+* [[Data Object Coupling|Database data and Eiffel objects Coupling]] .
+* [[Query variables|Variables Binding]] .
+
+The whole sample code is contained in the root class:
+* SELECTOR for Oracle.
+* SELECTOR_ODBC for ODBC.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-dataview-cluster.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-dataview-cluster.wiki
new file mode 100644
index 00000000..375228f4
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-dataview-cluster.wiki
@@ -0,0 +1,431 @@
+[[Property:title|EiffelStore DataView Cluster]]
+[[Property:weight|3]]
+==1. Introduction==
+
+DataView cluster helps the programmer creating a GUI for a RDBMS. It gives a basic solution for a RDBMS GUI and also enables the developer to customize his GUI from this basic interface.
+
+This cluster is client of EiffelStore to interface with a RDBMS and EiffelVision2 to create a GUI. However, the use of EiffelStore and EiffelVision 2 is sufficiently encapsulated to let the programmer use other database/graphic libraries.
+
+Notice finally that DataView is based on some common O-O ''design patterns''. Knowing these patterns will help you understand how the library works. It can also give an example of patterns use.
+
+==2. Specifications==
+
+This part draws the main capabilities that can be expected from the DataView cluster. These capabilities are not exhaustive since the cluster architecture enables to add easily new capabilities to it.
+
+===2.1. Required database structure===
+
+The cluster has been designed to work well with relational databases on Third Normal Form. Database tables must also have an unique numeric ID.
+* The cluster automatically performs associations between related tables. This is required to work fine with 3rd NF architectures.
+* The unique ID enables to update the database content. If you only intend to display database table content, unique IDs are not required.
+* The numeric ID enables to directly give IDs to new table rows. If you don't intend to create table rows, this is not necessary. Notice that with only a couple of redefinitions, the numeric ID requirement problem can be overcome.
+
+===2.2. Database content display===
+
+The cluster provides facilities to:
+* display a set of table rows.
+* select a (current) table row in the set.
+* display the current table row so that it can be edited.
+
+For instance, an interface can display a multi-column list of table rows. A given row can be selected in the list and its information can be then edited through a set of text fields and combo-boxes.
+
+The standard cluster usage is to define a GUI that will associate a given frame/window to a given database table, that is, the information that is displayed in a GUI area will be determined at compile-time. This enables to adapt the GUI display to the type of information displayed, which is recommended when creating a GUI for non-developer users (or any people that should not be aware of the database structure and functioning). Nevertheless, determining the type of information displayed by a frame/window at runtime is still possible as not hard-coded.
+
+Abstracting database in the GUI might not be as easy as only changing database attribute fields names. Information to display may not match the database tables structure. However, for consistency reasons, we can assume that he information to display within a GUI area belongs to a set of associated tables. The easiest solution is to create database views that directly contain the information to display on the GUI area. This implies though that the database has to be modified for the GUI needs.
+
+DataView cluster affords a second solution:
+* Model-View separation enables to merge graphically information that is separated in the process part (i.e. that is from a different table).
+* Table associations facilities enable to specify to display automatically content of table rows associated to a given table row. For instance, with a CONTACTS table associated to a COMPANIES table, the cluster can retrieve automatically a COMPANIES table row associated to a selected CONTACTS table row.
+
+===2.3. Actions performed on the database===
+
+The cluster provides facilities for the following actions:
+* Creating a table row
+* Deleting a table row
+* Updating the content of a table row
+* Selecting a set of table rows
+
+Other capabilities can be added to these ones, for instance by writing descendants of DataView cluster classes that would handle more database operations.
+
+Operations relative to the database structure modification, for instance creating a database table, may be more difficult to add since the database structure is hard-coded. But these advanced capabilities might not be necessary in a GUI for non-developer users.
+
+==3. General description==
+
+===3.1. Global architecture===
+
+The DataView cluster is based on 1 class called [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] that represents the interface for 1 relational database table. An architecture using ''DataView'' is centered on database table structure rather than the GUI structure. The basic idea is to have:
+* 1 database relational table
+* 1 GUI window or frame
+* 1 [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] object
+
+This is then possible to adapt the code to have a GUI meeting the specifications, database structure can be totally abstracted in the interface, which might be more convenient for non-developer GUI users.
+
+===3.2. Library structure===
+
+The cluster can be separated into 3 main parts:
+* The '''model''': processes the information and interfaces with an abstract graphic interface (the handle) and an abstract database interface.
+* The '''handle''': defines an abstract graphic interface for the model.
+* The '''view''': implements the handle interface with EiffelVision2 widgets.
+
+The abstract database interface is defined in the EiffelStore generation.tables_access cluster. This cluster can indeed been used independently from the DataView cluster.
+
+===3.3. Model cluster structure===
+
+The '''model''' cluster processes the information retrieved from the GUI and the database and update then both GUI and database.
+
+The cluster is based on the [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] class which objects represents a database relational table (or view).
+
+DV_TABLE_COMPONENT objects can be interconnected to match the table associations. The [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] class has been designed to work with 3rd Normal Form relational databases. [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] achieves most of the work to retrieve associated table rows for a 3NF database. For instance, when deleting a table row, the component ensures that every associated table row is also deleted.
+
+[[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] objects can be customized by adding some subcomponents to it. Subcomponents enable to display table rows content on screen, to navigate among table rows and to perform different database queries.
+
+[[Image:sub-component-objects]]
+
+Process objects structure for a GUI
+
+===3.4. Design patterns===
+
+This cluster adapts several well-known O-O design patterns.
+
+====3.4.1. Model-View separation pattern====
+
+The GUI appearance is totally abstracted in the GUI processing part, this enables to change the GUI display without changing any part of the model part.This is implemented with 2 sets of classes:
+* A set of interfaces that corresponds to each type of abstract widgets needed by the model.
+* A set of classes that implements these interfaces. Notice that an implementation class can implement several interfaces and several classes can implement the same interface.
+
+Let's see an example through a BON diagram:
+
+[[Image:model-view-relationship]]
+
+Model-View separation pattern implementation in ''DataView''
+* Light blue classes represents the model cluster.
+* Orange class represents the handle.
+* Yellow and green classes represents the view cluster.
+* Pink classes represents the EiffelVision2 library.
+
+====3.4.2. Strategy pattern====
+
+DataView cluster provides the developer with a basic GUI implementation AND lets them customize their application. This is possible with a strategy pattern:
+
+The developer assigns different subcomponents to a [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] object to define its behavior. The component object only uses the interface of each subcomponent.
+
+A default implementation is written for each interface to let the user use the cluster as quick as possible. To adapt components behavior to their needs, the developer can then create a new subcomponent class inheriting from the abstract interface.
+
+This BON diagram illustrates this for [[ref:libraries/store/reference/dv_creator_chart|DV_CREATOR]] and [[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] subcomponents:
+
+[[Image:dv-table-component-strategy]]
+
+Strategy pattern used in ''DataView'' model cluster
+
+==4. Cluster interface==
+
+This part describes how to use the table component class and its subcomponents classes:
+* The [[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] class to [[#dv_searcher|select table rows from the database]] .
+* The [[ref:libraries/store/reference/dv_tablerows_navigator_chart|DV_TABLEROW_NAVIGATOR]] class to [[#dv_tablerow_navigator|navigate among selected table rows]] .
+* The [[ref:libraries/store/reference/dv_creator_chart|DV_CREATOR]] class to [[#dv_creator|create new table rows in the database]] .
+* The [[ref:libraries/store/reference/dv_tablerow_fields_chart|DV_TABLEROW_FIELDS]] class to [[#dv_tablerow_fields|edit a table row content]] .
+
+===4.1. DV_TABLE_COMPONENT class===
+
+This class is responsible for the management of a database table. Its behavior is determined by its assigned subcomponents.
+
+To create a valid and functional [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] object, follow these steps:
+# Call set_tablecode to specify which table the component will deal with.
+# Specify [[#output_handler|handlers to output messages]] .
+# Set the [[#database_handler|database handler]] .
+# Add different [[#controllers|controllers corresponding to actions to perform]] .
+# Set [[#subcomponents|subcomponents]] .
+# Set [[#associated_components|associated components]] .
+# Call activate to let the component work. This will basically set different default values for non required information not set during the creation process.
+
+The component can then be used on an interface:
+* Input interactions are done via component and subcomponents controllers (4).
+* Output interactions are done via output handlers (2).
+
+====4.1.1. Output handlers====
+
+Output handlers are specific to the [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] object, that is, you can output messages in a different way within your GUI. However, the same handlers will be used for subcomponents.
+
+3 handlers can be set:
+* `status_handler' to display status information
+* `warning_handler' to display warning information. Warnings usually correspond to database errors, they are called warnings because the database error is "caught" and the message should enable the user to round the problem.
+* `confirmation_handler' to ask for confirmation before an action.
+
+These handlers have default values, which are:
+* For `status_handler' and `warning_handler', messages are displayed on standard output (with {ANY}.io.put_string)
+* For `confirmation_handler', action is executed without confirmation.
+
+====4.1.2. Database handler====
+
+This handler is specific to the application. It must inherit from ABSTRACT_DB_TABLE_MANAGER. Since it is specific to the program, it can be set before creating any [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] object through {DV_DATABASE_HANDLER}.set_database_handler.The [[ref:libraries/store/reference/db_table_manager_chart|DB_TABLE_MANAGER]] class is the default database handler for EiffelStore.
+
+4.1.3. Action controllers
+
+No subcomponent is associated to 'write', 'refresh' and 'delete' actions since these actions does not require specific behavioral choices.
+
+To perform 'write', 'refresh' and 'delete' at runtime, a controller is associated to each of these actions. This controller triggers the action when a determined user event is grabbed, for instance, when the user clicks a button.
+
+[[#dv_s_control|Controllers]] are implemented by the abstract class [[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] of cluster user_interactions (handle).
+
+====4.1.4. Subcomponents====
+
+Subcomponents can be assigned to a table component to specify its behavior to create table rows, select table rows from the database and navigate among selected table rows. A special subcomponent enable to display the ''current'' table row, i.e. the table row that can be edited to update the database. The default behavior for these subcomponents is that the functionality is not available, that is, subcomponents are not mandatory.
+
+These components share the table component output handlers. They are automatically activated when table component is activated.
+
+====4.1.5. Associated components====
+
+Table components can be associated to reflect relation of database tables represented. Associated table components are organized:
+* 1 master component enables to manually select database table rows.
+* Slave components automatically select table rows that are associated to the current table row of the master component.
+
+{{note| '''Note''': Notice that table associations can be '''nested'''. }}
+
+2 types of associations are possible to reflect table relations:
+* The slave table is dependent on the master table (1:N relationship)
+* The slave table is necessary for the master table (N:1 relationship)
+
+Let us see an example with 3 relational tables:
+
+[[Image:table-objects-associations]]
+
+Tables architecture and corresponding component objects
+
+The object architecture leads to a GUI where the user can select a company and see the company country information and contacts in this company.
+
+Finally, notice that by default slave components have the same output handlers as their master and slave components are activated when the master component is.
+
+===4.2. DV_SEARCHER class===
+
+====4.2.1. Overview====
+
+[[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] is responsible for retrieving table rows from the database. Let us see how it interacts with a table component:
+
+[[Image:component-search-relation]]
+
+Basic relationship between table component class and search class
+* `display' assigns a set of table rows to the table component.
+* `refresh' asks to refresh the table rows from the same database query.
+
+[[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] component does not afford an extended interface. This interface is defined in its descendants. The implemented [[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] descendants are:
+* [[ref:libraries/store/reference/dv_typed_searcher_chart|DV_TYPED_SEARCHER]] performs different [[#dv_typed_searcher|basic searches]] used by the cluster.
+* [[ref:libraries/store/reference/dv_interactive_searcher_chart|DV_INTERACTIVE_SEARCHER]] enables to create a graphic interface to [[#dv_interactive_searcher|let user set search parameters]] .
+
+====4.2.2. DV_TYPED_SEARCHER class====
+
+This class provides 3 types of searches:
+* "Every row" search: every rows of a table are fetched.
+* "ID selection" search: the selection is qualified by an ID.
+* "Qualified selection" search: the selection is qualified.
+
+=====4.2.2.1. "Every row" search=====
+
+Call read to set table rows on the associated table component.
+
+=====4.2.2.2. "ID selection" search=====
+
+Call read_from_tablerow to set table rows on the associated table component. Qualification ID is the ID of the table row in parameter. Table of row in parameter must be the table of rows to select.
+
+This capability is used by DataView cluster in [[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] to select a just-created table row and display it on the table component.
+
+=====4.2.2.3. "Qualified selection" search=====
+
+Call read_from_table row to set table rows on the associated table component. Table of row in parameter may not be the table of rows to select.
+
+To extract the qualifier, the search component needs additional information:
+* The location of the qualifying value in the table row passed in parameter (set_row_attribute_code)
+* The qualifying attribute location in the table rows to select (set_criterion)
+
+This capability is used in [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] when a table row is selected to set associated table rows to slave components. Take a look at add_necessary_table and add_dependent_table.
+
+====4.2.3. DV_INTERACTIVE_SEARCHER class====
+
+This class enables to create a graphic interface to let user perform basic searches. These searches are qualified by one table attribute. This interface has 5 parts:
+* A [[#dv_s_control| controller]] that enables to launch the search
+* A [[#dv_s_string| text input field]] to set qualifying attribute
+* A [[#dv_s_string| text input field]] to set qualifying value
+* A [[#dv_s_integer| typed input field]] to set qualification type
+* A [[#dv_s_check| Boolean input field]] to set case sensitivity
+
+Text input fields correspond to handle class [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] , typed input fields corresponds to handle class [[ref:libraries/store/reference/dv_sensitive_integer_chart|DV_SENSITIVE_INTEGER]] and Boolean input fields corresponds to handle class [[ref:libraries/store/reference/dv_sensitive_check_chart|DV_SENSITIVE_CHECK]] .
+
+===4.3. DV_TABLEROW_NAVIGATOR class===
+
+====4.3.1. Overview====
+
+Table component class contains a set of table rows. This class lets table component class know which of these rows is the current one.
+
+[[Image:component-navigate-relation]]
+
+Basic relationship between table component class and navigation class
+
+[[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] also uses the class to enable to select associated table rows when creating a new table row (for instance, when creating a company, an existing country should be selected). Let us see how this is designed:
+
+[[Image:dv-tablerows-navigator-clients]]
+
+DV_TABLEROWS_NAVIGATOR clients
+
+{{note| '''Note''': DV_TABLEROWS_COMPONENT class merely carries a set of table rows and enables to select one table row. }}
+
+DV_CONTROL_NAVIGATOR affords a way to navigate among searched table rows.
+
+====4.3.2. DV_CONTROL_NAVIGATOR class====
+
+This class enables 2 navigation systems:
+* Navigating among table rows with "previous" and "next" controllers.
+* Navigating among table rows through a display list.
+
+{{tip| '''Tip''': Notice that both systems can be used. }}
+
+You can directly set [[#dv_s_control| controllers]] for "previous" and"next" actions. A 3rd controller, "edit list", enables to show or raise the display list.
+
+{{warning| '''Caution''': Notice that DV_CONTROL_NAVIGATOR only manages this controller sensitivity. }}
+
+You can assign a [[#dv_tablerow_list| display list]] to the navigator with a [[ref:libraries/store/reference/dv_tablerow_list_chart|DV_TABLEROW_LIST]] component.
+
+===4.4. DV_CREATOR class===
+
+====4.4.1. Overview====
+
+This class enables to create database table rows.
+
+[[Image:component-create-relation]]
+
+Basic relationship between table component class and navigation class
+
+[[ref:libraries/store/reference/dv_creator_chart|DV_CREATOR]] class contains minimum information to interact with [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] : when a table row is created, a creator component may display it on the table component. In this case, when the table component needs to refresh the table rows set, this refreshing action need to be managed by the creator component:
+* `set_just_created' informs a table component that displayed table row set comes from the creator component.
+* `refresh' lets the creation component refresh table component display.
+
+Much of the work, that is row creation, is totally abstracted in DV_CREATOR.DV_CHOICE_CREATOR implements DV_CREATOR and thus affords a creation procedure.
+
+====4.4.2. DV_CHOICE_CREATOR class====
+
+=====4.4.2.1. Overview=====
+
+This class creates a new table row and sets its key values:
+* Database handle gives the primary key value (ID) .
+* The class asks the user for foreign key values (for table associations) by displaying available values in a list.
+
+DV_TABLEROW_NAVIGATOR is used to select a foreign key value, let us see how this is implemented:
+
+[[Image:dv-choice-creator-fkeys-selection]]
+
+[[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] suppliers for foreign keys selection
+
+[[ref:libraries/store/reference/dv_tablerow_id_provider_chart|DV_TABLEROW_ID_PROVIDER]] inherits from [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLEROWS_COMPONENT]] to interface with [[ref:libraries/store/reference/dv_tablerows_navigator_chart|DV_TABLEROWS_NAVIGATOR]] .
+
+Relation between [[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] and [[ref:libraries/store/reference/dv_tablerow_id_provider_chart|DV_TABLEROW_ID_PROVIDER]] is basically:
+
+[[Image:creator-provider-relation]]
+
+DV_CHOICE_CREATOR/DV_TABLEROW_ID_PROVIDER basic interactions
+
+Creation process and [[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] objects creation procedure can help you use this class.
+
+=====4.4.2.2. Creation process=====
+
+Table row creation process is:
+# Table row creation is triggered by a [[#dv_s_control| controller]] ("create")
+# DV_CHOICE_CREATOR creates a table row object
+# DV_CHOICE_CREATOR requests a first foreign key value to [[ref:libraries/store/reference/dv_tablerow_id_provider_chart|DV_TABLEROW_ID_PROVIDER]] (through `select_from_table')
+# DV_TABLEROW_ID_PROVIDER loads the available table rows that can be referenced
+# DV_TABLEROW_ID_PROVIDER assigns the table rows to DV_TABLEROWS_NAVIGATOR and pops up the interface with the table rows
+# Table row selection is triggered by a [[#dv_s_control| controller]] ("ok")
+# DV_TABLEROW_ID_PROVIDER retrieves the selected table row ID and gives it back to DV_CHOICE_CREATOR (through `add_foreign_key_value')
+# DV_CHOICE_CREATOR requests other foreign key values to DV_TABLEROW_ID_PROVIDER
+# DV_CHOICE_CREATOR creates the database row with a new ID through the database handle
+
+=====4.4.2.3. Objects creation procedure=====
+
+To create a DV_CHOICE_CREATOR, follow these steps:
+# Create an object conforming to DV_TABLEROWS_NAVIGATOR
+# Create a DV_TABLEROW_ID_PROVIDER object and assign the DV_TABLEROWS_NAVIGATOR object to it
+# Set a [[#dv_s_control| controller]] to trigger foreign key selection
+# Set the action to perform to pop up the interface to select the foreign key
+# Create a DV_CHOICE_CREATOR object and assign the DV_TABLEROW_ID_PROVIDER object to it
+# Set a [[#dv_s_control| controller]] to trigger table row creation
+
+===4.5. DV_TABLEROW_FIELDS class===
+
+====4.5.1. Overview====
+
+This class enable to display and edit the current table row of a table component. Let us see first how it interacts with the table component:
+
+[[Image:component-fields-relation]]
+
+DV_TABLE_COMPONENT/DV_TABLEROW_FIELDS basic interactions
+* refresh_tablerow refreshes display with a new table row
+* update_tablerow requests an updated table row for database update. Unchanged values are kept from a default table row
+* updated_tablerow is the last updated table row
+
+The class contains a list of fields that represent editable table attributes.The design is simple:
+
+[[Image:dv-tablerow-fields-design]]
+
+Table row edition capability design
+
+====4.5.2. DV_TABLEROW_FIELD class====
+
+This class enables to edit a table row attribute value. The view is abstracted using the handle cluster [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] class that [[#dv_s_string|represents the editable text value]] .
+
+This class manages a field value but can also provide field name and type if [[#dv_s_string|graphic fields]] are provided. Notice that standard [[ref:libraries/store/reference/dv_tablerow_field_chart|DV_TABLEROW_FIELD]] objects can be generated through the [[ref:libraries/store/reference/dv_factory_chart|DV_FACTORY]] class, which is a component factory.
+
+==5. Handle cluster==
+
+This cluster provides the model with an interface to input or output data on the GUI. This enables to remove any link to a graphic implementation in the model, following the [[#model-view_sep|Model-View separation]] design pattern. The cluster contains a set of interface classes to design this:
+* The [[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] class to [[#dv_s_control|let the user trigger an action]] .
+* The [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] class to [[#dv_s_string|input or output a text value]] .
+* The [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_INTEGER]] class to [[#dv_s_integer|input or output a quantity value]] .
+* The [[ref:libraries/store/reference/dv_sensitive_check_chart|DV_SENSITIVE_CHECK]] class to [[#dv_s_check|input or output a tag value]] .
+* The [[ref:libraries/store/reference/dv_tablerow_list_chart|DV_TABLEROW_LIST]] class to [[#dv_tablerow_list|display a set of table rows and grab events on it]] .
+
+===5.1. DV_SENSITIVE_CONTROL class===
+
+The [[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] class lets a model class trigger a specific action on a determined user event. Furthermore, the model class lets the user know when its state enables to trigger the action, by setting the controller sensitivity (i.e. if the controller is insensitive, the action cannot be triggered).
+
+{{note| '''Note''': sensitivity excepted, these controllers could have been implemented by Eiffel ''agents''. }}
+
+{{note| '''Note''': sensitivity enables to let the user know ''before''triggering an action if this is possible or not. The other possibility is to let the user know ''after'' trying to trigger the action that it was not possible(with a warning for instance): this is often less convenient. }}
+
+The standard controllers are buttons or menu items: the specific action is triggered when button is clicked or menu item selected.
+
+[[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] is inherited by [[ref:libraries/store/reference/dv_button_chart|DV_BUTTON]] that implements an EiffelVision2 button. Other implementations can be added, such as a menu item.
+
+===5.2. DV_SENSITIVE_STRING class===
+
+The [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] class lets a model class input or output a text graphically. As for controllers, the model class lets the user know when a text value can be input by setting the widget sensitivity.
+
+The standard graphical widgets to perform this are text fields, but several other widgets can be used:
+* A combo-box so that the interface can suggest different values.
+* A label if the text only need to be output.
+
+{{note| '''Note''': customized, specific widgets can be defined, you can for instance take a look at the DV_STRING_LIST class. }}
+
+===5.3. DV_SENSITIVE_INTEGER class===
+
+This class lets a model class input or output an INTEGER value graphically. As for controllers, the model class lets the user know when an integer value can be input by setting the widget sensitivity.
+
+Different widgets can be used to implement this:
+* A text field. Notice that the value entered should be checked to ensure it is an INTEGER value.
+* A combo-box. Each combo-box option is associated to an integer.
+* A scroll button.
+
+===5.4. DV_SENSITIVE_CHECK class===
+
+This class lets a model class input or output a BOOLEAN value graphically. As for controllers, the model class lets the user know when a Boolean value can be input by setting the widget sensitivity.
+
+The standard widget to implement this is a check box.
+
+===5.5. DV_TABLEROW_LIST class===
+
+The [[ref:libraries/store/reference/dv_tablerow_list_chart|DV_TABLEROW_LIST]] class provides an interface to display a set of table rows so that the user can select a particular row.
+* The model can be informed of a row selection or deselection: the class accepts actions (implemented by ''agents'') that are triggered when a row is selected or deselected.
+* The model can retrieve the currently selected row: the class yields the current index position in the list.
+
+[[ref:libraries/store/reference/dv_tablerow_multilist_chart|DV_TABLEROW_MULTILIST]] implements DV_TABLEROW_LIST with an EiffelVision2 multi-column list.
+
+{{note| '''Note''': This class is used for the [[#dv_control_navigator|standard implementation]] of [[ref:libraries/store/reference/dv_tablerows_navigator_chart|DV_TABLEROW_NAVIGATOR]] to [[#dv_tablerow_navigator|navigate among table rows]] selected from the database. }}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-creation.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-creation.wiki
new file mode 100644
index 00000000..2c0ee4df
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-creation.wiki
@@ -0,0 +1,654 @@
+[[Property:title|Data structures creation]]
+[[Property:weight|1]]
+==1. Overview==
+
+EiffelStore enables to create data structures mapped to your own database. This part describes how the EiffelStore wizard generates these structures mapped to your database and how you can map your own classes to your database with EiffelStore.
+
+'''Tip:''' We recommend that you read [[Data structures use|what are and how to use]] these data structures before reading this section.
+
+The EiffelStore wizard generates the database-specific classes from an EiffelStore generation system based on template files containing tags.
+
+Let us see first [[#generation_system| how the EiffelStore generation system works]] . Let us see then [[#wizard_generation| how the EiffelStore wizard uses this system]] for the data structures generation.
+
+==2. EiffelStore generation system==
+
+This part describes the class creation in 4 steps:
+* [[#capabilities|Mapping system possibilities]]
+* [[#mapping_system|General mapping system]]
+* [[#tags_descr|Tags description]]
+* [[#gen_impl_overview|Implementation overview]]
+
+===2.1. Capabilities===
+
+Let us see first what information you can map into your classes.
+2 kinds of classes can be generated:
+* Classes that represents a database table.
+* Classes that represents the whole database.
+
+====2.1.1. Database table classes====
+
+You can insert information about a database table:
+* The table name
+* The number of attributes of table
+
+You can also select a piece of code, map it to a table attribute and repeat the operation for every attribute. Information that can be inserted is:
+* The attribute names
+* The attribute types
+* The attribute default creation values
+* The attribute positions in the table
+
+Thus you can get for instance class attributes that correspond to database attributes:
+
+
+ class CONTACTS
+
+ feature
+
+ id: INTEGER
+
+ lastname: STRING
+
+ firstname: STRING
+
+
+
+You can also modify the piece of code to map for the first and last attributes, for cosmetics reasons. You can also choose to only map a piece of code to attributes of a given type.
+
+====2.1.2. Database content classes====
+
+Database content classes can basically store the list of your database tables.
+
+You can select a piece of code and map it to database table information:
+* Database table name.
+* Database table position in the database.
+
+The mapped pieces of code are then concatenated in your file.
+
+===2.2. General mapping system===
+
+EiffelStore follows this sequence of steps to generate a class:
+# You provide meta-data about the table or view
+# You provide the template
+# It parses the template to find the tags
+# It replaces each tag by the meta-data value corresponding to the tag
+
+Let us take an example:
+{| border="1"
+|-
+| template file extract
+| corresponding result file extract
+|-
+| attribute_count:
+| attribute_count: 5
+|}
+
+This works for meta-data on the class or view. For meta-data on class (or view) attributes, a second tag type enables to specify text areas that are mapped to specific table (or view) attributes.
+
+Let us take an example:
+{| border="1"
+|-
+| template file extract
+| corresponding result file extract
+|-
+| :
+
+| companyid: DOUBLE
+companyname: STRING
+|}
+
+Text contained in the tag 'A' is mapped to each table (or view) attribute and the resulting texts are concatenated. Let us see now the details about each tag.
+
+===2.3. Tags description===
+
+====2.3.1. Database table tags description====
+
+The available tags for database table classes generation can be separated into 3 types:
+* Tags corresponding to [[#table_meta-data|table meta-data]]
+* Tags corresponding to [[#attribute_meta-data|attribute meta-data]]
+* Tags to [[#enclosing_tag|enclose attribute meta-data]]
+
+=====2.3.1.1. Table meta-data tags=====
+{| border="1"
+|-
+| '''Tag name'''
+| '''Tag description'''
+| '''Options'''
+|-
+| '''Option name'''
+| '''Option description'''
+|-
+|
+| Table name
+| U
+| in uppercase
+|-
+| I
+| with initial capital
+|-
+| L
+| in lowercase
+|-
+|
+| Attribute count
+| N/A
+|}
+
+=====2.3.1.2. Attribute meta-data tags=====
+{| border="1"
+|-
+| '''Tag name'''
+| '''Tag description'''
+| '''Options'''
+|-
+| '''Option name'''
+| '''Option description'''
+|-
+|
+| Attribute name
+| U
+| in uppercase
+|-
+| I
+| with initial capital
+|-
+| L
+| in lowercase
+|-
+|
+| Attribute position in the table
+| N/A
+|-
+|
+| Attribute type name
+| U
+| in uppercase
+|-
+| I
+| with initial capital
+|-
+| L
+| in lowercase
+|-
+|
+| Attribute type default value
+| N/A
+|}
+
+'''Note''': Attribute tags are only valid within an enclosing tag.
+
+=====2.3.1.3. Enclosing tags=====
+
+The tag encloses text that will be mapped to attributes matching criteria. These criteria are specified by the tag options:
+* First option: attribute type criterion
+{| border="1"
+|-
+| '''Option name'''
+| '''Option description'''
+|-
+| A
+| All attributes
+|-
+| I
+| INTEGER attributes
+|-
+| S
+| STRING attributes
+|-
+| D
+| DATE attributes
+|-
+| B
+| BOOLEAN attributes
+|-
+| C
+| CHARACTER attributes
+|-
+| F
+| DOUBLE attributes
+|}
+
+* Second option: attribute position criterion
+{| border="1"
+|-
+| '''Option name'''
+| '''Option description'''
+|-
+| A
+| All attributes
+|-
+| F
+| First attribute
+|-
+| I
+| Intermediate attributes
+|-
+| L
+| Last attribute
+|}
+
+* '''Note''': this option is generally used to have a valid and nice layout or indentation.
+
+'''Note''': several options can be selected for one criterion.
+
+====2.3.2. Database content tags description====
+
+The tags described above can be reused for database content:database content class mapping is equivalent to the previous mapping but within a different scope:
+* class corresponds to the database rather than tables
+* class content deals with tables rather than table attributes
+
+The meaning of available tags is so modified:
+* [[#system_meta-data_ext|System meta-data tags]]
+* [[#table_meta-data_ext| Table meta-data tags]]
+* [[#enclosing_tag_ext| Enclosing tags]]
+
+'''Note''': every tag is not available for this mapping.
+
+=====2.3.2.1. System meta-data tags=====
+{| border="1"
+|-
+| '''Tag name'''
+| '''Tag description'''
+|-
+|
+| Table count
+|}
+
+=====2.3.2.2. Table meta-data tags=====
+{| border="1"
+|-
+| '''Tag name'''
+| '''Tag description'''
+| '''Options'''
+|-
+| '''Option name'''
+| '''Option description'''
+|-
+|
+| Table name
+| U
+| in uppercase
+|-
+| I
+| with initial capital
+|-
+| L
+| in lowercase
+|-
+|
+| Table position in the database
+| N/A
+|}
+
+=====2.3.2.3. Enclosing tags=====
+
+The tag encloses text that will be mapped to tables matching a position criterion. This criterion is specified by the tag options:
+{| border="1"
+|-
+| '''Option name'''
+| '''Option description'''
+|-
+| A
+| All tables
+|-
+| F
+| First table
+|-
+| I
+| Intermediate tables
+|-
+| L
+| Last table
+|}
+
+===2.4. Implementation overview===
+
+The data structure generation system is implemented with 4 EiffelStore classes:
+* DB_CLASS_GENERATOR abstractly generates a class mapped to database meta-data.
+* DB_TABLE_CLASS_GENERATOR generates a class mapped to a database table.
+* DB_ACCESS_CLASS_GENERATOR generates a class mapped to the database.
+* DB_TEMPLATE_TAGS defines available tags for mapping and their meaning.
+
+[[Image:estore-generation.generator]]
+
+Generation classes BON diagram
+
+==3.EiffelStore wizard==
+
+The EiffelStore wizard uses the [[#generation_system| EiffelStore generation system]] described above to generate the data structures mapped to your database.
+
+The wizard generates 3 types of classes:
+* [[#wiz_table_classes|Classes storing database table rows content]]
+* [[#wiz_descr_classes|Classes describing a database table]]
+* [[#wiz_access_class|A class describing the database and giving access to the previous types of classes]]
+
+The wizard uses one different template for each class.
+===3.1. Table classes===
+
+For each selected database table, a class is created from the same template, mapping the database table. This template is:
+
+ indexing
+ description: "Class which allows EiffelStore to retrieve/store%
+ %the content of a table row from database table "
+ author: "EiffelStore Wizard"
+ date: "$Date: 2004-12-09 23:29:16 +0100 (Thu, 09 Dec 2004) $"
+ revision: "$Revision: 46989 $"
+
+ class
+
+
+ inherit
+ DB_TABLE
+ -- redefine
+ -- out
+ -- end
+ undefine
+ Tables,
+ is_valid_code
+ end
+
+ DB_SPECIFIC_TABLES_ACCESS_USE
+
+ create
+ make
+
+ feature -- Access
+
+ :
+
+ table_description: DB_TABLE_DESCRIPTION is
+ -- Description associated to the .
+ do
+ tables._description.set_ (Current)
+ Result := tables._description
+ end
+
+ feature -- Initialization
+
+ set_default is
+ do
+ :=
+
+ end
+
+ feature -- Basic operations
+
+ set_ (a_: ) is
+ do
+ := a_
+ end
+
+ feature -- Output
+
+ out: STRING is
+ -- Printable representation of current object.
+ do
+ Result := ""
+
+ if /= Void then
+ Result.append (": " + .out + "%N")
+ end
+
+ end
+
+ end -- class CODES
+
+
+
+'''Note''': the template content can be adjusted, for instance to add comments or change the indexing. However, the fundamental template structure should not be changed to use data structures as described in the [[Data structures use|corresponding section]] .
+
+===3.2. Description classes===
+
+For each selected database table, a class is also created from a unique template, mapping the database table. This template is:
+
+ indexing
+ description: "Description of class "
+ author: "EiffelStore Wizard"
+ date: "$Date: 2004-12-09 23:29:16 +0100 (Thu, 09 Dec 2004) $"
+ revision: "$Revision: 46989 $"
+
+ class
+ _DESCRIPTION
+
+ inherit
+ DB_TABLE_DESCRIPTION
+ -- rename
+ -- Tables as Abstract_tables
+ undefine
+ Tables,
+ is_valid_code
+ end
+
+ DB_SPECIFIC_TABLES_ACCESS_USE
+
+ create
+ {DB_SPECIFIC_TABLES_ACCESS} make
+
+ feature -- Access
+
+ Table_name: STRING is ""
+
+ Table_code: INTEGER is
+
+ Attribute_number: INTEGER is
+ -- Number of attributes in the table.
+
+ Id_code: INTEGER is
+ -- Table ID attribute code.
+ do
+ Result :=
+ end
+
+ : INTEGER is
+
+ attribute_code_list: ARRAYED_LIST [INTEGER] is
+ -- Feature code list
+ once
+ create Result.make (Attribute_number)
+ Result.extend ()
+ end
+
+ description_list: ARRAYED_LIST [STRING] is
+ -- Feature name list. Can be interpreted as a list
+ -- or a hash-table.
+ once
+ create Result.make (Attribute_number)
+ Result.extend ("")
+ end
+
+ type_list: ARRAYED_LIST [INTEGER] is
+ -- Feature type list. Can be interpreted as a list
+ -- or a hash-table.
+ once
+ create Result.make (Attribute_number)
+ Result.extend (_type)
+ end
+
+ to_delete_fkey_from_table: HASH_TABLE [INTEGER, INTEGER] is
+ -- List of tables depending on this one and their
+ -- foreign key for this table.
+ -- Deletion on this table may imply deletions on
+ -- depending tables.
+ once
+ end
+
+ to_create_fkey_from_table: HASH_TABLE [INTEGER, INTEGER] is
+ -- List of associated necessary tables and the
+ -- linking foreign keys.
+ -- Creation on this table may imply creations on
+ -- associated necessary tables.
+ once
+ end
+
+ attribute (i: INTEGER): ANY is
+ -- Get feature value of feature whose code is 'i'.
+ do
+ inspect i
+
+ when then
+ Result := .
+
+ end
+ end
+
+ set_attribute (i: INTEGER; value: ANY) is
+ -- Set feature value of feature whose code is `i' to `value'.
+ -- `value' must be of type STRING, INTEGER, BOOLEAN, CHARACTER,
+ -- DOUBLE or DATE_TIME. References are made automatically from
+ -- expanded types.
+ local
+ integer_value: INTEGER_REF
+ double_value: DOUBLE_REF
+ boolean_value: BOOLEAN_REF
+ character_value: CHARACTER_REF
+ date_time_value: DATE_TIME
+ string_value: STRING
+ do
+ inspect i
+
+ when then
+ string_value ?= value
+ .set_ (string_value)
+ when then
+ double_value ?= value
+ if double_value /= Void then
+ .set_ (double_value.item)
+ else
+ .set_ (0.0)
+ end
+
+ when then
+ integer_value ?= value
+ if integer_value /= Void then
+ .set_ (integer_value.item)
+ else
+ .set_ (0)
+ end
+
+ when then
+ date_time_value ?= value
+ .set_ (date_time_value)
+
+ when then
+ character_value ?= value
+ if character_value /= Void then
+ .set_ (character_value.item)
+ else
+ .set_ ('%U')
+ end
+
+ when then
+ boolean_value ?= value
+ if boolean_value /= Void then
+ .set_ (boolean_value.item)
+ else
+ .set_ (False)
+ end
+
+ end
+ end
+
+ feature {} -- Basic operations
+
+ set_ (a_: ) is
+ -- Associate the description to a piece of .
+ require
+ not_void: a_ /= Void
+ do
+ := a_
+ ensure
+ = a_
+ end
+
+ feature {NONE} -- Implementation
+
+ :
+ -- Piece of associated with the description
+
+ end -- class CODES_DESCRIPTION
+
+
+'''Note''': As for the table class generation, the template content can be adjusted, for instance to add comments or change the indexing. However, the fundamental template structure should not be changed.
+
+Some additional tags are directly replaced by the wizard:
+* The and tags are replaced with information on associated tables.
+* The tag is replaced by information on the primary key (table ID).
+* The tag is replaced by the table position in the database.
+
+===2.3.3. Access class===
+
+The DB_SPECIFIC_TABLES_ACCESS class is mapped to the database from the following template:
+
+ indexing
+ description: "Description of database tables.%
+ %Use this class through DB_SPECIFIC_TABLES_ACCESS_USE."
+ author: "EiffelStore Wizard"
+ date: "$Date: 2004-12-09 23:29:16 +0100 (Thu, 09 Dec 2004) $"
+ revision: "$Revision: 46989 $"
+
+ class
+ DB_SPECIFIC_TABLES_ACCESS
+
+ inherit
+ DB_TABLES_ACCESS
+
+ creation
+ make
+
+ feature -- Access
+
+ : INTEGER is
+
+ Table_number: INTEGER is
+
+ code_list: ARRAYED_LIST [INTEGER] is
+ -- Table code list.
+ once
+ create Result.make (Table_number)
+ Result.extend ()
+ end
+
+ name_list: ARRAYED_LIST [STRING] is
+ -- Table name list. Can be interpreted as a list
+ -- or a hash-table.
+ once
+ create Result.make (Table_number)
+ Result.extend ("")
+ end
+
+ obj (i: INTEGER): DB_TABLE is
+ -- Return instance of table with code `i'.
+ do
+ inspect i
+
+ when then
+ create {} Result.make
+
+ end
+ end
+
+ description (i: INTEGER): DB_TABLE_DESCRIPTION is
+ -- Return description of table with code `i'.
+ do
+ inspect i
+
+ when then
+ Result := _description
+
+ end
+ end
+
+ _description: _DESCRIPTION is
+ -- Unique description of table `'.
+ once
+ create Result.make
+ end
+
+
+
+ end -- class DB_SPECIFIC_TABLES_ACCESS
+
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki
new file mode 100644
index 00000000..5d706f72
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki
@@ -0,0 +1,222 @@
+[[Property:title|Data structures use]]
+[[Property:weight|0]]
+==1. Overview==
+
+EiffelStore affords a context that optimizes and facilitates the use of the classes that maps your database content.
+
+The main advantage of database-specific structures is the static checking: you can determine at compile-time the type of information you are accessing or modifying.
+
+However, it can be more flexible to determine the type of data you are dealing with at run-time. This can be particularly useful for GUI applications, take a look at the [[EiffelStore DataView Cluster|DataView cluster]] .
+
+Each data structure carries some meta-data about its type so that the run-time typing hazards can be avoided with assertions based on this meta-data.
+
+The advantage of this system is two-fold:
+* You can choose to use compile-time type checking or not, depending on your own needs.
+* If you choose run-time type checking, assertions ensure that each object type is valid and prevent cat calls.
+
+Let us see first [[#capabilities|what you can do]] with data structures and their context, then [[#implementation|how it is implemented]] .
+
+==2. Data structure capabilities==
+
+Database-specific classes and their context let you perform the following operations:
+* [[#cap_storage|Storing table/view rows content]]
+* [[#cap_manipulation|Manipulating abstract table/view rows content]]
+* [[#cap_objects_metadata|Getting objects metadata]]
+* [[#cap_database_metadata|Accessing database metadata]]
+* [[#cap_more|More interesting features]]
+
+===2.1. Storing table/view rows content===
+
+You can store table/view rows content into classes that have the table or view name: one database table/view row correspond to one Eiffel object. Each table attribute will correspond to a class attribute with the same name. ''set'' commands enable to change the object content to insert rows in the database or update rows. [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class can directly map database results into these objects, and you can directly create a table/view row from one object with the [[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] class. Take a look at the [[Data Object Coupling|data-object coupling]] section.
+
+===2.2. Manipulating abstract table/view rows content===
+
+Each table/view storage structure inherits from the [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] abstract class. This enables to handle [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] objects as abstract database table/view structures.
+
+You can then access or modify [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] attributes: instead of accessing attributes with their ''name'', which implies that the object type is known at compile-time, attributes can then be accessed with a ''code''.
+
+ tablerow: DB_TABLE
+ ...
+ display_attribute (code: INTEGER) is
+ -- Display attribute with `code'.
+ do
+ io.putstring (tablerow.table_description.attribute (code).out)
+ end
+
+
+{{note| '''Note:''' to access attributes data with ''code'', you need to use the [[ref:/libraries/store/reference/db_table_description_flatshort|DB_TABLE_DESCRIPTION]] object associated to your [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] object. }}
+
+===2.3. Getting objects metadata===
+
+While manipulating DB_TABLE objects, you can easily get:
+* Which database table/view the object references.
+* What are the types of its attributes.
+
+'''Note:''' you also get objects metadata through the DB_TABLE_DESCRIPTION object associated to your DB_TABLE object.
+Objects metadata used in assertions ensures objects type validity. To illustrates this, let's look at the contract form of a class that manipulates "abstract" table/view rows:
+
+ set_table_code (code: INTEGER)
+ -- Assign `code' to `tablecode'.
+
+ tablecode: INTEGER
+ -- Table code.
+
+ compute (tablerow: DB_TABLE)
+ -- Compute `tablerow'.
+ require
+ type_is_ok: tablerow.table_description.Table_code = tablecode
+
+
+===2.4. Accessing database metadata===
+
+Basic database metadata is also available: the DB_SPECIFIC_TABLES_ACCESS_USE class (generated), stores INTEGER codes for each database table/view. These codes afford related table/view name and related new storing objects (i.e. that conforms to DB_TABLE class).
+
+ tables: DB_SPECIFIC_TABLES_ACCESS
+ ...
+ new_object (code: INTEGER): DB_TABLE is
+ -- New object of table with `code'.
+ do
+ Result := tables.obj (code)
+ end
+
+
+===2.5. More interesting features===
+
+The DB_TABLE_DESCRIPTION class offers more features to get table row attributes as conveniently as possible:
+* The table/view row primary key value (ID)
+* The list of table/view row attributes
+* A selection of table/view row attributes
+* The list of table/view row attributes mapped to a function.
+* Printable attribute values (i.e. the associated STRING values)
+
+==3. Implementation==
+
+Database-specific classes can be divided into 3 types:
+* Classes holding database table rows content (inheriting from DB_TABLE)
+* Classes describing database tables (inheriting from DB_TABLE_DESCRIPTION)
+* A class describing the database and giving access to the previous types of classes (inheriting from DB_TABLES_ACCESS)
+
+One database table is hence associated to one table class and one description class. Both classes are closely [[#table-descr_relationship| interrelated]] to provide what the developer need. The [[#table_access_classes|table access classes]] describes the database tables and gives access to both table and description classes.
+
+Each database-specific (generated) class inherits from an abstract class. These abstract classes gathers all the facilities that are not specific to your database, and so that can be inherited by all the database-specific classes.
+
+Let us see abstract and database-specific classes relationship:
+
+[[Image:tables-access-inherit]]
+
+General and generated classes relationships
+* Yellow classes are abstract.
+* Green classes are database-specific.
+
+==2. Table and description classes relationship==
+
+Table classes, that inherit from DB_TABLE, and description classes, that inherit from DB_TABLE_DESCRIPTION, both deals with database tables. This section explains what are their own role and their relationship.
+
+===2.1. Table classes===
+
+As seen in the previous section, table classes merely store table rows attribute values. Their objects can be considered as database table rows, or more precisely, database table rows on the Eiffel side. These classes inherit from DB_TABLE.
+
+Each of these classes are associated to a description class.
+
+'''Tip:''' Use table classes to ''carry'' data.
+
+===2.2. Description classes===
+
+The description classes goal is 3-fold:
+* [[#cap_objects_metadata|Getting meta-data]] about the table represented at run-time.
+* [[#cap_manipulation|Getting table rows data]] dynamically.
+* [[#cap_more|Facilitating data management]] .
+
+These descriptions inherit from [[ref:libraries/store/reference/db_table_description_flatshort|DB_TABLE_DESCRIPTION]] .
+
+Since they only describes a table and provide tools, description objects can be unique. EiffelStore ensures their unicity for resources optimization.
+
+'''Tip:''' Use description classes to ''access and modify'' data.
+
+===2.3. Relationship===
+
+Each table class is associated to the description class corresponding to the same database table.
+
+A table class object provides the associated table description:
+
+
+ row: DB_TABLE
+ description: DB_TABLE_DESCRIPTION
+ ...
+ row := db_manager.database_result
+ description := row.table_description
+
+
+As descriptions are unique, every table row object is associated to the same description. The following figure illustrates this:
+[[Image:table-descr-objects]]
+
+table and description objects relationship
+
+As seen in the previous section, to manipulate abstract table/view rows content, you have to use the description class. The following example shows how to output a table row ID value.
+
+
+ row: DB_TABLE
+ description: DB_TABLE_DESCRIPTION
+ ...
+ -- Link description unique object to `row' content.
+ description := row.table_description
+ io.putstring (description.attribute (description.id_name) + ": ")
+ io.putstring (description.attribute (description.id_code).out)
+
+
+
+As descriptions are unique, this means that description objects are also associated to a specific table object to deal with it (i.e. access or modify its content). Actually, the table_description feature associates the description with the current object and then returns this description.
+
+{{note| '''Note:''' The table_description feature is still a query as the association part should not be visible at the interface level. }}
+
+On the whole, you have to pay attention to always execute table_descriptionon your table/view row to get the appropriate description.
+
+==3. Table access classes==
+
+===3.1. Overview===
+
+Table access classes provide facilities to manage table row and table description objects. They also give basic database table meta-data.
+
+The following figure shows table access classes and their relations.
+* Yellow classes are EiffelStore classes
+* Green class is generated
+* Pink class is an application class
+
+[[Image:db-specific-tables-access-use]]
+
+Table access classes BON diagram
+
+[[Image:table-descr-access-objects]]
+
+Relationship between the tables access object, description and table objects
+
+===3.2. DB_SPECIFIC_TABLES_ACCESS class===
+
+The DB_SPECIFIC_TABLES_ACCESS class stores the unique table description object. It also provides the following facilities:
+* Every database table code
+* Table descriptions from a table code
+* Sample table class objects from a table code
+* Table names from a table code
+
+'''Note''': database table codes given in the class match the table codes provided by DB_TABLE_DESCRIPTION.
+
+===3.3. Abstract access class===
+
+The DB_TABLES_ACCESS class provides an interface for the DB_SPECIFIC_TABLES_ACCESS class which is non-specific to the database. This can be used by non database-specific code (for instance the [[EiffelStore DataView Cluster|DataView cluster]] ) to access database tables.
+
+Unique table description objects and table codes are of course not directly available from this class, but the following features are still available:
+* Table descriptions from a table code
+* Sample table class objects from a table code
+* Table names from a table code
+
+===3.4. Use classes===
+
+The DB_SPECIFIC_TABLES_ACCESS object can be accessed as a kind of "global variable" by any class which inherits from DB_SPECIFIC_TABLES_ACCESS_USE. This class also ensures DB_SPECIFIC_TABLES_ACCESS object unicity.
+
+The DB_TABLES_ACCESS_USE class affords the same possibility but with no reference to the DB_SPECIFIC_TABLES_ACCESS object. The unique DB_SPECIFIC_TABLES_ACCESS should be set to this class as of type DB_TABLES_ACCESS.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/index.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/index.wiki
new file mode 100644
index 00000000..d67d639c
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|EiffelStore Generation Cluster]]
+[[Property:weight|2]]
+The EiffelStore library lets the user associate database elements with Eiffel objects. These database elements are basically database table rows, database view rows or more generally sets of database attribute values. The easiest way to manipulate database elements is to insert their content into Eiffel objects and to work on these Eiffel objects as database elements.
+
+A first solution to implement this is to use some adaptable structures that will fit to any database element. This is done in EiffelStore through the [[ref:libraries/store/reference/db_tuple_flatshort|DB_TUPLE]] class, which contains mainly an [[ref:libraries/base/reference/array_chart|ARRAY]] [[[ref:libraries/base/reference/string_8_chart|STRING]] ] containing element attribute names and an [[ref:libraries/base/reference/array_chart|ARRAY]] [[[ref:libraries/base/reference/any_chart|ANY]] ] containing element attribute values. This solution has one major drawback: any static checking is impossible: the developer cannot be sure at compile time of the nature of a [[ref:libraries/store/reference/db_tuple_flatshort|DB_TUPLE]] , i.e. what it represents, and cannot know if attributes number, names and types are correct. To overcome this problem, a second solution is to use data structures that statically fits to the expected database element, as introduced in the [[Data Object Coupling|DataObject Coupling]] section.
+
+The major problem of this technique is that structures are static: one structure, so one class instead of one object, should be created for each database element.
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki
new file mode 100644
index 00000000..937146dd
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki
@@ -0,0 +1,91 @@
+[[Property:title|EiffelStore Implementation Layer]]
+[[Property:weight|1]]
+Each interface class has an implementation counterpart that implements specific DBMS handling. The class prefix indicates clearly its layer, for instance:
+* [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] is the interface to perform a database selection query.
+* [[ref:/libraries/store/reference/database_selection_flatshort|DATABASE_SELECTION]] [[[ref:/libraries/store/reference/database_flatshort|DATABASE]] ] is its implementation.
+
+The abstract [[ref:/libraries/store/reference/database_flatshort|DATABASE]] class represents a DBMS, i.e. it is the Eiffel-side database call interface. It is inherited for instance by the instantiable ORACLE and ODBC classes.
+
+EiffelStore enables to link common interface objects with database-specific implementation objects using a '''handle'''. This handle also enables to switch between different databases.
+
+Let us see in 4 steps how EiffelStore implements this handle system:
+* The [[#handle|active database handle]] .
+* The [[#association|association between interface and implementation]] objects.
+* The [[#access|access to the DBMS call interface]] from the implementation layer.
+* The [[#selection|active database selection]] from the database application.0
+
+==The active database handle==
+
+The HANDLE_USE class provides access to the unique HANDLE instance. This object stores all the information about the active database, mainly:
+* Database login information:
+
+ login: LOGIN [DATABASE]
+ -- Session login
+
+
+* Database status information:
+
+ status: DB_STATUS
+ -- Status of active database
+
+
+
+==Association between interface and implementation==
+
+The association between an interface object and its implementation counterpart is done at the interface object creation.
+
+Every interface class inherits from the HANDLE_USE class and can access the active database handle. This handle contains a DB [DATABASE] object that provides implementation objects corresponding to every interface objects.
+
+The creation procedure for a DB_CHANGE object is for instance:
+
+ make is
+ -- Create an interface object to change active base.
+ do
+ implementation := handle.database.db_change
+ create ht.make (name_table_size)
+ implementation.set_ht (ht)
+ end
+
+
+==Access to the DBMS call interface==
+
+Every implementation class can access the active database call interface by inheriting from the HANDLE_SPEC [DATABASE] class. This class provides access to the DATABASE object, i.e. an instance of class ORACLE or ODBC.
+
+DATABASE descendants are actually wrappers for the DBMS call interfaces written in C. More precisely, call interfaces as delivered by the DBMS companies are called in an EiffelStore C library. The C libraries are then wrapped into Eiffel classes, DATABASE descendants.
+
+==Active database selection==
+
+As seen in the [[Database Connection|interface connection]] part, active database selection is performed by the {DATABASE_APPL}.set_base feature: when a DATABASE_APPL object calls set_base, database represented by this object is activated.
+
+Let us give some details about the set_base feature:
+* Database call interface global reference is updated through {HANDLE_SPEC}.update_handle.
+* All information about the database is set to the handle, mainly:
+** Login information.
+** Status information.
+
+{{note| '''Note''': When database is inactive, its information is stored in the DATABASE_APPL object. }}
+
+
+The corresponding code looks like:
+
+ session_status: DB_STATUS
+ -- A session management object reference.
+ ...
+ set_base is
+ ...
+ update_handle
+ if session_status = Void then
+ create session_status.make
+ end
+ handle.set_status (session_status)
+ ...
+
+
+{{seealso| '''See Also'''
+[[EiffelStore Interface Layer|The interface layer]]
+}}
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki
new file mode 100644
index 00000000..923f1938
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Data Modification]]
+[[Property:weight|1]]
+Use the [[ref:/libraries/store/reference/db_change_flatshort|DB_CHANGE]] class to perform any operation on your database that does not require access to a result. You can for instance modify table row content, drop table rows, create and delete tables.
+
+{{note| '''Note''': Take a look at the [[Data Object Coupling|Data Storing]] capability if you want to '''insert''' table rows. }}
+
+[[ref:/libraries/store/reference/db_change_flatshort|DB_CHANGE]] allows you to modify the database data using the SQL language:
+* Prepare your SQL query and use modify:
+
+ modification: DB_CHANGE
+ -- Modification tool.
+ ...
+ create modification.make
+ modification.modify("Update CONTACTS set Firstname = ' John'")
+
+
+* Commit your changes with your session control:
+
+ session_control: DB_CONTROL
+ -- Session control.
+ ...
+ session_control.commit
+
+
+{{tip| '''Tip''': It is always better to check the database status for errors before committing changes. }}
+
+
+{{seealso| '''See Also'''
+[[Data Object Coupling|Data storing]]
+[[Stored Procedures|Stored procedures]]
+[[EiffelStore Implementation Layer|Implementation]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki
new file mode 100644
index 00000000..4e678279
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki
@@ -0,0 +1,91 @@
+[[Property:title|Data Object Coupling]]
+[[Property:weight|4]]
+A smart way to work with relational databases is to have Eiffel objects directly mapping relational tables. Three EiffelStore classes enable this coupling:
+* [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects [[#describe|describe a relational table]] and allow Eiffel to create objects mapping database tables.
+* [[ref:/libraries/store/reference/db_store_flatshort|DB_STORE]] works directly with [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects to [[#insert|insert data into relational tables]] .
+* [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can [[#map|map a database query result into Eiffel objects]] .
+
+==Describing relational tables with DB_REPOSITORY==
+
+A [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] object stores available information about a table. To access this information, you mainly have to give the table name and load the table description:
+
+ repository: DB_REPOSITORY
+ ...
+ create repository.make ("CONTACTS")
+ repository.load
+ if repository.exists then
+ ...
+ end
+
+
+{{tip| '''Tip''': Loading a table description is often a costly operation: table has to be fetched among existing tables then every table column description must be loaded. Hence it is better to store and reuse a repository (maybe with a HASH_TABLE) once it has been loaded. }}
+
+Using the table information, [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] then helps generating Eiffel classes mapping relational tables:
+* You can directly use {[[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] }.generate_class. Generated class may look like:
+
+ class CONTACTS
+
+ feature -- Access
+
+ id: INTEGER
+ ...
+ feature -- Settings
+
+ set_id (an_id: INTEGER) is
+ -- Set an_id to id.
+ do
+ id := an_id
+ end
+ ...
+
+
+{{note| '''Note''': The EiffelStore Wizard uses the generation.generator cluster to generate the classes mapped to your database. }}
+
+
+==Inserting data in the database==
+
+[[ref:/libraries/store/reference/db_store_flatshort|DB_STORE]] lets you easily insert rows into a table using:
+* the table description provided by [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] .
+* a class mapping the relational table.
+This is straight-forward since you only have to give [[ref:/libraries/store/reference/db_store_flatshort|DB_STORE]] the object filled with the table values. Suppose you want to add a contact into your database:
+
+ storage: DB_STORE
+ contacts_rep: DB_REPOSITORY
+ a_contact: CONTACTS
+ ...
+ create storage.make
+ -- contacts_rep is loaded and exists.
+ storage.set_repository (contacts_rep)
+ -- a_contact carries values to insert into the database.
+ storage.put (a_contact)
+
+
+==Accessing database content with Eiffel objects==
+
+[[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] lets you map data retrieved from the database into Eiffel objects: Result column names must match object attributes names so you can use for instance classes created by [[ref:/libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . Class DB_ACTION redefines ACTION and can be used to retrieve Eiffel objects directly into an ARRAYED_LIST:
+
+ selection: DB_SELECTION
+ list_filling: DB_ACTION [CONTACTS]
+ contact: CONTACTS
+ ...
+ selection.object_convert (contact)
+ create list_filling.make (selection, contact)
+ selection.set_action (list_filling)
+ ...
+ selection.load_result
+ if selection.is_ok then
+ Result := list_filling.list
+ end
+
+
+{{note| '''Note''': You can see how actions are used in [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] . }}
+
+
+{{seealso| '''See Also'''
+[[Database Selection|Performing a database selection.]]
+[[Data structures use|Database-specific structures use.]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-connection.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-connection.wiki
new file mode 100644
index 00000000..afddf4a5
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-connection.wiki
@@ -0,0 +1,38 @@
+[[Property:title|Database Connection]]
+[[Property:weight|0]]
+# To connect to your database, you have to create a '''handle''': this handle actually links the interface classes with corresponding implementation classes mapped to your DBMS. This handle is implemented by the DATABASE_APPL class:
+
+ database_appl: DATABASE_APPL [ODBC]
+ -- Database handle.
+ ...
+ create database_appl.login (a_name, a_psswd)
+ database_appl.set_base
+
+
+
+{{note| '''Note''': Calling set_base links the EiffelStore interface to this specific handle. }}
+
+{{tip| '''Tip''': You can manage handles to many databases: as an instance of DATABASE_APPL stands for a specific database handle, you only have to create one instance of DATABASE_APPL for every DBMS handle you wish to create. Do not forget to call set_base to activate appropriate handle. }}
+
+{{note| '''Note''': The generic parameter of DATABASE_APPL specifies the actual DBMS used. }}
+
+# Once your handle is created, you have to create a session manager which will allow you to manage your database, specifically to establish connection, disconnect and also handle errors. The class DB_CONTROL enables your application to plainly control the functioning and status of your database and to request any information about it.
+
+ session_control: DB_CONTROL
+ -- Session control.
+ ...
+ create session_control.make
+ session_control.connect
+
+
+{{note| '''Note''': Take a look at the [[Database control|database control]] part to see how to use DB_CONTROL capabilities. }}
+
+
+{{seealso| '''See Also'''
+[[Database control|Database control and error handling]]
+[[EiffelStore Implementation Layer|Implementation]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki
new file mode 100644
index 00000000..1b8414af
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki
@@ -0,0 +1,68 @@
+[[Property:title|Database control]]
+[[Property:weight|7]]
+Use the [[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] class to check or change database status and behavior. The main operations you are likely to use are:
+* [[#errors|Handling]] database errors.
+* [[#connection|Connecting]] to the database.
+* [[#commit|Committing]] changes in the database.
+
+==Handling database errors==
+
+Every EiffelStore interface class has an is_ok feature. This enables to check directly if the last database operation has been successful.
+
+When an error is detected, you can access through [[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] further information about the error:
+* error_message provides a description of the error that occurred.
+* error_code returns a code corresponding to the error type. This code enables to handle specific errors within your code without parsing the error_message.
+* warning_message provides a warning message about the last transaction performed.
+
+Once you have handled your error, for instance by displaying the error_message on screen, you can call reset to perform new database transactions.
+
+==Managing database connection==
+
+[[ref:/libraries/store/reference/db_control_flatshort|DB_CONTROL]] lets you connect, check connection and disconnect from the database.
+
+The following example sum up these capabilities:
+
+ session_control: DB_CONTROL
+ ...
+ session_control.connect
+ if session_control.is_connected then
+ -- Perform your transactions here.
+ session_control.disconnect
+ end
+
+
+==Committing changes in the database==
+
+Every modification you do in the database are usually not directly saved. This enables to limit damage caused by mishandlings. You can then manage database modification through 2 commands:
+* ''Commit'' saves the changes in the database.
+* ''Rollback'' restores the database content corresponding to last commitment.
+
+The following example illustrates the use of these commands:
+
+ session_control: DB_CONTROL
+ ...
+ from
+ until
+ transaction_completed or else not session_control.is_ok
+ loop
+ -- Perform your transaction here.
+ end
+ if session_control.is_ok then
+ session_control.commit
+ else
+ session_control.rollback
+ end
+
+
+The loop performs a multi-step transaction. If transaction is not carried out entirely, the database could stay in an invalid state: this code ensures that database remains in a valid state.
+
+{{warning| '''Caution''': Some databases can be in an auto-commit mode. Furthermore, some special database commands can automatically commit database changes. }}
+
+{{seealso| '''See Also'''
+[[Database Connection|Database connection]]
+[[EiffelStore Implementation Layer|Implementation]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki
new file mode 100644
index 00000000..c85526f3
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki
@@ -0,0 +1,29 @@
+[[Property:title|Database Selection]]
+[[Property:weight|2]]
+Use the [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class to select data from the database. Once you have selected the data, you can [[Selection Access|access]] it with convenience using adaptative EiffelStore structures.
+
+{{note| '''Note''': Take a look at the [[Data Object Coupling|Database/Eiffel objects Coupling]] if you need information about your database structure. }}
+
+[[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] enables your application to get database content using SQL 'select' queries:
+* You can carry out 'select' queries in an intuitive way using directly the SQL language:
+
+ selection: DB_SELECTION
+ ...
+ create selection.make
+ selection.set_query ("select * from CONTACTS where firstname = 'John'")
+ selection.execute
+
+
+{{tip| '''Tip''': Always check the database status for errors after your 'select' query. }}
+
+* You can also customize your selection using [[Query variables|bind variables]] .
+
+{{seealso| '''See Also'''
+[[Query variables|Binding variables in a database query.]]
+[[Data Object Coupling|Coupling database objects with Eiffel objects.]]
+[[Selection Access|Accessing selected data from the database.]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/index.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/index.wiki
new file mode 100644
index 00000000..7a79d296
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/index.wiki
@@ -0,0 +1,22 @@
+[[Property:title|EiffelStore Interface Layer]]
+[[Property:weight|0]]
+The Interface layer gathers a set of classes covering all the capabilities an application need to interface efficiently with a DBMS.
+
+The interface affords these main capabilities:
+* [[Database Connection|Connecting]] to the database.
+* [[Data Modification|Modifying]] database objects.
+* [[Database Selection|Selecting]] data from the database.
+* [[Selection Access|Accessing]] data selected from the database.
+* [[Data Object Coupling|Coupling]] database objects with Eiffel objects.
+* [[Query variables|Binding variables]] in a database query.
+* Using [[Stored Procedures|stored procedures]] .
+* Dealing with database [[Database control|status and behavior]] .
+
+{{note| '''Note''': In general, each of these capabilities corresponds to one EiffelStore class. }}
+
+{{seealso| '''See Also'''
+[[EiffelStore Implementation Layer|The implementation layer]] }}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki
new file mode 100644
index 00000000..56528a69
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki
@@ -0,0 +1,49 @@
+[[Property:title|Query variables]]
+[[Property:weight|5]]
+If you have to execute database queries which only differ in the expression values, you can create a template query and then bind variables into this template for each execution.
+
+This mechanism can be applied for requests with a result ([[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] ). Hence both classes inherits from STRING_HDL that actually handle variable binding.
+
+To use variable binding:
+* [[#create|Create]] a template query.
+* [[#bind|Bind]] variables to the query.
+
+==Creating a template query==
+
+Template queries are parsed to replace each variable by its bound value. To create a template query, you have hence to put directly variables where the values would take place.
+
+Variables syntax is simple: the ':' special character followed by the variable name.
+
+ selection: DB_SELECTION
+ Bind_var: STRING is "firstname"
+ ...
+ create selection.make
+ selection.set_query ("Select * from CONTACTS where Firstname = ':" + Bind_var + "'")
+
+
+{{note| '''Note''': The code example shows how to bind variables to a [[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] object but the mechanism is exactly the same for [[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] objects. }}
+
+==Binding variables to a query==
+
+Once you have created your query, you can map variable names to values and execute the query:
+
+ selection: DB_SELECTION
+ Bind_var: STRING is "firstname"
+ ...
+ loop
+ io.read_line
+ selection.set_map_name (io.laststring, Bind_var)
+ selection.execute_query
+ ...
+ selection.unset_map_name (Bind_var)
+ end
+
+
+{{seealso| '''See Also'''
+[[Database Selection|Performing a database selection.]]
+[[Data Modification|Modifying database content.]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki
new file mode 100644
index 00000000..accd1e4d
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki
@@ -0,0 +1,103 @@
+[[Property:title|Selection Access]]
+[[Property:weight|3]]
+Once you have [[Database Selection|selected data]] from the database, it returns a set of rows containing queried columns values. Each row loaded with DB_SELECTION is stored in a DB_RESULT object. The easiest way to access the data is thus to refer to DB_RESULT objects themselves.
+
+{{note| '''Note''': Take a look at the [[Data Object Coupling|Database/Eiffel objects Coupling]] to learn advanced data handling features. }}
+
+To use DB_RESULT, process in 2 steps:
+* [[#retrieve|retrieve]] DB_RESULT objects.
+* [[#access|access]] DB_RESULT content.
+
+==Retrieving DB_RESULT objects==
+
+[[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class provides different ways to customize result loading:
+* You want to access an '''unique''' row: [[ref:/libraries/store/reference/db_result_flatshort|DB_RESULT]] object is accessible via cursor:
+
+ selection: DB_SELECTION
+ my_result: DB_RESULT
+ ...
+ selection.query ("...")
+ if selection.is_ok then
+ selection.load_result
+ my_result := selection.cursor
+ end
+
+
+* You want to load a '''complete list''' of rows: [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can store [[ref:/libraries/store/reference/db_result_flatshort|DB_RESULT]] objects in a list. To do this, you have mainly to provide a LIST object to DB_SELECTION with set_container:
+
+ selection: DB_SELECTION
+ container: ARRAYED_LIST [DB_RESULT]
+ create container.make (Max_results)
+ ...
+ selection.set_container (container)
+ ...
+ from
+ container.start
+ until
+ container.after
+ loop
+ ...
+ end
+
+
+{{tip| '''Tip''': Provide [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] with the LIST structure convenient for what you need to do with the results. }}
+
+* You want to '''select part''' of the result set: you can set an action in [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] that will be executed each time a row is loaded. This action can for instance manipulate current row and define a stop condition.
+** You need to define a descendant of class ACTION and set it to [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] :
+
+ class
+ MY_ACTION
+ inherit
+ ACTION
+ redefine
+ execute, found
+ end
+ ...
+ execute is
+ do
+ i := i + 1
+ end
+ ...
+ found: BOOLEAN is
+ do
+ Result := i >= Max_result
+ end
+
+
+** Then set action to [[ref:/libraries/store/reference/db_selection_flatshort|DB_SELECTION]] :
+
+ selection: DB_SELECTION
+ action: MY_ACTION
+ ...
+ selection.set_action (action)
+ selection.query ("...")
+ if selection.is_ok then
+ selection.load_result
+ end
+
+
+
+
+==Accessing content of DB_RESULT==
+
+A DB_RESULT object merely carries data retrieved from the database. You have to convert it to a DB_TUPLE to access data within the retrieved row conveniently, i.e. mostly the column values:
+
+ selection: DB_SELECTION
+ tuple: DB_TUPLE
+ ...
+ create tuple
+ tuple.copy (selection.cursor)
+ if tuple.count >= 2 and then tuple.column_name (2).is_equal ("Firstname") then
+ io.putstring (tuple.item (2).out)
+ end
+
+
+{{seealso| '''See Also'''
+[[Database Selection|Performing a database selection.]]
+[[Data Object Coupling|Coupling database data and Eiffel objects.]]
+}}
+
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki
new file mode 100644
index 00000000..918e66e7
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki
@@ -0,0 +1,71 @@
+[[Property:title|Stored Procedures]]
+[[Property:weight|6]]
+When sending requests to the database, the request is first parsed then executed. Instead of parsing many times the same requests, i.e. with only changes in expression values, most of RDBMS enable to '''precompile''' requests. These requests can then be executed as routines and are identified by a name and a signature.
+
+EiffelStore lets you use stored procedures with [[ref:/libraries/store/reference/db_proc_flatshort|DB_PROC]] class to:
+* [[#execute|Execute]] a stored procedure.
+* [[#create|Create]] a stored procedure.
+
+==Executing a stored procedure==
+
+To execute a stored procedure:
+* Create a [[ref:/libraries/store/reference/db_proc_flatshort|DB_PROC]] object and load the stored procedure you want to use:
+
+ procedure: DB_PROC
+ ...
+ create procedure.make ("UPDATE")
+ procedure.load
+ if procedure.exists then
+ ...
+ end
+
+
+* Execute the procedure through a [[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] (if a result is expected) or a [[ref:/libraries/store/reference/db_change_chart|DB_CHANGE ]] object (otherwise).
+{{note| '''Note''': Requests with a result ([[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] ) are both abstract '''expressions'''. DB_PROC executes an abstract expression using an object of [[ref:/libraries/store/reference/db_expression_chart|DB_EXPRESSION]] type, which corresponds to an abstract expression. [[ref:/libraries/store/reference/db_selection_chart|DB_SELECTION]] and [[ref:/libraries/store/reference/db_change_chart|DB_CHANGE]] inherits from [[ref:/libraries/store/reference/db_expression_chart|DB_EXPRESSION]] . }}
+You can execute your request mostly like a basic one:
+** Create your request.
+** Bind request variables. Variables are stored procedure arguments.
+{{note| '''Note''': Take a look at how to [[Query variables|bind variables]] to a query. }}
+
+** Execute the query through the DB_PROC object.
+
+ procedure: DB_PROC
+ expr: DB_CHANGE
+ ...
+ procedure.execute (expr)
+ expr.clear_all
+
+
+** Check for errors and load result if any.
+
+
+==Creating a stored procedure==
+
+DB_PROC also enables you to create or drop stored procedures:
+* Use store to create a procedure.
+* Use drop to delete one.
+The following example shows how to overwrite a procedure in the database:
+
+ procedure: DB_PROC
+
+ ...
+ create procedure.make ("NEW_PROCEDURE")
+ procedure.load
+ if procedure.exists then
+ procedure.drop
+ end
+ procedure.load
+ if not procedure.exists then
+ procedure.set_arguments (<<"one_arg">>, <<"">>)
+ procedure.store ("update contacts set firstname = one_arg where contactid = 1")
+ end
+
+
+{{seealso| '''See Also'''
+[[Database Selection|Performing a database selection.]]
+[[Data Object Coupling|Coupling database data and Eiffel objects.]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/index.wiki b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/index.wiki
new file mode 100644
index 00000000..4ea6eddf
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/eiffelstore-tutorial/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|EiffelStore Content]]
+[[Property:link_title|EiffelStore Tutorial]]
+[[Property:weight|1]]
+EiffelStore main classes are grouped into 2 main layers:
+* The [[EiffelStore Interface Layer|interface layer]] provides a high-level, unique interface for every DBMS.
+* The [[EiffelStore Implementation Layer|implementation layer]] customizes high-level routines to various DBMS handles.
+
+Other cluster can facilitate your database management:
+* The [[EiffelStore Generation Cluster|generation cluster]] , with the EiffelStore wizard, generates a facilitated and dynamic interface with your database.
+* The [[EiffelStore DataView Cluster|dataview cluster]] lets you create a customized database GUI.
+
+
+
+
diff --git a/documentation/current/solutions/database-access/eiffelstore/index.wiki b/documentation/current/solutions/database-access/eiffelstore/index.wiki
new file mode 100644
index 00000000..10fae3c5
--- /dev/null
+++ b/documentation/current/solutions/database-access/eiffelstore/index.wiki
@@ -0,0 +1,17 @@
+[[Property:title|EiffelStore Library]]
+[[Property:link_title|EiffelStore]]
+[[Property:weight|1]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[EiffelStore Introduction|Introduction]]
+* [[EiffelStore Content|Content]]
+* [[EiffelStore Samples|Samples]]
+* [[ref:libraries/store/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/absolute-time.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/absolute-time.wiki
new file mode 100644
index 00000000..0a67f1db
--- /dev/null
+++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/absolute-time.wiki
@@ -0,0 +1,114 @@
+[[Property:title|Absolute time]]
+[[Property:weight|0]]
+The classes dealing with date and those dealing with time have almost the same construction. At the top of the hierarchy are the constants and the notion of value ([[ref:libraries/time/reference/time_value_chart|TIME_VALUE]] , [[ref:libraries/time/reference/date_value_chart|DATE_VALUE]] , [[ref:libraries/time/reference/date_time_value_chart|DATE_TIME_VALUE]] ). From this notion come two kinds of heirs which are the absolute notion of time (classes [[ref:libraries/time/reference/date_chart|DATE]] , [[ref:libraries/time/reference/time_chart|TIME]] and [[ref:libraries/time/reference/date_time_chart|DATE_TIME]] ) and the notion of duration (classes [[ref:libraries/time/reference/date_duration_chart|DATE_DURATION]] , [[ref:libraries/time/reference/time_duration_chart|TIME_DURATION]] , [[ref:libraries/time/reference/date_time_duration_chart|DATE_TIME_DURATION]] ).
+
+[[ref:libraries/time/reference/date_chart|DATE]] , [[ref:libraries/time/reference/time_chart|TIME]] and [[ref:libraries/time/reference/date_time_chart|DATE_TIME]] inherit from the deferred class ABSOLUTE. It implies that instances of these classes are used as absolutes. We can imagine an oriented axis on which are reported values. ABSOLUTE inherits COMPARABLE, there is a complete order inside the class and its heir. ABSOLUTE is a client of DURATION, so that each instance of ABSOLUTE is linked with the duration between the origin and itself.
+
+The default way to compare absolute objects is to compare their respective duration to each other.
+
+==TIME==
+
+[[ref:libraries/time/reference/time_chart|TIME]] deals with hour, minute and second. Is is possible to use more precision for time (there is no limit inside the class). See More precision in TIME for documentation. This section deals only with second.
+
+====Creation====
+
+There are three ways to create an instance of the class TIME: by choosing the time (make), by getting the time from the system (make_now), or by choosing the number of seconds elapsed from the origin (make_by_seconds). The arguments of make and make_by_seconds have to respect the range of a day (see preconditions).
+
+====Origin and cyclic representation====
+
+The origin is 0 hour 0 minute and 0 second. Notion of time is relative to a day in a cyclic representation: days begin at 0:0:0 and end at 23:59:59. If a second is added to 23:59:59 then the result will be 0:0:0. Subtracting a minute to 0:0:0 will yield 23:59:0.
+
+====Comparison====
+
+Instances of [[ref:libraries/time/reference/time_chart|TIME ]] may be compared. Functions <, + > and >= are available. Function is_equal must be use to test equality. = will compare references.
+
+====Measurement====
+
+The duration linked to an instance of [[ref:libraries/time/reference/time_chart|TIME]] (attribute duration) is an instance of [[ref:libraries/time/reference/time_duration_chart|TIME_DURATION]] . It is the duration from the origin until the current time. The function seconds returns the number of seconds since the origin. This function may be useful to get the number of seconds between two events.The feature - creates an interval between two instances of TIME. The duration of this interval is given by the function duration. However, this duration is not canonical (See [[Duration|Duration]] for precisions). In TIME, the feature relative_duration returns the same duration, but more efficiently and also it is canonical.
+
+====Operations====
+* Set directly hour, minute and second with set_hour, set_minute and set_second. Arguments must satisfy the rules of creation.
+* Adding hours, minutes and seconds with features hour_add, minute_add and second_add. Features add and + take an instance of TIME_DURATION as an Page 3 argument and add it to the current time.
+* Moving to the next or the previous hour, minute or second with features hour_forth, hour_back, minute_forth, minute_back, second_forth and second_back. It is faster to use these features rather than those above (hour_back <-> hour_add (-1)).
+
+==DATE==
+
+DATE deals with year, month and day. It is more complicated since there is no regular period in dates: each month contains its own total of days and there are leap years. That is why some peculiarities appear while manipulating objects of this class. There is no limit for a date (inside the class). The only limit comes from INTEGER representation. If INTEGER size is 32 bits (most common case), and as long as the basic unit is a day, the range for a date is from (- 2^31) to 2^31 (days), i.e. 5.8 million years from the origin.
+
+====Creation====
+
+There are also three ways to create an instance of the class DATE: by choosing the date (make, make_month_day_year, make_day_month_year), by getting the date from the system (make_now), or by choosing the number of days elapsed from the origin (make_by_days). The arguments of each creation procedure have to respect the common range (See preconditions).
+
+====Origin====
+
+The origin is 01/01/1600.
+
+====Comparison====
+
+Instances of DATE may be compared. Functions <, + > and >= are available. Function is_equal must be use to test equality, = will compare references.
+
+====Measurement====
+
+Each instance of DATE has a function (duration) which returns the duration since the origin until the current date (it is an instance of DATE_DURATION). This duration is definite, i.e. it contains only days (See below). However, it may be useful to deal directly with days (no need of DATE_DURATION). In this case, the function days of DATE yields the number of days since origin.
+
+====Status Report====
+
+Much information may be gotten from functions written in this part. Most of them are used within the class, but they are exported at the same time.
+
+====Operations====
+
+DATE operations looks like TIME operations:
+* Setting directly year, month and day with set_year, set_month and set_day. Arguments must satisfy the rules of creation. These rules are more complicated than those of TIME. For example it is not allowed to set day to 31 if the current month is April, whereas it is allowed if the month is January. It is the same rules as for make. The same thing for years: It is not allowed to set year to a non-leap year if the current date is February 29th of a leap year. However, two features are available to set month and year even if day is too large: set_month_cut_days and set_year_cut_days will cut day down to the largest value allowed.
+* Adding years, months and days with features year_add, month_add and day_add. There is no requirement to add a year or a month. However, these features have to return a correct result, i.e. day is checked before each addition-. Adding one month to August 31st will yield September 30th. 31 is cut to 30 since there are only 30 days in September. Features add and + take an instance of DATE_DURATION in argument and add it to the current date. It is written so that years and months are added first, the days last.(see DATE_DURATION below)
+* Moving to the next or the previous year, month or day with features year_forth, year_back, month_forth, month_back, day_forth and day_back. It is the same but faster to use these features rather than those upper (year_back <-> year_add (-1)).
+* Features relative_duration and definite_duration return the duration between the current date and the argument. The first one returns a result which is canonical (See definitions below), while the second one returns a definite result but may be not canonical.
+
+For example, date1 is April 20th and date2 is May 28th. Both features will yield instances of DURATION; however, relative_duration will yield 1 month and 8 days whereas definite_duration will yield 38 days.
+
+==DATE_TIME==
+
+The aim is to gather the time with the date. DATE_TIME is client of TIME and DATE (see inheritance relation). Some features from DATE and TIME are re-written since they are useful within the class. Many other features may be called indirectly with the correct attribute (time or date).
+
+====Creation====
+
+There are still several ways to create an instance:
+* by choosing value for all the attributes of the date and the time (make).
+* by getting the time from the system (make_now).
+* by gathering an instance of DATE with an instance of TIME (make_by_date_time).This feature copies only the references of its arguments, so that if the time (or the date) is changed, the instance previously initialized will be also changed. If this effect has to be avoided, cloning the arguments is required.
+* by encapsulating an instance of DATE (make_by_date). The attribute time is set to the origin, i.e. 0:0:0.
+
+The attribute date is set with the same reference as the argument (See comment of the previous section).
+
+====Access====
+
+To make it easier calls to features of TIME and DATE, the most useful access features are written as features in DATE_TIME (days, seconds and their associated duration date_duration and time_duration).
+
+====Comparison====
+
+Instances of DATE_TIME are totally ordered (the class inherit from ABSOLUTE). Functions <, + > and >= are available. Function is_equal must be used to test equality, = will compare references.
+
+====Measurement====
+
+Function duration gathers functions duration from the attributes time and date. The result is an instance of DATE_TIME_DURATION.
+
+====Element change====
+
+It is possible to change reference of time and date with the features set_time and set_date. To change only one element (for example hour), features from TIME or DATE have to be used.
+
+====Operations====
+
+Addition of hours, minutes and seconds are available directly in the class.The reason is that adding one second may have a consequence on the date. Using second_add from TIME is also possible but the date will not be modified in the case time makes a cycle. It is of course the same for minute and hour. day_add is also available directly since it is frequently used within the class.
+
+Features + and add take an instance of DATE_TIME_DURATION in arguments. The date duration is added first then the time duration. Adding the time duration first would have yield some different result as in this example: the current date is August 30th 23:59:59. The duration to add is one month and one second. Feature add returns October 1st 0:0:0, whereas adding the second first would return September 30th 0:0:0! The same difference occurs with leap years.
+
+Feature relative_duration and definite_duration returns the duration between the current date (with time) and the argument. The first one returns a result which is canonical (see definitions below), while the second one returns a result definite but may be not canonical. It is the same notion than in DATE.
+
+==DATE and DATE_TIME==
+
+Another way to process would have been to make DATE_TIME inherit from DATE,as long as DATE_TIME is a DATE, with more precision. The choice was to have a client relation between them. Otherwise DATE should have known the existence of DATE_TIME, and many assignment attempts would have been useful in features such as infix +. So DATE_TIME is client of DATE.
+
+However, it could be useful to mix instances of DATE of DATE_TIME. As DATE_TIME is client of DATE with its attribute date, it is easy to get only the date from instances of DATE_TIME. On the other way features are available to convert objects from DATE to DATE_TIME. In class DATE, feature to_date_time builds an instance of DATE_TIME with the origin of time (0,0,0). In the class DATE_TIME, the creation procedure make_by_date has the same effect. (The same feature exists for duration, replacing origin by zero).
+
+
+
+
diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/date-time-string-conversion.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/date-time-string-conversion.wiki
new file mode 100644
index 00000000..ffa57075
--- /dev/null
+++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/date-time-string-conversion.wiki
@@ -0,0 +1,94 @@
+[[Property:title|DATE / TIME to STRING Conversion]]
+[[Property:weight|3]]
+The following table lists format conversion codes.
+{|
+|-
+| '''Code'''
+| '''Description'''
+|-
+| dd
+| day - numeric
+|-
+| [0]dd
+| day - numeric (padded with '0' to 2 figures)
+|-
+| ddd
+| day - text (3 letters e.g "Mon", "Tue")
+|-
+| yyyy
+| year - numeric (4 figures)
+|-
+| yy
+| year - numeric (2 figures)
+|-
+| mm
+| month - numeric
+|-
+| [0]mm
+| month - numeric (padded with '0' to 2 figures)
+|-
+| mmm
+| month - text (3 letters e.g "Dec", "Jan")
+|-
+| hh
+| hour - numeric (24 hour clock scale by default)
+|-
+| [0]hh
+| hour - numeric (padded with '0' to 2 figures)
+|-
+| hh12
+| hour - numeric (12 hour clock scale)
+|-
+| mi
+| minute - numeric
+|-
+| [0]mi
+| minute - numeric (padded with '0' to 2 figures)
+|-
+| ss
+| seconds - numeric
+|-
+| [0]ss
+| seconds - numeric (padded with '0' to 2 figures)
+|-
+| ff
+| fractional seconds - numeric (precise to figures)
+|-
+| ':', '/', '-' and ','
+| separators e.g. "03/Aug/97"
+|}
+These are some examples of output with their associated format code:
+{|
+|-
+| '''Code'''
+| '''Output'''
+|-
+| yy/m/dd
+| 97/8/18
+|-
+| mmm-dd-yy
+| Aug-18-97
+|-
+| dd,mm,yyyy
+| 18,Aug,1997
+|-
+| hh-mi-ss
+| 13-06-32
+|-
+| hh12,mi,ss
+| 1,06,32 pm
+|-
+| hh12:mi:ff
+| 1:06:32.25 pm
+|-
+| hh:mi:ff3
+| 13:06:32.248
+|-
+| [0]mm/dd/yy hh12:mi:ff3
+| 08/18/97 1:06:32.248 pm
+|}
+
+
+
+
+
diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki
new file mode 100644
index 00000000..b93041c9
--- /dev/null
+++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki
@@ -0,0 +1,126 @@
+[[Property:title|Duration]]
+[[Property:weight|1]]
+TIME_DURATION, DATE_DURATION AND DATE_TIME_DURATION
+
+The classes dealing with duration inherit DURATION, which inherits GROUP_ELEMENT and PART_COMPARABLE. An instance of TIME_DURATION, DATE_DURATION or DATE_TIME_DURATION is an element of a group, i.e. there is a zero and addition operations (infix +,infix -, prefix + and prefix -). Duration is used as an amount of time, without link to an origin. It may be added to the respective absolute notion (time + time_duration is possible, not time + date_time_duration nor date_time + time_duration...see classes TIME, DATE and DATE_TIME).
+
+Attributes are allowed to take negative values or values which do not stand in the usual range (hour = -1, minute = 75, day = 40...). However, features are available in each class to convert instances into the usual format: functions canonical and to_canonical are present in each class. An instance is canonical (canonical = True) if its attributes stand into the usual range. For example, an instance of TIME_DURATION such as 12:-10:60 is not canonical. to_canonical will return 11:51:0. In DATE_DURATION and DATE_TIME_DURATION, these features are also present.
+
+The order is partially implemented. TIME_DURATION has a complete order whereas DATE_DURATION and DATE_TIME_DURATION are more specific.
+
+==TIME_DURATION==
+
+====Creation====
+
+Two ways are possible: by choosing the value of each attributes hour, minute and second (feature make), or by giving an amount of seconds (make_by_seconds). Any integer value is accepted. It is possible to create a duration with 1 hour and -60 minutes.
+
+====Access====
+
+Zero is a once feature with 0 hour, 0 minute and 0 second. The total amount of second of the current duration is the result of feature seconds_count.
+
+====Comparison====
+
+Instances of TIME_DURATION may be compared easily. The order is the order oft he respective total amount of second. 1:-40:0 is less than 0:0:1800, etc... Functions <, >,<= and >= are available. Is_equal tests equality, = will compare references.
+
+====Element change====
+
+Set directly hour, minute and second with set_hour, set_minute and set_second. Arguments do not need to satisfy any range rule.
+
+====Operations====
+* Adding hours, minutes and seconds with features hour_add, minute_add and second_add.
+* TIME_DURATION inherits from GROUP_ELEMENT. infix and prefix +, infix and prefix - are available to compose instances of each other.
+
+====Conversion====
+
+Two features ensure a link with the notion of day: to_days returns the number of days equivalent to the current duration. For example, a duration such as 23:60:0 is equivalent to one day. For negative duration, the result is never 0. -1 hour is equivalent to -1 day (i.e. the result of the function is -1). To_days is associated with time_modulo_day. This second function returns an instance of TIME_DURATION. The result represents the difference between the current duration and the number of days yielded by to_days. It implies that the result is always positive and less than one day.
+
+For example, the current duration is 25:70:600. to_days will returns 1 (one day) and time_modulo_day will return 2:20:0:. If the current duration is negative: -23:-80:300,to_days will return -2 (minus two days) and time_modulo_day will return 23:45:0.
+
+Durations may be canonical or not canonical (BOOLEAN canonical). That means the features hour, minute and second are included in a particular range, or not. An instance of TIME_DURATION is canonical if:
+* in the case of a positive duration (> zero), all of the three features have to be positive or 0, minute and second less than 60.
+* in the case of a negative duration (< zero), all of the three features have to be negative or 0, minute and second strictly greater than -60. The function canonical tests if the duration is canonical or not, the function to_canonical yields a new duration equivalent to the current one and canonical.
+
+==DATE_DURATION==
+
+Dealing with the Gregorian calendar is not so easy because of irregularities. A duration of one month may be equal to 28 up to 31 days, depending on the current date! On the other hand, it could be useful to deal with precise duration. This point leads to an original design of the class: A separation is made between two kinds of instances.
+
+The definite ones and the relative ones. The function definite which returns a BOOLEAN, is true for definite duration and false otherwise. An instance is definite if and only if its attributes month and year are 0. Then only the number of days is used. Relative (non definite) durations have their attributes year, month and day meaningful but it is then impossible to compare them to each other (is one month greater than 30 days?, is one year greater than 365 days?). The main difference appears when a duration is added to a date. In the case of a definite duration, there is no ambiguity. A given number of days are added to the date, taking care of the calendar. In the other case, the result is relative to the origin date. For example, a one month duration may be equal to 28 days if the date is in February or 31 days if the date is in August. A duration becomes definite when its attributes year and month become 0. However it is possible to deal with instances of DATE_DURATION without taking care of this distinction.
+
+===Relative date_duration===
+
+Relative duration cannot be compared with any other durations (including zero). The reason is simple. It is not possible to say if 30 days are less than 1 month: it depends on the date: it is true in August (in a 31 days month) and it is false in February.
+
+If feature > (or <, + + is called with at least one non definite member (the current instance or the argument), the result will be always False. We may only know if two durations are equal, with the feature is_equal. It compares field by field the two durations. When adding a relative date_duration to a date, the years and the months are added first, then the date may be cut (June 31 -> June 30) and finally the days are added. For example, if one month is added to the date August 31st, the result is September 30th.
+
+Nevertheless there is a way to compare relative durations: a relative date_duration may be canonical. It means that the duration has its attributes month and day in a fixed range.month must be between 1 and 12, and day larger than 1 and less than a value between 27 and 30. This value is fixed simply: (in the case of a positive duration) when setting day to 0 and adding one more month, the addition of the start date and this new duration must yield a date strictly after the final date (yielded by adding date and tested duration). For example is 0/0/30 (i.e. 0 year, 0 month and 30 days) canonical?
+* If the origin date is 01/15 (15th of January), the final date is 02/14. We cannot convert 30 days into 1 month in this case. The duration is canonical.
+* If the origin date is 04/15 (15th of April), the final date is 05/15. The duration is not canonical since it is possible to convert days into 1 month. The origin date is used to determine whether the duration is positive or not. If the final date is after the origin date the duration is positive, otherwise it is negative. That does not mean we can compare it to zero, that is only used to determine the sign of the canonical standard. If the duration is negative, it is canonical only if all the attributes are negative.
+
+A way to compare two relative durations is to make them canonical from the same date, and then to compare the fields. It is the same as adding the durations to the same date, and to compare the final dates to each other.
+
+===Definite date_duration===
+
+Definite durations are characterized by the attribute day. Whenever a duration has its attributes year and month equal to 0, this duration is then definite. On the other hand, if one of these two attributes is not 0, the duration is not definite anymore.
+
+The number of days between an origin date and the result of (date + duration) does not depend on the origin date. It is possible to compare definite date_duration to each other.The order is the one of day.
+
+A definite duration may be canonical or not. It is canonical if the number of day is small enough.
+
+===General description===
+
+====Creation====
+
+Two creation features are available: make takes three arguments (year, month and day). If year and month are null, the duration will be definite; make_by_days takes only the number of day. The duration is automatically definite.
+
+====Comparison====
+
+Features <, >, <= and >= are available. If both instances are definite, numbers of days are compared. If one of them is non definite, the result is False.
+
+====Element change====
+
+Features set_day, set_month and set_year are available to set one of these three attributes day, month, year.
+
+====Operation====
+* Add years, months and days with features year_add, month_add and day_add.
+* DATE_DURATION inherits from GROUP_ELEMENT. infix and prefix +, infix and prefix - are available to compose instances of each other.
+
+====Conversion====
+* to_canonical is used to get a new duration equivalent to the current one and canonical. It needs an argument from class DATE, which is the origin of calculations.
+* to_definite is used to get a new duration equivalent to the current one and definite. As with the previous feature, one argument is needed. - to_date_time is used to get an instance of DATE_TIME_DURATION. It will have the same date of the current duration and time set to zero.
+
+==DATE_TIME_DURATION==
+
+DATE_TIME_DURATION is client of DATE_DURATION and TIME_DURATION. Most of the common features described in DATE_DURATION are present in the class. The class deals with its attributes date and time in the same way as DATE_TIME.
+
+There are, as in DATE_DURATION, definite and non definite durations. It is the date part which gives the definite non definite status. Features canonical and to_canonical are present in DATE_TIME_DURATION. They have to deal with the attributes time.
+
+====Creation====
+
+There are still several ways to create an instance:
+* by choosing values for all the attributes of date and time (make). - by choosing a value for day and values for all the attributes of time. The instance is then definite (make_definite).
+* by gathering an instance of DATE with an instance of TIME (make_by_date_time). This feature copies the references of its arguments, so that if the time (or the date) is changed, the instance previously initialized will be also changed. If this effect has to be avoided, the use of clones is required.
+* by encapsulating an instance of DATE (make_by_date). The attribute time is set to zero, i.e. 0:0:0. The attribute date is set with the same reference than the argument.
+
+====Access====
+
+Seconds_count is the amount of seconds of the time part only. To get the total amount of seconds of the current duration, first shift it to a definite duration, then multiply day by the number of seconds in day and add to it seconds_count. Take care that the duration is not more than 68 years. If it is, the number of seconds will be larger than 2 billion, which is the upper limit for INTEGER (4 bytes).
+
+====Comparison====
+
+The rules are the same than those for DATE_DURATION. Features <, >,<= and >= are available. If both instances are definite, numbers of days are compared. If one of them is non definite, the result is False.
+
+====Element change====
+
+It is possible to change reference of time and date with the features set_time and set_date. To change only one element (for example hour), features from TIME_DURATION or DATE_DURATIONhave to be used.
+
+====Operation====
+* DATE_TIME_DURATION inherits from GROUP_ELEMENT. infix and prefix +, infix and prefix - are available to compose instances to each other.
+* Only day_add is present. To add only one element, features from TIME_DURATION or DATE_DURATION have to be used.
+
+====Conversion====
+* canonical and to_canonical are available in the class. To be canonical an instance of the class must have its attributes time and date canonical. Then time must have the same sign than the one of the current duration. The sign of the current instance is determined by adding it to the argument (from DATE_TIME). That will yield a final date. If this final date is after the origin (= the argument), the current duration is considered positive. Otherwise, it is considered negative. Finally time must be less than one day (if positive) or more than minus one day (if negative). To_canonical returns a duration equivalent to the current one (for the argument) and canonical.
+* time_to_canonical looks like to_canonical but focuses mainly on time. It requires a definite duration so that it is possible to compare it to zero. It yields a definite duration equivalent to the current one with a canonical time. hour is then cut so that it stands in the range of one day (0 to 23 if positive and -23 to 0 if negative). The attributes day is also modified to keep the result equivalent to the current duration.time_to_canonical does not need any argument because only time and day are modified.
+
+
+
+
diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki
new file mode 100644
index 00000000..10b71efa
--- /dev/null
+++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki
@@ -0,0 +1,43 @@
+[[Property:title|Interval]]
+[[Property:weight|2]]
+Class INTERVAL deals with intervals between two instances of the same class which conform to ABSOLUTE ( DATE, TIME, DATE_TIME). The notions of interval is directly linked with the notion of order.
+
+The start_bound must be before the end_bound.
+
+====Creation====
+
+The features make, set_start_bound and set_end_bound take clones of their arguments, so that if these arguments are changed, the interval previously created is not.
+
+It would have been possible to create intervals with references to date or time, but a modification of the dates would have been effective in the interval so that only the invariant would have been able to check if the start_bound is still before the end_bound.
+
+====Interval measurement====
+
+The measure of intervals is made by duration: the result is an instance of the class DURATION. However, as DURATION is the common parent of TIME_DURATION, DATE_DURATION and DATE_TIME_DURATION, it does not have many features available. Some features in class TIME, DATE, DATE_TIME return the same result and are more efficient to use. DURATION has to be use as the last solution.
+
+====Comparison====
+
+It includes intersection, inclusion and a special comparison.
+* is_equal is present and compare values, not references.
+* Feature intersects returns the mathematical result of the intersection of two intervals.
+* is_strict_included_by, strict_includes, is_included_by and includes are connected to the same notion of inclusion.
+* <, + > and >= use a special rule to compare intervals. int1 < int2 is true if int1 starts and ends strictly before int2. The other features use the same rule and is_equal if needed.
+* overlaps looks like intersects but the argument has to be after the current interval. is_overlapped is the opposite.
+* meets and is_met are used to test if two intervals have a common bound.
+
+====Status Report====
+
+The main part of the functions need an argument from the same generic type and return a BOOLEAN value.
+* empty tests if the bounds are equal.
+* has, strict_before, strict_after, before and after test the position of an element relatively to the current interval.
+
+====Element change====
+
+set_start_bound and set_end_bound are available to change the bounds.
+
+====Operations====
+
+Union and intersection are the mathematical functions. gather requires that two intervals meet each other and then yields the union.
+
+
+
+
diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki
new file mode 100644
index 00000000..68402fc1
--- /dev/null
+++ b/documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki
@@ -0,0 +1,45 @@
+[[Property:title|More precision]]
+[[Property:weight|4]]
+TIME and TIME_DURATION are designed to deal with high precision in time. The only limit is the one from number representation.
+
+The classes TIME and TIME_DURATION have an attribute fine_second (inherited from TIME_VALUE) which allows high precision. This attribute represents the number of seconds with fractions (it is an instance of DOUBLE). From this attribute are calculated second and fractional_second (which are functions): second is the truncated-to-integer part and fractional_second is the difference between the two previous one, so that the sum of second and fractional_second is always equal to fine_second (see invariant in TIME_VALUE).
+
+As a result of this, when fine_second is positive (3.55 for example), second and fractional_second are also positive (3 and 0.55). When fine_second is negative (- 3.55 for example), second and fractional_second are also negative (- 3 and - 0.55).
+
+Manipulation on second and fractional_second are in fact always made through fine_second. Users who do not want to deal with precision do not need to care about this.
+
+Features dealing with fine_second and fractional_second are described here.
+
+====Creation (common to TIME, TIME_DURATION)====
+* make_fine looks like make but it takes a DOUBLE for its third argument (instead of an INTEGER). fine_second is then set to this value.
+* make_by_fine_seconds looks like make_by_seconds but it takes a DOUBLE for argument (instead of an INTEGER). Comparison (common) There are no new features. The same ones are available since they are written to deal with precision. It is possible to compare two instances, one with precision and the other one without.
+
+====Measurement and access====
+
+In TIME:
+
+- fine_seconds looks like seconds but it contains fractions.
+
+In TIME_DURATION:
+
+- fine_seconds_count looks like seconds_count but it contains fractions.
+
+====Element change====
+* set_fine_second allows to set directly fine_second to a DOUBLE. In TIME, a precondition requires that the argument stands in the allowed range.
+* set_fractionals allows to set directly fractional_second to a DOUBLE. In TIME a precondition requires that the argument is positive and smaller than one. In TIME_DURATION the precondition is particular: it is not allowed to have an argument with a different sign than second. Otherwise, as long as fractional_second and second are linked to fine_second, such a setting would mean that second is also changed and fractional_second set to a different value. For example if fine_second = 4.5 (then second = 4 and fractional_second = 0.5) and - 0.8 is the argument of set_fractionals.
+
+The result of that would be fine_second = 3.2 (then second = 3 and fractional_second = 0.2). It is better to prohibit that.
+
+Comment: feature set_second (from both TIME and TIME_DURATION) will cut down fractional_second to zero.
+
+====Operations====
+
+- fine_second_add looks like second_add but takes a DOUBLE for argument.
+
+In TIME_DURATION:
+
+- canonical and to_canonical deals already with precision. There is nothing different.
+
+
+
+
diff --git a/documentation/current/solutions/dates-and-times/eiffeltime/index.wiki b/documentation/current/solutions/dates-and-times/eiffeltime/index.wiki
new file mode 100644
index 00000000..2ee94db1
--- /dev/null
+++ b/documentation/current/solutions/dates-and-times/eiffeltime/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|EiffelTime Library]]
+[[Property:link_title|EiffelTime]]
+[[Property:weight|9]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[EiffelTime|Content]]
+* [[ref:libraries/time/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki
new file mode 100644
index 00000000..6b80de5b
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Create an object]]
+[[Property:weight|1]]
+An EiffelBuild [[EiffelBuild Notation|object]] is a representation of a Vision2 component and its properties.
+
+To create a new instance of an object, [[EiffelBuild Notation|pick]] a type from the [[Type selector|type selector]] and [[EiffelBuild Notation|drop]] onto an existing [[EiffelBuild Notation|object]] (Accessible from the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] ). You will only be able to complete the [[EiffelBuild Notation|drop]] if the targeted [[EiffelBuild Notation|object]] will accept a new object of the transported type.
+
+{{note| '''Note''': Once an [[EiffelBuild Notation|object]] has been [[Create an object|created]] , it will always be contained in a parent [[EiffelBuild Notation|object]] until [[Delete an object|deleted]] . }}
+
+==Creating Window and Dialog Objects==
+
+Window and dialog objects are created by picking a type from the [[Type selector|type selector]] and dropping into the [[Widget selector|widget selector]] . If the target of the drop is a directory within the widget selector, the new object is created within that directory, otherwise in the root of the project location. Window and dialog objects are generated as individual classes by EiffelBuild.
+
+{{note|'''Note''' If there are no other windows or directories in the project, the newly created object is set as the root window.}}
+
+==Creating objects for re-use==
+
+If you wish to create an object that may be re-used in multiple locations within your EiffelBuild project, pick the type from the [[Type selector|type selector]] and drop into the [[Widget selector|widget selector]] . This ensures that at generation time, the object is generated as a seperate class (as with all objects in the [[Widget selector|widget selector]] ). Objects within the [[Widget selector|widget selector]] may be used in a client fashion within other object structures as required, and any changes made to these objects are reflected at all locations in which they are used.
+
+{{seealso| '''See Also'''
+[[Type selector|Type selector]]
+[[Reparent an Object|Reparent an object]]
+[[Delete an object|Delete an object]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/delete-object.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/delete-object.wiki
new file mode 100644
index 00000000..dfc9f575
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/delete-object.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Delete an object]]
+[[Property:weight|2]]
+To remove an [[EiffelBuild Notation|object]] from your EiffelBuild system, [[EiffelBuild Notation|pick]] the object you wish to delete, and [[EiffelBuild Notation|drop]] it on [[Image:icon-delete-small-color]] in the [[Main toolbar|main toolbar]] .
+
+You may also delete via the keyboard by pressing the delete key while the tool containing the objects representation has the focus. Whichever [[EiffelBuild Notation|object]] has the selection is deleted.
+
+{{note| '''Note''': To restore a deleted object, you may use the [[History|History]] }}
+
+{{seealso| '''See Also'''
+[[History|History]]
+[[Type selector|Type selector]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/eiffelbuild-creating-new-project.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/eiffelbuild-creating-new-project.wiki
new file mode 100644
index 00000000..3aa9a26d
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/eiffelbuild-creating-new-project.wiki
@@ -0,0 +1,23 @@
+[[Property:title|EiffelBuild: Creating a new project]]
+[[Property:weight|0]]
+When a project is not open in Build, there are only two menu options available. 'File' and 'Help'. To create a new project, select 'file', 'New project' as illustrated below:
+
+[[Image:new-project]]
+
+This will bring up a directory dialog from which you can select the directory in which you wish to create the new Build project.
+
+Selecting a directory that does not already contain a Build project will create a new project in that directory and the Build tools will become available for development of the newly created project. If a directory was selected that already contains a Build project, the following dialog will be displayed:
+
+[[Image:overwrite-project]]
+
+Selecting 'Ok' will create a new project, overwriting the existing project, and the Build tools will become available for development of the newly created project.
+
+Selecting 'Cancel' will return you to the directory selection dialog, from which you can select the directory in which you wish to create the new Build project.
+
+{{seealso| '''See Also'''
+[[Retrieving a project from a Build project file|Retrieving a project from a Build project file]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki
new file mode 100644
index 00000000..cd449235
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|EiffelBuild: Starting a project]]
+[[Property:weight|0]]
+* [[EiffelBuild: Creating a new project|Creating a new project]]
+* [[Retrieving a project from a Build project file|Retrieving a project from a Build project file]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/retrieving-project-build-project-file.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/retrieving-project-build-project-file.wiki
new file mode 100644
index 00000000..f949bb1c
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/retrieving-project-build-project-file.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Retrieving a project from a Build project file]]
+[[Property:weight|1]]
+When a project is not open in Build, there are only two menus available, 'File' and 'Help'. To retrieve an existing project, select 'file', 'Open Project
+
+[[Image:open-project]]
+
+A directory dialog will be displayed from which you can select the Build project file that you wish to retrieve. All build project files are named 'build_project.bpr' and are qualified by the directory in which they reside.
+
+You may also open a recent EiffelBuild project via the 'Recent Projects' entry of the 'file' menu as shown below:
+
+[[Image:recent-projects]]
+
+This list contains the most recent projects that have been used within EiffelBuild, and if none are available, this list is empty and the menu option disabled.
+
+{{seealso| '''See Also'''
+[[EiffelBuild: Creating a new project|Creating a new project]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/import-project.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/import-project.wiki
new file mode 100644
index 00000000..a185903f
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/import-project.wiki
@@ -0,0 +1,21 @@
+[[Property:title|Import a project]]
+[[Property:weight|5]]
+The contents of an existing project may be imported into the currently open project, permitting re-use of existing structures. All versions of EiffelBuild before 5.4 limited each project to a single titled window, with 5.4 removing this limitation. The ability to import multiple EiffelBuild projects into a single project is useful for maintaining larger systems with many windows.
+
+To import the contents of an existing project, select 'Import Project' from the 'File' menu as illustrated below:
+
+[[Image:import-project]]
+
+Upon selection of the menu item, a file dialog is displayed prompting for the EiffelBuild project to be imported (".bpr" files) . Selecting a valid EiffelBuild project file causes the import to commence, during which, EiffelBuild is unresponsive. Please be patient, as importing a large EiffelBuild project may take a little while, depending on the speed of the system.
+
+Upon completion of the import, there are two possible outcomes:
+* No name clashes occurred: No names from the imported project clashes with those of the open project. In this case, notification of success is displayed in the status bar for a short period of time.
+* One or more name clashes occurred: One or more objects or constants from the imported project had names that matched that of objects in the open project. As the names are used directly in the generated code, they must be unique within their scope (accessible within the code), and therefore EiffelBuild must resolve these clashes. A dialog is displayed on screen showing all the names that were resolved by EiffelBuild:
+[[Image:import-project-clashes]]
+
+{{note| '''Note''': If a name clash occurs, the names of the imported project are modified, not the open project. }}
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki
new file mode 100644
index 00000000..5be6dcdd
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|EiffelBuild How To's]]
+[[Property:weight|0]]
+* [[EiffelBuild: Starting a project|Starting a project]]
+* [[Create an object|Create an object]]
+* [[Delete an object|Delete an object]]
+* [[Save a project|Save a project]]
+* [[Reparent an Object|Reparent an object]]
+* [[Import a project|Import a Project]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/reparent-object.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/reparent-object.wiki
new file mode 100644
index 00000000..457d95a7
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/reparent-object.wiki
@@ -0,0 +1,21 @@
+[[Property:title|Reparent an Object]]
+[[Property:weight|4]]
+To reparent an [[EiffelBuild Notation|object]] , you need to [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|object]] and [[EiffelBuild Notation|drop]] it on the [[EiffelBuild Notation|object]] you wish it to be parented in. The [[EiffelBuild Notation|object]] will be removed from its current parent, and inserted in the new parent at the next available position.
+
+When an [[EiffelBuild Notation|object]] is inserted into a parent, it is always added at the next available position. If you wish to place an [[EiffelBuild Notation|object]] at a particular position within a parent, you must hold down the '''Shift''' key, and drop on an [[EiffelBuild Notation|object]] already contained in parent, Your [[EiffelBuild Notation|object]] will then be inserted in the parent, in the position preceding the child [[EiffelBuild Notation|object]] that you dropped on.
+
+You can access [[EiffelBuild Notation|objects]] from both the [[Builder window|builder window]] and [[Layout constructor|layout constructor]] .
+
+{{note|'''Note''' Although window and dialog objects may be accessed within the [[Widget selector|widget selector]] , it is not possible to build into these objects, you should use the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] directly in this situation. }}
+
+For more information about an [[EiffelBuild Notation|objects]] capacity and permitted children, see the [[EiffelVision Introduction|EiffelVision2]] documentation.
+
+{{seealso| '''See Also'''
+[[Create an object|Create an object]]
+[[Delete an object|Delete an object]]
+[[Builder window|Builder window]]
+[[Layout constructor|Layout constructor]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/save-project.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/save-project.wiki
new file mode 100644
index 00000000..86d5f209
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/save-project.wiki
@@ -0,0 +1,14 @@
+[[Property:title|Save a project]]
+[[Property:weight|3]]
+To save the project that is currently open, select '''Save''' from the '''File''' menu or click on [[Image:icon-save-color]] in the [[Main toolbar|main toolbar]] .
+
+Alternatively, you may use the keyboard shortcut - '''Ctrl+S'''
+
+{{note| '''Note''': If no changes have been made to the system, the save command will be disabled. }}
+
+{{seealso| '''See Also'''
+[[EiffelBuild: Key shortcuts|Key shortcuts]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki
new file mode 100644
index 00000000..146f0ec3
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Builder window]]
+[[Property:weight|7]]
+The Builder window provides a view of the [[EiffelBuild Notation|objects]] in your system, in which the [[EiffelBuild Notation|objects]] may be manipulated.
+
+This window may either be shown or hidden (default). To change between these two states, click [[Image:icon-builder-window-color]] on the [[Main toolbar| main toolbar]] , or select '''Show/Hide builder window''' from the '''View''' menu.
+
+[[Image:builder-window]]
+
+The content of this window is a representation of the [[EiffelBuild Notation|objects]] you have defined in your project. Each [[EiffelBuild Notation|object]] is represented by the [[EiffelVision Introduction|EiffelVision2]] control matching its type. For example, an [[EiffelBuild Notation|object]] representing an EV_BUTTON will be displayed in here using an EV_BUTTON. As this view provides direct access to the objects ( [[EiffelBuild Notation|Pick]] any of the controls in this window), it enables you to build your interface within a view which provides rich visual feedback.
+Because this window is just a view of the [[EiffelBuild Notation|objects]] , it will be always synchronized with the [[Layout constructor| layout constructor]] . This means you can [[Reparent an Object| re-parent objects]] , using the [[EiffelBuild Notation|pick and drop]] transport method, seamlessly between the two views.
+
+{{note|'''Note:''' Holding Ctrl while right clicking on an [[EiffelBuild Notation|object]] in the Builder Window creates a new [[Object editor|object editor]] targeted to the [[EiffelBuild Notation|object]] . Holding Ctrl and Shift while right clicking on an [[EiffelBuild Notation|object]] , highlights it within the [[Layout constructor|layout constructor]] .}}
+
+==Visual Differences==
+
+Although the builder window attempts to show you the interface you are developing, it is not a completely accurate representation (Unlike the [[Display window|display window]] ). The main difference is that all [[EiffelBuild Notation|objects]] representing descendents of EV_CONTAINER are parented in a frame. This was implemented so that you would be able to easily manipulate the containers.
+
+Imagine that this was not the case, and each container [[EiffelBuild Notation|object]] was just represented by an [[EiffelVision Introduction|EiffelVision2]] object matching its type. Because these containers have no visible screen space when filled with children, manipulation of them would have been difficult, and the functionality of this view would be compromised.
+
+In the screenshot above, you can see that there are two [[EiffelBuild Notation|objects]] representing containers in your project, an EV_VERTICAL_BOX, and an EV_HORIZONTAL_BOX (Excluding the EV_TITLED_WINDOW [[EiffelBuild Notation|object]] represented by this window).
+
+The properties of the [[EiffelBuild Notation|objects]] in you system are always reflected in this window, with a few exceptions:
+* 'user_can_resize', 'maximum_width', 'maximum_height' and 'title_string' are not reflected in this window.
+* 'minimum_width' and `minimum_height' are not reflected in any of the controls representing [[EiffelBuild Notation|objects]] within this window.
+
+{{seealso| '''See also'''
+[[Display window|Display window]]
+[[Layout constructor| Layout constructor]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-selector.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-selector.wiki
new file mode 100644
index 00000000..29727ed2
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-selector.wiki
@@ -0,0 +1,39 @@
+[[Property:title|Component selector]]
+[[Property:weight|8]]
+The component selector allows you to build and retrieve user defined [[EiffelBuild Notation|components]] for use in your project.
+
+[[Image:component-selector]]
+
+==Creating a component==
+
+To define a new [[EiffelBuild Notation|component]] , [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|object]] that you wish to create the component from, and then [[EiffelBuild Notation|drop]] it anywhere in the component selector. The following dialog will appear:
+
+[[Image:component-namer]]
+
+Modify the suggested name as desired, and then click '''OK''' to create the new component. If you click '''Cancel''', the component will not be created.
+
+The component that has been created will contain enough information to allow a copy to be built of the existing object. This includes all the children of the original object (to any depth) and the properties (width, height, color etc)of all objects within the structure. The only properties of the objects that will not be set inside a component are the user defined names, and any events connected to the objects.
+
+==Using a component==
+To create a new set of [[EiffelBuild Notation|objects]] from a [[EiffelBuild Notation|component]] , [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|component]] , and [[EiffelBuild Notation|drop]] onto an [[EiffelBuild Notation|object]] representation. If an object is full, or does not allow other objects of the new type to be contained, then you will not be able to [[EiffelBuild Notation|drop]] on it.
+
+If the [[EiffelBuild Notation|pick and drop]] completed successfully, then you should have a new set of objects matching the structure of the [[EiffelBuild Notation|component]] .
+
+==Deleting a component==
+
+To remove a [[EiffelBuild Notation|component]] from your EiffelBuild system, [[EiffelBuild Notation|pick]] it, and then [[EiffelBuild Notation|drop]] it on [[Image:icon-delete-small-color]] in the [[Main toolbar| main toolbar]] .
+
+{{note| '''Note''': The deletion of a [[EiffelBuild Notation|component]] cannot be undone. }}
+
+==Viewing a component==
+
+To view an existing component, use the [[Component viewer|component_viewer]] .
+
+{{seealso| '''See also'''
+[[Component viewer|Component_viewer]]
+[[Builder window|Builder window]]
+[[Layout constructor| Layout Constructor]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-viewer.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-viewer.wiki
new file mode 100644
index 00000000..06fbfed4
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-viewer.wiki
@@ -0,0 +1,29 @@
+[[Property:title|Component viewer]]
+[[Property:weight|10]]
+The Component viewer allows you to view the structure of a [[EiffelBuild Notation|component]] without having to create new [[EiffelBuild Notation|objects]] from the [[EiffelBuild Notation|component]] .
+
+This tool is displayed in a separate window, and may either be shown or hidden (default). To change between these two states, click [[Image:icon-component-viewer-color]] on the [[Main toolbar| main toolbar]] , or select '''Show/Hide component viewer''' from the '''View''' menu.
+
+[[Image:component-viewer]]
+
+==Targeting a component==
+
+To target a [[EiffelBuild Notation|component]] into the tool, [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|component]] from the [[Component viewer|component_viewer]] , and [[EiffelBuild Notation|drop]] on the [[Image:icon-component-viewer-color]] displayed in the tool bar of the component viewer (See screenshots above). Any existing component displayed is simply removed.
+
+Alternatively, you can hold down the Ctrl key while starting a [[EiffelBuild Notation|pick]] on a [[EiffelBuild Notation|component]] in the [[Component selector| component_selector]] . This will automatically target the [[EiffelBuild Notation|component]] to the component viewer. If the viewer is currently hidden, it will also make it visible.
+
+==View types==
+
+Looking at the left-hand screenshot above, you can see that the [[Image:icon-component-display-view-color]] button is depressed, meaning the component viewer is in display view mode. Clicking on [[Image:icon-component-build-view-color]] will put the component viewer into build mode view as shown in the right-hand screenshot. These modes are mutually exclusive and are described below:
+* '''Builder view''' - This view is similar to the view used by the [[Display window|display window]] . i.e. the [[EiffelVision Introduction|EiffelVision2]] controls are displayed exactly as is defined in the [[EiffelBuild Notation|component]] .
+* '''Display view''' - This view is similar to the view used by the [[Builder window|builder window]] . i.e. all [[EiffelVision Introduction|EiffelVision2]] containers are represented by frames so they are immediately visible. This makes the actual structure represented by the [[EiffelBuild Notation|component]] completely visible.
+
+{{note| '''Note''': The type of the "root_object" within the component is displayed in the toolbar of the component viewer. }}
+
+{{seealso| '''See also'''
+[[Builder window|Builder window]]
+[[Layout constructor| Layout constructor]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/constants.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/constants.wiki
new file mode 100644
index 00000000..a0ac37ec
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/constants.wiki
@@ -0,0 +1,174 @@
+[[Property:title|Constants]]
+[[Property:weight|12]]
+EiffelBuild supports the use of constants, permitting you to define a particular value and use it comprehensively throughout your system. If a constant is in use, any changes are reflected immediately in all clients, providing a quick way of globally changing object properties. The Eiffel code generated by EiffelBuild, generates all constants as actual Eiffel constants for use in your system.
+
+The following constant types are supported by EiffelBuild:
+* '''String''' - Representing the Eiffel STRING type.
+* '''Integer''' - Representing the Eiffel INTEGER type.
+* '''Directory''' - Representing a directory location, of type STRING.
+* '''Pixmap''' - Representing an EV_PIXMAP, and either absolute, or built from a directory constant.
+* '''Font''' - Representing a font, of type EV_FONT.
+* '''Color''' - Representing a color, of type EV_COLOR.
+
+
+==Constants Dialog==
+
+Modification to all constant types is performed from the constants dialog, accessible from the [[Main toolbar|main toolbar]] via the [[Image:icon-format-onces-color]] button. The constants dialog has the following appearance:
+
+[[Image:constants-dialog]]
+
+The screenshot above, shows the constants dialog displayed for a project containing twelve constants, a few of each available type. Each of the constants in the project are displayed in the multi column list occupying most of the dialog.
+
+The "Type", "Name" and "Value" fields displayed along the bottom of the dialog are used to permit addition and modification of constants. The "OK" button displayed in the top right hand corner of the dialog closes the dialog when modifications to the constants are complete.
+===Adding a new constant===
+
+To add a new constant to your project, select the type of the constant that you wish to add from the "Type" combo box. Depending on the type of constant selected, the remaining fields, and associated buttons will be modified appropriately, and the steps required to add the constant differ:
+* '''String''' and '''Integer''' - Enter the name in the "Name" field, and value in the "Value" field. The "New" button is only enabled when the name is valid, and a valid entry is set, and clicking it adds the new constant.
+* '''Directory''' - Enter a name for the directory in the "Name" field, and then select "New" which displays a choose directory dialog. Selecting a directory from this dialog and pressing "OK" adds the new directory constant to the project.
+* '''Pixmap''' - Select the "New" button, which brings up the Pixmap Constant Dialog enabling you to select a constant. The use of this dialog is described further down this page.
+* '''Font''' - Enter a name in the "Name" field, and then select "New" which displays a font dialog. Selecting a font from this dialog and pressing "OK" adds the new font constant to the project.
+* '''Color''' - Enter a name in the "Name" field, and then select "New" which displays a color dialog. Selecting a color from this dialog and pressing "OK" adds the new color constant to the project.
+
+{{note| '''Note''': After adding a new constant, it is immediately displayed with all constants in the dialog. }}
+
+
+===Modifying an existing constant===
+
+To modify a constant that already exists, select the constant in the multi column list, and depending on the type of the constant, perform the following:
+* '''String''' and '''Integer''' - Modify the value, which in turn, enables the "Modify" button, which must be selected for the value to change. Note that if you change the name, the "New" button is enabled as this will now add a new constant.
+* '''Directory''' - Select the "Modify" button which displays a directory dialog, permitting selection of the new value.
+* '''Pixmap''' - Select the "Modify" button which displays the Pixmap Constant Dialog, in a mode which permits you to select the new pixmap you wish to use.
+* '''Font''' - Select the "Modify" button which displays a font dialog, permitting selection of the new font.
+* '''Color''' - Select the "Modify" button which displays a color dialog, permitting selection of the new color.
+
+===Removing constants===
+
+To remove a constant from the project, select it in the multi column list, and select the "Remove" button, or press the delete key. If the constant is not in use within the system, it will be removed, otherwise the following dialog is displayed:
+
+[[Image:constant-in-use]]
+
+As objects are reliant on the constant you are removing, you must confirm that you really wish to remove it from the system. If you select "OK", the constant is removed, and the object property relying on that constant is converted to a manifest value. For example, if you are using an Integer constant with a value of 100, and you remove the constant, the property no longer references the constant, but is set explicitly to 100.
+
+{{note| '''Note''': You may sort the constants displayed in the dialog, by clicking the associated column header. }}
+
+==String constant==
+
+A String constant represents an Eiffel STRING, and may be any valid STRING. For example, in the generated constants file, for a String constant named `modify_button_text', the following code is generated:
+
+ modify_button_text: STRING is
+ -- `Result' is STRING constant named modify_button_text.
+ once
+ Result := "Modify"
+ end
+
+
+
+==Integer constant==
+
+A Integer constant represents an Eiffel INTEGER, and may be any valid INTEGER value. For example, in the generated constants file, for an Integer constant named `medium_padding', the following code is generated:
+
+ medium_padding: INTEGER is
+ -- `Result' is INTEGER constant named medium_padding.
+ once
+ Result := 8
+ end
+
+==Directory constant==
+
+A Directory constant is an Eiffel representation of a directory, as a STRING value. For example, in the generated constants file, for a Directory constant named `pixmap_location', the following code is generated:
+
+ pixmap_location: STRING is
+ -- `Result' is DIRECTORY constant named pixmap_location.
+ once
+ Result := "C:\pixmaps"
+ end
+
+
+==Pixmap constant==
+
+A pixmap constant is a representation of a pixmap image, and two types are available:
+* '''Absolute''' - The generated code contains a constant of type EV_PIXMAP, built from a single, absolute path, based on the location of the original pixmap on disk as follows:
+
+ main_pixmap: EV_PIXMAP is
+ -- `Result' is PIXMAP constant named main_pixmap.
+ local
+ a_file_name: FILE_NAME
+ once
+ create Result
+ create a_file_name.make_from_string ("C:\pixmaps\main_pixmap.png")
+ -- Now set `Result' based on `a_file_name'.
+ set_with_named_file(Result, a_file_name)
+ end
+
+* '''Relative''' - The generated code contains a constant of type EV_PIXMAP, built from a file name and a directory constant. This type of pixmap constant is the most frequently used, as it is more flexible. By redefining the value of the directory constant on which it is based, your systems may easily account for the installation location of the pixmap. A relative Pixmap constant is generated as follows:
+
+ main_pixmap: EV_PIXMAP is
+ -- `Result' is PIXMAP constant named main_pixmap.
+ local
+ a_file_name: FILE_NAME
+ once
+ create Result
+ create a_file_name.make_from_string (pixmap_location)
+ a_file_name.set_file_name("main_pixmap.png")
+ -- Now set `Result' based on `a_file_name'.
+ set_with_named_file(Result, a_file_name)
+ end
+
+Where `pixmap_location' is the name of the Directory constant to which the pixmap is relative.
+
+
+==Font constant==
+
+A Font constant represents an EV_FONT. For example, in the generated constants file, for a font constant named `times_new_roman', the following code is generated:
+times_new_roman: EV_FONT is
+ -- `Result' is EV_FONT constant named `times_new_roman'.
+ once
+ create Result
+ Result.set_family (feature {EV_FONT_CONSTANTS}.Family_roman)
+ Result.set_weight (feature {EV_FONT_CONSTANTS}.Weight_regular)
+ Result.set_shape (feature {EV_FONT_CONSTANTS}.Shape_regular)
+ Result.set_height_in_points (12)
+ Result.preferred_families.extend ("Times New Roman")
+ end
+
+==Color constant==
+
+A Color constant represents an EV_COLOR. For example, in the generated constants file, for a color constant named `red', the following code is generated:
+red: EV_COLOR is
+ -- `Result' is EV_COLOR constant named `red'.
+ once
+ Result := create {EV_COLOR}.make_with_8_bit_rgb (255, 0, 0)
+ end
+
+===Pixmap constant dialog===
+
+The Pixmap Constant dialog is used to select pixmaps for addition to an EiffelBuild project, and is displayed from the Constants dialog when necessary. The Pixmap Constant dialog has the following appearance:
+
+[[Image:pixmap-selection-dialog]]
+
+An individual pixmap may be selected, or a whole directory of pixmaps may be selected from this dialog for addition. In the screenshot above, a directory containing two pixmaps was selected. The "Build from" option at the bottom of the dialog permits you to select if you wish to add an absolute or relative pixmap, and if multiple pixmaps are being added, the currently selected pixmap from the list above is active. The relative "DIRECTORY" for relative pixmaps is filled in automatically if EiffelBuild finds a directory constant in the system that matches the path chosen. If not, you may enter a name in this field to create a new directory matching the required path. If you do not enter a directory name for one or more relative pixmaps, upon closing the dialog, you will be prompted to enter a name for a directory constant used for these pixmaps.
+{{note| '''Note''': If you are selecting new pixmaps, and they appear in the dialog as unchecked, it means that an equivalent pixmap already exists in the project. }}
+
+
+==Loading constants==
+
+The generation of an EiffelBuild project creates two constants classes, an interface class and an implementation class, named to match the setting from the [[EiffelBuild: Project settings window|project settings]] . For example, if you have specified the name "constants" for the constants, two classes are generated, CONSTANTS and the implementation, CONSTANTS_IMP.
+
+By default, all constant values are hard coded into the implementation class, but it is possible to set these to be loaded from an external file upon execution of the generated system. To do this, the "Load constants from file" setting of the [[EiffelBuild: Project settings window|project settings]] must be checked, which causes a file "constants.txt" to be generated, containing the definitions of all Integer and String constant values. As the system is executed, the values of these constants are loaded from the file, and by providing different versions of the file, at the time of deployment, multiple languages may be accounted for in your generated system.
+
+==Using constants==
+
+Constants may be associated to properties of your [[EiffelBuild Notation|objects]] via an [[Object editor|object editor]] targeted to that [[EiffelBuild Notation|object]] . The [[Image:icon-format-onces-color]] button denotes the use of a constant value. For more information regarding using constants, in [[Object editor|object editors]] , see [[Object editor|object editor]] .
+
+When an EiffelBuild project is generated, all constants are added to a class, inherited by each window class. There is an "_IMP" and interface versions of these classes as with each window. For more information regarding the generation of constants, see [[EiffelBuild: Code Generation|code generation]] .
+{{note| '''Note''': To modify pixmap constants based on the current installation of an EiffelBuild generated interface, simply redefine the Directory constant used to access the pixmaps within the interface constants class (not "_IMP"), which is not re-generated if it already exists. }}
+
+{{seealso| '''See also''':
+[[EiffelBuild: Code Generation|Code generation]]
+[[Object editor|Object editor]]
+[[EiffelBuild: Project settings window|Project settings]] }}
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/display-window.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/display-window.wiki
new file mode 100644
index 00000000..e5370bfb
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/display-window.wiki
@@ -0,0 +1,19 @@
+[[Property:title|Display window]]
+[[Property:weight|6]]
+The Display window provides a view of the [[EiffelBuild Notation|objects]] in your system, but unlike the [[Layout constructor|layout constructor]] and [[Builder window|builder window]] , the objects cannot be manipulated.
+
+This window may either be shown or hidden (default). To change between these two states, click [[Image:icon-display-window-color]] on the [[Main toolbar|main toolbar]] , or select '''Show/Hide display window''' from the '''View''' menu.
+
+[[Image:display-window]]
+
+This view is provided so that you can really see what your project will look like when it has been generated and is running as a stand alone [[EiffelVision Introduction|EiffelVision2]] system.
+
+All properties that have been set on the [[EiffelBuild Notation|objects]] in your project are set in the [[EiffelVision Introduction|EiffelVision2]] control matching its type.
+
+{{seealso| '''See Also'''
+[[Builder window|Builder window]]
+[[Layout constructor|Layout constructor]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-code-generation.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-code-generation.wiki
new file mode 100644
index 00000000..d9417049
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-code-generation.wiki
@@ -0,0 +1,51 @@
+[[Property:title|EiffelBuild: Code Generation]]
+[[Property:weight|15]]
+To generate Eiffel code representing your system, select '''Generate code''' from the '''Project''' menu or click [[Image:icon-code-generation-color]] on the [[Main toolbar|main toolbar]] .
+The length of time taken to generate your code is dependent on the speed of the system you are running, and the size of your interface, but typically takes a couple of seconds. A progress bar is displayed during the generation of your system.
+
+The code will be generated according to the options you selected in the [[EiffelBuild: Project settings window|project settings]] .
+
+==Generated classes==
+
+The generation of an EiffelBuild project causes the following files to be generated:
+* A constants class and its respective implementation class. For example, if the constants class is named as "constants" in the [[EiffelBuild: Project settings window|project settings]] , two classes, CONSTANTS and CONSTANTS_IMP are generated.
+* A class and implementation class for each window, dialog and "top level" widget in the system (each of which is contained in the [[Widget selector|widget selector]] ), named to correspond with the name attribute of the object. For example, for a window in the project named "main_window", the files MAIN_WINDOW and MAIN_WINDOW_IMP are generated.
+* An optional file named "constants.txt" which contains definitions of all INTEGER and STRING constants. This is only generated if "Load constants from file" is selected in the [[EiffelBuild: Project settings window|project settings]] . The generated code loads the constants from this file, and allows simple modification for localization, i.e. for foreign languages provide a different version of this file with all strings converted.
+
+For each "top level" widget class in the system (contained in the [[Widget selector|widget selector]] ), the following class hierarchy is generated:
+
+[[Image:class-project-diagram]]
+
+If the "generate as client" option is selected for a particular object (changeable from the [[Object editor|object editor]] , only for objects contained in the [[Widget selector|widget selector]] ), a client supplier relationship exists between the generated widget class and the EiffelVision widget, as illustrated below:
+
+[[Image:class-project-diagram-client]]
+
+{{note| '''Note''': All other diagrams on this page show only the non client version of the settings, where the generated widget inherits from the EiffelVision class. }}
+
+==Project build type==
+
+If [[Build Tab|build type]] is selected as '''Project''' in the [[EiffelBuild: Project settings window|project settings]] , then all the classes listed above in "Generated classes" are generated, along with the following:
+* A project configuration file called "build_project.ecf".
+* An application class which launches the root window of the project.
+
+The generated files comprise a complete project with a configuration file enabling you to compile and execute the generated system as is. The following diagram illustrates the hierarchy of the generated project, showing only the root window of the project:
+
+[[Image:complete-project-diagram]]
+
+
+==Modifying code after generation==
+
+The choice to generate an interface and an implementation class for the windows and constants was to enable modification of the interface using EiffelBuild, once you had hand edited code. The rule is that the implementation classes are re-generated every time, but the interface classes are not. It follows from this that you should not add hand written code to the implementation classes (ending in _IMP), as any changes you make will be lost when re-generation takes place.
+
+Using this mechanism, you can generate your initial system using EiffelBuild, and implement any event features that have been generated (in the interface) by EiffelBuild. If you then decide that you wish to modify the look and the feel of the interface, you can return to EiffelBuild, make the necessary adjustments and then re-generate the system.
+
+{{note| '''Note''': When returning to EiffelBuild to modify the interface, if you delete or rename controls, then it is quite possible that you will break your existing code. Care should be taken with all changes of this type. }}
+
+Looking at a generated system, you will see that the [[Object editor|events]] connected to your controls are defined as deferred in the implementation and actually implemented in the interface class. This means that if you return to EiffelBuild with a previously generated system, and add a new event to a control, then you will have to implement the definition in the interface class yourself (as the class interface class is not re-generated).
+
+{{seealso| '''See also''':
+[[EiffelBuild: Project settings window|Project settings]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/docking.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/docking.wiki
new file mode 100644
index 00000000..31ebf96c
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/docking.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Docking]]
+[[Property:weight|3]]
+The docking mechanism permits customization of the EiffelBuild interface through the re-ordering of tools to suit your preferences. You may simply "drag" one of the supported tools to a new location as desired. The [[Type selector|Type Selector]] , [[Component selector|Component Selector]] and [[Widget selector|Widget Selector]] all support docking.
+
+==Performing a dock==
+
+To dock one of the three supported tools, press and hold the left mouse button on the title of the tool, and move the mouse so that it points to the new location for the tool. Upon releasing the mouse button, the dock completes, and based on the mouse location, the following may occur:
+* '''Re-positioning in the main window''' - If the mouse is held over the three part vertical split area displayed to the left hand side of the EiffelBuild window, the position of the tool within this structure may be modified, providing simple re-ordering. A small grayed area indicates the insertion position of the tool, only displayed if the tools position will be changed upon release. The gray area indicating the new insertion point has the following appearance:
+[[Image:docking-insert]]
+In this case, the tool being docked will be moved to immediately above the component selector. If no feedback is provided regarding the insertion, upon releasing the mouse button to complete the dock, the tool is moved to an external window.
+* '''Docking externally''' - Completing a dock while not above the left hand area of the main window, or if no insert feedback is provided, causes the tool to be moved from its current location to an external window. A tool that is docked externally has the following appearance:
+[[Image:docked-external]]
+The tool may now be freely moved to any location on screen, in the same fashion as you would move any standard window. The window in which the tool is contained is always displayed "on top" of the main window. There are two methods of restoring the dialog back to its original location in the main window:
+** '''Docking back''' - Start a drag from the title of the tool, and point the mouse to the position in which you wish to insert the tool within the main window. If the position is valid, feedback (the gray bar) is displayed, and completing the dock closes the dialog, and re-inserts the tool. If no feedback is provided, the pointed position is not valid, and completing the dock simply moves the window to that position on screen.
+** '''Closing the window''' - Clicking the cross displayed to the right hand side of the windows title bar causes the window to be destroyed, and the tool contained to be restored back to its original position within the main window.
+
+
+{{note| '''Note''': The position of tools that have been docked, is maintained automatically between EiffelBuild sessions. When a new project is opened, they are restored to the positions that they had during the last use. }}
+
+==Main window with externally docked tools==
+
+The following screenshot illustrates the appearance of the main window with all dockable tools external:
+[[Image:main-window-with-docked-tools]]
+
+
+{{seealso| '''See Also'''
+[[EiffelBuild: General interface description|General interface description]] }}
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-key-shortcuts.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-key-shortcuts.wiki
new file mode 100644
index 00000000..46a44cee
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-key-shortcuts.wiki
@@ -0,0 +1,45 @@
+[[Property:title|EiffelBuild: Key shortcuts]]
+[[Property:weight|2]]
+Many operations in EiffelBuild do not require the use of the mouse. The same effect can be achieved through the keyboard only.
+
+This page gathers all the keyboard shortcuts available in the environment.
+
+==Key shortcut reference==
+{|
+|-
+| '''Key shortcut'''
+| '''action'''
+|-
+| ''- file shortcuts -''
+|-
+| Ctrl+O
+| Open project.
+|-
+| Ctrl+N
+| New Project.
+|-
+| Ctrl+S
+| Save project
+|-
+| ''- code generation shortcuts -''
+|-
+| Ctrl+G
+| Generate code from project.
+|-
+| ''- miscellaneous shortcuts -''
+|-
+| Delete
+| Delete object from currently selected tool.
+|-
+| Ctrl+T
+| Tool always on top.
+|}
+
+'''Note''': These shortcuts are not always available and are dependent on the state of EiffelBuild. For example, Ctrl+S does nothing if there is no modified project open.
+
+{{seealso| '''See Also'''
+[[EiffelBuild: General interface description|General interface description]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-window-overview.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-window-overview.wiki
new file mode 100644
index 00000000..02af6a90
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-window-overview.wiki
@@ -0,0 +1,29 @@
+[[Property:title|EiffelBuild window overview]]
+[[Property:weight|0]]
+==Window layout==
+
+The use of EiffelBuild is based around one main window which remains throughout the execution. The appearance of the main window is as follows:
+
+[[Image:main-window]]
+
+The window contains several different tools, highlighted below:
+* The [[Type selector|type selector]] - Situated at the top left of the window, this tool contains all the available vision2 types available for interface construction.
+* The [[Component selector| component selector]] - Situated in the middle left of the window, below the [[Type selector|type selector]] , this tool contains all the user defined components.
+* The [[Widget selector|widget selector]] - Situated in the bottom left of the window contains all of the EiffelVision2 windows contained in the open project. Each of these windows are generated by EiffelBuild as separate classes.
+* The [[Layout constructor| layout constructor]] tool - Situated in the middle of the window, this tool displays a graphical representation of the interface that is currently being built.
+* The docked [[Object editor|object editor]] - Situated to the right hand side of the window, this object editor automatically targets itself to the selected [[EiffelBuild Notation|object]] in the [[Layout constructor| layout constructor]] .
+
+The [[Type selector|type selector]] , [[Component selector|component selector]] and [[Widget selector|widget selector]] may all be docked from their original position, permitting re-ordering and customization of the main window. Each of these may be docked external to the main window, permitting each to be displayed in their own movable window. For more information regarding the docking mechanism, see [[Docking|docking]] .
+
+{{seealso| '''See Also'''
+[[Main toolbar| Main toolbar]]
+[[Layout constructor| Layout constructor]]
+[[Type selector|Type selector]]
+[[Object editor|Object editor]]
+[[Component selector| Component_selector]]
+[[Docking| Docking]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki
new file mode 100644
index 00000000..cf765b3b
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki
@@ -0,0 +1,10 @@
+[[Property:title|EiffelBuild: General interface description]]
+[[Property:weight|2]]
+* [[EiffelBuild window overview|EiffelBuild window overview]]
+* [[Main toolbar|Main toolbars]]
+* [[EiffelBuild: Key shortcuts|Key shortcuts]]
+* [[Docking|Docking]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki
new file mode 100644
index 00000000..5cba9959
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki
@@ -0,0 +1,66 @@
+[[Property:title|Main toolbar]]
+[[Property:weight|1]]
+At the top of the EiffelBuild development window, one toolbar is displayed by default, as shown below:
+[[Image:toolbar]]
+
+The complete list of the icons in the toolbar is displayed below.
+{|
+|-
+| Icon
+| Command
+|-
+| [[Image:icon-delete-small-color]]
+| Delete [[EiffelBuild Notation|object]] / [[EiffelBuild Notation|component]] .
+|-
+| [[Image:icon-save-color]]
+| [[Save a project|Save]] current project.
+|-
+| [[Image:icon-object-editor-color]]
+| New [[Object editor|object editor]]
+|-
+| [[Image:icon-undo-color]]
+| [[History|Undo]] last action.
+|-
+| [[Image:icon-cmd-history-color]]
+| Display full [[History|history]] .
+|-
+| [[Image:icon-redo-color]]
+| [[History|Redo]] last undone action.
+|-
+| [[Image:icon-code-generation-color]]
+| [[EiffelBuild: Code Generation|Generate]] code.
+|-
+| [[Image:icon-system-color]]
+| Display [[EiffelBuild: Project settings window|project settings]] .
+|-
+| [[Image:icon-builder-window-color]]
+| Show/hide [[Builder window|builder window]] .
+|-
+| [[Image:icon-display-window-color]]
+| Show/hide [[Display window|display window]] .
+|-
+| [[Image:icon-component-viewer-color]]
+| Show/hide [[Component viewer|component viewer]] .
+|-
+| [[Image:icon-format-onces-color]]
+| Display [[Constants|Constants]] dialog.
+|-
+| [[Image:icon-cut-color]]
+| Cut selected object to clipboard.
+|-
+| [[Image:icon-copy-color]]
+| Copy selected object to clipboard.
+|-
+| [[Image:icon-past-color]]
+| Paste contents of clipboard.
+|-
+| [[Image:icon-clipboard-color]]
+| View clipboard contents.
+|}
+
+
+The screenshot at the top of this page shows all of the buttons enabled. As the state of the currently open project changes, the state of each of these buttons is updated to reflect this. For example, immediately after saving the project, the save button is disabled until the project is modified again.
+'''Note''': It is not possible to customize the toolbar.
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-notation.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-notation.wiki
new file mode 100644
index 00000000..fd11c24a
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-notation.wiki
@@ -0,0 +1,42 @@
+[[Property:title|EiffelBuild Notation]]
+[[Property:weight|1]]
+This page contains descriptions of terms found within the EiffelBuild documentation.
+
+==Object==
+
+An EiffelBuild object is a representation of a Vision2 component and its properties. When developing with EiffelBuild, you manipulate objects to build the desired interface.
+
+Each object type has a different set of properties that may be manipulated, and these correspond directly to the properties available within the [[EiffelVision Introduction|EiffelVision2]] type. There is property which is specific to an EiffelBuild object, '''Name''' which is used for your identification purposes and as the attribute name in the generated code.
+
+For more information on manipulating objects within EiffelBuild, see:
+* How to [[Create an object|create an object]]
+* How to [[Reparent an Object| reparent an object]] .
+* [[Object editor|Object editor]] for details on modifying object properties.
+
+Within EiffelBuild, there may be multiple views of a single object displayed simultaneously. Any modifications to an object will immediately update all views. Both the [[Layout constructor| layout constructor]] and the [[Builder window|builder window]] provide views of the objects within your project, and in these, the objects may be manipulated. The [[Display window|display window]] also provides a view of the objects in your system, except the objects cannot be manipulated from this view. It can be thought of as a preview of the project you are developing.
+
+==Component==
+
+EiffelBuild components are templates representing user defined object structures. From a component, you can quickly build a matching structure of objects. Components are available in EiffelBuild so that you do not repeatedly create the same structures over and over again while developing your projects.
+
+You specify a new component by creating it from an existing object structure. See [[Component selector| component_selector]] for more detailed instructions on the use of components.
+
+To view an existing component, use the [[Component viewer|component_viewer]] .
+
+It is not possible to modify a component once created, except to [[Component selector| delete]] it.
+
+==Pick and Drop==
+
+The pick and drop mechanism is one of Eiffel Software 's exclusive technologies and is provided by [[EiffelVision Introduction|EiffelVision2]] . In EiffelBuild, it allows you to easily send data from a component of the interface to another.
+
+You can '''Pick''' a reference to a '''development object''', such as an object or component with a single click of the '''right''' mouse button. Then as you start moving the mouse around - not pressing any of its buttons - a pebble tracks the cursor position, and a line continuously connects the pebble to the object's original position.
+
+You may terminate this situation in either of two ways:
+* If the pebble you are dragging is the regular cursor, you can right-click again to confirm the pick-and-drop and so effectively send the dragged development object to the targeted component. This is known as '''Dropping'''.
+Right-clicking when the pebble is the '''no''' cursor, will only stop the pick-and-drop because the component you are hovering with the mouse does not accept your development object.
+
+* If, for any reason, you change your mind, you can cancel the pick-and-drop by left-clicking anywhere or by pressing the Escape key.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-preferences.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-preferences.wiki
new file mode 100644
index 00000000..7d8d7d0d
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-preferences.wiki
@@ -0,0 +1,23 @@
+[[Property:title|EiffelBuild Preferences]]
+[[Property:weight|14]]
+The EiffelBuild preferences are used to handle all user defined preferences. For example, each time a dialog is displayed with a "do not show again" option, your chosen setting is recorded in the preferences. Various properties of the EiffelBuild interface are recorded by the preferences, on a user by user basis, permitting you to adapt the behavior of EiffelBuild to suit your needs.
+
+During use of EiffelBuild, many settings and options that you select, will modify the preferences, ensuring the desired behavior is maintained. To access all of the available EiffelBuild preferences, you may use the Preferences dialog, accessible from the "View", "Preferences", "Preferences..." menu option. The preference dialog has the following appearance:
+
+[[Image:preferences-dialog]]
+
+To the left hand side of the dialog is a tree, containing the preferences structure, while on the right, the actual preferences in the selected tree node are displayed. To modify the value of a particular preference, double click on its "Literal Value" which displays a small dialog permitting modification of the value. Dependent on the type of the property, the dialog displayed may change appropriately.
+
+The button marked "Restore Defaults" in the lower left hand corner of the dialog, may be selected to restore the preferences back to their defaults when EiffelBuild was first launched.
+
+When you have finished modifying the preferences, select the "Close" button to close the dialog.
+
+{{note| '''Note''': The preferences are saved automatically by EiffelBuild, even if the open project is not saved, the preferences are saved whenever a property changes. }}
+
+{{seealso| '''See also''':
+[[EiffelBuild: General interface description|General interface description]]
+[[EiffelBuild Reference|EiffelBuild reference]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/build-tab.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/build-tab.wiki
new file mode 100644
index 00000000..56cee8cf
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/build-tab.wiki
@@ -0,0 +1,41 @@
+[[Property:title|Build Tab]]
+[[Property:weight|0]]
+This tab contains information about the type of project you wish to build, and associated information.
+
+Here is the appearance of the Build tab when 'build type' is selected as 'Project':
+
+[[Image:project-build]]
+
+If 'build'_type' is selected as 'Class', then the tab will have the following appearance:
+
+[[Image:project-build-class]]
+
+The options available in this tab are as follows:
+* '''Build type'''
+Select 'Project' if you wish to generate a complete project including an ace file, and an application class, which will launch the GUI you are developing.
+
+Select `Class' if you wish to generate a single class that represents the GUI you are developing. This option is useful if you wish to incorporate your current project into an existing Vision2 system.
+
+* '''Always rebuild ace'''
+This option causes the ace file to be completely re-generated every time you generate your project. If you do not wish the ace file to be re-generated, then disable this option. This check box is only available if 'build type' is set to 'project'.
+
+* '''Project name'''
+This entry will be added to the generated ace file as the SYSTEM attribute. The executable built from compiling this ace file will have this name. This option is only available if you have specified 'build_type' as 'Project'.
+
+* '''Application class name'''
+This entry will be the class name for the generated vision2 application which will launch your GUI. This option is only available if you have specified 'build_type' as 'Project'.
+
+* '''Constants class name'''
+This entry is used as the name of the constants class generated by EiffelBuild to define all [[Constants|constants]] contained in your project. Two classes are actually generated from this name, an implementation and an interface class. For example, if you specify a name "constants", two classes, CONSTANTS_IMP and CONSTANTS (inheriting from CONSTANTS_IMP) are generated, and all other classes generated by EiffelBuild, inherit CONSTANTS for access to these constants.
+
+
+
+{{seealso| '''See Also'''
+[[EiffelBuild: Code Generation|Code generation]]
+[[EiffelBuild: Project settings window|Project settings window]]
+[[Generation Tab|Generation tab]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki
new file mode 100644
index 00000000..ef51c19d
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Generation Tab]]
+[[Property:weight|1]]
+This tab contains information about the available code generation options.
+
+Here is the appearance of the Generation tab with default settings for a Build project:
+
+[[Image:project-generation]]
+
+The options available in this tab are as follows:
+* '''Attribute declarations'''
+** '''Local''' - All attributes (corresponding to widgets and items generated by EiffelBuild) are declared as local variables.
+** '''Attributes''' -- All attributes are declared as attributes of the class with the following export status:
+**
+*** '''Exported''' - All attributes are exported to ANY.
+*** '''Export only named''' - Only those attributes that have been named are exported to ANY while unnaned attributes are not exported..
+*** '''Export None''' - None of the attributes are exported.
+
+** '''Grouped''' - Should different objects of same type be declared individually, or grouped?
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/index.wiki
new file mode 100644
index 00000000..7cb403bf
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/index.wiki
@@ -0,0 +1,22 @@
+[[Property:title|EiffelBuild: Project settings window]]
+[[Property:weight|13]]
+This is where global settings regarding your project are going to be made. In here you can specify:
+* The type of project you wish to generate
+* The system name
+* Class names
+* Code generation options
+
+The project window can be raised by clicking [[Image:icon-display-window-color]] on the [[Main toolbar| main toolbar]] , or by selecting '''Settings...''' from the '''Project''' menu.
+
+The window is organized as two tabs:
+# [[Build Tab|Build]]
+# [[Generation Tab|Generation]]
+
+All options are enabled and saved into the project settings file, 'build_project.bpr' as soon as the window is closed.
+
+{{seealso| '''See Also'''
+[[EiffelBuild: Code Generation|Code generation]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/history.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/history.wiki
new file mode 100644
index 00000000..6e90fdb6
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/history.wiki
@@ -0,0 +1,35 @@
+[[Property:title|History]]
+[[Property:weight|11]]
+EiffelBuild has an limitless undo/redo mechanism built in. However, this mechanism only applies to the structure of the [[EiffelBuild Notation|objects]] you are developing in your project.
+
+For example, every time you [[Create an object|create]] , [[Reparent an Object| reparent]] or [[Delete an object|delete]] an [[EiffelBuild Notation|object]] in your project, this is recorded in the history. If you modify properties of an [[EiffelBuild Notation|object]] (Using an [[Object editor|object editor]] ), these modifications are not recorded in the history.
+
+==Undo==
+
+To undo a change, click [[Image:icon-undo-color]] on the [[Main toolbar| main toolbar]] You can repeatedly undo, until you get to the beginning of the history, at which point, this button is disabled.
+
+==Redo==
+
+To redo a change (only applicable after one ore more undo's), click [[Image:icon-redo-color]] on the [[Main toolbar| main toolbar]] . You can repeatedly redo, until the history becomes current again, and at which point, this button is disabled.
+
+==History window==
+
+[[Image:history-window]]
+
+The screenshot above shows the appearance of the history window.
+
+This visibility of the window may be toggled by clicking [[Image:icon-cmd-history-color]] on the [[Main toolbar| main toolbar]] . You may also select '''History''' from the '''View''' menu to show the history window, and click the '''Close''' button to close the window manually.
+
+Looking at the screenshot above, you will see that the last action in the history list is selected. This is always the case while working, until you start undoing your changes. To go back six steps, so that (in this case), there is just the one BUTTON added to the HORIZONTAL_BOX, you could click the undo button on the [[Main toolbar| main toolbar]] six times, or you can simply select the third item in this list. both have the same effect. You can also redo by selecting an item below the currently selection in the history list (Only possible after an undo).
+
+If you execute an action which will be added to the history while the history is not at the final position, all history events after this current position will be removed, and the history will be up to date again.
+
+{{note| '''Note''': If you use the history list to move through many recorded actions at once, there may be a slight delay dependent on the systems complexity and steps moved. }}
+
+{{seealso| '''See also'''
+[[Builder window|Builder window]]
+[[Layout constructor| Layout constructor]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki
new file mode 100644
index 00000000..8fe328fb
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki
@@ -0,0 +1,22 @@
+[[Property:title|EiffelBuild Reference]]
+[[Property:weight|1]]
+* [[EiffelBuild Introduction|EiffelBuild Introduction]]
+* [[EiffelBuild Notation|EiffelBuild Notation]]
+* [[EiffelBuild: General interface description|General interface description]]
+* [[Layout constructor|Layout constructor]]
+* [[Type selector|Type selector]]
+* [[Object editor|Object editor]]
+* [[Display window|Display window]]
+* [[Builder window|Builder window]]
+* [[Component selector|Component selector]]
+* [[Widget selector|Widget selector]]
+* [[Component viewer|Component viewer]]
+* [[History|History]]
+* [[Constants|Constants]]
+* [[EiffelBuild: Project settings window|Project settings]]
+* [[EiffelBuild Preferences|Preferences]]
+* [[EiffelBuild: Code Generation|Code generation]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki
new file mode 100644
index 00000000..2c86c821
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki
@@ -0,0 +1,50 @@
+[[Property:title|Layout constructor]]
+[[Property:weight|3]]
+The layout constructor provides a view of the [[EiffelBuild Notation|objects]] you have defined in your system, in which the [[EiffelBuild Notation|objects]] may be manipulated. The root node of the tree is the object currently selected within the [[Widget selector|widget selector]] and objects may be added/moved within the displayed widget structure by picking and dropping the objects as required. For example, in the screenshot below, you could add another list to the vertical box, by picking a list from the [[Type selector|type selector]] and dropping it on the vertical box object.
+
+[[Image:layout-constructor]]
+
+Each item in the tree represents one object. The screenshot above represents the following [[EiffelVision Introduction|EiffelVision2]] interface definition - An EV_TITLED_WINDOW containing one child, of type EV_VERTICAL_BOX. Within the vertical box there is an EV_HORIZONTAL_BOX and an EV_LIST. The list is empty, but the horizontal box contains three different objects of type EV_BUTTON.
+
+{{note|'''Note''': The widget displayed as the root of the Layout Constructor is the currently selected object in the [[Widget selector|Widget Selector]] . To edit the contents of a different widget, select the widget you wish to manipulate from the [[Widget selector|widget selector]] .}}
+
+The information displayed, only shows you the structure of the [[EiffelBuild Notation|objects]] , and although it gives you an indication of the final appearance of the interface you are building, you cannot see the details of the interface. i.e. color, sizes, tool tips etc. To view an accurate representation of the widget structure you are building, show the [[Display window|Layout window]] .
+
+All [[EiffelBuild Notation|objects]] displayed in the Layout Constructure are [[EiffelBuild Notation|pickable]] , so can be easily manipulated, e.g. [[Delete an object|deleted]] or [[Reparent an Object|reparented]] .
+
+{{note| '''Note''': If the [[EiffelBuild Notation|object]] in the tree has the '''Name''' property set, then the text corresponds to the name, otherwise, the text is the type of the [[EiffelBuild Notation|object]] . }}
+
+If you have just started a new project, then the layout constructor will only contain one tree item, TITLED_WINDOW.
+==Selection==
+
+The currently selected object within the Layout Constructor is automatically targetted to the docked [[Object editor|object editor]] which is situated to the right hand side of the main EiffelBuild Window. This enables you to quickly and easily edit the properties of the selected object. Note that Ctrl-right clicking on an object in the Layout Constructor displays a floating [[Object editor|object editor]] targeted to that object.
+
+==Expanding/Collapsing==
+
+To Expand all of the items displayed in the layout constructor, select '''Expand layout tree''' from the '''View''' menu, or select the small cross icon displayed at the top of the tool.
+
+Similarly, if you wish to collapse all of the items in the layout constructor, select '''Collapse layout tree''' from the '''View''' menu.
+
+
+==Highlighting an Object==
+An [[EiffelBuild Notation|object]] contained in a system may be highlighted in the Layout Constructor by [[EiffelBuild Notation|picking]] it, and [[EiffelBuild Notation|dropping]] on the button displayed at the top of the Layout Constructor. Clicking this button with the mouse has no effect. The ability to highlight an object in this fashion proves to be particularly useful when building directly into the [[Builder window|builder window]] , as a particular object may be quickly highlighted in the Layout Constructor, and its properties edited.
+
+==Locked Objects==
+
+Objects that are instances of other objects are displayed as locked objects within the Layout Constructor as illustrated below:
+[[Image:layout-constructor-locked]]
+The object of type OK_CANCEL_BUTTONS is a locked instance of another object as illustrated by the locked icon displayed on top of it's type icon. As a locked object is simply an instance of another object, its internal structure may not be manipulated directly within the Layout Constructor. To change the structure of a locked object, you must directly change the object of which it is an instance.
+To add a locked object to your interface, simply pick the object that you wish to re-use from the [[Widget selector|widget selector]] and drop it into the desired parent object within the Layout Constructor. In this case, the instance of the OK_CANCEL_BUTTONS object is actually comprised of a number of widgets which may only be modified through manipulation of the original OK_CANCEL_BUTTONS_OBJECT. Changes made to this original object are then applied to all instances within your interface structures.
+
+You may convert an existing widget structure into a locked instance of a widget by picking the object to be used as the root of the structure (may not be locked) and dropping it into the [[Widget selector|widget selector]] . This creates a new "top level" object within the [[Widget selector|widget selector]] and places a locked instance of this at the original location in the widget structure where it was picked from.
+
+{{note| '''Note''': Double clicking on a locked object within the Layout Constructor, targets the object of which it is an instance to the Layout Constructor. }}
+
+{{seealso| '''See Also'''
+[[Builder window|Builder window]]
+[[Object editor|Object editor]]
+[[Display window|Layout window]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/index.wiki
new file mode 100644
index 00000000..a1ee6b3c
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/index.wiki
@@ -0,0 +1,72 @@
+[[Property:title|Object editor]]
+[[Property:weight|5]]
+An object editor is a tool which allows you to edit the properties of a selected [[EiffelBuild Notation|object]] . Common properties include minimum width and height, color, text etc.
+
+An object editor can only reference one [[EiffelBuild Notation|object]] at once, and when not empty, it is considered to be "targeted" to the [[EiffelBuild Notation|object]] whose properties it references.
+
+[[Image:object-editor]]
+
+The screenshot above shows a floating object editor. The docked object editor is almost identical except that it is located within the EiffelBuild main window.
+
+==Docked object editor==
+
+The docked object editor is displayed to the right hand side of the EiffelBuild main window. This editor is always displayed and is permanently linked to the [[Layout constructor| layout constructor]] . This means that whenever the selected [[EiffelBuild Notation|object]] changes in the [[Layout constructor| layout constructor]] , the docked object editor becomes targeted to this [[EiffelBuild Notation|object]] .
+
+==Floating object editors==
+
+These object editors appear in their own window, and you may open as many of these as you wish.
+
+To open a new floating object editor, [[EiffelBuild Notation|drop]] an [[EiffelBuild Notation|object]] on [[Image:icon-object-editor-color]] , displayed in the [[Main toolbar| main toolbar]] and also in each existing object editor. The new object editor will then be targeted to the [[EiffelBuild Notation|object]] that was [[EiffelBuild Notation|dropped]] .
+
+{{note| '''Note''': If the [[EiffelBuild Notation|object]] targeted to floating object editor is deleted, then the editor will be destroyed. This helps stop the screen becoming cluttered with empty editors. }}
+
+As a shortcut to a complete [[EiffelBuild Notation|pick and drop]] transport, you may hold down the Ctrl key while starting the [[EiffelBuild Notation|pick]] , which will immediately open a new floating object editor targeted to the [[EiffelBuild Notation|object]] you clicked.
+
+==General use==
+
+When an object editor is targeted to an [[EiffelBuild Notation|object]] , you will see that controls are available within the editor to customize that [[EiffelBuild Notation|object]] . Although every different type of [[EiffelBuild Notation|object]] will have different sets of properties that may be modified, the manipulation of these properties is as standardized as possible. Below are some general rules that apply:
+* String properties inputted via a text field are updated within the object every time a key is pressed
+* Integer properties inputted via a text field are only updated within the object when return is pressed, or the input box looses the focus.
+* Almost without exception, a push button which controls a property, will open up a dialog, allowing the property to be edited. Examples are colors, pixmaps and events.
+* If when you attempt to modify a property, it returns back to its original value, it means that the value you attempted to enter was invalid. For example, looking at the screen show above, if you enter -50 into the minimum_height text field and press return, it will revert back to 23. This is because the minimum_height of an EV_BUTTON may not be set to less than 0. To find allowable values for properties of an [[EiffelBuild Notation|object]] , consult the [[EiffelVision Introduction|EiffelVision2]] documentation.
+
+All properties that may be manipulated in an object editor correspond directly to a property of the [[EiffelVision Introduction|EiffelVision2]] control that is represented by the [[EiffelBuild Notation|object]] (Displayed in an object editor as '''type'''). There is one exception to that rule though, and that is the '''Name''' field which is specific to EiffelBuild. This field is used for your identification of the [[EiffelBuild Notation|object]] and as the attribute name in the generated code. For example, when EiffelBuild generates code corresponding to the [[EiffelBuild Notation|object]] targeted in the editor shown above, it would declare the vision2 component as - button1: EV_BUTTON
+
+{{note| '''Note''': You may have as many object editors targeted to the same [[EiffelBuild Notation|object]] as you wish. Whenever a change is made to the [[EiffelBuild Notation|object]] through one of the editors, all other editors targeted to that [[EiffelBuild Notation|object]] are synchronized. }}
+
+==Using Constants==
+
+All fields that may use constants have a button marked with the constants symbol [[Image:icon-format-onces-color]] , which when selected, modifies the field to allow selection of the desired constant. A combo box is displayed with all valid constants (matching the type of the property) displayed, from which you may select the constant you wish to use. To remove the use of the constant, simply press the constants button again, which removes the constant, and sets the property to a manifest value representing the previous value of the last selected constant.
+
+==Advanced property manipulation==
+
+Although many of the properties of [[EiffelBuild Notation|objects]] are relatively simple, and can be manipulated with STRING or INTEGER values, there are others that require more complicated control mechanisms. The following [[EiffelBuild Notation|object]] properties have more complicated interfaces warranting further explanation:
+* [[Merging radio button groups]]
+* [[Positioning table children]]
+* [[Positioning fixed children]]
+
+For all "top level" objects (those contained within the [[Widget selector|widget selector]] which are to be generated as individual classes), a check button marked "Generate as client" is available towards the top of the Object Editor. If this is checked, the generated class uses the widget type of the object as a client, otherwise it inherits directly from the widget's class.
+
+==Event connection==
+
+As well as being able to manipulate the standard properties of an [[EiffelBuild Notation|object]] , facilities are provided for connecting to the events of an [[EiffelBuild Notation|object]] . Looking at the object editor screenshot above, you will see that there is a button marked '''Select events''' which is also available in all targeted editors.
+
+{{note| '''Note''': The button will be marked '''Modify events''' when one or more events are already selected for the current [[EiffelBuild Notation|object]] . }}
+
+Clicking this button will cause the following dialog to be displayed:
+
+[[Image:event-selection-dialog]]
+
+Looking at the screenshot above, you will see that this dialog contains all the action_sequences available for the EV_BUTTON to which the object editor is targeted.
+
+If you check a button connected with one of the action sequences, you will be then able to enter the name of a feature that you wish to connect to the action sequence. The screenshot above shows the user has connected a feature named `button_pressed' to the `select_actions'. When [[EiffelBuild: Code Generation|code is generated]] , this will cause EiffelBuild to generate an empty feature named `button_pressed' already connected to the `select_actions' of the button.
+
+{{note| '''Note''': You will only be allowed to enter valid and unique Eiffel feature names. If a name is invalid, it will be highlighted in red, and a dialog will warn you when you attempt to close the dialog. }}
+
+{{seealso| '''See Also'''
+[[Create an object|Create an object]]
+[[Delete an object|Delete an object]] }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/merging-radio-button-groups.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/merging-radio-button-groups.wiki
new file mode 100644
index 00000000..f29b679b
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/merging-radio-button-groups.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Merging radio button groups]]
+[[Property:weight|0]]
+If the current [[Object editor|object editor]] contains an EV_CONTAINER [[EiffelBuild Notation|object]] , then the following control will be available:
+
+[[Image:empty-radio-merge]]
+
+With this control, you can merge two or more instances of EV_CONTAINER together, so that any EV_RADIO_BUTTON contained are grouped.
+
+==Merging==
+
+To create a new merge, [[EiffelBuild Notation|pick]] an [[EiffelBuild Notation|object]] of type EV_CONTAINER, and [[EiffelBuild Notation|drop]] it anywhere on the control. This will merge the radio button group of the EV_CONTAINER referenced in the object editor, to the transported one. Each merge, will show up as a new item in the control.
+{{note| '''Note''': Container objects may only be grouped once, and as such, you will not be permitted to add an [[EiffelBuild Notation|object]] that is already contained in the list. }}
+
+
+==Unmerging==
+
+To unmerge a container [[EiffelBuild Notation|object]] from a group, [[EiffelBuild Notation|pick]] the representation of that [[EiffelBuild Notation|object]] from the list, and [[EiffelBuild Notation|drop]] on [[Image:icon-delete-small-color]] . This will unmerge the [[EiffelBuild Notation|object]] from the current group of containers.
+
+==Locating group member==
+
+To locate the [[EiffelBuild Notation|object]] referenced by a list item in the control, left click the item that you wish to locate. This will display the representation of the associated [[EiffelBuild Notation|object]] within the [[Layout constructor|layout constructor]] , and the associated icon will be animated for a short period of time.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-fixed-children.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-fixed-children.wiki
new file mode 100644
index 00000000..2657f438
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-fixed-children.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Positioning fixed children]]
+[[Property:weight|2]]
+If the current [[EiffelBuild Notation|object]] in the object editor is of type EV_FIXED, a button marked "position children..." will be contained in the object editor. Click this button, to display the following window:
+
+[[Image:fixed-child-positioner]]
+* '''Moving''' - Press and hold the left mouse button within the selected child, and move the mouse.
+* '''Resizing''' - Move the mouse over the border of the child, until the cursor changes to a resize cursor, then press and hold the left mouse button to re-size the child.
+
+{{note| '''Note''': As placing a child in an EV_FIXED does not modify the size of the child, it is possible that some children have a size of 0x0 pixels, and hence do not show up in the diagram. In this case, there will be the following displayed in the status bar "Widget is 0x0 pixels, click HERE to enlarge". If you subsequently click on the status bar, then the widget will be enlarged to a more useful size. }}
+
+==Grid Properties==
+
+The grid properties are displayed in the bottom right hand side of the window. You may modify the following attributes:
+* '''Snap to grid''' - Select this option if you wish all widget coordinates to be snapped to the grid displayed in the window.
+* '''Visible''' - If selected, then the grid is visible.
+* '''Grid size''' - The spacing between grid elements in pixels.
+
+When you have finished manipulating the children of the table, click the button marked "Done" to close the dialog.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-table-children.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-table-children.wiki
new file mode 100644
index 00000000..4583b42e
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-table-children.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Positioning table children]]
+[[Property:weight|1]]
+If the current [[EiffelBuild Notation|object]] in the object editor is of type EV_TABLE, a button marked "position children..." is contained in the object editor. Click this button, to display the following window:
+
+[[Image:table-child-positioner]]
+
+Each of the children are displayed on a grid representing the table cells that each occupies (by default 1x1). To manipulate a child of the table, click the left mouse button inside the desired child, and it will be highlighted in red. You may the manipulate the selected child in the following ways:
+* '''Moving''' - Press and hold the left mouse button within the selected child, and move the mouse.
+* '''Resizing''' - Move the mouse over the border of the child, until the cursor changes to a resize cursor, then press and hold the left mouse button to re-size the child.
+
+{{note| '''Note''': Each child, may only occupy a unique set of cells within the table, and if you attempt to move or re-size a child to an invalid position, it will be displayed in gray. }}
+
+When you have finished manipulating the children of the table, click the button marked "Done" to close the dialog.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/type-selector.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/type-selector.wiki
new file mode 100644
index 00000000..ec24ccac
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/type-selector.wiki
@@ -0,0 +1,40 @@
+[[Property:title|Type selector]]
+[[Property:weight|4]]
+The type selector contains all the available Vision2 types supported by EiffelBuild. These are the basic building blocks for your system.
+
+[[Image:type-selector]]
+
+The types are organized into three groups - Primitives, Containers and Items. All types that may be used in EiffelBuild have a text in uppercase, corresponding to their type in [[EiffelVision Introduction|EiffelVision2]] . For example, looking at the screenshot above, the BUTTON item represents an EV_BUTTON, and the EV_COMBO_BOX item represents EV_COMBO_BOX.
+
+{{note| '''Note''': The types available in the type selector are fixed, and cannot be modified. Almost all [[EiffelVision Introduction|EiffelVision2]] components are available. }}
+
+==Creating a new object==
+[[EiffelBuild Notation|Objects]] are the building blocks used in EiffelBuild to construct your interface. To create a new [[EiffelBuild Notation|object]] for use in your system, [[EiffelBuild Notation|pick]] the type corresponding to the type of object you wish to create,and [[EiffelBuild Notation|drop]] onto an [[EiffelBuild Notation|object]] representation. If an object is full, or does not allow other objects of the new type to be contained, then you will not be able to [[EiffelBuild Notation|drop]] on it.
+
+For example, if you have just started a new project, [[EiffelBuild Notation|pick]] HORIZONTAL_BOX from the type selector, and drop it on the EV_TITLED_WINDOW [[EiffelBuild Notation|object]] displayed in the [[Layout constructor| layout constructor]] . This will build you a new [[EiffelBuild Notation|object]] of type EV_HORIZONTAL_BOX, parented in the window. If you then [[EiffelBuild Notation|pick]] a BUTTON from the type selector, you will not be able to [[EiffelBuild Notation|drop]] it on the EV_TITLED_WINDOW, as a window may only contain one child and is therefore currently full. You may however, [[EiffelBuild Notation|drop]] on the EV_HORIZONTAL_BOX object you had just created, as the box is empty, and has space for multiple children. Doing so, will create a new [[EiffelBuild Notation|object]] of type EV_BUTTON, parented in the box.
+
+This shows how simple it is to Build new [[EiffelBuild Notation|objects]] in EiffelBuild, you just need access to the parent [[EiffelBuild Notation|object]] to [[EiffelBuild Notation|drop]] the selected type into.
+
+You may drop an object directly from the Type Selector into the [[Widget selector|widget selector]] which creates the object as a "top level object" ensuring that upon generation, it is represented by an individual set of classes. These top level objects may then be re-used within your interface as desired.
+
+{{note| '''Note''': To understand the types accepted, and the capacity of objects, you should consult the [[EiffelVision Introduction|EiffelVision2]] library reference. }}
+
+==Changing the type of an existing object==
+
+Why would you want to change the type of an existing [[EiffelBuild Notation|object]] , when you could just delete it and create a new [[EiffelBuild Notation|object]] ?
+
+Imagine you have spent some time constructing a complicated interface. You have an EV_VERTICAL_BOX with children many levels deep. You realize that you wanted the EV_VERTICAL_BOX to be of type EV_HORIZONTAL_BOX. If you delete the object, all children contained will also be deleted, which in this case, is not what you want. Changing the type of the object does actually delete the object internally, but will automatically re-parent all of its children into the new object.
+
+To perform a type change, [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|object]] that you wish to change, and [[EiffelBuild Notation|drop]] it on an item in the type selector representing the desired new type. All existing children of the old [[EiffelBuild Notation|object]] will be automatically re-parented in the new object.
+
+The following rules govern if the type of an existing object may be changed to a new type:
+* The parent of the existing [[EiffelBuild Notation|object]] must accept children of type corresponding to the new type.
+* The new type must be able to accept all of the existing [[EiffelBuild Notation|objects]] children.
+
+{{seealso| '''See Also'''
+[[Layout constructor|Layout constructor]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/widget-selector.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/widget-selector.wiki
new file mode 100644
index 00000000..bfdc6ebc
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-reference/widget-selector.wiki
@@ -0,0 +1,59 @@
+[[Property:title|Widget selector]]
+[[Property:weight|9]]
+The Widget Selector allows you to manage windows, dialogs and "top level" objects within the EiffelBuild project, with all windows accessible through this tool. Using the widget selector, you may add new windows to your project; delete windows; assign a root window (launched from the generated application); and group windows into directories. All objects contained in the Widget Selector are generated as individual classes at generation time. The Widget Selector has the following appearance:
+
+[[Image:window-selector]]
+
+==Adding Objects==
+
+To add an Object to your project, [[EiffelBuild Notation|pick]] the object type from the [[Type selector|type selector]] , and [[EiffelBuild Notation|drop]] into the Widget Selector. There are two possible drop targets within the widget selector:
+* '''The Widget Selector itself''' - The newly created object is added to the root directory of the project.
+* '''A Directory node''' - The newly created object is added to the directory that was the target of the drop.
+Both of these outcomes create a new object in your project that is to be generated as an individual class during code generation.
+{{note| '''Note''': The selected object in the Widget Selector is automatically targeted as the root window of the [[Layout constructor|layout constructor]] , permitting building. You may not build directly into the representation of an object within the Widget Selector, as this must be performed within the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] . }}
+
+
+==Root Window==
+
+The root window of a project is launched by the application class of the generated EiffelBuild project when executed. By assigning a window as a root, you ensure that it will be displayed on screen as the "root" window of the generated system when the system is launched.
+
+The root window of the project is highlighted with a star, indicating that it is the root. Looking at the screenshot at the top of this page, the window named "main_window" is currently flagged as the root window of the project. To set a window as the root window of the project, select the window in the Widget Selector, and press the [[Image:icon-titled-window-main-small-color]] button displayed at the top of the Widget Selector.
+==Directories==
+
+The ability to add directories to your project permit organization of objects into sub groups as necessitated by your design. To add a directory to the project, select the [[Image:icon-new-cluster-small-color]] button displayed at the top of the Widget Selector, which displays the following dialog, prompting for the name of the directory to add:
+
+[[Image:new-directory-dialog]]
+
+Enter a unique name that is not already in use, and select "OK" to add the directory to your project. The newly added directory is then visible, as a node in the Widget Selector.
+
+{{note| '''Note''': Creating a new directory in the Widget Selector causes the actual directory on the disk to be created immediately. }}
+
+You may insert objects into a directory, or move an object between directories by [[EiffelBuild Notation|picking]] the object from its representation in the Widget Selector, and [[EiffelBuild Notation|dropping]] on the desired directory. Each object contained in the Widget Selector is generated as a seperate class and the parent directory is used as the generated location on disk.
+{{note| '''Note''': If you move an object between directories within an EiffelBuild project that has already generated the Eiffel code for that object, the code files are moved immediately on the disk. }}
+
+Directories may be nested as deeply as required, and the following buttons are available to help with directory nesting:
+* [[Image:directory-search-small]] Selecting this button recursively adds all directories from the current project location to the project.
+* [[Image:icon-show-hide-directory-color]] Selecting this button causes all directories included within the project that do not contain one or more objects to be hidden/shown within the Widget Selector.
+Note that any directories that do not contain objects or have object nested within their structure recursively are displayed grayed out to indicate that there are no objects within.
+==Expanding==
+
+The [[Image:icon-expand-all-small-color]] button displayed at the top of the Widget Selector expands all nodes contained.
+
+==Client Representations==
+
+All objects within the Widget Selector that are used as clients within other object structures have client information displayed as subnodes of their representation, as illustrated in the following screenshot:
+
+[[Image:images/eiffelbuild/screenshots/widget_selector_clients.png]]
+
+The OK_CANCEL_BUTTONS object is used is used in two different places within the project: once within INPUT_DIALOG and once within MAIN_WINDOW. If you select the tree node representing the instance of OK_CANCEL_BUTTONS within MAIN_WINDOW, the MAIN_WINDOW is targetted to the [[Type selector|type selector]] with the instance of the OK_CANCEL_BUTTONS object selected.
+
+To use an instance of a widget contained within the Widget Selector as a client, simply pick the representation of the object and drop into the desired parent object within the [[Type selector|type selector]]
+
+{{seealso| '''See also''':
+[[Layout constructor|Layout constructor]] }}
+
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-version-history.wiki b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-version-history.wiki
new file mode 100644
index 00000000..34748cff
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/eiffelbuild-version-history.wiki
@@ -0,0 +1,60 @@
+[[Property:title|EiffelBuild Version History]]
+[[Property:weight|2]]
+==6.2 Release==
+
+No changes.
+
+==6.1 Release==
+
+No changes.
+
+==6.0 Release==
+* Code generation includes the facility of closing the application when last window is closed.
+* The EiffelBuild binary has been renamed into '''esbuilder'''.
+* Fixed crash when generating code which included a combo box in read-only mode.
+* Fixed bug#12920 where pressing a digit while dropping was not adding x-time the selected widgets (where x is the digit pressed).
+* Fixed bug#12210 where pixmaps set on a menu would be incorrectly displayed in the generated executable (The last added one will always be shown for all menu entries with a pixmap).
+* Fixed bug#11878 where EiffelBuild would crash when saving a project just after removing an event.
+* Fixed bug#11738 where EiffelBuild would crash when picking and dropping a top level widget into the Generate button.
+
+==5.7 Release==
+* Fixed positioning bug when moving items within their current parent by dropping on another item in that parent with the shift key held down.
+* Fixed bug where modifying the "User can resize" property of a window while the tools were always shown on top stopped the tools from being shown on top.
+* Added support for multi-line tooltips.
+* Added support for `is_item_expanded' from EV_SPLIT_AREA.
+* Added the ability to specify a directory for generation, into which location all files are to be generated.
+* Event selection dialogs now contain the name of the object to which they refer in their title for cases where multiple dialogs are open simultaneously
+* The project settings dialog is now completely navigatable via the keyboard on Windows platforms.
+* Added support for Ctrl+Z and Ctrl+Y to navigate through the history.
+* The font selection dialog now shows the currently selected font when displayed.
+* Deleting an object that is contained within an object editor now clears the contents of the object editor.
+* Preferences window now has the focus when displayed so it is fully navigatable via the keyboard.
+* Code generation improved to allow the modifying of constants and subsequent update of the interface, permitting multiple languages to be supported.
+
+==5.6 Release==
+* Added support for the generation of any widget as a class. You now may place widgets within the "Widget Selector" to enable this. The "Widget Selector" is simply the old "Widget Selector" renamed.
+* Added clipboard functionality, permitting the copying/pasting of objects.
+* Added support for new constant types: Font and Color.
+
+==5.5 Release==
+* Added support for EV_RICH_TEXT which has been added to EiffelVision2.
+* Notebook item texts may now be set to string constants.
+* Better support for corrupt installations with warning dialogs now displayed.
+* Fixed bug with generated code for notebooks often hiding the first item when they were actually displayed.
+
+==5.4 Release==
+* Added support for multiple windows, including dialogs.
+* Added support for constants of type Integer, String, Directory and Pixmap.
+* New tool, "Widget Selector" added to handle organization of windows, including the ability to define subdirectories in a project, and group windows accordingly.
+* Tip of the day dialog added.
+* Recent projects are now available from the "File" menu.
+* The contents of EiffelBuild projects may now be imported.
+* The ability to reset the minimum dimensions of widgets have been added. In the previous version, it was not possible to complete undo the effects of setting a widgets minimum size.
+* Preferences added, which allow you to customize the default behavior of EiffelBuild. For example, dialogs may be displayed or hidden as desired.
+* The layout of EiffelBuild and its tools is now maintained between sessions.
+* Docking added, permitting the re-ordering of particular tools within the interface, including making them "float" externally.
+* Smarter code generation options, permitting only named attributes to be exported.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelbuild/index.wiki b/documentation/current/solutions/gui-building/eiffelbuild/index.wiki
new file mode 100644
index 00000000..34239d28
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelbuild/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelBuild]]
+[[Property:weight|0]]
+Type: Tool
+Platform: Any
+Version: 5.4
+Availability: Student and Enterprise versions.
+
+See:
+* [[EiffelBuild Introduction|Introduction]]
+* [[EiffelBuild How To's|How To's]]
+* [[EiffelBuild Reference|Reference]]
+* [[EiffelBuild Version History|Version History]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki
new file mode 100644
index 00000000..314135ba
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki
@@ -0,0 +1,31 @@
+[[Property:title|Accelerator Sample]]
+[[Property:weight|0]]
+[[Image:accelerator|accelerator]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\vision2\accelerator\''.
+* Choose ''accelerator.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+After launching the application, you will see a window displayed with a similar appearance to the one above. When the window has the focus, the key combination Ctrl + Q will exit the application.
+==Under the Hood==
+An EV_ACCELERATOR is created and associated with the EV_TITLED_WINDOW used for the main window of the application. The association is made by adding the accelerator to the accelerators list of the window.
+This sample contains the following class:
+* ACCELERATOR
+
+
+{{seealso| '''See Also'''
+[[ref:/libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]]
+[[ref:/libraries/vision2/reference/ev_key_chart|EV_KEY]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/cursor-sample.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/cursor-sample.wiki
new file mode 100644
index 00000000..2618c282
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/cursor-sample.wiki
@@ -0,0 +1,32 @@
+[[Property:title|Cursor Sample]]
+[[Property:weight|1]]
+[[Image:cursor-test|cursor_test]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\vision2\cursor\''.
+* Choose ''cursor.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. Selecting "File", "Close" or pressing the close icon at any time will exit the application.
+
+To the right hand side of the window you will see an EV_MULTI_COLUMN_LIST containing rows, each with an associated EV_PIXMAP. If you select one of the rows of the list, then press the button marked "Apply", the cursor displayed when over the label displayed to the right hand side of the window will be pixmap of the currently selected list row.
+==Under the Hood==
+
+The pixmaps used in the EV_MULTI_COLUMN_LIST were standard pixmaps provided with vision2, accessible through EV_STOCK_PIXMAPS. set_pixmap was used to set the EV_PIXMAP of the EV_MULTI_COLUMN_LIST_ROW. An agent was added to the select_actions of the EV_BUTTON which calls set_pointer_style on the desired widget.
+
+This sample contains the following class:
+* CURSOR_TEST
+
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/gauges-sample.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/gauges-sample.wiki
new file mode 100644
index 00000000..5d077bb3
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/gauges-sample.wiki
@@ -0,0 +1,37 @@
+[[Property:title|Gauges Sample]]
+[[Property:weight|2]]
+[[Image:gauges|gauges]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\vision2\gauges\''.
+* Choose ''gauges.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. The spin buttons at the top of the window control the current minimum, maximum and value of the three gauges displayed below. Modifying the values of the spin buttons will alter the three gauges in real time. Also, if you interact with one of the three gauges, any change in one, will be reflected in the others and in the spin buttons.
+
+==Under the Hood==
+
+The change_actions of each EV_GAUGE are used to synchronize all of the gauges.
+
+This sample contains the following class:
+* GAUGES
+
+
+{{seealso| '''See Also'''
+EV_GAUGE
+EV_SCROLL_BAR
+EV_RANGE
+EV_PROGRESS_BAR
+EV_SPIN_BUTTON }}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki
new file mode 100644
index 00000000..11691ca7
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|EiffelVision 2 Samples]]
+[[Property:weight|3]]
+Vision2 ships with a number of samples provided to demonstrate different aspects of the library. If you are a new vision2 user then it is suggested that you first compile and run the [[Widgets Sample|Widgets]] sample. This will demonstrate both the appearance and behavior of the available widgets.
+
+The other samples provided are listed below:
+* [[Accelerator Sample|Accelerator]] - Demonstrates the use of an [[ref:/libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]] .
+* [[Cursor Sample|Cursor]] - Demonstrates how to modify the displayed [[ref:/libraries/vision2/reference/ev_cursor_chart|EV_CURSOR]] for an [[ref:/libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] .
+* [[Gauges Sample|Gauges]] - Demonstrates different types of [[ref:/libraries/vision2/reference/ev_gauge_chart|EV_GAUGE]] .
+* [[Standard_dialogs Sample|Standard_dialogs]] - Demonstrates different types of [[ref:/libraries/vision2/reference/ev_standard_dialog_chart|EV_STANDARD_DIALOG]] .
+* [[Viewport Sample|Viewport]] - Demonstrates [[ref:/libraries/vision2/reference/ev_viewport_chart|EV_VIEWPORT]] .
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/standard-dialogs-sample.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/standard-dialogs-sample.wiki
new file mode 100644
index 00000000..160a2dbe
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/standard-dialogs-sample.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Standard_dialogs Sample]]
+[[Property:weight|3]]
+[[Image:standard-dialogs|Standard_dialogs]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\vision2\standard_dialogs\''.
+* Choose ''standard_dialogs.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. If you select an item from the "Standard Dialog" menu, a dialog of that type will be displayed. Selecting "Exit" from the "File" menu will exit the application.
+
+==Under the Hood==
+
+This sample contains the following class:
+* STANDARD_DIALOGS
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki
new file mode 100644
index 00000000..7ae9fb53
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki
@@ -0,0 +1,36 @@
+[[Property:title|Viewport Sample]]
+[[Property:weight|4]]
+[[Image:viewport|viewport]]
+
+
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\vision2\viewport\''.
+* Choose ''viewport.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. Modifying the values of the spin buttons will alter the position of the pixmapped button, relative to the viewport in which it is contained.
+
+==Under the Hood==
+
+The features set_x_offset and set_y_offset are used to modify the position of the EV_VIEWPORT relative to the EV_BUTTON contained within.
+
+This sample contains the following class:
+* VIEWPORT
+
+
+{{seealso| '''See Also'''
+EV_VIEWPORT
+EV_SPIN_BUTTON
+[[ref:/libraries/vision2/reference/ev_button_chart|EV_BUTTON]]
+}}
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/widgets-sample.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/widgets-sample.wiki
new file mode 100644
index 00000000..5bdc6ba0
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/widgets-sample.wiki
@@ -0,0 +1,44 @@
+[[Property:title|Widgets Sample]]
+[[Property:weight|-1]]
+[[Image:widgets|widgets]]
+
+
+==Compiling==
+
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\vision2\widgets\''.
+* Choose ''widgets.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+==Running==
+
+After launching the application, you will see a window displayed with a similar appearance to the one above. You may exit the application at any time, by clicking on the close icon, or you may select "exit" from the "File" menu. Selected "Help", "about" displays a dialog with details about the application.
+
+The left hand side of the main window contains a tree, showing the widgets available within vision2. If you select one of these widgets in the tree, then the type of widget you selected will be displayed in the middle of the main_window. Controls will also the be available to the right hand side of the widget, which allow you to modify its state. These controls do not represent all the available feature of the widget, but demonstrate many of the most common. The text area below the currently selected widget displays the events that have occurred on the widget. Only those events inherited by EV_WIDGET are displayed.
+
+==Under the Hood==
+
+This sample contains the following classes:
+* ABOUT_DIALOG
+* COLORIZABLE_CONTROL
+* CONTAINER_CONTROL
+* DESELECTABLE_CONTROL
+* DRAWABLE_CONTROL
+* GAUGE_CONTROL
+* ITEM_LIST_CONTROL
+* MAIN_WINDOW
+* PIXMAPABLE_CONTROL
+* SELECTABLE_CONTROL
+* SENSITIVE_CONTROL
+* TEXT_COMPONENT_CONTROL
+* TEXTABLE_CONTROL
+* WIDGET_CONTROL
+* WIDGETS
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki
new file mode 100644
index 00000000..7472e26a
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki
@@ -0,0 +1,62 @@
+[[Property:title|EiffelVision Introduction]]
+[[Property:weight|0]]
+The EiffelVision library offers an object-oriented framework for graphical user interface (GUI) development. Using EiffelVision, developers can access all necessary GUI components, called [[Widgets|widgets]] (buttons, windows, list views) as well as truly graphical elements such as points, lines, arcs, polygons and the like -- to develop a modern, functional and good-looking graphical interactive application.
+
+EiffelVision has played a major role at Eiffel Software and provided numerous Eiffel projects with a powerful, portable graphics development platform. EiffelStudio is totally reliant on EiffelVision for its graphical elements and overall interaction with the user.
+* [[EiffelVision Interface Content|Content]]
+* [[EiffelVision 2 Samples|Samples]]
+* [[ref:libraries/vision2/reference/index|Reference]]
+
+==Scope==
+
+The EiffelVision library addresses all the major needs of developers of systems supporting modern graphical interfaces. EiffelVision runs on Microsoft Windows and all major variations of Unix (including Linux). All versions are fully source-compatible; with only a recompile, applications will run on every supported platform with the native look-and-feel.
+
+EiffelVision provides an effective way of building advanced graphical applications using user interface standards and toolkits (such as Microsoft Windows and GTK) without having to learn the details of the toolkits. Instead, you can use EiffelVision to work entirely in terms of high level abstractions representing windows, buttons, labels, graphical figures, menus, buttons etc., and apply clearly understandable operations to the corresponding objects.
+
+==Architecture==
+
+EiffelVision relies on a two-tiered architecture illustrated by the following figure.
+ [[Image:vision2--figure1]]
+The two tiers play complementary roles:
+* At the top level, EiffelVision provides fully portable graphics.
+* At the lower level, platform-specific libraries cover the graphical mechanisms of graphics platforms such as Windows and GTK.
+
+The lower tier serves for the implementation of the upper tier, but can also be used independently. For example [[WEL Introduction|WEL]] has had a resounding success with Windows developers who need an advanced mechanism for building Windows-specific graphical applications, taking advantage of every facility of the Windows API (Application Programming Interface) and of the Eiffel approach, but do not need portability on the client side. The GEL library is a '''wrapper''' library, automatically generated from the entire GTK API by a tool named '''The Gote Converter'''.
+
+==Features==
+
+As stated before, the library has undergone some drastic changes since the previous release. Names have been changed to improve consistency. Contracts are added wherever possible. Following is a summary of the other re-engineered aspects of the library:
+* Taking full advantage of the '''agent''' mechanism of Eiffel, [[Events|events]] are now triggered through '''action sequences''' (lists of actions) that will be executed in order. This system does not require separate classes to be written for each event, however the command pattern can still be used if desired.
+* The [[EiffelVision Pick and Drop|pick-and-drop]] mechanism now relies on the Eiffel type system. A '''stone''' (some transportable object) is now any Eiffel class and can always be dropped on a widget that accepts the type (or a more general type) of that stone.
+* [[Containers|containers]] ( [[Widgets|widgets]] that contain other [[Widgets|widgets]] ) are now derived from [[EiffelBase Introduction|EiffelBase]] classes. For example you can now insert [[Widgets|widgets]] in any position and iterate over them.
+
+==Design==
+
+EiffelVision provides programmers with high-level classes, that provide all mechanism and data structures needed to build advanced user interfaces for deployment on almost all platforms without having to worry about detailed requirements of toolkits.
+
+The abstract design has been derived from an analysis of user interfaces. Therefore we have classes with names like MENU, WINDOW, BUTTON, LINE or POLYGON. The features of these classes are simple, clearly defined properties or commands, like the feature `minimize' (a command) on WINDOW or `text' (a property of type STRING) on BUTTON.
+
+{{note| '''Note''': all class names in EiffelVision are pre-pended with EV_ to avoid name clashes with existing classes. BUTTON hence becomes EV_BUTTON, etc. }}
+
+==Properties==
+
+When talking about a property of a class, like `text', in fact we are talking about multiple features. One is a query of the state of the property, in this case simply the query `text'. The other is the set-routine, which is by convention named `set_text' taking exactly one argument of the type of property. A property can be read-only, which means that it cannot be set by clients of the class.
+
+ text: STRING
+ set_text (a_text: STRING) is ...
+
+
+Boolean properties have a different convention. Instead of one set-routine, it has one enable-routine and one disable-routine. The first one sets the property to true, the second to false. This has been done like this because sometimes these enable/disable features have trivial equivalents, for example for feature `enable_visible' a clearer name is `show'.
+
+ is_sensitive: BOOLEAN
+ enable_sensitive is ...
+ disable_sensitive is ...
+
+
+==Implementation==
+
+For flexibility, EiffelVision is built using the bridge pattern. This means that every platform-dependent component of the library consist of two classes, plus an implementation class for each platform (currently two). One is the interface. All the features of interfaces do nothing except delegate the call to the implementation object which is coupled to it. This object has the static type of the implementation-interface with the name of the interface class, with _I appended to it. From this implementation-interface, implementation classes inherit to implement platform-specific features.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki
new file mode 100644
index 00000000..a7bfc4fe
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Events]]
+[[Property:weight|4]]
+This cluster contains classes for event handling within Vision2.
+
+==What is an event?==
+
+An event is considered to be an external action that occurs during a program's execution. Correctly dealing with events is an important part of developing a Vision2 application. For example, if a user clicks on a button, you will want to respond to this event by calling a routine that deals with the request. Vision2 contains action sequences for all kinds of widget events. To view the kind of events available to every widget, click [[ref:libraries/vision2/reference/ev_widget_action_sequences_chart|here]] .
+
+==How do I connect to an event?==
+
+Every widget and item has an action sequence associated with it that relates to some kind of event. For example an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] has a select_actions action sequence. This gets fired when the user clicks/selects the button. To have a procedure called on this event, you need to create an agent based on this procedure, and then add this to the action sequence (via extend). For a more detailed description of agents and their uses click [[11 Agents|here]] .
+
+An example of adding an agent to an action_sequence is as follows.
+
+ button.select_actions.extend (agent print ("Button Clicked!%N"))
+
+
+All Vision2 action sequences inherit [[ref:libraries/vision2/reference/ev_action_sequence_chart|EV_ACTION_SEQUENCE]] and when it is called, all of the agents held within are fired, thus calling all of the procedures represented by the agents. The signature of any agent that you place in an action sequence must conform to those of the action sequences actual generic parameter.
+
+When you want an agent to be called from a certain action sequence and the signatures do not match, you may use [[ref:libraries/vision2/reference/ev_action_sequence_chart|force_extend]] . This will call your agent but has no guarantees on the arguments passed to your procedure.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki
new file mode 100644
index 00000000..9c94dd5e
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki
@@ -0,0 +1,150 @@
+[[Property:title|Figures]]
+[[Property:weight|7]]
+The EiffelVision figure cluster can be considered a high-level way of drawing on an [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] descendant. Here are some advantages:
+* The model is separated from the representation by using projectors that take a world of figures and project it to any device, not just a drawing area.
+* Instead of drawing with static API's like draw_line, real figure objects are used that can move, change color or morph.
+* For projection devices that allow this, events may be caught and fired through the appropriate figure object.
+
+==Figure classes==
+
+Every basic figure class inherits from [[ref:libraries/vision2/reference/ev_atomic_figure_chart|EV_ATOMIC_FIGURE]] . An atomic figure has the property of having a representation. [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] on the other hand does not but is a collection of figures. On the top of those two stands [[ref:libraries/vision2/reference/ev_figure_chart|EV_FIGURE]] as common ancestor. As [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] is a collection of EV_FIGUREs, it can contain subgroups.
+
+As top-level group of a world of figures you must use [[ref:libraries/vision2/reference/ev_figure_world_chart|EV_FIGURE_WORLD]] . It inherits from [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] but adds some features for grid and background color.
+
+===Figures===
+{| border="1"
+|-
+| class
+| open/closed
+| points
+| description
+|-
+| [[ref:libraries/vision2/reference/ev_figure_arc_chart|EV_FIGURE_ARC]]
+| open
+| 2
+| a segment of an open ellipse
+|-
+| [[ref:libraries/vision2/reference/ev_figure_dot_chart|EV_FIGURE_DOT]]
+| open
+| 1
+| a single point
+|-
+| [[ref:libraries/vision2/reference/ev_figure_ellipse_chart|EV_FIGURE_ELLIPSE]]
+| closed
+| 2
+| ellipse inside imaginary rectangle
+|-
+| [[ref:libraries/vision2/reference/ev_figure_equilateral_chart|EV_FIGURE_EQUILATERAL]]
+| closed
+| 2
+| a figure with any number of sides of the same length
+|-
+| [[ref:libraries/vision2/reference/ev_figure_line_chart|EV_FIGURE_LINE]]
+| open
+| 2
+| a straight line between two points
+|-
+| [[ref:libraries/vision2/reference/ev_figure_picture_chart|EV_FIGURE_PICTURE]]
+| open
+| 1
+| an image positioned by its top-left point
+|-
+| [[ref:libraries/vision2/reference/ev_figure_pie_slice_chart|EV_FIGURE_PIE_SLICE]]
+| closed
+| 2
+| a part of a closed ellipse
+|-
+| [[ref:libraries/vision2/reference/ev_figure_polygon_chart|EV_FIGURE_POLYGON]]
+| closed
+| *
+| a figure defined by any number of points
+|-
+| [[ref:libraries/vision2/reference/ev_figure_polyline_chart|EV_FIGURE_POLYLINE]]
+| open
+| *
+| a figure consisting of any number of connecting lines
+|-
+| [[ref:libraries/vision2/reference/ev_figure_rectangle_chart|EV_FIGURE_RECTANGLE]]
+| closed
+| 2
+| figure with four sides
+|-
+| [[ref:libraries/vision2/reference/ev_figure_star_chart|EV_FIGURE_STAR]]
+| open
+| 2
+| any number of lines emerging from a center point
+|-
+| [[ref:libraries/vision2/reference/ev_figure_text_chart|EV_FIGURE_TEXT]]
+| open
+| 1
+| a string positioned by its top-left point displayed in the specified font
+|}
+
+A closed figure is a figure that has some area enclosed when drawn that can optionally be filled with a color. Closed figures inherit [[ref:libraries/vision2/reference/ev_closed_figure_chart|EV_CLOSED_FIGURE]] which gives them the property fill_color. Open figures inherit [[ref:libraries/vision2/reference/ev_atomic_figure_chart|EV_ATOMIC_FIGURE]] directly just as [[ref:libraries/vision2/reference/ev_closed_figure_chart|EV_CLOSED_FIGURE]] .
+===Points===
+
+Central in the design of the figures are points. Figures are built up as much from points as possible. For example, an ellipse is not a center point with two radii, but the biggest fitting ellipse inside an imaginary rectangle, so of two points.
+
+As you can see in the table above, each figure has a certain number of points. These values can be 1, 2 or * (any number). For each value there is a class the figure inherits from. These classes are:
+* 1 (a figure has one point): [[ref:libraries/vision2/reference/ev_single_pointed_figure_chart|EV_SINGLE_POINTED_FIGURE]] .
+* 2 (a figure has two points): [[ref:libraries/vision2/reference/ev_double_pointed_figure_chart|EV_DOUBLE_POINTED_FIGURE]] .
+* * (a figure has zero or more points): [[ref:libraries/vision2/reference/ev_multi_pointed_figure_chart|EV_MULTI_POINTED_FIGURE]] .
+
+These classes offer features to handle the given number of points. [[ref:libraries/vision2/reference/ev_single_pointed_figure_chart|EV_SINGLE_POINTED_FIGURE]] offers the feature:
+ point: EV_RELATIVE_POINT
+
+[[ref:libraries/vision2/reference/ev_double_pointed_figure_chart|EV_DOUBLE_POINTED_FIGURE]] inherits [[ref:libraries/vision2/reference/ev_single_pointed_figure_chart|EV_SINGLE_POINTED_FIGURE]] for its first point, which is renamed to point_a. It adds point_b, so it has the features:
+
+ point_a: EV_RELATIVE_POINT
+ point_b: EV_RELATIVE_POINT
+
+
+[[ref:libraries/vision2/reference/ev_multi_pointed_figure_chart|EV_MULTI_POINTED_FIGURE]] internally holds an array of points. Its most important feature is:
+
+ i_th_point (i: INTEGER): EV_RELATIVE_POINT
+
+
+===Relative point===
+
+The points that the figures use are of type [[ref:libraries/vision2/reference/ev_relative_point_chart|EV_RELATIVE_POINT]] . Each point is relative to another point, which is also relative. Each point is a set of coordinates and a reference point. The absolute coordinates are calculated only when needed by adding the absolute coordinates of the reference point to the relative coordinates.
+
+==Figure worlds==
+
+In order to put the figures you want to display in a context, you have to insert them in a figure world object, an instance of [[ref:libraries/vision2/reference/ev_figure_world_chart|EV_FIGURE_WORLD]] . This is a descendant of [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] and hence works in the same way. This figure world is later associated with one or more projectors.
+[[ref:libraries/vision2/reference/ev_figure_world_chart|EV_FIGURE_WORLD]] adds a number of features to [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] . These extra features are needed for the representation by a projector. One is the background color. This feature will be used to erase the canvas for a graphical projector in the specified color. The other features are to manage the grid.
+==Projectors==
+
+A projector is an object that knows what a figure world should look like. The figure world itself is not more than a hint towards its representation. For example, if a line is "20" long, this unit might mean pixels, miles, centimeters or whatever. It is up to the projector to interpret units. Also, color might be interpreted as gray scale. Typically, a projector will do the best possible job projecting the world to its device.
+
+With EiffelVision come these projectors:
+* [[ref:libraries/vision2/reference/ev_postscript_projector_chart|EV_POSTSCRIPT_PROJECTOR]]
+* [[ref:libraries/vision2/reference/ev_drawing_area_projector_chart|EV_DRAWING_AREA_PROJECTOR]]
+* [[ref:libraries/vision2/reference/ev_pixmap_projector_chart|EV_PIXMAP_PROJECTOR]]
+The first one maps figure worlds to a postscript file. The other two are descendants of [[ref:libraries/vision2/reference/ev_widget_projector_chart|EV_WIDGET_PROJECTOR]] , and can project on widgets that inherit [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] : [[ref:libraries/vision2/reference/ev_drawing_area_chart|EV_DRAWING_AREA]] and [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] , eventually using double-buffering, which results in a more smooth animation but requires fast copying from memory to the video buffer (can be slow for a remote display).
+==Events==
+The other features of drawing area and widget is that they generate pointer events. These events can be translated by projectors to map the figure world. These projectors send the event to the appropriate figure. Every figure has all common pointer action sequences:
+* pointer_motion_actions
+* pointer_button_press_actions
+* pointer_double_press_actions
+* pointer_button_release_actions
+* pointer_enter_actions
+* pointer_leave_actions
+* pick_actions
+* conforming_pick_actions
+* drop_actions
+There are no events for keyboard focus and no key press events. In case you wish to use these events, use the ones of the pixmap or drawing area.
+
+When using events, keep the z-order in mind. This is the order in which the figures are stacked in the world. The first item of a figure group is the figure that is the farthest away. This means that the figure is obscured by any figures which are in front of it, and events will also not be propagated to this figure in that case.
+==Rotation and scaling==
+
+The relative points also support rotation and scaling. These factors work just like coordinates, except scaling, which is multiplied instead of added in the chain of points. This means that when a relative point which is the root of a tree of several points is moved, the entire tree is moved, when it is scaled the entire tree is scaled and same for rotation.
+
+The scaling factor is divided into a horizontal and vertical component. If the factor is 0.5, everything is displayed at half its size. The rotation factor is in radians.
+
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki
new file mode 100644
index 00000000..f7074fd0
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki
@@ -0,0 +1,18 @@
+[[Property:title|EiffelVision Interface Content]]
+[[Property:link_title|EiffelVision Library Reference Manual]]
+[[Property:weight|1]]
+EiffelVision 2 is a platform independent Graphical User Interface (GUI) library that allows easy, simultaneous development of Windowed applications for both Windows & Unix based platforms. Heavily relying on EiffelBase library, EiffelVision 2 has been designed primarily with ease of use in mind. By reusing EiffelBase structures, existing, as well as new Eiffel users will find EiffelVision to be surprising intuitive and easy to use. In no time, users will be producing good-looking Windowed application skeletons, of which will run on a multitude of platforms with no manipulation of code.
+The EiffelVision 2 library includes the following interface clusters:
+* A [[Kernel| kernel]] cluster that includes classes that are key to a Vision2 application. The main class being [[ref:libraries/vision2/reference/ev_application_chart| EV_APPLICATION]] which is the main entry point of all Vision2 applications.
+* A [[Widgets| widgets]] cluster containing classes that used to create Vision2 widgets. Widgets are the visible objects that the user sees and interacts with on the desktop, examples of widgets are windows, buttons and labels.
+* An [[Items| items]] cluster includes the classes needed to create items, items can be thought of as widgets that are contained within only a certain type of widget, such as an [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]] that may only contain objects of type [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]] . Items provide an abstract way of dealing with an item widget's internal data structures and provide in many cases the same functionality that a widget does.
+* An [[Events| events]] cluster containing classes that allow for user initiated events, such as the clicking of a button to be dealt with via the use of a linked list of agents ( [[ref:libraries/vision2/reference/ev_action_sequence_chart|EV_ACTION_SEQUENCE]] ). Agents can be thought of as an object that encapsulates a certain procedure. When a user clicks a button on the screen, the corresponding [[ref:libraries/vision2/reference/ev_button_chart| EV_BUTTON]] object has its associating pointer_button_press_actions fired and this in turn, fires all of the agents held within, thus calling all of the procedures represented by the agents. Every widget and item has a certain number of [[ref:libraries/base/reference/action_sequence_chart|ACTION_SEQUENCE]] objects that are linked with a certain type of event.
+* A [[Properties| properties]] cluster contains classes that allow for the customization of Vision 2 widgets and items. Classes such as [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]] and [[ref:libraries/vision2/reference/ev_fontable_chart|EV_FONTABLE]] contain routines that allow for color and fonts to be altered for a widget or item respectively.
+* A [[Support| support]] cluster includes classes that provide more professional touches to an application, whether these are keyboard shortcuts ( [[ref:libraries/vision2/reference/ev_accelerator_list_chart|EV_ACCELERATOR_LIST]] ) or graphical output ( [[ref:libraries/vision2/reference/ev_graphical_format_chart|EV_GRAPHICAL_FORMAT]] ) for drawable widgets such as [[ref:/libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] .
+* A [[Figures| figures]] cluster that allows for the projection of two-dimensional shapes (figures) on to an [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] or printer via the use of an [[ref:libraries/vision2/reference/ev_projector_chart|EV_PROJECTOR]] .
+
+To see differences between released versions of EiffelVision, click [[Revisions and Bug Fixes|Here]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki
new file mode 100644
index 00000000..3438a8bd
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki
@@ -0,0 +1,52 @@
+[[Property:title|Items]]
+[[Property:weight|3]]
+All Vision2 items inherit [[ref:libraries/vision2/reference/ev_item_chart|EV_ITEM]] .
+
+==What is an item?==
+
+A Vision2 item is an object that is used to display information within certain primitives. For example, [[ref:libraries/vision2/reference/ev_list_chart|EV_LIST]] may hold items of type [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]] . All Vision2 items are descendants of [[ref:libraries/vision2/reference/ev_pixmapable_chart|EV_PIXMAPABLE]] meaning they can display an [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] .
+
+==Item holders==
+
+Below is a structure showing the Vision2 components and the items that they accept. All the items types available in Vision2 are included:
+* [[ref:libraries/vision2/reference/ev_list_chart|EV_LIST]] accepts items of type:
+** [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]]
+
+* [[ref:libraries/vision2/reference/ev_combo_box_chart|EV_COMBO_BOX]] accepts items of type:
+** [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]]
+
+* [[ref:libraries/vision2/reference/ev_window_chart|EV_WINDOW]] accepts items of type (Use set_menu_bar):
+** [[ref:libraries/vision2/reference/ev_menu_bar_chart|EV_MENU_BAR]] accepts items of type:
+*** [[ref:libraries/vision2/reference/ev_menu_chart|EV_MENU]] accepts items of type:
+**** [[ref:libraries/vision2/reference/ev_menu_chart|EV_MENU]]
+**** [[ref:libraries/vision2/reference/ev_menu_item_chart|EV_MENU_ITEM]]
+**** [[ref:libraries/vision2/reference/ev_menu_separator_chart|EV_MENU_SEPARATOR]]
+**** [[ref:libraries/vision2/reference/ev_radio_menu_item_chart|EV_RADIO_MENU_ITEM]]
+**** [[ref:libraries/vision2/reference/ev_check_menu_item_chart|EV_CHECK_MENU_ITEM]]
+
+
+
+* [[ref:libraries/vision2/reference/ev_multi_column_list_chart|EV_MULTI_COLUMN_LIST]] accepts items of type:
+** [[ref:libraries/vision2/reference/ev_multi_column_list_row_chart|EV_MULTI_COLUMN_LIST_ROW]]
+
+* [[ref:libraries/vision2/reference/ev_tool_bar_chart|EV_TOOL_BAR]] accepts items of type:
+** [[ref:libraries/vision2/reference/ev_tool_bar_button_chart|EV_TOOL_BAR_BUTTON]]
+** [[ref:libraries/vision2/reference/ev_tool_bar_radio_button_chart|EV_TOOL_BAR_RADIO_BUTTON]]
+** [[ref:libraries/vision2/reference/ev_tool_bar_separator_chart|EV_TOOL_BAR_SEPARATOR]]
+** [[ref:libraries/vision2/reference/ev_tool_bar_toggle_button_chart|EV_TOOL_BAR_TOGGLE_BUTTON]]
+
+* EV_TREE accepts items of type:
+** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]] accepts items of type:
+*** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]]
+*** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]]
+
+** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]] accepts items of type:
+*** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]]
+*** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]]
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki
new file mode 100644
index 00000000..ef083621
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki
@@ -0,0 +1,87 @@
+[[Property:title|Kernel]]
+[[Property:weight|1]]
+The kernel cluster contains classes that provide functionality that are common to most Windowed application. These classes are considered the core, or kernel of any Vision2 application. The most important of these classes is [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] . This is used to initialize the graphical toolkit and event loop of your Vision2 application. Kernel also includes classes such as [[ref:libraries/vision2/reference/ev_timeout_chart| EV_TIMEOUT]] that calls procedures (via agents) at a set interval, and [[ref:libraries/vision2/reference/ev_color_chart| EV_COLOR]] which is used for coloring widgets and items. To start programming with Vision2, you first have to correctly initialize [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] .
+
+==Launching your application with EV_APPLICATION - The heart of all Vision2 systems==
+
+[[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is the basis for every Vision2 application and is considered the most important class in the library. It is responsible for initializing the underlying toolkit that is driving the windowing system on the platform that you decide to compile your system on. It also also where the main event loop that drives your application is executed.
+
+{{note| '''Note:''' It is ''' not''' possible to create a Vision2 component unless an application exists (query [[ref:/libraries/vision2/reference/ev_environment_chart|EV_ENVIRONMENT]] ). }}
+You may inherit [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] or use it as a client in order to create your vision2 application. A simple method of using EV_APPLICATION is as follows:
+# Create an instance of EV_APPLICATION.
+# Create one or more windows for your application.
+# Launch the application.
+
+An example of a Vision2 application using inheritance from [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is shown below.
+
+ class
+ HELLOWORLD_APP
+
+ inherit
+ EV_APPLICATION
+
+ create
+ make
+
+ feature
+
+ make is
+ -- Create the application.
+ local
+ helloworld_window: EV_TITLED_WINDOW
+ do
+ default_create
+ create helloworld_window
+ helloworld_window.set_title ("Helloworld!")
+ helloworld_window.close_request_actions.extend (agent destroy)
+ helloworld_window.show
+ launch
+ end
+
+ end
+
+
+This is the same Vision2 application but instead using [/libraries/vision2/reference/ev_application_chart.xml| EV_APPLICATION ] in a client/supplier relationship.
+
+ class
+ HELLOWORLD_APP
+
+ create
+ make
+
+ feature
+
+ make is
+ -- Create the Vision2 application with a helloworld window.
+ local
+ app: EV_APPLICATION
+ helloworld_window: EV_TITLED_WINDOW
+ do
+ create app
+ create helloworld_window
+ helloworld_window.set_title ("Helloworld!")
+ helloworld_window.close_request_actions.extend (agent app.destroy)
+ helloworld_window.show
+ app.launch
+ end
+
+ end
+
+
+==What does Launch actually do?==
+In Vision2, to launch an application means to pass control to the underlying graphical toolkit. Simply creating an application does not launch it. An explicit call to launch is required for the event processing to begin.
+{{note| '''Note: '''A Vision2 system is event based. This means that you do not have control of the execution within a Vision2 system, but must respond appropriately to [[Events|events]] as they occur. Therefore, if you call launch on an [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] , the processing for the application will continue indefinitely unless you have provided a way to exit the application. It is essential to initialize your components correctly, so your application can be exited (call destroy on the application). }}
+
+==Building your application skeleton==
+
+Now that you have a basic application skeleton set up you can now go about
+* [[Widgets|Creating widgets and setting their properties.]]
+* [[Containers|Adding containers to your window(s), then place your created widgets in those containers.]]
+* [[Events|Add code to respond to user actions with agents and action sequences.]]
+
+Once you have learnt the basics of GUI programming within Vision2, you are well on the way to creating powerful multi-platform applications. The Application Programming Interface (API) of Vision2 has been designed in a way to ensure that the library is as intuitive, consistent and stylistic as possible. Heavy reuse of components from EiffelBase has been one of the main reasons that made this possible.
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki
new file mode 100644
index 00000000..50013f31
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki
@@ -0,0 +1,41 @@
+[[Property:title|EiffelVision Pick and Drop]]
+[[Property:weight|0]]
+Pick and drop is a mechanism which allows data to be transported from a '''source''' object to a '''target'''. Any Vision2 object inheriting [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]] can be used to transport or receive data.
+
+==A simple pick and drop example==
+
+Two necessary components for a pick and drop transport are a '''source''' and a '''target''', both of which must conform to [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]] . The data that is to be transported is known as a '''pebble'''.
+
+The following steps need to be undertaken to set up a simple pick and drop:
+* Set the '''source''' by calling set_pebble.
+* Set one or more '''targets''' by adding a function to their drop_actions. The arguments of the function must match the type of the '''pebble''' to be transported for the '''source''' otherwise the transport will not be permitted.
+
+A simple example of this is demonstrated here:
+
+ button1.set_pebble ("A PND transport has occured%N")
+ button2.drop_actions.extend (agent print (?))
+
+
+As print takes an argument of type [[ref:/libraries/base/reference/string_8_chart|STRING_8]] , button2 becomes a valid target for the pebble contained in button1. Right clicking the mouse pointer over the '''source''' will start the transport, and right clicking with the mouse pointer over a valid '''target''' will end the transport. The transport can be canceled anytime with a simple left click, just as you would do in EiffelStudio.
+
+{{note| '''Note''': When a transport completes, the '''pebble''' that was transported is passed as an argument to all features in the '''targets'''drop_actions whose argument type matches the '''pebble''' }}
+
+==Three different modes of transport==
+
+There are three different modes of transport available for pick and drop. They are listed below with details of their use:
+* Pick and Drop mode.
+This is the default mode for pick and drop, but can be set with set_pick_and_drop_mode. Right clicking on a '''source''' starts the transport and right clicking on a valid '''target''' completes the transport. During execution, a band is drawn from the screen position where the pick started to the current mouse position. Pressing the left mouse button or the escape key during execution will end the transport.
+* Drag and drop mode
+This mode can be set with set_drag_and_drop_mode. Left clicking on a '''source''' starts the transport and releasing the left mouse button over a valid '''target''' completes the transport. During execution, a band is drawn from the screen position where the pick started to the current mouse position. Releasing the left mouse button or pressing the escape key during execution will end the transport.
+* Target menu mode
+This mode can be set with set_target_menu_mode. Right clicking on a '''source''' brings up a menu of all the valid drop '''targets''' in the system. Selecting one of these targets completes the transport.
+
+
+==Accept and deny cursors==
+
+When mode_is_pick_and_drop or mode_is_drag_and_drop then the shape of the mouse cursor changes to reflect whether the current GUI component below the mouse accepts the pebble or not. Calling set_accept_cursor allows you to customize this cursor used to represent a valid '''target''' while calling set_deny_cursor allows you to customize the cursor used for non valid '''targets'''.
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki
new file mode 100644
index 00000000..1c74ee7c
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki
@@ -0,0 +1,47 @@
+[[Property:title|Properties]]
+[[Property:weight|5]]
+This cluster contains all the common properties available for Vision2 [[Widgets|widgets]] and [[Items|items]] . Every Vision2 widget has the same set of properties inherited from EV_WIDGET, but many widgets also inherit additional properties, further refining the behavior of the widget.
+
+EV_WIDGET inherits the following properties:
+* [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]]
+** For an overview of the Pick and Drop mechanism, click [[EiffelVision Pick and Drop|here]] .
+
+* [[ref:libraries/vision2/reference/ev_sensitive_chart|EV_SENSITIVE]]
+** If a Vision2 component inherits [[ref:libraries/vision2/reference/ev_sensitive_chart|EV_SENSITIVE]] , it can be made to ignore events.
+Use disable_sensitive to disable event handling, and enable_sensitive to restore event handling.
+
+* [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]]
+** If a Vision2 component inherits [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]] it has facilities for modifying its foreground and background colors.
+Use set_foreground_color to set the foreground_color and set_background_color to set the background_color.
+Use set_default_colors to restore the colors to their defaults.
+
+* [[ref:libraries/vision2/reference/ev_help_contextable_chart|EV_HELP_CONTEXTABLE]]
+** If a Vision2 component inherits [[ref:libraries/vision2/reference/ev_help_contextable_chart|EV_HELP_CONTEXTABLE]] , facilities are provided for associating help to the component when F1 or Shift F1 is pressed.
+
+* [[ref:libraries/vision2/reference/ev_positioned_chart|EV_POSITIONED]]
+** If a Vision2 component inherits [[ref:libraries/vision2/reference/ev_positioned_chart|EV_POSITIONED]] it is possible to query its current position, size and minimum size.
+Use x_position and y_position to find its position relative to its parent.
+Use width and height to find its size.
+Use minimum_width and minimum_height to find its size.
+
+* [[ref:libraries/vision2/reference/ev_containable_chart|EV_CONTAINABLE]]
+** If a Vision2 component inherits [[ref:libraries/vision2/reference/ev_containable_chart|EV_CONTAINABLE]] it is able question its parent. Use parent to query the current parent.
+
+
+
+{{note| '''Note:''' [[ref:libraries/vision2/reference/ev_containable_chart|EV_CONTAINABLE]] has no features for setting the parent. In Vision2, a child has no features for setting its parent, while a parent such as ev_container contains routines for adding children (one example is extend). }}
+
+The following properties are also used within Vision2:
+* [[ref:libraries/vision2/reference/ev_deselectable_chart|EV_DESELECTABLE]]
+* [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]]
+* [[ref:libraries/vision2/reference/ev_fontable_chart|EV_FONTABLE]]
+* [[ref:libraries/vision2/reference/ev_pixmapable_chart|EV_PIXMAPABLE]]
+* [[ref:libraries/vision2/reference/ev_positionable_chart|EV_POSITIONABLE]]
+* [[ref:libraries/vision2/reference/ev_selectable_chart|EV_SELECTABLE]]
+* [[ref:libraries/vision2/reference/ev_textable_chart|EV_TEXTABLE]]
+* [[ref:libraries/vision2/reference/ev_tooltipable_chart|EV_TOOLTIPABLE]]
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki
new file mode 100644
index 00000000..3945f5d4
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Support]]
+[[Property:weight|6]]
+The support cluster contains many classes providing useful facilities within the library. Many of the classes within this cluster are constant classes, which are filled with constant values for specific contexts, generally indicated by their names. The following constant classes are available within this cluster:
+* [[ref:libraries/vision2/reference/ev_dialog_constants_chart|EV_DIALOG_CONSTANTS]]
+* [[ref:libraries/vision2/reference/ev_drawable_constants_chart|EV_DRAWABLE_CONSTANTS]]
+* [[ref:libraries/vision2/reference/ev_font_constants_chart|EV_FONT_CONSTANTS]]
+* [[ref:libraries/vision2/reference/ev_key_constants_chart|EV_KEY_CONSTANTS]]
+* [[ref:libraries/vision2/reference/ev_postscript_page_constants_chart|EV_POSTSCRIPT_PAGE_CONSTANTS]]
+In a similar vein to constant classes, the two following classes are provided to provide support for default [[ref:libraries/vision2/reference/ev_color_chart|EV_COLOR]] 's and [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] 's.
+* [[ref:libraries/vision2/reference/ev_stock_colors_chart|EV_STOCK_COLORS]]
+* [[ref:libraries/vision2/reference/ev_stock_pixmaps_chart|EV_STOCK_PIXMAPS]]
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki
new file mode 100644
index 00000000..14f4333b
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki
@@ -0,0 +1,66 @@
+[[Property:title|Containers]]
+[[Property:weight|1]]
+All Vision2 containers inherit [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]]
+
+==What is a container?==
+
+A container is a Vision2 widget that may contain other widgets. Some containers such as [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] may only hold one widget while containers such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may hold multiple widgets. As a container is of type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] , this means that a container may be placed within a container. Windows inherit from [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] and are therefore classed as containers also.
+
+{{note| '''Note: '''Containers may only contain other widgets. Items may only be placed in certain primitives. For example, an [[ref:libraries/vision2/reference/ev_list_item_chart| EV_LIST_ITEM]] may be contained in an [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]] . }}
+
+==Inheritance from Base==
+
+Wherever possible, Vision2 containers reuse the container structures provided by Base. This provides three main advantages:
+# Familiarity for operations such as access, insertions and removals. Anybody who already uses [[EiffelBase Library|Base]] should find it easy to adapt to using Vision2 containers.
+# The underlying structures used have been tried and tested for many years and their design has been proved to be robust and effective.
+# It provides powerful methods of querying the contents. In the original Vision library, you needed to keep reference to widgets as you could not query the contents of a container.
+
+For example, [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] inherits BOX and COLLECTION. Descendents of [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may also inherit other structures from [[EiffelBase Library|Base]] .
+
+==Usage of Containers==
+
+The main role of a container is to position its children in a certain way. An [[ref:libraries/vision2/reference/ev_horizontal_box_chart| EV_HORIZONTAL_BOX]] for example positions its children side by side along the horizontal axis. To achieve vertical stacking you would use an [[ref:libraries/vision2/reference/ev_vertical_box_chart| EV_VERTICAL_BOX]] .
+A code example of adding widgets to a container is as follows:
+
+ add_to_container is
+ -- Add 3 buttons to a hbox and then show in window.
+ local
+ a_window: EV_TITLED_WINDOW
+ a_hbox: EV_HORIZONTAL_BOX
+ a_button: EV_BUTTON
+ do
+ create a_window
+ create a_hbox
+ create a_button.make_with_text ("Button1")
+ a_hbox.extend (a_button)
+ a_hbox.extend (create {EV_BUTTON}.make_with_text ("Button2"))
+ a_hbox.extend (create {EV_BUTTON}.make_with_text ("Button3"))
+ a_window.extend (a_hbox)
+ a_window.show
+ end
+
+
+The mapping of a Vision2 container interface is very close to that of containers in Base, such as a linked list.
+* To add a widget to a container call `extend'.
+* To remove a widget from the container call `prune'.
+* To empty a container call `wipe_out'.
+* To traverse the container, you can use features such as start, forth, item and off.
+
+{{note| '''Note''': When a widget is added to a container, the container is the parent of the widget. }}
+
+==Size of widget within a container==
+
+The size of a widget in a container is always at least its minimum size. By default, when a widget is added to a container it is expandable. This means that if the container gets bigger, the widget will expand to fit the extra space. This convenient functionality means that you don't have to worry about handling the size of the widget (such as when a user alters the size of a window) as this is all performed automatically. If, on the other hand, you decide you want the widget to remain at a certain size (its minimum size), [[ref:libraries/vision2/reference/ev_box_chart| EV_BOX]] contains the convenient call disable_item_resize.
+
+==Sizing of containers==
+As [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] is of type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] , the following facilities are provided for setting the minimum size: set_minimum_width, set_minimum_height and set_minimum_size. It is important to remember that as a general rule, '''the current size of a container is always at least the minimum size of all its contents.'''
+{{note| '''Note: '''The exception to this is: [[ref:libraries/vision2/reference/ev_fixed_chart|EV_FIXED]] , [[ref:libraries/vision2/reference/ev_viewport_chart|EV_VIEWPORT]] and [[ref:libraries/vision2/reference/ev_scrollable_area_chart|EV_SCROLLABLE_AREA]] which do actually allow their contents to be larger than their current size.
+}}
+
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki
new file mode 100644
index 00000000..7478c38b
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki
@@ -0,0 +1,32 @@
+[[Property:title|EiffelVision Dialogs]]
+[[Property:weight|2]]
+This cluster contains all the dialogs provided by Vision2.
+
+==Standard dialogs==
+
+A standard dialog provides a way of interacting with the underlying platform (such as Windows or Linux) to perform basic tasks such as opening a file or printing a document. Vision2 provides six dialogs that allow the user to perform everyday tasks that are
+* [[ref:libraries/vision2/reference/ev_color_dialog_chart|EV_COLOR_DIALOG]] -- This allows the user of your app to select an RGB color (useful for graphical apps such as a Paint Program).
+* [[ref:libraries/vision2/reference/ev_directory_dialog_chart|EV_DIRECTORY_DIALOG]] -- This allows the user of your app to select a directory.
+* [[ref:libraries/vision2/reference/ev_file_open_dialog_chart|EV_FILE_OPEN_DIALOG]] -- This allows the user of your app to select a file to be opened.
+* [[ref:libraries/vision2/reference/ev_file_save_dialog_chart|EV_FILE_SAVE_DIALOG]] -- This allows the user of your app to select a filename that will be used for the creation of a file.
+* [[ref:libraries/vision2/reference/ev_font_dialog_chart|EV_FONT_DIALOG]] -- This allows the user of your app to select a font (useful for a Word Processor for example).
+* [[ref:libraries/vision2/reference/ev_print_dialog_chart|EV_PRINT_DIALOG]] -- This allows the user of your app to choose printer settings may be used in conjunction with [[ref:libraries/vision2/reference/ev_print_projector_chart|EV_PRINT_PROJECTOR]] .
+
+
+==Creating custom dialogs==
+
+If you wish to provide a custom dialog in your application, [[ref:libraries/vision2/reference/ev_dialog_chart| EV_DIALOG]] has been provided to facilitate this.
+
+==Message dialogs==
+
+A message dialog gives your application a standard way of displaying useful (or vital) information, this information can be displayed with the following message dialogs.
+* [[ref:libraries/vision2/reference/ev_message_dialog_chart|EV_MESSAGE_DIALOG]] -- Allows a simple message to be displayed to the user.
+* [[ref:libraries/vision2/reference/ev_information_dialog_chart|EV_INFORMATION_DIALOG]] -- Allows useful info to be displayed to the user.
+* [[ref:libraries/vision2/reference/ev_question_dialog_chart|EV_QUESTION_DIALOG]] -- Allows the user to respond to a question with Yes or No.
+* [[ref:libraries/vision2/reference/ev_warning_dialog_chart|EV_WARNING_DIALOG]] -- Allows a warning to be displayed to the user.
+* [[ref:libraries/vision2/reference/ev_confirmation_dialog_chart|EV_CONFIRMATION_DIALOG]] -- Allows the user to confirm an action that has been requested.
+* [[ref:libraries/vision2/reference/ev_error_dialog_chart|EV_ERROR_DIALOG]] -- Allows an error message to be shown to the user.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki
new file mode 100644
index 00000000..141e19a3
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki
@@ -0,0 +1,50 @@
+[[Property:title|Widgets]]
+[[Property:weight|2]]
+==What is a Widget?==
+
+A Widget is the fundamental building block of your applications GUI, components such as Windows, Buttons and Labels are examples of such. The widget set of Vision2 provides you with the flexibility to easily create powerful graphical applications. All widgets in Vision2 inherit from [[ref:/libraries/vision2/reference/ev_widget_chart| EV_WIDGET]] and the features provided in EV_WIDGET may be called on any widget.
+
+==Variations of Widget==
+Within Vision2, widgets have been classified into three different groups:
+* [[Primitives|Primitives]] -- These are elements of the user interface that are mainly responsible for interaction with the user, such as an [[ref:/libraries/vision2/reference/ev_button_chart|EV_BUTTON]] .
+* [[Containers|Containers]] -- These are used to contain other widgets and position them in a certain way, such as an [[ref:/libraries/vision2/reference/ev_vertical_box_chart| EV_VERTICAL_BOX ]] that stacks its children one by one vertically.
+* [[EiffelVision Dialogs|Dialogs]] -- These are pop up dialog windows used for interacting with the user for tasks such as opening a file (EV_FILE_OPEN_DIALOG) or displaying a message (EV_MESSAGE_DIALOG). You may construct your own dialogs by inheriting EV_DIALOG.
+
+==How do I create a widget?==
+
+All widgets in Vision2 are based around the default_create mechanism in Eiffel. This means that all that needs to be done to create a widget is to declare a reference to a type (such as [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] ) and then call create on that reference. An example of this is as follows.
+
+ a_button: EV_BUTTON
+ create a_button
+
+
+Along with the default creation, Vision2 also includes a few convenience creation functions. Examples of this are make_with_text for all widgets that may have text associated with them (those that inherit from [[ref:libraries/vision2/reference/ev_textable_chart| EV_TEXTABLE]] ), this saves a call to set_text upon default creation of the textable widget.
+
+ create a_button.make_with_text ("Click Me")
+
+
+This would be in place of
+
+ create a_button
+ a_button.set_text ("Click Me")
+
+
+{{note|Note: When a widget is created no extra initialization has to be performed. '''The only exception is for a window where you have to call show in order for it to be displayed on screen'''. }}
+
+==Sizing==
+
+As [[ref:libraries/vision2/reference/ev_primitive_chart|EV_PRIMITIVE]] is of type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] , the following facilities are provided for setting the minimum size: set_minimum_width, set_minimum_height and set_minimum_size.
+
+The minimum size of a widget is the smallest possible size that it can possibly be inside its parent container. If an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] was created and set with a minimum_size of width/height (100, 100), if this button was inserted in to an [[ref:libraries/vision2/reference/ev_horizontal_box_chart| EV_HORIZONTAL_BOX]] , then the box's size could never be below (100, 100) or it would break the minimum size of the button. '''The size of a container must always be greater or equal to the minimum sizes of its children.'''
+
+{{note| '''Note: '''In Vision2, there is no way to set the current size of the primitive. The current size is dependent on the size of the parent or the minimum_size. }}
+
+==Now what do I do?==
+Now that you can create a widget, you will need to actually make it usable to your intended user. This will usually involve these three steps.
+* Setting [[Properties| properties]] for the widget such as color and the minimum size that a widget can possibly be in its parent container.
+* Making the widget respond to user [[Events| events]] via the use of agents and action sequences.
+* Placing the widget inside a [[Containers| container]] widget (either a window or a child of a window) so it can be shown on screen.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/primitives.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/primitives.wiki
new file mode 100644
index 00000000..780204d4
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/primitives.wiki
@@ -0,0 +1,17 @@
+[[Property:title|Primitives]]
+[[Property:weight|0]]
+All Vision2 primitives inherit [[ref:libraries/vision2/reference/ev_primitive_chart|EV_PRIMITIVE]] .
+
+==What is a primitive?==
+A primitive is a Vision2 widget that may not contain other widgets. Primitives may be placed in [[Containers|containers]] , but a [[Widgets|widget ]] may not contain any child widgets. Some examples of primitives are [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] and [[ref:libraries/vision2/reference/ev_label_chart|EV_LABEL]] .
+==Features of a primitive==
+
+All primitives inherit from [[ref:libraries/vision2/reference/ev_tooltipable_chart|EV_TOOLTIPABLE]] and therefore can have tooltips assigned to them. They all inherit many features from [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] . Each descendent of [[ref:libraries/vision2/reference/ev_primitive_chart|EV_PRIMITIVE]] will typically have many available features, specific to their type. For example, [[ref:libraries/vision2/reference/ev_separator_chart|EV_SEPARATOR]] has no extra features, but [[ref:libraries/vision2/reference/ev_label_chart|EV_LABEL]] has features for modifying the current font and also the text to be displayed.
+
+==Widgets as item holders==
+
+Although no primitive can contain another widget, certain primitives may contain one or more [[Items|items]] . One example of this is an [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]] containing [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]] s.
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/index.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/index.wiki
new file mode 100644
index 00000000..31cc4fd2
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelVision 2 Library]]
+[[Property:link_title|EiffelVision 2]]
+[[Property:weight|10]]
+Type: Library
+Platform: Any
+
+See:
+* [[EiffelVision Introduction|Introduction]]
+* [[EiffelVision Interface Content|Content]]
+* [[EiffelVision 2 Samples|Samples]]
+* [[ref:libraries/vision2/reference/index|Reference]]
+* [[Revisions and Bug Fixes|Release notes]]
+
+
+
+
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/revisions-and-bug-fixes.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/revisions-and-bug-fixes.wiki
new file mode 100644
index 00000000..6090bad1
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/revisions-and-bug-fixes.wiki
@@ -0,0 +1,762 @@
+[[Property:title|Revisions and Bug Fixes]]
+[[Property:weight|10]]
+This document contains details of modifications and bug fixes to the Vision2 library listed by the release version of EiffelStudio. All bug fixes and modifications are relative to the previously released version.
+
+==EiffelStudio 6.2==
+
+'''Interface modifications'''
+* '''EV_WINDOW''' - Added hide actions.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_GRID'''
+*** Fixed crashes when rendering child tree nodes
+
+
+
+==EiffelStudio 6.1==
+
+'''Interface modifications'''
+* '''EV_APPLICATION''' - Added 'is_display_remote' for determining whether the graphical display is on the same machine as the running system.
+* '''EV_POINTER_STYLE_CONSTANTS''' - Added hyperlink_cursor constant so that hyperlink cursors may be used in applications
+* '''EV_POINTER_STYLE''' - Now pointer style objects may be twinned correctly to match the capability of pixmaps and cursor objects.
+* '''EV_DRAWABLE''' - Added 'draw_sub_pixel_buffer' so that pixel buffer data may be rendered to a drawable.
+* '''EV_PIXEL_BUFFER''' - Added 'draw_pixel_buffer_with_x_y'.
+* '''EV_STOCK_PIXMAPS''' - Now pixel buffers are used for stock icons; this allows for alpha transparency information to be retained.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_GRID'''
+*** Fixed certain crashes when recomputing offsets
+
+
+* '''Windows'''
+** '''EV_STOCK_PIXMAPS'''
+*** Now alpha information is correctly extracted for stock icons
+
+
+* '''Linux/Solaris'''
+** '''EV_COMBO_BOX'''
+*** Fixed calling of change_actions when items are selected via the drop down
+
+** '''EV_POINTER_STYLE'''
+*** Fixed issue when converting to a cursor object then reverting back would render a white square instead of the requested cursor
+
+** '''EV_WINDOW'''
+*** Fixed issues when calling disable/enable user resize in certain states
+
+
+
+==EiffelStudio 6.0==
+
+'''Interface modifications'''
+* '''EV_PICK_AND_DROPABLE''' - Added context menu capabilities with 'set_configurable_target_menu_mode', 'set_configurable_target_menu_handler' and 'show_configurable_target_menu' that can be used to override the existing Pick and Drop mechanism.
+* '''EV_ACTION_SEQUENCE''' - Now event_data is defined with named tuples for easier reading of the action sequence parameters.
+* '''EV_APPLICATION_ACTION_SEQUENCES'''
+** Added 'file_drop_actions' for OS based file drag and drop from exterior applications to a Vision2 application.
+** Made 'idle_actions' obsolete as it is not thread-safe
+** Now a full garbage collection occurs if the application has been idle for 30 seconds
+
+* '''EV_APPLICATION'''
+** Added 'transport_in_progress' for querying if a pebble transport is currently taking place.
+** Added caps_lock_on for querying if the caps lock key is currently toggled
+** `process_events' will now call idle actions when no more events are left in the pending queue
+
+* '''EV_FONT''' - Added 'line_height' to retrieve an appropriate text editor line height in pixels for a font.
+* '''EV_PIXEL_BUFFER''' - Added conversion to/from EV_PIXMAP and added 'save_to_named_file' for saving buffer to disk.
+* '''EV_POINTER_STYLE_CONSTANTS''' - Added header_sizewe cursor
+* '''EV_FIXED''' - Added extend_with_size_and_position and set_with_size_and_position for flicker free update of fixed children.
+* '''EV_GRID''' - Added `visible_row_count' for querying the number of currently visible rows.
+* '''EV_TEXT_FIELD''' - Added inheritance from EV_TEXT_ALIGNABLE
+* '''EV_POPUP_WINDOW''' - Added 'make_with_shadow' creation procedure to create a popup window with an alpha shadow (on platforms that support it).
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_GRID'''
+*** Fixed refresh issues and certain crashes when removing items from grid
+*** Fixed navigation and selection handling for trees
+
+** '''EV_PICK_AND_DROPABLE''' - Fixed 'memory leak' when calling 'pebble_function'.
+
+* '''Windows'''
+** Raised compatibility bar to Windows 2000 or greater. No more support for Windows 98 or NT 4.0.
+** '''EV_DIALOG'''
+*** Fixed resizing bug that led to a difference in behavior from regular EV_WINDOW descendents
+*** Corrected calling of cancel actions when closing via the Cross which previously was broken for modeless and modal dialogs
+
+** '''EV_PIXMAP'''
+*** Now correctly copying all agents over when the pixmap implementation internally changes state, previously some agents were being lost after certain operations on a pixmap
+*** Now mask is correctly queried when saving pixmap
+
+
+* '''Linux/Solaris'''
+** '''EV_ACCELERATOR''' - Reimplemented accelerator implementation so that it works with all key combinations that were previously being unprocessed by gtk
+** Completely reimplemented and optimized event handling for faster response, scaled down use of agents for event connection for decreased memory consumption
+
+
+==EiffelStudio 5.7==
+
+'''Interface modifications'''
+* '''STRING_GENERAL''' - All string operations now take STRING_GENERAL instead of STRING, this allows for mixing and matching of 8 and 32-bit string objects and allows for 32bit Unicode values, the return value is always STRING_32
+* '''EV_APPLICATION'''
+** Added action sequences for querying global user events such as pointer clicks and motion
+** Vision2 is now thread-aware with the addition of thread-safe 'add_idle_action' and 'do_once_on_idle' that allow threads to add agents to update the main GUI thread in a safe manner
+
+* '''EV_POINTER_STYLE''' - Added new pointer style class for setting the style of the mouse pointer, EV_CURSOR will be made obsolete, in the future animated cursors and transparency will be available
+* '''EV_PIXEL_BUFFER''' - New class for loading/querying and setting RGBA values from disk
+* '''EV_FIXED''' - Now item positions may be set to negative values within the fixed widget
+* '''EV_BITMAP''' - New class for setting 1 bit masks on EV_PIXMAP via set_mask
+* '''EV_TEXT''' - Added 'scroll_to_end' to scroll down so that the last line is visible
+* '''EV_WIDGET'''
+** Added 'refresh_now' that allows for immediate redraw of a widget without having to wait for the event loop to repaint it. A useful example of this is when calling 'set_text' on EV_LABEL during heavy computation.
+** Added ability to ignore the default key action on widgets.
+
+* '''EV_GRID'''
+** Changed semantic of `move_row' and `move_rows' so that destination position is now an insertion index before a row instead of placing as the row index itself. This allows for easier insertion of rows. Any code using these features will need to be rechecked as this is a breaking change for rows that are moved down the grid
+** Altered `move_rows' so that it will now unparent the top level nodes from the first row being moved whilst keeping any subtree structure
+** Added `move_rows_to_parent' that allows moving a block of parented rows from one parent to another
+** Added `insert_new_rows' and `insert_new_rows_parented' which permit you to add insert multiple rows at once. This is far quicker than adding rows individually.
+** Added `remove_rows' which permits you to remove multiple rows at once. This is far quicker than removing each row individually.
+** Fixed `enable_capture' and disable_capture' which previously captured an internally hidden component of the grid, so no events were ever received during capture.
+** Previously, `set_default_colors' did not work.
+** Fixed bug in `pointer_enter_actions' and `pointer_leave_actions' of EV_GRID_ITEM which were not always fired when the mouse pointer entered or left the grid.
+** Corrected `not_row_height_variable_and_vertical_scrolling_per_pixel' precondition of `enable_partial_dynamic_content'.
+** Fixed bug which caused an internal exception within the grid when `is_tree_enabled' and `is_content_partially_dynamic'.
+** Strengthened preconditions of `insert_new_row_parented' to prevent you inserting a new row at an index within a subtree structure of one of the existing subrows, as in that case, it is impossible for the parent to be the desired row.
+** Added capability to hide rows in the grid
+** Added ability for locking the position of rows and columns in the grid
+
+* '''EV_GRID_ROW''' - Added `insert_subrows' for the quick addition of multiple subrows at once.
+* '''EV_WINDOW''' - Added `is_border_enabled', `enable_border' and `disable_border'. This lets you turn on/off the border as required.
+* '''EV_HEADER_ITEM''' - Added `user_can_resize' which enables you to prevent a user from resizing the item. Also added `minimum_width' and `maximum_width' which permit you to restrict the resizing of the item within a particular range.
+* '''EV_MESSAGE_DIALOG''' - All message dialogs now use their associated message icon as the icon pixmap displayed in the title bar, instead of the standard EiffelVision2 icon.
+* '''EV_DYNAMIC_TREE_ITEM''' - The `subtree_function' is now only executed when you expand the item. In the previous version, querying the contents of the item caused the subtree function to be executed, filling the children.
+* '''EV_COMBO_BOX''' - Added `is_list_shown', `list_hidden_actions' and renamed `drop_down_actions' to `list_shown_actions'.
+* '''EV_APPLICATION''' - Added `pointer_motion_actions', `pointer_button_press_actions', `pointer_button_release_actions', `pointer_double_press_actions', `mouse_wheel_actions', `key_press_actions', `key_press_string_actions' and `key_release_actions'. Each of these action sequences pass the applicable widget as part of the event data.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_GRID''' - Fixed refresh issues and certain crashes when removing items from grid
+
+* '''Windows'''
+** '''EV_WINDOW''' - The default state is now `user_can_resize'. Although this was previously specified within `is_in_default_state', the window was not actually resizeable.
+** '''EV_DIALOG'''
+*** Calling `enable_user_resize' or `disable_user_resize' on a dialog that is shown relative to another window no longer looses the relative state of the dialog.
+*** Fixed failure of a "check" statement within EiffelVision when showing a dialog with a `default_cancel_button' relative or modal to another window.
+
+** '''EV_FONT_DIALOG''' - Fixed issue where displayed font did not take into account font specified through call to `set_font'.
+** '''EV_RICH_TEXT''' - Fixed calling of `change_actions' which were never called in the previous version.
+** '''EV_PIXMAP''' - If a pixmap was parented directly within a container and Windows XP themes were enabled, the background theme of the parent container was not applied to the pixmap. This was especially noticeable when using EV_NOTEBOOK as a parent container.
+** '''EV_WIDGET''' - Fixed bug in theme handling on Windows XP. Previously, any widgets that were created before the first window was created did not draw correctly when displayed.
+** '''EV_COMBO_BOX''' - Fixed bug in `key_press_actions' which were called twice when you pressed the up or down arrow keys.
+** '''EV_TITLED_WINDOW'''
+*** `title' was returning `Void' if you had not explicitly set a `title'.
+*** Fixed raise to work when process is not in the foreground, the window will now flash in the window selector
+
+** '''EV_MENU''' - A menu with an ampersand (i.e. menu.set_text ("Test && Verify")) could be truncated when displayed (i.e. the `y' could be missing).
+** '''EV_PIXMAP''' - Fixed a memory corruption while loading PNG images.
+** Fixed resizing issue which would happen if too many widgets are nested in each other, those nested widgets would not resize properly.
+
+* '''Gtk'''
+** '''EV_DIALOG''' - Fixed modal dialogs so that they behave the same as on Windows so that show_modal_to_window is indeed only modal to the parent window
+** - Mouse events now only go to the widget that the mouse is currently interacting with
+** '''EV_FONT''' - Fixed bug where font names were being matched on substring, meaning that Sans would match with San Serif
+** '''EV_TEXT''' - Fixed and optimized calls relating to display lines versus actual lines
+** - Fixed potential instability due to signal marshal calls being made during object dispose
+** - Completely overhauled event handling implementation to use less resources and be much more optimal
+** '''EV_POPUP_WINDOW'''Completely rewrote popup window implementation to be not dependent on the window manager, this means that they will work in all scenarios with WM intervention
+** '''EV_ACCELERATOR''' - Fixed crashes caused by certain accelerator combinations
+** '''EV_TOOL_BAR_BUTTON''' - Toolbar buttons are now accepted as Pick and Drop targets
+
+
+==EiffelStudio 5.6==
+
+'''Interface modifications'''
+* '''EV_POPUP_WINDOW''' - A new window type which inherits EV_WINDOW with two differences: It does not display a border of any sorts and is not displayed in the task bar. This is especially useful for simulating tooltips and other such pop-ups.
+* '''EV_APPLICATION''' - Added 'uncaught_exception_actions' which is called whenever an action sequence called from the underlying toolkit fails to deal with any exceptions raised.
+* '''EV_CLIPBOARD''' - Added 'has_text' so that the clipboard can be queried without retrieving the entire contents.
+* '''EV_CHECKABLE_TREE''' - A new widget that inherits EV_TREE, providing similar functionality but for each item contained a check box is displayed.
+* '''EV_NOTEBOOK'''
+** Added `pointed_tab_index' which returns the index of the tab beneath the mouse pointer or 0 if none.
+** Added EV_NOTEBOOK_TAB which may be queried via the new query `item_tab'. The object represented by this new class provides the ability to set both the text and a pixmap for the tab item.
+** Now inherits EV_ITEM_PIXMAP_SCALER as the tabs support pixmaps through the use of EV_NOTEBOOK_TAB.
+
+* '''EV_COMBO_BOX''' - Added `drop_down_actions', fired as the list is dropped down which permits dynamic filling of the combo box as its contents are displayed.
+* '''EV_WIDGET''' - Removed postcondition `has_focus' from `set_focus' since in most cases it does not hold. Indeed between the time you set the focus and the time you check if you still have the focus something could have happen that would remove the focus.
+* '''EV_PIXMAP''' - Added `sub_pixmap', this allows a pixmap to be created from a region of another
+* '''EV_RICH_TEXT''' - Corrected postcondition of `buffered_format' which restricted the end position to `text_length' instead of `text_length' + 1.
+* '''EV_FILE_OPEN_DIALOG''' - Added features for retrieving multiple file names. The following additional features are now available: 'enable_multiple_selection', `disable_multiple_selection', `multiple_selection_enabled' and `file_names'.
+* '''EV_TEXT_COMPONENT''' - Removed `is_editable' precondition of `set_caret_position'.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_DIALOG_I''' - Fixed consistency of `default_push_button', before we could get some assertions violations from the implementation classes.
+** '''EV_ANY''' - Added protection for multiple calls of `destroy' which previously caused crashes in some situations, now `destroy' calls a `safe_destroy' intermediary which checks if the implementation has not already been destroyed
+** '''EV_GAUGE''' - Fixed bug in `make_with_value_range' which did not adjust `value' to `lower', thereby putting the gauge in an invalid state.
+
+* '''Windows'''
+** Fixed resizing issue: when a widget is inserted in a hidden window and that the minimum size of the window does not change, the widget would not appear on the window when shown. One had to manually resize the window to make it appear. Now it will appear properly.
+** Fixed a crash which could occur when using the tab or arrows keys to navigate between the primitive of a window. It would happen when trying to set the focus on a widget which was previously parented but is not anymore.
+** Improved appearance of applications running on Windows XP with manifest files.
+** '''EV_RADIO_BUTTON''' - Enabled better navigation between radio buttons of a group using the arrow keys.
+** '''EV_SPIN_BUTTON'''
+*** When it gets the focus, we set the focus to the associated text field. Before one would loose the focus until one use the mouse to set it to the text field part.
+*** Fixed bug which restricted the maximum values permitted to approx. 16,000. Attempting to manipulate the spin button with values greater than this caused precondition violations internally.
+
+** '''EV_SCREEN'''
+*** `widget_at_position' returns an instance of EV_COMBO_BOX when cursor is on top of the text part of the combo box, before it would return Void.
+*** `set_pointer_position' was not setting the position accurately and it may have actually been set to one of the adjacent positions.
+
+** '''EV_COMBO_BOX'''
+*** `focus_out_actions' are only called once when loosing focus. Before they would be called twice and even called when the combo box was getting the focus.
+*** Fixed `has_focus' to return True when either the combo or the text field when it exists has the focus.
+*** Fixed call on Void target when calling `set_foreground_color' on a displayed combo box which is not editable.
+*** Fixed invariant violation with a non editable combo box.
+*** Fixed `caret_position' which was failing if you attempted to set a caret position to a value greater than approx 65,000.
+*** Fixed `set_focus' which failed if the combo box was non-editable.
+*** Fixed handling of escape and enter keys while list was dropped down. If the combo box was contained within a dialog, the default cancel and default push button actions were fired as a result of pressing these keys. These keys are no longer propagated to the dialog in this fashion.
+
+** '''EV_MULTI_COLUMN_LIST''' - Calling `column_width' after calling `resize_column_to_content' did not return the correct result but instead the previously set column width.
+** '''EV_NOTEBOOK'''
+*** Fixed resizing issue of notebook when it is included in a hidden pane of another notebook, resulting in an assertion violation in the resizing code.
+*** Fixed class invariant which failed when calling `destroy'.
+
+** '''EV_WINDOW'''
+*** Fixed `screen_x' and `screen_y' so that they return the same value as `x_position' and `y_position'.
+*** Fixed issue where `move_actions' were called with incorrect positions (before the given positions were the one from the child of the window, not the window itself).
+
+** '''EV_DIALOG'''
+*** Calling `show', moving the window and then subsequently calling `show_relative_to_window' or `show_modal_to_window' caused the dialog to move from its current position. Now the window no longer moves which mirrors the behavior in the opposite case where `show_relative_to_window' or `show_modal_to_window' is called before `show'.
+*** Fixed bug which caused processing of particular keys in widgets contained within the dialog to be processed by the dialog preventing the `key_press_actions' from being fired and causing miscellaneous keyboard navigational issues.
+*** Proper handling of `remove_default_push_button' and `set_default_push_button'. Before the internal state would be messed up, resulting in calling the `select_actions' of the the `default_push_button' even though the `default_push_button' did not have focus.
+*** Better navigation using keys
+*** Fixed bug where modal and modeless dialogs were not centered to parent
+
+** '''EV_TREE_NODE''' - Fixed bug which caused a crash if you performed the following: pruned a node from it's parent, pruned an empty node from this just pruned node and then attempted to insert a node within the empty node.
+** '''EV_DIRECTORY_DIALOG''' - Fixed bug in which the dialog always reported that "ok" has been selected even if the "cancel" button had been selected. This occurred if the dialog had been shown more than once with "ok" already selected.
+** '''EV_PIXMAP'''
+*** Fixed color displayed around a pixmap while parented in a container. Previously, gray was always displayed but now we use the `background_color' of the `parent'.
+*** Fixed masking blitting in draw_sub_pixmap. Previously the mask wasn't being blitted correctly discoloring the source image
+*** Fixed mask handling with PNG loading. Previously if the source image pixels under the mask were not black then masking for icons and cursors didnt work correctly, now any color can be used underneath the mask and it will still be masked correctly
+
+** '''EV_TOOL_BAR'''
+*** Fixed `is_show_requested' which was still returning `True' after a call to `hide'.
+*** Improved resizing of tool bar buttons. A tool bar button with a text and no associated pixmap used to display an empty area where the pixmap would be displayed if set. Now, in this case, the button is just large enough to display its text.
+
+** '''EV_FONT''' - Fixed bug in `is_equal' which occasionally failed due to rounding errors between `height' and `height_in_points'. Now, `is_equal' compares `height_in_points' for the font which is more accurate and prevents this issue.
+** '''EV_APPLICATION''' - `cancel_actions' were not always called when they should have been. If you cancelled a pick and drop by right clicking on a target that does not accept the `pebble', the `cancel_actions' were not fired.
+** '''EV_RICH_TEXT'''
+*** Fixed bug in `buffered_format' which corrupted the current text upon calling `flush_buffer' if the text contained any RTF reserved characters such as '/', '{' or '}'.
+*** Fixed `set_background_color' which was not changing the background color
+*** Fixed bug in `disable_word_wrapping' which had a side effect that limited the maximum number of characters to 64000.
+
+** '''EV_TOOL_BAR_BUTTON''' - Fixed bug in handling of enabled/disabled state during a pick and drop transport. The pick and drop mechanism disables tool bar buttons automatically that are not valid targets. If you called `enable_sensitive' or `disable_sensitive' during a pick and drop, this state was not reflected at the end of the pick and drop and the buttons were always restored to their original state. Now the buttons are restored to their last set state.
+** '''EV_TITLED_WINDOW''' - Fixed issue with `raise' where in addition of bringing the window to the front it was changing the previously focused widget within that window. Now it preserves the previously focused widget.
+** '''EV_PRIMITIVE''' - Fixed bug which affected all primitives that hold items. Calling `destroy' on the primitive and then calling `destroy' on one of the items caused precondition violations internally. The bug was that the call to `destroy' on the primitive did not call `wipe_out' to remove all of the contents and the item was still attempting to access its `parent' which should have been `Void'.
+** '''EV_WIDGET'''
+*** Fixed two bugs with `key_press_string_actions'. The first was that the action sequence was fired when Escape or Backspace was pressed. As these are not displayable characters, the `key_press_string_actions' are no longer fired for these keys. The second is that pressing Enter was passing the the string "%R" which is the Windows specific newline character. We now pass "%N" when the Enter key is pressed.
+*** Fixed bug in `pointer_motion_actions'. In some uncommon situations, it was possible to receive the motion event multiple times with the same position.
+*** The `key_press_string_actions' are no longer fired by the "delete" key ( ASCII 127).
+
+** '''EV_TEXT''' - Fixed bug where `caret_position' was returning an incorrect value if it the text had word wrapping enabled and one or more lines in the text were currently word wrapped.
+** '''EV_FONT_DIALOG''' - Fixed bug where `name' of `font' returned was incorrect.
+** '''EV_SPLIT_AREA''' - Split areas now have a completely flat appearance.
+
+* '''Gtk'''
+** '''EV_CURSOR''' - Now the default X-Cursors are used where applicable instead of pixmapped representations of them, this allows for animated cursors if available on the X-server
+** '''EV_VIEWPORT''' - Fixed issue where offsets where not being updated right away so querying back to the viewport from an expose caused by the viewport for the values would be incorrect
+** '''EV_TEXTABLE''' - Now UTF8 strings from different language locales are displayed correctly and not cut-off
+** '''EV_CLIPBOARD''' - Now UTF8 strings from different language locales are handled correctly for copying and pasting
+** '''EV_DRAWING_AREA''' -
+*** Fixed `flush' to instantly call any pending expose events
+*** Fixed issue where drawing area was not being focused when clicked upon by default
+
+** '''EV_FONT'''
+*** Fixed memory leaks in font lookup
+*** Now all resources get freed on disposal of font
+*** Now precalculating `ascent' and `descent' to improve drawing performance
+*** Added better default font handling, now if the default font gets passed in, it will be treated as such by the Gtk theme engine
+
+** '''EV_TOOL_BAR_BUTTON''' - Improve appearance of text and pixmap when `disable_vertical_button_style' is called
+** '''EV_FONTABLE''' - Improved font handling with theme manager, all default fonts now relate to the Application font chosen from the Gtk theme manager
+** '''EV_DRAWABLE'''
+*** Corrected font placement with `draw_text' using fonts of the same height that have varying ascent values
+*** Corrected `draw_arc' to handle all radian angles for both start_angle and aperture values
+*** Fixed mask handling for `draw_sub_pixmap' to work with non-zero 'area' coordinates
+
+** '''EV_MULTI_COLUMN_LIST''' - Fixed memory leak when setting string values
+** '''EV_TREE_NODE'''
+*** Fixed `remove_pixmap' to remove pixmap from tree model
+*** Fixed crash when removing nodes from parent nodes not present in a tree widget
+
+** '''EV_RICH_TEXT'''
+*** Now `paste' uses the Vision2 clipboard directly and so all clipboard assertions are fulfilled
+*** Fixed `buffered_format' to not wipe out the text buffer of the widget and therefore stop other EV_TEXT features from functioning correctly
+*** Now `buffered_append' doesn't wipe out the screen contents of the rich text control
+
+** '''EV_ACCELERATOR''' - Now the key accelerator is checked if valid before proceeding, in some circumstances when a key is not present in the key mapping table adding an accelerator would crash the system, now if the accelerator is not valid for the current key mapping then nothing is done
+** '''EV_WINDOW'''
+*** Now setting and querying focus works in all circumstances with all window types
+
+** '''EV_PIXMAP''' - Improved pixmap 'stretch' for smaller images
+** '''EV_WIDGET'''
+*** Optimized motion event handling so that current motion events only get requested when the previous one has been processed
+*** Fixed theme managed handling in all widgets so that fonts when changed outside of the application by the theme manager get reflected in the Vision2 application
+
+** '''EV_DIALOG'''
+*** Fixed bug where modal and modeless dialogs were not centered to parent
+
+** '''EV_FRAME''' - Corrected issue where changing alignment of text was resetting the vertical alignment
+** '''EV_COMBO_BOX''' - Now the drop down box doesn't fire focus out actions when shown
+
+
+==EiffelStudio 5.5==
+
+'''Interface modifications'''
+* '''EV_TEXT'''
+** Weakened a number of preconditions that required a non empty final line, which was unnecessary. Removed the obsolete feature `put_new_line' and made `last_line_not_empty' obsolete as it is unnecessary and can be queried via `line'.
+** Added `line_number_from_position' which returns the line on which a particular caret position resides.
+
+* '''EV_ACTIVE_LIST''' - New class added which replaces all occurrences of ACTIVE_LIST within the interface. This prevents the EiffelVision implementation from being "unhooked" by user modification through the interface. The class is completely backwards compatible, and does not require any modifications to your code. Classes such as EV_ACCELERATOR_LIST and EV_FONT incorporate this change.
+* '''EV_DOCKABLE_SOURCE''' - Added features `is_external_docking_relative', `enable_external_docking_relative' and `disable_external_docking_relative'. This permits you to dock a source to an EV_DOCKABLE_DIALOG that is not displayed relative to the original top window.
+* '''EV_RICH_TEXT''' - New class, providing a text control with support for character formatting and colors on a character by character basis. The following supporting classes have been added for use with EV_RICH_TEXT: EV_CHARACTER_FORMAT, EV_CHARACTER_FORMAT_EFFECTS, EV_PARAGRAPH_FORMAT, EV_CHARACTER_FORMAT_RANGE_INFORMATION, EV_PARAGRAPH_FORMAT_RANGE_INFORMATION and EV_PARAGRAPH_CONSTANTS.
+* '''EV_ENVIRONMENT''' - Added `fonts' which returns a list of all fonts available on the system.
+* '''EV_APPLICATION''' - Added `captured_widget' which returns the EV_WIDGET currently captured in the system, or `Void' if none.
+* '''EV_SPLIT_AREA''' - Added `splitter_width' which returns the width of the splitter in pixels.
+* '''EV_ANY_HANDLER''' - This is the only class to which `default_create' from EV_ANY is supposed to be exported. However, particular descendents were exporting `default_create' to ANY instead. This has now been fixed.
+* '''EV_MESSAGE_DIALOG''' - `make_with_text_and_actions' has now been added to the list of creation procedures.
+* '''EV_SCREEN''' - Added `horizontal_resolution' and `vertical_resolution' which return the number of pixels per inch.
+* '''EV_FILE_DIALOG''' - Added support for multiple file extensions through the addition of `filters' which provides support for setting both a filter and an associated comment. The existing features `filter' and `set_filter' have been made obsolete.
+* '''EV_FONT'''
+** Modified return type of `string_size' from TUPLE [INTEGER, INTEGER] to TUPLE [INTEGER, INTEGER, INTEGER, INTEGER]. This does not break any existing code, but provides additional `left_offset' and `right_offset' queries (items 3, 4). Items 1, 2 still return the width and height of the string, but this is only the dimensions to be used when placing multiple strings next to each other. Some characters on more exotic fonts may still extend past this boundary, and the rectangle that fully encloses the string is given by adding the left and right offsets to the width.
+** Added `height_in_points' and `set_height_in_points' for setting the height of a font in points (1/72 of an inch). This may be used to ensure that your fonts occupy the same height on screens with varying resolutions.
+
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_DRAWABLE''' - `draw_text' and `draw_text_top_left' now both support text containing new line characters.
+** '''EV_APPLICATION''' - `focused_widget' had a side effect which may modify the index of some containers.
+** '''EV_DYNAMIC_TREE_ITEM''' - fixed `count' which was not executing the subtree function as necessary when called.
+** '''EV_TREE''' - Fixed bug in `has_recursively' which failed if there were one or more dynamic tree items contained.
+** '''EV_MULTI_COLUMN_LIST''' - Fixed bug in `set_column_alignments' which crashed if you called it with an empty list after having previously called it with a non empty list.
+** '''EV_FIGURE_TEXT''' - Fixed bounding size issues which would cause the `width' and `height' to be returned incorrectly, causing them to be not correctly cleared when moved in a figure world.
+** '''EV_FIGURE_GROUP''' - Fixed both `append' and `make_from_array' which were not setting the `group' of each item inserted.
+
+* '''Windows'''
+** '''EV_WINDOW'''
+*** `move_actions' was always passing positive values for the x and y coordinates of the window, even if they should have been negative.
+*** Showing two or more dialogs relative to a window and then hiding the focused relative dialog could cause the window to move being the next window in the Z order. This has now been fixed.
+
+** '''EV_FONT'''
+*** Fixed bug when using `preferred_families' after creating a font via `make_with_values'. The family that was specified was previously ignored.
+*** Fixed bug in `copy' which in certain cases could lead to a copied font not exhibiting the typeface as the original, even though no assertions were violated.
+
+** '''EV_SCROLL_BAR''' - Fixed handling of scroll bars with upper values greater than 32,000. Previously, dragging the bar of a scroll bar past this limit, corrupted the position of the bar and the `value'.
+** '''EV_TEXT'''
+*** Corrected `last_position_from_line_number' which was returning an incorrect position when there were multiple lines of text contained, and you queried the final line.
+*** Modified `insert_text' so that the control is no longer scrolled to the top as a result. The original position is now maintained wherever possible.
+*** Corrected handling of selection for caret positions greater than 64,000 characters. The following features were broken when using caret positions greater than 64,000: `caret_position', `has_selection', `selection_start' and `selection_end'
+
+** '''EV_SPIN_BUTTON'''
+*** Corrected positioning in parent container. In many situations, the spin button mis-behaved and would be moved to the 0x0 pixel position in the parent.
+*** Fixed tooltips which were never displayed.
+
+** '''EV_LIST_ITEM''' - Setting a pixmap to an item that was already displayed in a list and had a text would cause the end of the text to be cut off. This is now fixed.
+** '''EV_COMBO_BOX''' - Fixed tooltips which were never displayed.
+** '''EV_TOOL_BAR''' - Fixed a number of serious GDI leaks, the worst of which occurred when items that had a pixmap were removed from a tool bar.
+** '''EV_PROGRESS_BAR''' - Fixed bug which was limiting values in the range 0 to 65535.
+** '''EV_TEXT_FIELD''' - calling `set_font' now updates the `minimum_height' of the text field so that it is large enough to completely display the font.
+
+* '''Gtk'''
+** '''GTK 2.4''' EiffelVision 2 has been completely upgraded from gtk 1.2 to version 2.4 and provides completely new implementations for EV_LIST, EV_COMBO_BOX, EV_FILE_DIALOG, EV_MULTI_COLUMN_LIST, EV_CLIPBOARD, EV_MENU, EV_TREE, EV_FONT, EV_PIXMAP using the latest gtk widget set
+** '''EV_WIDGET''' Fixed a screen positioning for all widgets
+** '''EV_GAUGE''' Fixed bounds setting
+** '''EV_DIALOG''' Now key presses work whilst in Pick and Drop
+** '''EV_WIDGET''' Now motion events pass x and y coordinates relative to the captured widget
+
+
+==EiffelStudio 5.4==
+
+'''Interface modifications'''
+* '''EV_ITEM_PIXMAP_SCALER''' - New class added which provides no new functionality, but is a clean abstraction of `pixmaps_width', `pixmaps_height' and `set_pixmaps_size' which were all defined independently in EV_TREE, EV_LIST, EV_MULTI_COLUMN_LIST and EV_COMBO_BOX. Your code will not be affected by this change.
+* '''EV_TOOL_BAR''' - Added three new features `has_vertical_button_style', `enable_vertical_button_style' and `disable_vertical_button_style'. The default style for buttons is vertical and was the only style previously available, in which the `pixmap' is displayed above `text'. When vertical style is disabled, the `pixmap' of a button will be displayed to the left of its `text'.
+* '''EV_TREE ''' - No longer inherits EV_TREE_NODE_CONTAINER which is now obsolete. Made `selected' obsolete, use selected_item /= Void instead.
+* '''EV_TREE_NODE''' - Now inherits EV_TREE_NODE_LIST instead of EV_TREE_NODE_CONTAINER. This provides more functionality at the level of the node, but does not change the features available in non deferred descendents, as they all previously inherited EV_TREE_NODE_LIST. Changed type of `parent' to EV_TREE_NODE_LIST from EV_TREE_NODE_CONTAINER. Removed three obsolete features - `align_text_left', align_text_center' and `align_text_right'.
+* '''EV_TREE_ITEM''' - Strengthened `is_expandable' so that it checks `parent_tree' is not Void, this brings it into line with the preconditions of `expand'.
+* '''EV_DYNAMIC_TREE_ITEM''' - Strengthened `is_expandable' to check `parent_tree', in line with preconditions of `expand'. Added "valid_operands" precondition to `set_subtree_function' which ensures that you only pass a function with valid operands.
+* '''EV_TREE_NODE_CONTAINER''' - Now obsolete, you should use EV_TREE_NODE_LIST instead.
+* '''EV_MULTI_COLUMN_LIST''' - Added missing postconditions to `align_text_left', `align_text_right', `align_text_center' and other miscellaneous features that were missing relevant postconditions.
+* '''EV_MENU''' - Tightened preconditions of `show' and `show_at' to ensure that the menu is not parented.
+* '''EV_TEXT''' Added `has_word_wrapping', `enable_word_wrapping' and `disable_word_wrapping'. These features allow you to switch between horizontal word wrapping, in which lines too long to be displayed will be wrapped, and no word wrapping, in which horizontal scroll bars will be displayed, allowing you to view the complete contents of each line. Previously EV_TEXT would always wrap lines, and the default behavior is `has_word_wrapping' as it was before these changes.
+* '''EV_TEXT_COMPONENT''' - Added `has_selection' precondition to `selected_text' which requires that `has_selection' must be True for you to call `selected_text'.
+* '''EV_FILE_DIALOG''' - Added `valid_file_title' for validation of a file name excluding the path.
+* '''EV_STANDARD_DIALOG''' - Corrected postcondition of `make_with_text' which was checking that `text' was the same object as the STRING passed as an argument. This was incorrect, as `text' is cloned during the creation.
+* '''EV_WIDGET''' - Added `remove_real_target' which ensures that `real_target' is Void.
+* '''EV_WIDGET_ACTION_SEQUENCES''' - Added `mouse_wheel_actions', fired each time that the mouse wheel is scrolled.
+* '''EV_NOTEBOOK''' - Now inherits EV_FONTABLE permitting a font to be applied to the item texts.
+* '''EV_ENVIRONMENT'''
+** Added `mouse_wheel_scroll_lines' which returns an INTEGER corresponding to the number of lines that should be scrolled in response to each mouse wheel scroll event received.
+** Added `has_printer' which returns `True' if at least one printer is installed.
+
+* '''EV_PRINT_CONTEXT''' - Added `horizontal_resolution' and `vertical_resolution' which return the page size in pixels of the page type selected from an EV_PRINT_DIALOG. This permits you to adjust the figure world you are printing to an EV_PRINT_PROJECTOR based on the limits of the page, as determined by `horizontal_resolution' and `vertical_resolution' in pixels.
+* '''EV_APPLICATION''' - Added `process_events_until_stopped' and `stop_processing', similar to `process_events', except the processing is executed until `stop_processing' is called.
+* '''EV_PRINT_PROJECTOR''' - Added `has_printer' check to `make_with_context', ensuring that if you are to print to a printer, at least one printer is available.
+* '''EV_PRINT_CONTEXT''' - `default_create' now initializes a set of standard values, permitting the printing to the default printer, using US letter size.
+* '''EV_RELATIVE_POINT''' - The features `set_x_abs', `set_y_abs', `set_angle_abs', `set_scale_x_abs' and `set_scale_y_abs' now all have a precondition ensuring that you may only call them while `being_positioned' is True, which is only the case during execution of a custom positioning agent. Previously, if they were called at other times, the values set would be overridden.
+* '''EV_FIGURE''' - `accept_cursor' and `deny_cursor' are now available as queries.
+* '''EV_ABSTRACT_PICK_AND_DROPABLE''' - `set_accept_cursor' and `set_deny_cursor' no longer accept `Void' arguments.
+* '''EV_FIGURE_MATH ''' - 'line_angle' now correctly returns the angle in radians relative to world.
+* '''EV_ARROWED_FIGURE''' - 'start_angle' and 'end_angle' now work in all circumstances
+* '''EV_FIGURE_STAR''' - First line generated is now created from 'point_b'
+* '''EV_FIGURE_EQUILATERAL''' - First point generated is now based upon 'point_b'
+
+'''Breaking changes'''
+* '''EV_TREE_NODE_CONTAINER''' - This class is no longer used in EiffelVision2, and if you were relying on it, you should use EV_TREE_NODE_LIST instead. The type of `parent' for tree nodes has been changed from EV_TREE_NODE_CONTAINER to EV_TREE_NODE_LIST, so if you retrieve the `parent' and then attempt to iterate, you may have declared an instance of EV_TREE_NODE_CONTAINER. In this situation, you should simply change the definition to EV_TREE_NODE_LIST instead.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_DYNAMIC_TREE_ITEM''' - No longer crashes if your `subtree_function' returns Void. In this situation, it will now behave as if the `Result' was empty.
+** '''EV_BOX''' - Attempting to dock from an EV_DOCKABLE_SOURCE while the box was empty would not work. This has now been fixed.
+** '''EV_TEXT_COMPONENT''' - Calling `append_text', `prepend_text' or `insert_text' while `is_editable' is False caused a precondition failure in the implementation which is now fixed.
+** '''EV_DOCKABLE_SOURCE'''
+*** It was previously not possible to dock to an empty window, as the target was ignored in error.
+*** Fixed bug which caused a crash if a dock was attempted to an empty box.
+
+** '''EV_CHECKABLE_LIST''' - Corrected postcondition of `checked_items' which was checking `selected_items' in error, and therefore almost always failing.
+** '''EV_APPLICATION''' - Querying `focused_widget' if the window with the focus was empty caused a crash. This has now been fixed, and in this situation, the window itself is returned.
+** '''EV_FIGURE_TEXT''' - Fixed handling of `preferred_fonts' from the `font', which was not taken into account. Previously, the default font was always used.
+** '''EV_DYNAMIC_LIST''' - Fixed `retrieve_item_by_data' and `retrieve_items_by_data' which were always performing object comparison, even when reference comparison was selected by passing `False' as the second argument.
+** '''EV_TREE_NODE_LIST''' - Fixed `retrieve_item_recursively_by_data' and `retrieve_items_recursively_by_data' which were always performing object comparison, even when reference comparison was selected by passing `False' as the second argument.
+** '''EV_CONTAINER''' - Fixed bug in `unmerge_radio_button_groups' which would crash if the container had no radio buttons.
+
+* '''Windows'''
+** '''EV_TEXT_COMPONENT''' - fixed bug in `select_region' which would fail if `start_pos' was greater than `end_pos'.
+** '''EV_PIXMAP'''
+*** `expose_actions' previously had a feature contained related to the implementation, and calling `wipe_out' on `expose_actions' would stop the image from being redrawn. There are now no side effects related to `expose_actions'.
+*** Calling `copy' on a pixmap that was parented in an EV_CONTAINER, and therefore displayed on screen had no visual effect until the window was re-painted. The image is now updated immediately. Also, using `copy' on a pixmap in a similar situation that was originally set with a masked icon, and passing a pixmap created from a bitmap file would cause a crash.
+*** Fixed display error in handling of pixmaps created from a PNG with a transparent color, using `set_with_named_file'. The background would be garbled and partially black.
+
+** '''EV_LIST'''
+*** Calling `disable_sensitive' when already non sensitive would loose the original selection, and calling `enable_sensitive' when already sensitive would alter the selected item. The features will no longer alter the selection if called twice.
+*** Fixed result of `background_color' which was returning gray instead of white before a color was assigned
+'''EV_CELL''' - If you removed the item, the minimum size was not updated to reflect this, thereby retaining the minimum size as constrained by the minimum size of the now removed item.
+** '''EV_TREE_ITEM'''/ '''EV_TREE''' - A call to `disable_select' on an EV_TREE_ITEM will now actually remove the selection from the tree. Previously, the style of the item was changed, but a call to `selected_item' on the tree would still return the item.
+** '''EV_FILE_DIALOG''' - Fixed precondition violation when you calling `set_file_name' which was rejecting directory separators.
+** '''EV_DIALOG''' - Fixed a bug when you had two dialogs displayed modally, with the second modal to the first. If you had a text field within the second dialog whose `return_actions' contained an agent which would destroy the second dialog, the `select_actions' of the `default_push_button' in the lower dialog would be subsequently fired.
+** '''EV_LABEL''' - If a label was disabled through the disabling of a container in which it was contained, it would sometimes not be grayed out. This has now been fixed.
+** '''EV_PICK_AND_DROPABLE'''
+*** `mode_is_target_menu' did not work for a pick and drop source whose `pebble' was generated by a `pebble_function'.
+*** Fixed bug where drag and drop was not working as it was attempting to perform docking instead. If both are enabled, docking has priority.
+
+** '''EV_COMBO_BOX_IMP'''
+*** Fixed `set_foreground_color' and `set_background_color' which previously did nothing.
+*** Fixed bug in selection. If during execution of the `select_actions' of an item contained, you called `enable_select' on another item within the combo box, subsequently selecting the originally selected item would no longer fire its `select_actions'.
+*** `enable_edit' and `disable_edit' were both causing the pixmaps of any items contained to be no longer displayed.
+
+** '''EV_PRINT_DIALOG''' - Querying `print_context' from a print dialog if a user selected "Cancel" would previously crash.
+** '''EV_TREE''' and '''EV_MULTI_COLUMN_LIST''' - Fixed result of `background_color' which was returning gray instead of white before a color was assigned
+** '''EV_SCREEN''' - `widget_at_pointer_position' now returns the combo box if the mouse pointer is held above the drop down list button of a combo box. Previously, `Void' was returned.
+
+* '''Gtk'''
+** '''EV_TREE_NODE''' - Now expansion state remains the same when 'set_pixmap' is called.
+** '''EV_DIALOG''' - Fixed bug where 100 percent of CPU time was being used when dialog was shown modally.
+** '''EV_WINDOW''' - Now sizing invariants are fulfilled when widget is destroyed, preventing segmentation violation.
+** '''EV_COMBO_BOX'''
+*** Fixed bug where reselecting an item within the combo box list was in fact deselecting it.
+*** Now first item remains selected when items are added.
+
+** '''EV_WINDOW''' - Fixed querying of positioning which never changes if previously set by user.
+** '''EV_APPLICATION''' - Priority of `idle_actions' has been changed so that gtk will recalculate widgets sizes before calling its idle handler, this means that all resizing is done before idle actions are called.
+** '''EV_WINDOW ''' - Now windows correctly shrink when requested size is smaller than current size
+** '''EV_PICK_AND_DROPABLE''' - Fixed bug where if both drag and drop and docking were enabled, both would be executed, now docking overrides drag and drop if both are enabled.
+** '''EV_TIMEOUT ''' - Now timeouts correctly unregister themselves on dispose preventing segmentation violation.
+** '''EV_PIXMAP ''' - Pixmap stretching now works as expected.
+** '''EV_WINDOW''' - Now all window specific events work as expected
+** '''EV_TITLED_WINDOW''' - Now is_displayed returns false when window is minimized.
+** '''EV_TREE_NODE''' - Insertion of children at specific rows now displays as expected.
+** '''EV_WINDOW''' - Now windows have a border and are resizable to match Win32 behavior
+** '''EV_SPLIT_AREA''' - Now 'split position' honors request when widget resize is pending
+** '''EV_DRAWING_AREA ''' - Fixed full size optimization so that all expose actions are handled correctly
+** '''EV_TEXT_COMPONENT - ''' Fixed issue where up and down arrow keys caused widget to lose focus unnecessarily
+** '''EV_FONT''' - Now preferred families are taken in to account when no style is set
+** '''EV_STANDARD_DIALOG '''- Now all file handling dialogs are resizable
+
+
+==EiffelStudio 5.3==
+
+'''Interface modifications'''
+* '''EV_TITLED_WINDOW_ACTION_SEQUENCES''' added which is inherited only by EV_TITLED_WINDOW and provides three new action sequences :- `minimize_actions', `maximize_actions' and `restore_actions'.
+* '''EV_TITLED_WINDOW'''
+** You may now only call `maximize' and `minimize' if `is_show_requested'.
+** When minimized, `is_displayed' now returns False.
+
+* '''EV_BUTTON''' now inherits EV_FONTABLE, allowing you to modify the font displayed.
+* '''EV_DYNAMIC_LIST_ITEM''' - Corrected `off' which was using the version inherited from EV_TREE_NODE when it should have been using the version from EV_TREE_NODE_LIST instead.
+* '''EV_RECTANGLE''' - Added precondition to `intersects' which stops a Void rectangle being passed as an argument.
+* '''EV_TOOL_BAR_SEPARATOR''' - Now export many inherited features to {ANY} instead of {NONE}, including `parent'.
+* '''EV_ENVIRONMENT''' - Added `supported_image_formats' which returns a LINEAR [STRING] containing all valid formats by their three letter extension.
+* '''EV_CHECKABLE_LIST''' - New class added which behaves as an EV_LIST, except that for each EV_LIST_ITEM contained, an associated check box is displayed.
+* '''EV_MESSAGE_DIALOG''' - No longer deferred, and has two creation procedures `default_create' and `make_with_text'.
+* '''EV_STANDARD_DIALOG''' - All descendents now have `make_with_text' as a creation procedure'.
+* '''EV_TABLE''' - Now inherits CHAIN instead of ARRAY. This is a breaking change, and may require some modification to your code. The inheritance from ARRAY was seriously flawed. For example, if you were to call `extend' on an EV_CONTAINER object that was currently referencing an EV_TABLE, then this would fail. Now that we inherit CHAIN, this problem, among others of a similar nature are fixed. Another advantage of inheriting CHAIN, is that the table may now be iterated which allows for greater flexibility.
+
+The following list details some of the breaking changes, and how to fix them:
+** '''item''' - If you were using `item', you should change this to `item_at_position'. A call to `item' will now return the current item.
+** '''put''' - If you were using `put', you must now replace this with `put_at_position'.
+** '''extend''' and '''replace''' - These are now both exported, as before, they were exported to {NONE}.
+** features inherited from '''ARRAY''' - These are no longer available but you may use the feature `to_array', which returns the contents of the table represented as an ARRAY [EV_WIDGET]. This feature is marked as obsolete, as it is temporary, to simplify the transition to the new inheritance structure of EV_TABLE.
+** '''count''' - The previous version of `count' was the one from ARRAY, which returned the number of available (not empty) cells in the table. We now use the version of `count' inherited from EV_CONTAINER which returns the number of widgets currently contained. Previously, the feature `widget_count' was used to return the number of items, but this feature has now been made obsolete. Therefore, if you were previously using `count', replace this with `rows' * `columns', and if you were using `widget_count', replace this with a call to `count'.
+** '''item_list''' - This is now obsolete. You may use `linear_representation' to retrieve the contents of the table, or simply traverse the table.
+
+* '''EV_FIXED''' - No longer inherits DOUBLE_MATH.
+* '''EV_VIEWPORT''' - No longer inherits DOUBLE_MATH.
+* '''EV_TEXT''' - `line_count' now returns the number of lines actually displayed, and not just the newline characters, as an EV_TEXT will wrap the text when necessary. The postcondition of `linecount' has been updated to reflect this change.
+* '''EV_FILE_DIALOG''' Added "valid_file_name" precondition to `set_file_name' and a new feature `valid_file_name' which checks that a file name is valid on the current platform.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_WIDGET''' - `pointer_style' now correctly returns the Ibeam cursor for textable widgets.
+** '''EV_FIGURE_RECTANGLE'''
+*** Corrected `bounding_box' which was previously computed incorrectly when the rectangle was rotated.
+*** Fixed `width' and `height' which were always returning one less pixel than they should have.
+
+
+* '''Windows'''
+** '''EV_PIXMAP''' - Setting a tile with `set_tile' followed by a call to a fill routine would crash the implementation.
+** '''EV_COMBO_BOX''' - Implemented pick and drop.
+** '''EV_TEXT_FIELD''' - Implemented pick and drop.
+** '''EV_PASSWORD_FIELD''' - Implemented pick and drop.
+** '''EV_TEXT'''
+*** Implemented pick and drop.
+*** If not `is_editable' and a `background_color' had been set, it was only used on lines containing text. The `background_color' is now correctly displayed throughout the whole control when not `is_editable'.
+*** Fixed `select_region' which was selecting an incorrect region starting on any line except the first, when the `text' spanned multiple lines.
+*** Fixed `selection_start' and `selection_end' which were incorrect when the selection was not completely contained on the first line.
+*** Fixed `first_position_from_line_number' and `last_position_from_line_number' which were returning incorrect values when the text was wrapped.
+*** Fixed `caret_position' and `set_caret_position' which were incorrect when the text spanned multiple lines, and the caret was not on the first line.
+*** `line_count' now returns the number of lines actually displayed, and not simply the number of newline characters. To query the number of new line characters do :- text.occurrences ('%N')
+*** Fixed bug in `search' which was returning -1 instead of 0 when the text was not found.
+
+** '''EV_DRAWABLE''' - Fixed bug when you performed the following: drew a filled shape, called `set_tile' and then drew another filled shape. The tile would not be used on the second fill.
+** '''EV_COLOR_DIALOG''' - Querying `color' after a user had canceled the dialog would previously crash a system, if `set_color' had never been called.
+** '''EV_COLOR''' - Fixed `set_rgb_with_24_bit' which would fail when called.
+** '''EV_BUTTON, EV_TOGGLE_BUTTON''' - The buttons now correctly display a text, pixmap and background color simultaneously. Previously, the background color was never displayed, and either the pixmap or text would be displayed, not both.
+** '''EV_PRINT_DIALOG''' - Fixed `set_from_page' and `set_to_page' which were previously not implemented.
+** '''EV_LIST'''
+*** Fixed a graphical glitch when using `wipe_out' when items were contained that required the horizontal scroll bar to be visible. The scroll bar was not hidden, even though there were no longer any items in the list.
+*** Changing the selection behavior between multiple and single selection would cause the scroll bars to become hidden, even if they were necessary. Changing this status will no longer hide the scroll bars if they are required.
+
+** '''EV_TOOL_BAR'''
+*** Items that were disabled would sometimes become enabled when other properties of the item were set. For example, performing "my_tool_bar_button.disable_sensitive" followed by "my_tool_bar_button.set_text ("Disabled")" while the button was parented, would result in a sensitive tool bar button. This is now fixed.
+*** If you changed the `text' of a tool bar toggle button during the firing of the `select_actions' of the toggle button, the button would become unchecked as a result. This is now fixed, and changing the text will not stop the button from becoming selected.
+
+** '''EV_MULTI_COLUMN_LIST''' - Changing the selection behavior between multiple and single selection would cause the scroll bars to become hidden, even if they were necessary. Changing this status will no longer hide the scroll bars if they are required.
+** '''EV_DYNAMIC_TREE_ITEM''' - Calling `set_tooltip' failed and has now been fixed.
+** '''EV_TIMEOUT''' - Calling `destroy' more than once on a timeout, caused the implementation to crash, and has now been fixed.
+** '''EV_TOOLTIPABLE''' - Tooltips on primitives were not supporting multiple lines and this has now been fixed. Use %N for a line break.
+
+* '''Gtk'''
+** '''EV_SCROLLABLE_AREA''' - Items smaller than the area are now positioned correctly.
+** '''EV_VIEWPORT'''
+*** Widget now works correctly with negative offset values
+*** Item position is now handled correctly on item resize.
+
+** '''EV_PIXMAP''' - All drawing routines now flush immediately to screen.
+** '''EV_DIALOG''' - Canceling via Enter key is now handled correctly.
+** '''EV_LIST''' - Fixed selection of selected item when changing from multiple selection to single selection.
+** '''EV_MULTI_COLUMN_LIST'''
+*** Row height now incorporates spacing pixel to match the implementation of Windows.
+*** Default row height is now slightly larger to be more aesthetically pleasing with smaller fonts sizes.
+
+** '''EV_CONTAINER'''
+*** `set_background_pixmap' now works with repeated parenting.
+*** Radio group unmerging is now handled correctly.
+
+** '''EV_TEXT_FIELD ''' - Now vertical alignment is identical to that on Windows, including that for text field descendants.
+** '''EV_RANGE ''' - Now motions events are passing consistent pointer values instead of sometimes skewed ones.
+** '''EV_DRAWING_AREA''' - Now `focus_in_actions' are called in all circumstances.
+** '''EV_TEXT'''
+*** `scroll_to_line' is now implemented.
+*** `line_count' and `current_line_number' now handle lines in text widget and not the text itself.
+
+** '''EV_FIXED''' - Now item sizing is correctly handled in all circumstances.
+** '''EV_NOTEBOOK''' - Now tabs are more aesthetically pleasing.
+** '''EV_MENU_SEPARATOR ''' - Menu Separators are now more prominent.
+** '''EV_TOOLBAR_SEPARATOR - '''Toolbar Separators are now more prominent.
+
+
+
+
+==EiffelStudio 5.2==
+
+'''Interface modifications'''
+* '''EV_TEXTABLE''' - `align_text_left', `align_text_right' and `align_text_center' have been extracted into a new class, EV_TEXT_ALIGNABLE which inherits EV_TEXTABLE. All previous descendents of EV_TEXTABLE now inherit EV_TEXT_ALIGNABLE, except EV_TREE_NODE, EV_MENU_ITEM, EV_LIST_ITEM and EV_TOOL_BAR_BUTTON
+* '''EV_TEXT_COMPONENT''' - Now inherits EV_TEXTABLE.
+* '''EV_TEXT_ALIGNMENT_CONSTANTS''' - New class added to support EV_TEXT_ALIGNABLE.
+* '''EV_MENU_ITEM_LIST''' - `parent' is now of type EV_ANY, instead of EV_MENU_ITEM_LIST as it did not hold for EV_MENU_BAR. The renaming of `parent' to `old_parent' in EV_MENU_BAR has now been removed.
+* '''EV_VIEWPORT''' - added `set_item_width', `set_item_height' and `set_item_size'.
+* '''EV_TABLE'''
+** redefined `prunable' to `True' and implemented `prune'.
+** Added the following features - `set_item_span', `set_item_position', `set_item_span_and_position', `area_clear_excluding_widget', `item_row_span', `item_column_span', `item_row_position' and `item_column_position'.
+
+* '''EV_WIDGET''' - Changed type of `focus_in_actions' and `focus_out_actions' from EV_FOCUS_ACTION_SEQUENCE to EV_NOTIFY_ACTION_SEQUENCE. `is_parent_recursive' is no longer available. It has been moved to EV_CONTAINER. This was necessary to fix a catcall encountered using vision2 under .NET. The problem manifested with widgets that held items.
+* '''EV_FIGURE''' - `proximity_in_actions' and `proximity_out_actions' are now obsolete.
+* '''EV_FONTABLE''' - `set_font' now sets a copy of the font internally.
+* '''EV_TREE''' - `ensure_item_visible' and `has_recursively' now take an EV_TREE_NODE as arguments, instead of an EV_TREE_ITEM.
+* '''EV_TEXT''' - `put_new_line' is now obsolete. Use `set_text ("%N") instead."
+* '''EV_APPLICATION_ACTION_SEQUENCES''' - Added `cancel_actions', fired when a pick and drop is canceled, and `pnd_motion_actions' fired while the pointer moves during a pick and drop.
+* '''EV_TREE_NODE_LIST'''
+** `find_item_recursively_by_data', `has_recursively' and `recursive_do_all' are now implemented in this class, instead of both EV_TREE and EV_TREE_NODE which are descendents.
+** Added `retrive_items_recursively_by_data' and `retrieve_item_recursively_by_data' which allow you to specify a comparison criterion, and due to this addition, `find_item_recursively_by_data' has now been made obsolete.
+
+* '''EV_DYNAMIC_LIST''' - Added `retrieve_item_by_data' and `retrieve_items_by_data'.
+* '''EV_ITEM_LIST''' - Made `item_by_data' obsolete, as you should now use `retrieve_item_by_data' added in EV_DYNAMIC_LIST.
+* '''EV_DIALOG''' - Added `is_relative' and defined `is_modal' in this class, instead of inheriting it from EV_WINDOW.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_FIGURE_POLYLINE''' - Fixed `start_angle' and `end_angle' so that they are computed relative to the first and last polyline segments. This also fixes the start and end arrows, so that when displayed, they now actually point in the direction of their respective line segments.
+** '''EV_TREE and EV_TREE_NODE''' - Fixed `find_item_recursively_by_data' which failed on the `index_not_changed' postcondition. Note that these features are now defined in EV_TREE_NODE_LIST.
+** '''EV_DYNAMIC_TREE_ITEM''' - Fixed invariant violation from EV_ITEM_LIST, when created with `default_create'.
+
+* '''Windows'''
+** '''EV_RADIO_BUTTON''' - The default minimum height after `default_create' is now enough to display the widget correctly.
+** '''EV_CHECK_BUTTON''' - The default minimum height after `default_create' is now enough to display the widget correctly.
+** '''EV_NOTEBOOK''' - When removing a widget from a notebook, it is now visible. Previously, the widget would be hidden.
+** '''EV_LIST, EV_MULTI_COLUMN_LIST, EV_TREE''' - Fixed `set_foreground_color' and `set_background_color'. Previously, calling these features did nothing.
+** '''EV_BOX''' - If a widget was not`is_item_expanded', then adding a new widget to the box before that widget would sometimes cause a different widget to become `is_item_expanded'.
+** '''EV_TOOL_BAR_RADIO_BUTTON''' - The currently selected button in `peers' was unselected when the button was pressed, and not when it was really selected. This bug made it possible to make `selected_peer' Void, which caused an invariant to fail.
+** '''EV_LIST_ITEM''' - Calling `enable_select' when parented in an EV_LIST now also sets the item as focused in the parent. This corrects bugs in keyboard navigation when selecting an item programatically.
+** '''EV_FIXED''' - The minimum size is constrained by the positions and sizes of the children (They must be completely displayed), although when the positions of the children were reduced, the minimum allowable size was not recomputed. This meant that the widget would be enlarged when the positions of the children increased, but could never be reduced in size when the positions of the children were decreased.
+** '''EV_MENU and EV_MENU_ITEM''' - `set_pixmap' has been implemented as previously, it did nothing.
+** '''EV_TABLE''' - re-implemented resizing calculations to fix numerous problems when children had minimum sizes. The minimum size now also includes the border width when empty.
+** '''EV_NOTEBOOK''' - `selection_actions' were called when you selected an item through `select_item', even if the item was already selected. `selection_actions' are now only fired when the selection changes.
+** '''EV_TREE_ITEM''' - calling `set_pixmap' twice successively with the same EV_PIXMAP caused a postcondition failure.
+** '''EV_TEXT''' - Fixed `put_new_line', although it has been made obsolete, as you should just use `append_text ("%N") instead.
+** '''EV_SPLIT_AREA''' - Fixed crash reproducable by inserting an EV_PIXMAP directly into the split area.
+** '''EV_CONTAINER''' - Fixed `propagate_foreground_color' and `propagate_background_color' which failed when one of the children was a descendent of EV_CELL.
+** '''EV_APPLICATION_ACTION_SEQUENCES''' - `drop_actions' was being fired even when the pick and drop was canceled.
+** '''EV_PIXMAP''' - Previously, if you were to add an agent to an action sequence of the pixmap, before it was parented, the agent would be removed during the parenting.
+** '''EV_MENU'''
+*** Pruning an EV_MENU_SEPARATOR when one or more EV_RADIO_MENU_ITEM were still contained in the menu would cause occasional crashes.
+*** Previously, when adding an EV_MENU_SEPARATOR, followed by multiple EV_RADIO_MENU_ITEMS, all the items were being selected.
+*** Fixed bug in `destroy' which was causing postcondition failures.
+
+** '''EV_TITLED_WINDOW''' - Fixed a GDI leak, manifesting when a window was destroyed.
+** '''EV_DIALOG'''
+*** Fixed `is_modal' which was previously always returned `False'.
+*** Fixed bug with `background_color' and `foreground_color' which was not taken into account if the dialog was shown relative or modally to another window.
+*** If a dialog with a default cancel button was displayed using `show', then minimizing the dialog would cause the system to fail internally.
+*** Fix bug in `show_relative_to_window' which would cause any associated menus to be removed.
+*** Fixed bug in `show', as if the dialog had already been shown modelessly to a window, then calling `show' did not show it independently, but still modelessly.
+*** Fixed bug with `show_actions' which would be wiped out if you called `show_modal_to_window' and then `hide'.
+*** `set_pixmap' will now actually display the pixmap, whereas before, no pixmap was displayed.
+
+** '''EV_TEXT_COMPONENT''' - Fixed `text_length' which was returning incorrect value for all descendents.
+** '''EV_TEXT''' - Fixed `line_count' which was previously returning the correct result + 1.
+** '''EV_SCROLLABLE_AREA''' - Fixed crash which occurred when you attempted to use `set_x_offset' or `set_y_offset' before the area had been parented or displayed.
+** '''EV_FONTABLE''' - Fixed bug when `font' was queried, `preferred_families' was not returned correctly, and would always be empty.
+** '''EV_CONTAINER''' - `set_background_pixmap' was not correctly cloning the image of the pixmap, and the displayed image could then be modified after setting, by changing the image of the original pixmap.
+
+* '''Gtk'''
+** Remaining EV_WIDGET memory leaks have been fixed.
+** '''EV_WIDGET'''- Focus in/out actions are now correctly called for widgets that do not occupy their entire space allocation such as EV_TEXT_FIELD.
+** '''EV_DRAWABLE_IMP''' - Polylines now display correctly on big-endian machines (Sparc, PowerPC).
+** '''EV_KEY'''
+*** `out' is now correct for all keys (previously Quote and Backquote were incorrect).
+*** The events for all keys are now fired when Shift is held down.
+
+** '''EV_STOCK_PIXMAPS''' - Warning and error pixmaps have been updated.
+** '''EV_WINDOW''' - `remove_title now' works will all Window Managers.
+** '''EV_TITLED_WINDOW'''
+*** `propagate_foreground_color' is now fixed in use with pixmaps as children.
+*** `set_maximum_size' now works as expected
+*** `set_minimum_width' now has no effect on Window height.
+*** calls on `minimize' before `launch' now satisfies all assertions
+*** calling `destroy' twice now doesn't fail on precondition.
+*** `set_position' now satisfies post-condition in all situations.
+*** `resize_actions' are now passed the correct values.
+*** `move_actions' are now called correctly.
+
+** '''EV_NOTEBOOK''' - now satisfies invariants when empty.
+** '''EV_DIALOG'''
+*** Destroy now satisfies all invariants.
+*** Reported memory leaks now fixed.
+
+** '''EV_LABEL''' - Size is now taken from default gtk style size instead of hard coded 10
+** '''EV_FONT''' - Font caching is now vastly improved in terms of speed.
+** '''EV_DRAWABLE''' - Calls to `set_font' are now also vastly speeded up.
+** '''EV_TABLE'''
+*** Memory management is now correct on item removal.
+*** Now setting child's parent correctly
+
+** '''EV_TREE_NODE'''
+*** Fixed all reported issues regarding item insertion and removal.
+
+** '''EV_CONTAINER''' - Fixed remaining issues with radio grouping and merging.
+** '''EV_PICK_AND_DROPABLE''' - Now drop_actions may destroy `Current' without crash.
+** '''EV_TEXT_FIELD'''
+*** Now default `minimum_width' is reasonable (before 148, now same as Windows being 4 characters wide)
+*** Fixed `caret_position' when queried in change actions
+
+
+
+==EiffelStudio 5.1==
+
+'''Interface modifications'''
+* '''EV_TEXTABLE and EV_TEXT_COMPONENT''' - `text' no longer returns Void when empty.
+* '''EV_WINDOW''' - `title' no longer returns `Void' when empty.
+* '''EV_TOOLTIPABLE''' - `tooltip' no longer returns `Void' when empty. If empty, no tooltip is displayed.
+* '''EV_TITLED_WINDOW''' - `icon_name' no longer returns `Void' when empty.
+* '''EV_CLIPBOARD''' - `text' no longer returns `Void' when empty.
+* '''EV_MESSAGE_DIALOG''' - `text' no longer returns `Void' when empty.
+* '''EV_FILE_DIALOG''' - `file_name' no longer returns `Void' when the "Cancel" button was pressed, `Result' is empty instead.
+* '''EV_DIRECTORY_DIALOG''' - `directory' no longer returns `Void when the "Cancel" button was pressed, `Result' is empty instead.
+* '''EV_CONTAINER''' - has three new features `set_background_pixmap', `background_pixmap' and `remove_background_pixmap'. `background_pixmap' will be tessellated to cover complete background area.
+* '''EV_TREE and EV_TREE_NODE''' - Added `recursively_do_all'.
+* '''EV_STANDARD_DIALOGS'''
+** `ok_actions' have been renamed in descendents where appropriate. e.g. in EV_PRINT_DIALOG, they are renamed to `print_actions' to match the texts of the associated buttons. Where renamed, `ok_actions' are still available but obsolete.
+** Selected button now also returns the correct text of the button (Previously it was always "Ok").
+
+* '''EV_DIALOG_CONSTANTS''' - Added new constants required for the above change to EV_STANDARD_DIALOGS.
+* '''EV_DRAWABLE''' - `draw_straight_line' now has a precondition to ensure the points are not identical.
+* '''EV_SPLIT_AREA''' - separated `put' from `extend'. They were defined as synonyms, but have different behavior.
+* '''EV_DYNAMIC_TREE_ITEM''' - Added `remove_subtree_function'. Item now only shows as expandable if there is a subtree function.
+* '''EV_WINDOW''' - Added `maximum_dimension' which is the greatest value allowed for `width' and `height'. This is also the default value for `width' and `height'.
+* '''EV_OPTION_BUTTON''' - This class has been made obsolete. It will be removed at the next release.
+* '''EV_PICK_AND_DROPABLE_ACTION_SEQUENCES''' - Added `pick_ended_actions' which are called when a pick ends.
+* '''EV_WIDGET''' - `set_minimum_height', `set_minimum_width' and `set_minimum_size' now all allow 0 as an argument. Previously, 1 was the minimum valid dimension.
+* '''EV_MULTI_COLUMN_LIST''' - `clear_selection' is now obsolete. Use `remove_selection' instead.
+
+'''Bug fixes'''
+* '''Platform independent'''
+** '''EV_FIXED''' - Corrected `set_item_height', which was failing.
+** '''EV_SELECTABLE''' - Corrected postcondition of `is_selected'.
+** '''EV_PND_ACTION_SEQUENCE''' -- `veto_pebble_function' is now only called when its argument conforms to the transported pebble.
+
+* '''Windows'''
+** '''EV_RANGE''' - The `maximum_value' could not be set greater than 32,000. The full range of an INTEGER may now be set.
+** '''`focused_widget' from `EV_APPLICATION'''' - was incorrect if an EV_CONTAINER had just received the focus.
+** '''EV_PICK_AND_DROPABLE'''
+*** Ending a pick and drop on an EV_TOOL_BAR_BUTTON which has a non `void' pebble no longer starts a transport from the button.
+*** Reduced flicker on cursor when picking from an EV_TREE_ITEM or EV_LIST_ITEM.
+*** `pebble_function' would previously be called twice during a pick and drop.
+
+** '''EV_FIXED''' - Items contained are now drawn correctly dependent on their z order.
+** '''EV_DRAWABLE'''
+*** `Remove_clip_area' did not remove the clip_area correctly, but set it to the current size. This meant that if you then enlarged the widget, clipping would be applied.
+*** Fixed problems with ordering of calls to certain features which would cause postcondition violations in the implementation.
+*** `draw_pie_slice', `fill_pie_slice' and `draw_arc' now have divide by 0 protection in the implementation.
+
+** '''EV_TEXT''' - `set_background_color' now correctly sets the color of the whole background. Previously only the area containing text was modified.
+** '''EV_CLIPBOARD''' - Our implementation would sometimes query `text' when not allowed by Windows, thus causing postcondition failures.
+** '''EV_BUTTON''' - The result of `text_alignment' after default_create was incorrect.
+
+* '''Gtk'''
+** Gtk version of Studio released (including Vision2), so no fixes from 5.0
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/advanced.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/advanced.wiki
new file mode 100644
index 00000000..40e027cd
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/advanced.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Advanced]]
+[[Property:weight|0]]
+==Compiling==
+
+To compile the example, you must compile two projects: ''chat'' and ''join''.
+
+To compile the ''chat ''project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\advanced\chat\''.
+* Choose ''chat.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+To compile the ''join ''project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\advanced\join\''.
+* Choose ''join.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/index.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/index.wiki
new file mode 100644
index 00000000..d79d3b1d
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|EiffelNet Samples]]
+[[Property:weight|2]]
+=Description=
+
+Here is a set of five examples written thanks to the EiffelNet library to show some basic applications. Two of them rely on specific code to Unix Operating systems and consequently could not be run under Windows.
+* [[Advanced|Advanced]] : for Unix Operating systems.
+* [[Polling|Polling]]
+* [[Predef|Predef]]
+* [[Same Machine|Same mach]] : for Unix Operating systems.
+* [[Two Machines|Two mach]]
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/polling.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/polling.wiki
new file mode 100644
index 00000000..08aa0f25
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/polling.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Polling]]
+[[Property:weight|1]]
+==Compiling==
+
+To compile the example, you must compile two projects: ''client'' and ''server.''
+
+To compile the ''client'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\polling\client\''.
+* Choose ''polling_client.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+To compile the ''server'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\polling\server\''.
+* Choose ''polling_server.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/predef.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/predef.wiki
new file mode 100644
index 00000000..38bd0e78
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/predef.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Predef]]
+[[Property:weight|2]]
+==Compiling==
+
+To compile the example, you must compile two projects: ''client'' and ''server.''
+
+To compile the ''client'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\predef\client\''.
+* Choose ''our_client.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+To compile the ''server'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\predef\server\''.
+* Choose ''our_server.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/same-machine.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/same-machine.wiki
new file mode 100644
index 00000000..298f4106
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/same-machine.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Same Machine]]
+[[Property:weight|3]]
+==Compiling==
+
+To compile the example, you must compile two projects: ''client'' and ''server.''
+
+To compile the ''client'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\same_mach\client\''.
+* Choose ''our_client.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+To compile the ''server'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\same_mach\server\''.
+* Choose ''our_server.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/two-machines.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/two-machines.wiki
new file mode 100644
index 00000000..bc6d138d
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-samples/two-machines.wiki
@@ -0,0 +1,26 @@
+[[Property:title|Two Machines]]
+[[Property:weight|4]]
+==Compiling==
+
+To compile the example, you must compile two projects: ''client'' and ''server.''
+
+To compile the ''client'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\two_mach\client\''.
+* Choose ''our_client.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+To compile the ''server'' project:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\net\two_mach\server\''.
+* Choose ''our_server.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/bibliography.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/bibliography.wiki
new file mode 100644
index 00000000..30a299d9
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/bibliography.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Bibliography]]
+[[Property:weight|10]]
+[1] Bertrand Meyer: [http://www.eiffel.com/doc/] , Prentice Hall, 1992. (Available from Eiffel Software.)
+[2] Bertrand Meyer: [http://www.eiffel.com/doc/] , Prentice Hall, 1994. (Available from Eiffel Software.)
+[3] W. Richard Stevens: ''Unix Network Programming'', Prentice Hall, 1990.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/clients-and-servers.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/clients-and-servers.wiki
new file mode 100644
index 00000000..a8e2fd5b
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/clients-and-servers.wiki
@@ -0,0 +1,18 @@
+[[Property:title|Clients and servers]]
+[[Property:weight|1]]
+In the client-server model of computing, a number of software systems, the clients, may require general-purpose services provided by other systems, the servers. Clients and servers run concurrently, on the same machine or, more generally, on different machines connected through a network.
+
+Typically, the clients are systems, for example systems that provide useful facilities for human users; the servers take care of operations that clients could not perform on their own (or would perform less efficiently), and of operations that are common to several clients. Example of servers include:
+* '''Computation servers''', which take care of heavy or specialized computations not appropriate for the clients, assuming the servers' processors are more powerful.
+* '''File servers''' and '''database servers''', providing access to persistent data that different clients may need to access.
+
+The client-server relation is usually many-to-many: each client application, in the course of performing its duties, may successively require services from different servers; and each server may cater to different clients. This second aspect, illustrated by the following figure, is particularly important; it allows a single server to communicate with as many clients as appropriate.
+ [[Image:fig-1]]
+Although communication occurs both ways - clients sending objects to servers and conversely - the situation in such a scheme is usually not symmetric. Whereas a client requesting a certain service will need to know beforehand what server provides that service, the server, for its part, will not in general name its clients in advance; it will simply stand ready to provide its services to whatever suitable client happens to request them.
+
+This dissymmetry appears clearly in EiffelNet and in the examples of this manual. It means in particular that clients and servers act differently at the '''beginning''' of their client-server lifecycle. The party that initiates the communication is the client; in this operation it will identify the desired server (through a local file name for communication on the same machine, or though a machine name for network communication). The server simply makes itself ready for possible connections by starting to "listen" on the communication channels - relying for this on an EiffelNet procedure that is indeed called ''listen''.
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki
new file mode 100644
index 00000000..59af953a
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki
@@ -0,0 +1,202 @@
+[[Property:title|Event-driven command execution]]
+[[Property:weight|8]]
+{| border="1"
+|-
+| The example classes discussed in this section appear in the subdirectory ''polling ''of the example directory
+|}
+
+===9.1 Commands and events===
+
+In the preceding examples each participant in a communication had to get ready to send or receive at specific stages of its life. Although this did not preclude asynchronous communication, it is sometimes desirable to make the scheme even more asynchronous, and control more decentralized, by letting each system simply specify certain communication events that it wants to monitor, and certain commands to be executed on occurrence of the specified events.
+
+The commands are objects, instances of a general-purpose class COMMAND or its proper descendants. Class COMMAND has, among its features, a procedure ''execute'' which executes the current command; some commands are undoable and have an ''undo'' procedure.
+
+In EiffelNet the possible events associated with a socket will be of three kind: a read event; a write event; or a special event (out of bounds operation). The command classes will be descendants of [[ref:/libraries/net/reference/poll_command_chart|POLL_COMMAND]] , an heir of COMMAND.
+
+===9.2 Command classes===
+
+The example uses four command classes: CLIENT_DATAGRAM_READER, CLIENT_DATAGRAM_WRITER and their counterpart for servers, representing operations that must be triggered in the case of a read event and a write event.
+
+Here is the reader command for clients:
+
+ class
+ CLIENT_DATAGRAM_READER
+
+ inherit
+
+ POLL_COMMAND
+ redefine
+ active_medium
+ end
+
+ creation
+ make
+
+ feature
+
+ active_medium: NETWORK_DATAGRAM_SOCKET
+
+ execute is
+ -- Obtain a packet of ten characters and print them.
+ local
+ rec_pack: DATAGRAM_PACKET
+ i: INTEGER
+ do
+ rec_pack := active_medium.received (10, 0)
+ io.putint (rec_pack.packet_number)
+ io.new_line
+ from
+ i := 0
+ until
+ i > 9
+ loop
+ io.putchar (rec_pack.element (i)); i := i + 1
+ end
+ io.new_line
+ end
+
+ end
+
+
+
+The ''execute'' procedure reads a packet of ten characters and prints these characters. Its counterpart in the writing command will produce these ten packets:
+
+ class
+ CLIENT_DATAGRAM_WRITER
+
+ inherit
+
+ POLL_COMMAND
+ redefine
+ active_medium
+ end
+
+ BASIC_ROUTINES
+
+ creation
+ make
+
+ feature
+
+ active_medium: NETWORK_DATAGRAM_SOCKET
+
+ execute is
+ -- Make a packet with characters 'a' to 'k' in successive positions.
+ local
+ sen_pack: DATAGRAM_PACKET
+ ccode: INTEGER
+ do
+ create sen_pack.make (10)
+ from
+ ccode := charcode ('a')
+ until
+ ccode > charcode ('k')
+ loop
+ sen_pack.put_element (charconv (ccode), ccode -- charcode ('a'))
+ ccode := ccode + 1
+ end
+ sen_pack.set_packet_number (1)
+ active_medium.send (sen_pack, Void, 0)
+ end
+
+ end
+
+
+===9.3 The server and the client===
+
+Once the commands have been defined, it suffices for the server and the client to associate instances of these commands with the appropriate.
+
+The abstraction needed for this purpose is provided by class MEDIUM_POLLER. An instance of this class knows about a number of commands, each associated with a certain socket in read, write or special event mode. By applying procedure ''execute'' to such a medium poller, you direct it to monitor these sockets for the corresponding events and to execute the command associated with each event that will be received. Procedure ''execute'' takes two integer arguments: the maximum number of sockets to monitor, and the timeout in milliseconds.
+
+Here is the server built with this mechanism:
+
+ class
+
+ POLLING_SERVER
+
+ creation
+ make
+
+ feature
+
+ make is
+ -- Create read and write commands, attach them to a poller,
+ -- set up the poller for execution.
+ local
+ soc: NETWORK_DATAGRAM_SOCKET
+ poller: MEDIUM_POLLER
+ readcomm: SERVER_DATAGRAM_READER
+ writecomm: SERVER_DATAGRAM_WRITER
+ do
+ create soc.make_server_by_port (6530)
+ create poller.make
+ create readcomm.make (soc); poller.put_read_command (readcomm)
+ create writecomm.make (soc); poller.put_write_command (writecomm)
+ poller.make_read_only; poller.execute (15, 20000)
+ poller.make_write_only; poller.execute (15, 20000)
+ soc.close
+ end
+
+ end
+
+
+
+Procedure ''make'' creates three objects: a socket, which it associates with a specific port; a poller; and a read command (an instance of SERVER_DATAGRAM_READER), which it attaches to the socket. It then enters the read command into the poller, and does the same thing with a write command. It sets up the poller to accept read commands only and then executes the poller; this will enable the server to get the read event triggered by the client's write command (as it appears below in the text of class POLLING_CLIENT). Then the server reverses the poller's set-up to write-only, and calls ''execute'' again.
+
+The procedures ''make_read_only'' and ''make_write_only'' are creation procedures, so that it is possible in a single instruction to create a poller and set it up for read-only or write-only, as in '''create''' ''poller''l. ''make_read_only''. For clarity, however, the above class and the next separate calls to these procedures from the creation of the poller, which uses ''make'' as creation procedure.
+
+The client follows the same scheme, reversing the order of read and write operations:
+
+class
+
+ POLLING_CLIENT
+
+creation
+ make
+
+feature
+
+ make is
+ -- Create read and write commands, attach them to a poller,
+ -- set up the poller for execution.
+ local
+ soc: NETWORK_DATAGRAM_SOCKET
+ poller: MEDIUM_POLLER
+ readcomm: DATAGRAM_READER
+ writecomm: DATAGRAM_WRITER
+ do
+ create soc.make_client_by_port (6530, "serverhost")
+ create poller.make
+ create readcomm.make (soc)
+ poller.put_read_command (readcomm)
+ create writecomm.make (soc)
+ poller.put_write_command (writecomm)
+ poller.make_write_only
+ poller.execute (15, 20000)
+ poller.make_read_only
+ poller.execute (15, 20000)
+ soc.close
+ rescue
+ if soc /= Void and then not soc.is_closed then
+ soc.close
+ end
+ end
+
+end
+
+
+
+===9.4 A less deterministic scheme===
+
+Although the example uses the event-driven mechanisms of EiffelNet, it is still relatively deterministic in that it follows a precise protocol defined by a strict sequence of read and write operations on both sides. This is why every call to ''execute'' is preceded by a call to either ''make_read_only'' or ''make_write_only ''to set up the poller in the appropriate mode.
+
+A less deterministic scheme may often be desirable, where you simply enter a number of commands (read, write, out of bounds processing) into a poller and then wait for arbitrary events to occur and trigger commands. There is no need with this scheme to know in advance the order in which events may occur: a read event will trigger the command entered into the poller through ''put_read_command''; a write event will trigger the command entered through ''put_write_command''.
+
+To achieve this behavior, simply create the poller using ''make'' as creation procedure. This will set up the poller so as to accept all socket events, and enter into event-driven command execution by calling ''execute'' on the poller.
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/index.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/index.wiki
new file mode 100644
index 00000000..ae21c4a1
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/index.wiki
@@ -0,0 +1,17 @@
+[[Property:title|EiffelNet]]
+[[Property:link_title|EiffelNet Tutorial]]
+[[Property:weight|0]]
+* [[What is EiffelNet|Introduction]]
+* [[Clients and servers|Clients and server]]
+* [[An overview of EiffelNet Mechanisms|An overview of EiffelNet mechanisms]]
+* [[The predefined level|The predefined level]]
+* [[Introduction to the examples|Introduction to the examples]]
+* [[Working at predefined level|Working at the predefined level]]
+* [[Obtaining a finer degree of control|Obtaining a finer degree of control]]
+* [[Using datagram sockets|Using datagram sockets]]
+* [[Event-driven command execution|Event-driven command execution]]
+* [[A more complex example|A more complex example]]
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/introduction-examples.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/introduction-examples.wiki
new file mode 100644
index 00000000..49d17501
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/introduction-examples.wiki
@@ -0,0 +1,13 @@
+[[Property:title|Introduction to the examples]]
+[[Property:weight|4]]
+The following sections describe a set of examples showing how to use EiffelNet to build client-server applications.
+
+The examples start with the most simple uses involving high-level classes covering common cases and shielding developers from details of the mechanism. Subsequent examples will reveal some of these details, useful for more advanced or specific applications of EiffelNet.
+
+All the examples discussed here appear in the directory ''$ISE_EIFFEL/examples/net'' of the Eiffel distribution.
+
+{{warning| '''Caution''': On Windows, the `advanced' and the `same_mach' are not working since they are using specific code to Unix Operating systems. }}
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/more-complex-example.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/more-complex-example.wiki
new file mode 100644
index 00000000..cf8b0d02
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/more-complex-example.wiki
@@ -0,0 +1,18 @@
+[[Property:title|A more complex example]]
+[[Property:weight|9]]
+{| border="1"
+|-
+| The example classes discussed in this section appear in the subdirectory ''advanced ''of the example directory
+|}
+
+The last example exercises most of EiffelNet's major facilities. It consists of a server that allows an arbitrary number of clients to connect to it. Each time the user of one of the client systems types a line on the keyboard, the client sends this character to the server, which then broadcasts it to all the clients (including the original sender). This scheme allows several people to talk together, hence the names chosen: the server class is called CHAT , and the client is called JOIN .
+
+The example uses the network mode of communication, based on the [[ref:libraries/net/reference/network_client_chart|NETWORK_CLIENT]] and [[ref:libraries/net/reference/network_server_chart|NETWORK_SERVER ]] classes. It uses automatic polling through [[ref:libraries/net/reference/medium_poller_chart|MEDIUM_POLLER]] as in the previous example; the relevant command is given by class CONNECTION , an heir of [[ref:libraries/net/reference/poll_command_chart|POLL_COMMAND]] . The information exchanged between the server and its clients is described by class MESSAGE , an heir of [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] [ [[ref:libraries/base/reference/string_8_chart|STRING]] ] similar to the earlier examples' OUR_MESSAGE (see [[Working at predefined level|see "Object structures"]] ). Attributes include, the name ''client_name'' of the client that has sent this message, the boolean ''new'' indicating whether the current message is the first from a client that is trying to connect to the server, and ''over ''indicating that the message is the last sent by a client before disconnecting.
+
+The server maintains a list of the currently active connections. In the ''receive'' routine, it checks on the main socket for any client trying to connect. The socket is set to be non-blocking to enable the server to continue checking the already connected clients. If the connection is successful, the server sends to the new client the list of clients already connected and adds the new connection to its list. Then it polls the connections in the list, and processes the messages, if any. If the message is tagged ''new'', the server sends a message to all the clients indicating that a new client has joined the server; if it is tagged ''over'', it sends a message indicating that the client has opted out.
+
+Each client uses the [[ref:libraries/net/reference/medium_poller_chart|MEDIUM_POLLER]] to check any message coming from the server and immediately displays any such message. It also checks a special connection, created with ''io''l''input'' as a medium, to check what the user is typing and then send it to the server. If the user types ''bye'', the client terminates, sending a message tagged ''over ''to the server.
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/obtaining-finer-degree-control.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/obtaining-finer-degree-control.wiki
new file mode 100644
index 00000000..13f79826
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/obtaining-finer-degree-control.wiki
@@ -0,0 +1,246 @@
+[[Property:title|Obtaining a finer degree of control]]
+[[Property:link_title|]]
+[[Property:weight|6]]
+Let us now take a more internal look at the workings of EiffelNet. The two examples that follow have the same behavior as the preceding one; since their text is less simple, they are only interesting as an illustration of the lower-level facilities that you may want to use in specific cases. If you are already familiar with socket programming, they will also give you a more precise idea of how EiffelNet encapsulates the basic socket mechanisms.
+
+As before, we have a client and a server class, still called OUR_CLIENT and OUR_SERVER, which are part of two different systems and will run concurrently. The communication uses streams rather than datagrams; the datagram form of communication will be examined in section [[Using datagram sockets|using datagram sockets]] .
+
+===A client and a server on the same machine===
+
+{{note|The example classes discussed in this section appear in the subdirectory ''same_mach ''of the example directory }}
+
+First, let us assume that the client and server run on the same machine, so that we will use the UNIX_ versions of the classes (the next example will be multi-machine). The communication protocol is also the same as before: the client sends a list of strings, the server returns it extended.
+
+Here we will create and manipulate sockets directly. For that reason, both classes inherit from the EiffelNet class SOCKET_RESOURCES which introduces a number of constants and other useful socket-related features.
+
+The two sockets must be able to refer to a common address. For a communication within a single machine, as noted, this address is a path name, again ''/tmp/here'' for this example. The address will be an argument of the creation procedure used to obtain a socket ''soc1 ''on either side:
+
+ create soc1.make_client ("/tmp/here")
+ create soc1.make_server ("/tmp/here")
+
+The ''make_'' procedures take care of all the hassles of establishing a socket for a client or a server: creating an address object, setting it to the given path name, binding the socket to the address, and in the client case establishing the connection. For finer control, these procedures are still available: you can create a bare socket by using the basic creation procedure ''make'' (rather than the more sophisticated ''make_client ''and ''make_server''), then create a separate address object, associate the two, and call the ''bind'' and ''connect'' procedures.
+
+Because communication is bidirectional, the distinction between client and server is not between who sends and who receives, although here the server only sends messages of acknowledgment. The client is the party that initiates the communication; the server is the party which stands ready to accept the communication. This difference justifies the presence of two creation procedures ''make_client'' and ''make_server ''as illustrated above. To initiate the communication, the client will execute:
+ soc1.connect
+
+To make itself ready for the communication, the server will execute:
+ soc1.listen (n)
+
+where ''n'' is a positive integer indicating the maximum number of client connection attempts that may be queued. The value 5, used in the example, is typical for ''n''.
+
+When you use the _SERVER classes of the predefined level, as in the earlier example, 5 is indeed the default; you can change the value to a positive integer ''n'' through the call ''set_queued ''( ''n'').
+
+Whenever the server needs to exchange objects with one of the clients, it obtains access to the socket through the following sequence:
+
+ soc1.accept
+ soc2 := soc1.accepted
+ ... Storage and retrieval operations using soc2 (not soc1) ...
+ soc2.close
+
+
+
+Procedure ''accept ''ensures synchronization with the client. When communication is established, ''accept'' creates a new socket which will be accessible through attribute ''accepted'', whose value is here assigned to the local entity ''soc2''. To receive objects, the server will use operations of the form introduced earlier ( [[An overview of EiffelNet Mechanisms|An overview of EiffelNet, sending and receiving object structures]] ):
+ struct ?= soc2.retrieved
+
+applying to ''soc2'', not ''soc1''; this makes ''soc1 ''available to accept connections with other clients, a fundamental feature of client-server mechanisms.
+
+The operation ''soc2''. ''close'' which terminates the above sequence closes the new socket. In principle this is not necessary, since garbage collection should eventually reclaim the socket object, and the ''dispose'' procedure of the corresponding socket class includes a call to ''close''. But the risk exists that you run out of sockets before garbage collection reclaims all currently opened sockets, so it is preferable to include the ''close'' calls explicitly.
+
+At the end of the processing it is necessary to close the original socket ''soc1'' but also to unlink it. The feature ''cleanup'' from class ''SOCKET'' takes care of both closing and unlinking.
+
+Here is the server class based on these principles. The actual processing has been put aside in a procedure ''process''.
+
+ class
+ OUR_SERVER
+ inherit
+
+ SOCKET_RESOURCES
+
+ STORABLE
+
+ creation
+ make
+
+ feature
+
+ soc1, soc2: UNIX_STREAM_SOCKET
+
+ make is
+ -- Accept communication with client and exchange messages
+ local
+ count: INTEGER
+ do
+ create soc1.make_server ("/tmp/here")
+ from
+ soc1listen (5)
+ count := 0
+ until
+ count = 3
+ loop
+ process -- See below
+ count := count + 1
+ end
+ soc1.cleanup
+ rescue
+ soc1.cleanup
+ end
+
+ process is
+ -- Receive a message, extend it, and send it back
+ local
+ our_new_list: OUR_MESSAGE
+ do
+ soc1.accept
+ soc2 ?= soc1.accepted
+ our_new_list ?= retrieved (soc2)
+ from
+ our_new_list.start
+ until
+ our_new_list.after
+ loop
+ io.putstring (our_new_list.item)
+ io.new_line
+ our_new_list.forth
+ end
+ our_new_list.extend ("%N I'm back.%N")
+ our_new_list.general_store (soc2)
+ soc2.close
+ end
+
+ end
+
+
+Note that at the end the server should not only closes the original socket ''soc1 ''but also unlinks it. It is recommended to have a Rescue clause which, as here, ensures that the socket will be closed and unlinked if the system terminates abnormally before its term.
+Here now is the client class:
+
+ class
+ OUR_CLIENT
+
+ inherit
+
+ SOCKET_RESOURCES
+
+ creation
+ make
+
+ feature
+
+ soc1: UNIX_STREAM_SOCKET
+
+ make is
+ -- Establish communication with server, and exchange messages
+ do
+ create soc1.make_client ("/tmp/here")
+ soc1.connect
+ process -- See below
+ soc1.cleanup
+ rescue
+ soc1.cleanup
+ end
+
+ process is
+ -- Build a message to server, receive answer, build
+ -- modified message from that answer, and print it.
+ local
+ our_list, our_new_list: OUR_MESSAGE
+ do
+ create our_list.make
+ our_list.extend("This"); our_list.extend (" is")
+ our_list.extend (" our"); our_list.extend (" test")
+ our_list.general_store (soc1)
+ our_new_list ?= soc1.retrieved
+ from
+ our_new_list.start
+ until
+ our_new_list.after
+ loop
+ io.putstring (our_new_list.item)
+ our_new_list.forth
+ end
+ io.new_line
+ end
+
+ end
+
+
+===Communication between two different machines===
+{| border="1"
+|-
+| The example classes discussed in this section appear in the subdirectory ''two_mach ''of the example directory
+|}
+
+Let us now assume that the client and the server will run on two separate machines. Instead of UNIX_ sockets, we must now use sockets of type NETWORK_STREAM_SOCKET.
+
+The available creation procedures are slightly different. The server will be set up so as to listen to clients from any machine; it designates a '''port''', identified by an integer, on which it will listen. The socket creation on the server side is then
+create soc1.make_server_port (2000)
+For the client, the creation will specify two elements of information: the port number and the server. The server argument, a string, identifies the machine used as a server; it may be the host name of that machine, for example ''"serverhost" ''as used in the example; or it can be the machine's internet address, made of a sequence of numbers separated by periods, such as ''"127.0.0.1"''.
+
+The rest of the classes is as before.
+
+ class
+ OUR_SERVER
+
+ inherit
+
+ SOCKET_RESOURCES
+
+ STORABLE
+
+ creation
+ make
+
+ feature
+
+ soc1, soc2: NETWORK_STREAM_SOCKET
+
+ make is
+ -- Accept communication with client and exchange messages.
+ do
+ create soc1.make_server_by_port (2000)
+ ... The rest as before...
+ end
+
+ process is
+ ... As before ...
+ end
+
+ end
+
+ class
+ OUR_CLIENT
+
+ inherit
+
+ SOCKET_RESOURCES
+
+ creation
+ make
+
+ feature
+
+ soc1: NETWORK_STREAM_SOCKET
+
+ make is
+ do
+ create soc1.make_client_by_port (2000, "serverhost")
+ ... The rest as before ...
+ end
+
+ process is
+ ... As before ...
+ end
+
+ end
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki
new file mode 100644
index 00000000..0cbb16bc
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki
@@ -0,0 +1,112 @@
+[[Property:title|An overview of EiffelNet Mechanisms]]
+[[Property:weight|2]]
+To enable clients and servers to exchange objects, you will have to ensure that they can refer to a common '''address'''. At the predefined level this is really the only notion that you need to know, although it is useful to get the bigger picture, in particular the concept of '''socket '''(which enables systems to set up communication channels), the various forms of communication (single-machine versus multi-machine, stream versus datagram), the kinds of object structure that may be exchanged, the notion of packet, and how to associate commands with communication events. The following paragraphs review these ideas and the corresponding EiffelNet abstractions.
+
+===Establishing a common address===
+
+When two systems need to communicate through sockets, they must establish a binding through some common point of reference, called an '''address'''. Predictably, the notion of address is one of the important internal abstractions of EiffelNet, although in most cases developers of applications using EiffelNet do not need to manipulate address objects directly.
+
+EiffelNet supports two modes of communication: single-machine and multi-machine. In the single-machine case, the two communicating systems are known to be running on the same machine. In the multi-machine case, also known as the '''network''' case, they may be running on different machines, and communication occurs through a network. These two modes clearly require a different binding mechanism.
+
+When a client and a server reside on the same machine, they both have access to that machine's file system. This provides a straightforward binding mechanism: the common address will simply be a "path name", the Unix terminology for the full name of a file in a hierarchically organized file system. In the examples below this file will be ''/tmp/here ''(file ''here'' in the ''/tmp'' directory, conventionally used for temporary files). This file must not exist prior to the communication; it will be created by the socket mechanisms and then removed.
+
+For the network style of communication, this simple device of using a path name is no longer applicable. To define a common address, we may use two elements of information: the name of a machine, and the indication of a '''port''' on that machine. More precisely:
+* The port will be identified by an integer. In the examples below port ''2000'' will be used.
+* The machine may be identified in either of two ways: its '''host name''' (the name assigned to the machine when the operating system was first installed on it) or its '''Internet address''', a sequence of numbers separated by periods, such as ''127.0.0.1''. EiffelNet routines that need an argument identifying a machine will indifferently take a host name or an Internet address, passed in either case as a string. In the examples below the identification will be a host name, given as the string ''"serverhost"''.
+
+In network-style client-server communication, the mechanism will be dissymmetric, reflecting the possibility (noted earlier) of a single server catering to many clients. The clients will state both the machine identification of their intended server and the port on which they will talk to that server. The server, however, will only specify the port; this means that it makes itself available to any client that cares to talk to it on that port. This provides some of the essential flexibility of client-server communication, where only one of the partners needs to state beforehand whom it wants to talk to.
+
+===Sockets and communication modes===
+
+A software system will exchange objects with another by sending them to a socket. Although if you stay at the predefined level you will not need to manipulate sockets explicitly, it is useful to understand this concept and know about the corresponding EiffelNet classes.
+
+You may think of a socket as a communication port; by attaching sockets together you enable communication between the corresponding systems, for example a client and a server:
+ [[Image:fig-2]]
+EiffelNet has been designed so that sockets look very much like files. You send objects to a socket in the same way that you write objects onto a file, and receive objects from a socket in the same way that you read objects from a file. This fundamental commonality is reflected in the inheritance hierarchy of the corresponding classes:
+ [[Image:fig-3]]
+Note that the hierarchy as shown is not complete; in particular the full structure uses classes STREAM (of which the STREAM_ classes are heirs) and DATAGRAM for multiple inheritance ''. ''Only the classes below the dotted line are part of EiffelNet; the others are part of EiffelBase, the fundamental data structure and algorithm library of ISE Eiffel [2].
+
+The most important property of this inheritance hierarchy is that it shows how sockets fit within the overall structure. Thanks to the common ancestor IO_MEDIUM, socket classes have most of their features in common with files.
+
+In normal usage, the only socket classes that you will need are four classes appearing at the bottom of the above figure. They correspond to two separate distinctions: single-machine versus multi-machine, and reliable versus unreliable.
+
+On the first distinction:
+* If the communicating systems run on the same machine, you may use one of the UNIX_ classes.
+* For systems that run on different machines, you must use one of the NETWORK_ classes. This will also work if the systems are on the same machine, but less efficiently since communication may go through the network.
+
+The use of the word UNIX_ does not mean that the machine must be running the Unix operating system; rather, it denotes a certain style of client-server communication, the Unix style. (This is comparable to the use of the name UNIX_FILE in EiffelBase, for a class describing files that behave in the Unix style even though they may be implemented on non-Unix machines.)
+
+The second distinction reflects two modes of socket communication: stream communication and datagram communication. Both of these modes support two-way communication between systems, but with different properties:
+* A stream socket, as provided by the STREAM_ classes, provides sequenced communication without any loss or duplication of data. Stream communication is normally synchronous: the sending system waits until it has established a connection to the receiving system and transmitted the data.
+* A datagram socket, as provided by the DATAGRAM_ classes, is asynchronous: the sending system emits its data and does not wait for an acknowledgment. Because the sender is not blocked, this mode is more efficient, but it does not guarantee sequencing, reliability or non-duplication.
+
+===Sending and receiving simple values===
+
+IO_MEDIUM has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of FILE in reference [2]). So you can use sockets to send and receive characters, integers, real numbers in simple or double precision and strings. For example, if the type of
+
+`my_socket' is one of the socket classes shown on the preceding figures, any of the above calls will be valid:
+
+ my_socket.putstring ("Some text") my_socket.readint; my_last_integer := my_socketllastint
+
+
+Since sockets are bidirectional, these instructions may all appear as part of the same class provided you make sure to guarantee proper synchronization between senders and receivers. You may also prefer to specialize certain sockets for sending and others for receiving.
+
+===Sending and receiving object structures===
+
+In many cases, what you will want to send and receive is not just simple values but non-basic objects (instances of arbitrary classes, having as many fields as needed) and, more generally, entire object structures.
+
+The basic mechanism enabling a system to send objects through EiffelNet is also the basic mechanism for storing objects into a file: class STORABLE from EiffelBase.
+
+As documented in [2], STORABLE provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms
+
+ struct1.basic_store (iom1)
+ struct1.general_store (iom1)
+ struct1.independent_store (iom1)
+
+
+Assuming that the type of ''iom1 ''is IO_MEDIUM or a conforming type such as [[ref:libraries/base/reference/file_chart|FILE]] or one of the _SOCKET classes, and that the type of ''struct1'' conforms to STORABLE ''.''Note that reference [2] in its original version does not include ''independent_store'', and requires ''iom'' to be of type FILE rather than the more general IO_MEDIUM. The current version of EiffelBase, however, supports the more general properties described here.
+
+All three storage procedures have the effect of sending to ''iom1 ''(whether a file, a socket or some other IO-medium) a copy of the entire object structure starting at ''struc1''. Together with the retrieval routines seen below, they apply the principle of reference completeness stated in [1] and [2]:
+{| border="1"
+|-
+| Whenever a routine of class STORABLE stores an object into an external file, it stores with it the dependents of that object.
+| Whenever one of the associated retrieval routines retrieves a previously stored object, it also retrieves all its dependents.
+|}
+
+For EiffelNet, of course, "storing" and "retrieving" mean sending and receiving. The rest of this section, which applies to sockets as well as to files, will continue to use the original terminology of storage and retrieval.
+
+The three storage procedures differ in their degree of generality:
+* ''basic_store'' will only work if the sending and retrieving are performed by instances of the same system (the same executable module).
+* ''general_store'' will work if the sender and retriever are different systems (using the same classes for the objects that they exchange), but these systems must run on machines of the same architecture, or at least of architectures that use the same data representation.
+* ''independent_store'' will work in the most general case, with the sender and receiver possibly running on platforms using different data representations.
+
+The penalty for using more general representations is that the data representation (as stored into the file or sent to the socket) will have to include more information. So ''basic_store ''uses the most compact representation, and ''independent_store'' the most verbose.
+
+The scheme for accessing an object structure produced by one of these three procedures is the following, used in a descendant of class STORABLE:
+ struct2 ?= retrieved (iom2)
+
+Here ''iom2'' must be of a type conforming to IO_MEDIUM. The assignment attempt ?= checks that the root object of the structure produced by the corresponding call to one of the ''_store'' procedures is of a type that conforms to the type of ''struct2''; if not, the assignment will assign to ''struct2'' a void reference.
+
+Although there are three separate storage procedures, there is only one retrieval routine, ''retrieved''; the algorithm for ''retrieved ''is able to figure out, from the format of the retrieved objects, whether they were produced in the basic, general or independent mode.
+
+===Packets===
+
+The classes PACKET and DATAGRAM_PACKET are used to represent packets of data that can be sent to sockets.
+
+Their main use is for a system that relies on datagram communication. As noted above, this mode does not guarantee sequencing, making each system responsible for checking that packets arrive in the proper order. This is possible through feature ''number ''of class DATAGRAM_PACKET, which gives the number of the current packet.
+
+===Associating commands with events===
+
+EiffelNet supports a highly asynchronous (and hence efficient) mode of operation by offering mechanisms through which you can specify that a certain action must be executed whenever a certain medium becomes available for reading, writing or handling of special cases (out of bounds). This facility is provided by a set of related classes:
+* The actions are represented by class POLL_COMMAND, an heir of the EiffelBase class COMMAND with, in particular, the procedure ''execute''.
+* Using MEDIUM_POLLER, you can specify that a certain command (an instance of POLL_COMMAND) must be executed whenever a certain medium becomes available for the appropriate operation (read, write, handling of out-of-bounds cases).
+* Using POLL_MASK, you can set a mask to select the sockets or files on which your instance of MEDIUM_POLLER is working.
+
+
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/using-datagram-sockets.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/using-datagram-sockets.wiki
new file mode 100644
index 00000000..957a870c
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/using-datagram-sockets.wiki
@@ -0,0 +1,16 @@
+[[Property:title|Using datagram sockets]]
+[[Property:weight|7]]
+{| border="1"
+|-
+| The example classes discussed in this section appear in the subdirectory ''datagram ''of the example directory
+|}
+
+Using datagram sockets implies a few differences from the preceding schemes. You create a [[ref:libraries/net/reference/network_datagram_socket_chart|NETWORK_DATAGRAM_SOCKET]] or a UNIX_DATAGRAM_SOCKET as before. You do not need to call ''listen'', ''accept'' or ''connect''. Once you have created your sockets using the ''make_client ''or ''make_server'' creation procedure, you can use the ''send ''and ''received ''routines, specifying the socket to which you want to send, or from which you want to receive.
+
+The command ''send ''takes an argument of type [[ref:libraries/net/reference/datagram_packet_chart|DATAGRAM_PACKET]] , and the query ''received ''returns a result of this type. [[ref:libraries/net/reference/datagram_packet_chart|DATAGRAM_PACKET]] is an heir of class [[ref:libraries/net/reference/packet_chart|PACKET]] , itself an heir of [[ref:libraries/base/reference/array_chart|ARRAY]] [ [[ref:libraries/base/reference/character_8_chart|CHARACTER]] ]. Class [[ref:libraries/net/reference/datagram_packet_chart|DATAGRAM_PACKET]] makes it possible, through the query ''number'' and the associated command ''set_number'', to associate a packet number with each packet. This compensates for lack of guaranteed sequencing of datagram sockets: the sender can number packets through ''set_number'', and the receiver can check that all packets have been received through ''number'', asking the sender to re-emit missing objects.
+
+The text of this example is similar to what appears below (in a more general setting involving event-driven computation) for the next example.
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki
new file mode 100644
index 00000000..d529abfb
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki
@@ -0,0 +1,32 @@
+[[Property:title|What is EiffelNet]]
+[[Property:weight|0]]
+===What is EiffelNet?===
+
+The client-server model of computing is quickly gaining ground as a way of optimizing network resources and of building sophisticated and flexible transactional applications.
+
+The object-oriented method of software development, as embodied in Eiffel, potentially provides ideal support for developing client-server applications. The EiffelNet library described in this report makes this potential a reality by addressing one the crucial needs of client-server development: how to exchange objects between software systems. Systems using EiffelNet can exchange object structures with other systems running on the same machine or on different machines; in the case of different machines, the hardware architectures need not be the same. Objects are transmitted using sockets.
+
+Writing client-server applications, especially their communication aspects, is an arduous task; developers must master many tricky details of socket programming and other low-level mechanisms. EiffelNet hides this complexity by providing ready-made classes addressing the most common cases, so that developers only have to describe what is specific to their application, letting EiffelNet handle the whole process of communication and synchronization between clients and servers. This part of EiffelNet is known as the ''predefined level'' and for many uses this is the only one that you will need to learn about. For developments requiring a finer degree of control, all the major mechanisms of socket programming are still accessible in a convenient form through more specialized classes.
+
+In offering these varying levels of abstraction and control, EiffelNet follows the principles set by other libraries of the Eiffel environment (see for example the discussion of EiffelLex in reference [ [[Bibliography|2]] ]). Some users require a mechanism that will be very easy to learn and will hide all the details in common cases; other users (or the same at later stages of their work) need to access the whole array of facilities available at the level of the underlying hardware or software. The various components of the library should address all these needs.
+
+This manual describes how to use EiffelNet at its various levels of abstraction.
+
+===Background and prerequisites===
+
+EiffelNet is a component of the Eiffel development environment.
+
+This manual assumes the following prerequisites:
+* Familiarity with the basic Eiffel concepts: classes, inheritance, features, assertions, exception handling (see reference [ [[Bibliography|1]] ]).
+* Experience of writing software with Eiffel.
+* Basic knowledge of the EiffelBase libraries, as described in reference [ [[Bibliography|2]] ].
+
+Familiarity with the basic concepts of client-server computing will also be helpful (see for example reference [ [[Bibliography|3]] ]; if you are new to this area, however, you will still be able to use EiffelNet, as this manual defines all the needed concepts.
+
+===Organization of this manual===
+
+[[Clients and servers|Section 2]] discusses the notion of client and server. [[An overview of EiffelNet Mechanisms|Section 3]] presents an overview of EiffelNet's facilities. [[The predefined level|Section 4]] describes the predefined level: a set of high-level classes that provide a complete framework, covering the most common uses and limiting the developer's work to the strict minimum. Sections [[Introduction to the examples|5]] to [[A more complex example|10]] describe the facilities in detail through a set of increasingly ambitious examples (whose texts may all be found in the directory '''$ISE_EIFFEL/examples/net''' of the Eiffel distribution). [[Clients and servers|Section 11]] is a short bibliography.
+
+
+
+
diff --git a/documentation/current/solutions/networking/eiffelnet/index.wiki b/documentation/current/solutions/networking/eiffelnet/index.wiki
new file mode 100644
index 00000000..16624658
--- /dev/null
+++ b/documentation/current/solutions/networking/eiffelnet/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelNet Library]]
+[[Property:link_title|EiffelNet]]
+[[Property:weight|4]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[EiffelNet|Content]]
+* [[EiffelNet Samples|Samples]]
+* [[ref:libraries/net/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki b/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki
new file mode 100644
index 00000000..e66779bd
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki
@@ -0,0 +1,530 @@
+[[Property:title|CECIL interface overview]]
+[[Property:weight|3]]
+==Eiffel basic types==
+The EIFFEL include files define types for every EIFFEL types:
+* An Eiffel INTEGER is an ''EIF_INTEGER'',
+* An Eiffel CHARACTER is an ''EIF_CHARACTER'',
+* An Eiffel REAL is an ''EIF_REAL'',
+* An Eiffel DOUBLE is an ''EIF_DOUBLE'',
+* Eiffel references (any Eiffel objects that are not from a basic type) are ''EIF_REFERENCE'' (not protected, and can be moved),
+* An Eiffel POINTER is an ''EIF_POINTER,''
+* An Eiffel BOOLEAN is an ''EIF_BOOLEAN'',
+* A Protected Eiffel object is an ''EIF_OBJECT'' (does not move, and should be accessed through eif_access. ).
+
+Generally, you should use these types when implementing external C functions bound to be used from Eiffel or when you want to manipulate Eiffel objects from the C side. EIF_REFERENCE, EIF_OBJECT, EIF_POINTER all correspond in C to a (char *), but their semantic remains different in Eiffel.
+
+{{note|'''Note:''' In the following code samples, the class OBJECT is a placeholder for one of your type that you wish to use via CECIL.}}
+
+{{sample| '''Sample''': Calling C external `foo' from Eiffel, which takes a pointer and an eiffel object of type OBJECT as arguments and returns an INTEGER. }}
+
+
+ c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
+ external
+ "C | %"your_file.h%""
+ alias
+ "foo"
+ end
+
+
+
+In the C side, The C function `foo' is defined as follow:
+
+
+EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj)
+ {
+ /* some code */
+ }
+
+
+
In some cases, you may not be able to change the signature of a C function you want to use. In this case, you must describe its actual signature in the Eiffel code. On the C side, foo is already defined as below:
+
+int foo (void *arg1, char c, FILE *file)
+ {
+ /* some code */
+ }
+
+
To match the signature, you must declare it in Eiffel as:
+
+ c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER is
+ external
+ "C (void *, char, FILE *) : int | %""your_file.h%""
+ alias
+ "foo"
+ end
+
+
+Not doing this would generally produce warnings during the C compilation, and it could crash with some C compilers.
+
+To perform the conversion, here is the actual Eiffel types mapping to C types:
+ POINTER is compatible with any C pointer ( ''char *'').
+INTEGER is a long.
+CHARACTER is an ''unsigned char. ''
+DOUBLE is a ''double''.
+REAL is a ''float''.
+BOOLEAN is an ''unsigned char (EIF_TRUE = '\01', EIF_FALSE = '\0')'' .
These are the current correspondences but they may change. The definition of each Eiffel type is located in $ISE_EIFFEL/bench/spec/$PLATFORM/include/eif_portable. h.
+===More about EIF_OBJECT, EIF_REFERENCE, and basic expanded types===
+It is sometimes difficult to tell the difference between an ''EIF_OBJECT'' and an ''EIF_REFERENCE''.
+An ''EIF_REFERENCE'' is an Eiffel reference. It corresponds to an Eiffel object in the Eiffel side. eif_attribute, eif_reference_function, eif_string, eif_wean all return ''EIF_REFERENCEs''. An ''EIF_REFERENCE'' can be used "as is" by the Eiffel run-time. eif_attribute, eif_xx_function take ''EIF_REFERENCEs'' as arguments, never ''EIF_OBJECTs''. The return value of a C external is to be an ''EIF_REFERENCE'', if it is not a basic expanded type. To protect an ''EIF_REFERENCE'', use eif_protect.
+
+An ''EIF_OBJECT'' is a safe and static indirection to an Eiffel reference. As the GC may move an Eiffel reference, this indirection is updated at every collection so that you do not need to know whether an Eiffel reference has moved or not. You must pass through this indirection to access the Eiffel reference (see eif_access). Not doing so is completely unsafe since an Eiffel reference may be obsolete after a collection. eif_create, eif_adopt, and eif_protect returns an ''EIF_OBJECT''. The argument of a C external (on the C side) , which is not a basic expanded type, is also an ''EIF_OBJECT''. The Eiffel run-time temporarily protects the Eiffel objects that are passed to a C external , that is why the signature of a C external has no ''EIF_REFERENCE'' in it, but ''EIF_OBJECT'' instead. After the C external call, the run-time unprotects the Eiffel object. If you intend to use in the C side an ''EIF_OBJECT'' given by a C external afterwards, you must protect it with eif_adopt. To unprotect an ''EIF_OBJECT'' , which is not a C external argument, use eif_wean.
+
+The basic expanded types are INTEGER, INTEGER_64, INTEGER_16, INTEGER_8, REAL, DOUBLE, CHARACTER, BOOLEAN, POINTER. They are passed to C externals by values. There is no need to protect instances of these types. When the POINTER is a pointer to an Eiffel object (ex: $my_object), then the direct Eiffel reference is passed to C, with no protection and this reference may move. Use eif_protect to manually protect it. To unprotect it, call eif_wean.
+
+==Protecting the Eiffel objects==
+You can use the CECIL functions directly from a C program as well as from a C external called from Eiffel. If you encounter problems, they may be related to the handling of garbage collection. The programmer who uses CECIL has to be aware that all Eiffel objects can be moved or collected asynchronously by the Garbage Collector (GC).
+The cecil library provides the user with numerous macros and functions, which relieve the programmer from these kinds of low-level considerations (most of them are declared in $ISE_EIFFEL/bench/spec/$PLATFORM/include/eif_cecil. h).
+
+===Eiffel objects passed in a C external===
+An Eiffel object which is passed as an argument of a C external is automatically protected: the value passed to C is not a direct Eiffel reference. In fact, it is a temporary indirection pointer, which is only valid until the C external returned. This indirection pointer is to be used to access the direct reference of the Eiffel object with ''eif_access (eiffel_object)'' where ''eiffel_object'' is the argument (an ''EIF_OBJECT)'' of the C external which corresponds to the Eiffel object. Only Eiffel objects passed to C is automatically protected. This excludes basic expanded types, since they cannot be moved.
+===Accessing the direct reference to an Eiffel object: eif_access===
+'''# include "eif_hector. h"'''
+'''EIF_REFERENCE eif_access (EIF_OBJECT object) /* Macro */'''
+
+The GC moves the objects every time it runs a collection cycle. A collection cycle can only occur during an Eiffel call. This includes calls to Eiffel routines and calls to CECIL functions (other than ''eif_access''). Thus, it may be unsafe to access a "raw" reference to an Eiffel object, (of type ''EIF_REFERENCE'') "as is", since the latter can be obsolete after each collection. To avoid this, you must access a direct reference through a "protection", which is a safe, non-moving pointer (of type ''EIF_OBJECT''). Call the macro ''eif_access'' as follows: ''eif_access (protection)'' , where ''protection'' is either a value returned by eif_create, eif_adopt or eif_protect, or an Eiffel object which is an argument of a C external.
+
+Use ''eif_access'' to pass an Eiffel object to an Eiffel routine or to return the value of a C external. It is also unsafe to pass a direct Eiffel reference ( ''EIF_REFERENCE'') to a C function which is not an Eiffel routine. Pass a protected indirection instead ( ''EIF_OBJECT''). However, if you still intend to pass a direct reference, be very careful and make sure that you do not perform any Eiffel call after passing the reference to the C function and before reading it.
+
+'''For example, in the following external:'''
+
+
+ c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
+ external
+ "C | %""your_file.h%""
+ alias
+ "foo"
+ end
+
+
+
+the Eiffel run-time will protect obj, which can asynchronously move, and give a static and safe indirection to C.
+
+'''Here is an example of how accessing obj: OBJECT:'''
+
+EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj);
+{
+ /* Print the Eiffel object `obj', with the feature `print'
+ * from ANY. (do not forget to put `visible' the class
+ * ANY in the project configuration file.
+ */
+
+ EIF_PROCEDURE ep;
+ EIF_TYPE_ID tid;
+ tid = eif_type_id ("ANY");
+ ep = eif_procedure ("print", tid);
+ (ep) (eif_access(obj),eif_access(obj));
+}
+
+
+'''Important rules when using eif_access:'''
+
+{{note| '''Note''': The first argument of ''(ep)'' is the target of the function (the eiffel object to which you want to apply the Eiffel feature ''(ep)'') and the second argument corresponds to the first argument of ` ''print'''. Any Eiffel object could have been the 1st argument of ''(ep)'' since all of them inherit ''ANY''. }}
+
+
+* '''Never pre compute the value returned by eif_access. '''
+'''Example:'''
+Example:
+Instead of the code above, it would have been dangerous to write:
+
+EIF_REFERENCE e_ref = eif_access (obj);
+...
+(ep) (e_ref, e_ref);
+
+
+
+because e_ref is the direct reference to the Eiffel object when calling ''eif_access(). '' There is not guarantee that it will still be valid when the call to ''(ep)'' is done: meanwhile, e_ref may have been moved by the GC.
+
+
+* '''Never use eif_access with encapsulated eiffel calls:'''
+(eif_access in not an eiffel call)
+'''Example:'''
+
+
+(ep) (eif_access (a), eif_string ("Hello world"));
+ /* eif_string is a macro returning a direct reference to an Eiffel string,
+ * which corresponds to the C string passed as its argument.
+ */
+
+Nothing guarantees that the direct reference returned by `eif_access (a)' will be still valid when executing (ep): it may be obsolete after the Eiffel call eif_string ("Hello world"), which may invoke a collection cycle.
+
+The correct code is
+
+
+EIF_REFERENCE my_string;
+/* some code */
+my_string = eif_string ("Hello world");
+(ep) (eif_access (a), my_string);
+
+
+
+In this case, you do not need to protect `my_string' since the GC is not likely to be triggered after the call to ''eif_string'' and before `my_string' is given as argument in ''(ep). '' A collection is triggered only during Eiffel calls. If an Eiffel call had been performed, you would have had to use ''eif_protect'' (see paragraph 3. 2):
+
+
+EIF_REFERENCE my_string;
+EIF_OBJECT i_my_string;
+/* some code */
+my_string = eif_string ("Hello world");
+i_my_string = eif_protect (my_string); /* Protect `my_string'. */
+/* Some eiffel calls */
+(ep) (eif_access (a), eif_access (i_my_string));
+eif_wean (i_my_string); /* Release protection. */
+
+
+
+
+===Keeping a reference from C after an external call: eif_adopt===
+'''# include "eif_hector. h"'''
+EIF_OBJECT eif_adopt (EIF_OBJECT object)
+
+When passing Eiffel objects to C, you may need to keep a reference to them after the C external is called. Since the Eiffel run-time automatically will unprotect the Eiffel object references passed to a C external after execution, if one of the Eiffel objects is not referenced any longer from Eiffel, then the garbage collector will collect it because it is not aware that you may still need to reference this object from the C side.
+
+Called within a C external, the function ''eif_adopt'' creates a user protection for the Eiffel object ''object'' passed to C ( ''object'' is a C external argument). This way, the GC cannot collect the Eiffel reference returned by ''eif_access(object)'' when the C external returned. It tells the GC to keep artificially a reference to this Eiffel reference from C. It returns the new indirection pointer (say ''returned_value'') that must be used afterwards to access this direct Eiffel reference with ''eif_access (return_value)''. It is important to note that ''eif_adopt'' already takes an indirection pointer as unique argument. This is a temporary protection pointer: you can access the direct Eiffel reference with ''eif_access (object)'' only within the code of the C external. When the C external returns, ''eif_access (object)'' is NULL but ''eif_access (returned_value)'' remains valid until you release it with eif_wean.
+
+'''Example:'''
+
+In Eiffel:
+
+
+ c_foo (ptr: POINTER; obj: OBJECT): INTEGER is
+ external
+ "C | %"your_file.h%""
+ alias
+ "foo"
+ end
+ c_display_and_release_obj is
+ external
+ "C | %"your_file.h%""
+ alias
+ "display_and_release_obj"
+ end
+
+
+
+On the C side:
+
+
+EIF_OBJECT my_obj; /* Protection of the object of type OBJECT. */
+EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj)
+{
+ my_obj = eif_adopt (obj); /* Keeping a reference on it for
+ * for later use.
+ */
+ /* some code */
+}
+void display_and_release_obj (void)
+{
+ /* Display global object. */
+ EIF_PROCEDURE ep;
+ EIF_TYPE_ID tid;
+ tid = eif_type_id ("OBJECT");
+ ep = eif_procedure ("print", tid);
+ (ep) (eif_access(my_obj),eif_access(my_obj)); /* Print global object.*/
+ eif_wean (my_obj); /* Remove the protection on global object.*/
+}
+
+
+
+Between the call of ` ''c_foo''' and ` ''c_display_obj''', the global object ''(eif_access (my_obj))'' may not be referenced from Eiffel any longer. To prevent the GC from collecting it before the call to ` ''c_display_and_release_obj''', you must protect it with ` ''eif_adopt''' in the C function ` ''foo'. ''
+
+==Other CECIL functions:==
+
+===Creating Eiffel objects from C: eif_create===
+''' # include "eif_cecil. h"'''
+EIF_OBJECT eif_create (EIF_TYPE_ID type_id)
+
+All CECIL calls are not completed using C externals. It is possible to create and manipulate Eiffel objects from a C program and still reap benefits from the garbage collector and design by contract methodology provided by Eiffel (see also [[Compiling an Eiffel system for CECIL|How to run a CECIL program]] ). This function does not call any creation procedure.
+
+The CECIL function ''eif_create'' takes a type identifier ''type_id'' as argument (generally returned by eif_type_id). It returns a static indirection pointer which is to be used afterwards to access the newly created Eiffel object with ''eif_access (returned_value)'' where ''returned_value'' is the value returned by ''eif_create'' . This means that when creating an eiffel object from C, the eiffel object is automatically protected: there is no need to call eif_adopt or eif_protect on it. This function does not call any creation procedure. To do so, you need to explicitly call it with eif_procedure. The garbage collector will not collect the newly created object until you call eif_wean on it.
+
+'''Example:'''
+
+Creating an object of type "OBJECT":
+
+
+#include eif_setup.h" /* for EIF_INITIALIZE and EIF_DISPOSE_ALL */
+#include "eif_eiffel.h" /* for other exported routines from the Eiffel run-time */
+main (int argc,char **argv,char **envp)
+{
+ EIF_TYPE_ID tid;
+ EIF_OBJECT my_obj;
+ EIF_INITIALIZE(failure) /* Initialization of Eiffel run-time.
+ * This is to be done before any CECIL call.
+ */
+
+ tid = eif_type_id ("OBJECT");
+ if (tid == EIF_NO_TYPE)
+ eif_panic ("No type id.");
+ my_obj = eif_create (tid); /* Create eiffel object, returns an indirection. */
+ /* some code */
+ eif_wean (my_obj); /* We do not need it any more. */
+ EIF_DISPOSE_ALL /* Reclaim memory allocated by Eiffel run-time. */
+}
+
+
+
+{{note| '''Note''': `eif_create' does not call any creation procedure. It just allocates memory and initializes an object. }}
+
+===Protecting the objects returned by Eiffel functions.===
+
+> '''# include "eif_hector. h"'''
+''' EIF_OBJECT eif_protect (EIF_REFERENCE object)'''
+
+This function is used to tell explicitly the GC that you want to keep a reference to an eiffel object from the C. It returns a static indirection pointer which is to be used afterwards to access the direct Eiffel reference object with eif_access (returned_value) where returned_value is the value returned by eif_protect . With this call, the GC artificially references object, so that it cannot collect it. It is unsafe to access directly (i.e without using eif_access) the Eiffel reference object, which may be obsolete after any collection cycle (the GC moves the objects). Ignore this rule, if you are sure that there is no Eiffel call after you pass the direct Eiffel reference to a C function and before you read it.
+
+To release this artificial reference, call eif_wean (returned_value)
+
+eif_protect is to be called on an EIF_REFERENCE returned by eif_attribute, eif_string, or the returned value of eif_reference_function.
+
+See also eif_adopt, eif_create, eif_wean, eif_access.
+
+'''Example:''' Assume that you want to access an attribute `tab' of type ARRAY [INTEGER] in the class OBJECT.
+
+
+#include eif_setup.h"
+#include "eif_eiffel.h"
+main (int argc,char **argv,char **envp)
+{
+ EIF_TYPE_ID tid;
+ EIF_OBJECT my_obj;
+ EIF_PROCEDURE emake; /* Creation procedure of "OBJECT". */
+ EIF_REFERENCE tab; /* direct reference to `tab' from "OBJECT". */
+ EIF_OBJECT i_tab; /* Protected indirection to `tab'. */
+ EIF_INITIALIZE(failure)
+ tid = eif_type_id ("OBJECT");
+ if (tid == EIF_NO_TYPE)
+ eif_panic ("No type Id.");
+ my_obj = eif_create (tid);
+ emake = eif_procedure ("make", tid); /* On the eiffel side: make is do ... end.. */
+ (emake) (eif_access (my_obj)); /* Call `make' on `eif_access(my_obj)'.*/
+ tab = eif_attribute( eif_access (my_obj), "tab", EIF_REFERENCE, NULL);
+ /* Return the attribute `tab' of type EIF_REFERENCE
+ * of the object `eif_access (my_obj)'.
+ */
+ i_tab = eif_protect (tab); /* Here, protect `tab'. */
+ /* some code */
+ eif_wean (my_obj);
+ eif_wean (i_tab); /* We do not need it any more. */
+ EIF_DISPOSE_ALL /* Reclaim memory allocated by Eiffel run-time. */
+}
+
+
+
+{{note| '''Note''': Although you must protect Eiffel references returned by eif_attribute, you do not have to protect attributes of basic types - they are not Eiffel references and not supposed to move. }}
+
+===Getting the type id of an Eiffel type: eif_type_id===
+'''# include "eif_gen_conf. h"''' # include "eif_gen_conf. h"
+EIF_TYPE_ID eif_type_id (char *type_string)
+
+Return the type identifier corresponding to the type described in type_string. If the type does not exist, is not visible or an instance of it is not declared in the root class, it returns EIF_NO_TYPE.
+
+COMPATIBILITY:
+eif_type_id is equivalent to eif_type_by_name.
+'''Example:''' type_id of STD_FILES so as to call 'put_string'.
+
+
+EIF_PROCEDURE p_put_string; /* 'put_string' from STD_FILES. */
+EIF_TYPE_ID tid;
+EIF_REFERENCE_FUNCTION fn_io; /* once function `io' from ANY (and STD_FILES by inheritance). */
+EIF_REFERENCE o_io; /* Eiffel object `io' returned by once function*/
+EIF_REFERENCE o_str; /* Eiffel string */
+EIF_OBJECT i_io, i_str; /* safe indirection pointers to ``io' and Eiffel string. */
+tid = eif_type_id ("STD_FILES");
+if (tid == EIF_NO_TYPE)
+ eif_panic ("Type not in system.");
+fn_io = eif_reference_function ("io", tid);
+o_io = (fn_io) (root_obj); /* `root_obj' is the root object of the CECIL system
+ * automatically initialized in EIF_INITIALIZED
+ * if it does not exists */
+i_io = eif_protect (o_io); /* Protect `io' . */
+o_str = eif_string ("Hello World"); /* Create Eiffel string */
+i_str = eif_protect (o_str); /* Protect Eiffel string. */
+p_put_string = eif_procedure ("put_string", tid);
+if (p_put_string == (EIF_PROCEDURE) 0) /* No routine found. */
+ eif_panic ("put_string not visible"); /* Raised if "visible exception" disabled. */
+(p_put_string) (eif_access (i_io), eif_access (i_str));
+
+
+
+eif_type_id is also used for returning the type identifier of generic types but you need to specify the generic parameter, otherwise it returns EIF_NO_TYPE.
+
+'''Example:'''
+
+
+EIF_PROCEDURE p_make; /* 'make' from ARRAY [INTEGER] . */
+EIF_TYPE_ID tid;
+tid = eif_type_id ("ARRAY[INTEGER]");
+p_make = eif_procedure ("make", tid);
+
+
+
+===Getting the type id of a generic type : eif_generic_type.===
+Obsolete: see eif_type_id.
+===Raising an eiffel panic: eif_panic.===
+''' # include "eif_except. h"'''
+void eif_panic(char *msg)
+
+#include "eif_threads. h"
+
+void eif_thr_panic (char *msg)
+
+Raise an Eiffel panic with Eiffel exception trace with message msg. In MT mode, use eif_thr_panic instead.
+
+===Releasing an Eiffel indirection pointer: eif_wean===
+'''# include "eif_hector. h"'''
+EIF_REFERENCE eif_wean(EIF_OBJECT object)
+
+Tell the GC to remove the artificial reference to the nested Eiffel reference returned by eif_access (object). Then, the GC will be able to collect this nested object, as soon as it is not referenced from Eiffel any longer.
+
+{{note| '''Note:''' Object must have been previously created with eif_adopt, eif_protect or eif_create. }}
+eif_wean (object) returns an Eiffel reference, which corresponds to eif_access (object). After a call to eif_wean (object), eif_access (object) is NULL, which does not mean that the nested Eiffel object is Void, but that the indirection pointer does not reference it any longer. It is possible to reuse object later on.
+Calling eif_wean (external_argument) where external_argument is an Eiffel object given by a C external can cause erratic behaviors. Indeed, external_argument is an indirection pointer, which is automatically deleted after the external call (not the nested Eiffel object), deleting it prematurely can corrupt the indirection pointers stack.
+See also eif_access.
+'''Example:''' C external returning an Eiffel string.
+
+In Eiffel:
+
+ foo : STRING is
+ external
+ "C | %"a file.h%""
+ end
+
+
+In C:
+
+EIF_REFERENCE foo () {
+ EIF_REFERENCE str;
+ EIF_OBJECT i_str;
+ str = eif_string ("Hello world");
+ i_str = eif_protect(str);
+ /* Some operations on `i_str' */
+ return eif_wean (i_str); /* Returns direct reference to the Eiffel string.
+ * No need to keep an extra reference from the C. */
+}
+
+
+===Getting the attribute from an Eiffel object: eif_attribute===
+''' # include "eif_cecil. h"'''
+EIFFEL_TYPE eif_attribute (EIF_REFERENCE object, char *name, EIFFEL_TYPE, int *status)
+
+Return the attribute of an Eiffel object.
+
+The `eif_attribute' macro returns the attribute of object of name, which is of type EIFFEL_TYPE.
+
+EIFFEL_TYPE is the type of the Eiffel attribute. It can be: EIF_INTEGER, EIF_POINTER, EIF_CHARACTER, EIF_BOOLEAN, EIF_DOUBLE, EIF_REAL or EIF_REFERENCE.
+
+If status is NULL then no status is set. Otherwise the status of the function is put in *status:
+*status = EIF_NO_ATTRIBUTE => no attribute found.
+*status = EIF_CECIL_OK => attribute found.
+*status = EIF_CECIL_ERROR => an undefined error occurred, object may be invalid.
+
+If the visible exception is enabled, then a visible exception is raised upon failure (EIF_NO_ATTRIBUTE, EIF_CECIL_ERROR).
+
+RETURN VALUE:
+upon failure, it returns (EIFFEL_TYPE) 0, otherwise, the attribute is returned. If the return value is not a basic type, you must protect it with eif_protect
+COMPATIBILITY:
+eif_attribute (object, name, type, NULL) is equivalent to eif_field (object, name, type)
+{{tip| '''Tips''': You cannot access a constant attribute, or the result of a function (once or not) with eif_attribute. Use eif_procedure or eif_xx_function instead.
+
+EIF_BOOLEAN attribute_exists (EIF_REFERENCE object, char *name) returns EIF_TRUE or EIF_FALSE depending if the attribute exists or not, is visible or not. }}
+
+===Getting the address of an Eiffel routine===
+''' #include "eif_cecil. h"'''
+
+''' EIF_PROCEDURE eif_procedure (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_REFERENCE_FUNCTION eif_reference_function (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_INTEGER_FUNCTION eif_integer_function (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_CHARACTER_FUNCTION eif_character_function (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_REAL_FUNCTION eif_real_function (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_DOUBLE_FUNCTION eif_double_function (char *rput_name, EIF_TYPE_ID type_id)'''
+''' EIF_BIT_FUNCTION eif_bit_function (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_BOOLEAN_FUNCTION eif_boolean_function (char *rout_name, EIF_TYPE_ID type_id)'''
+''' EIF_POINTER_FUNCTION eif_pointer_function (char *rout_name, EIF_TYPE_ID type_id)'''
+Return the address of the Eiffel routine by giving its name rout_name and the type id type_id of the class, in which it is declared. Returns a NULL pointer or raises a visible exception (if enabled) when there is no corresponding routine with name rout_name or the routine is not visible. The first argument of an Eiffel routine has to be the target of the Eiffel routine.
+
+The Eiffel object returned by an Eiffel function must be protected afterwards with 'eif_protect' (this only applies for functions whose addresses are returned by `eif_reference_function', since the other function types returns basic types, which are not Eiffel objects).
+
+{{note| '''Note''': The address returned by these functions must be called between parenthesis. }}
+
+{{warning| '''Caution''': Be sure that the Eiffel routine is not a C External. In this case, you should call directly the C external instead of its Eiffel wrapper. }}
+
+===Enabling/Disabling the visible exception===
+''' #include "eif_cecil. h"'''
+''' void eif_enable_visible_exception ()'''
+''' void eif_disable_visible_exception ()'''
+
+Respectively, enable and disable the visible exception.
+By default, the visible exception is disabled (since v4. 5).
+
+===Creating an Eiffel string: eif_string===
+'''#include "eif_plug. h"'''
+EIF_REFERENCE eif_string (char *string) /* Macro */
+
+Return the direct reference to an Eiffel string by giving the corresponding C string . The result of eif_string does not reference the C string passed as argument: it copies it, before creating the Eiffel string.
+
+{{note| '''Notes''': The return value must be protected with eif_protect for later use.
+
+The C string must be manually freed by the user, if it has been dynamically allocated. }}
+
+COMPATIBILITY:
+eif_string ("ABC") is equivalent to RTMS ("ABC") and eif_make_string ("ABC", strlen ("ABC")).
+===Getting the return-type of an attribute: eif_attribute_type===
+''' #include "eif_cecil. h"'''
+int eif_attribute_type (char *attr_name, EIF_TYPE_ID tid)
+
+''' #define EIF_REFERENCE_TYPE 1'''
+''' #define EIF_CHARACTER_TYPE 2'''
+''' #define EIF_BOOLEAN_TYPE 3'''
+''' #define EIF_INTEGER_TYPE 4'''
+''' #define EIF_REAL_TYPE 5'''
+''' #define EIF_DOUBLE_TYPE 6'''
+''' #define EIF_EXPANDED_TYPE 7'''
+''' #define EIF_BIT_TYPE 8'''
+''' #define EIF_POINTER_TYPE 0'''
+''' #define EIF_NO_TYPE (-1)'''
+
+
+Return the type of the attribute described by its name attr_name and the type identifier tid of the class where it is defined. The return type is an int (see above for correspondences). In case of failure, EIF_NO_TYPE is returned - not such given attribute name, routine name instead of attribute name, or so on.
+
+'''Example:''' Get the type of count from STRING
+
+
+int i;
+i = eif_attribute_type ("count", eif_type_id ("STRING");
+printf ("type is %d\n"); /* Should be EIF_INTEGER_TYPE since it returns an Eiffel Integer */
+
+
+
+{{tip| '''Tip''': *(EIFFEL_TYPE *) eif_attribute_safe (EIF_REFERENCE object, char *name, int type_int, int *status) can be used for debugging or type checking. It returns the attribute reference of name from the object of type type_int. status contains the status of the function call: it can be EIF_CECIL_OK, EIF_CECIL_ERROR, EIF_NO_ATTRIBUTE or EIF_WRONG_TYPE (type_int does not match with real type of object). }}
+
+===Getting the class name corresponding to a type id: eif_name===
+''' #include "eif_cecil. h"'''
+char *eif_name (EIF_TYPE_ID tid)
+
+Return the corresponding name (C string) of the Eiffel class, given a type identifier type_id. If the type identifier is a generic type identifier, no generic parameter type is given. Return NULL if an invalid type identifier is given.
+
+'''Example:'''
+
+printf ("the class name with type id 1 is %s\n", eif_name (1); /* Should print "ANY" on most compiler versions */
+
+COMPATIBILITY:
+eif_name is equivalent to eif_name_by_tid
+===Getting the type id of an Eiffel object: eif_type, eif_type_by_reference.===
+''' #include "eif_cecil. h"'''
+EIF_TYPE_ID eif_type (EIF_OBJECT object)
+
+EIF_TYPE_ID eif_type_by_reference (EIF_REFERENCE reference)
+
+eif_type returns the type identifier, given an indirection pointer to an Eiffel object.
+
+eif_type_by_reference returns the type identifier, given the direct reference to an Eiffel object reference.
+
+COMPATIBILITY:
+eif_type is equivalent to eif_type_by_object.eif_type (object) is equivalent to eif_type_by_reference (eif_access (object)).
+===Converting a C array into an Eiffel array: eif_make_from_c.===
+'''eif_make_from_c(eif_array, c_array, int nelts, int type) /* Macro */''' (since 4. 5)
+eif_array is an EIF_REFERENCE, c_array is a C array of type (type *), nelts is the number of elements in the array.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/attribute-exists.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/attribute-exists.wiki
new file mode 100644
index 00000000..126d605d
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/attribute-exists.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Reference for `attribute_exists']]
+[[Property:link_title|attribute_exists]]
+[[Property:weight|-15]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"'''
+
+'''EIF_BOOLEAN attribute_exists (EIF_REFERENCE''' ''object'', '''char *''' ''name''''')''';
+
+==DESCRIPTION==
+The '''attribute_exists()''' macro returns '''EIF_TRUE''' or '''EIF_FALSE''' when the attribute of name ''name'' exists in the Eiffel object (reference) ''ref'' '''. '''
+==RETURN VALUE==
+'''EIF_TRUE''' or '''EIF_FALSE'''.
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==SEE ALSO==
+'''eif_attribute''' (1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-access.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-access.wiki
new file mode 100644
index 00000000..087b8dc3
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-access.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Reference for `eif_access']]
+[[Property:link_title|eif_access]]
+[[Property:weight|-14]]
+==SYNOPSYS==
+
+'''#include "eif_hector.h"
+
+EIF_REFERENCE eif_access (EIF_OBJECT''' ''obj''''');'''
+
+==DESCRIPTION==
+The '''eif_access()''' macro accesses the Eiffel object ''obj''.
+==RETURN VALUE==
+It returns the Eiffel reference protected by ''obj'' and which can be passed to Eiffel routines.
+==CONFORMANCE==
+ISE Eiffel 4.1 and later.
+==SEE ALSO==
+'''eif_wean'''(1) , '''eif_adopt'''(1), '''eif_protect'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-adopt.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-adopt.wiki
new file mode 100644
index 00000000..37b4aae4
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-adopt.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Reference for `eif_adopt']]
+[[Property:link_title|eif_adopt]]
+[[Property:weight|-13]]
+==SYNOPSYS==
+
+'''#include "eif_hector.h"
+
+EIF_OBJECT eif_adopt (EIF_OBJECT''' ''obj''''');'''
+
+==DESCRIPTION==
+The '''eif_adopt()''' function adopts ''obj''. By adopting it, the user prevents ''obj'' from being unprotected automatically by the Eiffel run-time. The run-time protects automatically the Eiffel objects passed to a C external before entering in it and unprotects them after exiting the C external. To keep this protection later on, you must call '''eif_adopt()'''.
+==RETURN VALUE==
+The '''eif_adopt()''' function returns an EIF_OBJECT. This return value can be used later on to access the nested protected Eiffel reference with '''eif_access()'''.
+==CONFORMANCE==
+ISE Eiffel 4.1 and later.
+==SEE ALSO==
+'''eif_access''' (1), '''eif_protect''' (1), '''eif_wean''' (1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-attribute-type.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-attribute-type.wiki
new file mode 100644
index 00000000..55edd2f3
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-attribute-type.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Reference for `eif_attribute_type']]
+[[Property:link_title|eif_attribute_type]]
+[[Property:weight|-11]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+int eif_attribute_type (char *''' ''attr''''', EIF_TYPE_ID''' ''tid''''');'''
+
+==DESCRIPTION==
+The '''eif_attribute_type()''' function returns the type of the attribute ''attr'', from the Eiffel type, which type identifier is ''tid'' '''. '''
+==RETURN VALUE==
+Upon failure, it returns EIF_NO_TYPE. Otherwise, the return value can be one of the following: '''EIF_INTEGER_TYPE''', '''EIF_CHARACTER_TYPE''', '''EIF_BOOLEAN_TYPE''', '''EIF_DOUBLE_TYPE''', '''EIF_REAL_TYPE''', '''EIF_REFERENCE_TYPE''', '''EIF_EXPANDED_TYPE''', '''EIF_BIT_TYPE'''.
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==SEE ALSO==
+'''eif_protect'''(1) , '''attribute_exists'''(1) , '''eif_procedure'''(1) , '''eif_reference_function'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-attribute.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-attribute.wiki
new file mode 100644
index 00000000..ce7ed4b9
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-attribute.wiki
@@ -0,0 +1,34 @@
+[[Property:title|Reference for `eif_attribute'.]]
+[[Property:link_title|eif_attribute]]
+[[Property:weight|-12]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+EIFFEL_TYPE eif_attribute (EIF_REFERENCE''' ''object''''', char *''' ''name''''', EIFFEL_TYPE, int *''' ''status'');
+
+==DESCRIPTION==
+The '''eif_attribute()''' macro returns the attribute of name ''name'', which is of type ''EIFFEL_TYPE''.
+''EIFFEL_TYPE'' is the type of the Eiffel attribute. It can be: '''EIF_INTEGER''', '''EIF_CHARACTER''', '''EIF_BOOLEAN''', '''EIF_DOUBLE''', '''EIF_REAL''', or '''EIF_REFERENCE'''.
+
+If ''status'' is NULL then no status is set. Otherwise the status of the call is put into ''*status''. Its value is one of the following:
+
+If the visible exception is enabled, then a visible exception is raised upon failure ( '''EIF_NO_ATTRIBUTE''', '''EIF_CECIL_ERROR''').
+
+==RETURN VALUE==
+Upon failure, it returns ( ''EIFFEL_TYPE'') 0, otherwise the attribute is returned.
+==NOTES==
+If the return value is an '''EIF_REFERENCE''', you must protect it with '''eif_protect()'''.
+You cannot access a constant attribute, or the result of a once function with '''eif_attribute()'''.
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==COMPATIBILITY==
+'''eif_attribute (''' ''object'' ''',''' ''name'' ''',''' ''type'' ''',''' ''NULL'' ''')'''
+is equivalent to:
+'''eif_field (''' ''object'' ''',''' ''name'' ''',''' ''type'' ''')'''
+which is deprecated.
+==SEE ALSO==
+'''eif_protect'''(1) , '''attribute_exists'''(1) , '''eif_procedure'''(1) , '''eif_reference_function'''(1). Markup created by 1. 0, November 15, 1999.
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-create.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-create.wiki
new file mode 100644
index 00000000..1c8dc622
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-create.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Reference for `eif_create']]
+[[Property:link_title|eif_create]]
+[[Property:weight|-7]]
+==SYNOPSYS==
+
+'''#include "eif_cecil. h"'''
+
+'''EIF_OBJECT eif_create (EIF_TYPE_ID''' ''tid''''');'''
+
+==DESCRIPTION==
+The '''eif_create()''' function creates an Eiffel object, which type identifier is ''tid''.
+==RETURN VALUE==
+It returns an Eiffel object, which is already protected.
+==NOTES==
+You cannot pass the return value to Eiffel routines as is: you must call '''eif_access()''' to pass it to Eiffel routine.
+To release the protection of an Eiffel object created with '''eif_create()''', call '''eif_wean()'''. It will be collected during the next collection.
+==CONFORMANCE==
+ISE Eiffel 4.1 and later.
+==SEE ALSO==
+'''eif_wean'''(1) , '''eif_type_id'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-disable-visible-exception.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-disable-visible-exception.wiki
new file mode 100644
index 00000000..3fdf99d9
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-disable-visible-exception.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Reference for `eif_disable_visible_exception']]
+[[Property:link_title|eif_disable_visible_exception]]
+[[Property:weight|-6]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+void eif_enable_visible_exception ();
+void eif_disable_visible_exception ();'''
+
+==DESCRIPTION==
+The '''eif_enable_visble_exception()''' routine enables the visible exception, while '''eif_disable_visible_exception()'''disables it. These routines can be used for debugging purpose. A visible exception is raised when the user tries to access to an Eiffel attribute or a Eiffel routine address which is not visible.
+The visible exception is disabled by default.
+
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==COMPATIBILTY==
+In ISE Eiffel 4.3 and 4.4, the visible exception is enabled by default.
+==SEE ALSO==
+'''eif_attribute'''(1) , '''eif_procedure'''(1), '''eif_reference_function'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-enable-visible-exception.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-enable-visible-exception.wiki
new file mode 100644
index 00000000..d37f2697
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-enable-visible-exception.wiki
@@ -0,0 +1,23 @@
+[[Property:title|Reference for `eif_enable_visible_exception']]
+[[Property:link_title|eif_enable_visible_exception]]
+[[Property:weight|-4]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+void eif_enable_visible_exception ();
+void eif_disable_visible_exception ();'''
+
+==DESCRIPTION==
+The '''eif_enable_visble_exception()''' routine enables the visible exception, while '''eif_disable_visible_exception()'''disables it. These routines can be used for debugging purpose. A visible exception is raised when the user tries to access to an Eiffel attribute or a Eiffel routine address which is not visible.
+The visible exception is disabled by default.
+
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==COMPATIBILITY==
+In ISE Eiffel 4.3 and 4.4, the visible exception is enabled by default.
+==SEE ALSO==
+'''eif_attribute'''(1) , '''eif_procedure'''(1), '''eif_reference_function'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-name-tid.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-name-tid.wiki
new file mode 100644
index 00000000..1be3c7e1
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-name-tid.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Reference for `eif_name_by_tid']]
+[[Property:link_title|eif_name_by_tid]]
+[[Property:weight|-1]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+char *eif_name_by_tid (EIF_TYPE_ID''' ''tid''''');'''
+
+==DESCRIPTION==
+The '''eif_name_by_tid()''' function returns the name of the class corresponding to ''tid''.
+==RETURN VALUE==
+A statically allocated C string which is the name of the class. If ''tid'' is invalid, it returns NULL.
+==CONFORMANCE==
+ISE Eiffel 4.4 and later.
+==COMPATIBILITY==
+'''eif_name()''' is equivalent to '''eif_name_by_tid()'''.
+==SEE ALSO==
+'''eif_type'''(1) , '''eif_type_by_reference'''(1), '''eif_type_id'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-name.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-name.wiki
new file mode 100644
index 00000000..312b4a09
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-name.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Reference for `eif_name']]
+[[Property:link_title|eif_name]]
+[[Property:weight|-2]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+char *eif_name (EIF_TYPE_ID '''''tid''''');'''
+
+==DESCRIPTION==
+The '''eif_name()''' function returns the name of the class corresponding to ''tid''.
+==RETURN VALUE==
+A statically allocated C string which is the name of the class. If ''tid'' is invalid, it returns NULL.
+==CONFORMANCE==
+ISE Eiffel 4.4 and later.
+==COMPATIBILITY==
+'''eif_name()''' is equivalent to '''eif_name_by_tid()'''.
+==SEE ALSO==
+'''eif_type'''(1) , '''eif_type_by_reference'''(1), '''eif_type_id'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-procedure.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-procedure.wiki
new file mode 100644
index 00000000..4c003260
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-procedure.wiki
@@ -0,0 +1,28 @@
+[[Property:title|Reference for `eif_procedure']]
+[[Property:link_title|eif_procedure]]
+[[Property:weight|1]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+EIF_PROCEDURE eif_procedure (char *''' ''name''''', int *''' ''tid''''');'''
+
+==DESCRIPTION==
+The '''eif_procedure()''' function returns the address of the Eiffel procedure of name ''name'' from the class, which type identifier is ''tid''.
+If the visible exception is enabled, it raises an visible exception upon failure.
+
+==RETURN VALUE==
+It returns NULL when it fails ( the procedure does not exist or is not visible). Otherwise, the address of the procedure is returned.
+==NOTES==
+The Eiffel procedure cannot be a C external. In this case, you must directly call the C routine.
+The return value is an address: to use it as a routine, you must call it with arguments or at least with ().
+No argument type checking is done. You may cast the address of an Eiffel routine obtained with '''eif_procedure()''' when calling it with real arguments.
+==CONFORMANCE==
+ISE Eiffel 4.4 and later.
+==COMPATIBILITY==
+'''eif_procedure()''' is equivalent to '''eif_proc()''', which is deprecated.
+==SEE ALSO==
+'''eif_type_id'''(1), '''eif_reference_function'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-protect.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-protect.wiki
new file mode 100644
index 00000000..abf60592
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-protect.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Reference for `eif_protect']]
+[[Property:link_title|eif_protect]]
+[[Property:weight|2]]
+==SYNOPSYS==
+
+'''#include "eif_hector.h"
+
+EIF_OBJECT eif_protect (EIF_REFERENCE''' ''ref''''');'''
+
+==DESCRIPTION==
+The '''eif_protect()''' function protects the Eiffel reference ''ref'' from the GC. It keeps a reference on it so that the Garbage Collector does not collect it if it is not referenced from Eiffel any longer.
+==RETURN VALUE==
+The '''eif_protect()''' function returns an EIF_OBJECT. This EIF_OBJECT can be used later on to access ''ref'' with '''eif_access ()'''.
+==CONFORMANCE==
+ISE Eiffel 4.4 and later.
+==COMPATIBILTY==
+It is equivalent to '''henter()''', which is deprecated.
+==SEE ALSO==
+'''eif_access'''(1), '''eif_protect'''(1) , '''eif_wean'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-string.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-string.wiki
new file mode 100644
index 00000000..1ce8b1b4
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-string.wiki
@@ -0,0 +1,24 @@
+[[Property:title|Reference for `eif_string']]
+[[Property:link_title|eif_string]]
+[[Property:weight|5]]
+==SYNOPSYS==
+
+'''#include "eif_plug.h"
+
+EIF_REFERENCE eif_string (char *''' ''string''''');'''
+
+==DESCRIPTION==
+The '''eif_string()''' macro returns the corresponding Eiffel string corresponding to the C string ''string''.
+The return value does not reference ''string''.
+
+==NOTES==
+This function return an Eiffel reference, which must be protected with '''eif_protect()'''.
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==COMPATIBILITY==
+'''eif_string()''' is equivalent to '''RTMS()''', which is deprecated.
+==SEE ALSO==
+'''eif_protect'''(1) , '''eif_create'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-id.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-id.wiki
new file mode 100644
index 00000000..23c5fea3
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-id.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Reference for `eif_type_id']]
+[[Property:link_title|eif_type_id]]
+[[Property:weight|9]]
+==SYNOPSYS==
+
+'''#include "eif_gen_conf.h"
+
+EIF_TYPE_ID eif_type_id (char *''' ''type''''');'''
+
+==DESCRIPTION==
+The '''eif_type_id()''' function returns the type identifier corresponding to ''type'', which is the name of the type.
+==RETURN VALUE==
+The '''eif_type_id()''' function returns the type
+==NOTES==
+An error cannot be caught by a visible exception.
+The type is not necessary visible.
+==CONFORMANCE==
+ISE Eiffel 4.3 and later.
+==COMPATIBILITY==
+'''eif_type_id()''' is equivalent to '''eif_type_by_name()'''. With ISE Eiffel 4.2 and earlier, use '''eif_generic_type()''' for generic types.
+==SEE ALSO==
+'''eif_reference_function'''(1) , '''eif_procedure'''(1) , '''eif_type'''(1), '''eif_name'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-name.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-name.wiki
new file mode 100644
index 00000000..242f467a
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-name.wiki
@@ -0,0 +1,25 @@
+[[Property:title|Reference for `eif_type_by_name']]
+[[Property:link_title|eif_type_by_name]]
+[[Property:weight|7]]
+==SYNOPSYS==
+
+'''#include "eif_gen_conf.h"
+
+EIF_TYPE_ID eif_type_by_name (char *''' ''type''''');'''
+
+==DESCRIPTION==
+The '''eif_type_by_name()''' function returns the type identifier corresponding to ''type'', which is the name of the type.
+==RETURN VALUE==
+The '''eif_type_by_name()''' function returns the type
+==NOTES==
+An error cannot be caught by a visible exception.
+The type is not necessary visible.
+==CONFORMANCE==
+ISE Eiffel 4.3 and later.
+==COMPATIBILITY==
+'''eif_type_by_name()''' is equivalent to '''eif_type_id()'''.
+==SEE ALSO==
+'''eif_reference_function'''(1) , '''eif_procedure'''(1) , '''eif_type'''(1), '''eif_name'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-reference.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-reference.wiki
new file mode 100644
index 00000000..d2d16571
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type-reference.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Reference for `eif_type_by_reference']]
+[[Property:link_title|eif_type_by_reference]]
+[[Property:weight|8]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+EIF_TYPE_ID eif_type_by_reference (EIF_REFERENCE''' ''reference''''');'''
+
+==DESCRIPTION==
+The '''eif_type_by_reference()''' function returns the type identifier corresponding to ''reference''.
+==RETURN VALUE==
+Type identifier of ''reference''. The behavior is unknown if ''reference'' is not a valid Eiffel reference.
+==CONFORMANCE==
+ISE Eiffel 4.5 and later.
+==SEE ALSO==
+'''eif_type'''(1) , '''eif_name'''(1), '''eif_type_id'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type.wiki
new file mode 100644
index 00000000..c5f27efa
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-type.wiki
@@ -0,0 +1,22 @@
+[[Property:title|Reference for `eif_type']]
+[[Property:link_title|eif_type]]
+[[Property:weight|6]]
+==SYNOPSYS==
+
+'''#include "eif_cecil.h"
+
+EIF_TYPE_ID eif_type (EIF_OBJECT '''''object''''');'''
+
+==DESCRIPTION==
+The '''eif_type()''' function returns the type identifier corresponding to ''object''.
+==RETURN VALUE==
+Type identifier of ''object''. The behavior is unknown if ''object'' is not a valid Eiffel object.
+==CONFORMANCE==
+ISE Eiffel 4.3 and later.
+==COMPATIBILITY==
+'''eif_type()''' is equivalent to '''eif_type_by_reference(eif_access (object))'''.
+==SEE ALSO==
+'''eif_type_by_reference'''(1) , '''eif_type_id'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-wean.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-wean.wiki
new file mode 100644
index 00000000..8f7e69d2
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/eif-wean.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Reference for `eif_wean']]
+[[Property:link_title|eif_wean]]
+[[Property:weight|10]]
+==SYNOPSYS==
+
+'''#include "eif_hector.h"
+
+EIF_REFERENCE eif_wean (EIF_OBJECT''' ''obj''''');'''
+
+==DESCRIPTION==
+The '''eif_wean()''' function releases the protection of the Eiffel reference, which is protected by the Eiffel object ''obj''.
+==RETURN VALUE==
+It returns the Eiffel reference previously protected by obj.
+==CONFORMANCE==
+ISE Eiffel 4.1 and later.
+==SEE ALSO==
+'''eif_access'''(1) , '''eif_adopt'''(1), '''eif_protect'''(1).
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-reference/index.wiki b/documentation/current/solutions/other-languages/cecil/cecil-reference/index.wiki
new file mode 100644
index 00000000..ba7921a1
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-reference/index.wiki
@@ -0,0 +1,32 @@
+[[Property:title|CECIL Reference]]
+[[Property:weight|4]]
+Index of CECIL features
+* [[Reference for `RTMS'|RTMS()]]
+* [[Reference for `attribute_exists'|attribute_exists()]]
+* [[Reference for `eif_adopt'|eif_adopt()]]
+* [[Reference for `eif_attribute'.|eif_attribute()]]
+* [[Reference for `eif_attribute_type'|eif_attribute_type()]]
+* [[Reference for `eif_bit_function'|eif_bit_function()]]
+* [[Reference for 'eif_boolean_function'|eif_boolean_function()]]
+* [[Reference for `eif_character_function'|eif_character_function()]]
+* [[Reference for `eif_disable_visible_exception'|eif_disable_visible_exception()]]
+* [[Reference for `eif_double_function'|eif_double_function()]]
+* [[Reference for `eif_enable_visible_exception'|eif_enable_visible_exception()]]
+* [[Reference for `eif_integer_function'|eif_integer_function()]]
+* [[Reference for `eif_name'|eif_name()]]
+* [[Reference for `eif_name_by_tid'|eif_name_by_tid()]]
+* [[Reference for `eif_pointer_function'|eif_pointer_function()]]
+* [[Reference for `eif_procedure'|eif_procedure()]]
+* [[Reference for `eif_protect'|eif_protect()]]
+* [[Reference for `eif_real_function'|eif_real_function()]]
+* [[Reference for `eif_reference_function'|eif_reference_function()]]
+* [[Reference for `eif_string'|eif_string()]]
+* [[Reference for `eif_type'|eif_type()]]
+* [[Reference for `eif_type_by_name'|eif_type_by_name()]]
+* [[Reference for `eif_type_by_reference'|eif_type_by_reference()]]
+* [[Reference for `eif_type_id'|eif_type_id()]]
+* [[Reference for `eif_wean'|eif_wean()]]
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-basic-sample.wiki b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-basic-sample.wiki
new file mode 100644
index 00000000..f8846413
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-basic-sample.wiki
@@ -0,0 +1,75 @@
+[[Property:title|CECIL - Basic sample]]
+[[Property:weight|2]]
+==cecil-test==
+
+After you have done the appropriate steps to compile the example, you will get a `cecil.exe' on windows, or `cecil' on Unix.
+
+This example performs some basic tests of CECIL from C to Eiffel and Eiffel to C. You can:
+* choose to raise an exception when a routine is not visible
+* create an Eiffel string
+* choose to raise a precondition violation from C.
+
+
+
+A typical output will be:
+
+$ cecil
+Do you want to enable the visible exception? (y-yes, n-no):n
+Disable visible exception
+
+====== In eiffel_call ======
+ Eiffel type id = 9
+ Eiffel procedure make 0x100546b4
+ Eiffel object = 0x30068030
+Testing linked_list...
+12345
+test_linked_list OK
+Testing memory...
+Give string length (enter a high number for raising an Eiffel exception)
+234
+Memory OK
+Testing if string void ...
+Enter a string: (press enter if you want to raise an Eiffel exception)
+wefsd
+wefsdTesting precondition...By default it is true
+
+====== Done ======
+
+====== In eiffel_call ======
+ Eiffel type id = 9
+ Eiffel procedure test_linked_list 0x10054ebc
+ Eiffel object = 0x30068030
+Testing linked_list...
+12345
+test_linked_list OK
+
+====== Done ======
+
+====== In eiffel_call_1_arg ======
+ Eiffel type id = 9
+ Eiffel procedure print 0x1004e0a8
+ Eiffel object = 0x30068030
+ Eiffel object = 0x30068030
+Execute the Eiffel code `print (linked_list)' from the C side:
+MAIN [0x30068030]
+ linked_list: LINKED_LIST [0x30068C40]
+
+====== Done ======
+
+====== In cecil_test ======
+ protected indirection of 30068c40 is 300311bc
+ Eiffel type id of STRING = 198
+ Eiffel type id of LINKED_LIST [STRING] = 224
+ Linked List forth: 10222fbc
+ Linked list object = 0x30068c40
+Do you want to test the visibility of an Eiffel routine? (y-yes, n-no):
+n
+Do you want raise a precondition violation? (y-yes, n-no):
+n
+
+====== Done ======
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-c-eiffel.wiki b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-c-eiffel.wiki
new file mode 100644
index 00000000..8fd80db2
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-c-eiffel.wiki
@@ -0,0 +1,45 @@
+[[Property:title|CECIL - C to Eiffel]]
+[[Property:weight|0]]
+==array==
+This example shows how to create an Eiffel array from an existing C array. After you have done the appropriate steps to compile the example, you will get a `cecil.exe' on windows, or `cecil' on Unix. Launch the program and you will be prompted for 10 integers that will be inserted in a C array, it will then initialize the Eiffel array and calls display from the MY_ARRAY class. A typical output will be:
+
+$ ./cecil
+Enter 10 integers:
+Enter element 1: 1
+Enter element 2: 2
+Enter element 3: 3
+Enter element 4: 4
+Enter element 5: 5
+Enter element 6: 6
+Enter element 7: 7
+Enter element 8: 8
+Enter element 9: 9
+Enter element 10: 10
+
+Display an Eiffel Array:
+@1 = 1
+@2 = 2
+@3 = 3
+@4 = 4
+@5 = 5
+@6 = 6
+@7 = 7
+@8 = 8
+@9 = 9
+@10 = 10
+
+
+==string==
+This example shows how to create an Eiffel string from an existing C string. After you have done the appropriate steps to compile the example, you will get a `cecil.exe' on windows, or `cecil' on Unix. Launch the program and you will be prompted for a string, it will then initialize the Eiffel string and calls io. put_string from the STD_FILES class. A typical output will be:
+
+$ ./cecil
+Enter a string to convert in Eiffel string:
+Hello World!
+Now printing the Eiffel string from Eiffel
+
+Hello World!
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-eiffel-c.wiki b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-eiffel-c.wiki
new file mode 100644
index 00000000..6f528c2c
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-eiffel-c.wiki
@@ -0,0 +1,95 @@
+[[Property:title|CECIL - Eiffel to C]]
+[[Property:weight|1]]
+==array==
+
+This example shows how to create a C array from an existing Eiffel array.
+
+After you have done the appropriate steps to compile the example, you will get a `cecil.exe' on windows, or `cecil' on Unix.
+
+Launch the program and you will be prompted for 10 integers that will be inserted in an Eiffel array, it will then initialize the C array and display it.
+
+A typical output will be:
+
+$ ./cecil
+This example create n array on the Eiffel side and print it on the C side
+Enter 10 integers:
+1
+2
+3
+4
+5
+6
+7
+8
+9
+10
+
+Displaying from C
+@1 = 1
+@2 = 2
+@3 = 3
+@4 = 4
+@5 = 5
+@6 = 6
+@7 = 7
+@8 = 8
+@9 = 9
+@10 = 10
+
+
+==object==
+This example shows the Eiffel memory management and all issues when passing an Eiffel object reference to C. In the example, you can edit the file `root_class.e' to modify the example:
+
+--give_to_c (o1)
+give_to_c_by_pointer ($o1) -- Choose the way you pass it
+
+When you choose the first possibility (commented by default), give_to_c will use the CECIL API eif_adopt to keep a reference on the Eiffel object. When you choose the second possibility, give_to_c_by_pointer will use the CECIL API eif_protect to keep a reference on the Eiffel object. Until forget_from_c is called from the C side, the object o1 will not be collected since we have protected it through the call to give_to_c or give_to_c_by_pointer. At the end after the object o1 is collected, we try to perform an operation on it which will fail with a call on void target exception. A typical output will be:
+
+$ cecil
+Creating o1
+Object string is o1
+Give it to C
+Losing reference to initial o1 from Eiffel
+Collecting...
+Display new o1:
+Object string is o2
+Display o1 given to C:
+Object string is o1
+Losing reference from C
+Losing reference from Eiffel
+Collecting...
+An Eiffel object of type OBJECT is collected
+Old o1 forgot from both C and Eiffel:
+Raise a Void exception..
+
+cecil: system execution failed.
+Following is the set of recorded exceptions:
+-------------------------------------------------------------------------------
+Class / Object Routine Nature of exception Effect
+-------------------------------------------------------------------------------
+ROOT_CLASS make @26 display:
+<30068030> Feature call on void target. Fail
+-------------------------------------------------------------------------------
+ROOT_CLASS make @26
+<30068030> Routine failure. Fail
+-------------------------------------------------------------------------------
+ROOT_CLASS root's creation
+<30068030> Routine failure. Exit
+-------------------------------------------------------------------------------
+An Eiffel object of type OBJECT is collected
+
+
+==string==
+This example shows how to create a C string from an existing Eiffel string. After you have done the appropriate steps to compile the example, you will get a `cecil.exe' on windows, or `cecil' on Unix. Launch the program and you will be prompted for a string from Eiffel and a C string will be created and display. A typical output will be:
+
+$ cecil
+Enter a string to convert into a C string:
+Hello World!
+
+Here is the C string:
+Hello World!
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-how-compile-samples.wiki b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-how-compile-samples.wiki
new file mode 100644
index 00000000..3ccfc8aa
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-how-compile-samples.wiki
@@ -0,0 +1,40 @@
+[[Property:title|CECIL - How to compile the samples?]]
+[[Property:weight|4]]
+==Compiling for Windows==
+
+Depending on your C compiler different steps have to be done, but do not forget to do the following before starting the C compiler specific part in a DOS console:
+set ISE_EIFFEL=XXX
+
+where XXX is the EiffelStudio installation directory.
+
+===With Borland C++:===
+
+By default, Borland C++ is not in your path, so you will have to first set your path correctly by typing:
+set PATH=%ISE_EIFFEL%\BCC55\bin;%PATH%
+
+If the file `Makefile. win' is present, then you can launch the compilation with:
+make -f Makefile. win
+
+Otherwise launch the compilation with:
+make -f Makefile. bcb
+
+===With Microsoft Visual C++:===
+
+By default, the command line tools of Visual C++ should be available from the command line.
+
+If the file `Makefile. win' is present, then you can launch the compilation with:
+nmake -f Makefile. win
+
+Otherwise launch the compilation with:
+nmake -f Makefile. msc
+
+==Compiling for UNIX==
+
+Then, make sure that your path to the EiffelStudio executables are properly configured before launching the command below.
+
+To compile and execute from scratch type:
+finish_freezing -library
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-threads.wiki b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-threads.wiki
new file mode 100644
index 00000000..9318ad7b
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-samples/cecil-threads.wiki
@@ -0,0 +1,69 @@
+[[Property:title|CECIL - Threads]]
+[[Property:weight|3]]
+==bank_account==
+
+After you have done the appropriate steps to compile the example, you will get a `bank_account.exe' on windows, or `bank_account' on Unix.
+
+This program launches two types of threads:
+* the spenders withdraw some money from a shared bank account
+* the savers make some deposits on it.
+
+The Eiffel Threads are launched from C. The synchronization is done from Eiffel. The shared bank account is a C structure, and is updated by the Eiffel Threads using some C externals.
+
+
+In main. c:
+LISTSZ size of bank account history.
+DEPOSITORS numbers of savers.
+WITHDRAWERS numbers of spenders.
+
+
+
+
+A typical output will be:
+
+$ bank_account
+**** Bank account report:
+Thread 0x30036350 DEPOSIT 161
+Thread 0x30036350 DEPOSIT 614
+Thread 0x30036350 DEPOSIT 626
+Thread 0x30036350 DEPOSIT 880
+Thread 0x30036350 DEPOSIT 601
+Thread 0x30036350 DEPOSIT 480
+Thread 0x30036350 DEPOSIT 177
+Thread 0x30036350 DEPOSIT 451
+Thread 0x30036350 DEPOSIT 96
+Thread 0x30036350 DEPOSIT 219
+*** BALANCE: 5305
+Do you want to continue? (y/n)
+y
+**** Bank account report:
+Thread 0x3003fcf0 DEPOSIT 161
+Thread 0x3004f088 DEPOSIT 161
+Thread 0x300567a0 WITHDRAWAL 161
+Thread 0x3005e1f0 WITHDRAWAL 161
+Thread 0x30036350 DEPOSIT 531
+Thread 0x3003fcf0 DEPOSIT 614
+Thread 0x3004f088 DEPOSIT 614
+Thread 0x300567a0 WITHDRAWAL 614
+Thread 0x30036350 DEPOSIT 409
+Thread 0x3003fcf0 DEPOSIT 626
+*** BALANCE: 7485
+Do you want to continue? (y/n)
+y
+**** Bank account report:
+Thread 0x3004f088 DEPOSIT 626
+Thread 0x30036350 DEPOSIT 799
+Thread 0x300567a0 WITHDRAWAL 626
+Thread 0x3005e1f0 WITHDRAWAL 614
+Thread 0x3003fcf0 DEPOSIT 880
+Thread 0x30036350 DEPOSIT 860
+Thread 0x3004f088 DEPOSIT 880
+Thread 0x300567a0 WITHDRAWAL 880
+Thread 0x30036350 DEPOSIT 307
+Thread 0x3004f088 DEPOSIT 601
+*** BALANCE: 10318
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/cecil-samples/index.wiki b/documentation/current/solutions/other-languages/cecil/cecil-samples/index.wiki
new file mode 100644
index 00000000..994188a4
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/cecil-samples/index.wiki
@@ -0,0 +1,13 @@
+[[Property:title|CECIL samples]]
+[[Property:weight|5]]
+Before trying the examples, please take a moment and look at the [[CECIL - How to compile the samples?|description]] that will explain how to compile the CECIL samples.
+
+Available samples include:
+* [[CECIL - C to Eiffel|C to Eiffel]]
+* [[CECIL - Eiffel to C|Eiffel to C]]
+* [[CECIL - Basic sample|Basic CECIL sample]]
+* [[CECIL - Threads|Threads]]
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/compiling-eiffel-system-cecil.wiki b/documentation/current/solutions/other-languages/cecil/compiling-eiffel-system-cecil.wiki
new file mode 100644
index 00000000..dbfb4a1d
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/compiling-eiffel-system-cecil.wiki
@@ -0,0 +1,31 @@
+[[Property:title|Compiling an Eiffel system for CECIL]]
+[[Property:weight|1]]
+==Compiling your Eiffel system for CECIL==
+It is very simple to "Cecilize" your Eiffel system, that is to say make its features available from the outside through CECIL. You will compile it as you normally would - either freeze it or finalize it. The only supplementary precaution is to protect from the dead-code remover any Eiffel features that are not called from the Eiffel system's root, and might thus be dead-code-removed by the optimization mechanism.
+To do this, make the appropriate features and classes [[Group Options|visible]] .
+
+==Building a CECIL archive==
+The EiffelStudio compiler produces both C code and a "Makefile". The Makefile compiles and links that C code in a subdirectory one level below the EIFGENs directory of a project. For frozen/melted code, the Makefile is located in the W_code subdirectory. For finalized code, it is in the F_code subdirectory.
+To produce a CECIL library, you must: open a shell (unix) or the MS-DOS prompt (Windows), go to the subdirectory that contains the Makefile, and then type:
+
+ '''make cecil''' (on unix and on windows with Borland)'''
+ nmake cecil''' (on windows with VC++)
+
+This generates a CECIL archive whose name derived from the name system name of the Eiffel system, as follows:
+
+ lib.a (on unix)
+ lib.lib (on Windows)
+For example, the corresponding archive for an Eiffel system called "test", would be called either "libtest.a" (Unix) or "libtest.lib" (Windows).
+Note that through CECIL you can use an Eiffel system compiled in any of the Eiffel compilation modes:
+* Finalized C code.
+* Workbench (melted/frozen) code, usually for development purposes. In this case you must copy the ''.melted'' file ( where '''' is the name of your system) located in EIFGENs\\W_code to the directory where you intend to execute your C application from.
+
+{{note| '''Note''': each time you melt the Eiffel system, the ''. melted'' file is updated. }}
+
+{{warning| '''Caution''': in the second case (workbench mode), it is not possible to call through the CECIL interface any routine that has been melted in the last compilation; this would raise the run-time exception:
+''' $ applied to melted routine'''
+The solution is simply to refreeze the system. }}
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/index.wiki b/documentation/current/solutions/other-languages/cecil/index.wiki
new file mode 100644
index 00000000..0db61bd9
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|CECIL]]
+[[Property:weight|3]]
+* [[CECIL: Introduction|Introduction]]
+* [[Compiling an Eiffel system for CECIL|Compiling an Eiffel system for CECIL]]
+* [[Using a CECIL archive|Using a CECIL archive]]
+* [[CECIL interface overview|CECIL interface overview]]
+* [[CECIL Reference|CECIL man pages]]
+* [[CECIL samples|CECIL examples]]
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/cecil/using-cecil-archive.wiki b/documentation/current/solutions/other-languages/cecil/using-cecil-archive.wiki
new file mode 100644
index 00000000..52005293
--- /dev/null
+++ b/documentation/current/solutions/other-languages/cecil/using-cecil-archive.wiki
@@ -0,0 +1,70 @@
+[[Property:title|Using a CECIL archive]]
+[[Property:weight|2]]
+==Linking the CECIL archive into a program==
+The CECIL archive already incorporates the Eiffel run-time. To use the functions provided in the CECIL archive, simply write the C programs according to the CECIL specifications of ETL, and then include the CECIL archive in the link line of your C application. This line looks like:
+on Unix/linux:
+ld -o [name of your CECIL executable] [your C object files and archives]lib.a -lm
+
+{{note| '''Note''': On Unix, linking with "-lm" is required since the Eiffel run-time uses the standard math libraries. You may need to link with other libraries (for example, on linux: with "-lbsd", in MT mode with "-lpthread" (posix threads) or "-lthread" (solaris)). }}
+
+
+
+on Windows, with MS VC++:
+link [your link flags] -OUT:[name of your cecil executable] [your C object files and archives] lib.lib [other Windows libraries]
+
+
+
+on Windows with Borland:
+ilink32 -ap -c -Tpe main.obj c0w32.obj, [name of your cecil executable],,EIFGENs\target_name\W_code\lib.lib CW32 IMPORT32 OLE2w32,,
+
+
+
+'''Notes for compiling CECIL C files:'''
+The CECIL library is built automatically, which is unfortunately not the case of the corresponding object files of the cecil program you wrote.
+The C flags to use are usually the same as the ones needed during the compilation of the generated C-code plus those which are relevant to your own C-code.
+
+Typically, you will compile with your flags as below (if you are using gcc):
+gcc -c -O -I$ISE_EIFFEL/studio/spec/$PLATFORM/include -I -D your_file.c
+
+or , if you are on Windows using MS VC++:
+cl -c -nologo -Ox -I$ISE_EIFFEL\studio\spec\windows\include -I -D your_file.c
+
+or, if you are on Windows using Borland:
+bcc32 -c -I$ISE_EIFFEL\studio\spec\windows\include -I -D your_file.c
+
+{{sample| '''Sample''': if you want to use the multithreaded facilities of Eiffel, you should define the EIFFEL MT flags by adding "-DEIF_THREADS" to the command line and follow the instructions of your C compiler and platform to find out which additional flags you may need '''. For example:''' on Solaris you need to add "-DSOLARIS_THREADS -D_REENTRANT". }}
+
+You can specify a Makefile in your configuration file, so that your C files will be compiled automatically after the Eiffel compilation and before the final linking. See [[Externals Options|the manipulation of external]] in the project settings to add $PATH_TO_MAKEFILE/your_makefile.
+
+This makefile will be run from the $/EIFGENs/target_name/W_code or $/EIFGENs/target_name/F_code directory. You should not give the CECIL executable the same name as your system, because it will be replaced by the Eiffel executable when you run another compilation.
+
+==Initializing the Eiffel run-time==
+Even though the main thread of control resides in the "C side" of the program, the Eiffel run-time must be initialized correctly before it can use CECIL facilities to communicate with the Eiffel world.
+In the C file containing the "main" C function, you must add the following line to include the header file "eif_setup. h" provided with this example:
+
+#include "eif_setup.h" /* Macros EIF_INITIALIZE and EIF_DISPOSE_ALL */
+#include "eif_eiffel.h" /* Exported functions of the Eiffel run-time */
+
+Your "main" function must have the three standard arguments of the C "main" function: "argc", "argv" and "envp" and include the following macros that are defined in "eif_setup. h":
+
+int main(int argc, char **argv, char **envp)
+ /* Please respect this signature: `argc', `argv' and `envp' are used * in EIF_INITIALIZE. */
+{
+ /* declarations of variables */
+ /* Initialize the Eiffel run-time. */
+ EIF_INITIALIZE(failure)
+
+/* body of your "main" function */
+
+ /* Reclaim the memory allocated by the Eiffel run-time. */
+EIF_DISPOSE_ALL
+}
+
+{{note| '''Notes''':
+The above mentioned macros must imperatively be in the body of the "main" function for the Eiffel exception handling mechanism to work correctly. You also need to add the Eiffel run time directory to the list of directories in which the C compiler searches for include files. You can do so by using the "-I" option of your C compiler. You can only link one CECIL library into your C applications at a time. }}
+
+{{warning| '''Caution''': Even though external object files and archives are correctly specified in the "object" clause of the configuration file, you will need to explicitly link them to your C application. }}
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki
new file mode 100644
index 00000000..bd6aa7e5
--- /dev/null
+++ b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki
@@ -0,0 +1,301 @@
+[[Property:title|C++ Externals]]
+[[Property:weight|2]]
+==Introduction==
+
+Before making C++ calls in EiffelStudio, you may want to learn the basics of making [[C externals|C calls]] , since these basics are not repeated here but they might be useful for C++ users as well and are necessary to fully benefit from this document.
+
+==Overview==
+
+Eiffel software must interact with software written in other languages. In this document you will learn about how to incorporate C++ classes in your Eiffel software.
+
+The C++/Eiffel interface offers the following mechanisms:
+* You can create instances of C++ classes from Eiffel, using the C++ "constructor" of your choice.
+* You can apply to these objects all the corresponding operations from the C++ class: executing functions ("methods"), accessing data members, executing destructors.
+* On Windows, you can use the Legacy++ tool to produce an Eiffel "wrapper class" encapsulating all the features of a C++ class, so that the result will look to the rest of the Eiffel software as if it had been written in Eiffel.
+
+The discussion concentrates on using C++ software from Eiffel. In the other direction, you can use [[CECIL: Introduction|the Cecil library (C-Eiffel Call-In Library)]] .
+
+==Syntax specification==
+
+In the following specification, the syntax for External and External_name is retained unchanged from ''Eiffel: The Language'', where Language_name is defined simply as Manifest_string; the rest covers the additional facilities.
+
+External == external Language_name [External_name]
+
+Language_name ==
+ '"'
+ Basic_language_name
+ [Special_external_declaration]
+ [Signature]
+ [Include_files]
+ '"'
+
+Basic_language_name == "C" | "C++"
+
+Special_external_declaration == "[" Special_feature "]"
+
+Special_feature == Special_C_feature | Special_C++_feature
+
+Special_C_feature == -- .... See appendix E of Eiffel: The Language...
+
+Special_C++_feature ==
+ Member_function_call|
+ Static_function_call |
+ Object_creation |
+ Object_deletion |
+ Data_member_access |
+
+Member_function_call == C++_Class
+
+C++_Class == Class_name File_name
+
+Class_name == Identifier
+
+Static_function_call == static C++_Class
+
+Object_creation == new C++_Class
+
+Object_deletion == delete C++_Class
+
+Data_member_access == data_member C++_Class
+
+ -- The remaining elements are repeated
+ -- from the C interface specification (page 291 in Eiffel: The Environment).
+
+File_name == User_file_name | System_file_name
+
+User_file_name == '%"' Manifest string '%"'
+
+System_file_name == "<" Manifest_string ">"
+
+Signature == "(" Type_list ")" [Result_type]
+
+Type_list == {Type "," ...}
+
+Result_type == ":" Type
+
+Include_files == "|" File_list
+
+File_list == {File_name "," ...}
+
+External_name == alias Manifest_string
+
+
+
+As with the C extensions of the previous appendix, the syntax description conventions are those of ''Eiffel: The Language''. == means "is defined as". The vertical bar | separates alternative choices, such as the three possibilities for Special_feature. The brackets [...] enclose optional components; for example a Language_name is made of required quotes, a required Basic_language_name and three further components, any or all of which may be absent. The notation {Element Separator ...} means: 0 or more occurrences ("specimens") of Element separated, if more than one, by Separator.
+
+Several of the symbols of the syntax notation, such as the brackets or the vertical bar, also appear in the language; to avoid any confusion they are given in double quotes. For example the specification for Include_files begins with "|" to indicate that an Include_files part starts with a vertical bar. Single quotes may be used instead of double quotes when one of the quoted characters is itself a double quote; for example '%"' appearing in the production for User_file_name denotes the percent character followed by the double quote character. Special words such as '''static''' in bold italics stand for themselves, unquoted.
+
+==Available possibilities==
+
+===Processing C++ features===
+
+A Special_C++_feature, if present, indicates one of the following, all illustrated by examples in the next sections:
+* If the special feature's declaration simply starts with a C++ class name, followed by the associated file name, it indicates that the Eiffel feature will call a C++ member function (also known as a "method") from that class. The name of the member function is by default the same as the name of the Eiffel feature; as usual, you can specify a different name through the alias clause of the external declaration.
+* If the declaration starts with static, it indicates a call to a C++ static function.
+* If the declaration starts with new, it indicates a call to one of the constructors in the C++ class, which will create a new instance of that class and apply to it the corresponding constructor function.
+* If the declaration starts with delete, it indicates a call to a destructor from the C++ class. In this case the Eiffel class may inherit [[ref:/libraries/base/reference/memory_chart|MEMORY]] and redefine the dispose procedure to execute the destructor operations whenever the Eiffel objects are garbage-collected.
+* If the declaration starts with data_member, it indicates access to a data member (attribute in Eiffel terminology) from the C++ class.
+
+The rest of the possible components are the same as in the C interface: Signature to specify types for arguments and results; possible Include file.
+
+===Extra argument===
+
+For a non-static C++ member function or destructor, the corresponding Eiffel feature should include an extra argument of type POINTER, at the first position. This argument represents the C++ object to which the function will be applied.
+
+For example, a C++ function
+void add(int new_int);
+
+should have the Eiffel counterpart
+
+ cpp_add (obj: POINTER; new_int: INTEGER) is
+ -- Encapsulation of member function add.
+ external
+ "C++ [IntArray %"intarray.h%"] (IntArray *, int)"
+ end
+
+This scheme, however, is often inconvenient because it forces the Eiffel side to work on objects in a non-object-oriented way. (The object-oriented way treats the current object, within a class, as implicit.) A better approach, used by Legacy++, is to make a feature such as cpp_add secret, and to export a feature whose signature corresponds to that of the original C++ function, with no extra object argument; that feature will use a secret attribute object_ptr to access the object. In the example this will give the feature
+
+ add (new_int: INTEGER) is
+ -- Encapsulation of member function add.
+ do
+ cpp_add (object_ptr, new_int)
+ end
+
+
+where ''object_ptr'' is a secret attribute of type POINTER, initialized by the creation procedures of the class. To the Eiffel developer, add looks like a normal object-oriented feature, which takes only the expected argument. Further examples appear below. This technique only works of course when the C++ object is implicit in the context of the Eiffel class.
+
+There is no need for an extra argument in the case of static member functions and constructors.
+
+==Wrapping C++ classes: Legacy++==
+
+Before taking a look at examples of the various facilities mentioned, it is useful to consider the tool that will help you, in many cases, avoid worrying about their details.
+
+===The role of Legacy++===
+
+Often you will want to provide an Eiffel encapsulation of all the facilities -- member functions, static functions, constructors, destructors, data members -- of a C++ class. This means producing an Eiffel class that will provide an Eiffel feature for each one of these C++ facilities, using external declarations based on the mechanisms listed in the preceding section.
+
+Rather than writing these external declarations and the class structure manually, you can use the Legacy++ tool to produce the Eiffel class automatically from the C++ class.
+
+===Calling Legacy++===
+
+Legacy++ is called with an argument denoting a ''.h'' file that must contain C++ code: one or more classes and structure declarations. It will translate these declarations into Eiffel wrapper classes. Legacy++ is only available on Windows. It is located in the $ISE_EIFFEL\studio\spec\windows\bin directory, under the name legacy.exe.
+
+The following options are available:
+* '''-E''': apply the C preprocessor to the file, so that it will process #include, #define, #ifdef and other preprocessor directives. This is in fact the default, so that you do not need to specify -E explicitly (see next option).
+* '''-NE''': do not apply the C preprocessor to the file.
+* '''-p''' ''directories'': use ''directories'' as include path.
+* '''-c''' ''compiler'': use ''compiler'' as the C++ compiler.
+* '''-g''': treat the C++ code as being intended for the GNU C++ compiler.
+
+===Result of applying Legacy++===
+
+Running Legacy++ on a C++ file will produce the corresponding Eiffel classes. Legacy++ processes not only C++ classes but also C++ "structs"; in both cases it will generate an Eiffel class.
+
+Legacy++ knows about default specifiers: public for structs, private for classes.
+
+Legacy++ will generate Eiffel features for member functions (static or not).
+
+It will also handle any constructors and destructors given in the C++ code, yielding the corresponding Eiffel creation procedures. If there is no explicit constructor, it will produce a creation procedure with no arguments and an empty body.
+
+For any non-static member function or destructor, Legacy++ will generate a secret feature with an extra argument representing the object, as explained in the preceding section in this page. It will also produce a public feature with the same number of arguments as the C++ function, relying on a call to the secret feature, as illustrated for add and cpp_add above.
+
+The char* type is translated into STRING. Pointer types, as well as reference types corresponding to classes and types that Legacy++ has processed, will be translated into POINTER. Other types will yield the type UNRESOLVED_TYPE.
+
+===Legacy++ limitations===
+
+It is up to you to supply Eiffel equivalents of all the needed types. If Legacy++ encounters the name of a C++ class or type that it does not know -- i.e. it is neither a predefined type nor a previously translated class -- it will use the Eiffel type name UNRESOLVED_TYPE. If you do not change that type in the generated class, the Eiffel compiler will produce an error (unknown class) at degree 5.
+
+Legacy++ does not handle inline function declarations.
+
+Legacy++ does not handle C++ templates.
+
+Legacy++ makes no effort to understand the C++ inheritance structure.
+
+More generally, given the differences in the semantic models of C++ and Eiffel, Legacy++ can only perform the basic Eiffel wrapping of a C++ class, rather than a full translation. You should always inspect the result and be prepared to adapt it manually.
+
+Legacy++'s contribution is to take care of the bulk of the work, in particular the tedious and repetitive parts. The final details are left to the Eiffel software developer.
+
+Legacy++ is only supported on the windows platform.
+
+==Example==
+
+Consider the following C++ class, which has an example of every kind of facility that one may wish to access from the Eiffel side:
+
+class IntArray {
+ public:
+ IntArray(int size);
+ ~IntArray();
+ void output();
+ void add(int new_int);
+ static char * type();
+
+ protected:
+ int *_integers;
+};
+
+
+Here is the result of applying Legacy++ to that class, which will serve as an illustration of both the C++ interface mechanisms and Legacy++:
+
+indexing
+ description: "Eiffel encapsulation of C++ class IntArray";
+ date: "$Date: 2006-10-12 03:18:50 +0200 (Thu, 12 Oct 2006) $";
+ revision: "$Revision: 64319 $"
+
+class
+ INTARRAY
+
+inherit
+ MEMORY
+ redefine
+ dispose
+ end
+
+create
+ make
+
+feature -- Initialization
+
+ make (size: INTEGER) is
+ -- Create Eiffel and C++ objects.
+ do
+ object_ptr := cpp_new (size)
+ end
+
+feature-- Removal
+
+ dispose is
+ -- Delete C++ object.
+ do
+ cpp_delete (object_ptr)
+ end
+
+feature
+
+ output is
+ -- Call C++ counterpart.
+ do
+ cpp_output (object_ptr)
+ end
+
+ add (new_int: INTEGER) is
+ -- Call C++ counterpart.
+ do
+ cpp_add (object_ptr, new_int)
+ end
+
+feature {INTARRAY}
+
+ underscore_integers: POINTER is
+ -- Value of corresponding C++ data member.
+ do
+ Result := underscore_integers (object_ptr)
+ end
+
+feature {NONE} -- Externals
+
+ cpp_new (size: INTEGER): POINTER is
+ -- Call single constructor of C++ class.
+ external
+ "C++ [new IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
+ end
+
+ cpp_delete (cpp_obj: POINTER) is
+ -- Call C++ destructor on C++ object.
+ external
+ "C++ [delete IntArray %"INTARRAY.H%"] ()"
+ end
+
+ cpp_output (cpp_obj: POINTER) is
+ -- Call C++ member function.
+ external
+ "C++ [IntArray %"INTARRAY.H%"] ()"
+ alias
+ "output"
+ end
+
+ cpp_add (cpp_obj: POINTER; new_int: INTEGER) is
+ -- Call C++ member function.
+ external
+ "C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
+ alias
+ "add"
+ end
+
+ cpp_underscore_integers (cpp_obj: POINTER): POINTER is
+ -- Value of C++ data member
+ external
+ "C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER"
+ alias
+ "_integers"
+ end
+
+feature {NONE} -- Implementation
+
+ object_ptr: POINTER
+
+end -- class INTARRAY
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki
new file mode 100644
index 00000000..992a9f36
--- /dev/null
+++ b/documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki
@@ -0,0 +1,197 @@
+[[Property:title|C externals]]
+[[Property:weight|1]]
+==General consideration==
+
+As Eiffel Software's technology relies heavily on the use of a C/C++ ANSI compiler, you have to be sure to always put the correct signature of an external C/C++ routine. If it was not the case, the C compilation of your system could fail. Most of the time a C compiler is more comprehensive than a C++ compiler and most type errors won't cause you any harm, but C++ compilers are not as lax as C compilers and they will mostly generate errors.
+
+The sections concerning [[#macros|Macros]] and [[#structs|Structs]] are also available for C++ if the macro or the struct is defined in a C++ header file.
+
+==C routines==
+
+You can encapsulate routines that are defined in a C header file. We will take some examples and will show you how to write wrappers in Eiffel.
+
+If in a header file called `my_header.h', you have the following declaration:
+
+ /* Routine with no parameter */
+extern void no_param(void);
+
+ /* Routine with one parameter */
+extern void one_param(int j);
+
+ /* Routine returning a value with no parameter */
+extern size_t no_param_return(void);
+
+ /* Routine returning a value with one parameter */
+extern size_t one_param_return(FILE *f);
+
+Here is the corresponding Eiffel code:
+
+ c_no_param is
+ -- Encapsulation of a C routine with no parameter.
+ external
+ "C | %"my_header.h%""
+ alias
+ "no_param"
+ end
+
+ c_one_param (i: INTEGER) is
+ -- Encapsulation of a C routine with one parameter.
+ external
+ "C (int) | %"my_header.h%""
+ alias
+ "one_param"
+ end
+
+ c_no_param_return: INTEGER is
+ -- Encapsulation of a C routine with no parameter
+ -- returning an INTEGER
+ external
+ "C (): EIF_INTEGER| %"my_header.h%""
+ alias
+ "no_param_return"
+ end
+
+ c_one_param_return (p: POINTER): INTEGER is
+ -- Encapsulation of a C routine with one parameter
+ -- returning an INTEGER
+ external
+ "C (FILE *): EIF_INTEGER| %"my_header.h%""
+ alias
+ "one_param_return"
+ end
+
+==Macros==
+
+If in a header file called `my_header.h', you have the following declaration:
+
+ /* Predefined constants */
+#define ID_MENU 128
+#define ID_MENU_CHARACTER 'c'
+
+ /* Access the `i'-th element of `a' where `a' * is an array of EIF_INTEGER */
+#define i_th(a,i)((a) + (i)*sizeof(EIF_INTEGER))
+
+Then, the corresponding Eiffel code will look like:
+
+ menu_id: INTEGER is
+ -- `ID_MENU' C encapsulation.
+ external
+ "C [macro %"my_header.h%"] : EIF_INTEGER"
+ alias
+ "ID_MENU"
+ end
+
+ menu_id_character: CHARACTER is
+ -- `ID_MENU_CHARACTER' C encapsulation.
+ external
+ "C [macro %"my_header.h%"] : EIF_CHARACTER"
+ alias
+ "ID_MENU_CHARACTER"
+ end
+
+ i_th (p: POINTER; i: INTEGER): INTEGER is
+ -- Access the `i'-th element of `p', array of C EIF_INTEGER.
+ external
+ "C [macro %"my_header.h%"] (EIF_INTEGER *, EIF_INTEGER): EIF_INTEGER"
+ alias
+ "i_th"
+ end
+
+==Structs==
+
+The struct encapsulation enables you to wrap C/C++ structures easily without having to write any additional code in a C header file as it was the case until Eiffel Software introduced this new keyword in the external specification with the 4.5 release of the Eiffel Software environment. With the struct encapsulation you can set and retrieve the value of a certain field of a struct.
+
+If in a header file called `my_header.h', you have the following declaration of the `Point' structure whose `x' and `y' fields we want to access and set:
+
+ /* Definition of `Point' */
+typdef struct point {
+ int x;
+ int y;
+} Point;
+
+Then, the corresponding Eiffel code will look like:
+
+ x (p: POINTER): INTEGER is
+ -- Access field x of struct pointed by `p'.
+ external
+ "C [struct %"my_header.h%"] (Point): EIF_INTEGER"
+ alias
+ "x"
+ end
+
+ y (p: POINTER): INTEGER is
+ -- Access field y of struct pointed by `p'.
+ external
+ "C [struct %"my_header.h%"] (Point): EIF_INTEGER"
+ alias
+ "y"
+ end
+
+ set_x (p: POINTER; v: INTEGER) is
+ -- Set field x of struct pointed by `p'.
+ external
+ "C [struct %"my_header.h%"] (Point, int)"
+ alias
+ "x"
+ end
+
+ set_y (p: POINTER: v: INTEGER) is
+ -- Set field y of struct pointed by `p' with `v'.
+ external
+ "C [struct %"my_header.h%"] (Point, int)"
+ alias
+ "y"
+ end
+
+==Windows externals==
+
+===DLLs===
+
+With EiffelStudio you now have two different ways to call C routines exported in a DLL. Why two, because Windows provides two ways to call a C routine in a DLL:
+* _cdecl: referred to as the standard way
+* __stdcall referred to as the Pascal way
+
+Therefore if you want to call an external routine defined in a DLL supposed to be called using the `_cdecl' method, you have to use the '''dll32''' sub-language option. For `__stdcall' you need to use the '''dllwin32''' sub-language option. Here is an example:
+
+ my_cdecl_routine (a: INTEGER): POINTER is
+ -- Encapsulation of a dll function with the `_cdecl' call mechanism.
+ external
+ "C [dll32 %"my_dll.dll%"] (int): EIF_POINTER"
+ end
+
+ my_stdcall_routine (a: INTEGER): POINTER is
+ -- Encapsulation of a dll function with the `_stdcall' call mechanism.
+ external
+ "C [dllwin32 %"my_dll.dll%"] (int): EIF_POINTER"
+ end
+
+{{warning| '''Caution''': Using wrongly '''dll32''' instead of '''dllwin32''' and reciprocally will conduce to a crash of your system since the C call stack will be corrupted. For more information please read your C compiler documentation. }}
+
+===Windows API===
+
+As described in the previous section concerning routines exported in a DLL, the Windows API is using the `__stdcall' convention. As a consequence, you cannot use the standard external mechanism to wrap them because it is using the `_cdecl' convention. However, you can easily wrap those function by using the '''macro''' sub-language.
+
+Here is an example that has been taken from WEL, the Windows Eiffel Library, to encapsulate the Windows `SendMessage' function:
+Windows defined SendMessage as:
+LRESULT SendMessage(
+ HWND hWnd, // handle to destination window
+ UINT Msg, // message
+ WPARAM wParam, // first message parameter
+ LPARAM lParam // second message parameter
+);
+In WEL, the encapsulation is written as:
+
+ cwin_send_message (hwnd: POINTER; msg, wparam, param: INTEGER) is
+ -- SDK SendMessage (without the result)
+ external
+ "C [macro %"wel.h%"] (HWND, UINT, WPARAM, LPARAM)"
+ alias
+ "SendMessage"
+ end
+
+{{seealso| '''See also'''
+[[C++ Externals|C++ externals]] }}
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki
new file mode 100644
index 00000000..25f3a1cc
--- /dev/null
+++ b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki
@@ -0,0 +1,100 @@
+[[Property:title|Eiffel2Java Sample]]
+[[Property:weight|1]]
+This example shows how to create an instance of the Java Virtual Machine and the creation of an object of type test, a java class reproduced below:
+
+(Java Code)
+
+class test
+{
+ test ()
+ {
+ my_integer = 10;
+ }
+
+ public int my_integer;
+ public static int my_static_integer;
+ public void my_method (int arg_int, String arg_string)
+ {
+ my_static_integer = arg_int;
+ my_integer = arg_int;
+ }
+}
+
+
+In order to run properly you need to read [[Eiffel2Java|the library requirement]] .
+
+===Compiling the example===
+
+Since the example is using the `test.java' class, the first step is to compile the java class using the `javac' command line utility from the JDK. Once it is done, copy the `test.class' either in $ISE_EIFFEL\examples\Eiffel2Java\EIFGENs\classic\W_code or in $ISE_EIFFEL\examples\Eiffel2Java\EIFGENs\classic\F_code depending on your compilation mode (freezing vs. finalizing).
+
+===Running the example===
+
+One the example is compiled, you can run it and here is the expected output:
+$ sample
+Creating instance of class `test'
+Value of `my_integer' is 10
+Value of `my_static_integer' is 0
+Calling `my_method' with (2, "String test")
+Value of `my_integer' after call to `my_method' is 2
+
+===Code description===
+(Eiffel Code)
+
+class
+ EIFFEL_TO_JAVA
+inherit
+ SHARED_JNI_ENVIRONMENT
+
+create
+ make
+
+feature -- Creation
+
+ make is
+ local
+ class_test: JAVA_CLASS
+ instance_of_class_test: JAVA_OBJECT
+ fid: POINTER
+ value: INTEGER
+ j_args: JAVA_ARGS
+ do
+ --| Creation of the Java object
+ class_test := jni.find_class ("test")
+ create instance_of_class_test.create_instance (class_test, "()V", Void)
+
+ --| Access to a public attribute
+ fid := instance_of_class_test.field_id ("my_integer", "I")
+
+ -- 'fid' contains the id of the field 'my_integer'
+ -- 'value' contains the value of the field referenced
+ -- by 'fid'
+
+ value := instance_of_class_test.integer_attribute (fid)
+
+ --| Access to a static attribute using directly the JAVA_CLASS
+ fid := class_test.field_id ("my_static_integer", "I")
+ value := class_test.integer_attribute (fid) ...
+
+ --| Access to a static attribute using the attribute 'jclass'
+ fid := instance_of_class_test.jclass.field_id ("my_static_integer", "I")
+ value := instance_of_class_test.jclass.integer_attribute (fid)
+
+ --| Access to the method 'my_method'
+ -- Get the id of 'my_method'
+ fid := instance_of_class_test.method_id ("my_method", "(ILjava/lang/String;)V")
+
+ -- Create the set of arguments for 'my_method'
+ create j_args.make(2)
+ j_args.push_int (2)
+ j_args.push_string("String test")
+
+ -- Create the set of arguments for 'my_method'
+ -- Call to the void method referenced by 'fid'
+ instance_of_class_test.void_method (fid, j_args)
+ end -- make
+
+end -- class EIFFEL_TO_JAVA
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki
new file mode 100644
index 00000000..067b59ab
--- /dev/null
+++ b/documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki
@@ -0,0 +1,163 @@
+[[Property:title|Eiffel to Java Interface]]
+[[Property:link_title|Eiffel2Java Tutorial]]
+[[Property:weight|0]]
+==Introduction==
+
+The Java interface allows you to call Java routines or attributes from your Eiffel code. It uses the Java Native Interface (JNI) provided by the Java Development Kit (JDK). You can get more information about the JNI at:
+
+[http://java.sun.com/j2se/1.5.0/docs/guide/jni/ http://java.sun.com/j2se/1.5.0/docs/guide/jni/]
+
+===Requirements===
+* JDK 1.1.8 or newer should be correctly set up (download it at [http://java.sun.com/javase/downloads/index.jsp http://java.sun.com/javase/downloads/index.jsp] )
+* The environment variable CLASSPATH should defined (check with the JDK documentation on how to do so) and that it contains the Java classes you want to access.
+* The environment variables should be setup correctly. See $ISE_EIFFEL\library\Eiffel2Java\README.txt for information how to do this..
+
+===Borland users===
+
+On Windows, the JDK includes a set of C libraries which have been compiled for the Microsoft C compiler. Before being able to use the JDK from Eiffel you need to perform the following operation:
+# In $JDK_HOME\lib, rename javai.lib into javai.lib.microsoft
+# From the DOS command prompt and in the directory $JDK_HOME\lib, launch the following command
+%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll
+
+
+===Limitations===
+* In this version, you can only use one JNI environment.
+* Only one thread can interact with the Java Virtual Machine (JVM).
+* It is not possible to call Eiffel features from Java program.
+* The Eiffel feature `destroy_vm' of `JAVA_VM' calls a C function of the Java NativeInterface that is not fully implemented in jdk 1.1.8. This function, called DestroyJavaVM, always returns -1 in jdk 1.1.8. For further information, go on the JNI pages at the address above.
+
+==Interface classes==
+
+===JNI_ENVIRONMENT===
+
+Holds information about JNI environment. Potentially many JNI environments can exists at once, but more than one was never tested. This class provide the facilities to interact with the JVM:
+* creation of instances of Java Classes
+* exceptions mechanism
+* destruction of the JVM
+
+===SHARED_JNI_ENVIRONMENT===
+
+Shared JNI environment. Since one JNI is needed per thread we limit Eiffel to having one thread that deals with Java. The class that calls Java routines or attributes must inherit from this class.
+
+===JAVA_VM===
+
+This class is used to initially load the JVM into the running program. This is the Eiffel representation of the JVM.
+
+===JAVA_CLASS===
+
+Access to Java classes. Static methods and attributes are accessed via this class.This is the Eiffel representation of a Java Class.
+
+===JAVA_OBJECT===
+
+This class gives Eiffel access to Java objects. You can use it directly or inherit from to and create a more convenient Eiffel class that makes the Java object look like an Eiffel object. The Eiffel representation of a Java Object.
+
+{{warning| '''Warning:''' to access the static fields or routines of a Java Class, you have to use the features of a JAVA_CLASS instance!! }}
+
+===JAVA_EXTERNALS===
+
+JNI external declarations. Don't use this class directly.
+
+===JAVA_***_ARRAY===
+
+Access to Java array of "***". "***" can be all the usual types of Java (byte, short, int, float, double, char, boolean) or object if it is an array of Java Object (a String is considered as an object)
+
+===JAVA_ARGS===
+
+Class representing the arguments that can be passed to a Java method. See below about the signature of the methods
+
+===JAVA_OBJECT_TABLE===
+
+This class provides a mapping between Java and Eiffel objects
+
+'''Mapping the Eiffel classes and the Java types:'''
+The following table describes the mapping of Java primitive types and classes to Eiffel classes.
+{|
+|-
+| '''Java type/class'''
+| '''Eiffel class'''
+|-
+| boolean
+| BOOLEAN
+|-
+| char, byte
+| CHARACTER
+|-
+| short, int
+| INTEGER
+|-
+| long
+| INTEGER_64
+|-
+| float
+| REAL
+|-
+| double
+| DOUBLE
+|-
+| String
+| STRING
+|-
+| void
+| Void
+|}
+
+The interface does the mapping automatically. For example, if you call a Java method that returns a 'float', by using float_method you will get a REAL.
+
+'''The signature of Java methods and attributes:'''
+
+When you want to call a Java method or access a field, you need to specify its signature.The Eiffel to Java interface follows the JNI specifications. The table below summarizes the encoding for the Java type signatures:
+{|
+|-
+| '''Signature'''
+| '''Java Type'''
+|-
+| Z
+| boolean
+|-
+| B
+| byte
+|-
+| C
+| char
+|-
+| S
+| short
+|-
+| I
+| int
+|-
+| J
+| long
+|-
+| F
+| float
+|-
+| D
+| double
+|-
+| V
+| void
+|-
+| [type
+| type []
+|}
+
+The signature for a Java class has the following form:
+L fully-qualified-class;
+
+For example, class String:
+Ljava/lang/String;
+
+
+The signature for a method has the following form:
+(arguments-types) returned-types
+
+For example, the signature of a method that takes as arguments an integer and a string and return void is:
+(ILjava/lang/String;)V
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/other-languages/eiffel2java/index.wiki b/documentation/current/solutions/other-languages/eiffel2java/index.wiki
new file mode 100644
index 00000000..e9fc4c4e
--- /dev/null
+++ b/documentation/current/solutions/other-languages/eiffel2java/index.wiki
@@ -0,0 +1,15 @@
+[[Property:title|Eiffel2Java]]
+[[Property:weight|4]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[Eiffel to Java Interface|Content]]
+* [[Eiffel2Java Sample|Samples]]
+* [[ref:libraries/eiffel2java/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/solutions/porting-instructions/index.wiki b/documentation/current/solutions/porting-instructions/index.wiki
new file mode 100644
index 00000000..4febc689
--- /dev/null
+++ b/documentation/current/solutions/porting-instructions/index.wiki
@@ -0,0 +1,9 @@
+[[Property:title|Porting Instructions]]
+[[Property:link_title|Porting instructions]]
+[[Property:weight|-11]]
+=Porting from one platform to another=
+* [[Porting an Eiffel application from UNIX to Windows or vice-versa|Porting from traditional Windows to UNIX and vice-versa. ]]
+
+
+
+
diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki
new file mode 100644
index 00000000..9da48cd5
--- /dev/null
+++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki
@@ -0,0 +1,11 @@
+[[Property:title|Preference Library]]
+[[Property:link_title|EiffelPreferences Tutorial]]
+[[Property:weight|0]]
+The preference library is a platform independent library that can be used to add preference and configuration settings to your application. Briefly, the library provides support for creating fully configurable preference values, on per application or per user basis. It also provides a graphical interface for manipulation of these values, and a easily extendible design for you to add your own custom preference types.
+* [[Overview|Overview]]
+* [[Initialization|Initialization]]
+* [[Interface for preferences|Graphical]]
+
+
+
+
diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki
new file mode 100644
index 00000000..4c5f8118
--- /dev/null
+++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki
@@ -0,0 +1,125 @@
+[[Property:title|Initialization]]
+[[Property:weight|1]]
+This document details how to setup preferences for your application.
+
+==Initializating the preferences==
+
+The first thing you must do to setup preferences for your application is create a PREFERENCES object. Ideally any access to preference information should be done through this object. There are 3 creation routines available to initialize the preferences:
+* make
+* make_with_location
+* make_with_defaults_and_location
+
+The first and most simple option ( make) will create a PREFERENCE object for you with no specific underlying datastore location, and no default preference values. In this scenario an underlying data store location will be created for you automatically based on the current system settings. For example, if you are using the Windows Registry as your data store, and your program is is called ''my_program.exe'', then a registry key will be created in ''HKEY_CURRENT_USER\Software\myprogram.exe''. In between user sessions the preference name-value pairs will be stored in this key location. This particular method of creating preferences is ideal if you are not particularly concerned where the values are stored, and if you do not need to specify any default values for the preferences. You may think of it as the "it just works" mode, and it is ideal for development and simple use.
+
+The second option ( make_with_location) will take a location value to use for the underlying data store. Values will be stored to and retrieved from this location between sessions. As with make no defaults values are provided.
+
+The final option make_with_defaults_and_location is similar to make_with_location except an additional parameter is given to retrieve one or more default file locations. This will be one or more XML files on disk containing the default values to use for some or all of your preferences. It is a convenient way to initialize your application with all the default values required `out of the box' for correct or preferred functioning. Those files also contain additional attributes for preference configuration such as more detailed descriptions of the preference. If two files list the same preference, the last one to mention it takes precedence.
+
+The format of the XML default file is very simple:
+
+ Value here
+ ...More preferences...
+
+
+The "HIDDEN" attribute indicates if this preference is to be hidden from view and is used for preferences that you do not wish for your users to modify or see. The "RESTART" attribute allows for you to flag that when a particular preference is changed it may be necessary to restart the application for the changes to take effect. You can handle this in your application by querying for this value in the preference and dispalying appropriate dialogs and messages for your application.
+
+==Managers==
+
+Once you have created a PREFERENCES object using one of the creation routines described above you will create a PREFERENCE_MANAGER to store related preference values. For example, if your application is a web browser control that has preferences for user favorites and also a user browsing history you could create 2 managers, one for the favorites and one for the history. It is not mandatory that you create 2 managers and you could just create one and have all preferences stored therein, but for reasons of management 2 would be better. Each separate manager must have a unique name to distinguish it from the other managers in the system. We may have one called "favorites" and one called "history".
+
+==Creating preferences==
+
+Now you have your preferences and at least one manager to put them in you can create the actual preferences. Preferences are generic, and all preferences inherit the class TYPED_PREFERENCE [G]. G denotes the type of the preference, for example INTEGER for a preference containing an integer value. Depending on the type you will use a factory class to actually create the new preference. By default the library supports 6 types of preferences, 4 basic type ones and 2 graphical types. The table below clearly indicates the currently available preferences and the factory class you should use to create them:
+{|
+|-
+| '''Preference type'''
+| '''Description'''
+| '''Factory class'''
+| '''Factory method'''
+|-
+| BOOLEAN_PREFERENCE
+| Stores boolean value (true or false)
+| BASIC_PREFERENCE_FACTORY
+| new_boolean_resource_value
+|-
+| INTEGER_PREFERENCE
+| Stores an integer value
+| BASIC_PREFERENCE_FACTORY
+| new_integer_resource_value
+|-
+| STRING_PREFERENCE
+| Stores a string value
+| BASIC_PREFERENCE_FACTORY
+| new_string_resource_value
+|-
+| ARRAY_PREFERENCE
+| Stores a list of string values
+| BASIC_PREFERENCE_FACTORY
+| new_array_resource_value
+|-
+| COLOR_PREFERENCE
+| Stores a color value (rgb)
+| GRAPHICAL_PREFERENCE_FACTORY
+| new_color_resource_value
+|-
+| FONT_PREFERENCE
+| Stores a font value (font name, face, height, etc)
+| GRAPHICAL_PREFERENCE_FACTORY
+| new_font_resource_value
+|}
+As you can see creating preferences is very easy. Also you will notice that color and font preferences use the GRAPHICAL_PREFERENCE_FACTORY. If you wish to use these preferences in your application you will need to use EiffelVision2 since these preference values are stored as EV_COLOR and EV_FONT types. If you wish to store preference value that are different to those offered by the 6 available preferences it also very easy to extend the design and add your own custom types. Simply inherit TYPED_PREFERENCE [G] and implement the deferred features for your specific preference. There is an example of this in the sample application.
+
+==Default Values==
+
+When you create a preference using a factory class you will provide a manager, a name for the preference, and a value. For example, in BASIC_PREFERENCE_FACTORY you create an integer preference by calling new_integer_resource_value:
+
+ new_integer_resource_value (a_manager: PREFERENCE_MANAGER; a_name: STRING; a_fallback_value: INTEGER): INTEGER_PREFERENCE is
+ -- Add a new integer resource with name `a_name'. If preference cannot be found in
+ -- underlying datastore or in a default values then `a_fallback_value' is used for the value.
+ require
+ name_valid: a_name /= Void
+ name_not_empty: not a_name.is_empty
+ not_has_resource: not a_manager.known_resource (a_name)
+ ensure
+ has_result: Result /= Void
+ resource_name_set: Result.name.is_equal (a_name)
+ resource_added: a_manager.preferences.has_resource (a_name)
+ end
+
+An appropriate example in code of this could be:
+
+
+window_width_preference: INTEGER_PREFERENCE
+ -- Preference holding value for width of application main window
+
+initialize_my_preferences is
+ -- Initialize the application preferences
+ local
+ factory: BASIC_PREFERENCE_FACTORY
+ do
+ create factory
+ window_width_preference := factory.new_integer_resource_value (my_manager, "window_width", 480)
+ end
+This will create a new preference, which you can then use in your application to get, set and save the corresponding value when necessary. The issue to be aware of here though involves the value that the preference will contain when it is created. You see in the code above we pass the integer value 480. '''This does not mean, however, the initial value of the preference will be 480'''. This may sound odd, so let me explain...
+The value of a preference when initialized is determined by a number of factors. The first of these is the underlying data store value. If a preference value was changed in a previous session, by the user or by the application directly, and was saved to the underlying data store, then this value will be given priority. This makes sense, since if a user changes their preferences they don't want to have to do it every time they use your program. So, if they want the default window width to be larger, say 600, then this will be the value of the preference named "window_width" when initialized next time. Following this, if there is no previously saved value then the library will look for a default value to use. If a default file was given when the preferences were created (see above), and this default specifies a default value of 240 for the integer preference called "window_width", then this will be used. Finally, if no preference value was previously stored ''and'' no value is provided as a default value then the supplied value in the code is used - our 480 value from the example above. Although this process may seem confusing it is infact very simple and intuitive way to initialze the preferences. The process chart below illustrates more clearly the various permutations.
+ [[Image:libraries/preferences/content/value_chart.png]]
+
+==Using and Manipulating Preferences==
+Now you have preferences created you may use them from your application. Using the example preference above, window_width_preference, you can query the value of the preferences by simply querying the preference directly:
+window_width := window_width_preference.value
+Or for a value which should always be associated to the preference:
+window_width: INTEGER is
+ -- Width of window
+ do
+ Result := window_width_preference.value
+ end
+If you need to react when a preference value is changed you can hook up an agent to the change_actions of the preference:
+window_width_preference.change_actions.extend (agent my_agent_routine)
+To manually set the value of the preference call set_value or set_value_from_string, and to set a value for the default value call set_default_value. To reset a preference value back to it's original default value use reset.
+To save the current preference to the underlying data store you must call save_resource on the PREFERENCES object. This will persist the value to the data store for retrieval in the next session. Remeber, if you change a preference value during execution and do not save it then the value will be lost when execution has finished. The preference window interface provided with the library will allow users to set theie own preference values and will save the values upon confirmation. However, if you re using preferences in your code and do not wish to provide an interface for preference modification you must remeber to manually save the preferences. You can save all preferences at once my calling save_resources in PREFERENCES, or individually with save_resource.
+
+
+
+
+
+
diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki
new file mode 100644
index 00000000..4a1d3501
--- /dev/null
+++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki
@@ -0,0 +1,40 @@
+[[Property:title|Interface for preferences]]
+[[Property:weight|2]]
+This document describes the use of graphical widgets to display and manipulate preferences.
+
+The preference library contains a cluster called interface. This cluster provides some basic classes which can be used to graphically display and manipulate the PREFERENCE types used by the library. There are various widget classes which correspond to particular types of preferences and can be used to view and change the values of an associated preference. The table below illustrates which widgets are used to display each of the known preference types:
+
+{|
+|-
+| '''Preference Type'''
+| '''Associated Widget'''
+|-
+| INTEGER_PREFERENCE
+| STRING_PREFERENCE_WIDGET
+|-
+| BOOLEAN_PREFERENCE
+| BOOLEAN_PREFERENCE_WIDGET
+|-
+| STRING_PREFERENCE
+| STRING_PREFERENCE_WIDGET
+|-
+| ARRAY_PREFERENCE
+| STRING_PREFERENCE_WIDGET or CHOICE_PREFERENCE_WIDGET
+|-
+| COLOR_PREFERENCE
+| COLOR_PREFERENCE_WIDGET
+|-
+| FONT_PREFERENCE
+| FONT_PREFERENCE_WIDGET
+|}
+
+All of these widgets inherit the abstract base class PREFERENCE_WIDGET and implement the required deferred features therein. Each implementation implements handling of an EV_GRID_ITEM widget from EiffelVision2 for use in the EV_GRID control, which allows for viewing and editing of the underlying preference value. For example, BOOLEAN_PREFERENCE_WIDGET uses an EV_GRID_COMBO_ITEM to display the 'True' and 'False' properties of a BOOLEAN_PREFERENCE. When the widget is loaded it displays the current value of the associated preference in the combo box. When the user changes the combo box value the preference value is changed also, and optionally saved.
+Using these supplied widgets in your interface is simply a matter of creating the object and adding the change_item_widget to an instance of EV_GRID. By default the library provides such a view, in the form of PREFERENCES_WINDOW, which is a control that contains an EV_GRID and has all the necessary logic to handle graphical manipulation of the prefernce types provided in the library. This is an EV_TITLED_WINDOW with a navigable tree for finding groups of related preferences (i.e. managers), and a grid for displaying each preference. It is a useful, general purpose interface for preference manipulation. As with preferences themselves you may create your own custom view if this dialog is not sufficient for your needs, and can use the code therein as a template for your owm code. Below is an image of the supplied window as it appears in the EiffelStudio preferences environment.
+
+[[Image:preference-window]]
+
+For an example of creating custom widget views for individual preferences, or a custom view for all preferences, please refer to the example in this documentation.
+
+
+
+
diff --git a/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki
new file mode 100644
index 00000000..3fbdae8a
--- /dev/null
+++ b/documentation/current/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki
@@ -0,0 +1,29 @@
+[[Property:title|Overview]]
+[[Property:weight|0]]
+This document gives a brief overview of the preference library.
+
+==Introduction==
+
+Simply, preferences are name-value pairs. All preferences are descendents of the deferred class PREFERENCE, and therefore all inherit the common properties of name, value, default values and string representations. Common to all PREFERENCE objects is the notion of `manager'. All preferences belong to a manager, which is a helper class used for organizational and hierarchical management of your applications preferences.
+
+So, all preferences belong to a PREFERENCE_MANAGER. The manager itself belongs to a set of related PREFERENCES. Infact, when you create a new manager for a group of preferences you must provide a PREFERENCES object to the creation routine to indicate which set of preferences the new manager will be associated:
+make (a_preferences: PREFERENCES; a_namespace: STRING) is
+ -- New manager.
+ require
+ preferences_not_void: a_preferences /= Void
+ namespace_not_void: a_namespace /= Void
+ namespace_not_empty: not a_namespace.is_empty
+ ensure
+ has_preferences: preferences /= Void
+ inserted_in_preferences: preferences.has_manager (namespace)
+ has_namespace: namespace /= Void
+ namesapce_valid: not a_namespace.is_empty
+ end
+
+You can see in the post-condition inserted_in_preferences that indeed the PREFERENCES object will have the new manager in its list of managers.
+
+For every group of preferences or configuration values you therefore wish to create for your project, you will need a corresponding PREFERENCES object. In general one PREFERENCE object should be sufficient for most applications, and will be the point of reference for all preference values in the entire application. This class may be initialized in a number of ways, depending on the specific configuration of your application. It will be used to create new managers, store default preference values, and handle the saving and retrieval of preference values to and from the underlying data store between sessions. In between sessions the preference name and value pairs are persisted to an underlying data store. This may be any imaginable datastore, such as a file, database or external storage device. Support for XML and the Windows Registry is provided in the library by default, but it would not be be too difficult to provide an implementation for your needs (such as SQL database store).
+
+
+
+
diff --git a/documentation/current/solutions/preferences/eiffelpreferences/index.wiki b/documentation/current/solutions/preferences/eiffelpreferences/index.wiki
new file mode 100644
index 00000000..539b3c27
--- /dev/null
+++ b/documentation/current/solutions/preferences/eiffelpreferences/index.wiki
@@ -0,0 +1,14 @@
+[[Property:title|EiffelPreference Library]]
+[[Property:link_title|EiffelPreferences]]
+[[Property:weight|1]]
+Type: Library
+Platform: Any
+
+See:
+* [[Preference Library|Content]]
+* [[Preferences Sample|Samples]]
+* [[ref:libraries/preferences/reference/index|Reference]]
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-input.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-input.wiki
new file mode 100644
index 00000000..4b431ebd
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-input.wiki
@@ -0,0 +1,54 @@
+[[Property:title|eiffel_scan console input]]
+[[Property:weight|2]]
+
+-- Example of a lexical analyzer based on the Eiffel syntax.
+-- The analyzer itself is found in the file ``eiffel_lex'', which
+-- is created according to the file ``eiffel_token'' if not
+-- previously built and stored.
+
+class EIFFEL_SCAN
+
+inherit
+
+ SCANNING
+ rename
+ make as scanning_make
+ end;
+
+ ARGUMENTS
+ undefine
+ copy, consistent, is_equal, setup
+ end
+
+create
+
+ make
+
+feature
+
+ make is
+ -- Create a lexical analyser for Eiffel if none,
+ -- then use it to analyze the file of name
+ -- `file_name'.
+ local
+ file_name: STRING;
+ do
+ if argument_count < 1 then
+ io.error.putstring ("Usage: eiffel_scan eiffel_class_file.e%N")
+ else
+ file_name := argument (1);
+ scanning_make;
+ build ("eiffel_lex", "eiffel_regular");
+ io.putstring ("Scanning file `");
+ io.putstring (file_name);
+ io.putstring ("'.%N");
+ analyze (file_name)
+ end
+ end -- make
+
+end -- class EIFFEL_SCAN
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-output.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-output.wiki
new file mode 100644
index 00000000..da3536fd
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-output.wiki
@@ -0,0 +1,117 @@
+[[Property:title|eiffel_scan console output]]
+[[Property:weight|3]]
+
+Scanning file `eiffel_scan.e'.
+
+
+--------------- LEXICAL ANALYSIS: ----
+
+Token type 11: -- Example of a lexical analyzer based on the Eiffel syntax.
+-- The analyzer itself is found in the file ``eiffel_lex'', which
+-- is created according to the file ``eiffel_token'' if not
+-- previously built and stored.
+
+Keyword: class Code: 1819086195
+Token type 32: EIFFEL_SCAN
+Keyword: inherit Code: 1080299636
+Token type 32: SCANNING
+Keyword: rename Code: 2076787557
+Token type 32: make
+Keyword: as Code: 24947
+Token type 32: scanning_make
+Keyword: end Code: 6647396
+Token type 15: ;
+Token type 32: ARGUMENTS
+Keyword: undefine Code: 1472863845
+Token type 32: copy
+Token type 17: ,
+Token type 32: consistent
+Token type 17: ,
+Token type 32: is_equal
+Token type 17: ,
+Token type 32: setup
+Keyword: end Code: 6647396
+Token type 32: create
+Token type 32: make
+Keyword: feature Code: 1951938661
+Token type 32: make
+Keyword: is Code: 26995
+Token type 11: -- Create a lexical analyser for Eiffel if none,
+ -- then use it to analyze the file of name
+
+Token type 11: -- `file_name'.
+
+Keyword: local Code: 1869613420
+Token type 32: file_name
+Token type 16: :
+Token type 32: STRING
+Token type 15: ;
+Keyword: do Code: 25711
+Keyword: if Code: 26982
+Token type 32: argument_count
+Token type 10: <
+Token type 2: 1
+Keyword: then Code: 1952998766
+Token type 32: io
+Token type 13: .
+Token type 32: error
+Token type 13: .
+Token type 32: putstring
+Token type 20: (
+Token type 3: "Usage: eiffel_scan eiffel_class_file.e%N"
+Token type 21: )
+Keyword: else Code: 1701606245
+Token type 32: file_name
+Token type 18: :=
+Token type 32: argument
+Token type 20: (
+Token type 2: 1
+Token type 21: )
+Token type 15: ;
+Token type 32: scanning_make
+Token type 15: ;
+Token type 32: build
+Token type 20: (
+Token type 3: "eiffel_lex"
+Token type 17: ,
+Token type 3: "eiffel_regular"
+Token type 21: )
+Token type 15: ;
+Token type 32: io
+Token type 13: .
+Token type 32: putstring
+Token type 20: (
+Token type 3: "Scanning file `"
+Token type 21: )
+Token type 15: ;
+Token type 32: io
+Token type 13: .
+Token type 32: putstring
+Token type 20: (
+Token type 32: file_name
+Token type 21: )
+Token type 15: ;
+Token type 32: io
+Token type 13: .
+Token type 32: putstring
+Token type 20: (
+Token type 3: "'.%N"
+Token type 21: )
+Token type 15: ;
+Token type 32: analyze
+Token type 20: (
+Token type 32: file_name
+Token type 21: )
+Keyword: end Code: 6647396
+Keyword: end Code: 6647396
+Token type 11: -- make
+
+Keyword: end Code: 6647396
+Token type 11: -- class EIFFEL_SCAN
+
+Token type -1:
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-text.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-text.wiki
new file mode 100644
index 00000000..5eb8af70
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-text.wiki
@@ -0,0 +1,53 @@
+[[Property:title|EIFFEL_SCAN Text]]
+[[Property:weight|1]]
+
+
+ class
+ EIFFEL_SCAN
+
+ inherit
+ SCANNING
+ rename
+ make as scanning_make
+ end
+
+ ARGUMENTS
+ undefine
+ copy,
+ consistent,
+ is_equal,
+ setup
+ end
+
+ create
+ make
+
+ feature
+
+ make is
+ -- Create a lexical analyser for Eiffel if none,
+ -- then use it to analyze the file of name
+ -- file_name.
+ local
+ file_name: STRING
+ do
+ if argument_count < 1 then
+ io.error.putstring ("Usage: eiffel_scan eiffel_class_file.e%N")
+ else
+ file_name := argument (1)
+ scanning_make
+ build ("eiffel_lex", "eiffel_regular")
+ io.putstring ("Scanning file `")
+ io.putstring (file_name)
+ io.putstring ("'.%N")
+ analyze (file_name)
+ end
+ end
+
+ end -- class EIFFEL_SCAN
+
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffellex-samples.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffellex-samples.wiki
new file mode 100644
index 00000000..9caf3c81
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffellex-samples.wiki
@@ -0,0 +1,99 @@
+[[Property:title|EiffelLex Samples]]
+[[Property:weight|0]]
+
+
+
+Real $R
+Integer $Z
+String ("\"" -> "\"")
+Div "//"
+Mod "\\"
+Quotient '/'
+Product '*'
+Plus '+'
+Minus '-'
+Relational ('=' | '<' | '>' | ('<' '=') | ('>' '=') | ('/' '='))
+Comment ("--" -> "\n") *(' '| '\t') *("--" -> "\n")
+FeatureAddress '$'
+Dot '.'
+Dotdot ".."
+Semicolon ';'
+Colon ':'
+Comma ','
+Assign ":="
+ReverseAssign "?="
+Lparan '('
+Rparan ')'
+Lcurly '{'
+Rcurly '}'
+Lsquare '['
+Rsquare ']'
+Bang '!'
+LeftArray "<<"
+RightArray ">>"
+Power '^'
+Constraint "->"
+Character (('\''$P'\'') | ('\'''\\'['t'|'n'|'r'|'f']'\'') | ('\''+('0'..'7')'\''))
+Identifier ~('a'..'z') *(~('a'..'z') | '_' | ('0'..'9'))
+-- Keywords
+as
+and
+check
+class
+current
+debug
+deferred
+do
+else
+elseif
+end
+ensure
+expanded
+export
+external
+false
+feature
+from
+if
+implies
+indexing
+infix
+inherit
+inspect
+integer
+invariant
+is
+language
+like
+local
+loop
+not
+obsolete
+old
+once
+or
+prefix
+real
+redefine
+require
+rename
+rescue
+result
+retry
+select
+strip
+then
+true
+undefine
+unique
+until
+variant
+void
+when
+xor
+
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/index.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/index.wiki
new file mode 100644
index 00000000..c09d00de
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|Eiffel scanner]]
+[[Property:weight|0]]
+In the directory '''$ISE_EIFFEL/examples/lex''' you will find a system that scans Eiffel classes. It consists of the class [[EIFFEL_SCAN Text|EIFFEL_SCAN]] . It uses the file [[EiffelLex Samples|eiffel_regular]] as lexical grammar to analyze an Eiffel class passed on the command line.
+
+When compiling the example, the executable '''eiffel_scan(.exe)''' is created. Use the program as follows:
+eiffel_scan ;
+
+As an example, when the [[eiffel_scan console input|source code]] of the root class is run through the scanner, it outputs a [[eiffel_scan console output|list]] of all consecutive tokens and keywords in that class to the console.
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/index.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/index.wiki
new file mode 100644
index 00000000..e0563a77
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-sample/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|Lex Sample]]
+[[Property:link_title|EiffelLex Sample]]
+[[Property:weight|2]]
+* [[Eiffel scanner|Eiffel scanner]]
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki b/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki
new file mode 100644
index 00000000..6104111a
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki
@@ -0,0 +1,538 @@
+[[Property:title|Lexical analysis: the Lex library]]
+[[Property:link_title|EiffelLex Tutorial]]
+[[Property:weight|0]]
+==OVERVIEW==
+
+When analyzing a text by computer, it is usually necessary to split it into individual components or '''tokens'''. In human languages, the tokens are the words; in programming languages, tokens are the basic constituents of software texts, such as identifiers, constants and special symbols.
+
+The process of recognizing the successive tokens of a text is called lexical analysis. This chapter describes the Lex library, a set of classes which make it possible to build and apply lexical analyzers to many different languages.
+
+Besides recognizing the tokens, it is usually necessary to recognize the deeper syntactic structure of the text. This process is called '''parsing''' or '''syntax analysis''' and is studied in the next chapter.
+
+Figure 1 shows the inheritance structure of the classes discussed in this chapter. Class [[ref:/libraries/parse/reference/l_interface_chart|L_INTERFACE]] has also been included although we will only study it in the [[Parsing: The Parse Library|next chapter]] ; it belongs to the Parse library, where it takes care of the interface between parsing and lexical analysis.
+ [[Image:figure1]]
+Figure 1: Lexical classes
+
+==AIMS AND SCOPE OF THE LEX LIBRARY==
+
+To use the Lex library it is necessary to understand the basic concepts and terminology of lexical analysis.
+
+===Basic terminology===
+
+The set of tokens accepted by a lexical analyzer is called a '''lexical grammar'''. For example, the basic constructs of Eiffel (identifiers, keywords, constants, special symbols) constitute a lexical grammar. For reasons that will be clear below, a lexical grammar is also known as a '''regular grammar'''.
+
+A lexical grammar defines a number of '''token types''', such as Identifier and Integer for Eiffel. A token that conforms to the structure defined for a certain token type is called a '''specimen''' of that token type. For example, the token my_identifier, which satisfies the rules for Eiffel tokens, is a specimen of the token type Identifier; 201 is a specimen of the token type Integer.
+
+To define a lexical grammar is to specify a number of token types by describing precisely, for each token type, the form of the corresponding specimens. For example a lexical grammar for Eiffel will specify that Identifier is the token type whose specimens are sequences of one or more characters, of which the first must be a letter (lower-case or upper-case) and any subsequent one is a letter, a digit (0 to 9) or an underscore. Actual grammar descriptions use a less verbose and more formal approach, studied below: regular expressions.
+
+A lexical analyzer is an object equipped with operations that enable it to read a text according to a known lexical grammar and to identify the text's successive tokens.
+
+The classes of the Lex library make it possible to define lexical grammars for many different applications, and to produce lexical analyzers for these grammars.
+
+===Overview of the classes===
+
+For the user of the Lex libraries, the classes of most direct interest are [[ref:/libraries/lex/reference/token_chart|TOKEN]] , [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , [[ref:/libraries/lex/reference/metalex_chart|METALEX]] and [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] .
+
+An instance of [[ref:/libraries/lex/reference/token_chart|TOKEN]] describes a token read from an input file being analyzed, with such properties as the token type, the corresponding string and the position in the text (line, column) where it was found.
+
+An instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] is a lexical analyzer for a certain lexical grammar. Given a reference to such an instance, say analyzer, you may analyze an input text through calls to the features of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , for example:
+ analyzer.get_token
+
+Class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] defines facilities for building such lexical analyzers. In particular, it provides features for reading the grammar from a file and building the corresponding analyzer. Classes that need to build and use lexical analyzers may be written as descendants of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] to benefit from its general-purpose facilities.
+
+Class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] is one such descendant of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . It contains all the facilities needed to build an ordinary lexical analyzer and apply it to the analysis of input texts. Because these facilities are simpler to use and are in most cases sufficient, SCANNING will be discussed first; the finer-grain facilities of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] are described towards the end of this chapter.
+
+These classes internally rely on others, some of which may be useful for more advanced applications. [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , one of the supporting classes, will be introduced after [[ref:/libraries/lex/reference/metalex_chart|METALEX]] .
+
+===Library example===
+
+The EiffelStudio delivery includes (in the examples/library/lex subdirectory) a simple example using the Lexical Library classes. The example applies Lex library facilities to the analysis of a language which is none other than Eiffel itself.
+
+The root class of that example, EIFFEL_SCAN, is only a few lines long; it relies on the general mechanism provided by [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] (see below). The actual lexical grammar is given by a lexical grammar file (a concept explained below): the file of name eiffel_regular in the same directory.
+
+===Dealing with finite automata===
+
+Lexical analysis relies on the theory of finite automata. The most advanced of the classes discussed in this chapter, [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , relies on classes describing various forms of automata:
+* [[ref:/libraries/lex/reference/dfa_chart|DFA]] : deterministic finite automata.
+* [[ref:/libraries/lex/reference/pdfa_chart|PDFA]] : partially deterministic finite automata.
+* [[ref:/libraries/lex/reference/ndfa_chart|NDFA]] : non-deterministic finite automata.
+* [[ref:/libraries/lex/reference/automaton_chart|AUTOMATON]] , the most general: finite automata.
+* [[ref:/libraries/lex/reference/fixed_automaton_chart|FIXED_AUTOMATON]] , [[ref:/libraries/lex/reference/linked_automaton_chart|LINKED_AUTOMATON]] .
+
+These classes may also be useful for systems that need to manipulate finite automata for applications other than lexical analysis. The interface of [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which includes the features from [[ref:/libraries/lex/reference/automaton_chart|AUTOMATON]] , [[ref:/libraries/lex/reference/ndfa_chart|NDFA]] and [[ref:/libraries/lex/reference/pdfa_chart|PDFA]] , will provide the essential information.
+
+==TOKENS==
+
+A lexical analyzer built through any of the techniques described in the rest of this chapter will return tokens - instances of class [[ref:libraries/lex/reference/token_chart|TOKEN]] . Here are the most important features of this class:
+* string_value: a string giving the token's contents.
+* type: an integer giving the code of the token's type. The possible token types and associated integer codes are specified during the process of building the lexical analyzer in one of the ways described below.
+* is_keyword: a boolean indicating whether the token is a keyword.
+* keyword_code: an integer, meaningful only if is_keyword is true, and identifying the keyword by the code that was given to it during the process of building the analyzer.
+* line_number, column_number: two integers indicating where the token appeared in the input text.
+
+==BUILDING AND USING LEXICAL ANALYZERS==
+
+The general method for performing lexical analysis is the following.
+# Create an instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , giving a lexical analyzer for the desired grammar.
+# Store the analyzer into a file.
+# Retrieve the analyzer from the file.
+# Use the analyzer to analyze the tokens of one or more input texts by calling the various features of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] on this object.
+
+Steps 2 and 3 are obviously unnecessary if this process is applied as a single sequence. But in almost all practical cases you will want to use the same grammar to analyze many different input texts. Then steps 1 and 2 will be performed once and for all as soon as the lexical grammar is known, yielding an instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] that step 2 stores into a file; then in every case that requires analyzing a text you will simply retrieve the analyzer and apply it, performing steps 3 and 4 only.
+
+The simplest way to store and retrieve the instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] and all related objects is to use the facilities of class [[ref:/libraries/base/reference/storable_chart|STORABLE]] : procedure store and one of the retrieval procedures. To facilitate this process, [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] inherits from [[ref:/libraries/base/reference/storable_chart|STORABLE]] .
+
+The next sections explain how to perform these various steps. In the most common case, the best technique is to inherit from class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , which provides a framework for retrieving an analyzer file if it exists, creating it from a grammar description otherwise, and proceed with the lexical analysis of one or more input texts.
+
+==LEXICAL GRAMMAR FILES AND CLASS SCANNING==
+
+Class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] may be used as an ancestor by classes that need to perform lexical analysis. When using [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] you will need a '''lexical grammar file''' that contains the description of the lexical grammar. Since it is easy to edit and adapt a file without modifying the software proper, this technique provides flexibility and supports the incremental development and testing of lexical analyzers.
+
+===The build procedure===
+
+To obtain a lexical analyzer in a descendant of class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , use the procedure
+ build (store_file_name, grammar_file_name: STRING)
+
+If no file of name store_file_name exists, then build reads the lexical grammar from the file of name grammar_file_name , builds the corresponding lexical analyzer, and stores it into store_file_name .
+
+If there already exists a file of name grammar_file_name , build uses it to recreate an analyzer without using the grammar_file_name .
+===Lexical grammar files===
+
+A lexical grammar file (to be used as second argument to build, corresponding to grammar_file_name ) should conform to a simple structure, of which the file ''eiffel_regular'' in the examples directory provides a good illustration.
+
+Here is the general form:
+
+Token_type_1 Regular_expression_1
+Token_type_2 Regular_expression_2
+...
+Token_type_m Regular_expression_m
+
+
+'''-- Keywords'''
+
+Keyword_1
+Keyword_2
+...
+Keyword_n
+
+
+
+In other words: one or more lines, each containing the name of a token type and a '''regular expression'''; a line beginning with two dashes -- (the word '''Keywords''' may follow them to signal that this is the beginning of keywords); and one or more lines containing one keyword each.
+
+Each ''Token_type_i'' is the name of a token type, such as ''Identifier'' or ''Decimal_constant''. Each ''Regular_expression_i'' is a regular expression, built according to a precisely specified format. That format is defined later in this chapter, but even without having seen that definition it is not hard to understand the following small and typical example of lexical grammar file without keywords:
+
+Decimal '0'..'9'
+Natural +('0'..'9')
+Integer ['+'|'-'] '1'..'9' *('0'..'9')
+
+
+The first expression describes a token type whose specimens are tokens made of a single-letter decimal digit (any character between 0 and 9). In the second, the + sign denotes repetition (one or more); the specimens of the corresponding token type are all non-empty sequences of decimal digits - in other words, natural numbers, with leading zeroes permitted. In the third, the | symbol denotes alternation, and the asterisk denotes repetition (zero or more); the corresponding tokens are possibly signed integer constants, with no leading zeroes.
+
+As explained below, keywords are regular expressions which are treated separately for convenience and efficiency. If you are using lexical grammar files of the above form, all keywords must be specimens of the last regular expression given ( ''Regular_expression_m'' above). More details below.
+
+===Using a lexical analyzer===
+
+Once build has given you an analyzer, you may use it to analyze input texts through calls to the procedure
+
+ analyze (input_file_name: STRING)
+
+This will read in and process successive input tokens. Procedure analyze will apply to each of these tokens the action of procedure do_a_token. As defined in SCANNING, this procedure prints out information on the token: its string value, its type, whether it is a keyword and if so its code. You may redefine it in any descendant class so as to perform specific actions on each token.
+
+The initial action begin_analysis, which by default prints a header, and the terminal action end_analysis, which by default does nothing, may also be redefined.
+
+To build lexical analyzers which provide a higher degree of flexibility, use [[ref:/libraries/lex/reference/metalex_chart|METALEX]] or [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , as described in the last part of this chapter.
+
+==ANALYZING INPUT==
+
+Let us look more precisely at how we can use a lexical analyzer to analyze an input text.
+
+===Class LEXICAL===
+
+Procedure analyze takes care of the most common needs of lexical analysis. But if you need more advanced lexical analysis facilities you will need an instance of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] (a direct instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] itself or of one of its proper descendants). If you are using class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] as described above, you will have access to such an instance through the attribute analyzer.
+
+This discussion will indeed assume that you have an entity attached to an instance of [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] . The name of that entity is assumed to be analyzer, although it does not need to be the attribute from [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] . You can apply to that analyzer the various exported features features of class [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] , explained below. All the calls described below should use analyzer as their target, as in
+ analyzer.set_file ("my_file_name")
+
+===Creating, retrieving and storing an analyzer===
+
+To create a new analyzer, use
+ create analyzer.make_new
+
+You may also retrieve an analyzer from a previous session. [[ref:/libraries/lex/reference/lexical_chart|LEXICAL]] is a descendant from [[ref:/libraries/base/reference/storable_chart|STORABLE]] , so you can use feature retrieved for that purpose. In a descendant of [[ref:/libraries/base/reference/storable_chart|STORABLE]] , simply write
+ analyzer ?= retrieved
+
+If you do not want to make the class a descendant of [[ref:/libraries/base/reference/storable_chart|STORABLE]] , use the creation procedure make of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , not to be confused with make_new above:
+
+ create analyzer.make
+ analyzer ?= analyzer.retrieved
+
+
+===Choosing a document===
+
+To analyze a text, call set_file or set_string to specify the document to be parsed. With the first call, the analysis will be applied to a file; with the second, to a string.
+
+{{note| '''Note''': if you use procedure analyze of [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , you do not need any such call, since analyze calls set_file on the file name passed as argument. }}
+
+===Obtaining the tokens===
+
+The basic procedure for analyzing successive tokens in the text is get_token, which reads in one token and sets up various attributes of the analyzer to record properties of that token:
+* last_token, a function of type [[ref:/libraries/lex/reference/token_chart|TOKEN]] , which provides all necessary information on the last token read.
+* token_line_number and token_column_number, to know where the token is in the text. These queries return results of type INTEGER.
+* token_type, giving the regular expression type, identified by its integer number (which is the value No_token if no correct token was recognized).
+* other_possible_tokens, an array giving all the other possible token types of the last token. (If token_type is No_token the array is empty.)
+* end_of_text, a boolean attribute used to record whether the end of text has been reached. If so, subsequent calls to get_token will have no effect.
+
+Procedure get_token recognizes the longest possible token. So if <, = and <= are all regular expressions in the grammar, the analyzer recognizes <= as one token, rather than < followed by =. You can use other_possible_tokens to know what shorter tokens were recognized but not retained.
+
+If it fails to recognize a regular expression, get_token sets token_type to No_token and advances the input cursor by one character.
+
+===The basic scheme===
+
+Here is the most common way of using the preceding facilities:
+
+ from
+ set_file ("text_directory/text_to_be_parsed")
+ -- Or: set_string ("string to parse")
+ begin_analysis
+ until
+ end_of_text
+ loop
+ analyzer.get_token
+ if analyzer.token_type = No_token then
+ go_on
+ end
+ do_a_token (lexical.last_token)
+ end
+ end_analysis
+
+
+This scheme is used by procedure analyze of class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , so that in standard cases you may simply inherit from that class and redefine procedures begin_analysis, do_a_token and end_analysis. If you are not inheriting from [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , these names simply denote procedures that you must provide.
+
+==REGULAR EXPRESSIONS==
+
+The Lex library supports a powerful set of construction mechanisms for describing the various types of tokens present in common languages such as programming languages, specification languages or just text formats. These mechanisms are called '''regular expressions'''; any regular expression describes a set of possible tokens, called the '''specimens''' of the regular expression.
+
+Let us now study the format of regular expressions. This format is used in particular for the lexical grammar files needed by class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] and (as seen below) by procedure read_grammar of class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . The ''eiffel_regular'' grammar file in the examples directory provides an extensive example.
+
+Each regular expression denotes a set of tokens. For example, the first regular expression seen above,
+ '0'..'9'
+
+denotes a set of ten tokens, each consisting of a single digit.
+
+===Basic expressions===
+
+A character expression, written '''character''' where ''character'' is a single character, describes a set of tokens with just one element: the one-character token character. For example, '''0''' describes the set containing the single-digit single token ''0''.
+
+Cases in which character is not a printable character use the following conventions:
+{| border="1"
+|-
+| '\ooo'
+| Character given by its three-digit octal code ''ooo''.
+|-
+| '\xx'
+| Character given by its two-digit hexadecimal code ''xx''.
+(Both lower- and upper-case may be used for letters in ''xx''.)
+|-
+| '\r'
+| Carriage return
+|-
+| '\''
+| Single quote
+|-
+| '\\'
+| Backslash
+|-
+| '\t'
+| Tabulation
+|-
+| '\n'
+| New line
+|-
+| '\b'
+| Backspace
+|-
+| '\f'
+| Form feed
+|}
+
+===Intervals===
+
+An interval, written ''lower..upper'' where ''lower'' and ''upper'' are character expressions, describes a set of one-character tokens: all the characters whose ASCII code is between the codes for the characters in ''lower'' and ''upper''. For example, '''0'..'9''' contains all tokens made of a single decimal digit.
+
+===Basic operator expressions===
+
+A parenthesized expression, written ( ''exp'') where ''exp'' is a regular expression, describes the same set of tokens as ''exp''. This serves to remove ambiguities in complex regular expressions. For example, the parenthesized expression ( '''0'..'9''') also describes all single-decimal-digit tokens.
+
+A difference, written ''interval - char'', where ''interval'' is an interval expression and ''char'' is a character expression, describes the set of tokens which are in ''exp'' but not in ''char''. For example, the difference '''0'..'9' - '4''' describes all single-decimal-digit tokens except those made of the digit 4.
+
+{{warning| '''Caution''': a difference may only apply to an interval and a single character. }}
+
+===Iterations===
+
+An unbounded iteration, written ''*exp'' or ''+exp'' where ''exp'' is a regular expression, describes the set of tokens made of sequences of zero or more specimens of ''exp'' (in the first form, using the asterisk), or of one or more specimens of ''exp'' (in the second form, using the plus sign). For example, the iteration ''+('0'..'9')'' describes the set of tokens made of one or more consecutive decimal digits.
+
+A fixed iteration, written ''n exp'' where ''n'' is a natural integer constant and ''exp'' is a regular expression, describes the set of tokens made of sequences of exactly ''n'' specimens of ''exp''. For example, ''3 ('A'..'Z')'' describes the set of all three-letter upper-case tokens.
+===Other operator expressions===
+
+A concatenation, writtenexp 1 exp 2 ... exp n, describes the set of tokens made of a specimen of exp 1 followed by a specimen of exp 2 etc. For example, the concatenation '''1'..'9' * ('0'..'9')'' describes the set of tokens made of one or more decimal digits, not beginning with a zero - in other words, integer constants in the usual notation.
+
+An optional component, written ''[exp]'' where ''exp'' is a regular expression, describes the set of tokens that includes the empty token and all specimens of ''exp''. Optional components usually appear in concatenations.
+
+Concatenations may be inconvenient when the concatenated elements are simply characters, as in '''A' ' ' 'T' 'e' 'x' 't'''. In this case you may use a '''string''' in double quotes, as in
+ "A Text"
+
+
+More generally, a string is written"a 1 a 2 ... a n"for ''n >= 0'', where thea i are characters, and is an abbreviation for the concatenation 'a 1' 'a 2' ... 'a n'
+, representing a set containing a single token. In a string, the double quote character " is written \" and the backslash character \ is written \\. No other special characters are permitted; if you need special characters, use explicit concatenation. As a special case, "" represents the set containing a single empty token.
+
+A union, writtenexp 1 | exp 2 | ... | exp n, describes the set of tokens which are specimens ofexp 1, or ofexp 2 etc. For example, the union ''('a'..'z') | ('A'..'Z')'' describes the set of single-letter tokens (lower-case or upper-case).
+
+===Predefined expressions===
+
+A joker, written '''$?''', describes the set of all tokens made of exactly one character. A joker is considered to be an interval expression, so that it may be the first operand of a difference operation.
+
+A printable, written '''$P''', describes the set of all tokens made of exactly one printable character.
+
+A blank, written '''$B''', describes the set of all tokens made of one or more specimens of the characters blank, new-line, carriage-return and tabulation.
+
+The following non-elementary forms are abbreviations for commonly needed regular expressions:
+{| border="1"
+|-
+| Code
+| Equivalent expression
+| Role
+|-
+| '''$L'''
+| '''\n'''
+| New-line character
+|-
+| '''$N'''
+| ''+('0'..'9')''
+| Natural integer constants
+|-
+| '''$R'''
+| ''['+'|'-'] +('0'..'9') '.' *('0'..'9')['e'|'E' ['+'|'-'] +('0'..'9')]''
+| Floating point constants
+|-
+| '''$W'''
+| +( '''$P''' - ' ' - '\t' - '\n' - '\r')
+| Words
+|-
+| '''$Z'''
+| ''['+'|'-'] +('0'..'9')''
+| Possibly signed integer constants
+|}
+
+A delimited string, written ''->string'', where ''string'' is of the form,"a 1 a 2 ... a n", represents the set of tokens made of any number of printable characters and terminated by ''string''.
+One more form of regular expression, case-sensitive expressions, using the ~ symbol, will be introduced below.
+
+===Combining expression-building mechanisms===
+
+You may freely combine the various construction mechanisms to describe complex regular expressions. Below are a few examples.
+{| border="1"
+|-
+| '''a'..'z' - 'c' - 'e'''
+| Single-lower-case-letter tokens, except ''c'' and ''e''.
+|-
+| ''$? - '\007'''
+| Any single-character token except ASCII 007.
+|-
+| ''+('a'..'z')''
+| One or more lower-case letters.
+|-
+| ''['+'|'-'] '1'..'9' *('0'..'9')''
+| Integer constants, optional sign, no leading zero.
+|-
+| ''->"*/"''
+| Any string up to and including an occurrence of */
+(the closing symbol of a PL/I or C comment).
+|-
+| ''"\"" ->"\""''
+| Eiffel strings.
+|}
+
+===Dealing with keywords===
+
+Many languages to be analyzed have keywords - or, more generally, "reserved words". Eiffel, for example, has reserved words such as class and Result .
+{{note| '''Note''': in Eiffel terminology reserved words include keywords; a keyword is a marker playing a purely syntactical role, such as class . Predefined entities and expressions such as Result and Current , which have an associated value, are considered reserved words but not keywords. The present discussion uses the term "keyword" although it can be applied to all reserved words. }}
+
+In principle, keywords could be handled just as other token types. In Eiffel, for example, one might treat each reserved words as a token type with only one specimen; these token types would have names such as Class or Then and would be defined in the lexical grammar file:
+
+''Class'' ''''c' 'l' 'a' 's' 's''''
+''Then'' ''''t' 'h' 'e' 'n''''
+...
+
+This would be inconvenient. To simplify the task of language description, and also to improve the efficiency of the lexical analysis process, it is usually preferable to treat keywords as a separate category.
+
+If you are using class SCANNING and hence a lexical grammar file, the list of keywords, if any, must appear at the end of the file, one per line, preceded by a line that simply reads
+
+'''-- Keywords'''
+
+For example the final part of the example Eiffel lexical grammar file appears as:
+
+ ... Other token type definitions ...
+Identifier ~('a'..'z') *(~('a'..'z') | '_' | ('0'..'9'))
+'''
+-- Keywords
+alias
+all
+and
+as
+'''
+BIT
+BOOLEAN
+... Other reserved words ...
+
+
+{{warning| '''Caution''': every keyword in the keyword section must be a specimen of one of the token types defined for the grammar, and that token type must be the last one defined in the lexical grammar file, just before the '''Keywords''' line. So in Eiffel where the keywords have the same lexical structure as identifiers, the last line before the keywords must be the definition of the token type ''Identifier'', as shown above. }}
+
+{{note| '''Note''': the rule that all keywords must be specimens of one token type is a matter of convenience and simplicity, and only applies if you are using SCANNING and lexical grammar files. There is no such restriction if you rely directly on the more general facilities provided by [[ref:/libraries/lex/reference/metalex_chart|METALEX]] or [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . Then different keywords may be specimens of different regular expressions; you will have to specify the token type of every keyword, as explained later in this chapter. }}
+
+===Case sensitivity===
+
+By default, letter case is not significant for regular expressions and keywords. So if ''yes'' matches a token type defined by a regular expression, or is a keyword, the input values ''Yes'', ''yEs'' and ''yES'' will all yield the same token or keyword. This also means that '''a'..'z''' and '''a'..'z' | 'A'..'Z''' describe the same set of tokens.
+
+The regular expression syntax introduced above offers a special notation to specify that a particular expression is case-sensitive: ''~exp'', where ''exp'' is a regular expression. For example, ''~('A'..'Z')'' only covers single-upper-case-letter tokens. But for all other kinds of expression letter case is not taken into account.
+
+You may change this default behavior through a set of procedures introduced in class [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] and hence available in its descendants [[ref:libraries/lex/reference/metalex_chart|METALEX ]] and [[ref:libraries/lex/reference/scanning_chart|SCANNING]] .
+
+To make subsequent regular expressions case-sensitive, call the procedure
+ distinguish_case
+
+To revert to the default mode where case is not significant, call the procedure
+ ignore_case
+
+Each of these procedures remains in effect until the other one is called, so that you only need one call to define the desired behavior.
+
+For keywords, the policy is less tolerant. A single rule is applied to the entire grammar: keywords are either all case-sensitive or all case-insensitive. To make all keywords case-sensitive, call
+ keywords_distinguish_case
+
+The inverse call, corresponding to the default rule, is
+ keywords_ignore_case
+
+Either of these calls must be executed before you define any keywords; if you are using [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , this means before calling procedure build. Once set, the keyword case-sensitivity policy cannot be changed.
+
+==USING METALEX TO BUILD A LEXICAL ANALYZER==
+
+(You may skip the rest of this chapter if you only need simple lexical facilities.)
+
+Class [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , as studied above, relies on a class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . In some cases, you may prefer to use the features of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] directly. Since [[ref:libraries/lex/reference/scanning_chart|SCANNING]] inherits from [[ref:/libraries/lex/reference/metalex_chart|METALEX]] , anything you do with [[ref:/libraries/lex/reference/metalex_chart|METALEX]] can in fact be done with [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , but you may wish to stay with just [[ref:/libraries/lex/reference/metalex_chart|METALEX]] if you do not need the additional features of [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] .
+
+===Steps in using METALEX===
+
+[[ref:/libraries/lex/reference/metalex_chart|METALEX]] has an attribute analyzer which will be attached to a lexical analyzer. This class provides tools for building a lexical analyzer incrementally through explicit feature calls; you can still use a lexical grammar file, but do not have to.
+
+The following extract from a typical descendant of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] illustrates the process of building a lexical analyzer in this way:
+
+ Upper_identifier, Lower_identifier, Decimal_constant, Octal_constant, Word: INTEGER is unique
+ ...
+ distinguish_case
+ keywords_distinguish_case
+ put_expression("+('0'..'7'"), Octal_constant, "Octal")
+ put_expression ("'a'..'z' *('a'..'z'|'0'..'9'|'_')", Lower_identifier, "Lower")
+ put_expression ("'A'..'Z' *('A'..'Z'|'0'..'9'|'_' )", Upper_identifier, "Upper")
+ dollar_w (Word)
+ ...
+ put_keyword ("begin", Lower_identifier)
+ put_keyword ("end", Lower_identifier)
+ put_keyword ("THROUGH", Upper_identifier)
+ ...
+ make_analyzer
+
+
+This example follows the general scheme of building a lexical analyzer with the features of [[ref:/libraries/lex/reference/metalex_chart|METALEX]] , in a class that will normally be a descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] :
+# Set options, such as case sensitivity.
+# Record regular expressions.
+# Record keywords (this may be interleaved with step 2.)
+# "Freeze" the analyzer by a call to make_analyzer.
+
+To perform steps 2 to 4 in a single shot and generate a lexical analyzer from a lexical grammar file, as with [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] , you may use the procedure
+ read_grammar (grammar_file_name: STRING)
+
+In this case all the expressions and keywords are taken from the file of name grammar_file_name rather than passed explicitly as arguments to the procedures of the class. You do not need to call make_analyzer, since read_grammar includes such a call.
+
+The rest of this discussion assumes that the four steps are executed individually as shown above, rather than as a whole using read_grammar.
+===Recording token types and regular expressions===
+
+As shown by the example, each token type, defined by a regular expression, must be assigned an integer code. Here the developer has chosen to use Unique constant values so as not to worry about selecting values for these codes manually, but you may select any values that are convenient or mnemonic. The values have no effect other than enabling you to keep track of the various lexical categories. Rather than using literal values directly, it is preferable to rely on symbolic constants, Unique or not, which will be more mnemonic.
+
+Procedure put_expression records a regular expression. The first argument is the expression itself, given as a string built according to the rules seen earlier in this chapter. The second argument is the integer code for the expression. The third argument is a string which gives a name identifying the expression. This is useful mostly for debugging purposes; there is also a procedure put_nameless_expression which does not have this argument and is otherwise identical to put_expression.
+
+Procedure dollar_w corresponds to the '''$W''' syntax for regular expressions. Here an equivalent call would have been
+ put_nameless_expression ( "$W" ,Word )
+
+Procedure declare_keyword records a keyword. The first argument is a string containing the keyword; the second argument is the regular expression of which the keyword must be a specimen. The example shows that here - in contrast with the rule enforced by [[ref:/libraries/lex/reference/scanning_chart|SCANNING]] - not all keywords need be specimens of the same regular expression.
+
+The calls seen so far record a number of regular expressions and keywords, but do not give us a lexical analyzer yet. To obtain a usable lexical analyzer, you must call
+ make_analyzer
+
+After that call, you may not record any new regular expression or keyword. The analyzer is usable through attribute analyzer.
+{{note| '''Note''': for readers knowledgeable in the theory of lexical analysis: one of the most important effects of the call to make_analyzer is to transform the non-deterministic finite automaton resulting from calls such as the ones above into a deterministic finite automaton. }}
+
+Remember that if you use procedure read_grammar, you need not worry about make_analyzer, as the former procedure calls the latter.
+Another important feature of class [[ref:/libraries/lex/reference/metalex_chart|METALEX]] is procedure store_analyzer, which stores the analyzer into a file whose name is passed as argument, for use by later lexical analysis sessions. To retrieve the analyzer, simply use procedure retrieve_analyzer, again with a file name as argument.
+
+==BUILDING A LEXICAL ANALYZER WITH LEX_BUILDER==
+
+To have access to the most general set of lexical analysis mechanisms, you may use class [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which gives you an even finer grain of control than [[ref:/libraries/lex/reference/metalex_chart|METALEX]] . This is not necessary in simple applications.
+
+===Building a lexical analyzer===
+
+[[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] enables you to build a lexical analyzer by describing successive token types and keywords. This is normally done in a descendant of [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . For each token type, you call a procedure that builds an object, or '''tool''', representing the associated regular expression.
+
+For the complete list of available procedures, refer to the flat-short form of the class; there is one procedure for every category of regular expression studied earlier in this chapter. Two typical examples of calls are:
+
+ interval ('a', 'z')
+ -- Create an interval tool
+
+ union (Letter, Underlined)
+ -- Create a union tool
+
+
+Every such procedure call also assigns an integer index to the tool it creates; this number is available through the attribute last_created_tool. You will need to record it into an integer entity, for example Identifier or Letter.
+===An example===
+
+The following extract from a typical descendant of [[ref:/libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] illustrates how to create a tool representing the identifiers of an Eiffel-like language.
+
+ Identifier, Letter, Digit, Underlined, Suffix, Suffix_list: INTEGER
+
+ build_identifier is
+ do
+ interval ('a', 'z'); Letter := last_created_tool
+ interval ('0', '9'); Digit := last_created_tool
+ interval ('_', '_'); Underlined := last_created_tool
+ union (Digit, Underlined);
+ Suffix := last_created_tooliteration (Suffix);
+ Suffix_list := last_created_toolappend (Letter, Suffix_list);
+ Identifier := last_created_tool
+ end
+
+
+Each token type is characterized by a number in the tool_list. Each tool has a name, recorded in tool_names, which gives a readable form of the corresponding regular expression. You can use it to check that you are building the right tool.
+===Selecting visible tools===
+
+In the preceding example, only some of the tools, such as Identifier, are of interest to the clients. Others, such as Suffix and Suffix_list, only play an auxiliary role.
+
+When you create a tool, it is by default invisible to clients. To make it visible, use procedure select_tool. Clients will need a number identifying it; to set this number, use procedure associate. For example the above extract may be followed by:
+
+ select_tool (Identifier)
+ associate (Identifier, 34)
+ put_keyword ("class", Identifier)
+ put_keyword ("end", Identifier)
+ put_keyword ("feature", Identifier)
+
+
+If the analysis encounters a token that belongs to two or more different selected regular expressions, the one entered last takes over. Others are recorded in the array other_possible_tokens.
+
+If you do not explicitly give an integer value to a regular expression, its default value is its rank in tool_list.
+
+
+
+
+
+
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffellex/index.wiki b/documentation/current/solutions/text-processing/eiffellex/index.wiki
new file mode 100644
index 00000000..451f202b
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffellex/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelLex Library]]
+[[Property:link_title|EiffelLex]]
+[[Property:weight|1]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[Lexical analysis: the Lex library|Content]]
+* [[Lex Sample|Samples]]
+* [[ref:libraries/lex/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffelparse/index.wiki b/documentation/current/solutions/text-processing/eiffelparse/index.wiki
new file mode 100644
index 00000000..d2c70c95
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffelparse/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelParse Library]]
+[[Property:link_title|EiffelParse]]
+[[Property:weight|5]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[Parsing: The Parse Library|Content]]
+* [[Parse Sample|Samples]]
+* [[ref:libraries/parse/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/solutions/text-processing/eiffelparse/parse-sample/eiffel-polynomial-parser.wiki b/documentation/current/solutions/text-processing/eiffelparse/parse-sample/eiffel-polynomial-parser.wiki
new file mode 100644
index 00000000..40e623af
--- /dev/null
+++ b/documentation/current/solutions/text-processing/eiffelparse/parse-sample/eiffel-polynomial-parser.wiki
@@ -0,0 +1,20 @@
+[[Property:title|Eiffel polynomial parser]]
+[[Property:weight|0]]
+In the directory '''$ISE_EIFFEL/examples/parse''' you will find a system that implements a processor for a grammar describing a simple language for expressin polynomials. A typical document in this language is the line
+x;y: x * (y + 8 - (2 * x))
+The beginning of the line, separated from the rest by a colon, is the list of variables used in the polynomial, separated by semicolons. The rest of the line is the expression defining the polynomial. The grammar can be described with the following grammar:
+
+LINE = VARIABLES ":" SUM
+VARIABLES = VAR .. ";"
+SUM = DIFF .. "+"
+DIFF = PRODUCT .. "-"
+PRODUCT = TERM .. "*"
+TERM = SIMPLE_VAR | INT_CONSTANT | NESTED
+NESTED = "(" SUM ")"
+This grammar assumes a terminal '''VAR''', which must be defined as a token type in the lexical grammar. The other terminals are keywords, shown as strings appearing in the double quotes, for example "+".
+When compiling the example, the executable '''process(.exe)''' is created. When executing the program, it will prompt for the name of a file with a polynomial description, reads a polynomial from the given file, prompts for integer values of the variables, and evaluates the polynomial.
+
+
+
+
+
diff --git a/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-sample/eiffelweb-basic-sample.wiki b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-sample/eiffelweb-basic-sample.wiki
new file mode 100644
index 00000000..60e2f38e
--- /dev/null
+++ b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-sample/eiffelweb-basic-sample.wiki
@@ -0,0 +1,37 @@
+[[Property:title|EiffelWeb Basic Sample]]
+[[Property:weight|0]]
+This sample shows how to retrieve and display information from a basic form on a web page.
+
+{{note| '''Note:''' This sample requires a web server supporting CGI in order to be run. Both the Internet Information Services web server from Microsoft and the GNU Apache server may be used.
+==Compiling==
+
+To compile the example:
+* Launch EiffelStudio.
+* Click '''Add project'''
+* Browse to ''$ISE_EIFFEL\examples\web\basic\''.
+* Choose ''web.ecf''
+* Choose the location where the project will be compiled, by default the same directory containing the configuration file.
+* Click '''OK'''.
+
+==Installing==
+
+You should copy the file ''web_demo.exe'' in the ''cgi_bin'' directory of your web server and the file ''sample.html'' in a directory on the web server.
+
+==Running==
+
+To run the example, access the page ''sample.html'' that you copied on the web server with a web browser (typically '' http://localhost/sample.html''). Fill in the text field with a username and click ''Submit''. You should see a page displaying the name you just entered. Although not earth-shattering, this sample shows the basis for building more complex forms processing in Eiffel.
+
+==Under the Hood==
+
+This basic sample has just one class SAMPLE which inherits from CGI_INTERFACE. SAMPLE implements execute which retrieves the name entered in the form and creates a new HTML page with it.
+
+
+
+See the reference for the class interfaces.
+
+}}
+
+
+
+
+
diff --git a/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-sample/index.wiki b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-sample/index.wiki
new file mode 100644
index 00000000..e31df340
--- /dev/null
+++ b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-sample/index.wiki
@@ -0,0 +1,8 @@
+[[Property:title|EiffelWeb Sample]]
+[[Property:weight|2]]
+The [[EiffelWeb Basic Sample|basic]] sample will get you started on the development of forms processing in Eiffel.
+
+
+
+
+
diff --git a/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/eiffelweb-content-introduction.wiki b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/eiffelweb-content-introduction.wiki
new file mode 100644
index 00000000..2e7601f2
--- /dev/null
+++ b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/eiffelweb-content-introduction.wiki
@@ -0,0 +1,34 @@
+[[Property:title|EiffelWeb Content Introduction]]
+[[Property:weight|0]]
+==CGI Applications==
+
+The way a CGI application communicates with the Web browser is simple: when the user presses a button on an HTML form, with an associated action (such as ''Submit''), the browser starts the application whose path is indicated inside the HTML form declaration. It sends data corresponding to the HTTP request and to the input form information in the usual file descriptor ''In'', stores within environment variables the transaction environment of the request, and waits for the application message, expected in its ''Out'' canal. The ''In'' and '' Out ''canals are accessible via the class CGI_IN_AND_OUT.
+
+HTML forms are an easy way to collect user entries in a web page, which are sent by the browser to the CGI application. A simple example of a form is:
+
+
+
+
+
+When the user presses the submit button, the browser will launch the application located at ''/cgi-bin/convert.exe'' on the server, will use the HTTP Post protocol, and will store among others the environment variable ''Celsius'' with the value entered by the user.
+
+==Advantages of using EiffelWeb==
+
+With EiffelWeb, you can:
+* Design object-oriented systems
+* Access and use the Eiffel libraries
+* Increase maintainability because your code is reusable and readable
+* Deal with complexity because you use a language particularly efficient in the Business Modeling.
+* Use one/a few big Eiffel Web applications, which allow for an easier maintenance and provide better code readability and reusability than having a huge number of scripts.
+* Use the ''Design by Contract'' methodology, thanks to the debugging facilities provided by EiffelWeb.
+
+
+
+
+
diff --git a/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/index.wiki b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/index.wiki
new file mode 100644
index 00000000..f7dd05e3
--- /dev/null
+++ b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/index.wiki
@@ -0,0 +1,12 @@
+[[Property:title|EiffelWeb Content]]
+[[Property:link_title|EiffelWeb Tutorial]]
+[[Property:weight|0]]
+The Common Gateway Interface (CGI) emerged as the first way to present dynamically generated information on the World Wide Web. It allows the computer to process forms filled by the user and return appropriate information.
+EiffelWeb was developed by Interactive Software Engineering to provide Eiffel developers access to the CGI technology. The library makes it possible to write Eiffel systems that interact directly with the WEB.
+{{seealso| '''See Also'''
+[[EiffelWeb Content Introduction|Introduction to EiffelWeb]]
+[[Processing Requests|Processing forms with EiffelWeb]] }}
+
+
+
+
diff --git a/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki
new file mode 100644
index 00000000..5ea1ef05
--- /dev/null
+++ b/documentation/current/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki
@@ -0,0 +1,53 @@
+[[Property:title|Processing Requests]]
+[[Property:weight|1]]
+EiffelWeb provides a complete set of features and interface which helps building a wide range of possible requests.
+
+==Basic CGI Handling==
+
+===Accessing Environment Variables===
+
+Much of the information needed by CGI applications is made available via environment variables. Programs using EiffelWeb can access this information through the class CGI_ENVIRONMENT.
+These variables are usually used for the following purposes:
+* Getting information about the server itself
+* Checking the client browser
+* Restricting Access for specified Domains
+* Ensuring User Authentication and Identifications
+* Dealing with Cookies
+
+===Accessing Input Values===
+
+The browser sends in the ''In'' a stream containing the data relative to the user entry and selection at the applications starts. EiffelWeb stores each data element and its associated name within a Hash-Table, the feature form_data of class CGI_INTERFACE. You can access their values from your code with the interface defined in class CGI_FORMS, which allows you to retrieve text entries, to know whether a button was pressed or not, etc.
+
+===Sending answers to the browser===
+
+The response has to contain an HTTP header in order to be understood by the browser. Depending on the nature of the reply, an HTML page, a simple re-direction, an error notification, you will select different features and options. Your application must send at least a response header, indicating the status of the request if known. You may want to attach to it the text you wish to send back to the user. This text is usually written in HTML, so that it will display nicely on the user's browser; you can use for this purpose the class HTML_PAGE. You may then send the header followed by your text using the features send_to_browser of classes CGI_RESPONSE_HEADER and HTML_PAGE.
+
+{{note| '''Note''': You may not write into a file before you have sent the answer to the browser. }}
+
+===Dealing with Cookies===
+
+You can access the cookies corresponding to a specific URL/domain thanks to the feature cookies, of class CGI_ENVIRONMENT. It is a hash-table, in which all the data with associated names as keys are stored.
+
+To store a cookie on a machine, you can use the feature set_cookies, of class CGI_RESPONSE_HEADER.
+
+==Advanced Topics==
+
+===EiffelWeb and Security===
+
+The information the server sends back may be confidential. Follow these steps to protect the page content:
+# Create an HTML page, for example by using class HTML_PAGE.
+# Store this page somewhere, with a random name.
+# Create an instance of class CGI_RESPONSE_HEADER and choose the secure redirect option. Then call send_to_browser.
+
+===Complex Headers===
+
+The Eiffel-Web application has the possibility to send a selection of different HTTP headers. They can be found in class CGI_RESPONSE_HEADER. In particular, it is advised to generate a status for each request, the value of the most common ones may be found in class CGI_ [[ref:/libraries/web/reference/cgi_common_status_types_chart|COMMON_STATUS_TYPE]] .
+
+===Debugging facilities===
+
+Design by Contract is one of the greatest strengths of the Eiffel language. When you usually run your application from EiffelStudio, you are notified when an assertion is violated and the tool offers different options in order to be able to find out its sources (feature and class tools, object inspectors, etc). However this cannot be applied to an EiffelWeb application, since it has to be run on the server.
+Therefore, EiffelWeb provides its own facilities for debugging. To test your classes at run-time, all you need to do is to set the Boolean feature is_debug_mode to True in your root class (which should inherit from CGI_INTERFACE). When your application crashes (because of an assertion ora bug), the exception trace will be displayed on the screen.
+
+
+
+
diff --git a/documentation/current/solutions/web-technology/eiffelweb/index.wiki b/documentation/current/solutions/web-technology/eiffelweb/index.wiki
new file mode 100644
index 00000000..dd3fde39
--- /dev/null
+++ b/documentation/current/solutions/web-technology/eiffelweb/index.wiki
@@ -0,0 +1,16 @@
+[[Property:title|EiffelWeb Library]]
+[[Property:link_title|EiffelWeb]]
+[[Property:weight|1]]
+Type: Library
+Platform: Any
+
+
+See:
+* [[EiffelWeb Content|Content]]
+* [[EiffelWeb Sample|Samples]]
+* [[ref:libraries/web/reference/index|Reference]]
+
+
+
+
+
diff --git a/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki b/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki
new file mode 100644
index 00000000..4ba04de6
--- /dev/null
+++ b/documentation/current/why-eiffel/eiffel-two-minute-fact-sheet.wiki
@@ -0,0 +1,92 @@
+[[Property:title|Eiffel: The Two-Minute Fact Sheet]]
+[[Property:weight|0]]
+If you are both curious about Eiffel and in a hurry, take a couple of minutes to read these facts about Eiffel. If anything here seems too good to be true, please suspend your disbelief. Press on to the more detailed documentation for the rationale, and our success stories for the evidence behind these facts.
+
+===Eiffel is the most comprehensive approach to the construction of successful object-oriented software.===
+
+Software produced with Eiffel is typically:
+
+*Cheaper -- You spend less on development, debugging, maintenance
+*Better -- You get the bugs before they get you
+*Shorter time-to-market -- You release quality products ahead of your competitors
+*Easier -- In every way: understanding, maintenance, reuse, and extension
+
+===Systems developed using Eiffel can be made portable across major industry platforms.===
+
+*Windows NT/2000/XP/Vista including CLS compliance on Microsoft .NET
+*Major Unix versions
+*Macintosh OS X
+*Linux
+*OpenVMS
+
+===Eiffel is the only approach that covers analysis, design, implementation and maintenance in a single framework.===
+
+Eiffel consists of:
+
+====The Eiffel Method====
+
+*Is Based on a small number of powerful ideas from computer science and software engineering
+**An example of these is Design by Contract
+***Defines a software system as a set of components interacting through precisely specified contracts
+***Contracts are active and enforceable throughout the life-cycle
+***Design by Contract promotes:
+****Precise software specification
+****Software reliability
+****Safe, effective software reuse
+*Uses a "single-product" model
+**All life-cycle phases are supported by a single notation
+***No need to switch, say, from "analysis language" to "design language"
+**Products of all phases are recorded in a single document with multiple views
+
+====Eiffel the Language====
+
+*Exists to express the products of the Eiffel Method
+*Supports features not always available in competing technologies
+**Contracts and contract monitoring
+**Exception handling based on software specification (versus ad hoc try/catch)
+**Inheritance, including safe, controllable multiple and repeated inheritance
+**Genericity (generic classes), including constrained genericity
+*Widely recognized as simultaneously the simplest and most complete implementation of object-oriented concepts
+*Is clean, elegant, readable, easy to learn
+
+
+====EiffelStudio and the Eiffel Libraries====
+
+*'''EiffelStudio'''
+**Runs on all major platforms (of course, it's built with Eiffel)
+**Features lightning-fast compilation (Melting Ice Technology)
+**Generates lightning-fast executables
+***Final compilation generates standard C (MSIL in the case of .NET)
+***Speed of executables rivals native C
+**Provides multiple views of your product
+***Views for different life-cycle phases and developer roles
+***Graphical views
+**Features automated generation HTML and XML documentation
+
+*'''The Eiffel Libraries'''
+**Contain rich, time-tested, multi-platform components
+**Include facilities for
+***GUI building and graphics
+***Web
+***Networking
+***Fundamental algorithms and data structures
+***Object persistence and database access
+***Multi-threading
+***Lexical analysis and parsing
+***Interfacing with other technologies
+
+===Eiffel has a proven track record of successful projects===
+
+*Some of the largest successful object-oriented projects ever built, including systems target to:
+**Finance and securities
+**Education
+**Trading
+**Manufacturing
+**Telecommunications
+**Government and national defense
+**Science
+
+For a more detailed overview see [[Invitation to Eiffel|An Invitation to Eiffel]] .
+
+
+
diff --git a/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki b/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki
new file mode 100644
index 00000000..684be96b
--- /dev/null
+++ b/documentation/current/why-eiffel/why-your-next-project-should-use-eiffel.wiki
@@ -0,0 +1,140 @@
+[[Property:title|Why your next project should use Eiffel]]
+[[Property:weight|1]]
+(After an article in the special Eiffel issue of the ''Journal of Object-Oriented Programming'', May 1996. )
+
+
+Over its ten-year life Eiffel has evolved into one of the most usable software development environments available today. Other articles discuss its theoretical contributions. This one addresses a more mundane subject: how practical software projects can benefit, today, from the power of Eiffel. In so doing it will largely rely on published assessments from both Eiffel users and book authors. In fact a quotation from one of the best-known books in the object-oriented field -- ''Object-Oriented Modeling and Design'' by James Rumbaugh and his colleagues, the text that introduced the OMT O-O analysis method -- provides a good start:
+
+{{note| ''Eiffel is arguably the best commercial object-oriented language available today. [Jim Rumbaugh et al. in Object-Oriented Modeling and Design, Prentice Hall 1988]. '' }}
+
+==What is Eiffel?==
+
+First we should define what the word "Eiffel" means. If you are thinking "a programming language" you are not wrong (and the preceding quotation shows that you are in good company). The programming language is indeed the most visible part, but it is only a reflection of something broader: a comprehensive approach to the production of quality software. As Richard Wiener wrote:
+
+{{note| ''Eiffel is more than a language; it is a framework for thinking about, designing and implementing object-oriented software. [Richard Wiener in Software Development using Eiffel: There is life other than C++, Prentice Hall, 1995. ] '' }}
+
+The Eiffel approach includes a method (a "methodology", as it is sometimes called) based on a number of pervasive ideas such as Design by Contract, seamlessness, reversibility, rigorous architectural rules, systematic use of single and multiple inheritance, static type checking and several others. Besides a method and a language Eiffel also means powerful graphical development environments, such as EiffelStudio, available across a wide number of industry-standard platforms and supporting analysis and design as well as implementation, maintenance and evolution.
+
+The language itself, indeed (which Wiener calls an elegant and powerful language for object-oriented problem solving") is not just a programming language but extends to the phases of system construction that both precede and follow implementation. This is sometimes hard to accept if you have been raised in the view that software development must involve a sequence of separate steps; that one should initially use an analysis method and then at some point switch to a programming language, with perhaps a design method in-between. This view is detrimental to the software process and to the quality of the resulting product, as it does not support the inevitable back-and-forth hesitations that characterize real software development.
+
+Wisdom sometimes blooms late in the season. However careful you may have been at the analysis stage, some great ideas will hit you - or your implementers - past the point at which you thought you had all the specifications right. Why renounce the benefit of such belated but valuable ideas? Eiffel and the associated Business Object Notation approach to analysis and design accommodate them naturally, by providing a single conceptual framework from the beginning to the end of the process.
+
+Here Eiffel does not have much competition. The most bright-eyed Smalltalk or C++ enthusiast would not seriously claim that one can do design, let alone analysis, in his language of choice. And users of any of the popular O-O analysis notations know that at some stage they must stop working on their model and move on to the implementation in some programming language. Eiffel is unique in helping you for all of these tasks, without ever introducing the impedance mismatches that characterize other approaches.
+
+As a reviewer wrote:
+
+{{note| ''As a design language, Eiffel continues to be a better model for object- oriented programming than Ada. It is even better than the new Ada 9X standard. [Richard Riehle in HP Professional, October 1994, A Tour of Eiffel. ] '' }}
+
+==The commercial and political context==
+
+The next few sections give a glimpse of the technical contributions of Eiffel, or more precisely of what other people have written about them. But of course the best technology in the world requires infrastructure and support to succeed.
+
+Eiffel has plenty of these. It has been around for more than a decade. Eiffel is available from several commercial and open-source providers. The number of licenses sold is in the tens of thousands. Reusable library classes are in the thousands.
+
+The platforms covered range from Unix (all of Unix, the famous and the arcane) and Linux to VMS, OS/2, Windows 3. 1, Windows NT, Windows 95/98.
+
+Particularly impressive is the growth of Eiffel usage in education. Eiffel is quickly becoming the language of choice for teaching modern software technology, including, increasingly, introductory programming. A dozen of excellent textbooks are now available from Prentice Hall, Addison-Wesley, Macmillan and others, with about as many announced just for the coming months.
+
+It is not just the professors who like the approach. Here is just one typical comment on student reaction, from an institution (Rochester Institute of Technology) having adopted Eiffel as its first-year introductory language on a massive scale:
+
+{{note| ''We were pleased to discover many of our more skeptical students turning around and admitting that Eiffel was a "fun" language in which to work. [Jim Heliotis in the Proceedings of OOPSLA 95, Experiences teaching objects: A new curriculum for computer science students. ] '' }}
+
+A Computer World article confirmed the need for Eiffel in training the high-powered software professionals of tomorrow. Quoting Amy Cody-Quinn from Management Recruiters International, the journalist writes
+
+{{note| ''There is a big problem with people who say they know C++ - but they don't really know how to do objects. If they have Eiffel on their resume, then we know they really have the proper understanding of what they are doing. [Leslie Goff in ComputerWorld, Object Edge, December 18, 1995. ] '' }}
+
+But it would be a mistake to think of Eiffel as an academic tool. A little-known fact is that some of the biggest object-oriented projects ever undertaken (at least the successful ones - other O-O languages have had their share of large-scale failures) are being done in Eiffel. The hot areas at the moment are banking and the financial industry (in particular some very large derivative trading and investment management systems), telecommunications, health care. These are all areas in which all that counts in the end is quality and time to market, so that projects need to select the best technology available. Quoting from an article by Philippe Stephan, the system architect of such a project (Rainbow, a major derivative trading system built with ISE Eiffel):
+
+{{note| ''We evaluated three major object-oriented languages for the project - Smalltalk, C++ and Eiffel - and chose Eiffel. [...] Rainbow currently comprises over 400,000 lines of code, for about 3000 classes. [Current figures are way over these mid-1995 counts. ] The developers feel very productive. This was confirmed when Rainbow's financial backers brought in object professionals to audit the project. The auditors evaluated the project during July 1994 and were impressed with the productivity of the Rainbow development group. [Philippe Stephan in Object Magazine, July-August 1995, Building financial software with object technology. ] '' }}
+
+The development group in question is remarkable for being made only for a third of software professionals. The others are professionals from other disciplines (such as trading and financial analysis), who, Stephan writes,
+
+{{note| ''can express business concepts in Eiffel because they can focus on design and implementation, rather than struggling with memory management problems and debugging. '' }}
+
+The result has received lavish praise from such publications as ComputerWorld and analysts:
+
+{{note| ''Industry experts briefed on Rainbow said they were impressed with the results. CALFP is "progressive" in [...] committing the organization's mission-critical systems development efforts to this architecture, said Richard Crone, senior manager of financial services at KPMG Peat Marwick in Los Angeles. "What's unique here is that [CALFP is] delivering this system end-to-end using object-oriented technologies", said Henry Morris, a research analyst at International Data Corporation (IDC) in Framingham, Mass. [Thomas Hoffmann in ComputerWorld, May 8, 1995, Object- Oriented financial package tames transactions. ] '' }}
+
+Along with these Eiffel mega-projects, you will also find myriad smaller endeavors. Many consultants, in particular, have found for themselves the key competitive advantage that they can gain from Eiffel's excellence. In ensuring this spread of Eiffel throughout the industry, the benefit of cheap yet complete environments such as EiffelStudio for Linux has been immeasurable.
+
+Also crucial to the development of Eiffel has been the neutral status of its definition, now controlled by a consortium of vendors and users, NICE (the Nonprofit International Consortium for Eiffel). NICE has already produced a library standard and expects to produce soon the language standard that should shortly thereafter enjoy a smooth ride through ANSI and other international standards bodies.
+
+The pace of Eiffel history has been accelerating in the past few months. This has been picked up by many journalists. As Dan Wilder wrote:
+
+{{note| ''With an open specification for both the language and the kernel libraries, and support from multiple vendors, Eiffel now stands poised to take off. [Dan Wilder in Linux Journal, June 1995, Introduction to Eiffel. ] '' }}
+
+==The criteria==
+
+{{note|Eiffel - the method, the language, the environment - is based on a small set of goals, addressing the crucial needs of software quality and productivity. Quoting from an article in ''Byte'' magazine: }}
+
+{{note| ''Developers who want an object-oriented language that adheres to the keystone principles of software engineering need look no further than Eiffel. [Peter Varhol in Byte Magazine, February 1996. ] '' }}
+or, as Steve Bilow wrote in a review of Eiffel Software's Melting Ice compiling technology (which he calls "an outstanding marriage between portability and development speed"):
+{{note| ''Eiffel was designed precisely for the purpose of enabling software developers to deliver high quality, reliable, efficient, reusable code. [Steve Bilow in The X Journal, The Eiffel alternative, July-August 1995. ]'' }}
+
+==Reliability==
+
+The first goal is reliability. No other approach available today has made the effort to give developers all the tools that they need to produce bug-free software - software that will run without bugs the first time around. Crucial in this effort is the presence of static typing ( ''real'' static typing, not "a little bit typed" as in those languages that still keep C-like type conversions); assertions and the whole mechanism of Design by Contract, on which more than one Eiffel developer has said "this has changed my life" by enabling him or her to specify precisely what the software should do, and to track at run time that it does it; disciplined exception handling; automatic garbage collection, which eliminates a source of horrendous bugs in C++-based environments (and a large part of the code, tedious and error-prone); a clean approach to inheritance; the use of dynamic binding as the default policy, meaning the guarantee that all calls will use the right version of each operation; and the simplicity of the language design, which enables Eiffel developers to know '''all''' of Eiffel and feel in control.
+
+The role of assertions and Design by Contract is particularly important here. According to the ''Journal of Object-Oriented Programming'':
+
+{{note| ''The contribution of Eiffel is significant: it shows how invariants, preconditions, and postconditions can be incorporated into a practical developer's view of a class. Wider use of Eiffel [...] will encourage a greater use of simple but powerful mathematics during development. [Richard Mitchell et al. in Journal of Object-Oriented Programming, July-August 1995, As-a: a relationship to support code reuse. ] '' }}
+
+==Reusability==
+
+The second goal is reusability. This has become a catchword, but Eiffel is the only approach that has taken this requirement and its consequences all the way to the end. Quoting Roland Racko:
+
+{{note| ''Everything about [Eiffel] is single-mindedly, unambiguously, gloriously focused on reusability - right down to the choice of reserved words and punctuation and right up to the compile time environment. [Roland Racko in Software Development, December 1994, In praise of Eiffel. ] '' }}
+
+Eiffel benefits here from being a simple ("but not simplistic", writes Racko) and consistent design, not a transposition from older, unrelated technology. Beyond the language and the environment facilities (such as precompilation), the crucial help to reusability is of course the presence of thousands of high-quality library ''classes'', such as, in EiffelBase (a "Linnaean approach to the reconstruction of software fundamentals"), EiffelNet for client-server communication, EiffelStore for relational and O-O database manipulations, EiffelLex and EiffelParse for lexical analysis and parsing, EiffelMath for object-oriented numerical computation, EiffelVision for portable graphics, WEL (the Windows Eiffel Library) for Windows-specific graphics, EiffelWeb to process forms from the Web, and many others. Not even mentioning quality, the result is probably the biggest repository of object-oriented components available elsewhere. The care that has been applied to the production of these libraries also has considerable pedagogical benefits: the way people learn Eiffel is by learning the libraries - first to use them, then to adapt them if necessary, then to write their own software.
+
+Part of the single-mindedness mentioned by acko is the emphasis on abstraction. In contrast with, say, Smalltalk, you do not read the source code of a class when you want to use it. This may be fine for a couple dozen classes, but not for a large, powerful library. Eiffel introduces the notion of '''short form''': an abstract version of the class, keeping only the interface information including assertions. This is an ideal tool for documenting classes but also for discussing designs and presenting them to outsiders - managers or customers - who need to know what is going on without getting bogged down in the details.
+
+Let me mention just one of the unique reusability-supporting features of Eiffel, without which it is, in my experience, impossible to have a long-term reuse effort. Racko again:
+
+{{note| ''The language's designer [...] recognized that no reusable library is ever perfect and, thus, that libraries are always in flux. So he built a kind of version-control system into the language. Specifically, there are language elements to demarcate obsolete code that is, however, still being supported. When these elements are referenced by someone unaware of such code's obsolescence, the compiler will issue a warning at compile time about the impending doom that awaits persons who continue the referencing. '' }}
+
+It is this kind of detail that can make or break the success of reuse in a company.
+
+==Extendibility==
+
+Next comes extendibility. With Eiffel, modifying software is part of the normal process. As Philippe Stephan writes of the external audit of his project:
+
+{{note| ''The auditors rated the responsiveness of the development team as very high. '' }}
+
+Chief among the method's support for extendibility is the careful design of the inheritance mechanism. Unlike Smalltalk, which is fatally limited by the absence of multiple inheritance, the Eiffel approach fundamentally relies on multiple inheritance to combine various abstractions into one. As Dan Wilder notes:
+
+{{note| ''Most object-oriented languages do not attempt multiple-inheritance. The literature is full of elaborate explanations why. This is sad. Eiffel demonstrates that multiple inheritance need not be difficult or complex, and it can also yield some quite practical results. '' }}
+
+The approach also enforces a strict form of information hiding, which means that a module (a '''client''' in Eiffel Design by Contract terminology) that uses another's facilities (its '''supplier''') is protected against many of the changes that can be made later on to these facilities. This is essential in preserving the coherent evolution of a large system - and the sanity of its developers.
+
+==Efficiency==
+
+Performance is almost as much an obsession in Eiffel as reusability. The software field is still, and will remain for a long time, largely driven by performance considerations. (Do not believe anyone who says that speed does not matter. If we get faster computers, it is to do things faster and especially to do more things - not to use more CPU cycles to run the same old applications at the same old visible speed. )
+
+There is no reason whatsoever to leave the mantle of efficiency to the proponents of machine-oriented languages such as C/C++, or to follow the path of Smalltalk which sacrifices performance to object orientation. With Eiffel you can have the best of both worlds. Thanks to a performance-obsessed language design and ten years of research and competition on compiling algorithms, the speed of Eiffel-generated code (in such modes as what is known as "finalization" in Eiffel Software's implementation) is as good as that of hand-produced C code, or better.
+
+Software producers should stand up to their ideas. That is what we do at Eiffel Software: apart from the run-time engine (a few thousand lines of C), all of our software - thousands of classes, hundreds of thousands of lines - is written in Eiffel, and it runs fast. Typical of the situation is a recent incident with the EiffelLex library: it still had a few C elements, remnants of an earlier design. We rewrote them in Eiffel - for a 30% performance gain.
+
+Why these gains? The answer is simple. The /C++ approach of doing everything by hand, under tight programmer control, works well for small programs. Similarly, a good secretary has no equivalent for keeping one person's records. But in the same way that no humans can match the performance of a computer for managing, say, the records of a bank or a city, no programmer can beat a sophisticated Eiffel compiler for optimizing a large program. Against the automatic application of inlining, static binding, memory management and other optimizations, the human does not stand a chance.
+
+To have one's cake and eat it also means not to have to choose between run-time and compilation-time performance. For programmers used to the contrast between a Smalltalk-like style of rapid turnaround and the interminable edit-compile-link cycle of most compiled environment, the following comments by Dan Wilder (in a separate article) will be a shock:
+
+{{note| ''EiffelStudio uses "melting ice technology", which allows incremental changes to run in an interpreted mode. Only modified classes are recompiled. Changing one class and clicking the Melt button caused only a few seconds of compilation. [...] My test application took 20 seconds to compile from scratch in "melt" mode. [Dan Wilder in Linux Journal, September 1995, Two Eiffel implementations. ] '' }}
+Steve Bilow provides further explanations:
+{{note| ''Based on the observation that software development is an iterative process which is usually focused on constructing systems from code modifications, the folks at Eiffel Software have developed something that they call "Melting Ice Technology". Essentially, this means that when you make a [change] and you want to try it out, you simply "melt" it into the system. You don't need to regenerate a bunch of C code, so your changes are integrated into the system proportionally to the amount of code changed. Even in C and C++, `make' still has to relink. '' }}
+
+What this also indicates in passing is the technology choice made by Eiffel Software's implementation and all current implementations: using C as the portable implementation vehicle. By going through C, the compilers gain efficiency and portability. This also makes Eiffel one of the most open environments around; in contrast to the self-centered view that predominates in Smalltalk, Eiffel software is born with a sociable attitude, ready to interface with all kinds of other software written in C or other languages. This, needless to say, is a key to the success of realistic applications.
+
+==With us, everything is the face==
+
+A good way to think about Eiffel - the seamlessness of it, the insistence on getting everything right, the conviction that software should be beautiful in and out, specification and implementation - is this little anecdote stolen from Roman Jakobson's Essays on ''General Linguistics'':
+
+{{note| ''In a far-away country, a missionary was scolding the natives. "You should not go around naked, showing your body like this!". One day a young girl spoke back, pointing at him: "But you, Father, you are also showing a part of your body!". "But of course", the missionary said in a dignified tone; "That is my face". The girl replied: "So you see, Father, it is really the same thing. Only, with us, everything is the face". '' }}
+
+So it is with Eiffel too. Everything is the face.
+
+Hundreds of thousands of people have now been exposed to Eiffel through books, through courses, through hearing about other people's successes, and most importantly (for the most fortunate among them) through using it to complete a project on time, within budget, and to the satisfaction of their customers. Shouldn't your next project use Eiffel too?
+
+
+
+