August 30, 2008

A month of iPhone

I've had my iPhone for about a month now, so I thought I'd chime in with the rest of the iPhone reviews flooding cyberspace.

I've been reading about the various problems people have been having and I've got to say that I haven't experienced these problems yet. I have been updating the software when the updates become available, so perhaps that's been keeping me clear of the issues.

I live in an area that gets excellent 3G coverage. This past weekend I was in Philadelphia and the 3G coverage was also good with just a couple of exceptions. One thing I did have trouble with was the Maps application in a moving vehicle. I found that if I had my position identified when the vehicle was stopped, I could then track my progress for quite some time. If I stopped Maps and attempted to do this while moving, then Maps had trouble.

I previously had a Windows Mobile "smart" phone. The iPhone is so much better than that. The two just do not compare (so I will). The iPhone starts faster, is more responsive, has better call quality, and is so much easier to use. The Windows "smart" phone was like using an old ASCII terminal (yes, I am that old). Poorly designed with poor software, I couldn't wait to get rid of it. The thing didn't even know about daylight savings time until I downloaded a hard-to-find patch for it!

But the iPhone isn't perfect yet. It definitely needs stereo bluetooth, better battery life, and a memory expansion slot. I like the keyboard, actually, and am pretty good at typing on it. That "smart" phone had a terrible keyboard. And who thought overlaying numbers on the keyboard was a good idea? At least the iPhone can draw whatever keyboard it needs at the appropriate time.

I also dislike the earbuds it comes with. I guess I have little ears because on the plane trip they made my ears sore and kept falling out. But I did feel sorry for the woman seated next to me who kept juggling all of her equipment - I just had my iPhone for entertainment (watched a movie - perfect for an airplane) as well calling home when I arrived. I've now ordered some new earphones that come with an assortment of tips.

I love the fact that it is expandable and there are so many apps for it. I have this terrific tip calculator that is positively ingenious. I also have the Pandora app. Plus you can get apps to stream radio and podcasts.

Oh, and the very first app I downloaded was "Remote" - turning the iPhone into a remote control for iTunes. I have my Macs upstairs, but downstairs in the living room I have an Apple Airport Express plugged into the stereo. Now with the Remote application I can control iTunes from the sofa without having to run up the stairs. This app is awesome - it is so 'real time' that adjusting the volume on the phone instantly adjusts the play volume. Whoever wrote this deserves a huge bonus.

The bottom line is that I love this phone. It does everything I want and if I want something more, someone has, or will, write an app to do that, too. The iPhone 3G was definitely worth the wait, for me.

Now if Apple will just merge Apple TV with the Mac Mini...

Posted by pent at 08:47 AM | Comments (5)

July 10, 2008

(re)Genesis

I started a whole new career path in November 2004 when I joined the Flex Support team at Macromedia. In the 3+ years since, I have answered a lot (and I mean, a lot) of questions from Adobe customers. Starting on Monday, July 14 2008, I will be joining a new team on something we call Genesis.

Visit the Genesis Blog at http://blogs.adobe.com/mashup.

You can read more about Genesis in this article at IT World: Adobe readying new mashup tool for business users.

I have enjoyed working for the best managers (Eric Anderson, Jim Schley, and Judy Ricciarelli) and with the best teammates (Woojin Choi, Kurt Mossman, Lin Lin, Brandon Purcell, Kyle Quevillon, Patrick Simon, Nick Watson, Peter Watson, John Zhao). Customer support is a team effort and I think the Flex Support team has proven that with the best-in-the business product support.

My new adventure with the Genesis group turns me back into a developer working on an exciting product sure to find a home in any coporation. Everyone needs a change of pace now and again and I'm delighted to be able to stay with Adobe and work with the best people in the business. I just hope I'm up for the challenge.

I'm still going to keep blogging and making Flex and AIR more accessible. Stay tuned for more articles.

Posted by pent at 08:23 AM

July 02, 2008

Adobe Reader 9 is Here!

Adobe Reader 9 adds new capabilities, better performance and stronger security. Here are the highlights:

Improved launch speeds
Looking for faster launch speeds? Adobe has enhanced general performance and, in particular, has reduced launch times with Adobe Reader 9. Try it: You'll notice the difference.

