Suppose I am binding using
bs.Bind(y)
.For(v => v.Visibility)
.To("Failures['TaxPercent'].Length")
.WithConversion("Visibility")
.WithFallback(false);
Where Failures is a dictionary which would contain the property name (e.g. TaxPercent) if, and only if, the property fails validation.
Therefore Failure['TaxPercent'] returns the validation failure message (e.g value missing).
I want to have an expandable textview in Android which is visible only when the error is detected. I used the above code and it is not working. The fallback value does not trigger when Failure['TaxPercent'] does not exist in the dictionary.
How do I get an expandable/collapsible textview based on the validation result using a dictionary in the viewmodel??? I would really like to use a dictionary because that would save me from creating IsErrorVisible for each property.
Oddly enough, using a dictionary works for retrieving the error message though, but not for visibility! In other words, this is working great
bs.Bind(y)
.For(v => v.Text)
.To("Failures['TaxPercent']");
Also, any reason why I cannot concatenate the binding, meaning can I do this???
bs.Bind(y)
.For(v => v.Text)
.To("Failures['TaxPercent']")
.For(v => v.Visibility)
.To("Failures['TaxPercent'].Length")
.WithConversion("Visibility")
.WithFallback(false);
EDIT
The error msg in the log is
MvxBind:Error:168.86 Problem seen during binding execution for binding Visibility for Failures['TaxPercent'].Length - problem ArgumentException: The value passed in must be an enum base or an underlying type for an enum, such as an Int32.
If the dictionary doesn't contain an entry for 'TaxPercent' then the expression Failures['TaxPercent'].Length will not evaluate (an exception will be throw) so UnsetValue will be used.
In the case of UnsetValue, the ValueConverter will not be called, and the Fallback will be used. This is the same pattern as in Wpf - http://msdn.microsoft.com/en-us/library/system.windows.dependencyproperty.unsetvalue(v=vs.110).aspx
For your particular situation, it looks like you could either:
change the Fallback to the correct value for the platform instead of to a boolean value (the question didn't specify which platform(s) you are using)
create a new Visibility ValueConverter that takes Failures as its binding source and 'TaxPercent' as its parameter
remove the .Length from your binding expression - just test on the existence of the entry.
you could switch to free text binding expressions - then you could do more complicated binding statements, including nested bindings, multiple value converters, multiple fallback values, ...
For this particular case, I would just drop the .Length
For "any reason why I cannot concatenate", that won't work as the return type of Bind is a single Fluent binding entry - not a Fluent binding set.
Related
Derived from Canonical question for TypeError Cannot [call method / read property / set property] of null in Google Apps Script
Proposed reference for questions like :
Why the Execution order of GS files in a Project causes TypeError: Cannot read property "sayName" from undefined.?
Testing a trigger causes ReferenceError: 'e' is not defined. or TypeError: Cannot read property *...* from undefined
TypeError: Cannot read property "0" from undefined
Google Script send form values by email, error: cannot read property "namedValues"
Not enough details from the OP but three different answers that for different scenarios
TypeError: Cannot call method "getName" of undefined
TypeError: Cannot read property 'value' of undefined (line 3, file "Code"). I have a trigger for on form submit and yet it still has an errorMissing character in property name (OP used value instead of values)
Description
The error message indicates that you are trying to access a property on an Object instance, but during runtime the value actually held by a variable is a special data type undefined.
See key terms definition at the bottom.
Causes:
The error occurs when accessing properties of an object, which does not exist.
If a property doesn't exist in a object, accessing that property results in undefined and eventually a type error, if undefined is accessed like a real object.. This maybe due to typos or using case insensitive names to access a property. A variation of this error with a numeric value in place of property name indicates that an instance of Array was expected. As arrays in JavaScript are objects, everything mentioned here is true about them as well.
const obj = {a:1};
const b = obj.b;//undefined because b isn't available on obj. But doesn't throw a error
console.log(b.toString())//Throws type error
Accessing Arrays index greater than the last element's index
Array.prototype.length returns the number of elements of the Array. This number is always greater than the last element's index, as JavaScript uses 0 based indices. Accessing any index greater than or equal to the length of the array results in this type error. Eg, when accessing 3rd element in a array of length 3,
const a = [[1],[2],[3]];
const getElement3 = a[3];//undefined,because `3`'s index is ``2`` not `3`;But doesn't throw a error
console.log(getElement3[0])//Throws type error
Accessing Event objects without a event:
There is a special case of dynamically constructed objects such as event objects that are only available in specific contexts like making an HTTP request to the app or invoking a function via time or event-based trigger.
The error is a TypeError because an "object" is expected, but "undefined" is received
How to fix
Using default values
Nullish Coalescing operator ?? operator in JavaScript evaluates the right-hand side if the left-hand is null or undefined. An expression like (myVar ?? {}).myProp (or (myVar ?? [])[index] for arrays) will guarantee that no error is thrown, if the property is at least undefined.
One can also provide default values: (myVar ?? { myProp : 2 }) guarantees accessing myProp to return 2 by default. Same goes for arrays: (myVar ?? [1,2,3]).
Checking for type
Especially true for the special case, typeof operator combined with an if statement and a comparison operator will either allow a function to run outside of its designated context (i.e. for debugging purposes) or introduce branching logic depending on whether the object is present or not.
One can control how strict the check should be:
lax ("not undefined"): if(typeof myVar !== "undefined") { //do something; }
strict ("proper objects only"): if(typeof myVar === "object" && myVar) { //do stuff }
Key Terms
Object
It's one of the JavaScript data types.
undefined
It's one of the JavaScript primitive data types.
To learn about the very basics of JavaScript data types and objects see What are JavaScript Data Types? and What exactly is an object? [JavaScript].
Original revision extracted from here (Credit to #OlegValter)
Derived from Canonical question for TypeError Cannot [call method / read property / set property] of null in Google Apps Script
Proposed reference for questions like :
Why the Execution order of GS files in a Project causes TypeError: Cannot read property "sayName" from undefined.?
Testing a trigger causes ReferenceError: 'e' is not defined. or TypeError: Cannot read property *...* from undefined
TypeError: Cannot read property "0" from undefined
Google Script send form values by email, error: cannot read property "namedValues"
Not enough details from the OP but three different answers that for different scenarios
TypeError: Cannot call method "getName" of undefined
TypeError: Cannot read property 'value' of undefined (line 3, file "Code"). I have a trigger for on form submit and yet it still has an errorMissing character in property name (OP used value instead of values)
Description
The error message indicates that you are trying to access a property on an Object instance, but during runtime the value actually held by a variable is a special data type undefined.
See key terms definition at the bottom.
Causes:
The error occurs when accessing properties of an object, which does not exist.
If a property doesn't exist in a object, accessing that property results in undefined and eventually a type error, if undefined is accessed like a real object.. This maybe due to typos or using case insensitive names to access a property. A variation of this error with a numeric value in place of property name indicates that an instance of Array was expected. As arrays in JavaScript are objects, everything mentioned here is true about them as well.
const obj = {a:1};
const b = obj.b;//undefined because b isn't available on obj. But doesn't throw a error
console.log(b.toString())//Throws type error
Accessing Arrays index greater than the last element's index
Array.prototype.length returns the number of elements of the Array. This number is always greater than the last element's index, as JavaScript uses 0 based indices. Accessing any index greater than or equal to the length of the array results in this type error. Eg, when accessing 3rd element in a array of length 3,
const a = [[1],[2],[3]];
const getElement3 = a[3];//undefined,because `3`'s index is ``2`` not `3`;But doesn't throw a error
console.log(getElement3[0])//Throws type error
Accessing Event objects without a event:
There is a special case of dynamically constructed objects such as event objects that are only available in specific contexts like making an HTTP request to the app or invoking a function via time or event-based trigger.
The error is a TypeError because an "object" is expected, but "undefined" is received
How to fix
Using default values
Nullish Coalescing operator ?? operator in JavaScript evaluates the right-hand side if the left-hand is null or undefined. An expression like (myVar ?? {}).myProp (or (myVar ?? [])[index] for arrays) will guarantee that no error is thrown, if the property is at least undefined.
One can also provide default values: (myVar ?? { myProp : 2 }) guarantees accessing myProp to return 2 by default. Same goes for arrays: (myVar ?? [1,2,3]).
Checking for type
Especially true for the special case, typeof operator combined with an if statement and a comparison operator will either allow a function to run outside of its designated context (i.e. for debugging purposes) or introduce branching logic depending on whether the object is present or not.
One can control how strict the check should be:
lax ("not undefined"): if(typeof myVar !== "undefined") { //do something; }
strict ("proper objects only"): if(typeof myVar === "object" && myVar) { //do stuff }
Key Terms
Object
It's one of the JavaScript data types.
undefined
It's one of the JavaScript primitive data types.
To learn about the very basics of JavaScript data types and objects see What are JavaScript Data Types? and What exactly is an object? [JavaScript].
Original revision extracted from here (Credit to #OlegValter)
Derived from Canonical question for TypeError Cannot [call method / read property / set property] of null in Google Apps Script
Proposed reference for questions like :
Why the Execution order of GS files in a Project causes TypeError: Cannot read property "sayName" from undefined.?
Testing a trigger causes ReferenceError: 'e' is not defined. or TypeError: Cannot read property *...* from undefined
TypeError: Cannot read property "0" from undefined
Google Script send form values by email, error: cannot read property "namedValues"
Not enough details from the OP but three different answers that for different scenarios
TypeError: Cannot call method "getName" of undefined
TypeError: Cannot read property 'value' of undefined (line 3, file "Code"). I have a trigger for on form submit and yet it still has an errorMissing character in property name (OP used value instead of values)
Description
The error message indicates that you are trying to access a property on an Object instance, but during runtime the value actually held by a variable is a special data type undefined.
See key terms definition at the bottom.
Causes:
The error occurs when accessing properties of an object, which does not exist.
If a property doesn't exist in a object, accessing that property results in undefined and eventually a type error, if undefined is accessed like a real object.. This maybe due to typos or using case insensitive names to access a property. A variation of this error with a numeric value in place of property name indicates that an instance of Array was expected. As arrays in JavaScript are objects, everything mentioned here is true about them as well.
const obj = {a:1};
const b = obj.b;//undefined because b isn't available on obj. But doesn't throw a error
console.log(b.toString())//Throws type error
Accessing Arrays index greater than the last element's index
Array.prototype.length returns the number of elements of the Array. This number is always greater than the last element's index, as JavaScript uses 0 based indices. Accessing any index greater than or equal to the length of the array results in this type error. Eg, when accessing 3rd element in a array of length 3,
const a = [[1],[2],[3]];
const getElement3 = a[3];//undefined,because `3`'s index is ``2`` not `3`;But doesn't throw a error
console.log(getElement3[0])//Throws type error
Accessing Event objects without a event:
There is a special case of dynamically constructed objects such as event objects that are only available in specific contexts like making an HTTP request to the app or invoking a function via time or event-based trigger.
The error is a TypeError because an "object" is expected, but "undefined" is received
How to fix
Using default values
Nullish Coalescing operator ?? operator in JavaScript evaluates the right-hand side if the left-hand is null or undefined. An expression like (myVar ?? {}).myProp (or (myVar ?? [])[index] for arrays) will guarantee that no error is thrown, if the property is at least undefined.
One can also provide default values: (myVar ?? { myProp : 2 }) guarantees accessing myProp to return 2 by default. Same goes for arrays: (myVar ?? [1,2,3]).
Checking for type
Especially true for the special case, typeof operator combined with an if statement and a comparison operator will either allow a function to run outside of its designated context (i.e. for debugging purposes) or introduce branching logic depending on whether the object is present or not.
One can control how strict the check should be:
lax ("not undefined"): if(typeof myVar !== "undefined") { //do something; }
strict ("proper objects only"): if(typeof myVar === "object" && myVar) { //do stuff }
Key Terms
Object
It's one of the JavaScript data types.
undefined
It's one of the JavaScript primitive data types.
To learn about the very basics of JavaScript data types and objects see What are JavaScript Data Types? and What exactly is an object? [JavaScript].
Original revision extracted from here (Credit to #OlegValter)
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.
While perusing an application that I'm documenting, I've run across some examples of bang notation in accessing object properties/methods, etc. and in other places they use dot notation for what seems like the same purpose.
Is there a difference or preference to using one or the other? Some simple googling only reveals limited information on the subject with some people actually using it in opposite cases. Perhaps there is a coding standards section from MS somewhere that indicates the method of madness?
Despite the (formerly) accepted answer to this question, the bang is not in fact a member or collection access operator. It does one simple and specific thing: The bang operator provides late-bound access to the default member of an object, by passing the literal name following the bang operator as a string argument to that default member.
That's it. The object doesn't have to be a collection. It doesn't have to have a method or property called Item. All it needs is a Property Get or Function which can accept a string as the first argument.
For much more detail and proof, see my blog post discussing this: The Bang! (Exclamation Operator) in VBA
The bang operator (!) is shorthand for accessing members of a Collection or other enumerable object, such as the Fields property of an ADODB.Recordset.
For example, you can create a Collection and add a few keyed items to it:
Dim coll As Collection
Set coll = New Collection
coll.Add "First Item", "Item1"
coll.Add "Second Item", "Item2"
coll.Add "Third Item", "Item3"
You can access an item in this collection by its key in three ways:
coll.Item("Item2")
This is the most explicit form.
coll("Item2")
This works because Item is the default method of the Collection class, so you can omit it.
coll!Item2
This is short-hand for both of the above forms. At run-time, VB6 takes the text after the bang and passes it as a parameter to the Item method.
People seem to make this more complicated than it should be, which is why it's hard to find a straightforward explanation. Usually the complications or "reasons not to use the bang operator" stem from a misunderstanding of how simple it actually is. When someone has a problem with the bang operator, they tend to blame it instead of the real cause of the problem they are having, which is often more subtle.
For example, some people recommend not using the bang operator to access controls on a form. Thus, Me.txtPhone is preferred over Me!txtPhone. The "reason" this is seen as bad is that Me.txtPhone will be checked at compile-time for correctness, but Me!txtPhone won't.
In the first case, if you mistype the code as Me.txtFone and there is no control with that name, your code won't compile. In the second case, if you wrote Me!txtFone, you won't get a compile error. Instead, your code will blow up with a run-time error if it reaches the line of code that used Me!txtFone.
The problem with the argument against the bang operator is that this problem has nothing to do with the bang operator itself. It's behaving exactly the way it's supposed to.
When you add a control to a form, VB automatically adds a property to your form with the same name as the control you added. This property is part of the form's class, so the compiler can check for typos at compile-time if you access controls using the dot (".") operator (and you can access them using the dot operator precisely because VB created a named control property for you).
Since Me!ControlName is actually short-hand for Me.Controls("ControlName")1, it should not be suprising that you don't get any compile-time checks against mistyping the control name.
Put another way, if the bang operator is "bad" and the dot operator is "good", then you might think
Me.Controls("ControlName")
is better than
Me!ControlName
because the first version uses a dot, but in this case, the dot isn't any better at all, since you are still accessing the control name via a parameter. It's only "better" when there is an alternative way to write the code such that you will get compile-time checking. This happens to be the case with controls due to VB creating properties for each control for you, and this is why Me.ControlName is sometimes recommended over Me!ControlName.
I had originally stated that the Controls property was the default property of the Form class, but David pointed out in the comments that Controls isn't the default property of Form. The actual default property returns a collection that includes the contents of Me.Controls, which is why the bang short-hand still works.
Couple gotchas to serve as addenda to the two exceptional answers already posted:
Accessing recordset fields in forms vs. reports
The default item of Form objects in Access is a union of the form's Controls collection and the form recordset's Fields collection. If the name of a control conflicts with the name of a field, I'm not sure which object is actually returned. Since the default property of both a field and a control is their .Value, it's often a "distinction without a difference." In other words, one normally doesn't care which it is because the values of the field and control are often the same.
Beware of naming conflicts!
This situation is exacerbated by Access's Form and Report designer defaulting to naming bound controls the same as the recordset field to which they are bound. I've personally adopted the convention of renaming controls with their control type prefix (e.g., tbLastName for the text box bound to the LastName field).
Report recordset fields aren't there!
I said earlier the Form object's default item is a collection of Controls and Fields. However, the Report object's default item is only its collection of Controls. So if one wants to refer to a recordset field using the bang operator, one needs to include that field as the source for a (hidden, if desired) bound control.
Beware conflicts with explicit form/report properties
When one adds controls to a form or report, Access automatically creates properties that refer to these controls. For example, a control named tbLastName would be available from a form's code module by referring to Me.tbLastName. However, Access will not create such a property if it conflicts with an existing form or report property. For example, assume one adds a control named Pages. Referring to Me.Pages in the form's code module will return the form's Pages property, not the control named "Pages".
In this example, one could access the "Pages" control explicitly using Me.Controls("Pages") or implicitly using the bang operator, Me!Pages. Be aware, though, that using the bang operator means that Access might instead return a field named "Pages" if one exists in the form's recordset.
What about .Value?
Though not explicitly mentioned in the question, this topic came up in the above comments. The default property for Field objects and most "data-bindable"¹ Control objects is .Value. Since this is the default property, VBA will implicitly return the .Value property's value when it does not make sense to return the object itself. Thus, it's common practice to do this...
Dim EmployeeLastName As String
EmployeeLastName = Me.tbLastName
...instead of this...
EmployeeLastName = Me.tbLastName.Value
The above two statements produce identical results because EmployeeLastName is a string.
Beware the subtle .Value bug when keying dictionaries
There are some cases where this convention can cause subtle bugs. The most notable--and, if memory serves, only--one I've actually run into in practice is when using the value of a Field/Control as a Dictionary key.
Set EmployeePhoneNums = CreateObject("Scripting.Dictionary")
Me.tbLastName.Value = "Jones"
EmployeePhoneNums.Add Key:=Me.tbLastName, Item:="555-1234"
Me.tbLastName.Value = "Smith"
EmployeePhoneNums.Add Key:=Me.tbLastName, Item:="555-6789"
One would likely expect that the above code creates two entries in the EmployeePhoneNums dictionary. Instead, it throws an error on the last line because we are trying to add a duplicate key. That is, the tbLastName Control object itself is the key, not the value of the control. In this context, the control's value does not even matter.
In fact, I expect that the object's memory address (ObjPtr(Me.tbLastName)) is likely what's being used behind the scenes to index the dictionary. I did a quick test that seems to bear this out.
'Standard module:
Public testDict As New Scripting.Dictionary
Sub QuickTest()
Dim key As Variant
For Each key In testDict.Keys
Debug.Print ObjPtr(key), testDict.Item(key)
Next key
End Sub
'Form module:
Private Sub Form_Current()
testDict(Me.tbLastName) = Me.tbLastName.Value
Debug.Print ObjPtr(Me.tbLastName); "..."; Me.tbLastName
End Sub
When running the above code, exactly one dictionary item is added each time the form is closed and re-opened. Moving from record to record (and thus causing multiple calls to the Form_Current routine) does not add new dictionary items, because it is the Control object itself indexing the dictionary, and not the Control's value.
My personal recommendations/coding conventions
Over the years, I've adopted the following practices, YMMV:
Prefix Form/Report control names with control type indicators (e.g., tbTextBox, lblLabel, etc.)
Refer to Form/Report controls in code using Me. notation (e.g., Me.tbLastName)
Avoid creating table/query fields with problematic names in the first place
Use Me! notation when there are conflicts, such as with legacy applications (e.g., Me!Pages)
Include hidden report controls to gain access to report Recordset field values
Explicitly include .Value only when the situation warrants the added verbosity (e.g., Dictionary keys)
¹ What's a "data-bindable" control?
Basically, a control with a ControlSource property, such as a TextBox or ComboBox. A non-bindable control would be something like a Label or CommandButton. The default property of both a TextBox and ComboBox is .Value; Labels and CommandButtons have no default property.