Learning Flex 3

Handling user input is what makes an application tick. Dealing with mouse clicks, dragging, typing on the keyboard, and such is where the fun is. Otherwise, you wouldn’t have an application; you’d have just an animation or a static image, and that’s, well, comparatively boring.

However, understanding what someone using your application does and responding to that action takes some planning and work. You have to account for every interaction that you think is important. Basically, you’re thinking about what a user might want to do and preparing for that. Of course, this can be a challenge, but it can be really rewarding as well.

Figure 6-1. The click event play-by-play

Understanding Events

A Flex application responds to user input by something called an event. An event is something that happened, either by user interaction, or by other things happening such as a photo appearing or data returning from a server. (Getting data from a server is covered briefly in Chapter 10.) When a user clicks a button, for instance, an event occurs. (The event for clicking something is called—you guessed it—click.) And when a button is created, an event also occurs. (This event is called creationComplete.) When the event happens, you say the event fired or was dispatched. To respond to such an event, you set up something called an event handler or listener.

Handling Events Inline

MXML makes listening for events very simple. All you have to do is add the proper event attribute to a tag and tell it what to do. This could mean calling a function or just modifying a property. The following code example shows a Button (myButton) that changes the text of a Label (myLabel), as shown in Figure 6-1, by modifying the Label’s text property. You do this simply by adding the attribute click to the Button:

<mx:Label id="myLabel" text="The Button will change my text" /> 
<mx:Button id="myButton" label="Change it!" click="myLabel.text = 'Some new text'"/>

The same goes for other events, such as when a TextInput’s text changes by a user typing into the component. That’s a change event, so the following code would cause a TextInput to modify the Label:

<mx:Label id="myLabel" text="The TextInput will change my text" /> <mx:TextInput id="myTextInput" change="myLabel.text = 
myTextInput.text"/>
                      

This code modifies the Label’s text to match the TextInput’s text any time the TextInput’s text changes. There’s actually a better way to make a property update itself automatically when another property changes, and that’s called data binding. I’ll go into more detail on that in Chapter 7.

While there’s no limit to the number and names of events that a component can use, you will see a few old standards. Table 6-1 lists the most common types of events.

Of course, tons more events exist, and many are specific to certain controls, but knowing the events in Table 6-1 will get you pretty far. You can see what kinds of events a specific control offers in a few other ways:

• In Design mode, click a control that’s been added to the stage, and look at the Flex Properties panel’s Category view. Check out the Events section in that list, and you’ll see every event available for that component.
• In Source mode, when using code completion on a component, all of its properties will pop up. The events will be listed with a little lightning bolt icon next to them.
• Check out the documentation for a component by selecting Help→Help Contents and searching for a component or by selecting a component in Source mode and then selecting Help→Find in Language Reference. At the top of every component’s documentation page are links to its properties, methods, and events. Check out its list of events for details. (See the sidebar “Reading Flex Documentation” for more information.)

Reading Flex Documentation

Flex comes with some of the best documentation of any programming language. You can access this documentation by going to Help→Help Contents when in Flex Builder, or you can access it online at http://livedocs.adobe.com/flex/3/.

The Flex documentation contains a number of articles on using every aspect of Flex, so once you’re keen on using the documentation, you can find pretty much everything you need to build your skills, including lots of example code. Often, you’ll find exactly what you’re looking for by using the search functionality in the documentation.

One of the most useful parts of the documentation is the Flex 3 Language Reference, which contains all the information you need to use Flex components. It might seem daunting at first, but once you get the hang of it, you’ll find yourself visiting it quite a bit.

There are a few ways to get to the Language Reference. One is to search for a component by name, such as Button. Another is when you’re using Flex Builder in Source mode—from there you can get the details for a specific component by selecting the component and going to Help→Find in Language Reference. Otherwise, you can browse for the Language Reference by using the table of contents, where you’ll choose Adobe Flex 3 Help, then Adobe Flex 3 Language Reference. Typically, you’ll access the reference when you’re looking for the specifics of a component, so I recommend either searching for the component or using the Find in Language Reference feature of Flex Builder.

Once you look at the reference for a particular component, you’ll see something similar to Figure 6-2. At the top of every component’s reference is a list of its available properties, methods, events, styles, and so on—even a link to examples is included.

Figure 6-2. The Flex Language Reference for Button

To see the available events for a component, you could click the Events link at the top, or scroll your browser to the Events heading. There you’d see the list of events as pictured in Figure 6-3. However, like other properties of a component, there may be a large list of inherited events which you can see by clicking “Show Inherited Events.” Components typically inherit functionality from a higher-level class, so to view the properties of the base classes, you can choose to view the inherited events. You’ll find it valuable, because many of the properties you’ll want to access may be inherited from a higher class. In the case of Button, it inherits its click event from the class UIComponent (which is actually the base class for all visual Flex components).

Figure 6-3. The Flex Language Reference for Button - Events

The Flex 3 Language Reference is your one-stop shop for everything you need to use components in ActionScript and MXML, and you’ll find it an indispensable resource when you start developing in Flex.

Using Event Constants

A constant is a fixed value in Flex, which means it’s a way to store a value that you don’t expect will change, to make it easier to remember. Constants are usually used to give a name to some numeric value, because, let’s face it, words are easier to remember than numbers. Can you remember π (pi) to the fifteenth decimal place? I didn’t think so. What about the ASCII value for the Caps Lock key? That’s why some smart person invented constants. Get a piece of the pi by using the constant Math.PI, or get the keyboard code for the Caps Lock key with Keyboard.CAPS_LOCK.

But numeric values aren’t all constants are good for. Flex often uses constants for strings as well, and the most common place you’ll see them is in event types. For instance, the event for when the user’s mouse goes out of the Flex application’s bounds is called mouseLeave. Because the string “mouse leave” or “mouse-leave” isn’t sufficient, Flex has a constant set up so you don’t have to remember the specifics: Event.MOUSE_LEAVE.

You might be thinking to yourself, “That’s not any easier to remember!” True, but if it makes you feel any better, because these constants are properties of a class (MOUSE_LEAVE is a property of the Event class, PI is a property of the Math class, and so on.), they’re available using code completion. That means you don’t have to worry about typos. Type the first few letters, and Flex Builder will fill in the rest for you.

You’ve probably noticed by now that constants are all in uppercase—that’s to distinguish them as constants. Though this capitalization is not necessary, it’s considered a best practice. And because it’s difficult to distinguish separate words in all-uppercase text, the standard is to place an underscore ( _ ) between the words.

Read more from Alaric Cole.