PDF Portfolios
Packages, introduced in Adobe Reader 8, have been greatly enhanced and renamed. Portfolios provide easy navigation when you work with multiple PDF documents and other document types. They also enable you to work with a collection of materials such as drawings, e-mail messages, spreadsheets, and videos as a single file, which makes distribution, storage, retrieval, and collaboration easy for end users.

Native Adobe Flash support
Adobe Reader 9 can natively display rich media content, which you'll notice immediately with Portfolios. Interested in viewing SWF and FLV files? Adobe Reader 9 is the answer.

Acrobat.com (beta)
In addition, Adobe Reader 9 includes easy access to Acrobat.com (beta), an exciting new set of online services from Adobe. With Acrobat.com, you can create PDF files online; create and coauthor documents with others; host live web meetings; upload and share PDF files and other types of documents and control who has access to them; and even embed a rich, interactive preview of your document in a web page. All of these services and more are provided online, so you can access them from anywhere. And you'll find easy access points from within Reader 9. As an added convenience, Acrobat.com leverages Adobe AIR, so you can interact with Acrobat.com from your desktop. Acrobat.com on Adobe AIR is a small application that is included with your download of Adobe Reader 9. Available in select languages.

Security enhancements
Adobe Reader 9 provides new digital signature functionality for an improved user experience. The new version also adds support for 256-bit AES encryption and new advanced security capabilities.

But, that's not all. Adobe Reader 9 offers a new PDF Standards Pane, improved CAD and geospatial functionality and accessibility enhancements.

So, download Adobe Reader 9 now! Or, distribute Adobe Reader 9 in your enterprise or bundle it with a CD or computer!

Posted by pent at 09:51 AM

June 25, 2008

MAX North America Site is Up

Please visit the MAX NA Experience site:

http://max.adobe.com/na/experience/

It is a 100% Flash based website with interactive landscapes (click the background). The backgrounds were created by several of the best digital design agencies on the planet. If you can figure out the puzzles, you discover who built them.

After the site launches, click on the background. When it appears, click again. There are three backgrounds - the one in the middle, one to the right, and a very cool tropical one to the left.

Posted by pent at 10:21 AM

June 17, 2008

itemEditors - Part 3

itemEditor,itemRenderer

The previous article in this series discussed item editing events. Using events can make your application respond to what the user enters and help the user make fewer mistakes.

This article is about using itemRenderers as itemEditors - one class to do both display data and edit the data. I tend to think of it more as an itemEditor used as an itemRenderer. But that's just me.

Download source for these examples.

Further, I have to be honest and say I am not a big fan of the renderer-as-editor; I think renderers should present data and editors should edit it. There are a few occasions when I think it is a good idea to use a single class for both, but those times are very few in my opinion.

Examples

Here is an example of over-using the itemRendererAsEditor. The DataGrid on the left is a nice, clean DataGrid. All of the cells are editable and when you click or tab into a cell its editor appears. The DataGrid on the right uses itemEditors to render the cells and edit them. All you see are the editors: TextInput controls for some columns, a ComboBox for another, and a NumericStepper for the last. Lots going on, very busy to look at.

itemEditors only	itemRenderers as itemEditors

Here is an example of using the CheckBox as both an itemRenderer and an itemEditor. I think the CheckBox works really well for this. It is clean, simple control and you can readily see whether a value is true or false. Plus you can just click it to change it. Straightforward implementation, good user experience.

Here is another example of using an itemEditor as a renderer. This List control represents a shopping cart. In it are all of the things you have added to your cart while shopping online at your favorite grocery store.

As you can see, the quantity of each item in the cart is represented by a NumericStepper. All the user has to do is change the quantity and the cart is updated. A delete button would also be a good idea here, too.

Shopping Cart

This complex editor/renderer class works as follows:

