Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Home

TFKsoftware

Project Members:


  • TFKsoftware
    TFKsoftware
    2013-08-04

    Lazarus logo TemplateApp - getting you going fairly quickly

    • Introduction
    • How to use
    • Interface
    • Centralized data handling
    • Localization
    • Tips
    • Changelog v0.9.2
    • Changelog v0.9.4

    Introduction

    I wanted to create an application with full localization support and -while developing it- discovered that all information on how to do this was spread over various forum threads and pages on the internet. Furthermore, I wanted an application that not only detects the system language but is also able to set the language via a settings window. This took quite some time to figure out. Not wanting to do that again this application became my template application. Doing so made me realize that there wasn't something like this available yet. Well, I had to gather all information so logically more developers would face this obstacle when developing multi-language applications in Lazarus. So I decided to share this template in good open source tradition. And thus 'TemplateApp' was born.

    TFK

    If you like my work, please buy me a beer (or a carbonated beverage)
    BTC: 1ETYQRoTecjJi6AAeGYf129VU4oAuYGJiF
    LTC: LWeGdQG5YFfycDojL38nnZ79woVSAQpb2Q
    FTC: 712S2uiERgVBEjjmDpJUNNuT7T1nX6WXAY

    How to use

    TemplateApp is basically a main form with all the basic controls that a common application has. I kept it intensionally simple. I did this for two reasons:

    1. The more features you don't need, the more you have to remove before you can start developing the bits that are -in your case- important. Thus undermining the goal of this template, getting you on your way as quickly as possible.
    2. I don't want to be in the way of your creativity. Remember, this application is soly a template which saves you a few days of investigation on the obvious things you don't want to lose time on.

    Interface

    The interface consists of a main form with a standard menu. It is completely multi-language. When you run the application it will default to the system language. When the system language is not supported the application defaults to English. The code behind for the main form is non existent. Everything is built using a layered design. Al non visible components are placed onto a TDataModule 'dmdCentralComponents' . Using a system like this prevents your main form unit from cluttering up with components and it's code behind with code. You can add more TDataModules to suit your needs. I added two extra elements to the main form. Just to show what is possible and to show how easy it is with a TDataModule/TActionList/TAction/EventHandler set-up to switch interface elements. Instead of the standard about box form, I used a panel and I added a side panel with some custom buttons that pop-up a menu.

    Centralized data handling

    Preferences within a common application can mount up to a staggering amount of data that needs to be handled. Having the code to handle all this data spead over the entire application can become a real pain to maintain. Especially over time. Here the TDataModule 'dmdCentralData' comes in. The code behind for this element contains all code to handle the centralized data within the application. Also the swithing between languages has a place here. I chose a TDataModule for this to be able to place non-visual components onto it. Again with the goal of having all this centralized. I can imagine that you want to store information in an a database requiring some non-visual components. This way you have them readably available without cluttering your main form.

    For maintaining all settings within the preferences dialog I use a field called FBatchSettings. Which is basically a TStringList. This was again done with simplicity in mind. The objects list within the FBatchSettings field contain TBatchSetting instances. These hold a value and an old value. The latter makes it possible to cancel changed settings and to go back to the original values.

    Localization

    This application is fully multi-language. It detects the system language and -when available- sets it on application start. The language can also be set using the settings dialog. When set, the chosen language is saved in an ini file and this value is read on application start instead of the system setting.

    The method of storing the various texts within the application is done via PO-files. This is a very open system of storing localization texts, again done with open source in mind, and allows for easy addition of support for extra languages. The file template.po is the default PO-file and contains all English texts. This file is generated a lfm file is saved. All other languages can be added or maintained from this one.

    Adding new languages involves two steps.

    1. Create a new PO-file with the filename in the following format and place it in the languages directory.

      appname.language-id.po

    2. Edit settings.ini and add under the section languages the new language in the following format.

      language-name=language-id

    The language-name is not very important, it is what's presented to the user. The language-id is important as it links the newly added language to the corresponding PO-file.

    Tips

    Some basic tips for solid multi-language and multi-platform application development.

    1. Use standard visual components where possible. These have been tested on multiple platforms and thus chances are that you application will run out of the box on different systems with different themes. This is very important when developing for Linux and becomes more and more important for Windows which also supports themes.
    2. Make sure you read the Multiplatform Programming Guide for all information on multi platform programming with Lazarus.
    3. For more information on localization read the Localization for programs page.

    Changelog v0.9.2

    • Added a safeguard for trying to load a PO-file that doesn't exist. Before the language in the settings.ini file is added to the settings window, the check is done whether the corresponding PO-file is there.

    Changelog v0.9.4

    • Had completely forgotten about the system language. The application now checks the system language when there is no user defined setting in settings.ini and checks whether there is a corresponding PO-file for the system language. In case there is one, this language is used. Otherwise the default language is used.
     
    Last edit: TFKsoftware 2013-12-03