I am checking this guy's code...
http://www.codingcolor.com/as3/as3-youtube-chromless-api/
I have download the source code...but I couldn't figure out how he add the play, pause and stop button in the stage. I know in his VideoPlayerControl.as, he has
playbackControl = new PlayPauseButton();
playbackControl.addEventListener(Event.CHANGE,setPlaybackState);
addChild(playbackControl);
in his PlayPauseButton.as. there is not code for the location of the button(x,y)..
I am not sure how he place the control buttons....
Also...Are there anyways to give the button location with object oriented way instead of specify it with static number???
I appreciate any help...
Without reviewing his code...
it sounds like you need to read up on the Flex Component Lifecycle.
In normal cases, the PlayPauseButton will be created and added in createChildren().
the updateDisplayList() method will position and size the elements. Additionally, many components implement a measure() method that will determine the ideal size for it. And many containers have code to automatically lay out the children. If the PlayPauseButton has a measure method and it is added to a container (such as an HBox of VBox) he won't need code to position or size the button as that wrk is already done in the code that he inherits from the Flex framework.
Related
I am developing a JavaFX application where a class I have developed (extended from javafx.scene.Parent) is created on-the-fly based on what entry the user has clicked in a ListView control.
Just to be clear about this node, it is not created using a layout tool like SceneBuilder, it is created at runtime based on the user's actions.
The constructor for my custom node class creates a VBox and a Label and uses passed coordinates (X,Y) in the constructor method to set its own Layout coords. I then use a custom utility class to make the node draggable. This new node is then added to the main application Pane.
However, I have failed to find out how I can make these nodes resizable by the user. That is, allow the user to mouse over the corner of the node, hold and drag to resize. An operation that all users are used to, no matter what the OS.
Has anyone done anything like this in JavaFX? (My searches on the subject only seem to pull up subjects on the automatic resizing that a parent node does with its child nodes.)
Many thanks,
Ian.
As you can see on the documentation of VBox you can only define minimum, prefered and maximum range, there's not really a way to make it manually resizable.
The only proper solution to solve your problem is to develop your own class to do it, because what you want seems very specific, with your problem description, I don't think use some layouts or panels will do what you exactly want.
I found something that you can use : Dragging to resize a JavaFX Region
This allows you to resize a region, all you have to do after is to put you VBox in this region, but notice in this article that :
Only height resizing is currently implemented.
This code won't work in JavaFX8, you'll have to check the comment to see how it worls in JavaFX8
Hope this helps.
This is a general question on optimization technique and please I am more than willing to rewrite a majority of my code as I am moving a lot of it to a library.
My concern applies not so much to flex performance as I have used methods that have reduced cpu/memory footprint so performance is quick when inside a view.
The problem I have is with the navigator.pushView which seems slow, I do call my init function on creationComplete for the view but I have it factored so my init looks like:
private function init() : void {
doStuff1();
doStuff2();
doStuff3();
}
What can I do to make the view transition smooth? This is on a mobile device.
I have considered delaying off all of the code inside the init function using a timer so that for lets say the first 3 seconds there is nothing happening and the view has all the frames it needs but that doesn't seem right.
Advice would be much appreciated!
Thank you,
Performance really depends on what you're doing in those "doStuff()" methods. A few things to consider:
1) At the time creationComplete() executes; the view has already rendered once. Are you doing anything that will cause the thing to render itself again? Changing styles, and many properties on children components will cause that child to re-render and often the view component.
A lot of people use creationComplete as a constructor when, in reality, that is the worst place to put "constructor style" code. Instead you should consider using preinitialize for most stuff, or initialize if you need to set properties on children components.
2) viewActivate executes after the transition occurs. So, perhaps you should consider moving code out of creationComplete and into viewActivate. More info on a mobile view's lifecycle is here.
I have a Flex application, running with Flash Player, not AIR, that contains a Tree that I would like to put a custom context menu on.
Tried just doing <mx:Tree ... contextMenu="{MyClassWithStatic.menu}">, but that didn't do anything.
Went searching, and found this quote from some Adobe docs somewhere
In Flex or Flash Builder, only top-level components in the application can have context menus. For example, if a DataGrid control is a child of a TabNavigator or VBox container, the DataGrid control cannot have its own context menu.
so went upwards, trying each parent element until I reached my <Application>-element, which is consistent with what they wrote.
Tried making a Flex component, based on Group (the default) which contained my tree, and the context menu on the top-level element there, hoping it would work, but to no avail.
Is there any other way to manage this that I haven't found yet?
The code I use to create the menu:
var menuItems:Array = [];
var rename:ContextMenuItem = new ContextMenuItem("Rename");
rename.addEventListener(ContextMenuEvent.MENU_ITEM_SELECT, renameSelectedHandler);
menuItems.push(rename);
menu.customItems = menuItems;
menu.hideBuiltInItems();
You're right, the contextmenu only works on top level components. It's a limitation of Flex which is annoying and shouldn't be there in the first place. There's not much you can do since there is no way to capture the event other than using some Javascript trickery, but even then, it doesn't tell you where you were clicking.
If I were you, I would just forget the concept and go away from using right click altogether if possible.
I can't be sure, as all the code isn't' there. But you seem to have ignored your own research. Don't use your new component, or anything which "contains" your tree. Then just stick the Tree in your application.
Also I've a memory of TreeItemRenderer not being the same as in other UIcomponents. Maybe, test your "menu" code with a Datagrid first and make sure it works. Good luck
I did not try it myself, but after reading the comments on http://michael.omnicypher.com/2007/02/flex-trees-with-context-menu_14.html it looks like you could add a context menu to the tree's item renderer.
The article and comments at http://blog.arc90.com/2008/04/21/adding-a-contextmenu-to-a-flex-tree/ are worth a look too.
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/
What is the best way to render to a UIComponent which hasn't been added to the stage? (I'm using UIComponents as renderers for objects, and want to render new copies for image export, filtering, etc.)
Two strategies I've seen/used so far include realizing the component to ensure it calls all the lifecycle methods:
Add the component to Application.application, render with BitmapData.draw(), remove component. This is similar to what I've seen done for printing unrealized components as well.
Add the component to a pop up window, render with BitmapData.draw(), dismiss popup after rendering complete.
I believe both of these just rely on the UI not refreshing while the current thread/event is executing, though (1) could also rely on the component being realized out of view.
Is there a better way?
What I've used in the past with much success is the following:
Create a new instance of your component
Add an event listener for FlexEvent.CREATION_COMPLETE
Set visible=false on the component
Add the component as a child of the main Application
When the component is created, the event listener function will be invoked. The rest of the logic should be put in / invoked from your event listener function
Remove the event listener you added in step #2.
Use ImageSnapshot.captureImage() or captureBitmapData() to capture the visual representation of the component.
Remove the component from the main Application
Process the image data as you need to.
I've used this to snapshot various Flex charting components for use in PDF's generated on the server side. After getting the BitmapData I use the PNGEncoder or JPEGEncoder classes to compress the data, then encode it in Base64 before uploading to the server.
I'm pretty sure you can use the draw() method in BitmapData without having your component on the DisplayList.
For example is use it when I need to modify images I load with the Loader Class. In the init handler I create a BitmapData instance and draw the Bitmap from the loadInfo.content property, then copyPixels() or whatever I need to modify the loaded image
So much of a UIComponent's layout can be tied to it's context. This is especially true for a lot of its derivatives (e.g. HBox) since the fluidity of the layout is tied to it's parent's size and the number of siblings sharing its parents space.
Additionally Flex can be a real pain to get to visually update. Often critical render functions aren't done synchronously ... there are callLater, callLater2 and other hacky approaches that make dealing with the auto-magical layout properties of UIComponents a major headache. Not even calling validateNow or updateDisplayList can guarantee that the layout will be correct on the current frame (instead of a few frames in the future).
I suggest the best thing you can do is not use a UIComponent and try and use a Sprite or other.
Your approach to attach it but make it invisible (alpha = 0, mouseEnabled = false, mouseChildren = false) is decent. You should listen for the FlexEvent.CREATION_COMPLETE callback before you are certain it is properly laid out. Then you can bitmapData.draw it and then remove it from the stage. If you must use UIComponents then I know of no better way.
You can call the lifecycle function manually before using the BitmapData.draw(). Do the following.
createChildren().
commitProperties().
updateDisplayList().
bmd.draw().
The first 2 steps are not 100% necessary, you can put all codes into updateDisplayList(). Because you invoke the function manually, you don't have to worry this is invoked by Flex framework many times.