<?xml version="1.0" encoding="utf-8"?>
<mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml" verticalAlign="middle" paddingRight="4" paddingLeft="4" >

    <mx:Script>
    <![CDATA[
        public function get quantity() : Number
        {
            return itemQuantity.value;
        }
    ]]>
    </mx:Script>
    
    <mx:CurrencyFormatter id="cfmt" precision="2" />
    
    <mx:Label text="{data.name}" fontWeight="bold" fontSize="12"/>
    <mx:Spacer width="100%"/>
    <mx:NumericStepper id="itemQuantity" value="{data.quantity}" 
        minimum="0"
        maximum="100"/>
    <mx:Label text="{cfmt.format(data.price*itemQuantity.value)}" width="66"/>
    
</mx:HBox>

As with every itemEditor, this one has a property used as the editorDataField. In this case it is the quantity property getter function. The function retrieves the value setting of the NumericStepper (with id itemQuantity).

As an itemRenderer, this component must also display the current quantity (as well as the product name, price, and sub-total). These values are displayed through data binding. The sub-total is actually an ActionScript expression, multiplying the price by the value of the NumericStepper. As the NumericStepper is changed so does the sub-total.

Now you are probably wondering how to get the grand total below the shopping cart to update as the NumericSteppers are changed. Simply changing the sub-total and the quantity field of the itemRenderer/Editor will not update the grand total. Remember that the editor does not commit the new value into the data provider until after the edit completes. In other words, if you increase the value of the NumericStepper for the Snow Peas row, the grand total will not update until focus leaves the Snow Peas row. This is so you can validate the information as shown in previous articles.

For a shopping cart like this, you want the grand total to update as the user changes the NumericSteppers. So you have to force the situation a little.

The first thing you do is have the itemRenderer class implment the IDropInListItemRenderer interface. This gives you access to the listData which contains a reference to the list itself and, through that, to the dataProvider.

The code demonstrating this is available in the download. Look for the ShoppingCartRendererExtra.mxml file.

Once you have the listData you can have the change event on the NumericStepper force an update on the dataProvider:

private function forceUpdate() : void
{
    // Access the collection - listData.owner is the List and from there you have its dataProvider.
    var ac:ArrayCollection = (listData.owner as List).dataProvider as ArrayCollection;
    
    // update the quantity field from the numeric stepper. This is what the List will automatically
    // do when editing completes, but since you want to see the grand total change as the NumericStepper
    // changes, you have to force things a bit.
    data.quantity = itemQuantity.value;
    
    // finally, tell the collection the data changed. this will cause the collection to
    // dispatch its own change event which is then picked up by the main application.
    ac.itemUpdated(data);
}

When the NumericStepper's change event triggers this event handler, the ArrayCollection has the item updated immediately, rather than waiting for the List to complete editing the cell. If the main application is listening for a COLLECTION_CHANGE event on the collection, the grand total can be calculated:

    <mx:ArrayCollection id="shoppingCartDB" 
        source="{shoppingCartArray}"
        collectionChange="updateCartTotal()" />
...
private function updateCartTotal() : void
{
    if( cartTotal ) {
        var total:Number = 0;
        for(var i:int=0; i < shoppingCartDB.length; i++)
        {
            var record:Object = shoppingCartDB.getItemAt(i);
            total += record.price * record.quantity;
        }
        
        cartTotal.text = cfmt.format(total);
    }
}

 

Conclusion

Take care when turning an itemRenderer into an itemEditor. The user should have a straightforward interface with a single purpose when editing a cell or record. I personally prefer to separate the functions, but there are times when using an itemRenderer as an itemEditor can make sense, even if you have to go the extra mile as with this shopping cart grand total example.

Posted by pent at 12:22 PM | Comments (7)

June 04, 2008

itemEditors - Part Two

Editing Events and Complex Editors

In the last article of this series you saw how to make some simple inline itemEditors. If you have read the series on itemRenderers, then you noticed how similar the two are.

The key to making an itemEditor work is a) naming the class using the itemEditor property and b) naming the value property of the itemEditor using the editorDataField property.

In this article I'll show you how to use events to do some simple data validation and to prevent certain cells from being edited. In the course of this you will see how to make more complex itemEditors.

You can download the source code for this example here.

