diff --git a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
index 02214cc1..4ec77f13 100644
--- a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
+++ b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
@@ -226,11 +226,11 @@ As with the other examples of the '''attached syntax''', it is no longer necessa
 
 ==More about CAPs==
 
-You might wonder about the use of a CAP using a <code>check</code> like this:
+You might wonder about the use of a CAP which employs a <code>check</code> instruction like this:
 
 <code>
     my_detachable_any: detachable ANY
-
+            ...
     my_attached_any: ANY
         local
             l_result: like my_detachable_any
diff --git a/documentation/current/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki b/documentation/current/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki
new file mode 100644
index 00000000..88d7adc7
--- /dev/null
+++ b/documentation/current/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki
@@ -0,0 +1,83 @@
+[[Property:title|Converting EiffelVision 2 Systems to Void Safety]]
+[[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
+
+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
+
+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.
+
+Example from EV_TIMEOUT
+
+
+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
+
+If you have an existing, custom platform dependent implementation, there are a few more changes needed than what was required for the interface class.
+
+For the interface class changes, now the interface object is passed to the implementation after creation, via `assign_interface', this means that `make' no longer takes an argument.  This also means that to adhere to void-safety all of the types are now created and initialized via the creation routine of the implementation object.
+
+
+An example from the conversion of Windows implementation of EV_BUTTON_IMP.
+
+
+   make (an_interface: like interface) 
+           -- Create `Current' with interface `an_interface'. 
+       do 
+           base_make (an_interface) 
+           wel_make (default_parent, "", 0, 0, 0, 0, 0) 
+           extra_width := 20 
+           text_alignment := default_alignment 
+               -- Retrieve the theme for the button. 
+           open_theme := application_imp.theme_drawer.open_theme_data (wel_item, "Button") 
+       end 
+
+   initialize 
+           -- Initialize `Current'. 
+       do 
+           Precursor {EV_PRIMITIVE_IMP} 
+           set_default_font 
+       end
+
+    interface: EV_BUTTON;
+
+would become: 
+
+   make 
+           -- Initialize `Current'. 
+       do 
+           wel_make (default_parent, "", 0, 0, 0, 0, 0) 
+           extra_width := 20 
+           text_alignment := default_alignment 
+               -- Retrieve the theme for the button. 
+           open_theme := application_imp.theme_drawer.open_theme_data (wel_item, "Button") 
+           Precursor {EV_PRIMITIVE_IMP} 
+           set_default_font 
+       end
+
+    interface: detachable EV_BUTTON note option: stable attribute end;
+
+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.
+
+