Been a while but, I have been working in the labs for quite some time (8 months to be exact), I guess just waiting for this current US presidency to END! Always like molasses in the end.

Anyway, I have written some short tutorials and other adventure notes from my past travels and will start posting them up here soon.

Teoti Graphix, LLC also has a new component framework that extends Container and UIComponent that we will be releasing early fall. We will have a variety of tool kits to choose from.

Part of this new release will be a full transform floating canvas with move, resize, rotation, snap and grid, with drag and drop. We have had many of our customers ask about these things when they purchased the ResizeManagerFX component.

Another thing to note: We will be selling our source code (optional)! So for all of you who have asked me about this, coming up is your chance to see beautiful code when purchasing our components. If you think wading through the mx framework is enlightening, wait till you get your hands on our code!

We have also created a documentation system that can handle our new frameworks. Cross linking and tutorials.

So stay tuned, this time I won’t get lost in development and let my blog collect dust!

Mike

Through the years (man, it’s been years now since Flex was released), I have seen a lot of confusion about container scroll bars.

The confusion summed up;

Developers have a child container within a parent. The child container’s measuredHeight exceeds the parent’s viewable height. The parent container then EXPANDS itself to make room for the child’s measuredHeight.

With this condition a developer thinks, well how come the parent is expanding and not showing it’s scrollbars?

The answer;

In order to increase performance of the flex framework and LayoutManager, the engineers decided that having scroll bars pop up everywhere wasn’t that appealing. So they decided to honor the minimums of a container.

This means by setting the child container’s minHeight to something below 100, essentially 0, you will now force the parent to keep it’s current height and show scrollbars for the child container that has it’s measuredHeight greater than it’s parent’s height.

Once you think about this for a second, you realize it is kind of intuitive. You now have control over scrollbar appearance.

Mike

Back from the lab and we have a great component release, the DockAreaFX.

Product Page

Update, New Product

The DockAreaFX set is a new product that is well worth a look.

The DockAreaFX is a very powerful, extendable and simple to use drag and drop container set. The set consists of the DockAreaFX that serves as the drop container and the DockPaneFX that acts as the drag initiator container. Along with these two components, the TitleBarFX and DockTaskListFX are also included to serve as a jump start for more complicated drag and drop set ups.

We have added the ResizeDockAreaFX component that uses a Fire Works style open and close resize bar. This bar can close and open the dockarea with a click of it’s toggle button or drag and resize the dock area! The bar placement can be set from top, left, right and bottom. This means the dock area can open and close from all 4 layout positions. The bar is also fully stylable with open and close transition styles.

Information sources

• Online Help Book
• ASDoc Documentation
• Technical Forum
• Ask Before You Buy
• SWF Examples

Main Features

DockAreaFX

This image is taken from the ThemedDockTaskList.mxml included in the product’s example project and is also covered in the Help Books section of the web site.

Important Notes:

• The example uses a custom theme to create an OS look and feel. You could adjust this to any style and skin combination thinkable.
• The DockTaskListFX component is used as the content holder within the DockPaneFX drag initiator. (The DockTaskListFX is a subclass of the TaskListFX component).
• The task list component is specially designed to size it’s parent when opening and closing (with or without a tween).
• The task list component also uses a custom title bar that allows for a drag handle, alternate minimize button position, title and a menu popup button located on the right hand side of the title bar.
• The DockPaneFX drag initiators can be placed in any container at startup or a DockAreaFX component.
• The DockPaneFX drag initiators can be dropped on the Application or into a DockAreaFX container. These two actions constitute a dock or float operation. The DockPaneFX's isDocked property is updated just before the operation completes and the component’s default action has run.
• The DockAreaFX drop target containers can have layouts of absolute, vertical, horizontal and flow. Each of these layouts have specially placed drop indicators relative to it’s children. The dock areas can also drag a bounding box around the full container (skinnable and stylable).
• The DockPaneFX is completely resizable when in it’s float state(isDocked == false) and when the DockTaskListFX is used, resizes vertically. Also note that when a DockPaneFX is closed (isOpen == false), it’s resize is limited to left and right.
• The Colors pane is being dropped into a vertical DockAreaFX component.

The image above now shows the DockPaneFX dropped into the DockAreaFX component at index 1. You can see that when a pane’s isDocked property is set to false, the default action is to hide the border and title bar. The dock pane also takes care of taking it out of the popUp state and then adding itself into the drop target component.