A word of caution here: by "complex" I do not mean editors with many controls and layouts. I really mean slightly more complex than inline itemEditors. The reason being is that I think it is unfair to ask users to make complex edits within a list or cell of a DataGrid. An editor should be focused only one one thing: the contents of a cell. For example, if you are using the List control and presenting a shopping cart, it is not unreasonable to allow the user to change the quantity of the items in the cart by letting them edit that value right in the cell. What would be unreasonable is to allow them to change the item itself, the colors, quantity, special instructions, and so forth. Or in other words, allow them to shop for items right from the cart when you have a whole site that does that. The cart is just a checkout convenience. Sure, let them add an extra tub of ice cream or delete a bag of chips, but don't have them turn the bag of chips into a two boxes of whole wheat pasta.

The itemEditEnd event

Let's say you have a DataGrid which helps you mange inventory. One of things you can do is change part numbers, but you cannot allow a part number to be blank. Using the default itemEditor, the TextInput control, you can click on a cell in the "Part #" column, press the delete key and erase the part number. This is one technique to prevent that.

	<mx:DataGrid x="10" y="64" editable="true" dataProvider="{inventoryDB}" 
		itemEditEnd="verifyInput(event)">
		<mx:columns>
			<mx:DataGridColumn headerText="Product" dataField="product"/>
			<mx:DataGridColumn headerText="Part #" dataField="part"/>
			<mx:DataGridColumn headerText="Type" dataField="type"
				itemEditor="editors.ProductTypeEditor" editorDataField="type"/>
			<mx:DataGridColumn headerText="Quantity" dataField="quantity"/>
		</mx:columns>
	</mx:DataGrid>

The list controls dispatch an itemEditEnd event whenever editing is about to be completed. The event happens before the data is commited back to the dataProvider. By handling this event you have the option of changing the data, validating the data, and stopping the commit if necessary. For this example, the verifyInput() function will make sure the product part number is not empty.

		private function verifyInput( event:DataGridEvent ) : void
		{
			// it is OK if the user cancels the edit
			if( event.reason == DataGridEventReason.CANCELLED ) return;
			
			// grab the instance of the itemEditor. For this DataGrid, only the
			// TextInput control is used as the editor, so it is safe to get the
			// editor no matter what column has been edited.
			var editor:TextInput = (event.currentTarget as DataGrid).itemEditorInstance as TextInput;
			
			// if  the edit is on the part number column, make sure it is not blank
			if( event.dataField == "part" )
			{
				if( editor.text.length == 0 ) {
					// call event.preventDefault() so the edit will not continue and store the
					// blank value
					event.preventDefault();
					// give the editor an error to display to the user
					editor.errorString = "You must enter a part number";
					return;
				}
			}
			
			// handle other columns here
		}

The event is a DataGridEvent and contains some very useful properties. The reason property tells you why the event was dispatched. If the user pressed the ESCAPE key or clicked outside of the DataGrid the reason will be DataGridEventReason.CANCELLED. You may want to ignore this event as I have done and just let the DataGrid to its default action which is to cancel the edit and restore the previous value.

If you have decided to handle the event then you will need the itemEditor to get to its properties. The event's currentTarget property contains the control which I have cast to DataGrid. The DataGrid has an itemEditorInstance property which I cast to TextInput which is the type of itemEditor for this example.

This event handler is called for any cell so you must determine if the edit is something you are interested in pursuing. I check the event's dataField property to make sure it is the "part" column. If so, I test the editor's text property to see if there are any characters in it. If there are no characters, two things happen:

First: the event.preventDefault() is called. This is how to prevent the edit from happening - prevent the DataGrid from storing the new value back into the dataProvider.  For the user, they will have pressed TAB or ENTER and nothing will appear to happen. The preventDefault() function will keep the itemEditor in place.

Second: I put an errorString onto the TextInput control. This is optional, but it does signal the user that there is something wrong. Afterall, they pressed the TAB or ENTER key and nothing happened.

The itemEditBeginning Event

