I have a custom widget which I'm using in a QWizard. It has a property called path, which can be a Path object (from pathlib), or None. I implemented this as a plain python property, but I need to change it to a pyqtProperty so I can use it as a field in the wizard.
Is it possible to overload the property so that it can work with None as well as Path?
Related
I want a function onAnyChange() be called whenever any property of an object is changed. Ways to do this would be
Define a setter for each property and call onAnyChange() in each
Define one function that takes a property name as argument, sets the property via reflection and calls onAnyChange(). Use only this function to change properties.
Is there a more convenient way to do this?
Seems to be possible e.g. in JavaScript: How do I invoke a function whenever a property of an object is read?
I would like to map a placeholder in a SCADA widget to a custom property that I put in my device via UpdateManagedObject. I can see the property using the API but it doesn't appear along native properties when I configure the widget.
This is possible, although this feature to add non-native properties from managed objects was implemented in version 7.27.0.
In the skeleton-nav app.html, the nav-bar is imported like a custom element using the require statement and can by used like a custom element using tags , but according to the docs you also need to define it by importing customelement or by using CustomElement convention. However, the nav-bar.js does not use customelement or the convention but you can still use it as a custom tag in your html. What is the difference between the nav-bar template and one defined using the customelement syntax. By using require on any template does this mean that it is automatically a custom element, is this another convention?
I believe that the documentation is simply not up to date. Because in previous version i indeed needed to use the convention but as you said it is not necessary anymore. Just a camelcase name should be enough fir any custom element. But you still need the convention for the custom attribute I believe.
I have a TextBlock and its Text property is bound to a ViewModel property. The binding is Oneway.
When I change the Text property of the Control from the xaml.cs the binding gets broken. If the binding is TwoWay I don't have this problem but the source property is updated too. Is it possible to have OneWay binding and change the target property value without braking the binding?
I suggest a workaround, like setting the Binding to TwoWay and ignore the update in the property. Something like this:
private string textValue;
public string TextValue
{
get { return textValue; }
set
{
:
}
}
Now the Property can no longer be set by the view.
Although no code is provided, this scenario typically occurs when you have bound a control to a view model and at a later stage your logic tries to update the value in the control programmatically.
You should not try to do this, that is define multiple sources of the value for a control. If you bind the control to a property on the view model, then to update the value in the control you should update the field in the view model.
If you were to set the value of a bound control programmatically at runtime so that it no longer matched the bound object value, when some other event causes the control binding to be re-evaluated, the value that you have provided programmatically would be overwritten again, you could easily end up with a scenario where the value you provided programmatically is never visible to the user.
In this scenario you should either:
Add a new property to the view model, bind this value to the control, then your program logic can set this value equal to the original property when the data is loaded, and updated when you need to
Not use bindings at all, always write to the control programatically that way you tightly control when the value is updated.
There is a workaround to this if you absolutely must have one. if you are using compiled bindings (x:Bind), then because the bindings are compiled it is possible to call SetValue on the bound dependency property at runtime and the previously compiled bindings will still be evaluated. However I advise against exploiting this because it makes your code a lot harder to follow and debug, when bindings are used, we tend not to look for code that directly addresses and sets control values.
A Java class has properties and methods for manipulating those properties. An ExtJS class has properties, methods and configOptions.
Conceptually, what is the difference between configOptions and properties? Why we need both?
As per my understanding…
configs - are passed in the constructor, which defines behavior of the class, configs should not be changed at run-time because it will not have any effect, suppose you need to specify a title for the panel then you can add a config e.g. { title : 'some title' } that will be used by panel to set title of the panel at render time, but after that, even if you try to change title, you can't alter the property by simply changing that config option.
properties - are used to store information which is useful for that class, this is normally not passed through constructor but should have getter and setter methods, you can change property at run-time (if setter method is defined) and class object should detect this change, there can be read only properties also which are modified by class object only we shouldn't change it all.
More Info
Sencha: Properties vs Configs, in the Ext 4 Documentation
My answer to this question is a little simplistic and idealistic. I'm afraid trying to give a full answer that covers all the subtleties is more likely to add to the confusion rather than clarifying the situation.
Config options are used to configure an object when it is created. Trying to set them as properties on the object after it has been instantiated will often have no effect.
Ext.create('Ext.panel.Panel', {
// config options go here
});
An object will have lots of properties but only the ones listed in the Properties section should be considered public properties. While there's nothing to stop you accessing the private properties you should only do it as a last resort, try to use the documented methods to manipulate them instead where possible.
// rendered is a public property used to indicate whether the panel has been rendered
if (panel.rendered) {
// could just do panel.el but that isn't a public property, so use getEl instead
var el = panel.getEl();
...
}
One reason why the lines get blurred is that objects generally copy their configs onto themselves like this:
Ext.apply(this, config);
This results in all the config options becoming private properties, at least initially. Internally classes can then manipulate those properties as appropriate but externally accessing those properties is a breach of encapsulation and should be avoided.