One of the truly irritating features of .NET is the extra steps that you have to go through to get controls to display data bound to them. In virtually all of the exercises in the VS .NET help, you create a Typed Dataset, and then fill in the Text
element of the DataBindings
property with dsName.ColName
. That's okay, but it's not so great if you're trying to build generic mechanisms. And since the typed dataset for the twelve-column Customers
table is nearly a thousand lines of code (albeit automatically generated), it just feels like a bridge too far. You don't need a typed dataset to use databinding, as you'll see.
In Listing 5
, I've included the code for the Customers form that automatically binds the data. It assumes that bindable controls are named with a three-character prefix followed by the name of a column in a table in the dataset (e.g. txtCompanyName
). This is a simple example, but it shows what you can do with a little generic code. You can put this into your base inheritable forms and never worry about databinding again, provided you're willing to use the required naming convention.
The names of the three textboxes (txtCompanyName
) are all that the BaseForm.vb
inheritable form class code needs to automatically bind the three textboxes to their respective data columns in the data source, which is ds.tables(0)
. You don't even need a typed DataSet. I added Next and Previous buttons so you can move around in the dataset.
The Forms Translation System in Action
I'll now show you how to build an application that demonstrates how this works. First, I'll create a Main
module to set up the data access components for the translation system as well as for the application's data. Then I'll launch the main form with the application's menu on it.
The MainModule module (see Listing 6
), is the startup object for the TranslationDemo project, which is the startup project for the solution. It creates two DAC components, one for translations and one for user data.
Instead of setting the components' properties in the Properties Sheet, I used the MainModule code to read the values from App.config:
<?xml version="1.0" encoding="utf-8" ?>
<add key="AccessTypeTranslator" value="MDB" />
<add key="ServerTranslator" value=""></add>
<add key="DatabaseTranslator" (
<add key="UIDTranslator" value="admin"></add>
<add key="PWDTranslator" value=""></add>
<add key="FileNameTranslator" (
<add key="AccessTypeAppData" value="SQL" />
<add key="ServerAppData" value="(local)"></add>
<add key="DatabaseAppData" (
<add key="UIDAppData" value="sa"></add>
<add key="PWDAppData" value=""></add>
<add key="FileNameAppData" value=""></add>
When I launch the application, MainModule loads the property values for the two DAC instances (one for the translations, one for the application's data), then launches MainForm. MainForm immediately calls the StoreCaptions
method of the FormPreparer component to store the captions that it finds on the form into the Original
table, if they aren't there already (see the InsertWord
method in Listing 2
). In this case, the only captions on MainForm are the form title and the label beside the cmbLanguagePicker
control. If I select "Translations" from the menu, it brings up the Translation Table Manager, where I can enter translations for these captions into Spanish and French, the two languages I previously loaded into the Languages
When I launch the Customers form, the captions for the three labels on the form are loaded into the Original
table. I can close the form, open the Translation Table Manager, and translate them. The next time I open the Customers form, I can select Spanish, and my translations will be used. Figure 7
shows the Customers form when initially loaded. In Figure 8
, I've selected Spanish, and the screen captions instantly change to Spanish.
|Figure 8: The Customers Form with Spanish Selected as the Language. Note the Controls and the Menus.|
For a little thrill, add the Russian keyboard using Control Panel, Regional and Language Settings, then enter Russian translations for these strings. If you don't know Russian, just make something up; it'll look right to you. It took me about 30 seconds to add Russian translations for these strings, open the form again, select the latest language, and see the captions change to Russian.
Allowing users to maintain their own translations of their screens solves some serious maintenance headaches, and uses available talent. You can use a local MDB or a set of FoxPro tables for the translation subsystem, or integrate it with your SQL databases. Either way, it's a powerful tool to add to your toolkit, and will open up new worlds for your software.