There are times you might want to prevent a cell from being edited. You could set the DataGridColumn's editable property to false, but that prevents every cell from being edited. Suppose you just want to make some of the cells in the column uneditable? You can determine whether a cell is editable or not using the itemEditBeginning event.

    <mx:DataGrid x="10" y="64" editable="true" dataProvider="{inventoryDB}" 
        itemEditEnd="verifyInput(event)" 
        itemEditBeginning="allowForEdit(event)">
        <mx:columns>
            <mx:DataGridColumn headerText="Product" dataField="product"/>
            <mx:DataGridColumn headerText="Part #" dataField="part"/>
            <mx:DataGridColumn headerText="Type" dataField="type"
                itemEditor="editors.ProductTypeEditor" editorDataField="type"/>
            <mx:DataGridColumn headerText="Quantity" dataField="quantity"/>
        </mx:columns>
    </mx:DataGrid>

Handling the itemEditBeginning event gives you the option of dynamically deciding the editability of a cell. In this example, the data has a field called permanent on each record. The idea is that permanent=true means the product name is an unchangable value so the product cell for that row cannot be edited. This is handled by the allowForEdit() function:

        private function allowForEdit(event:DataGridEvent) : void
        {
            // if the field to be edited is a product, prevent the user from making
            // changes if the permanent flag is true<. You can use more complex logic, 
            // of course.
            if( event.dataField == "product" ) {
                
                var item:Object = ((event.currentTarget as DataGrid).dataProvider as ArrayCollection)[event.rowIndex];
                if( item.permanent ) {
                    event.preventDefault();
                }
            }
            
            // handle other columns here
        }

Again, the event is a DataGridEvent and here I have checked the dataField property of the event to make sure it is the "product" field I am dealing with. I can then get the record from the dataProvider of the DataGrid using the currentTarget property of the event and cast that to DataGrid. I then cast the DataGrid's dataProvider to ArrayCollection and get the event.rowIndex value. I could also have used the inventoryDB ArrayCollection directly in this function since they are in the same file, but this is more generic.

Once I have the record I can query its permanent property and if it is true, call the event.preventDefault() function to disable editing of that cell. In the case, the default behavior of itemEditBeginning is to present the itemEditor; preventing the default behavior makes the cell uneditable.

Editing Limitations

While I was proof reading this article I thought of something you might try and do and offer a warning. When you are using these edit events and trying to determine if the event should proceed, you may be tempted to make a call to a backend or server process. For example, you may have a web service where you can validate a part number. You may be tempted, while inside of the itemEditEnd event, to make a web service call and validate what the user just entered. Seems logical, right?

Logical maybe, but it won't work. The reason is that data service calls are asynchronous. You can make the call, sure, but the result will be returned sometime later - well after your event handler has exited. In fact, your call won't actually be made until your function exits. Your call is queued and when the Flex framework exits the function the request will be made and then the result will be returned by your web service's result handler.

So there is no way to do this type of server-side validation while editing cells. You should query the server, when your application starts, for the data to validate against, then use that while the cells are being edited.

Conclusion

The ability to dynamically allow editing and to validate the edit is a excellent way to give your users a better experience. You can help them make fewer mistakes and give feedback during the editing process. You can prevent them from editing certain data and make it easier for yourself to write the application since you do not have to validate what the user cannot change.

In next article I'll cover itemRenderers used as itemEditors.

Posted by pent at 01:15 PM | Comments (1)

May 29, 2008

itemEditors - Part 1

inline itemEditors

I recently completed a series on itemRenderers - customizations to list controls which format the display of the list contents. Displaying and rendering content is very cool and with Flex you can do nearly anything you can imagine.

This new series covers itemEditors - a way to allow data to be changed directly inside of a list control. This first article covers inline itemEditors which are very simple, though quite useful, components you write directly inside your MXML files. The other articles in the series will cover more complex editing, validation, events, and using itemRenderers as itemEditors.

The source code to this article is available by downloading it here.

TextInput Editor

It is nice to edit directly in the list controls. You can imagine a DataGrid of warehouse inventory where you can adjust the content right in the grid without needing a special pop-up. The list controls have a built in editor - a TextInput control - which appears whenever the user clicks the mouse in an editable area, either a row (for a List), a branch (for a Tree), or a cell (for a DataGrid). All you need to do is set the list control's editable property to true. For a DataGrid you can exclude a column from being edited by setting the DataGridColumn's editable property to false.

Before editing a cell	After clicking on a cell, the editor opens and the content is ready for editing.

