1. Open your Unity project and click Assets->Import Package->Custom Package...
   
   
2. Locate the core EZ GUI unityPackage file which came with the EZ GUI distribution. Select it and click “Open”. Import all files.

1. Attach a UIManager script to a GameObject in the scene and set its various options. (See UIManager for more details.)
   
   
2. Add an empty GameObject to the scene and drag one of the many control scripts onto it (such as UIButton).
   
   

1. Create an empty GameObject.
   
   
2. Click Component > EZ GUI > Controls > Button.
   
   
3. You'll now see lots of settings listed in the inspector that are inherited from the various sprite base classes as well as a few settings that are specific to this control. We will cover these later. For now, open the UI Control Editor window and we will proceed to define our button's visual appearance. To do this, click Window > UI Control Editor.
   
   
4. In the UI Control Editor you will find a selection of "states" that are supported by the selected control. Drag textures onto the texture slots to define the appearance the button will have when in each state. The states for the Button control are:
   • Normal
   • Over
   • Active
   • Disabled
   
   
5. Now select a material for the control (if not managed) and build its graphics to an atlas (see Building Atlases for details). Now you should be able to check Pixel Perfect or manually set a width/height. You may now need to press play briefly and the button should appear.
   
   
6. Now that we have defined the appearance of our button, we want our button to cause something to happen (call into our code) when clicked. We can register a delegate in-code by calling the button's SetValueChangedDelegate() method, but the easiest way to get up and running quickly is to make the member in the inspector labeled Script With Method To Invoke point to a GameObject containing the script that will serve as our input handler. We then fill in the Method To Invoke with the name of the method we want to receive input from our button. NOTE: This is case-sensitive and does not include the function/method's "()".
   
   
7. Finally, we set When To Invoke to match the type of event we want our code to respond to. This defaults to TAP. This means that when the button is tapped (pressed and then released), our code will get called.

The button should now function normally. If clicked, your input handling script should be called. Note that a box collider was added automatically. If you want, you can assign your own colliders.

You will find that, for the most part, the process to setup every control is largely the same as the above. To learn more about each control type, see Controls.

Making Changes

Always remember, whenever you make changes to a control's textures, you must rebuild your atlases for the changes to take effect.

IMPORTANT NOTE: If your game consists of more than one scene that contain identical controls, or you have any sprite-based control prefabs, it is recommended that every control you create be associated with a prefab, and then as you make design changes to your controls (such as changing their textures), only make these changes to the prefabs and let the instances of those prefabs in your scene(s) be automatically updated. Making changes directly to controls in a scene which are linked to a prefab will cause the properties you change to "override" the same properties in the prefab. The problem with this is that the atlas builder will skip prefab instances and only look at the "source" prefab, meaning a prefab instance that has a different set of textures than its original prefab will not get updated with the correct UVs and will not have its differing source textures included on the atlas. This is by design so that controls in a non-open scene do not get "left behind" when a new atlas is generated.
The rule of thumb is to manage and keep all your control types in prefabs and only modify the properties of the prefabs themselves and not the prefab instances in a scene.