I am extending VBox to make a Calendar component. What method should I override to add the code to draw itself? What is the difference between all these methods? Is there something I should be putting in each one, or is there a specific method I can just override, add my drawing code, and have it work?
Thanks!
This white-paper is perhaps the best source of information I have seen on the subject.
Deepa's MAX 2008 talk was easily the best and most easily understanding presentation on the topic. It shows exactly how to write components properly in Flex 3.
I also recommend this article:
http://maohao.wordpress.com/2009/02/02/6-steps-in-creating-custom-uicomponent-in-flex-halo-framework/
Briefly, if you're doing graphics operations to draw, you'll want to use override updateDisplayList() and call invalidateDisplayList() as necessary; if you're using subcomponents, you'll use commitProperties()/invalidateProperties(). If you're dynamically sized, you'll need measure() and invalidateSize().
Override updateDisplayList method of UIComponent and do your drawing in it. Use the component's unscaledWidth and unscaledHeight as the bounds for drawing.
From Adobe Flex 3 Live Docs Advanced Visual Components in ActionScript - great source.
Related
I’ve been using Xamarin.Forms for a bit lately and can generally get enough information following the Microsoft docs. But I seem to be stuck now that I need to create a custom renderer, so if someone could help, I’d really appreciate.
I read through the docs on creating a custom render and maybe I missed the part I’m looking for, but I’m not able to tell if as part of OnElementChanged, I also need to render all the children of the Element?
The ContentPage could have a StackLayout for example with several child elements. If I dont have to render these, how do they get rendered/laid-out?
No, you don't need to render ContentPage's children.
When you create a Custom Renderer you are only extending Xamarin's renderer, meaning you only add functionality (unless you explicitly change something, like redefining a property).
So, basically, the ContentPage render/lay-out the children the same way it renders/lays-out without the Custom Renderer.
Answering your second question, actually the layout and positioning is done without renderers, as said here Xamarin.Forms Layouts.
If you want to dig deeper, you can try to understand how the ContentView (it's the easier one) is positioned by reading the source code. Here the TemplatedView (ContentView's base class) is calling LayoutChildIntoBoundingRegion for each of its children: TemplatedView.
Then this line on the LayoutChildIntoBoundingRegion calls the Layout method of the view: Layout.
The VisualElement.Layout method only gets the rectangle and sets the Bounds of the view (Layout Method). The Bounds setter is called: Setter.
Well, now you can go on and explore more of the source code if you want, but I think you got the idea ;)
Hope it helps!
I'm moving some Flex classes to pure Flash/AS3 to be part of a shared library. I have an event listener on FlexEvent.CREATION_COMPLETE to create and add display-objects once things are running, but I don't know the right way to do this in Flash?
edit: Maybe if my class subclasses Sprite rather than a Flex class, I can add children in the constructor, I don't need to wait for a "construction complete" event?
It depends on what you are trying to do: When you add children in the constructor, you will not be able to depend on any information about the stage and/or other elements on it. I have found it a better practice to add an event listener for Event.ADDED_TO_STAGE in the constructor, and have the handler method initialize the element.
You're really comparing apples and oranges here.
The Flex Framework is a UI Framework, and the CREATION_COMPLETE event is part of that framework.
Flash Professional is an IDE, primarily geared for creating animation. It has ActionScript support, but is not a framework and does not offer anything beyond native ActionScript other than libraries or classes you build, buy, create, or borrow.
If you want some parallel to creationComplete, you'll probably need to find--or create--a UI Framework. It is, in theory, possible (although not easy, nor something I'd recommend) to initialize the Flex Framework for use inside a Flash IDE created movie. After all, under the hood it is all ActionScript.
creationComplete Dispatched when the component, and all of its child components, and all of their children, and so on have been created, laid out, and are visible.
See more info on the flex life-cycle events and some that are plain flash here: also +1ed the added_to_stage as it's likely what you'll need in this case.
http://livedocs.adobe.com/flex/3/html/help.html?content=containers_intro_3.html
I'm moving to a pure as3 environment into flex and I have a question about preloaders.
For one of my apps in particular when the swf loaded I would add a screen with an animated preloader. Then at a particular point in my code when I know all of my xml has been parsed, UI built and all initiliztion done I dispatch a "done" event which removes the preloader.
How can I achieve this is flex? I've only ever really seen flex preloaders that are percentage based which I believe represent the actual loading of the swf itself?
Please read the flex cookbook for preloaders, they have some demo applications, that could help u out
actually there is a preloader property in the application tag,
that could be wht u might help u out
tc
Ankur Sharma
Flex has a ProgressBar control that you can use for similar purposes. If you want to continue to use your own custom animated progress bar, you can add that Sprite to the rawChildren of a Container (preferably Canvas) and show it as a modal pop-up using the PopUpManager - remove the pop-up from the done event's handler.
The overriden addChild method of the Container class will throw an error if you pass a child that doesn't extend UIComponent - that's why you should use rawChildren.addChild.
Yep default flex preloader represents the loading of the swf itself.
If I were you, I would use the Task library from the Cairngorm 3 Libs, works perfectly with a preloader :
http://opensource.adobe.com/svn/opensource/cairngorm3/trunk/libraries/TaskTest/src/samples/TaskFlowPreloader.as
I've read in the flex developer guide that you sometimes need to override one
of the lifecycle methods like: commitProperties and updateDisplayList
but I've written a few flex apps without ever needing to implement them.
when do I need to override them?
First, I 100% recommend studying this presentation by EffectiveUI:
Diving Deep with the Flex Component Lifecycle
and this by Michael Labriola from Digital Primates:
Diving in the Data Binding Waters
They go into things you'll never find in the docs but that are super practical for understanding the Flex Component Lifecycle.
From my experience, the only time you need to worry about overriding core lifecycle methods is if you are creating components. I make a distinction between Application Views and the Components.
Components are things that need to be nearly perfect, highly optimized, and extremely versatile/abstract.
Views are things that you may only need in one Application, but could reuse if you so desired (LoginScreen, ContactForm, etc.).
Views, for the most part, are just adding things to the display list of a more generic component (Canvas, Group, Container, VBox, List, etc.). You, as a View/Application developer, don't really care about how the "dataProvider" creates it's itemRenderers, it just works.
Components are a different story though. When you create a component, you want it to fit perfectly into that system Flex has set up: the Component Lifecycle. It's pretty tough when you first try to build a component like they do, but after you wrap your head around it it's super easy. Here's how I think of the methods when I develop components:
createChildren()
Called once when component is constructed
Called top down. So if Panel calls createChildren, it's createChildren method will call addChild on all of it's children, which calls initialize, which calls createChildren.
If you created a custom component, say a StarRatingComponent, you might want to add 5 stars to the stage when the component is constructed. So you'd override createChildren() to do add stars to the component you're in. By default, though, all Container components in the Flex SDK add their children here (lists do it a bit differently), so you never have to do this if you're building MXML views or something not-to-be-extremeley-reusable.
The next 3 methods are called 1 frame after properties are set.
measure()
If the parent doesn't have any sizing (percent or explicit), it will need to be sized based on it's children's sizes. This can only happen from the bottom up (took me quite a while to really wrap my head around that).
If the parent has explicit or percent sizes, it skips this step.
You override measure if you want to:
Have measuredWidth or measuredHeight return a useful value. So if you build a custom CoverFlowContainer component, and measuredWidth/measuredHeight aren't set (because measure was not overriden), then if you don't specify any sizing on CoverFlowContainer, it would be 0 width 0 height. So instead, override measure and have it set measuredWidth to radius * 2 or something like that, and now you don't need to give it a size!
If the component does not have an explicit or percent size, measure will be used to size the component. Otherwise it's skipped.
commitProperties
Called after measure.
Applies all property changes (from setting properties on the component) to the component (they were stored in private variables for that first frame).
Called a frame after initial property settings.
This is the most important method to override in my opinion. So for your CoverFlowContainer, say you set the hypothetical distance, gap, selectedItem, and tilt properties. When you set them, store them in private variables. Flex will wait a frame, and call commitProperties. In your overridden commitProperties, you can then say layout.updateEverything(selectedItem, distance, gap, tilt); so to speak. So this is the method you override to make all property changes be applied at once.
updateDisplayList
Called after commitProperties
Called top down.
You only override this to set visible properties on the component, such as setActualSize, graphics, etc. But by now (because of `commitProperties), you have all your required variables to update the display set to the right values.
Overall
So from my experience, I worked a lot with these lifecycle methods when creating a component library for things I would use in a million projects:
TitleWindow (my own version)
View3D (for Away3D/Papervision)
Tree and Stack for Flex 4
TextArea (with prompt, expandable, etc.)
ToolTip (easier to skin tooltip)
I needed to make sure everything was updated and rendered perfectly according to the lifecycle. Reading and understanding the Flex 4 Spark Source Code really helps clarify when to override these methods. As does the Openflux Source Code (very simple, clear alternative to the Flex Framework. Not as feature rich so it shows how to bare-bone override those methods to accomplish some pretty advanced things).
When I develop applications and make things like AdvertismentView, MenuView and LoginView, I don't ever think about it because all the components I'm using have already solved those problems (ViewStack, Group, List, etc.). I'm basically just setting properties they've defined and updated in their own commitProperties override.
The only time I would start overriding lifecycle methods in a View would be when I need to access custom variables from outside the view. So say I had a custom RichTextEditor and I created some properties called showFontControls and showStylePanel. When I set those variables, I would probably do what they described in the Data Binding Presentation: accessor sets private variable and calls the invalidation methods, lifecycle methods execute a frame later and I have overridden commitProperties and updateDisplayList to show those panels and fonts. But in practice, that's probably overkill because it wouldn't offer that much of a performance gain for the amount of work it would take. I'd just set up some binding to a visible property in that case. Nevertheless....
The best thing to do to really get into this is to just download the Flex SDK Source and see what they're doing.
Hope that helps.
Lance
Here's another presentation by Deepa (from the Flex framework team) that goes over a lot of the same framework methods, including a nice explanation of why the whole invalidation model exists to begin with:
http://tv.adobe.com/watch/max-2008-develop/creating-new-components-in-flex-3-by-deepa-subramaniam/
I'd like to develop a network graph application for Flex - imagine placing nodes on a Canvas and connecting them with links. The nodes should have editable text and other UI components.
I'm trying to find examples of creating an entirely new UI component from scratch, but all I've been able to find are trivial examples that extend existing components: a RedButton that extends Button, for example, or a ComboBox that has states to choose from.
My main question is, what ActionScript method defines the drawing of a component? What is the ActionScript equivalent of Java's paint() method?
You want to create a component that overrides the updateDisplayList method, and do your drawing in there:
override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
super.updateDisplayList( unscaledWidth, unscaledHeight );
// The drawing API is found on the components "graphics" property
graphics.clear();
graphics.lineTo( 0, unscaledWidth );
// etc
}
More information can be found here: http://livedocs.adobe.com/flex/3/html/help.html?content=ascomponents_advanced_3.html
I would suggest looking at the flexlib project if you need examples of custom components.
There's good general info in the livedocs here
Although you can create custom components in MXML and in ActionScript, I would recommend implementing them in ActionScript.
In short this is what you need to do:
When you create a custom component in ActionScript, you have to override the methods of the UIComponent class. You implement the basic component structure, the constructor, and the createChildren(), commitProperties(), measure(), layoutChrome(), and updateDisplayList() methods.
I recommend reading the 5-part tutorial series by Peter Ent on creating custom components.
Here is the link to Part 1.
Also recommended, tutorial series on ItemRenderers and ItemEditors.
Chapter 19 of Programming Flex 2 by Kazoun and Lott show the construction event model as well as the refresh event model.
In short, the Flex component structure assumes that you have properties of the object that affect its appearance. Instead of applying changes immediately, it allows property mutators to invalidate the component's "content" (e.g. text) via the inherited invalidateProperties() method. One also calls invalidateSize() when a property change will, ummm, change the size of the component, and invalidateDisplayList() when things need to be re-drawn (as opposed to just having different text).
This invalidation model optimizes the work of the component. It does not measure itself unless it knows it changed size; it does not place and draw itself unless something called invalidateDisplayList() since the last time it updated its layout; and it does not move its properties' values into its subcomponents unless it knows those values have changed.
Cheers
The typical behavior is to subclass an existing component, mainly because so much of the work of implementing the functionality of so many of the most typical kinds of components is already done for you -- you just have to know which component most resembles the one you want to create. (A challenge in its own right, given how many there are.)
If you like, though, you can create a pretty bare-bones UIComponent "from scratch" simply by extending UIComponent (which'll give you all the baseline stuff), or I suppose, if you're really going for minimalism, and you're up for a challenge, you can just implement IUIComponent, and define each interface method manually. If you do choose to go that second route, do yourself a favor and listen to this talk first -- it's an in-depth discussion of the Flex component architecture, given by one of the engineers on the Flex team. I recommend it often, and highly; it's excellent, and it clarifies a number of component-development details that still aren't all that well documented. Extremely valuable stuff if you're going to be building non-trivial custom components of the kind you're describing.
Hope it helps. Good luck!