itemEditors differ from itemRenderers in that only one instance of the itemEditor is seen - just on the cell being edited. The itemEditor is not seen until the cell to be edited receives input focus. Then the itemRenderer is hidden and the itemEditor is moved to that position, sized to fit the area, and given the data for the record. When editing is finished (by moving focus to another location), the list control copies the new value from the editor to the dataProvider record.

Using the image above as an example, when the user clicks in a cell of the "Part #" column, the dataProvider[row][dataField] value is given to the text property of the itemEditor (TextInput) control. When editing is finished, the text property value from the itemEditor (TextInput) control is copied to the dataProvider[row][dataField]. The dataProvider, being a collection, dispatches an event in response to the update.

While the default TextInput control makes a fine editor, it really only works for the most simple of cases. It works fine for String values, for example, such as a book title, author name, or product number. If you need more control or want to validate the user's input, then you need to take matter into your own hands.

Flex Controls as itemEditors

Here is how you make an itemEditor which only accepts numeric values:

	<mx:DataGrid x="46" y="270" editable="true" dataProvider="{employeeDB}">
		<mx:columns>
			<mx:DataGridColumn headerText="Name" dataField="name"/>
			<mx:DataGridColumn headerText="Position" dataField="position"/>
			<mx:DataGridColumn headerText="Age" dataField="age">
				<mx:itemEditor>
					<mx:Component>
						<mx:TextInput restrict="0-9" maxChars="3" />
					</mx:Component>
				</mx:itemEditor> 
			</mx:DataGridColumn>
		</mx:columns>
	</mx:DataGrid>

A very common control to use for an itemEditor is the CheckBox. This is very useful for editing Boolean values. Here is an example of using the CheckBox to edit the values for an "In Stock" column of an inventory program:

<mx:DataGrid x="531" y="273" editable="true" dataProvider="{inventoryDB}">
		<mx:columns>
			<mx:DataGridColumn headerText="Product" dataField="product"/>
			<mx:DataGridColumn headerText="Part #" dataField="part"/>
			<mx:DataGridColumn headerText="In Stock?" dataField="inStock"
				labelFunction="inStockLabeler"
				itemEditor="mx.controls.CheckBox" editorDataField="selected" /> 
			<mx:DataGridColumn headerText="Quantity" dataField="quantity"/>
		</mx:columns>
	</mx:DataGrid>

In this example the content of the cells in this column are rendered using a labelFunction (inStockLabeler) which could display anything such as "Yes", "No", "In Stock", or "Out of Stock". The itemEditor property is set to the mx.controls.CheckBox class. And there is another, equally important, property set on the DataGridColumn: editorDataField. This field indicates the property of the itemEditor class to use to fetch the value when editing is finished. In this case it is the CheckBox's selected property. When editing is finished, the DataGrid will use the CheckBox's selected property to replace the inStock property in the data record.

You may wonder why the example with the TextInput did not supply the editorDataField property. That is because the default value for editorDataField is "text" which just happens to be name of the property on the TextInput control holding the value.

You can use this same technique with a number of Flex controls. Here is one for an order quantity column using NumericStepper:

	<mx:DataGrid x="531" y="82" editable="true" dataProvider="{inventoryDB}">
		<mx:columns>
			<mx:DataGridColumn headerText="Product" dataField="product"/>
			<mx:DataGridColumn headerText="Part #" dataField="part"/>
			<mx:DataGridColumn headerText="In Stock?" dataField="inStock"/>
			<mx:DataGridColumn headerText="Quantity" dataField="quantity"
				itemEditor="mx.controls.NumericStepper" editorDataField="value"/> 
		</mx:columns>
	</mx:DataGrid>

Notice the editorDataField is "value" - the property of the NumericStepper which holds the current value of the control. Make sure you use the fully-qualified class name for the itemEditor property.

Complex Editor

