Give us a call 203-379-0773
Check out our new training course on AngularJS for Flex Developers

Flextras Calendar 1.05 Updated

A while back a customer asked to be added to the mailing list for our Calendar updates. We don't actually have product specific lists; but I thought I might as well start posting the release notes when I post a new build.

I just pushed out the Flextras Calendar, version 1.05. This is a minor update that provides a few bug fixes. You can read the full release notes here. Here are the important updates:

  • Fixed Bug where selectedIndex went to -1 if you selected an item in a day where an item was already selected.
  • Added a default collectionChangeHandler so that modifying the dataProvider will immediately show up in the Calendar's display.
  • Updated Drag and Drop sample.
  • Fixed a bug when drop moving an item outside the Calendar would not properly remove that item from the dataProvider.

You can get the new version by logging in and downloading the developer edition. If you've purchased a license, then you can log in and download the latest version from purchase history under the account menu.

Get a Free Flex Calendar Component with your 360|Flex Ticket

Flextras is a sponsor of 360|Flex Denver this coming April. 360|Flex is the best Flex conference and they always put on a killer show. They'll have 50 sessions from some of the industries best coders; plenty of networking events, and even a full day of hands on sessions.

As part of our sponsorship agreement, we will be holding two 24 hour sales. The first one was last month, and you probably missed it. The next one is tomorrow. If you buy a 360|Flex ticket on March 16th, then you are eligible for a free unlimited domain edition of the Flextras Calendar Component license. The unlimited domain edition includes the complete source code.

If you like Flextras and 360|Flex; head over to 360|Flex tomorrow to pick up your ticket. Then the 360|Flex folks will e-mail you instructions on how to get your complimentary Flextras Component.

Even if you can't snag your tickets tomorrow for whatever reason, you can still try out our free developer editions of all our components, including the Calendar and our AutoCompleteComboBox. Check them out today; and be sure to stop by our booth at the conference to say Hi.

Spark Renderers - 3/4/2011 - Episode 96 - Flextras Friday Lunch

This time I talk about creating Spark Renderers for our Flex Calendar Component. The conversation touches on Playbook apps, The Flash 3D API (Molehill), and a bit about ActionLinq.

Flextras Friday Lunch is a short demo followed by open Q&A that occur the first and third Friday of every month at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Contact

iCalendar in Flex - 9/10/2010 - Episode 78 - Flextras Friday Lunch

This time I give a dry run through my 360|Flex DC talk about using iCalendar data with Flex. We also touch on Apple's iPhone 3rd party tools reversal.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Contact

Calendar Styling - 5/28/2010 - Episode 63 - Flextras Friday Lunch

In this session, I show some code behind a custom dayRenderer for Flextras Flex Calendar. We chat about The Flextras AutoCompleteComobBox, ASDocs, and Elips Studo.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

Why won't my ASdocs Copy?

This post comes from the monthly Flextras newsletter. While we were finishing up the Flextras Calendar, we wrote over 27 pages of ASDocs. I was presented with an interesting issue with ASDocs.

What are ASDocs?

ASDocs, if you're unaware, are special blocks of code you write in your Flex files that can be run through a command line utility to generate an API Reference. The API References you use for the Flex Framework are generated by the ASDocs tool, for example.

ASdocs look like this one, from the changeMonth method of the Flextras Calendar:

/**
* A method to change the month based on the specified increment.
* You can use a negative value to go back in time or a positive value
* to go forward.
* Only has an effect if in the MONTH_VIEW state.
*
* @param value The increment value used to change the month; the
* default is 1.
*
* @see #MONTH_VIEW
*/

The ASDoc are placed before elements in your files, such as properties or method and when you run the ASDoc tool it picks up the text and adds it to the generated ASDocs files.

In the ASDocs segment above you see two ASDoc tags, @param and @see. These tags give special instructions to ASDocs. The @see tags add links to other elements of the API, other classes, or even URL links. The @param tag defines the parameter to a method, and they are given a special place in the ASDoc output.

The @copy tag?

Our Calendar supports most elements of the List class API and the DateChooser API. The Calendar extends ListBase, so most of the properties are inherited. The DateChooser properties, such as firstDayOfWeek, monthNames, or dayNames are implemented as if they were brand new.

We thought instead of writing new documentation for these properties, we could use another ASDoc tag--@copy--to just copy the documentation from the DateChooser class into the Calendar class. The code looked like this:

/**
* @copy mx.controls.DateChooser#firstDayOfWeek
*/

This seemed logical to us, but for some reason the ASdocs wouldn't copy; and the documentation in our generated file was blank for those copied properties. What was the problem?

It turns out that the DateChooser is never used anywhere in our Calendar. As such, the Flex Compiler will automatically optimize the class right out of the SWC file. This is good because it keeps file size low and you do not have to distribute unnecessary classes. Unfortunately, it seems to the ASDoc appears to use the same approach. DateChooser wasn't in the API, so therefore the ASDoc utility couldn't find the DateChooser code in order to copy the appropriate ASDocs from one place to another.

The Solution Part 1!

One solution, and I hated doing this, was to create a dummy variable of the DateChooser type:

private var temp : DateChooser;

Then all was well and the properties would get documented as expected. I don't like this because it artificially inflates the size of the SWC. Thankfully there is a better solution.

The Solution Part 2!

The ASDoc command line tool supports many of the same command line arguments that the Flex compiler supports. We can use the include-libraries argument and point it at the framework SWC. This will make all classes in the framework available to the ASDoc compiler whether or not they are used.

