(This may be too localized an issue but I will try to generalize it)
Question: If a property setteris marked as Bindable, will it not get called if the new value is the same as the old value?
I am seeing the above behavior in a legacy project I have inherited: the setter is not getting called. If I don't declare the setter as Bindable then the setter is called no matter what the new value is.
Can anyone confirm that the above is the way things are designed to work with Binding?
This project uses Binding all over the place and there are no comments in the code so it is hard to tell what the dependencies are and which parts of the code depend on particular bindings. I'm trying to avoid making major changes but I also don't want to waste time trying to work around something which should be refactored.
The property is bound:
[Bindable]
protected var _source:AolMediaFile;
The setter is bound:
[Bindable]
public function set source(file:AolMediaFile):void{
_source = file;
// do some stuff with file
}
The setter should only get called if the event source is [Bindable]. Data binding is basically a chain of events dispatched from source to target in a variety of scenarios. When you declare your property or setter as [Bindable], that will basically change nothing in the behaviour in terms of side effects, as events are dispatched and listeners are generated. For example:
<your:Component source="{any.source.aolMediaFile}" />
Only when any, source and aolMediaFile are declared [Bindable], source would be invoked. Having source declared as a [Bindable] property is only interesting, if a second component would be depending on your component's state
<your:Component id="yourComponent" source="{any.source.aolMediaFile}" />
<s:TextField text="{yourComponent.source}" />
If you would want to bind to a property of AolMediaFile, then the class or the specific property has to be be [Bindable] as well.
Usually the compiler prints warnings, if bindings can't be generated:
warning: unable to bind to property 'source' on class 'Object'
(class is not an IEventDispatcher)
So check the source object, which are the source's host object's dependency and the compiler warnings.
So digging around here a bit more I came across this question: Flex: Help me understand data Binding on getters and setters which describes the code generated by declaring a setter or getter Bindable
So apparently in the generated code there is a check to see if the value is different:
public function set name(value:String)
{
if (_name == value)
return;
_name = value;
dispatchEvent(new Event("nameChanged"));
}
Related
I need to set the Xaml property of a RichTextBox user control via a binding expression in Windows Phone 8, and I found that it is not a DP, so I have decided to inherit from a RichTextBox and add a DP that will change the Xaml property with PropertyChanged event, anyways the code looks like this, stripped out irrelevant parts.
public class RichTextBoxWithBindableXaml : RichTextBox
{
public string BindableXaml
{
get { return (string)GetValue(BindableXamlProperty); }
set { SetValue(BindableXamlProperty, value); }
}
public static readonly DependencyProperty BindableXamlProperty =
DependencyProperty.Register("BindableXaml",
typeof(string),
typeof(RichTextBoxWithBindableXaml),
new PropertyMetadata(0));
}
//xaml code
<local:RichTextBoxWithBindableXaml BindableXaml="{Binding PageContent , Mode=OneWay}"> </local:RichTextBoxWithBindableXaml>
And I get the following dreaded exception message:
Object of type 'System.Windows.Data.Binding' cannot be converted to type 'System.String'.
I have checked many solutions to these exceptions and similar problems with data binding, and still going through the suggested similar questions on the right, and still cannot see why a simple thing wont work for me. The code I listed above is just the simplest implementations of a DP with a binding expression. Btw, the source PageContent is from a INotifyPropertyChanged object, and it works, I know because, it can bind to TextBlock's Text property.
Am I missing out something so obvious? I wouldn't want to post question for such a straightforward thing, but I cant seem to solve in any way.
EDIT:
Following P.S note turned out to be completely irrelevant.
P.S. My final doubt was on the way xmlns namespace local is loaded. It is loaded as clr assembly, could xaml parser think my custom inherited class as clr-only and confuse since clr properties are not dependency properties. Hope it doesnt sound stupid, i'm desperate. It is as such :
xmlns:local="clr-namespace:RumCli"
I found out that I should either provide a null PropertyMetadata (new PropertyMetadata(null) instead of 0), or a metadata with a default value type if the DP is supposed to be used in Xaml. For my sceneario, since I will make use of the PropertyChangedCallback, the propertymetadata that will passed to the Register method looks like this.
new PropertyMetadata(default(string), new PropertyChangedCallback(OnBindableXamlChanged))
hope, it helps to others.
For each dependency property one must supply a non subscribed value (not a C# term here) which suites the type of object which the consumer will access.
To quote MSDN Dependency Property Metadata
Dependency property metadata exists as an object that can be queried to examine the characteristics of a dependency property.
So for the value type results, a default for the different value types, such as a double is to use double.NaN. A decimal use decimal.Zero. While a string, string.empty is good as a base.
That allows whatever operation which may blindly reflect off of the property, it can determine what its true property type is and access it accordingly.
So assigning 0 to a string makes no sense in identifying that the property is a string which 0 identifies it as an integer. So the int as string is setting up a future runtime failures when objects try to assign bindings, styles and other items to it.
In ActionScript 3.0, this compiles:
public function set func(value:Function):void
{
}
public function func():void
{
}
This doesn't:
public function set someVar44(value:int):void
{
}
var someVar44:int;
Why does the first one compile? I suppose it's possible that Adobe just specifically and arbitrarily decided to block this for variables and to allow it for functions, but allowing it for either functions or variables doesn't seem to make any sense. I'm suspicious there's more to the story here. What am I not seeing?
This is really interesting, and took a fair amount of digging to get down to (although the answer seems painfully obvious).
As you know variables/properties cannot be declared in the same scope with identical names. Therefore the set function someVar44() and the variable someVar44 are in direct conflict (besides issues with trying to initialize the variable twice). Conversely if you had tried:
public function get func(value:Function):void
{
}
you would have ran into a similar issue with a duplicate function definition error. So why does the set function seem to allow you to get past these errors? As setters and getters are known for accessing and mutating properties of a class, it would seem they are also treated as class properties as opposed to a typical method, but this is not entirely the case. In fact, only the setter appears as a property of the public interface, the getter on the other hand is a method that can read like a property.
The setter:
public function set func(value:Function):void
Is read exactly like a property of the object, and without any other properties in direct conflict with it (i.e. - there is no current property like var func.) you do not receive a compiler error.
From adobe:
set Defines a setter, which is a method that appears in the public interface as a property.
get Defines a getter, which is a method that can be read like a property.
I believe that is why you are not getting a compiler error with set method. Although if you attempt to access that set method, the priority is immediately assumed to the function func(). That is, if you attempt this.func = function():void { } you will get the error:
Error #1037: Cannot assign to a method func
I can understand logically why the first compiles (in the older compiler). When considering an instance of the object, getting the obj.func property should return the member function you've defined, while setting the obj.func property should call the setter you've defined. This doesn't seem to be an ambiguity to me, though as we've seen, the runtime disagrees with me.
In the second case, you've defined a var (which defaults to the internal scope since you didn't say public, but that's another story) which, being externally visible, implicitly defines a getter and setter. So if someone sets the obj.someVar44 property of your object, are they calling the setter or setting your variable value? It's clearly an ambiguity and a duplicate definition.
I was reading a tutorial and the user there was starting setters and getters like so
function get f():Number;
function set f(value:Number):void;
inside an interface, then saving it in the main file inside a variable
var testNode:INode;
and referencing them as
testNode.f;
I thought this was really handy, specially for when you have a lot of variables. Instead of having to create two functions for each private value.
However, I tried to do the same without instancing the get and set inside an interface (because I had no need for this) and I get an error saying the function doesn't have a body.
Why is that? Is there any way to write get and set in such a clean, short manner? So far I've been writing these as
public function get someVar():SomeClass {
return _someVar;
}
public function set someVar(newValue:SomeClass):void {
_someVar = newValue;
}
but it's a bit of a hassle when I have several private variables.
An interface is just a model for your class, it does not allows you to skip the definition of a function (or a getter/setter). You must declare the getter and the setter in any class implementing your interface. What you are looking for is an extension (inheritage).
If you define a class Mother.as with a getter and a setter, the class Child.as which extends Mother.as doesn't need to redefine the getter and setter.
Furthermore, if you don't plan on writing anything else inside the getter and setter, you should use a public variable. These are less resource consuming than useless get/set.
Ok, so this might be me being pendantic but I need to know the best way to do something:
(This is psudocode, not actual code. Actual code is huge)
I basically have in my package a class that goes like this:
internal class charsys extends DisplayObject {
Bunch of Variables
a few functions
}
I another class which I intend to add to the timeline I want to create a function like this:
public class charlist {
var list:Array = new Array();
var clock:Timer = new Timer(6000);
var temp:charsys;
function addObj(MC:DisplayObject, otherprops:int) {
temp=MC;
temp.props = otherprops;
list.push(temp)
}
function moveabout(e: event) {
stuff to move the items in list
}
function charlist() {
stuff to initialize the timers and handle them.
}
}
So the question is, is my method of populating this array a valid method of doing it, is there an easier way, can they inherit like this and do I even need to pass the objects like I am?
(Still writing the package, don't know if it works at all)
Yes, you can pass an object into a function, but you should be careful of what you are planning to do with that object inside that function. Say, if you are planning to pass only charsys objects, you write the function header as such:
function addObj(MC:charsys, otherprops:int) {
Note, the type is directly put into the function header. This way Flash compiler will be able to do many things.
First, it will query the function body for whether it refers to valid properties of a passed instance. Say, your charsys object does not have a props property, but has a prop property, this typing error will be immediately caught and reported. Also if that props is, for example, an int, and you are trying to assign a String value to it, you will again be notified.
Second, wherever you use that function, Flash compiler will statically check if an instance of correct type charsys is passed into the function, so if there is no charsys or its subclass, a compilation error is thrown.
And third, this helps YOU to learn how to provide correct types for functions, and not rely on dynamic classes like MovieClip, which can have a property of nearly any name assigned to anything, and this property's existence is not checked at compile time, possibly introducing nasty bugs with NaNs appearing from nowhere, or some elements not being displayed, etc.
About common usage of such methods - they can indeed be used to create/manage a group of similar objects of one class, to the extent of altering every possible property of them based on their corresponding values. While default values for properties are occasionally needed, these functions can be used to slightly (or not so slightly) alter them based on extra information. For example, I have a function that generates a ready-to-place TextField object, complete with formatting and altered default settings (multiline=true etc), which is then aligned and placed as I need it to be. You cannot alter default values in the TextField class, so you can use such a function to tailor a new text field object to your needs.
Hope this helps.
This would work, I think I would assign values to the properties of the charsys object before passing it into the add method though, rather than passing the properties and having a different class do the property assignment. If you have some common properties they could either have defaults in charsys class definition or you could set literals in the addObj method.
I was reading ActionScript 3.0 Abstract Factory Design Pattern: Multiple Products and Factories, and I have the following,
private var busFactory:AbFactory;
busFactory=new BusinessFactory();
Both in BusinessFactory.as and in AbFactory.as there is no method with the same name as the class, only createProductA and createProductB. So, how could busFactory call the constructor with new BusinessFactory ?
The default constructors for both AbFactory and BusinessFactory (which the article shows inherits from AbFactory) are created by the compiler.
If you start to pass arguments to the BusinessFactory() constructor, the compiler will complain about an unexpected argument count. That's when you need to write the constructor yourself. But passing nothing means the default can be used.
Also the reason that you could set a AbFactory to a BusinessFactory means that they share the same heritage.