Author:king

Date:2009-05-26T00:13:41.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@228 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki

@@ -26,6 +26,7 @@ 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.
+
 <span id="file_pattern"></span> 
 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:
 
@@ -36,6 +37,7 @@ Exclude rules are regular expressions which are matched against directories and
 {{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<br/>
 Matching would now be first done against ''/interface'' and then against ''/interface/ignore_me.e''<br/>
 A rule like ''^/interface$'' would exclude the whole subdirectory, a rule like ''^/interface/ignore_me\.e$'' would only exclude the ignore_me.e class. }}
+
 <span id="condition"></span> 
 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:
 

documentation/current/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki

@@ -2,33 +2,30 @@
 [[Property:link_title|Converting EiffelVision 2 Systems to Void-Safety]]
 [[Property:weight|1]]
 [[Property:uuid|96e01318-700b-da6e-42d1-14fee219daf5]]
-Converting EiffelVision 2 System to Void Safety
+==Introduction==
 
 In order to convert systems that employ EiffelVision 2 (Vision2) to void-safety, some adjustments may be needed depending on its usage.  This document describes the various usage scenarios of Vision2 that will need converting to adhere to void-safety.
 
-Inheritance purely from an Interface Class
+==Inheritance purely from an Interface Class==
 
-If you have classes that inherit from a Vision2 interface class such as EV_DRAWING_AREA, the first change that has to be made is to alter 'initialize' so that any types that are attached (ie: types that remain non-void throughout the lifetime of its housing parent object) are initialized via 'create_interface_objects', this needs to be redefined if the type from Vision2 is instantiable, if not then it may need to be made effective (such as inheritance directly from EV_ANY).  It is important that any attached types in the interface class are instantiated in `create_interface_objects' and these objects are initialized via 'initialize'.  Attached types should not be instantiated in `initialize' due to the bridge pattern implementation and initialization of these types in `create_interface_objects' MUST be performed via 'initialize', otherwise unexpected behavior may occur as the bridge pattern has not been fully set up at this point in time.
+If you have classes that inherit from a Vision2 interface class such as EV_DRAWING_AREA, the first change that has to be made is to alter 'initialize' so that any types that are attached (ie: types that remain non-void throughout the lifetime of its housing parent object) are instantiated via 'create_interface_objects', this needs to be redefined if the type from Vision2 is instantiable, if not then it may need to be made effective (such as inheritance directly from EV_ANY).  It is important that any attached types in the interface class are instantiated in `create_interface_objects' and these objects are initialized via 'initialize'.  Attached types should not be instantiated in `initialize' due to the bridge pattern implementation and initialization of these types in `create_interface_objects' MUST be performed via 'initialize', otherwise unexpected behavior may occur as the bridge pattern has not been fully set up at this point in time.
 
 Example from EV_TIMEOUT
+<code>
+   create_interface_objects
+         -- <Precursor>
+      do
+         create actions
+      end
+   
+   create_implementation
+         -- Create implementation of timeout.
+      do
+         create {EV_TIMEOUT_IMP} implementation.make
+      end
+</code>
 
-
-feature {NONE} -- Implementation
-
-create_interface_objects
--- <Precursor>
-do
-create actions
-end
-
-create_implementation
--- Create implementation of button.
-do
-create {EV_TIMEOUT_IMP} implementation.make
-end
-
-
-Inheritance from an Implementation Interface Class with associating interface class
+==Inheritance from an Implementation Interface Class with associating interface class==
 
 If you have an existing, custom platform dependent implementation, there are a few more changes needed than what was required for the interface class.
 
@@ -37,7 +34,7 @@ For the interface class changes, now the interface object is passed to the imple
 
 An example from the conversion of Windows implementation of EV_BUTTON_IMP.
 
-
+<code>
    make (an_interface: like interface) 
            -- Create `Current' with interface `an_interface'. 
        do 
@@ -57,9 +54,11 @@ An example from the conversion of Windows implementation of EV_BUTTON_IMP.
        end
 
     interface: EV_BUTTON;
+</code>
 
 would become: 
 
+<code>
    make 
            -- Initialize `Current'. 
        do 
@@ -73,11 +72,12 @@ would become:
        end
 
     interface: detachable EV_BUTTON note option: stable attribute end;
+</code>
 
 The following steps are needed during the conversion:
 
-- The attribute 'interface' needs to be made a stable attribute
-- Copy any initialization of the widget from 'make' to 'initialize' excluding `base_make' setup.  Any initialization code that relies on `interface' would have to be rewritten so that this gets passed to new creation routine that in turn calls the original `make'.  See EV_PRINT_PROJECTOR_IMP on Windows `make_with_context' for an example of this.
-- Remove `make', rename `initialize' to `make', make sure that any calls to Precursor do not override any settings set in 'initialize', the ordering may need to be changed in order to make the code void-safe so.  See EV_POPUP_WINDOW_IMP.make (Windows implementation) where the setting of 'user_can_resize' is performed after the Precursor call so that is doesn't get overriden.
+* The attribute 'interface' needs to be made a stable attribute, the converted 'interface' attribute shows the syntax for doing so.
+* Copy any initialization of the widget from 'make' to 'initialize' excluding `base_make' setup.  Any initialization code that relies on `interface' would have to be rewritten so that this gets passed to new creation routine that in turn calls the original `make'.  See EV_PRINT_PROJECTOR_IMP on Windows `make_with_context' for an example of this.
+* Remove `make', rename `initialize' to `make', make sure that any calls to Precursor do not override any settings set in 'initialize', the ordering may need to be changed in order to make the code void-safe so.  See EV_POPUP_WINDOW_IMP.make (Windows implementation) where the setting of 'user_can_resize' is performed after the Precursor call so that is doesn't get overriden.