Data Binding

[mansellan]

Is your feature request related to a problem? The data binding capabilities of VBx are limited, and by extension so are those of WinForms in .Net. The data binding capabilities of WPF are comprehensive, but also very difficult to learn. Is there a middle ground?

Describe the solution you'd like TwinBasic uses JSON as its primary serialisation format. This is a good thing, XML is way too bloated. I'd like to think that bindings could also be serialised, but that leads to complications for runtime template selection, and advanced MVVM scenarios.

Describe alternatives you've considered Perhaps there's a way to facilitate runtime bindings by third party solutions, without having to design the whole thing on day one?

[mwolfe02]

I have to believe @retailcoder has thoughts about how data binding might work in twinBASIC, based on his previous work and writing:

• MVVM in VBA!
• Making MVVM Work in VBA Part 3: Bindings

[bclothier]

I can't speak to VB6's data binding, never really used it. I can honestly say that I found WinForm's data binding system to be over-engineered, requiring too many pieces to work together. Contrast populating a result of SQL query into a combobox control on a WinForm combobox in a .NET project to the same on an Access combobox -- it's ridiculous.

My biggest gripes with WPF is that it's way too open-ended to the point that there's no obvious starting point. You're effectively given a 17 different way to do it right (for some value of "right") and 12,381 different ways to do it wrong. Mike is absolutely spot on it being a nightmare to debug. This requires multiple compilations & builds that you might be as well coding in JavaScript.

I don't know what exactly will make this "right" but for me the most important thing is that the binding should be capable of being validated at compile-time whenever possible. Look at PowerApps as an example where formulas are always going to be valid and be validated. You'd have to try really hard to write a valid expression that can't be verified at design time. In contrast, stringified code (I'm looking especially at DAO/ADO recordsets) are impossible to validate at compile-time. Access does a pretty sure at making this easy by exposing Access.AccessField whenever a recordsource is set, but it's a one-trick pony --- it only works with SQL data source where I think we need a more general framework that can work with any kind of data, not just SQL.

The other nice thing about Access' binding is that the relationship is easy to infer -- you look at the control, see a ControlSource, and you know where it's coming from. With WPF/XAML, I'm usually chasing the deep dependency graph and usually getting lost in the forest. A MVVM framework seems to be more prone to this flaw due to the double dispatch it usually requires. Therefore for it to be "BASIC", it should be easy to connect the bindee to the binder and visualize the relationship. It also needs to be easy to infer whether the relationship is dynamic (e.g. runtime code may change the property). In Access, I avoid using expressions like =Foo() in events mainly because it makes code harder to discover, read and understand. If you have an application with expressions in one place and code in other, you now have to do more work of analyzing the relationships. I want to be able to see it all in one place.

I know this is short on specifics but hopefully that gives some ideas on what to shoot for.

[YogiYang]

When is comes to data binding and db related programming I would suggest @WaynePhillipsEA to check out WinDev Express (it is free).

WinDev has the best data binding that I have seen in any development tool till date and it is also very easy to learn and use as well as it is consistent across different RDBMSs.

The easiest way is to use the technique used in VBRichClient. Just a data object and developer will do the necessary programming to access DB. Like for example - create a Connection object, create a Recordset object and then execute a query with connection object to get date in recordset object.

[vbRichClient]

In the RichClient I have designed that, based on a "non-visual" cDataSource-Class.

cDataSource acts as an abstraction-layer for 3 "internal sub-types" of DataContainers:

• a cRecordset (the 2D-multicolumn-resultsets which come in from SQL-queries)
• a cCollection in "flat-mode" (2D-container with only 2 "fixed-named" columns: "Key" and "Value")
• a cCollection in "hierarchic-mode" (e.g. as a result of parsed JSON-data, used for tree-widgets)

cDataSource (on the outside) then supports a fixed set of Methods and Events (Move-, FieldChange, etc.), no matter what type the DataContainer-Object on the inside of cDataSource currently is.

DropDown, List-, Tree- and Grid-Widgets can then implement a Public DataSource-Prop(Get/Let/Set) of type cDataSource quite conveniently (using the Event it throws internally, to re-render Widget-visualizations accordingly).

HTH

Olaf