I built a struct named Fraction, with three properties: double Value, int Numerator and int Denominator. In my data source I use the Fraction as a property, Fraction Position.
The data is bound like this:
<TextBox Text="{Binding Path=Position.Numerator}"/>
<TextBox Text="{Binding Path=Position.Denominator}"/>
but the binding happens to work only one way - from source to target. I tried to catch the SourceUpdated event, but it didn't work.
Is there a way to force two-way binding? I tried Mode=TwoWay, but it didn't work either.
You may have to create Position as a dependency property so that when target updates source updates too
Edit
please check it should be something like
public static readonly DependencyProperty PositionProperty = DependencyProperty.Register("Position", typeof(Fraction), typeof(NoteUserControl),new UIPropertyMetadata(new Fraction()));
public Fraction Position
{
get { return (Fraction)GetValue(PositionProperty ); }
set
{
SetValue(PositionProperty, value);
}
}
Hope NoteUserControl is the Class in which you have defined the dependency property
Related
This might be more of a Java question, but how would you access values (say from a textfield) of a given view/class from a different class? For example if there was a TextField t1 that is in the MainView, and I wanted to get its current value for a computation in a different class. And is there a more Vaadin-specific approach here?
That can depend on the use case specifically. Since you mentioned a TextField value I assume the value is not yet stored in the DB, it's just on the UI yet -> I rule out singleton spring services.
A few ideas:
If the MainView and the different class are nested components and it's viable and not really complicated across a lot of classes... then probably passing it down the way when creating the sub-component. This is a naive solution - it can get pretty messy.
MainView() {
var t1 = new TextField();
var d = new Different(t1);
}
Fire and listen to Vaadin Component events. If you want really loose coupling, the most universal would be to use the UI instance as the event bus.
// listen in different class
ComponentUtil.addListener(attachEvent.getUI(), CloseMenuEvent.class, e -> closeMenu());
// fire change in MainView
ComponentUtil.fireEvent(ui, new CloseMenuEvent(ui))
A more specific version of number 2. is to pass the ValueChangeListener of the MainView's t1 to the different class.
MainView() {
var t1 = new TextField();
var d = new DifferentClass();
t1.addValueChangeListener(d::t1Changed)
add(t1, d);
}
Extract the common field to a third party, to a third class. Use a #UIScoped spring bean (#SpringComponent, #Service, ...) that will hold that field, and inject it to both MainView and the different class.
#Route
public class MainView extends VerticalLayout {
public MainView(Model m, Different d) {
add(m.t1, d);
}
}
#Scope(SCOPE_PROTOTYPE)
public class Different extends Component {
public Different(Model m) {
// something with m.t1
}
}
#UIScoped
public class Model {
public final TextField t1 = new TextField(); // TODO use getter
}
You could change the 4th approach by keeping String in Model and having a value change listener that updates it.
What's the main difference between property observers and property wrappers? They seem to be very similar in that they manage how the properties are stored. The only thing I can think of is that you can reuse property wrappers since there is a layer of separation between code that manages how a property is stored and the code that defines a property.
Property Wrapper
#propertyWrapper
struct TwelveOrLess {
private var number: Int
init() { self.number = 0 }
var wrappedValue: Int {
get { return number }
set { number = min(newValue, 12) }
}
}
struct Rectangle {
#TwelveOrLess var height: Int
#TwelveOrLess var width: Int
}
Property Observer
struct Rectangle {
var height: Int {
didSet {
if oldValue > 12 {
height = 12
} else {
height = oldValue
}
}
}
var width: Int {
didSet {
if oldValue > 12 {
width = 12
} else {
width = oldValue
}
}
}
}
The two cases above accomplish pretty much the same thing, which is to set the properties to be equal to or less than 12.
You say:
The only thing I can think of is that you can reuse property wrappers since there is a layer of separation between code that manages how a property is stored and the code that defines a property.
Your example (and some of your text) appears to be lifted from the Swift Programming Language: Property Wrapper manual:
A property wrapper adds a layer of separation between code that manages how a property is stored and the code that defines a property. For example, if you have properties that provide thread-safety checks or store their underlying data in a database, you have to write that code on every property. When you use a property wrapper, you write the management code once when you define the wrapper, and then reuse that management code by applying it to multiple properties.
So, yes, the virtue of the property wrapper is the reuse achieved by separating the “code that manages how a property is stored and the code that defines a property.” This resulting reuse is the whole m.o. of property wrappers.
You clearly, you can write your own setters and getters (which is better, IMHO, than a pattern of writing an observer that mutates itself), too, but you lose the reuse and abstraction that the property wrappers offer.
You go on to say:
The two cases above accomplish pretty much the same thing, which is to set the properties to be equal to or less than 12.
Sure, but if you want to do this for ten different properties, the wrapper avoids you from needing to repeat this code ten times. It also abstracts the details of this “equal to or less than 12” logic away from where you declare the property.
Another big difference betwixt property observers and property wrappers is that property observers can access self, whilst property wrappers cannot yet (as of this writing) access self using a stable, documented interface.
You can work around this limitation by manually passing self to the property wrapper in init. This workaround is described in the property wrapper proposal.
You can access self in a property wrapper using an undocumented, unstable interface which you can learn about by typing “property wrapper _enclosingInstance” into your favorite search engine.
Is there way to late initialize for final variables. The problem is many values initialized with entry point to the class, which is not constructor. Hence they cannot be final right now. But in scope of particular class they will not be changed. For ex.
Controller controller;
double width;
void setup(final itemWidth) {
controller = MyController();
width = itemWidth;
}
Could it be possible? Right now I see only solution as a annotation. You might think it's for visual effect. But in fact it helps to avoid unpredictable flow during testing.
It is now possible to late initialize variables. For more information see Dart's documentation. The text below is copied from Dart's documentation:
Late final variables
You can also combine late with final:
// Using null safety:
class Coffee {
late final String _temperature;
void heat() { _temperature = 'hot'; }
void chill() { _temperature = 'iced'; }
String serve() => _temperature + ' coffee';
}
Unlike normal final fields, you do not have to initialize the field in its declaration or in the constructor initialization list. You can assign to it later at runtime. But you can only assign to it once, and that fact is checked at runtime. If you try to assign to it more than once — like calling both heat() and chill() here — the second assignment throws an exception. This is a great way to model state that gets initialized eventually and is immutable afterwards.
Just did a standard job interview is to calculate the volume of water in the histogram. On Monday this code worked, and still works on this site. After updating vala, an error is now displayed.
UPD: more easy example
> Algoritm.vala:2.5-2.16: error: struct `Algotitm.first' cannot be empty
> struct first {
> ^^^^^^^^^^^^ Algoritm.vala:6.5-6.17: error: struct `Algotitm.second' cannot be empty
> struct second {
When posting a question on Stack Overflow it is always good to post an example of the code that is a minimum, complete and verifiable example.
From the link you've provided it appears you have a struct with only members marked as static:
struct First {
static int data;
static int pos;
}
void main () {
}
Marking the fields as static means they aren't instance fields and so the struct is empty of fields. That's why you are getting the error message about the struct being empty. I'm not sure Vala should even allow marking struct fields as static, but it does make sense to allow methods in structs to be static.
You need to remove the static modifiers. This will work:
struct First {
int data;
int pos;
}
void main () {
}
Update
I'm guessing you are trying to write performance optimized code and you think static helps with that. static in Vala means there is no instance data to use. If you are using a data structure like a class or struct then it only makes sense to have instances of those. If you want something to remain unchanged during the running of your program use const in a namespace.
Using a struct may give you a slight performance boost if your are using a very large number in your program. structs created in Vala are allocated on the stack instead of the heap so may be slightly faster. If you are passing structs around you may want to consider [SimpleType] attribute. That means structs will be passed by value in C as well as Vala. Without the [SimpleType] they are copied and passed by reference at the C level, which appears as copy by value in Vala.
Structs in Vala can have initializers (similar to a constructor for a class) and methods. So what I can extract from your second pastebin you could write that as:
struct First {
int data;
int pos;
public First (int[] mass) {
data= 5;
pos = mass.length;
}
public int sas () {
return data + pos;
}
}
void main () {
int[] a = {1,3,0,1,2,3,2,1};
var b = First (a);
print (#"$(b.sas ())\n");
}
That is a follow on question though and should be asked as a second question on Stack Overflow. This is a public forum that follows a format that allows other people to learn from the question and answers.
I'm using Web UI to do observable data binding. Here is the brief snippet of code I'm working with:
import 'dart:html';
import 'dart:json';
import 'package:web_ui/web_ui.dart';
import 'package:admin_front_end/admin_front_end.dart';
//var properties = toObservable(new List<Property>()..add(new Property(1, new Address('','','','','',''))));
var properties = toObservable(new List<Property>());
void main() {
HttpRequest.request('http://localhost:26780/api/properties', requestHeaders: {'Accept' : 'application/json'})
.then((HttpRequest req){
final jsonObjects = parse(req.responseText);
for(final obj in jsonObjects){
properties.add(new Property.fromJsonObject(obj));
}
});
}
In index.html, I bind properties to it's respective property in the template:
<div is="x-property-table" id="property_table" properties="{{properties}}"></div>
In the first snippet of code, I'm populating the observable properties list, but it never reflects in the UI (I've stepped through the code and made sure elements were in-fact being added). If I pre-populate the list (see the commented out line), it does display, so the binding is at least working properly. Am I doing something wrong here?
The problem is most likely that you don't have any variables or types marked as #observable. In lack of observables, Web UI relies on call to watchers.dispatch() in order to update GUI.
You have following options:
1) import watchers library and call dispatch() explicitly:
import 'package:web_ui/watcher.dart' as watchers;
...
void main() {
HttpRequest.request(...)
.then((HttpRequest req){
for(...) { properties.add(new Property.fromJsonObject(obj)); }
watchers.dispatch(); // <-- update observers
});
}
2) mark any field of your x-property-table component as observable, or just the component type, e.g.:
#observable // <-- this alone should be enough
class PropertyTable extends WebComponent {
// as an alternative, mark property list (or any other field) as observable.
#observable
var properties = ...;
NOTE:
when a collection is marked #observable, UI elements bound to the collection are updated only when the collection object itself is changed (item added, removed, reordered), not when its contents are changed (e.g. an object in the list has some property modified). However, as your original properties list is an ObservableList, #observable annotation only serves here as a way to turn on the observable mechanism. Changes to the list are queued as a part of ObservableList implementation.
I think solution 2 (#observable) is better. As far as I know, watchers is the old way to track changes and will probably be removed.