Browse DevX
Sign up for e-mail newsletters from DevX


Localize Your .NET Windows Forms Apps : Page 5

It's a small world. For the price of a nice pair of shoes, you can get on a plane, have dinner, watch a movie, sleep a few hours, and wake up on another continent. Your software can travel even more easily. When it gets there, will it be ready to go to work?




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Automating Databinding
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, txtContactName, txtContactTitle) 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" ?> <configuration> <appSettings> <add key="AccessTypeTranslator" value="MDB" /> <add key="ServerTranslator" value=""></add> <add key="DatabaseTranslator" ( value="Northwind"></add> <add key="UIDTranslator" value="admin"></add> <add key="PWDTranslator" value=""></add> <add key="FileNameTranslator" ( value="..\Translations.MDB"></add> <add key="AccessTypeAppData" value="SQL" /> <add key="ServerAppData" value="(local)"></add> <add key="DatabaseAppData" ( value="Northwind"></add> <add key="UIDAppData" value="sa"></add> <add key="PWDAppData" value=""></add> <add key="FileNameAppData" value=""></add> </appSettings> </configuration>

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 table.

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.

Les Pinter is a Visual Basic MVP specializing in database application development, software localization, and migration of applications to .NET. His latest book, VFP to VB .NET (Sams), came out in May, and will be published in Spanish in January by McGraw-Hill Interamericana in Mexico City. Les is a member of the INETA Speakers Bureau, and gives talks on .NET in English, French, Spanish, Russian, and Portuguese. He lives with his Taiwanese wife Ying-Ying in San Mateo, California.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date