I had a question recently from someone, and it seemed a common enough requirement that I thought the solution might be worth sharing.
Let’s say you’ve got a database that has an Integer column which is really used as a Boolean. Zero for False, One for True. Further, for whatever reason, you can’t change the DB structure. How do you display this column to the end user as a boolean, so that they can use a Checkbox column in a grid, a TSwitch control, or similar to edit it? Read On…
CodeRage 7 is on next week and I’ll be doing a session introducing MVVM and how to implement it in Delphi. If you’re not aware of MVVM, it’s a Presentation Pattern, a way to structure your applications so that you maximize the amount of code in your app that can be unit tested (including your form logic) while at the same time, simplifying the task of swapping out different UI’s in front of your app (eg. to have different forms for different platforms or devices). It leverages Data Binding, in my case, LiveBindings in XE3.
I have a series of deeper dive articles planned on different areas of MVVM in Delphi, and this session will serve as the starting point.
Session details are here.
In the last post I looked at formatting the data we’re binding to our UI. This post is related, but it might take a little while to see how.
Back when I wrote about TAdapterBindSource, one of the adapters I used was a TDataGeneratorAdapter. This combination was useful to give me both a) design-time fields from which to visually bind in the LiveBindings Designer and b) design-time data in those fields to help layout my UI more easily. Read On…
I want to dig a little into the formatting support in LiveBindings. How can we control how our data is displayed when we bind it to UI elements?
If we go back to the traditional data binding support in VCL, different TField descendants exposed different formatting properties. For example, TNumericField exposes a DisplayFormat property where you can specify a format string to be used when displaying the contents. TField also exposes an OnGetText event where you can do whatever you like to the value before it is displayed in the UI. Read On…
Where I left off in my last post, we were able to bind our UI elements to an object, or indeed a collection of objects, by using the TAdapterBindSource combined with a TObjectBindSourceAdapter<T> or a TListBindSourceAdapter<T>.
Over a few posts I want to drill a bit deeper into what happens when you make changes to those objects, specifically in this post, when you make changes via the bound controls. I’ll explore the notification system that LiveBindings uses in later posts. Read On…
RAD Studio XE3 brought significant enhancements to LiveBindings. The LiveBindings Designer is the most obvious of these, but there have also been a lot of additions made in the process of enabling the designer, some of which I’m going to explore over the next few posts.
First up are BindSources. If you did any work with LiveBindings in XE2, you would have used BindScopes. BindScopes were the way that you exposed different sources of data to the binding engine. TBindScopeDB, for example, let you connect to a TDataSource, and then bind the exposed fields to controls using LiveBindings. Read On…