For practical purposes, you want limit your use of this argument when creating swfs for wide release. But, none of that matters when generating ASDocs.

Conclusion!

Did I mention that the Flextras Calendar is out? It supports Flex 3 and Flex 4 and you can download a free developer edition to test it out.

Calendar Release - 5/7/2010 - Episode 61 - Flextras Friday Lunch

In this session, I demonstrate the final Flextras Calendar for the first time.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

  • Watch Original Recording
  • Calendar API Explorer
  • Subscribe

    Contact

Flextras Friday Lunch - Episode 50 - 2/19/2010 - Flex Calendar Component Architecture

In this episode I talk about how the architecture of our Calendar Component for Flex. After 9 months in development, the release is finally coming closer. For some reason I introduce the date as November instead of February; sorry about that.

Flextras Friday Lunch is a short demo followed by open Q&A that occur every Friday at 1pm EST. The presentations take place over Connect. You can find out what time this occurs in your own time zone at TimeAndDate.com.

I hope I can help answer some of your questions at the next one.

Notes

Subscribe

Contact

How do you tell if a component is in a transition?

I'm working on Fleshing out the Flextras CalendarDisplay component. I think I'm finally happy with our approach to implementing a day view. One of the things we want to support is the ability to transition between a month view, a week view, and a day view.

Transitioning from a day display to a month display was working fine. Transitioning from the month to the day was not. After stepping through the code I discovered that the updateDisplayList() method would resize the day before the effect ran, thus negating the effect.

I needed a way to figure out if a transition was playing and tell the component not to run the updateDisplayList() method.

I've seen some situations where you set a Boolean value "transitionRunning" to true before running the play method, then set it back to false in a listener to the effectEnd method.

But, that wouldn't work in this situation. If the transition is a transition between two states, then all the code for starting / stopping the effects is locked up in private methods of UIComponent.

I ended up writing this method to loop over the transitions array and figure out if one of the effects was playing.

protected function isTransitionPlaying():Boolean{
if(this.transitions){
for each(var transition : Transition in this.transitions){
if(transition.effect.isPlaying){
return true;
}
}
}
return false;
}

My intuition tells me there should be an easier way, but I'm not sure what that is.

Update:

A friend on twitter recommended I take a look at the activeEffects property. The function would be modified like this:

protected function isTransitionPlaying():Boolean{
if(this.activeEffects.length >
0){
return true;
}
return false;
}

Unfortunately, that didn't work. Even though a transition was running, it was not on the activeEffects array. I'm unsure why.

Understanding the Flex Component LifeCycle Methods

Lately we''ve been getting a lot of questions about the proper way to use the methods in the Flex 3 Component LifeCycle. I wrote about this in the December Flextras newsletter and thought I'd turn it into a post here too.

The Flex Component Lifecycle is a set of methods and events that Flex uses to setup, size, and position the components that make up your Flex Application. There four lifecycle methods that you'll use when creating Flex Components: createChildren(), commitProperties(), measure(), and updateDisplayList(). I'll discuss each one individually.

createChildren()

The createChildren() method is aptly named. It is intended to create the children of the component. This is run as part of the initial component setup and is never run again. In our Calendar component's MonthDisplay class we use createChildren() to create the day name headers to display the day of the week and the month header which displays forward / next buttons, the month name and the year.

commitProperties()

I consider the commitProperties() method is a wild card method. You'll use commitProperties() to coordinate component changes all at once. However, the exact use of this is a bit of a gray area. It depends what properties have changed and how they affect the component.

In many of the custom components I've built I find that I'm using commitProperties() as an alternative for createChildren(). In our Calendar component, I use it to create the month's days from a dayRenderer. This can't be done in createChildren() because we may not know the displayedMonth or displayedYear yet, and therefore can't determine the number of days in the week.

measure()

The measure() method will determine the ideal size of this component. Its' purpose is the most concretely defined of all the component lifecycle methods. This will set the measuredWidth, measuredHeight, measuredMinWidth, and measuredMinHeight properties on your component. A component is always sized by its' parent; but if these properties are suggestions to that parent.

How you calculate the meauredWidth and measuredHeight is open to interpretation and depends on your component. In most cases, you'll examine each of the component's children and keeping some type of running tally. For our Calendar component's 'month display, we set measuredWidth to the width of the longest week. MeasuredHeight is calculated using sum of the heights of the largest day in each week. The calculations take into account localization features, such as the first day of week.

I've experienced a few gotchas with the measure() method. First, if you specify an explicit height and width, the measure method will not be run. This is done for performance reasons. If you already know the height and width, why does the parent need suggestions from the child? It doesn't!

Second, the documentation states that measuredMinWidth and measuredMinHeight are optional, but I have found this not to be the case. If these values are not set I've experienced situations where the width or height ended up being set to NaN, which interferes with sizing calculations up the component chain.

updateDisplayList()

The updateDisplayList() method is intended for changing the visual pieces of the component. It is great for setting the height and width of your children and positioning those children with the x and y coordinates. In the Calendar's MonthDisplay this will size and position all the days. Even though the measure() method assumes that individual days can contain have different height or widths, updateDisplayList() forces all days to the same size. You may also use updateDisplayList for changing styles.

Final Words

So, in summary:

  • createChildre(): Creates the component's children
  • commitProperties(): Coordinates property changes
  • measure(): Determines the ideal size of a component's children
  • updateDisplayList(): Positions and sizes the children

Most of the work I do when building components for Flextras relates to use of one of these component lifecycle methods. The Flex 4 framework does bring quite a few changes along with a new component architecture. Perhaps I'll write about that another time.

More Entries