Equivalent of parent parentDocument from flex - apache-flex

I must turn a Flex code into an Apache Royale one but in my research, there is on attribute for which i dont find the equivalent.
In Flex, to call an actionScipt function from a parent mxml, I have:
<mx:Button label="Login" click="parentDocument.myfunction()"/>
I found parentComponent during my research, but i have Access of possibly undefined property parentComponent error.
I also tried just 'parent' and the error became Call to a possibly undefined method verif_sharedobject through a reference with static type IParent.
I did some research about IParent, Container and Group (From jewel) but for the moment I have no success

please check ParentDocumentBead bead from Core library.
From asdoc :
* The ParentDocumentBead class looks up the parent
* chain to find a parent that was written in MXML.
* Because it is usually rare for an application
* to need to know this information, an optional bead
* is used to compute it, instead of baking in the
* overhead of a recursive infrastucture to store
* this information. It is intended to be used
* as a bead in the top-level tag of an MXML document.
HTH

Related

QML: Is there any reason to set a context property instead of setting a property on the root object, when the latter way has advantages?

Consider this setting of a context property:
engine.rootContext()->setContextProperty("text", "hey");
And this qml code:
Text {
text: text
}
This doesn't work as expected, because of the name shadowing.
One fix is to name the context property _text - then there's no problem. But I don't want to have to remember this naming convention (both to remember to use it, and to remember what it means when I read it).
Another fix is to change the context property into a property on the root object:
engine.rootObjects()[0]->setProperty("text", "hey"); // [1]
and in the QML:
text: window.text
Is there any reason to avoid the latter way when it seems so good?
Setting a context property has one disadvantage - it requires recompilation of the C++ code. Naturally, that's a non-issue if you are exposing a C++ object, which is the typical and only logical use case.
It may be seen as an advantage that the context property can be available before the root object is created, but in most cases it will work equally well if it is just a property of the root object. And I clarify that "most cases" here means that object properties are typically not being set from C++ and not being used in initial bindings, since obviously, if you do that, the initial binding will fail to resolve the property when the object is created, before the property is being set. Also note that when creating QML object form C++, you can use the two step process - prepare the object, then set any properties and so on, and only then complete the object creation, which will delay binding evaluations, so you won't have that problem.
Another possible advantage is that you can have more than one root object, thus if the property is in the root context, then all root objects and their subsequent children will be able to resolve it.
Another possible advantage - when you set a context property, you typically get assistance from the IDE, as that object is now known to be out there, so you will have auto-complete for that property name. It sometimes works for parent object properties as well, but it is a hit-or-miss.
As for the speed of access, I am not so sure that a context property would be faster than root object property. I haven't tested it, but it is just logical. Any object property is a de-facto context property, as each object has its own context. Considering that, as you recently discovered, context properties can be shadowed by object properties, it is thus logical to conclude that a context property lookup simply goes down the object contexts until it finds that property rather than going straight to it, so if anything, resolving context properties should be a tad slower than resolving root object properties, because they go one step deeper.
Until line [1] has been executed, window.text is undefined, so at first, you get an error message on the console (though once it gets to executing line [1], the text is displayed). But if you use a context property, you're free to create it before loading the QML file, which removes the problem.

How to use a String constant in the ID declaration of an MXML component

I was wondering, if you have multiple components files that uses the same child component (but with slightly modified parameters), is it possible to assign that child component an ID with a String Constant?
When I try the following in Flex SDK 3.5, it gives me a compile error:
<!-- Example -->
<mx:Button id="{ComponentIDs.ID_BUTTON_ONE}" />
Error:
"{ComponentIDs.ID_BUTTON_ONE}" is not a valid identifier.
Any guess if this is even possible to achieve? Does the syntax differ for ID fields?
Components ids in MXML are evaluated at the compile time. So you cannot use any kind of expressions there.
So this means that even for the state tag, in its shiney new spark version, neither can any form of String constants be employed in the mxml. So of course, the next train of developer thought is how to do it in ActionScript, and everything goes hunky-dory for creating states in code using Object notation, ... until you realise that the includeIn token is an mxml compiler thing and means nothing to ActionScript ... So there you are, you have to keep using String literals in your code

What does the double colon ('::') mean in Actionscript 3 / Flex?

I'm tasked with updating a Flex project created by an outside contractor and in the Actionscript is the following chunk:
CONFIG::FLASH_10_1
{
//Some code here
}
I've never seen this type of structure before and I'm having a heck of a time trying to search for it on Google - I've found what it means in just about every programming language except AS3. Can anyone shed some light on this?
I'm pretty sure this relates to the conditional compilation features of the Flex compiler.
So, if you add a compiler argument, like this:
-define=CONFIG::FLASH_10_1
I bet that error will go away.
Although this is not the same context, to answer the question of what double colon "::" means in AS3...
It is a namespace accessor.
For example, the AS3 Vector.<T> type actually has a runtime type name of __AS3__.vec::Vector.<T>, where __AS3__.vec is the custom namespace. You can also use custom namespaces for members and access them on objects in AS3 using the syntax object.custom_namespace::membername. public and private are built in namespaces, so technically you could access public members like object.public::membername, as in:
var a:Array = [0,1];
trace(a.public::length); //prints 2
Not a flex / AS3 guru - this thread talks about the '::' being used as a "Namespace accessor":
Thread on Actionscript FAQs