Now suppose you want to do something a little more complex that doesn't have a ready-made Flex control available. Here is one which allows a credit card number to be entered using 4 separate 4-digit fields:

	<mx:DataGrid x="46" y="463" editable="true" dataProvider="{accountDB}" width="302">
		<mx:columns>
			<mx:DataGridColumn headerText="Account" dataField="account" width="100"/>
			<mx:DataGridColumn headerText="Credit Card" dataField="ccard" editorDataField="value">
				<mx:itemEditor>
					<mx:Component>
						<mx:HBox>
							<mx:Script>
							<![CDATA[
								public function get value() : String
								{
									return part1.text+part2.text+part3.text+part4.text;
								}
								override public function set data(value:Object):void
								{
									super.data = value;
									part1.text = value.ccard.substr(0,4);
									part2.text = value.ccard.substr(4,4);
									part3.text = value.ccard.substr(8,4);
									part4.text = value.ccard.substr(12,4);
								}
							]]>
							</mx:Script>
							<mx:TextInput id="part1" maxChars="4" restrict="[0-9]" width="40" />
							<mx:TextInput id="part2" maxChars="4" restrict="[0-9]" width="40" />
							<mx:TextInput id="part3" maxChars="4" restrict="[0-9]" width="40" />
							<mx:TextInput id="part4" maxChars="4" restrict="[0-9]" width="40" />
						</mx:HBox>
					</mx:Component>
				</mx:itemEditor>
			</mx:DataGridColumn>
		</mx:columns>
	</mx:DataGrid>

This inline itemEditor follows the same rules as other itemEditors and names the editorDataField as "value". The component chosen for the itemEditor is the HBox - which does not have a "value" property. To make this itemEditor work, a getter function named value is created to return the concatenation of the 4 input fields. Now when editing for the cell completes, the DataGrid can call upon the value property of the itemEditor and it will receive the combined fields.

You can also see that I have overridden the data setter function. In that function I split up the credit card number among the four TextInput fields. This is the technique you use to display the data to be edited. The editorDataField is the property used to retrieve the new value.

Conclusion

In this article you've seen how to create an inline itemEditor - from simply naming a class to creating a complex class right within the MXML tags. By naming the property of the editor class which contains the final editor value, the DataGrid can retreive the value from the editor instance and replace the current value in the data.

The next article covers more complex itemEditors and editing events.

Posted by pent at 05:39 PM | Comments (5)

May 28, 2008

Registration Open for MAX 2008

MAX 2008 will be held in San Francisco this year and is now ready for you to register. Each year MAX has gotten bigger and better. If you haven't attended MAX, make this year your first. MAX is a great place to network and to see the new things coming from Adobe and other companies. MAX is also the place to meet the Adobe staff and there are always plenty of Adobe people on hand.

Following this link and make your reservation: http://max.adobe.com/blog/

Hope to see you at MAX!

Posted by pent at 12:26 PM

May 07, 2008

Return to Normal

Our blogging server is back and my blog, along with a bushel of others, have been restored.

Now I can work on my back-log of articles.

Posted by pent at 03:02 PM

April 09, 2008

Adobe Media Player

Adobe Media Player,AIR

Adobe's just released a new product- the Adobe Media Player. This application is built upon AIR using the Flex 3 SDK. The AMP is a new type of video player.

As I write this I'm watching an episode of Star Trek: The Original Series from January 1968. It looks terrific and streams smoothly. There are a dozens of shows to choose from.

I personally think this is paving the way for the future of home entertainment. Why be at the mercy of the cable or satellite companies when the content you want to watch is available when you want to watch it. Right now you can download movies from iTunes and Amazon Unbox. NBC and FOX have the Hulu joint venture with movies and TV shows. I haven't rented a movie at a movie rental store in who-knows-how-long.

For me, the problem is making the interface to these services as easy as bringing up the guide on my TiVo and as simple to connect all the boxes together.

Here's an excerpt from the announcement:

It [AMP] provides high quality video playback of streamed, downloaded, or locally stored Internet TV shows and video podcasts. Users can subscribe to Internet television shows and other online video content, have them download automatically in the background, and later view them on demand. AMP's user interface optimizes the user experience, allowing users to easily enjoy finding and viewing their favorite shows.

AMP represents a tool that is not only important to consumers, but publishers who want to monetize advertisements.  The last couple of months we have been working very hard to get the top broadcasters signed to provide content through AMP. We have successfully signed CBS, MTV and Food Network as just a few that will be part of our launch.

Download Adobe Media Player today!

Posted by pent at 05:38 PM | Comments (1)