How to add scope to binding expressions in Delphi Live Bindings? - delphi

I know how to use live bindings on a form to bind one property to another property using an expression. For instance, binding a TLabel's Caption to a TEdit's text property.
I know how to create new expressions using IScope, TNestedScope, TDictionaryScope, etc. I can add my own classes and call them as scripted expressions.
What I don't know is how to take my new expression scope and make it available to the TBindExpressions in my TBindingList for use on a form when I'm doing things described in the first paragraph.
Anyone know how to do this? I've investigated, and I can't find a way to add an IScope reference to the binding expressions available to TBindingList and its sub-components.

Related

Instantiating a class by String name in Dart

I am trying to call a method of a class that I only know by name as a String. Now therefore I would need a ClassMirror of that class that allowes me to instantiate an instance. However, creating ClassMirrors seems to be only possible by entering a type using reflectClass(Type) or by passing an already existing instance of that class into reflect(dynamic). So these aren`t helping if I only have a String.
In Java you can do this pretty easily, by calling Class.forName(String). Then you would get a Constructor instance, make it accessibly and call it.
Does anyone know if this is even possible in dart? What seems weird is that once you have a ClassMirror you can access fields and methods by passing symbols, which can be created by Strings.
You can put a specific list of strings to map to a specific list of closures to create a new object with specific parameters.
But you can't get a reflection without using dart:mirrors, which is being deprecated, and also had a negative impact on tree shaking to get the payload size down.
In general, you're invited to look at the package:reflectable to achieve most of what you'd want out of dart:mirrors, using source-to-source builders.

Binding imperatively

Is there a way to set up bindings imperatively. An example use case:
var el2 = new MyElement();
el2.myProp = this.$.anotherElement.anotherProp
That won't setup a binding, it just assigns the value or object. I'd like to find a way to do something like:
el2.myProp.bindTo(this.$.anotherElement.anotherProp)
Possible?
Polymer 1.0 does not support this at the moment - as explained by #kevinpschaaf in Github https://github.com/Polymer/polymer/issues/1778.
(comment by #kevinpschaaf)
No, we don't currently support this, outside of dom-bind, which is the
only template implementation that late-binds instance children. You
can document.createElement('template', 'dom-bind'), then you can
dynamically append children with binding annotations to its content,
and the bindings will only be evaluated once the dom-bind is attached
to the document. See tests here that show this usage of it:
https://github.com/Polymer/polymer/blob/master/test/unit/dom-bind.html#L95
Note that dom-bind does not currently allow binding to outer scope, so
it has limited use in custom element templates (it's main use case is
for binding between elements in the main document), and that's not
likely to change short-term.
We are achieving a lot of performance optimization by baking the
binding connections into the prototype at registration time for an
element (rather than at instance time), and we haven't built up enough
of the machinery to easily allow runtime addition/removal of bindings.

How autocomplete in delphi?

I am using Delphi 7, when I write code in the unit, I want autocomplete the words of the tree's objects.
For example, I have the next objets: LabelName, LabelEdge, LabelWindow, I want start write LabelN and have the possibility of autocomplete to LabelName.
Is it possible?
As David Heffernan said in the comments you need to press the CTRL+Space key in order for code insight to provide you with available choices for auto-completion.
The available choices then depend on the part of the component name, method name, variable name, or constant name you have already written.
They also depend on your current code scope which means that code insight won't provide you choice to use some method, variable or constant if it can't be accessed from the method you are writing code in (local variables/constants that belong to other methods, private members of a different class, etc.)
You can invoke code insight to provide you choices even when you haven't written any partial name. In this case code insight will show you all available methods, variables, constants and objects (both components and classes) that can be accessed from within the current code scope. This is most useful when you are searching for specific method but you can't remember its name.

Using element to element binding in Silverlight 3?

I don't really see the need for element to element binding in Silverlight 3 if using MVVM. Won't having one property directly affect another proper cause that property to be untestable?
To me, it makes more sense to do a two way binding to a explicit property defined in the ViewModel.
I agree that the use of MVVM severely deflates the usefulness of element to element binding.
Still, if all you are doing is binding two elements using a ViewModel property... what can you test? You can test that setting a property in the ViewModel sends a PropertyChanged event... but thats about it. Only when something else cares about that value is it useful to test a property like that.
In the simple cases, I can see element2element binding being more efficient and less code.

Regarding F# Object Oriented Programming

There's this dichotomy in the way we can create classes in f# which really bothers me. I can create classes using either an implicit format or an explicit one. But some of the features that I want are only available for use with the implicit format and some are only available for use with the explicit format.
For example:
I can't use let inline* (or let alone) inside an explicitly defined class.
The only way (that I know) to define immutable public fields (not properties*) inside an implicitly defined class is the val bla : bla syntax.
But there's a redundancy here. Since I'll end up with two copy of the same immutable data, one private, one public (because in the implicit mode the constructor parameters persist throughout the class existence)
(Not so relevant) The need to use attributes for method overloading and for field's defaults is rather off putting.
Is there anyway I can work around this?
*For performance reasons
EDIT: Turns out I'm wrong about both points (Thanks Ganesh Sittampalam & MichaelGG).
While I can't use let inline in both implicit & explicit class definition, I can use member inline just fine, which I assume does the same thing.
Apparently with the latest F# there's no longer any redundancy since any parameters not used in the class body are local to the constructor.
Will be gone in the next F# release.
This might not help, but you can make members inline. "member inline private" works fine.
For let inline, you can work around by moving it outside the class and explicitly passing any values you need from inside the scope of the class when calling it. Since it'll be inlined, there'll be no performance penalty for doing this.

Resources