What is a fork relating in a framework? When creating abstract superclasses that rely on subclasses to fill in details we need forks. A micro routine in a macro routine. Take the flex framework, the commit properties fork is a very important and extensible piece of logic. This code path enables you to set any property, composite property or micro routine that a measurement or update to the display list relies upon.

Take for example a routine that needs subclasses to create bars and set visibilities of those bars. This routine needs to happen before measure() and updateDisplayList() is called becasue the viewMetrics and/or size may change when a new bar (in the component's chrome) comes into existence.

From the sentence above we have abstracted two routines that fork from the original commit properties fork.

• creation of bars
• setting of bar visibilities

Lets look at some code structure;

commitProperties()

• commitBarVisibilites();
  • visibleBars = new Dictionary(true);
  • validateBarVisibilites();
    • createTitleBar();
      • create the instance
    • visibleBars[TITLE_BAR_NAME] = _showTitleBar;
  • updateBarVisibilities();
    • titleBarInstance.visible = visibleBars[TITLE_BAR_NAME];
    • invalidateSize();
    • invalidateViewMetrics();

With this algorithm we may now subclass this component and add new bars. The subclass needs to override

• validateBarVisibilites()
• updateBarVisibilities()

the super class takes care of the base logic, subclasses just add to this fork and use it's two new forking ends.

There is a rule in abstraction you must learn. If you plan on creating a useful fork, you need to plan and create a base method commitBarVisibilites from our original super class fork that now calls new sub forks, validateBarVisibilites and updateBarVisibilities.

For any type of useful subclass overrides to efficiently override this fork and provide maximum flexibility, the base method is required so that any logic in the first fork (validateBarVisibilites) is encapsulated from the second fork (updateBarVisibilities).

With this scenario you have three override possibilities;

1. override commitBarVisibilites()
• control before and after sub fork run.
2. override validateBarVisibilites()
• control inside run
3. override updateBarVisibilities()
   • control inside run

Also, if abstracted correctly, you can call these methods individual. The purpose of a fork within the flex framework is to provide decoupled micro routines that are not dependent on it's caller. This is a very important rule. By making the two micor routines dependent on commitBarVisibilities you have now spun a web that a subclass cannot get out of.

When you subclass this fork, you for all intents and purposes copy what is in the two micro routines and leave the concrete implementation to the super class that has defined this code path.

The code examples are listed just to show what this 'might' look like. I do have this implemented in my framework but, there are other subtle things going on since this is a non trivial property commit.

The dictionary values are used in method like showAllBars(), hideAllBars(), restoreBars(), etc. It allows use to either explicitly hide/show or remove bars during transitions to save performance while restoring them when the transition is complete. This way we do not touch our component showBar properties.

UPDATED ::

From Toms comment, the Flash Player is a single thread. Yeah it is and most of us know this. I speak English and fork means multiple directions from the point your at. If I was talking about threads in the Flash Player I would be wrong. But, I'm not.

I am trying to say, in an abstract sense of the word [fork], the flex framework has code forks due to how the Template Method pattern is implemented. This article explains how to utilize this routine path and how to create new roads from an existing path.

PS, If some one else wants to comment on my English, I can do a search and replace.

Mike

I have seen a couple posts on flexcoders about the Adobe Dev Center's rotating UI at the bottom of the page.

Check out

RotatingListFX Product

to see how well an encapsulated custom component can create that functionality plus a whole bunch more.

This component is a container that you create children in just like a box or canvas. It gives you the ability to place titled containers within the main component that transition open and closed, minimized to maximized. You also can specify custom tile layouts for the all open state of the container.

This is by far a great value for the price 89.99$ when you receive a supported and encapsulated component with now worry about implementation. After you purchase, you then can use it an unlimited amount of times saving you even more money in development.

The component market is heating up and Teoti Graphix offers development time and money saving components.

Mike

Have you ever felt like you were a dog chasing it's tail when programming? One of the main things I have learned from creating Flex applications is create and destroy.

Creation ::

You create a plan on paper and map out what happens to who and where. Then you go to implement it and you start getting creative. You find easier ways to do things and end up having some extra classes, events that dispatch a little different then intended and methods that abstract and encapsulate even better.

How do we now test what we did not imply?

Destroying ::

This is my favorite part of the iterative process. When you create applications, the best way to make them better is by destroying the very art you sought after.

What do I mean, well I am sure some of you know that by breaking apart an application and purposely killing it, you find it's weaknesses and fix them.

To the beginner, you strive for perfection, which through experience you will never get with software. What I strive for is near perfection. Through years of painstaking meticulous actions, I have learned to let go and kick the table hard to see if the cards fall down. If, they don't your good to go.

Sometimes this process can be more methodical than I make it out to be. But, to those wondering if snapping an application in half for the fun of it is healthy, I recommend doing it.

Yes, there is UnitTests and other things. Sometimes we don't have these tools and good ole remolding of the clay is a perfect solution for any doubts you may have about a 'finished' product.

Peace, Mike

I have had a couple questions and off line chats with some fellow component developers, some questions were raised about invalidation. Specifically,

invalidateProperties()
invalidateSize()
invalidateDisplayList()

I was about to answer the question in a comment but, thought I could put a little more effort into a post.

Ok, for those that like to read...

In my last article a decade or so ago I talked about commitProperties(). I also referred to it as a component's state queue or something like that. Well it turns out that confused some people because they thought I was talking about the UIComponent.currentState property.

Realign,

commitProperties() is the back bone of the components model. There, how about that.

measure() is the back bone of a components dimensions and position.

updateDisplayList() is the back bone of a component's look and feel.

This is where the invalidation methods come into play. The brain in a human is a wonderful thing, it lets us talk, classify, listen etc(our human properties). The brain also measures itself constantly while walking, jumping and laughing(our human measurements) The brain also gives us our identity through what we choose to wear, how we do our hair(human look and feel).

Stack all these weird analogies together and you have one crazy component called the human system. Yes, that's right, we are a organic component, very abstractly.

Now back to invalidation. If you closed your eyes, took a snap shot of what you heard, what you see, how you feel, how big you fell and where you were, this would be your state. Imagine living in that snap shot state for infinity... haha Don't think so, now take that same thought and apply it to a flex component.

Would you want your component to live in a state of unchanging indifference? Of course not!!!

Enter...

invalidateProperties()
invalidateSize()
invalidateDisplayList()

So we have the brain that takes messages from everything, every human interface possible(eyes, ears, mouth, nose, etc) and changes your internal state instantly to feel something else. Well, man, your brain just called an invalidation method it has stored within itself!

When you call an invalidation method, it allows time for all the other senses to link up and sync up. Can you smell 10 things at once, or does you smell happen linearly within 1 millisecond?

The same applies to Flex, life doesn't just happen all at once and things definatly don't change all at once. But, one thing is for sure, things change in groups.

So each invalidation method of Flex changes a part of it's back bone to adjust to the new stimuli.

The invalidateThis() method is like breathing in and the commitSomething() is the breathing out. It also coincides with frame passes of the player to allow the player to use processor cycles efficiently(allows the player to take a breath).

If you want to change your component's internal model state, call invalidateProperties(), flag it and catch the actual implementation of that model change in the component's breathing out method of commitProperties().

If you want to change your component's internal dimension state, call invalidateSize(), flag it and catch the actual implementation of that size change in the component's breathing out method of measure().

If you want to change your component's internal look and feel, call invalidateDisplayList(), flag it and catch the actual implementation of that look and feel in the component's breathing out method of updateDisplayList().

These 6 methods ARE VITAL to any successful components that are to be considered 'professional'.

Once you get the hang of this, you can start creating your own sub ecosystems within your own framework using more aggregate invalidation and validation.

Thats all folks, back to a secret AIR project I am finishing up for component developers that hate how default styles work in Flex.

Peace, Mike

I am starting a series on the flex framework from a component developers point of view ( after much experience). Expect useful articles from a professional and experienced component developer.

Some of you may know what I am talking about others might learn something.

I see some things in a different light now that I have been developing components for a year and a half.

Flex offers a unique way of validating your component when performance is a necessity.

• component property state
• component measurement
• component layout

AKA;

• commitProperties() [This issue]
• measure()
• updateDisplayList()


Properties

Properties in your component hold it's current state. When we talk about state in this respect we are referring to changes made from it's default base state. The default state is what the component's class defines as it's starting point.

In the code above, we set the private variable _moveEnabled to false. We have now set the default move enabled state of the component.

Updating Properties

There is now a way to set the base state but, as you can see the access is private, only for this classes eyes. We now need to create a point at which a developer can change the component's move enabled state.

Enter public properties;

This code is the hallmark of the public property API. Most of your properties will and/or should look like this. Notice some thing we have done;

• Created a place to hold the default state and updated state.
• Created a boolean flag to let all classes below that this state is changing.
• Created a simple access point publicly for the private internal state.
• Created a public place to change the state.
  • For performance, check that we are not already setting a current state with the same value. (this might differ depending on implementation)
  • Set our state changing flag so subclasses are aware our state is changing.
  • Invalidate the component's properties, get a call to commitProperties() on the next validation pass.
  • For bindable properties, dispatch an event to let listeners know we are changing state.

Below is an algorithm my framework follows and I have found it to be extremely successful in creating tighter performance and easier subclassing.

In the above code sample, although we are making a method call here, the performance savings down the road outweigh this one call.

Simply, the above algorithm does this;

• In component state validation.
• Call any super state changes. (this order could be reversed depending on the component's needs)
• If our move enabled state is changing
• Commit that change right now.
• The move enabled state has now changed, switch our move enabled state flag to false.

Note :: With components you create, you will know that in the commitProperties() method that you call commitMoveEnabled(), this is the only place you will call that method. All subclasses rely on the timing of this call. Which in most cases works perfect.

When you subclass this component, your whole move enabled protected commit API is shared. You then have the ability to aggregate private and protected delegation in a logical order starting from the first class that defined the state property.

Some subclasses might just completely override the commitMoveEnabled() method and not even call super. Some classes that define this commit method might actually supply 2 sub commit methods inside this commit method for subclasses to override on a more granular level.

Notice in the code above, you now can subclass this class and override this method completely if you do not want the skins to be updated at this time.

In this subclass, you have not sacrificed the algorithm of the superclass.

Well, that is all for today. I have a bunch more to elaborate and continue with, but that is for the rest of the week.

In my commercial components, I may not release the code but, I want future customers to realize that my API is a new type of SWC. In this new world, you can subclass a component without screwing up it's parent. Plus, all methods that can extend your new product with are there for the taking.

Peace, Mike

From the world of Teoti Graphix comes the Flex look and feel revolution. We are really trying to help developers create original looking applications on the developer front of "Look and Feel". Our latest little gem is the EyeDropperFX component that allows you to use an eye drop sampler in your Flex applications.

We have also just released the FSCollectionFX1 set that has a gradient border and border button class that allow for multiple corner radii, border gradients and fully adjustable highlights. The set also contains a new ColorList, ColorPicker, GroupContainers, Container Watermarking and Form controls.

The information pages can be found here;

Product Pages ::

• FSCollectionFX1
• EyeDropperFX

EyeDropperFX

• Online Help Book(wiki)
• ASDoc Documentation
• Technical Forum
• Ask Before You Buy

FSCollectionFX1

• Online Help Book(wiki)
• ASDoc Documentation
• Technical Forum
• Ask Before You Buy

All these components come with solid support; including asdoc documentation, wiki and dedicated forum support. Each component also comes zipped and ready for archive import into Flex Builder 2 to get you off to a running start with working examples out of the box(zip file).

There are also dedicated issue/feature request areas on the site as well for our customers.

Check out a few screen shot;

EyeDropperFX

This image shows the EyeDropperFX toggle button implemented in the PopUpInfo mxml component that is included with the product.

FSCollectionFX1

Set1 Installation Guide

PackageA (Background Look & Feel)

Watermarking of any container that uses the borderSkin style.

Robust gradient and button borders/skins.

PackageB (Color Pallet)

Stylable color swatches, border thickness, border color and square or stretch layout.

An enhanced color picker to accommodate object/xml color pallets.

PackageC (Form Controls and Containers)

GroupContainerFX borderStyle - solid, inset, outset.

GroupNavigatorFX example using a ViewStack that has 3 child views and uses effects in transition.

Form Controls

Custom Form class inheriting the GroupContainerFX class.

Custom form heading control with title, titleIcon, subTitle, border, verticalAlign, titleStyleName and subTitleStyleName.

Form separator with icon, label, vertical and horizontal align and border.

And to top it all off, a customized UnderlineLinkButton.

Value

By purchasing valuable components for pennies on your development costs, you get support, faster development and original looks for your next Flex application.

We have a lot more planned for Flex Components, it's just the beginning.

While I am at it before I get lost again, check these two screen shots out of my mdi pane.

Here we have a fully dragable tab pane. You can set the position of the tab bar to all positions, top, left, right, bottom. Full flow layout implemented.

You can drag a tab out and into a new window, shift tabs, or even create an new divider that holds the new tab pane with the single tab in it. More later.

Here the effect has run and all of the tabs have turned into WindowFX's! Animation and everything. It uses a proxy so the animation looks goods. Performance is greate, becasue that tab content is actually windows in disguise.

As I said, this was a tid bit since I was hooked into the blog.

Peace, Mike