Getting the target when using bindable getter in flex

I have the following files:
model.as
clint.mxml
in clint.mxml I have the following line:
<s:Group id='clint1' x="model.locationX">
...
in the model.as I have a getter:
[bindable(event="locationXChanged"))
function get locationX () : int {
return ...
}
My problem is that I need to know within the getter locationX that the id of the object that is getting the id is clint1 (The object id in the mxml).
The result of a getter should not depend on which object it is called from. I guess your getter should not be a getter and should maybe take a clintId as argument.
You can use this to refer to the current component. You can use 'this.id' to find out the component's name. More info on id property.
However, I'm getting mixed signals from your question and the question's title. Are you asking for the id of the binding target inside the binding source? Implementing that would add dependencies to your components thus harming their ability for reuse.

React to change on a static property

I'm re-writing an MXML item renderer in pure AS. A problem I can't seem to get past is how to have each item renderer react to a change on a static property on the item renderer class. In the MXML version, I have the following binding set up on the item renderer:
instanceProperty={callInstanceFunction(ItemRenderer.staticProperty)}
What would be the equivalent way of setting this up in AS (using BindingUtils, I assume)?
UPDATE:
So I thought the following wasn't working, but it appears as if Flex is suppressing errors thrown in the instanceFunction, making it appear as if the binding itself is bad.
BindingUtils.bindSetter(instanceFunction, ItemRenderer, "staticProperty");
However, when instanceFunction is called, already initialized variables on the given instance are all null, which was the cause of the errors referenced above. Any ideas why this is?
You have 2 options that I am aware of:
Option 1
You can dig into the code that the flex compiler builds based on your MXML to see how it handles binding to static properties. There is a compiler directive called -keep-generated-actionscript that will cause generated files to stick around. Sleuthing through these can give you an idea what happens. This option will involve instantiating Binding objects and StaticPropertyWatcher objects.
Option 2
There is staticEventDispatcher object that gets added at build time to classes containing static variables see this post http://thecomcor.blogspot.com/2008/07/adobe-flex-undocumented-buildin.html. According to the post, this object only gets added based on the presence of static variables and not getter functions.
Example of Option 2
Say we have a class named MyClassContainingStaticVariable with a static variable named MyStaticVariable and another variable someobject.somearrayproperty that we want to get updated whenever MyStaticVariable changes.
Class(MyClassContainingStaticVariable).staticEventDispatcher.addEventListener(
PropertyChangeEvent.PROPERTY_CHANGE,
function(event:PropertyChangeEvent):void
{
if(event.property == "MyStaticVariable")
{
someobject.somearrayproperty = event.newValue as Array;
}
});
I think you need to respond to the "PropertyChanged" event.
If you're going to do that, use a singleton instead of static. I don't think it will work on a static. (If you have to do it that way at all, there are probably a couple ways you could reapproach this that would be better).
var instance:ItemRenderer = ItemRenderer.getInstance();
BindingUtils.bindProperty(this, "myProperty", instance, "theirProperty");
After fiddling with this for a while, I have concluded that this currently isn't possible in ActionScript, not even with bindSetter. It seems there are some MXML-only features of data bindings judging by the following excerpt from the Adobe docs (though isn't it all compiled to AS code anyways)?
You cannot include functions or array
elements in property chains in a data
binding expression defined by the
bindProperty() or bindSetter() method.
For more information on property
chains, see Working with bindable
property chains.
Source: http://livedocs.adobe.com/flex/3/html/help.html?content=databinding_7.html
You can create a HostProxy class to stand in for the funciton call. Sort of like a HostFunctionProxy class which extends from proxy, and has a getProperty("functionInvokeStringWithParameters") which will invoke the function remotely from the host, and dispatch a "change" event to trigger the binding in typical [Bindable("change")] Proxy class.
You than let the HostProxy class act as the host, and use the property to remotely trigger the function call. Of course, it'd be cooler to have some TypeHelperUtil to allow converting raw string values to serialized type values at runtime for method parameters (splitted by commas usually).
Example:
eg.
var standInHost:Object = new HostFunctionProxy(someModelClassWithMethod, "theMethodToCall(20,11)");
// With BindingUtils.....
// bind host: standInHost
// bind property: "theMethodToCall(20,11)"
Of course, you nee to create such a utlity to help support such functionality beyond the basic Flex prescription. It seems many of such (more advanced) Flex bindings are usually done at compile time, but now you have to create code to do this at runtime in a completely cross-platform Actionscript manner without relying on the Flex framework.

Resources