https://wiki.openpetra.org/api.php?action=feedcontributions&user=Joejoe2010&feedformat=atomOpenPetra Wiki - User contributions [en-gb]2024-03-29T14:26:30ZUser contributionsMediaWiki 1.39.6https://wiki.openpetra.org/index.php?title=Programming_hints&diff=3516Programming hints2013-05-29T19:39:12Z<p>Joejoe2010: </p>
<hr />
<div>== C# ==<br />
=== Regex ===<br />
If you want to use Regex-Expressions you can use [[http://odwn.brinkster.net/regex.aspx this tool]] to test them.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Programming_hints&diff=3515Programming hints2013-05-29T19:38:31Z<p>Joejoe2010: Created page with '== C# == === Regex === If you want to use Regex-Expressions you can use [this http://odwn.brinkster.net/regex.aspx] tool to test them.'</p>
<hr />
<div>== C# ==<br />
=== Regex ===<br />
If you want to use Regex-Expressions you can use [this http://odwn.brinkster.net/regex.aspx] tool to test them.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Developers&diff=3514Documentation for Developers2013-05-29T19:37:33Z<p>Joejoe2010: /* Tips and Tricks */</p>
<hr />
<div>== Projects ==<br />
Please read about what needs to be done, and how to take charge of a project here:<br/><br />
[[Summary of Projects]]<br />
<br />
<br />
==Development==<br />
=== Development Environment ===<br />
* [[Setup of Development environment]]<br />
* [[OpenPetra Developer's Assistant]]<br />
<br />
=== Programming ===<br />
* [[Coding Standard and Guidelines]]<br />
* [[Explanation of Directory Structure and Rules]]<br />
* [[Useful hints regarding coding in CSharp/.net]]<br />
* [[Development with Code Generation]]<br />
* [[Build system with our own NAnt tools and tasks]]<br />
* [[Preventing/getting around circular dependency problems]]<br />
<br />
=== Development Cycle ===<br />
* [[Build System for OpenPetra]]<br />
* [[Releases and Patching]]<br />
* [[Building and maintaining customized versions of OpenPetra]]<br />
* [[Migrating data from legacy systems]]<br />
* [[Working with NUnit tests]]<br />
<br />
=== Getting Started ===<br />
* [[HowTo develop a new screen]]<br />
* [[HowTo port a screen from Old Petra]]<br />
* [[HowTo develop a new report]]<br />
* [[Report Designer]]<br />
<br />
=== Tools Used ===<br />
This is a list of software that we use; some of it you will already have installed when you did your [[Setup of Development environment]].<br />
* [[Software tools for Developers]]<br />
* [[Memory profiling]]<br />
<br />
=== Tips and Tricks ===<br />
* [[Quicker development/debugging/testing turnaround with customised PetraClient startup]]<br />
* [[Specifying custom settings in Config Files for Development]]<br />
* [[Literature]]<br />
* [[Programming hints]]<br />
* [[Retrieving the 'SiteKey' of an OpenPetra installation]]<br />
* [[Homepage]]<br />
<br />
== OpenPetra Software Architecture ==<br />
* [[Overview openPETRA architecture]] <br />
** Taken from the old Petra wiki. Should be merged with the other articles!<br />
* [[n-tier architecture]]<br />
* [[Database access architecture]]<br />
* [[openPETRA Architecture Team]]<br />
<br />
=== Client Side ===<br />
* [[GUI development]]<br />
* [[Printing]]<br />
* [[Main Menu]]<br />
* [[Singleton (single-instance) Screens]]<br />
* Specific Screens<br />
** [[Exchange Rates (Design and Test)]]<br />
<br />
== Bug Tracking ==<br />
See [[Contributing_Source_Code_to_OpenPetra.org#Tracking_of_Bugs_and_Things_to_do|Tracking of Bugs]]<br />
<br />
<br />
== Database Structure Documentation ==<br />
We have DB model documentation online available in two formats, both of which are auto-generated with each release:<br />
* [http://openpetraorg.sourceforge.net/dbdoc/index.html Our own format] (see also [[SQL Diagram creation]])<br />
** There is a [http://openpetraorg.sourceforge.net/dbdoc/img/img_AccountsPayable.html?a_ap_document diagram for the Accounts Payable sub system]<br />
*** We need volunteers do design more diagrams! Please also have a look at the old 2.1 diagrams ([http://openpetraorg.sourceforge.net/Petra21DBDiagrams.zip download 9 png files in a zip file]).<br />
* [http://openpetraorg.sourceforge.net/schemaSpy/index.html SchemaSpy format]<br />
** features quite nice automatically drawn relationship diagrams once you select a certain DB table. That can also be shown for the whole DB if you simply go to the ‘Relationships’ Tab on the index page (though that diagram is HUGE as the OpenPetra DB currently holds >300 DB Tables!).<br />
<br />
<br />
* [[Base and Demo databases]]<br />
<br />
== OpenPetra Specifications & Requirements ==<br />
Please have a look at the specifications and add your own requirements in the appropriate sections (eg. Wishlist):<br/><br />
[[Specifications and Requirements]]<br />
<br />
<br />
== Project Infrastructure ==<br />
* Have a look at [[wordpress]]. The OpenPetra Website is running on Wordpress.<br />
* Continuous integration with [[Jenkins CI Server]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Homepage&diff=3513Homepage2013-05-15T17:11:45Z<p>Joejoe2010: </p>
<hr />
<div>In order to check the html and css-syntax of the homepage the following 2 tools can be used:<br />
* [http://jigsaw.w3.org/css-validator/ css-validator]<br />
* [http://validator.w3.org/ html-validator]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Homepage&diff=3512Homepage2013-05-15T17:11:25Z<p>Joejoe2010: Created page with 'In order to check the html and css-syntax of the homepage the following 2 tools can be used: [http://jigsaw.w3.org/css-validator/ css-validator] [http://validator.w3.org/ html-va…'</p>
<hr />
<div>In order to check the html and css-syntax of the homepage the following 2 tools can be used:<br />
[http://jigsaw.w3.org/css-validator/ css-validator]<br />
[http://validator.w3.org/ html-validator]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Developers&diff=3511Documentation for Developers2013-05-15T17:09:45Z<p>Joejoe2010: /* Tips and Tricks */</p>
<hr />
<div>== Projects ==<br />
Please read about what needs to be done, and how to take charge of a project here:<br/><br />
[[Summary of Projects]]<br />
<br />
<br />
==Development==<br />
=== Development Environment ===<br />
* [[Setup of Development environment]]<br />
* [[OpenPetra Developer's Assistant]]<br />
<br />
=== Programming ===<br />
* [[Coding Standard and Guidelines]]<br />
* [[Explanation of Directory Structure and Rules]]<br />
* [[Useful hints regarding coding in CSharp/.net]]<br />
* [[Development with Code Generation]]<br />
* [[Build system with our own NAnt tools and tasks]]<br />
* [[Preventing/getting around circular dependency problems]]<br />
<br />
=== Development Cycle ===<br />
* [[Build System for OpenPetra]]<br />
* [[Releases and Patching]]<br />
* [[Building and maintaining customized versions of OpenPetra]]<br />
* [[Migrating data from legacy systems]]<br />
* [[Working with NUnit tests]]<br />
<br />
=== Getting Started ===<br />
* [[HowTo develop a new screen]]<br />
* [[HowTo port a screen from Old Petra]]<br />
* [[HowTo develop a new report]]<br />
* [[Report Designer]]<br />
<br />
=== Tools Used ===<br />
This is a list of software that we use; some of it you will already have installed when you did your [[Setup of Development environment]].<br />
* [[Software tools for Developers]]<br />
* [[Memory profiling]]<br />
<br />
=== Tips and Tricks ===<br />
* [[Quicker development/debugging/testing turnaround with customised PetraClient startup]]<br />
* [[Specifying custom settings in Config Files for Development]]<br />
* [[Literature]]<br />
* [[Retrieving the 'SiteKey' of an OpenPetra installation]]<br />
* [[Homepage]]<br />
<br />
== OpenPetra Software Architecture ==<br />
* [[Overview openPETRA architecture]] <br />
** Taken from the old Petra wiki. Should be merged with the other articles!<br />
* [[n-tier architecture]]<br />
* [[Database access architecture]]<br />
* [[openPETRA Architecture Team]]<br />
<br />
=== Client Side ===<br />
* [[GUI development]]<br />
* [[Printing]]<br />
* [[Main Menu]]<br />
* [[Singleton (single-instance) Screens]]<br />
* Specific Screens<br />
** [[Exchange Rates (Design and Test)]]<br />
<br />
== Bug Tracking ==<br />
See [[Contributing_Source_Code_to_OpenPetra.org#Tracking_of_Bugs_and_Things_to_do|Tracking of Bugs]]<br />
<br />
<br />
== Database Structure Documentation ==<br />
We have DB model documentation online available in two formats, both of which are auto-generated with each release:<br />
* [http://openpetraorg.sourceforge.net/dbdoc/index.html Our own format] (see also [[SQL Diagram creation]])<br />
** There is a [http://openpetraorg.sourceforge.net/dbdoc/img/img_AccountsPayable.html?a_ap_document diagram for the Accounts Payable sub system]<br />
*** We need volunteers do design more diagrams! Please also have a look at the old 2.1 diagrams ([http://openpetraorg.sourceforge.net/Petra21DBDiagrams.zip download 9 png files in a zip file]).<br />
* [http://openpetraorg.sourceforge.net/schemaSpy/index.html SchemaSpy format]<br />
** features quite nice automatically drawn relationship diagrams once you select a certain DB table. That can also be shown for the whole DB if you simply go to the ‘Relationships’ Tab on the index page (though that diagram is HUGE as the OpenPetra DB currently holds >300 DB Tables!).<br />
<br />
<br />
* [[Base and Demo databases]]<br />
<br />
== OpenPetra Specifications & Requirements ==<br />
Please have a look at the specifications and add your own requirements in the appropriate sections (eg. Wishlist):<br/><br />
[[Specifications and Requirements]]<br />
<br />
<br />
== Project Infrastructure ==<br />
* Have a look at [[wordpress]]. The OpenPetra Website is running on Wordpress.<br />
* Continuous integration with [[Jenkins CI Server]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Setup_of_Development_Environment_for_Windows&diff=3176Setup of Development Environment for Windows2012-09-28T18:12:42Z<p>Joejoe2010: /* Database systems */</p>
<hr />
<div>= Overview =<br />
All the development tools we use are open source themselves, so developers do not need to spend money to be able to partly or fully join the openPETRA development!<br />
<br />
'''If you already have some or all of the software installed that is listed here, please make sure it is the same version that we specify before skipping the relevant section on this page!'''<br />
<br />
<br />
== Development Hardware Needed ==<br />
Any PC that you would otherwise use for serious software development should suffice. <br />
* As a rough guide, a PC with a processor speed of more than 2GHz and at least 1 GB of RAM should be OK. <br />
** If your PC is below that specification, development will probably be possible, but rather slow and cumbersome.<br />
** On the other hand: Timotheus works with a Acer One Netbook, N280 CPU 1.6 Ghz, 2 GB RAM; speed is fine.<br />
* More than 2GB of RAM is not necessary if the only applications that you run simultaneously are the ones which are used for developing openPETRA.<br />
* The faster the processor, the better.<br />
** When compiling, it all comes down to processor speed, number of cores of the processor, and the architecture of the processor. <br />
*** We have seen quite a boost in compilation speed with the new "i" series of Intel processors.<br />
* A multi-processor PC has its advantages.<br />
** The SharpDevelop IDE can do parallel compilations of Projects that aren't interdependent - that can speed up compilation notably (we saw an average of 20%-40% speed gain when comparing compilation of all the Client Projects on two processor cores compared to compiling on one processor core). We have verified this to scale very well on up to four processors (we don't have PC's with more processors than that...).<br />
** NAnt (our build system) can do parallel compilations of Projects that aren't interdependent - that can speed up compilation notably. We have verified this to scale very well on up to four processors (we don't have PC's with more processors than that...).<br />
* A 64-bit Operating System (e.g. Windows 7 64-bit) has no advantages for the purposes of developing openPETRA.<br />
* Disk space needed: at least 1 GB<br />
** about 300 MB of this will be needed for the source code and compiled binaries of openPETRA;<br />
** about 200 MB will be needed for development environment software tools;<br />
** roughly 500 MB [+/- 300 MB…] will be needed for the .NET 3.5 SP 1 Redistributable and the corresponding SDK).<br />
<br />
== Time required for setting up an openPETRA development environment ==<br />
Depending on the speed of your PC, and of course the speed of your Internet connection and the speed of the respective download servers, the setting of up of a development environment for openPETRA on Windows can take something between one and two hours.<br />
<br />
= Required software =<br />
<br />
== Microsoft .NET 3.5 ==<br />
Download and install the two Microsoft .NET dependencies. They allow execution of and development for .NET applications (such as openPETRA).<br />
<br />
* Free downloads from Microsoft ('''Both are needed''')<br />
** '''Microsoft .NET 3.5 SP1 Redistributable'''<br />
*** http://www.microsoft.com/downloads/details.aspx?familyid=AB99342F-5D1A-413D-8319-81DA479AB0D7&displaylang=en<br />
**** Follow the 'Instructions' section on that web page and read the 'Important' section.<br />
*** This is ''not needed'' (and will indeed not work!) if you are installing on ''Windows 7'', because the .NET Redistributable is already pre-installed (or even the Microsoft .NET 4 Redistributable, which will also work).<br />
** '''Windows Software Development Kit (SDK), .NET 3.5 SP1'''<br />
*** http://www.microsoft.com/downloads/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505<br />
*** There is no need to install all the components that are available - many involve huge further downloads! Only ".NET Development Tools" and "Debugging Tools for Windows" are needed for developing openPETRA.<br />
*** ''ALTERNATIVE:'' '''Windows Software Development Kit (SDK) for Windows 7 and .NET Framework 4'''<br />
**** http://www.microsoft.com/download/en/details.aspx?id=8279<br />
**** When selecting install options don't forget to include the .NET development section (which includes "Intellisense and Reference Assemblies" and "Tools")<br />
<br />
Microsoft recommends to run 'Windows Update' ''before'' installing those dependencies. It might also be a good idea to run 'Windows Update' ''after'' installing those dependencies to check whether any updates or security patches are available.<br />
<br />
Note: Both the Redistributable '''and''' the SDK are needed!<br />
<br />
== SharpDevelop ==<br />
SharpDevelop is the IDE (Integrated Development Environment) we use for developing openPETRA.<br />
<br />
* Free download: http://www.icsharpcode.net/OpenSource/SD/Download/<br />
* We currently use the latest SharpDevelop 4.2, from 05/06/2012.<br />
* Modifying Text Editor options<br />
** The [[Coding Standard and Guidelines#White_Spaces | openPETRA Coding Standard and Guidelines]] specify that identation needs to be with <SPACE> characters and not <TAB> characters. To set up SharpDevelop to adhere to that standard, change the following setting: Menu 'Tools' -> 'Options…', then 'Text Edior' -> 'Behaviour', 'Tabs' GroupBox. Make sure that 'Convert Tabs to Spaces' is ticked and that 'Tab size' and 'Indentation size' are both set to '4'.<br />
<br />
==PuTTY / Pageant== <br />
[http://www.putty.org/ PuTTY] is a SSH and telnet client for the Windows platform. Pageant comes with PuTTY and is used to load a Private SSH Key; it is used by Bazaar (see below). <br />
<br />
Pageant is needed for 'developer access' only, i.e. if you intend to feed your changes back to the openPETRA Bazaar source code repository at some point. PuTTY and Pageant are ''not'' needed for 'anonymous access'.<br />
<br />
Free download: [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY Download Page] <br />
* In the section 'Binaries', choose the installer under the heading 'A Windows installer for everything except PuTTYtel', e.g. [http://the.earth.li/~sgtatham/putty/latest/x86/putty-0.60-installer.exe putty-0.60-installer.exe] <br />
* Run the installer.<br />
<br />
Load your private key (a .ppk file if generated from putty) with pageant. See https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Submitting_patches_and_features.<br />
<br />
== Bazaar ==<br />
Please follow the instructions at [[How to work with bazaar on the command line]] or [[How to work with bazaar through the GUI on Windows]] to download Bazaar and to get the latest version of the code.<br />
<br />
== WinMerge ==<br />
[http://winmerge.org/downloads/ WinMerge] is a very good tool on Windows to compare single files but also complete source code trees. See the [[WinMerge HowTo]] page for more information.<br />
<br />
== Uncrustify ==<br />
We use Uncrustify to automatically format the code so that it looks more the same.<br />
<br />
Speaking of formatting code, please have a look at [[Coding Standard and Guidelines]] too.<br />
<br />
We are currently using version 0.56, and it is best that all developers use the same version.<br />
<br />
Please use our own installer for Uncrustify, from http://sourceforge.net/projects/openpetraorg/files/openpetraorg/Tools/Uncrustify-Setup-0.56.exe/download<br />
<br />
=== For older installations ===<br />
If you have a different path than below, <br />
&lt;property name="external.Uncrustify" value="${OP::GetFileInProgramDirectory('/uncrustify/uncrustify.exe')}"/&gt;<br />
then you need to add an entry to your OpenPetra.build.config similar to the following with the correct path:<br />
<br />
eg.<br />
<br />
&lt;property name="external.Uncrustify" value="${OP::GetFileInProgramDirectory('/uncrustify-0.56-win32/uncrustify.exe')}"/&gt;<br />
<br />
== NUnit ==<br />
We use NUnit (http://www.nunit.org/, or https://launchpad.net/nunitv2/) for running automated tests.<br />
<br />
At the moment we are using version 2.6.0. (please note: it is better not to use a newer version of NUnit than NAnt supports)<br />
<br />
See also [[Working with NUnit tests]]<br />
<br />
== NAnt ==<br />
NAnt is our build system. It is used for ongoing compilation, for creation of Builds/Releases of openPETRA, and for the automation of quite a few tasks in the development lifecycle of openPETRA - including auto-generation of source code and Forms.<br />
<br />
* Use our own NAnt Installer for Windows, which already includes the NAntContrib files.<br />
** it is available here: http://sourceforge.net/projects/openpetraorg/files/openpetraorg/Tools/NAnt-Setup-0.92.exe/download<br />
<br />
See also our [[Notes about NAnt]].<br />
<br />
Another possible error while trying to compile with nant is the following:<br />
generateFrameworkPath<br />
the path for the .NET Framework could not be found<br />
Then you need to install ''Microsoft .NET Framework 3.5 SDK''<br />
<br />
== Database systems ==<br />
openPETRA works with a number of Database Management systems.<br />
<br />
* Choose one (or more) of the following Database Management systems. (If you want to start development quickly, SQLite is sufficient, so there is no immediate need to install PostgreSQL or MySQL. PostgreSQL is recommended for serious development, however).<br />
** '''SQLite''': no installation effort at all is required! See [[Notes about SQLite]]<br />
** '''PostgreSQL ''(recommended)'''''. See [[Notes about PostgreSQL]]<br />
*** get the latest version from http://www.postgresql.org/download/windows. The one click installer works fine for me.<br />
*** You need to add a Postgresql user/role in pgAdmin with your windows username. Give permissions to create roles and databases to that user.<br />
*** In order to see the OpenPetra tables with pgAdmin go to "Server" -> "PostgreSQL" or "localhost" -> "Database" -> "petra" -> "Schemas" -> "public" -> "tables" - or use the Search function by right-clicking on the database-name.<br />
** '''MySQL'''. See [[Notes about MySQL]]<br />
*** get the latest Windows version from http://dev.mysql.com/downloads/mysql/. It is called MySQL Community Server. The MSI essential package works fine for me.<br />
<br />
If you want to switch from SQLite to PostgreSQL which we recommend for serious development, please follow the instructions at [[Setup_of_Development_environment#Use_another_database_system]].<br />
<br />
= Optional Software =<br />
* For the editing of YAML files (which we use for defining the layout of screens, the main menu entries, and code hierarchy) we use Notepad++, which has syntax highlighting support for YAML files.<br />
** [http://notepad-plus-plus.org/download Download Notepad++]<br />
** Once the software is installed, it needs to be set up once to accept our file extension, '.yaml', in addition to the one is built in, '.yml' for the syntax highlighting to work:<br />
*** Menu 'Settings' -> 'Style Configurator'. Select 'YAML' in the 'Language' list and enter 'yaml' in the 'User ext.' field. Choose 'Save & Close'. (You might need to close and re-open any .yaml file that you already have open to get the syntax highlighting working.)<br />
* The following pieces of software are only required when you want to build releases of OpenPetra:<br />
** Poedit (for translation, generating the .mo file from the .po file): http://www.poedit.net/download.php (alternative: direct .mo file download from launchpad)<br />
** Inno Setup 5 for building setup files: http://www.jrsoftware.org/isdl.php<br />
<br />
<br />
= Downloading of source code and configuring the build environment =<br />
<br />
== Get the source code ==<br />
The source code is managed with the Bazaar source code versioning system. <br />
<br />
You should have got the source code already if you followed the instructions at [[How to work with bazaar on the command line]] or [[How to work with bazaar through the GUI on Windows]].<br />
<br />
Especially when using Windows 7 it is recommended to checkout into a local directory (e.g. on C:) and not one on the network as otherwise compiling with NAnt can give problems. Compiling from a network drive gave the following error on Windows 7: <br />
System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, ... failed<br />
<br />
Please have a look at the following page: [[Submitting patches and features]]!<br />
<br />
= Finally: Building openPETRA with NAnt =<br />
After completing all the steps that are involved in the setup of your development environment for openPETRA, you are ready for the compiling and starting of openPETRA!<br />
<br />
We have a central NAnt script that is able to build openPETRA, to generate a lot of code and is able to do all automated tasks in the openPETRA project.<br />
<br />
Please go to [[Setup_of_Development_environment#NAnt_script|OpenPetra NAnt script]] for finishing your openPETRA development setup.<br />
<br />
If you want to switch from SQLite to PostgreSQL which we recommend for serious development, please follow the instructions at [[Setup_of_Development_environment#Use_another_database_system]].</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Notes_about_PostgreSQL&diff=3175Notes about PostgreSQL2012-09-28T18:04:27Z<p>Joejoe2010: /* Some notes */</p>
<hr />
<div>== Installation ==<br />
== Windows ==<br />
=== Running the Installer ===<br />
* see http://www.postgresql.org/download/windows for current version<br />
* eg. http://wwwmaster.postgresql.org/download/mirrors-ftp/binary/v8.3.7/win32/postgresql-8.3.7-1.zip<br />
<br />
* see also http://jacqueschirag.wordpress.com/2007/08/15/installing-postgresql-on-windows-vista/<br />
<br />
* You might choose to not install a Windows Service for running the PostgreSQL Server, if that option is present in the installer. (It is a personal choice whether you want to run PostgreSQL as a Service or from the Command Line.)<br />
<br />
<br />
=== Initialising the DB Cluster and starting the DB Server ===<br />
You might want to set the environment variables before creating the database:<br />
set PGUSER=postgres<br />
set PGPASSWORD=myPassword<br />
<br />
Or alternatively, write the file pgpass.conf; see http://www.postgresql.org/docs/9.0/interactive/libpq-pgpass.html<br />
<br />
<br />
From the Postgres program folder (e.g. C:\Program Files\PostgreSQL\9.0\bin\) run the following separate commands in a command window:<br />
<br />
initdb -D "petra" <ENTER> <br />
This will create a new Database Cluster called 'petra' (for details on what this is for see [http://www.postgresql.org/docs/9.0/static/app-initdb.html initdb command in the PostgreSQL Documentation]).<br />
<br />
postgres -D "petra" <ENTER> <br />
This will start the PostgreSQL server using the cluster 'petra' from the command line. After the command executed successfully, this command window is then running the PostgreSQL server until the PostgreSQL server is stopped and the command window can therefore not accept any further commands.<br />
* In case you get an error message 'Execution of PostgresSQL by a user with administrative permissions is not permitted. The server must be started under an unprivileged user ID to prevent possible system security compromises. See the documentation for more information how to properly start the server': You need to run the command in a command window that is not associated with your current windows user, as this windows user has administrative privileges. To achieve that, open the command window using the 'Run...' menu item from the start menu and enter the following: <code>runas /user:postgres cmd</code>. You will be asked to enter the username for the postgres user. After entering that, execute the <code>postgres -D "petra"</code> command in this command window. The command should not give the error message anymore. (See [http://postgresql.1045698.n5.nabble.com/GENERAL-starting-postgres-on-windows-td1871435.html this forum post] for details.)<br />
* In case you get an error message 'FATAL: could not create lock file "postmaster.pid": Permission denied': ensure that the user that the PostgreSQL server is running under (usually 'postgres') has full access permissions to the folder that is above the 'data' directory, e.g. 'C:\Program Files\PostgreSQL\9.0'. You would check this and change this using Windows Explorer. (See [http://archives.postgresql.org/pgsql-bugs/2009-06/msg00017.php this forum post] for details.)<br />
<br />
Instead of using the command line you can also use the program pgadmin3. Add there first a new server-connection (Name + Host = localhost, User: postgres, Password: the one that you entered during postgres-installation). Then in the left window-part go to "databases" and add a new one called "petra" with owner "postgres".<br />
<br />
=== Creating a user ===<br />
Open a new command window and again go to the Postgres program folder (e.g. C:\Program Files\PostgreSQL\9.0\bin\). Execute the following command there:<br />
psql -c "CREATE USER mywindowsusername WITH PASSWORD 'anypassword';" <ENTER><br />
* Please replace 'mywindowsusername' with the username that you log in to Windows when developing OpenPetra to avoid problems at a later stage when you will create the OpenPetra DB using the <code>nant recreateDatabase</code> command.<br />
* You can choose any password you want for that PostgreSQL user, it doesn't need to be your real windows password - and in fact it ''shouldn't'', as you will need to put it in plaintext into the OpenPetra.build.config file at a later stage.<br />
<br />
Instead of executing the CREATE USER command you could also use the program pgAdmin. When doing that, ensure that the new user has privileges to create a new database and for creating roles.<br />
<br />
<br />
''When you got to this point you can follow the instructions [[Setup of Development environment#Use_another_database_system | here]] to create the OpenPetra Database in the PostgreSQL cluster.''<br />
<br />
<br />
In case you forgot your postgres-Password do fe. the following:<br />
- Uninstall PostgreSQL<br />
- execute the following command on the windows command line: NET USER postgres /DELETE<br />
- Reinstall PostgreSQL<br />
<br />
<br />
== When Encountering an Error on OpenPetra Server Startup ==<br />
If you get the following error message when starting the OpenPetra server: '<code>Exception occurred while establishing a connection to Database Server. ... System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.</code>' and you are sure that the PostgreSQL DB Server's IP address and Port are correct and you are sure that the username and the password for connecting to the OpenPetra DB are right then it is most likely that the authorisation for your PC that is trying to access the PostgreSQL DB Server is missing from the PostgreSQL DB Server's pg_hba.conf file.<br />
<br />
Solution: <br />
* Open the file <code>/etc/postgresql/9.0/main/pg_hba.conf</code> (on Debian Linux) or <code>/var/lib/pgsql/data/pg_hba.conf</code> (on CentOS and RedHat Linux) or <code>C:\Program Files\PostgreSQL\9.0\data\pg_hba.conf</code> (on Windows) in a text editor and add a line like the following at the end of the file:<br />
host openpetra petraserver xx.yyy.zz.xx/0 md5<br />
- replacing xx.yyy.zz.xx with the IP Address of the PC that you are trying to start the OpenPetra Server on.<br />
* Restart the PostgreSQL DB Server from the command line (or if you use pgAdminIII: right-click on the PostgreSQL DB Server in the Object Browser and choose 'Reload configuration').<br />
* Restart the OpenPetra Server. The error should be gone. If it isn't, check that the PostgreSQL DB Server's IP address and Port are correct and you are sure that the username and the password for connecting to the OpenPetra DB are right.<br />
<br />
<br />
Additional notes regarding pg_hba.conf:<br />
* at least in PostgreSQL 8.x, the order of the lines in that file is important. This means, I had to add the line for the petraserver user before the "host all" line.<br />
* for local access with psql, I need the row before <code>local all all ident sameuser</code><br />
local openpetra petraserver md5<br />
<br />
== Some notes ==<br />
* drop database but tables are still there when creating the database again: [http://bytes.com/groups/postgresql/423960-drop-database-but-still-there]; reason: tables are in template1 db, and that is used as a template for creating the new database<br />
* drop all tables in db: DROP SCHEMA public CASCADE; [http://archives.postgresql.org/pgsql-novice/2004-08/msg00272.php]<br />
** you should create a new schema public again (especially if this is the template1 db): CREATE SCHEMA public;<br />
<br />
<br />
* Hide notice during nant recreateDatabase: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "..." for table "..."<br />
** http://archives.postgresql.org/pgsql-sql/2009-06/msg00006.php: alter role bubba set log_min_messages=error; <br />
** pitfalls: need to set this as user postgres, otherwise no permission to change role. Need to use double quotes "MyCapitalizedUsername" otherwise the role is not known<br />
<br />
* If you get problems logging in to the database via nant recreateDatabase then please look [https://sourceforge.net/apps/phpbb/openpetraorg/viewtopic.php?f=8&t=141&p=451#p451 here]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Coding_Standard_and_Guidelines&diff=3165Coding Standard and Guidelines2012-09-14T16:35:23Z<p>Joejoe2010: /* Capitalization Styles */</p>
<hr />
<div>=About the C# Coding Style Guide=<br />
<br />
'''This document may be read as a guide to writing robust and reliable C# programs.'''<br />
<br />
Notes: <br />
# Many of the rules in this document can be ''applied automatically'' to source code using the 'Uncrustify' tool that we use (<code>make uncrustify</code>)<br />
## Those rules are marked with '<font color="blue">Enforced by Uncrustify.</font>'<br />
# Many of the rules in this document can be ''checked automatically'' with the 'StyleCop' tool that we use (<code>make stylecop</code>)!<br />
## Those rules are marked with '<font color="peach">Checked by StyleCop.'</font> ''<font color="darkred">'''TODO'''</font>''<br />
# 'Uncrustify' and 'StyleCop' and how we use them with Petra are described in [[Coding Standards Tools: 'Uncrustify' and 'StyleCop']].<br />
<br />
This 'C# Coding Style Guide' was inspired by the [http://www.icsharpcode.net/TechNotes/ C# Coding Style Guide] written by Mike Krüger. This is used by the SharpDevelop programmers who work on the SharpDevelop IDE.<br />
<br />
=File Organization=<br />
<br />
==C# Sourcefiles==<br />
<br />
* Keep your classes/files short: try hard not to exceed 3.000 lines of code and never go beyond 4.000 lines of code.<br />
** Exception to that:<br />
*** Auto-generated code can ignore that rule if the generated file doesn't need to be looked at/touched by developers.<br />
* Divide your code up and make structures clearer. <br />
* Every class should go in a separate file. <br />
** Exceptions to that:<br />
*** Helper classes for the main class in the same file are allowed, but they must be private classes!<br />
*** Auto-generated code can ignore that rule if the generated file doesn't need to be looked at/touched by developers.<br />
* The file name should reflect the name of the class in the file (.cs as extension of course).<br />
** Exception to that:<br />
*** The file name of a source file can have the last part of a Namespace in it ''if'' the Namespace is nested quite deeply ''and'' <br />
the directory structure doesn't reflect that deep nesting anymore (see [[Coding_Standard_and_Guidelines#Directory_Layout|'Directory Layout']] below). Example: DataAggregates.PPartnerAddress.cs in Namespace 'Ict.Petra.Server.MPartner.'''DataAggregates'''' in directory 'U:\openpetraorg\csharp\ICT\Petra\Server\lib\MPartner'.<br />
<br />
<br />
''These conventions makes things much easier to read and find.''<br />
<br />
==Directory Layout==<br />
<br />
* Create a directory for every namespace. Example: for Namespace 'Ict.Petra.Server.App.Core' use 'U:\delphi.net\ICT\Petra\Server\app\' as the path (do not use the Namespace name with dots for directory names).<br />
** Exceptions to that:<br />
*** Additional directories might be placed inbetween parts of the Namespace ''if'' that benefits the directory structure ''and'' an agreed rule when to do that is followed. Example: Namespace 'Ict.Petra.Server.MPartner.DataAggregates' resides in directory 'U:\delphi.net\ICT\Petra\Server\'''lib'''\MPartner'. Note the 'lib' directory, which is inserted.<br />
*** ''If'' a Namespace is nested quite deeply, we can opt to have the directory structure ''not'' reflecting that deep nesting. In that case, the last part of a Namespace should then be part of the file name of a Class (see [[Coding_Standard_and_Guidelines#C.23_Sourcefiles |'C# Sourcefiles']] above).<br />
<br />
<br />
See also [['Explanation of Directory Structure and Rules']] for more detailed information!<br />
<br />
<br />
''These conventions make it easier to map namespaces to the directory layout.''<br />
<br />
=Indentation=<br />
<br />
==White Spaces==<br />
For code indentation, two standards exist in the world of programming: indendation with spaces and indendation with tabs. Some programmers prefer spaces, others prefer tabs.<br />
<br />
Here, we define the space character as the standard indentation character.<br />
Specifically, '''we indent everything with four spaces''' - <font color="blue">Enforced by Uncrustify</font>. This applies for the indendation from column 1 to the indendation level of the current code and also to any further indendations from there.<br />
<br />
By using spaces, not tabs, we can ensure that our code is indented identically for every developer and in every editor. If we used tabs, the indentation could vary.<br />
<br />
'''Don't use tabs for indentation - use spaces!''' <font color="blue">Enforced by Uncrustify.</font><br />
<br />
==Wrapping Lines==<br />
<br />
When an expression will not fit on a single line, break it up before it reaches more than '''150''' characters. <font color="blue">Enforced by Uncrustify.</font> You might want to break it up before that for readability.<br />
<br />
Follow these general principles when breaking up a line: <br />
<br />
*Break after a comma.<br />
*Break after an operator.<br />
*Prefer higher-level breaks to lower-level breaks.<br />
*Indent the new line at the standard indentation level, or align the new line with the beginning of the expression at the same level on the previous line.<br />
<br />
Example of breaking up method calls:<br />
<pre><br />
LongMethodCall(expr1, expr2,<br />
<br />
expr3, expr4, expr5); // indented at the standard indentation level<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
LongMethodCall(expr1, expr2,<br />
<br />
expr3, expr4, expr5); // aligned with the beginning of the expression on the previous line<br />
</pre><br />
<br />
The first is preferred because it results in uniformly formatted code, but if indenting with the second method makes for better reading in a specific case then use the second method.<br />
<br />
<br />
Examples of breaking an arithmetic expression:<br />
<br />
PREFER:<br />
<br />
<pre><br />
var = a * b / (c - g + f) + <br />
<br />
4 * z;<br />
</pre><br />
<br />
BAD STYLE – AVOID:<br />
<pre><br />
var = a * b / (c - g + <br />
<br />
f) + 4 * z;<br />
</pre><br />
<br />
The first is preferred, since the break occurs outside the paranthesized expression (higher level rule).<br />
<br />
<br />
=Comments=<br />
<br />
All comments must be written in English.<br />
<br />
==Block Comments==<br />
<br />
Block comments for the purpose of describing Classes, Methods, etc. should be avoided. Instead, use of the <code>///</code> comments to give C# standard descriptions is recommended (see [[Coding_Standard_and_Guidelines#Documentation_Comments | 'Documentation Comments']] below). <br />
<br />
If you wish to use block comments inside Methods, Classes, etc. you should use the following style:<br />
<br />
<pre><br />
/* The following Algorithm does bla bla bla<br />
<br />
<nowiki> * and is adapted from the well-known blah blah Algorithm.</nowiki><br />
<br />
<nowiki> * An example of this Algorithm can be found on http://www.blahalgorithms.org</nowiki><br />
<br />
<nowiki> *</nowiki>/<br />
</pre><br />
<br />
...as this will set off the block visually from code for the (human) reader. <br />
<br />
Block comments may be useful in rare cases, refer to the TechNote [http://www.icsharpcode.net/TechNotes/Commenting20020413.pdf 'The fine Art of Commenting'] for an example.<br />
<br />
''As a general rule of thumb, the length of a comment should not overly exceed the length of the code it explains as this is an indication of too complicated (and potentially buggy) code.''<br />
<br />
''For commenting out sections of code, use the 'Single Line Comments' (despite their name) to distinguish better between code that has comments attached and code that is commented out.''<br />
<br />
==Single Line Comments==<br />
<br />
Developers should use the <code>//</code> (two forward slahes) comment style to "comment out" code (SharpDevelop has a shotcut key for it, Alt+/). ''It may be used for commenting out sections of code too.''<br />
<br />
Note on using StyleCop: because we will use StyleCop, you should rather use <code>////</code> (four forward slashes) instead of <code>//</code> when commenting out ''single'' lines of code. This helps the tool to not confuse it with a single line comment (which is not commented out code). (Refers to StyleCop Rule SA1512: SingleLineCommentsMustNotBeFollowedByBlankLine.)<br />
<br />
<br />
Single line code comments must be indented to the indent level when they are used for code documentation. Commented out code should be commented out so that the <code>//</code> (two slashes) start in column 1. This is to enhance the visibility of commented out code.<br />
<br />
==Documentation Comments==<br />
<br />
In the .NET framework, Microsoft has introduced a documentation generation system based on XML comments. These comments are formally single line C# comments containing XML tags. They follow this pattern for single line comments:<br />
<br />
<pre><br />
/// <summary><br />
<br />
/// This class...<br />
<br />
/// </summary><br />
</pre><br />
<br />
Multiline XML comments follow this pattern:<br />
<br />
<pre><br />
/// <exception cref=”BogusException”><br />
<br />
/// This exception gets thrown as soon as a<br />
<br />
/// Bogus flag gets set.<br />
<br />
/// </exception><br />
</pre><br />
<br />
All lines must be preceded by <code>///</code> (three slashes) to be accepted as XML comment lines.<br />
<br />
Tags fall into two categories:<br />
<br />
* Documentation items<br />
* Formatting/Referencing<br />
<br />
The first category contains tags like <code><summary></code>, <code><param></code> or <code><exception></code>. <br />
These tags represent the elements of a program's API which must be documented for the program to be useful to other programmers. <br />
They usually have attributes such as <code>name</code> or <code>cref</code> (as demonstrated in the multi line example above) and are <br />
checked by the compiler, so they should be valid.<br />
<br />
The latter category governs the layout of the documentation, using tags such as <code><nowiki><code></nowiki></code>, <code><list></code> or <code><para></code>.<br />
<br />
For a fuller explanation of XML comments see [['CSharp In-Code Documentation with MS XML Tags']]. <br />
For information on how to produce API-style documentation for C# Projects whose .cs files contain XML Comment Tags, see [['How to produce CSharp API Documentation']].<br />
<br />
For information on commenting best practice and further issues related to commenting, see the TechNote [http://www.icsharpcode.net/TechNotes/Commenting20020413.pdf 'The fine Art of Commenting'].<br />
<br />
==End Comments==<br />
<br />
By 'End Comments' we mean adding a single-line comment after the closing curly brace "}" of a code block to explain what section of code the closing curly braces ends. <br />
<br />
We decided this is unnecessary if this information is obvious. In other words, use 'End Comments' only when the meaning of the closing curly brace "}" of a code block is not immediately obvious due to either a very long block, or in the case of many nested blocks.<br />
<br />
=Declarations=<br />
<br />
==Number of Declarations per Line==<br />
<br />
Only one declaration per line is allowed. This greatly enhances readabiliy and it encourages commenting. <br />
<br />
GOOD STYLE: <br />
<br />
<pre><br />
int Level; // indentation level<br />
int Size; // size of table<br />
</pre><br />
<br />
Do not put more than one variable or variables of different types on the same line when declaring them. <br />
<br />
BAD STYLE - AVOID: <br />
<br />
<pre><br />
int Var1, Var2; // What is 'Var1'? What does 'Var2' stand for?<br />
</pre><br />
<br />
Declarations should be followed by an empty line so that they are visually set apart from the rest of the source code. <font color="blue">Enforced by Uncrustify.</font><br />
<br />
The above example also demonstrates the drawbacks of non-obvious variable names. <br />
<br />
''Be clear when naming variables.'' Using self-explanatory variable names such as <code>IndentLevel</code> eradicates the need for making explanatory comments.<br />
<br />
==Initialization==<br />
<br />
Try to initialize local variables as soon as they are declared. <br />
<br />
For example:<br />
<br />
<pre><br />
string Name = myObject.Name;<br />
int Val = time.Hours;<br />
</pre><br />
<br />
Initialisations should be followed by an empty line so that they are visually set apart from the rest of the source code. <font color="blue">Enforced by Uncrustify if the initialisations are part of declarations.</font><br />
<br />
'''Note:''' when initializing a Dialog/Modal Form (by using .ShowDialog instead of .Show), use the following construct to be sure the Form is released from memory when it is closed:<br />
<br />
<pre><br />
using (TOpenFileDialog openFileDialog = new TOpenFileDialog()) <br />
{<br />
openFileDialog.ShowDialog();<br />
...<br />
} <font color="gray">// .NET will release openFileDialog automatically, so we can't forget about it!</font><br />
</pre><br />
<br />
'''Background:''' forms shown with .ShowDialog are not released from memory, but kept in memory so the caller can call methods after the Form is closed to retrieve parameters. Therefore, you can forget to release the form from memory later.<br />
<br />
==Class, Interface and Namespace Declarations==<br />
<br />
For C# classes, interfaces and namespaces, the following formatting rules should be followed:<br />
<br />
* Braces<br />
** The opening brace "{" appears in the next line after the declaration statement.<br />
** The closing brace "}" starts a line by itself indented to match its corresponding opening brace.<br />
** The opening brace "{" and the closing brace "}" should be on the same indentation level as the code block construct that owns it.<br />
* Spacing<br />
** A single space character should be placed on each side of the colon that follows the class name. <br />
** If there is a list of types/interfaces that the class inherits from, the items should be separated by a comma followed by a space character.<br />
* Code block separation<br />
** An empty line should preceed and succeed each class, interface or namespace block.<br />
*** Exceptions:<br />
**** if a class, interface or namespace block begins immediately after another class, interface or namespace block has been started with an opening brace "{": then no empty line should be inserted.<br />
**** if a class, interface or namespace block ends and another enclosing code block also ends immediately after the closing brace "}": then no empty line should be inserted.<br />
<br />
For example:<br />
<br />
<pre><br />
namespace MyNamespace<br />
'''{''' <font color="gray">// no empty line</font><br />
class TMySample : TMyClass, IMyInterface<br />
'''{'''<br />
void DoSomething()<br />
'''{'''<br />
<br />
'''}'''<br />
<br />
void DoAnotherThing()<br />
'''{'''<br />
<br />
'''}'''<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
class TMyOtherSample : TMySample, IMyOtherInterface<br />
'''{'''<br />
void DoSomething()<br />
'''{'''<br />
<br />
'''}'''<br />
<br />
void DoAnotherThing()<br />
'''{'''<br />
<br />
'''}'''<br />
'''}''' <font color="gray">// no empty line</font><br />
'''}'''<br />
</pre><br />
<br />
For another brace placement example look at section 'Code Examples - Brace placement example'.<br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Method Declarations==<br />
<br />
For method declarations the following formatting rules should be followed:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** No space should be put between a method name and the opening parenthesis "(" that starts its parameter list.<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
<br />
For example:<br />
<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
public MySample'''('''int AMyInt''')'''<br />
'''{'''<br />
this.FMyInt = AMyInt;<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
void Inc'''()'''<br />
'''{'''<br />
++FMyInt;<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Property, Indexer and Event Declarations==<br />
<br />
For properties, indexers and events, the following formatting rules should be followed:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied. <font color="blue">Enforced by Uncrustify: all rules, except for 'opening curly bracket must be on a new line' (Uncrustify can't enforce that for EventHandlers).</font><br />
* Spacing<br />
** For properties where both 'get' and 'set' blocks are present, an empty line should be placed between the 'get' block and the 'set' block.<br />
** For event handlers where both 'add' and 'remove' blocks are present, an empty line should be placed between the 'add' block and the 'remove' block.<br />
** For indexers, use no space between 'this' and '['. <font color="blue">Enforced by Uncrustify.</font><br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the getter/setter or adder/remover!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
public int Amount <br />
'''{'''<br />
get <br />
'''{'''<br />
...<br />
'''}'''<br />
<font color="gray">// empty line goes here</font> <br />
set <br />
'''{'''<br />
...<br />
<br />
'''}'''<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
public EventHandler MyCustomEventHandler<br />
'''{'''<br />
add <br />
'''{'''<br />
...<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
remove <br />
'''{'''<br />
...<br />
'''}'''<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
public this'''['''string index]<br />
'''{'''<br />
get;<br />
<font color="gray">// empty line goes here</font> <br />
set;<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
==Simple Statements==<br />
<br />
Each code line should contain ''only one statement''.<br />
<br />
==Return Statements==<br />
<br />
A <code>return</code> statement should not use outermost parentheses. <font color="blue">Enforced by Uncrustify.</font><br />
<br />
GOOD STYLE : <br />
<br />
<code>return (n * (n + 1)) / 2;</code><br />
<br />
BAD STYLE - AVOID: <br />
<br />
<code>return '''('''(n * (n + 1)) / 2''')''';</code><br />
<br />
<br />
== Statements With Multiple Conditions ==<br />
In a situation where more than one condition is specified (eg. in <code>if</code>, <code>for</code> or <code>do-while</code>-statments), please follow these guidelines:<br />
* Place each condition on a separate line.<br />
* Place the ''&&'' and ''||'' that connects the conditions on the same line as the next condition. (See example.)<br />
* If you have a very complicated condition statement, try to align the different conditions. The goal is to make the condition more readable in the end, so you may use your discretion here as well.<br />
<br />
Example:<br />
<pre><br />
if (((''condition1)''<br />
&& (''condition2'')<br />
|| (''condition3''<br />
&& ''condition4''))<br />
(&& !''condition5''))<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
==If, if-else, if else-if else Statements==<br />
<br />
<code>if, if-else</code> and <code>if else-if else</code> statements should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "if" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the ensuing code statement(s), or between the code statement(s) and the closing bracket ")".<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the condition!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
if '''('''condition''')'''<br />
{<br />
DoSomething();<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
if '''('''condition''')''' <br />
{<br />
DoSomething();<br />
...<br />
} <br />
else <br />
{<br />
DoSomethingOther();<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
if '''('''condition''')'''<br />
{<br />
DoSomething();<br />
...<br />
} <br />
else if '''('''condition''')'''<br />
{<br />
DoSomethingOther();<br />
...<br />
} <br />
else <br />
{<br />
DoSomethingOtherAgain();<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==For / Foreach Statements==<br />
<br />
<code>For</code> and <code>foreach</code> statements should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "for"/"foreach" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the ensuing code statement(s), or between the code statement(s) and the closing bracket ")".<br />
** <code>for</code> only<br />
*** Space characters should be put after the semicolon ";" which separates the initialisation, condition and execution code parts (contained inside the brackets).<br />
*** Inter-term spacing rules should be applied (see [[Petra_Coding_Conventions_for_C_Sharp#Inter-term_spacing | 'Inter-term spacing']] below).<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the loop!<br />
<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
for '''('''int Counter = 0; Counter < 5; ++Counter''')''' <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
foreach '''('''int MyIterator in IntList''')''' <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==While/Do-While Statements==<br />
<br />
<code>while/do</code> statements should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "while" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the condition, or between the condition and the closing bracket ")".<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the loop!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
while '''('''condition''')'''<br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
An empty while should have the following form:<br />
<br />
<pre><br />
while '''(condition)'''<br />
{<br />
;<br />
}<br />
</pre><br />
<br />
A do-while statement should have the following form:<br />
<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
do <br />
{<br />
...<br />
} while '''('''condition''')''';<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Switch Statements==<br />
<br />
A <code>switch</code> statement should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "switch" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the condition, or between the condition and the closing bracket ")".<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
** An empty line should succeed each 'break;' statement.<br />
*** Exception: no empty line after the 'break;' statement in the 'default' block.<br />
* Other line breaks:<br />
** the <code>case ''x'':</code> condition and its ensuing statement(s), as well as the <code>default:</code> line and its statement(s), should be separated by a line break.<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
switch '''('''condition''')'''<br />
{<br />
case A: <font color="gray">// line break here</font><br />
...<br />
break;<br />
<font color="gray">// empty line goes here</font><br />
case B: <font color="gray">// line break here</font><br />
...<br />
break;<br />
<font color="gray">// empty line goes here</font><br />
default: <font color="gray">// line break here</font><br />
...<br />
break; <font color="gray">// NO empty line to follow!</font><br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Try-Catch Statements==<br />
<br />
<code>try-catch</code> statements should follow these formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the respective try/except/finally section!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
try <br />
{<br />
...<br />
} <br />
catch (Exception) <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
try <br />
{<br />
...<br />
} <br />
catch (ApplicationException ae) <br />
{<br />
...<br />
}<br />
catch (Exception e) <br />
{<br />
...<br />
} <br />
finally <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify -</font> all rules, except for: <br />
* 'Code block separation' (Uncrustify can't enforce that);<br />
* 'Opening curly bracket must be on new line' for the 'finally' statement (Uncrustify's rule to enforce that doesn't work).<br />
<br />
=White Space=<br />
<br />
==Blank Lines==<br />
<br />
Blank lines improve readability by setting off blocks of code which are in themselves logically related.<br />
<br />
''Two blank lines'' should always be used between:<br />
* Logical sections of a source file.<br />
* Class and interface definitions (try one class/interface per file to prevent this case).<br />
<br />
''One blank line'' should always be used between:<br />
* Methods. <font color="blue">Enforced by Uncrustify</font><br />
* Properties.<br />
* Code blocks (<code>if</code> statements, <code>for/foreach</code> loops and <code>while</code> loops, <code>switch</code> blocks and <code>try/catch</code> blocks). <font color="blue">Enforced by Uncrustify</font><br />
* Local variables in a method and the first statement in the method. <font color="blue">Enforced by Uncrustify (although not always reliable)</font><br />
* Logical sections inside a method to improve readability.<br />
<br />
Blank lines should be indented to the correct indent level instead of leaving them blank or, even worse, using another indentation level. This makes the insertion of new statements in these lines much easier.<br />
<br />
==Inter-term spacing==<br />
<br />
There should be a single space after a comma or a semicolon.<br />
<br />
For example:<br />
<pre><br />
TestMethod(a, b, c); <font color="gray">// don't use : TestMethod(a,b,c)</font><br />
</pre><br />
<br />
Single spaces surround operators (except unary operators like increment (<code>++</code>) or logical not (<code>!</code>)).<br />
<br />
For example:<br />
<pre><br />
a = b; <font color="gray">// don't use a=b;</font><br />
<br />
for (int Counter = 0; Counter < 10; ++Counter) <font color="gray">// don't use 'for (int i=0; i<10; ++i)' <br />
// or 'for(int i=0;i<10;++i)'</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify:</font> all rules.<br />
<br />
<br />
=Naming Conventions=<br />
<br />
All names of all code elements must be written in English.<br />
<br />
==Capitalization Styles==<br />
<br />
===Pascal Casing===<br />
<br />
This convention capitalises the first character of each word (as in '''T'''est'''C'''ounter).<br />
<br />
===Camel Casing===<br />
<br />
This convention capitalises the first character of each word except the first word (as in '''t'''est'''C'''ounter).<br />
<br />
===All-Uppercase===<br />
<br />
All-uppercase capitalises all characters of a word. Use all-uppercase only for ''constant identifiers''. (For non-constant identifiers that are commonly used in all-uppercase (eg. URL, PI) use Pascal Casing instead.)<br />
<br />
==Naming Guidelines==<br />
<br />
Naming according to the guidelines for 'Hungarian Notation' is considered bad practice.<br />
<br />
Hungarian Notation is a defined set of prefixes and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used <br />
in early Windows programming, but is now obsolete or at least should be considered deprecated. Using Hungarian Notation is not allowed if you follow this guide.<br />
<br />
''Remember: a good variable name describes the semantic not the type.''<br />
<br />
An exception to this rule is GUI code. All fields and variable names that contain GUI elements like ''Button'' should be prefixed with their respective [[GUI_controls_prefixes|GUI control prefix]].<br />
<br />
For example:<br />
<pre><br />
System.Windows.Forms.Button '''btn'''Cancel;<br />
System.Windows.Forms.TextBox '''txt'''Name;<br />
</pre><br />
<br />
===Namespace Naming Guidelines===<br />
* Namespace names should be nouns or noun phrases.<br />
* Use Pascal Casing.<br />
* Name prefix: none.<br />
<br />
===Class Naming Guidelines===<br />
<br />
* Class names should be nouns or noun phrases.<br />
* Use Pascal Casing.<br />
* Name prefix: '<code>T</code>' (stands for '''T'''ype).<br />
** Classes that are derived from <code>System.Windows.Form</code> should use the prefix <code>TFrm</code> instead.<br />
<br />
For example:<br />
<pre><br />
public class TConnection<br />
{<br />
...<br />
}<br />
<br />
<br />
public class TFrmAboutPetra<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
===Interface Naming Guidelines===<br />
<br />
* Name interfaces with nouns or noun phrases or adjectives describing behaviour.<br />
* Use Pascal Casing.<br />
* Name prefix: '<code>I</code>' (stands for '''I'''nterface).<br />
<br />
For example:<br />
<pre><br />
public interface IComponent<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
===Exception Naming Guidelines===<br />
<br />
* Name Exceptions with nouns or noun phrases.<br />
* Use Pascal Casing.<br />
* Name prefix: '<code>E</code>' (stands for '''E'''xception).<br />
* Name suffix: '<code>Exception</code>'. (The suffix is a recommended convention of Microsoft and considered good style by many C# programmers.)<br />
<br />
For example:<br />
<pre><br />
public class EConnectionException<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
===Enum Naming Guidelines===<br />
<br />
* Name<br />
** Use singular names for enum ''types''. Pascal Casing.<br />
** Use singular names for enum ''values''. camelCasing.<br />
* Prefixes<br />
** Enum type name: 'T'. It is to be followed by a capital letter (first character of the enum name). Enum types should also include the word <code>Enum</code> as a suffix to the name.<br />
** Enum values: concatenate the letters of each word that make up the enum type name and prefix those in lower case to the enum value.<br />
<br />
<br />
For example:<br />
<pre><br />
public enum '''T'''ModuleSwitchEnum<br />
{<br />
'''ms'''None, '''ms'''Partner, '''ms'''Personnel, '''ms'''Finance<br />
}<br />
<br />
<br />
public enum '''T'''UIConnectorTypeEnum<br />
{ <br />
'''uict'''PartnerKey, '''uict'''LocationKey, '''uict'''NewPartner<br />
}<br />
</pre><br />
<br />
===Event Names===<br />
<br />
Event Handlers:<br />
* Name event handlers with the <code>EventHandler</code> suffix.<br />
* Name event handlers that have a timeline concept of pre and post using the present and past tense (eg. <code>...Chang'''ing'''EventHandler</code> and <code>...Chang'''ed'''EventHandler</code>).<br />
* For generic event handlers use two parameters named <code>sender</code> and <code>e</code>.<br />
* Use Pascal Casing.<br />
* Prefix: 'T' followed with a capital letter (first character of the event handler).<br />
<br />
Event Arguments:<br />
* Name event argument classes with the <code>EventArgs</code> suffix.<br />
* Consider naming events using a verb.<br />
* Use Pascal Casing.<br />
* Prefix: 'T' followed with a capital letter (first character of the event argument class).<br />
<br />
===Property Names===<br />
<br />
* Name properties using nouns or noun phrases.<br />
* Consider naming a property with the same name as it’s Type.<br />
* Use Pascal Casing.<br />
* Prefix: none!<br />
<br />
===Method Names===<br />
<br />
* Name methods with verbs or verb phrases.<br />
* Use Pascal Casing.<br />
* Prefix: none!<br />
<br />
===Argument Names===<br />
'Arguments' are parameters that are passed to a method. They are used much like private variables of a method.<br />
<br />
* Use accurate and descriptive names that are sufficient to determine the argument's meaning and it’s type.<br />
* Use Pascal Casing.<br />
* Prefix: 'A' (stands for '''A'''rgument) followed by a capital letter (first character of the argument name).<br />
<br />
===Field Names===<br />
'Fields' are private variables of a class.<br />
<br />
* Use accurate and descriptive names that are sufficient to determine the field's meaning and it’s type.<br />
* Use Pascal Casing.<br />
* Prefix: 'F' (stands for '''F'''ield) followed by a capital letter (first character of the field name).<br />
<br />
=== Variable Names===<br />
'Variables' are private variables of a method.<br />
<br />
* Use accurate and descriptive names that should be sufficient to determine the variable's meaning and it’s type.<br />
* Boolean variables: use prefixes like 'Is...', 'Has...' or 'Can...'. and names that imply true or false. For example: 'FileFound', 'Done', 'Success' or with their prefixes: 'IsFileFound', 'IsDone', 'IsSuccess'; don't try 'Is''Name''' that doesn't make sense at all.<br />
* Loop counters: use ''Counter'' as the standard name for these kinds of variables as they are used in loops to serve as counters, indexes, or the like. Whenever you have a nested loop that also uses a counter, add numbers to the end to indicate the level of the counter.<br />
* Temporary variables: should be called ''Tmp''. Many times you need to use a variables with no specific meaning - just a quick place-holder or something that will have but a moment of usage. Whenever you need more than one temporary variable in a particular context, you should consider using self-explanatory names for these variables instead.<br />
* Use Pascal Casing.<br />
* Prefix: none!<br />
<br />
===Constant Names===<br />
<br />
* Name constant fields with nouns, noun phrases or abbreviations for nouns. If they consist of more than one word, separate the words with underscore characters (<code>_</code>).<br />
* Use ALL-UPPERCASE<br />
* Prefix: none!<br />
<br />
For example:<br />
<pre><br />
public class TMath<br />
{<br />
public const string LONG_CONST_NAME = ...<br />
public const double PI = 3.14...<br />
public double Pi = 3.14... <font color="gray">// this is a variable and not a constant, <br />
// so don't use PI</font><br />
}<br />
</pre><br />
<br />
===Naming and Capitalisation Summary===<br />
<br />
{| width="643" border="1" cellpadding="4"<br />
<br />
|- valign="top"<br />
! width="88" |<br />
Type<br />
! width="80" |<br />
Prefix<br />
! width="80" |<br />
Case<br />
! width="400" |<br />
Notes<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Namespaces<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Classes / Structs<br />
| width="80" |<br />
T<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Special prefix: <code>TFrm</code> if derived from <code>System.Windows.Form</code>.<br />
<br />
|-<br />
| Interfaces<br />
| I<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Exception Classes<br />
| width="80" |<br />
E<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Suffix: <code>Exception</code>.<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Enum Types<br />
| width="80" |<br />
T<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Suffix: <code>Enum</code><br />
<br />
|- valign="top"<br />
| width="120" |<br />
Enum Values<br />
| width="80" |<br />
see Notes<br />
! width="80" |<br />
Camel Casing<br />
| width="400" |<br />
Prefix: Concatenate the letters of each word that make up the enum type name and prefix those in lower case to the enum value.<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Event Handlers / Event Arguments<br />
| width="80" |<br />
T<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Suffix for Event Handlers: <code>EventHandler</code>. Suffix for Event Arguments: <code>EventArgs</code>.<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Properties<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Methods<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Arguments<br />
| width="80" |<br />
A<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Fields<br />
| width="80" |<br />
F<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Local variables<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Global Variables<br />
| width="80" |<br />
G<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Constants<br />
| width="80" |<br />
none<br />
! width="80" |<br />
All-Uppercase<br />
| width="400" |<br />
<br />
|}<br />
<br />
=Programming Practices=<br />
<br />
==Visibility==<br />
<br />
===Generally===<br />
Give a class, interface, event handler, method, field always the ''least possible visibility''.<br />
This means that you should consider giving it <code>private</code> visibility, and only if that is not enough increase the visibility - but only as much as is needed.<br />
<br />
===Fields===<br />
Do not make fields public - always make them private. Create properties for fields instead. You may use public static fields (or consts) as an exception to this rule, but be very careful with it.<br />
<br />
''Having appropriate visibility ensures proper use of classes by every programmer and is kind of 'self-documenting' in the way that it tells how the class can be used.''<br />
<br />
==No 'Magic' Numbers==<br />
<br />
Do not use 'magic' numbers, i.e. place constant numerical values directly into the source code. Replacing these lateron in case of changes <br />
(say, your application can now handle 3540 users instead of the 427 users hardcoded into your code in 50 lines scattered troughout your 25000 lines of code) is error-prone and unproductive. <br />
Instead declare a const which contains the number:<br />
<br />
<pre><br />
public class TMyMath<br />
{<br />
public const double PI = 3.14... <br />
}<br />
</pre><br />
<br />
== SQL Queries ==<br />
<br />
All SQL keywords should be in capital letters. <br /><br />
<br />
The main query command keyword (e.g. ''SELECT'', ''UPDATE'', ''INSERT'', etc.) should be on the indentation base, and the rest of the text belonging to that query should be indented.<br />
<br />
Indentation for SQL queries should be four spaces (like for the rest of the source code). <br /><br />
<br />
If the list of columns or tables become to long, it should be split over more than one line. If this is done, the lists should be aligned.<br />
<br />
Every keyword that signifies a new 'section' of the query should be on a new line, with everything belonging to that section indented. (See example.) <br /><br />
<br />
The keywords ''AND ''and ''OR'' should also be on a new line, and indented. It is also recommended to try and align the conditions. To do this, simply add a few spaces after the ''AND'' and ''OR'' keywords until the condition is aligned to the one in the previous line.<br />
<br />
<br /> Cumulative examples: <br /><br />
<br />
<pre><br />
SELECT a_column_1_i, a_column_2_l,<br />
a_column_3_i, a_column_4_n<br />
FROM a_table<br />
WHERE a_column_1_i > 5<br />
AND a_column_2_l = TRUE<br />
OR a_column_4_n = 10<br />
ORDER BY a_column_3_i;<br />
<br />
SELECT surname, forenames<br />
FROM employee<br />
WHERE depno =<br />
(SELECT depno<br />
FROM employee<br />
WHERE empno = 16)<br />
AND empno != 16<br />
<br />
DELETE FROM a_whatever<br />
WHERE mmm<br />
AND mmm<br />
OR mmm<br />
<br />
UPDATE a_whatever<br />
SET (mm1 = 'khasg kvjshdfbv jszhdvb kszjhvb ksjvhb asj,f abv,jfhv badfj',<br />
mm2 = (SELECT id<br />
FROM something<br />
WHERE something else)<br />
mm3, mm4)<br />
WHERE mmm<br />
AND mmm;<br />
</pre><br />
<br />
<br /> Table aliases can be named by using the first letter of every word in the table name (excluding unnecessary things like prefixes). If the same table is used twice in the query with two aliases, simply add a number at the end of the alias name to distinguish them, or name them in such a way as to separate them logically. <br /><br />
<br />
<span style="font-style: italic;">Never use </span>''SELECT * ''<span style="font-style: italic;">for a query in Petra!</span> This can cause a lot of data transfer! By not using it you can prevent errors, and also make life much easier for things like Typed DataSets.<br />
<br />
= Use Discretion! =<br />
<br />
'''These standards were set up to help us as programmers to better maintain the code. Please try to comply to these standards.''' <br />
<br />
'''We realise that there are times when the standards would actually have a negative effect, or maybe where the standards are not entirely clear. In these situations, please use your discretion to come up with a suitable alternative, and discuss it with the rest of the team before you use it.'''<br />
<br />
<br />
=Code Examples=<br />
<br />
==Brace placement example==<br />
<br />
<pre><br />
namespace ShowMeTheBracket<br />
{<br />
public enum TTheTestEnum<br />
{<br />
ttOne, ttTwo<br />
}<br />
<br />
<br />
public class TTestMeClass<br />
{<br />
TTheTestEnum FTestVar;<br />
<br />
<br />
public TTheTestEnum Test <br />
{<br />
get <br />
{<br />
return FTestVar;<br />
}<br />
<br />
set <br />
{<br />
FTestVar = value;<br />
}<br />
}<br />
<br />
<br />
void DoSomething()<br />
{<br />
if (FTestVar == TTestEnum.ttOne) <br />
{<br />
//...stuff gets done<br />
} <br />
else <br />
{<br />
//...other stuff gets done<br />
}<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
==Variable naming example==<br />
<br />
Instead of:<br />
<br />
<pre><br />
for (int i = 1; i < num; ++i) <br />
{<br />
meetsCriteria[i] = true; <br />
}<br />
<br />
<br />
for (int i = 2; i < num / 2; ++i) <br />
{<br />
int j = i + i;<br />
<br />
<br />
while (j <= num) <br />
{<br />
meetsCriteria[j] = false;<br />
j += i;<br />
}<br />
}<br />
<br />
<br />
for (int i = 0; i < num; ++i) <br />
{<br />
if (meetsCriteria[i]) <br />
{<br />
Console.WriteLine(i + " meets criteria");<br />
}<br />
}<br />
</pre><br />
<br />
<br />
...do name variables appropriately:<br />
<br />
<pre><br />
for (int Counter1 = 1; Counter1 < num; ++Counter1) <br />
{<br />
isPrime[Counter1] = true; <br />
}<br />
<br />
<br />
for (int Counter2 = 2; Counter2 < num / 2; ++Counter2) <br />
{<br />
int factorableNumber = Counter2 + Counter2;<br />
<br />
<br />
while (factorableNumber <= num) <br />
{<br />
isPrime[factorableNumber] = false;<br />
factorableNumber += Counter2;<br />
}<br />
}<br />
<br />
<br />
for (int Counter3 = 0; Counter3 < num; ++Counter3) <br />
{<br />
if (isPrime[Counter3]) <br />
{<br />
Console.WriteLine(Counter3 + " is prime.");<br />
}<br />
}<br />
</pre><br />
<br />
'''Note:''' indexer variables should generally be called Counter1, Counter2, etc. But in cases like this where it isn't quickly obvious what is going on with those loops, it may make sense to reconsider this rule: for instance, <code>Counter1</code> and <code>Counter3</code> could be renamed to <code>PrimeCandidate</code>, and <code>Counter2</code> to <code>Factor</code> to make the code more 'self-documenting'.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Coding_Standard_and_Guidelines&diff=3162Coding Standard and Guidelines2012-09-11T20:13:24Z<p>Joejoe2010: </p>
<hr />
<div>=About the C# Coding Style Guide=<br />
<br />
'''This document may be read as a guide to writing robust and reliable C# programs.'''<br />
<br />
Notes: <br />
# Many of the rules in this document can be ''applied automatically'' to source code using the 'Uncrustify' tool that we use (<code>make uncrustify</code>)<br />
## Those rules are marked with '<font color="blue">Enforced by Uncrustify.</font>'<br />
# Many of the rules in this document can be ''checked automatically'' with the 'StyleCop' tool that we use (<code>make stylecop</code>)!<br />
## Those rules are marked with '<font color="peach">Checked by StyleCop.'</font> ''<font color="darkred">'''TODO'''</font>''<br />
# 'Uncrustify' and 'StyleCop' and how we use them with Petra are described in [[Coding Standards Tools: 'Uncrustify' and 'StyleCop']].<br />
<br />
This 'C# Coding Style Guide' was inspired by the [http://www.icsharpcode.net/TechNotes/ C# Coding Style Guide] written by Mike Krüger. This is used by the SharpDevelop programmers who work on the SharpDevelop IDE.<br />
<br />
=File Organization=<br />
<br />
==C# Sourcefiles==<br />
<br />
* Keep your classes/files short: try hard not to exceed 3.000 lines of code and never go beyond 4.000 lines of code.<br />
** Exception to that:<br />
*** Auto-generated code can ignore that rule if the generated file doesn't need to be looked at/touched by developers.<br />
* Divide your code up and make structures clearer. <br />
* Every class should go in a separate file. <br />
** Exceptions to that:<br />
*** Helper classes for the main class in the same file are allowed, but they must be private classes!<br />
*** Auto-generated code can ignore that rule if the generated file doesn't need to be looked at/touched by developers.<br />
* The file name should reflect the name of the class in the file (.cs as extension of course).<br />
** Exception to that:<br />
*** The file name of a source file can have the last part of a Namespace in it ''if'' the Namespace is nested quite deeply ''and'' <br />
the directory structure doesn't reflect that deep nesting anymore (see [[Coding_Standard_and_Guidelines#Directory_Layout|'Directory Layout']] below). Example: DataAggregates.PPartnerAddress.cs in Namespace 'Ict.Petra.Server.MPartner.'''DataAggregates'''' in directory 'U:\openpetraorg\csharp\ICT\Petra\Server\lib\MPartner'.<br />
<br />
<br />
''These conventions makes things much easier to read and find.''<br />
<br />
==Directory Layout==<br />
<br />
* Create a directory for every namespace. Example: for Namespace 'Ict.Petra.Server.App.Core' use 'U:\delphi.net\ICT\Petra\Server\app\' as the path (do not use the Namespace name with dots for directory names).<br />
** Exceptions to that:<br />
*** Additional directories might be placed inbetween parts of the Namespace ''if'' that benefits the directory structure ''and'' an agreed rule when to do that is followed. Example: Namespace 'Ict.Petra.Server.MPartner.DataAggregates' resides in directory 'U:\delphi.net\ICT\Petra\Server\'''lib'''\MPartner'. Note the 'lib' directory, which is inserted.<br />
*** ''If'' a Namespace is nested quite deeply, we can opt to have the directory structure ''not'' reflecting that deep nesting. In that case, the last part of a Namespace should then be part of the file name of a Class (see [[Coding_Standard_and_Guidelines#C.23_Sourcefiles |'C# Sourcefiles']] above).<br />
<br />
<br />
See also [['Explanation of Directory Structure and Rules']] for more detailed information!<br />
<br />
<br />
''These conventions make it easier to map namespaces to the directory layout.''<br />
<br />
=Indentation=<br />
<br />
==White Spaces==<br />
For code indentation, two standards exist in the world of programming: indendation with spaces and indendation with tabs. Some programmers prefer spaces, others prefer tabs.<br />
<br />
Here, we define the space character as the standard indentation character.<br />
Specifically, '''we indent everything with four spaces''' - <font color="blue">Enforced by Uncrustify</font>. This applies for the indendation from column 1 to the indendation level of the current code and also to any further indendations from there.<br />
<br />
By using spaces, not tabs, we can ensure that our code is indented identically for every developer and in every editor. If we used tabs, the indentation could vary.<br />
<br />
'''Don't use tabs for indentation - use spaces!''' <font color="blue">Enforced by Uncrustify.</font><br />
<br />
==Wrapping Lines==<br />
<br />
When an expression will not fit on a single line, break it up before it reaches more than '''150''' characters. <font color="blue">Enforced by Uncrustify.</font> You might want to break it up before that for readability.<br />
<br />
Follow these general principles when breaking up a line: <br />
<br />
*Break after a comma.<br />
*Break after an operator.<br />
*Prefer higher-level breaks to lower-level breaks.<br />
*Indent the new line at the standard indentation level, or align the new line with the beginning of the expression at the same level on the previous line.<br />
<br />
Example of breaking up method calls:<br />
<pre><br />
LongMethodCall(expr1, expr2,<br />
<br />
expr3, expr4, expr5); // indented at the standard indentation level<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
LongMethodCall(expr1, expr2,<br />
<br />
expr3, expr4, expr5); // aligned with the beginning of the expression on the previous line<br />
</pre><br />
<br />
The first is preferred because it results in uniformly formatted code, but if indenting with the second method makes for better reading in a specific case then use the second method.<br />
<br />
<br />
Examples of breaking an arithmetic expression:<br />
<br />
PREFER:<br />
<br />
<pre><br />
var = a * b / (c - g + f) + <br />
<br />
4 * z;<br />
</pre><br />
<br />
BAD STYLE – AVOID:<br />
<pre><br />
var = a * b / (c - g + <br />
<br />
f) + 4 * z;<br />
</pre><br />
<br />
The first is preferred, since the break occurs outside the paranthesized expression (higher level rule).<br />
<br />
<br />
=Comments=<br />
<br />
All comments must be written in English.<br />
<br />
==Block Comments==<br />
<br />
Block comments for the purpose of describing Classes, Methods, etc. should be avoided. Instead, use of the <code>///</code> comments to give C# standard descriptions is recommended (see [[Coding_Standard_and_Guidelines#Documentation_Comments | 'Documentation Comments']] below). <br />
<br />
If you wish to use block comments inside Methods, Classes, etc. you should use the following style:<br />
<br />
<pre><br />
/* The following Algorithm does bla bla bla<br />
<br />
<nowiki> * and is adapted from the well-known blah blah Algorithm.</nowiki><br />
<br />
<nowiki> * An example of this Algorithm can be found on http://www.blahalgorithms.org</nowiki><br />
<br />
<nowiki> *</nowiki>/<br />
</pre><br />
<br />
...as this will set off the block visually from code for the (human) reader. <br />
<br />
Block comments may be useful in rare cases, refer to the TechNote [http://www.icsharpcode.net/TechNotes/Commenting20020413.pdf 'The fine Art of Commenting'] for an example.<br />
<br />
''As a general rule of thumb, the length of a comment should not overly exceed the length of the code it explains as this is an indication of too complicated (and potentially buggy) code.''<br />
<br />
''For commenting out sections of code, use the 'Single Line Comments' (despite their name) to distinguish better between code that has comments attached and code that is commented out.''<br />
<br />
==Single Line Comments==<br />
<br />
Developers should use the <code>//</code> (two forward slahes) comment style to "comment out" code (SharpDevelop has a shotcut key for it, Alt+/). ''It may be used for commenting out sections of code too.''<br />
<br />
Note on using StyleCop: because we will use StyleCop, you should rather use <code>////</code> (four forward slashes) instead of <code>//</code> when commenting out ''single'' lines of code. This helps the tool to not confuse it with a single line comment (which is not commented out code). (Refers to StyleCop Rule SA1512: SingleLineCommentsMustNotBeFollowedByBlankLine.)<br />
<br />
<br />
Single line code comments must be indented to the indent level when they are used for code documentation. Commented out code should be commented out so that the <code>//</code> (two slashes) start in column 1. This is to enhance the visibility of commented out code.<br />
<br />
==Documentation Comments==<br />
<br />
In the .NET framework, Microsoft has introduced a documentation generation system based on XML comments. These comments are formally single line C# comments containing XML tags. They follow this pattern for single line comments:<br />
<br />
<pre><br />
/// <summary><br />
<br />
/// This class...<br />
<br />
/// </summary><br />
</pre><br />
<br />
Multiline XML comments follow this pattern:<br />
<br />
<pre><br />
/// <exception cref=”BogusException”><br />
<br />
/// This exception gets thrown as soon as a<br />
<br />
/// Bogus flag gets set.<br />
<br />
/// </exception><br />
</pre><br />
<br />
All lines must be preceded by <code>///</code> (three slashes) to be accepted as XML comment lines.<br />
<br />
Tags fall into two categories:<br />
<br />
* Documentation items<br />
* Formatting/Referencing<br />
<br />
The first category contains tags like <code><summary></code>, <code><param></code> or <code><exception></code>. <br />
These tags represent the elements of a program's API which must be documented for the program to be useful to other programmers. <br />
They usually have attributes such as <code>name</code> or <code>cref</code> (as demonstrated in the multi line example above) and are <br />
checked by the compiler, so they should be valid.<br />
<br />
The latter category governs the layout of the documentation, using tags such as <code><nowiki><code></nowiki></code>, <code><list></code> or <code><para></code>.<br />
<br />
For a fuller explanation of XML comments see [['CSharp In-Code Documentation with MS XML Tags']]. <br />
For information on how to produce API-style documentation for C# Projects whose .cs files contain XML Comment Tags, see [['How to produce CSharp API Documentation']].<br />
<br />
For information on commenting best practice and further issues related to commenting, see the TechNote [http://www.icsharpcode.net/TechNotes/Commenting20020413.pdf 'The fine Art of Commenting'].<br />
<br />
==End Comments==<br />
<br />
By 'End Comments' we mean adding a single-line comment after the closing curly brace "}" of a code block to explain what section of code the closing curly braces ends. <br />
<br />
We decided this is unnecessary if this information is obvious. In other words, use 'End Comments' only when the meaning of the closing curly brace "}" of a code block is not immediately obvious due to either a very long block, or in the case of many nested blocks.<br />
<br />
=Declarations=<br />
<br />
==Number of Declarations per Line==<br />
<br />
Only one declaration per line is allowed. This greatly enhances readabiliy and it encourages commenting. <br />
<br />
GOOD STYLE: <br />
<br />
<pre><br />
int Level; // indentation level<br />
int Size; // size of table<br />
</pre><br />
<br />
Do not put more than one variable or variables of different types on the same line when declaring them. <br />
<br />
BAD STYLE - AVOID: <br />
<br />
<pre><br />
int Var1, Var2; // What is 'Var1'? What does 'Var2' stand for?<br />
</pre><br />
<br />
Declarations should be followed by an empty line so that they are visually set apart from the rest of the source code. <font color="blue">Enforced by Uncrustify.</font><br />
<br />
The above example also demonstrates the drawbacks of non-obvious variable names. <br />
<br />
''Be clear when naming variables.'' Using self-explanatory variable names such as <code>IndentLevel</code> eradicates the need for making explanatory comments.<br />
<br />
==Initialization==<br />
<br />
Try to initialize local variables as soon as they are declared. <br />
<br />
For example:<br />
<br />
<pre><br />
string Name = myObject.Name;<br />
int Val = time.Hours;<br />
</pre><br />
<br />
Initialisations should be followed by an empty line so that they are visually set apart from the rest of the source code. <font color="blue">Enforced by Uncrustify if the initialisations are part of declarations.</font><br />
<br />
'''Note:''' when initializing a Dialog/Modal Form (by using .ShowDialog instead of .Show), use the following construct to be sure the Form is released from memory when it is closed:<br />
<br />
<pre><br />
using (TOpenFileDialog openFileDialog = new TOpenFileDialog()) <br />
{<br />
openFileDialog.ShowDialog();<br />
...<br />
} <font color="gray">// .NET will release openFileDialog automatically, so we can't forget about it!</font><br />
</pre><br />
<br />
'''Background:''' forms shown with .ShowDialog are not released from memory, but kept in memory so the caller can call methods after the Form is closed to retrieve parameters. Therefore, you can forget to release the form from memory later.<br />
<br />
==Class, Interface and Namespace Declarations==<br />
<br />
For C# classes, interfaces and namespaces, the following formatting rules should be followed:<br />
<br />
* Braces<br />
** The opening brace "{" appears in the next line after the declaration statement.<br />
** The closing brace "}" starts a line by itself indented to match its corresponding opening brace.<br />
** The opening brace "{" and the closing brace "}" should be on the same indentation level as the code block construct that owns it.<br />
* Spacing<br />
** A single space character should be placed on each side of the colon that follows the class name. <br />
** If there is a list of types/interfaces that the class inherits from, the items should be separated by a comma followed by a space character.<br />
* Code block separation<br />
** An empty line should preceed and succeed each class, interface or namespace block.<br />
*** Exceptions:<br />
**** if a class, interface or namespace block begins immediately after another class, interface or namespace block has been started with an opening brace "{": then no empty line should be inserted.<br />
**** if a class, interface or namespace block ends and another enclosing code block also ends immediately after the closing brace "}": then no empty line should be inserted.<br />
<br />
For example:<br />
<br />
<pre><br />
namespace MyNamespace<br />
'''{''' <font color="gray">// no empty line</font><br />
class TMySample : TMyClass, IMyInterface<br />
'''{'''<br />
void DoSomething()<br />
'''{'''<br />
<br />
'''}'''<br />
<br />
void DoAnotherThing()<br />
'''{'''<br />
<br />
'''}'''<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
class TMyOtherSample : TMySample, IMyOtherInterface<br />
'''{'''<br />
void DoSomething()<br />
'''{'''<br />
<br />
'''}'''<br />
<br />
void DoAnotherThing()<br />
'''{'''<br />
<br />
'''}'''<br />
'''}''' <font color="gray">// no empty line</font><br />
'''}'''<br />
</pre><br />
<br />
For another brace placement example look at section 'Code Examples - Brace placement example'.<br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Method Declarations==<br />
<br />
For method declarations the following formatting rules should be followed:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** No space should be put between a method name and the opening parenthesis "(" that starts its parameter list.<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
<br />
For example:<br />
<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
public MySample'''('''int AMyInt''')'''<br />
'''{'''<br />
this.FMyInt = AMyInt;<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
void Inc'''()'''<br />
'''{'''<br />
++FMyInt;<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Property, Indexer and Event Declarations==<br />
<br />
For properties, indexers and events, the following formatting rules should be followed:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied. <font color="blue">Enforced by Uncrustify: all rules, except for 'opening curly bracket must be on a new line' (Uncrustify can't enforce that for EventHandlers).</font><br />
* Spacing<br />
** For properties where both 'get' and 'set' blocks are present, an empty line should be placed between the 'get' block and the 'set' block.<br />
** For event handlers where both 'add' and 'remove' blocks are present, an empty line should be placed between the 'add' block and the 'remove' block.<br />
** For indexers, use no space between 'this' and '['. <font color="blue">Enforced by Uncrustify.</font><br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the getter/setter or adder/remover!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
public int Amount <br />
'''{'''<br />
get <br />
'''{'''<br />
...<br />
'''}'''<br />
<font color="gray">// empty line goes here</font> <br />
set <br />
'''{'''<br />
...<br />
<br />
'''}'''<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
public EventHandler MyCustomEventHandler<br />
'''{'''<br />
add <br />
'''{'''<br />
...<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
remove <br />
'''{'''<br />
...<br />
'''}'''<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
public this'''['''string index]<br />
'''{'''<br />
get;<br />
<font color="gray">// empty line goes here</font> <br />
set;<br />
'''}'''<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
==Simple Statements==<br />
<br />
Each code line should contain ''only one statement''.<br />
<br />
==Return Statements==<br />
<br />
A <code>return</code> statement should not use outermost parentheses. <font color="blue">Enforced by Uncrustify.</font><br />
<br />
GOOD STYLE : <br />
<br />
<code>return (n * (n + 1)) / 2;</code><br />
<br />
BAD STYLE - AVOID: <br />
<br />
<code>return '''('''(n * (n + 1)) / 2''')''';</code><br />
<br />
<br />
== Statements With Multiple Conditions ==<br />
In a situation where more than one condition is specified (eg. in <code>if</code>, <code>for</code> or <code>do-while</code>-statments), please follow these guidelines:<br />
* Place each condition on a separate line.<br />
* Place the ''&&'' and ''||'' that connects the conditions on the same line as the next condition. (See example.)<br />
* If you have a very complicated condition statement, try to align the different conditions. The goal is to make the condition more readable in the end, so you may use your discretion here as well.<br />
<br />
Example:<br />
<pre><br />
if (((''condition1)''<br />
&& (''condition2'')<br />
|| (''condition3''<br />
&& ''condition4''))<br />
(&& !''condition5''))<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
==If, if-else, if else-if else Statements==<br />
<br />
<code>if, if-else</code> and <code>if else-if else</code> statements should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "if" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the ensuing code statement(s), or between the code statement(s) and the closing bracket ")".<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the condition!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
if '''('''condition''')'''<br />
{<br />
DoSomething();<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
if '''('''condition''')''' <br />
{<br />
DoSomething();<br />
...<br />
} <br />
else <br />
{<br />
DoSomethingOther();<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
if '''('''condition''')'''<br />
{<br />
DoSomething();<br />
...<br />
} <br />
else if '''('''condition''')'''<br />
{<br />
DoSomethingOther();<br />
...<br />
} <br />
else <br />
{<br />
DoSomethingOtherAgain();<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==For / Foreach Statements==<br />
<br />
<code>For</code> and <code>foreach</code> statements should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "for"/"foreach" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the ensuing code statement(s), or between the code statement(s) and the closing bracket ")".<br />
** <code>for</code> only<br />
*** Space characters should be put after the semicolon ";" which separates the initialisation, condition and execution code parts (contained inside the brackets).<br />
*** Inter-term spacing rules should be applied (see [[Petra_Coding_Conventions_for_C_Sharp#Inter-term_spacing | 'Inter-term spacing']] below).<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the loop!<br />
<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
for '''('''int Counter = 0; Counter < 5; ++Counter''')''' <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
foreach '''('''int MyIterator in IntList''')''' <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==While/Do-While Statements==<br />
<br />
<code>while/do</code> statements should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "while" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the condition, or between the condition and the closing bracket ")".<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the loop!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
while '''('''condition''')'''<br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
An empty while should have the following form:<br />
<br />
<pre><br />
while '''(condition)'''<br />
{<br />
;<br />
}<br />
</pre><br />
<br />
A do-while statement should have the following form:<br />
<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
do <br />
{<br />
...<br />
} while '''('''condition''')''';<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Switch Statements==<br />
<br />
A <code>switch</code> statement should follow the following formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Spacing<br />
** A space character should be put between "switch" and the opening parenthesis "(".<br />
** No space character should be put between the opening bracket "(" and the condition, or between the condition and the closing bracket ")".<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
** An empty line should succeed each 'break;' statement.<br />
*** Exception: no empty line after the 'break;' statement in the 'default' block.<br />
* Other line breaks:<br />
** the <code>case ''x'':</code> condition and its ensuing statement(s), as well as the <code>default:</code> line and its statement(s), should be separated by a line break.<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
switch '''('''condition''')'''<br />
{<br />
case A: <font color="gray">// line break here</font><br />
...<br />
break;<br />
<font color="gray">// empty line goes here</font><br />
case B: <font color="gray">// line break here</font><br />
...<br />
break;<br />
<font color="gray">// empty line goes here</font><br />
default: <font color="gray">// line break here</font><br />
...<br />
break; <font color="gray">// NO empty line to follow!</font><br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify: all rules</font><br />
<br />
==Try-Catch Statements==<br />
<br />
<code>try-catch</code> statements should follow these formatting rules:<br />
<br />
* Braces<br />
** Class braces placement rules should be applied.<br />
* Code block separation<br />
** An empty line should preceed and succeed the statement block (the same applies to other statements that appear as blocks of code).<br />
* '''No one-liners'''<br />
** ''Always'' use braces "{" and "}" on their own code lines even if there is only one statement in the respective try/except/finally section!<br />
<br />
For example:<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
try <br />
{<br />
...<br />
} <br />
catch (Exception) <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
<font color="gray">// empty line goes here</font><br />
try <br />
{<br />
...<br />
} <br />
catch (ApplicationException ae) <br />
{<br />
...<br />
}<br />
catch (Exception e) <br />
{<br />
...<br />
} <br />
finally <br />
{<br />
...<br />
}<br />
<font color="gray">// empty line goes here</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify -</font> all rules, except for: <br />
* 'Code block separation' (Uncrustify can't enforce that);<br />
* 'Opening curly bracket must be on new line' for the 'finally' statement (Uncrustify's rule to enforce that doesn't work).<br />
<br />
=White Space=<br />
<br />
==Blank Lines==<br />
<br />
Blank lines improve readability by setting off blocks of code which are in themselves logically related.<br />
<br />
''Two blank lines'' should always be used between:<br />
* Logical sections of a source file.<br />
* Class and interface definitions (try one class/interface per file to prevent this case).<br />
<br />
''One blank line'' should always be used between:<br />
* Methods. <font color="blue">Enforced by Uncrustify</font><br />
* Properties.<br />
* Code blocks (<code>if</code> statements, <code>for/foreach</code> loops and <code>while</code> loops, <code>switch</code> blocks and <code>try/catch</code> blocks). <font color="blue">Enforced by Uncrustify</font><br />
* Local variables in a method and the first statement in the method. <font color="blue">Enforced by Uncrustify (although not always reliable)</font><br />
* Logical sections inside a method to improve readability.<br />
<br />
Blank lines should be indented to the correct indent level instead of leaving them blank or, even worse, using another indentation level. This makes the insertion of new statements in these lines much easier.<br />
<br />
==Inter-term spacing==<br />
<br />
There should be a single space after a comma or a semicolon.<br />
<br />
For example:<br />
<pre><br />
TestMethod(a, b, c); <font color="gray">// don't use : TestMethod(a,b,c)</font><br />
</pre><br />
<br />
Single spaces surround operators (except unary operators like increment (<code>++</code>) or logical not (<code>!</code>)).<br />
<br />
For example:<br />
<pre><br />
a = b; <font color="gray">// don't use a=b;</font><br />
<br />
for (int Counter = 0; Counter < 10; ++Counter) <font color="gray">// don't use 'for (int i=0; i<10; ++i)' <br />
// or 'for(int i=0;i<10;++i)'</font><br />
</pre><br />
<br />
<font color="blue">Enforced by Uncrustify:</font> all rules.<br />
<br />
<br />
=Naming Conventions=<br />
<br />
All names of all code elements must be written in English.<br />
<br />
==Capitalization Styles==<br />
<br />
===Pascal Casing===<br />
<br />
This convention capitalizes the first character of each word (as in '''T'''est'''C'''ounter).<br />
<br />
===Camel Casing===<br />
<br />
This convention capitalizes the first character of each word except the first word (as in '''t'''est'''C'''ounter).<br />
<br />
===All-Uppercase===<br />
<br />
All-uppercase capitalizes all characters of a word. Use all-uppercase only for ''constant identifiers''. (For non-constant identifiers that are commonly used in all-uppercase (eg. URL, PI) use Pascal Casing instead.)<br />
<br />
<br />
==Naming Guidelines==<br />
<br />
Naming according to the guidelines for 'Hungarian Notation' is considered bad practice.<br />
<br />
Hungarian Notation is a defined set of prefixes and postfixes which are applied to names to reflect the type of the variable. This style of naming was widely used <br />
in early Windows programming, but is now obsolete or at least should be considered deprecated. Using Hungarian Notation is not allowed if you follow this guide.<br />
<br />
''Remember: a good variable name describes the semantic not the type.''<br />
<br />
An exception to this rule is GUI code. All fields and variable names that contain GUI elements like ''Button'' should be prefixed with their respective [[GUI_controls_prefixes|GUI control prefix]].<br />
<br />
For example:<br />
<pre><br />
System.Windows.Forms.Button '''btn'''Cancel;<br />
System.Windows.Forms.TextBox '''txt'''Name;<br />
</pre><br />
<br />
===Namespace Naming Guidelines===<br />
* Namespace names should be nouns or noun phrases.<br />
* Use Pascal Casing.<br />
* Name prefix: none.<br />
<br />
===Class Naming Guidelines===<br />
<br />
* Class names should be nouns or noun phrases.<br />
* Use Pascal Casing.<br />
* Name prefix: '<code>T</code>' (stands for '''T'''ype).<br />
** Classes that are derived from <code>System.Windows.Form</code> should use the prefix <code>TFrm</code> instead.<br />
<br />
For example:<br />
<pre><br />
public class TConnection<br />
{<br />
...<br />
}<br />
<br />
<br />
public class TFrmAboutPetra<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
===Interface Naming Guidelines===<br />
<br />
* Name interfaces with nouns or noun phrases or adjectives describing behaviour.<br />
* Use Pascal Casing.<br />
* Name prefix: '<code>I</code>' (stands for '''I'''nterface).<br />
<br />
For example:<br />
<pre><br />
public interface IComponent<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
===Exception Naming Guidelines===<br />
<br />
* Name Exceptions with nouns or noun phrases.<br />
* Use Pascal Casing.<br />
* Name prefix: '<code>E</code>' (stands for '''E'''xception).<br />
* Name suffix: '<code>Exception</code>'. (The suffix is a recommended convention of Microsoft and considered good style by many C# programmers.)<br />
<br />
For example:<br />
<pre><br />
public class EConnectionException<br />
{<br />
...<br />
}<br />
</pre><br />
<br />
===Enum Naming Guidelines===<br />
<br />
* Name<br />
** Use singular names for enum ''types''. Pascal Casing.<br />
** Use singular names for enum ''values''. camelCasing.<br />
* Prefixes<br />
** Enum type name: 'T'. It is to be followed by a capital letter (first character of the enum name). Enum types should also include the word <code>Enum</code> as a suffix to the name.<br />
** Enum values: concatenate the letters of each word that make up the enum type name and prefix those in lower case to the enum value.<br />
<br />
<br />
For example:<br />
<pre><br />
public enum '''T'''ModuleSwitchEnum<br />
{<br />
'''ms'''None, '''ms'''Partner, '''ms'''Personnel, '''ms'''Finance<br />
}<br />
<br />
<br />
public enum '''T'''UIConnectorTypeEnum<br />
{ <br />
'''uict'''PartnerKey, '''uict'''LocationKey, '''uict'''NewPartner<br />
}<br />
</pre><br />
<br />
===Event Names===<br />
<br />
Event Handlers:<br />
* Name event handlers with the <code>EventHandler</code> suffix.<br />
* Name event handlers that have a timeline concept of pre and post using the present and past tense (eg. <code>...Chang'''ing'''EventHandler</code> and <code>...Chang'''ed'''EventHandler</code>).<br />
* For generic event handlers use two parameters named <code>sender</code> and <code>e</code>.<br />
* Use Pascal Casing.<br />
* Prefix: 'T' followed with a capital letter (first character of the event handler).<br />
<br />
Event Arguments:<br />
* Name event argument classes with the <code>EventArgs</code> suffix.<br />
* Consider naming events using a verb.<br />
* Use Pascal Casing.<br />
* Prefix: 'T' followed with a capital letter (first character of the event argument class).<br />
<br />
===Property Names===<br />
<br />
* Name properties using nouns or noun phrases.<br />
* Consider naming a property with the same name as it’s Type.<br />
* Use Pascal Casing.<br />
* Prefix: none!<br />
<br />
===Method Names===<br />
<br />
* Name methods with verbs or verb phrases.<br />
* Use Pascal Casing.<br />
* Prefix: none!<br />
<br />
===Argument Names===<br />
'Arguments' are parameters that are passed to a method. They are used much like private variables of a method.<br />
<br />
* Use accurate and descriptive names that are sufficient to determine the argument's meaning and it’s type.<br />
* Use Pascal Casing.<br />
* Prefix: 'A' (stands for '''A'''rgument) followed by a capital letter (first character of the argument name).<br />
<br />
===Field Names===<br />
'Fields' are private variables of a class.<br />
<br />
* Use accurate and descriptive names that are sufficient to determine the field's meaning and it’s type.<br />
* Use Pascal Casing.<br />
* Prefix: 'F' (stands for '''F'''ield) followed by a capital letter (first character of the field name).<br />
<br />
=== Variable Names===<br />
'Variables' are private variables of a method.<br />
<br />
* Use accurate and descriptive names that should be sufficient to determine the variable's meaning and it’s type.<br />
* Boolean variables: use prefixes like 'Is...', 'Has...' or 'Can...'. and names that imply true or false. For example: 'FileFound', 'Done', 'Success' or with their prefixes: 'IsFileFound', 'IsDone', 'IsSuccess'; don't try 'Is''Name''' that doesn't make sense at all.<br />
* Loop counters: use ''Counter'' as the standard name for these kinds of variables as they are used in loops to serve as counters, indexes, or the like. Whenever you have a nested loop that also uses a counter, add numbers to the end to indicate the level of the counter.<br />
* Temporary variables: should be called ''Tmp''. Many times you need to use a variables with no specific meaning - just a quick place-holder or something that will have but a moment of usage. Whenever you need more than one temporary variable in a particular context, you should consider using self-explanatory names for these variables instead.<br />
* Use Pascal Casing.<br />
* Prefix: none!<br />
<br />
===Constant Names===<br />
<br />
* Name constant fields with nouns, noun phrases or abbreviations for nouns. If they consist of more than one word, separate the words with underscore characters (<code>_</code>).<br />
* Use ALL-UPPERCASE<br />
* Prefix: none!<br />
<br />
For example:<br />
<pre><br />
public class TMath<br />
{<br />
public const string LONG_CONST_NAME = ...<br />
public const double PI = 3.14...<br />
public double Pi = 3.14... <font color="gray">// this is a variable and not a constant, <br />
// so don't use PI</font><br />
}<br />
</pre><br />
<br />
===Naming and Capitalisation Summary===<br />
<br />
{| width="643" border="1" cellpadding="4"<br />
<br />
|- valign="top"<br />
! width="88" |<br />
Type<br />
! width="80" |<br />
Prefix<br />
! width="80" |<br />
Case<br />
! width="400" |<br />
Notes<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Namespaces<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Classes / Structs<br />
| width="80" |<br />
T<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Special prefix: <code>TFrm</code> if derived from <code>System.Windows.Form</code>.<br />
<br />
|-<br />
| Interfaces<br />
| I<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Exception Classes<br />
| width="80" |<br />
E<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Suffix: <code>Exception</code>.<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Enum Types<br />
| width="80" |<br />
T<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Suffix: <code>Enum</code><br />
<br />
|- valign="top"<br />
| width="120" |<br />
Enum Values<br />
| width="80" |<br />
see Notes<br />
! width="80" |<br />
Camel Casing<br />
| width="400" |<br />
Prefix: Concatenate the letters of each word that make up the enum type name and prefix those in lower case to the enum value.<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Event Handlers / Event Arguments<br />
| width="80" |<br />
T<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
Suffix for Event Handlers: <code>EventHandler</code>. Suffix for Event Arguments: <code>EventArgs</code>.<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Properties<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Methods<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Arguments<br />
| width="80" |<br />
A<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Fields<br />
| width="80" |<br />
F<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Local variables<br />
| width="80" |<br />
none<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Global Variables<br />
| width="80" |<br />
G<br />
! width="80" |<br />
Pascal Casing<br />
| width="400" |<br />
<br />
|- valign="top"<br />
| width="120" |<br />
Constants<br />
| width="80" |<br />
none<br />
! width="80" |<br />
All-Uppercase<br />
| width="400" |<br />
<br />
|}<br />
<br />
=Programming Practices=<br />
<br />
==Visibility==<br />
<br />
===Generally===<br />
Give a class, interface, event handler, method, field always the ''least possible visibility''.<br />
This means that you should consider giving it <code>private</code> visibility, and only if that is not enough increase the visibility - but only as much as is needed.<br />
<br />
===Fields===<br />
Do not make fields public - always make them private. Create properties for fields instead. You may use public static fields (or consts) as an exception to this rule, but be very careful with it.<br />
<br />
''Having appropriate visibility ensures proper use of classes by every programmer and is kind of 'self-documenting' in the way that it tells how the class can be used.''<br />
<br />
==No 'Magic' Numbers==<br />
<br />
Do not use 'magic' numbers, i.e. place constant numerical values directly into the source code. Replacing these lateron in case of changes <br />
(say, your application can now handle 3540 users instead of the 427 users hardcoded into your code in 50 lines scattered troughout your 25000 lines of code) is error-prone and unproductive. <br />
Instead declare a const which contains the number:<br />
<br />
<pre><br />
public class TMyMath<br />
{<br />
public const double PI = 3.14... <br />
}<br />
</pre><br />
<br />
== SQL Queries ==<br />
<br />
All SQL keywords should be in capital letters. <br /><br />
<br />
The main query command keyword (e.g. ''SELECT'', ''UPDATE'', ''INSERT'', etc.) should be on the indentation base, and the rest of the text belonging to that query should be indented.<br />
<br />
Indentation for SQL queries should be four spaces (like for the rest of the source code). <br /><br />
<br />
If the list of columns or tables become to long, it should be split over more than one line. If this is done, the lists should be aligned.<br />
<br />
Every keyword that signifies a new 'section' of the query should be on a new line, with everything belonging to that section indented. (See example.) <br /><br />
<br />
The keywords ''AND ''and ''OR'' should also be on a new line, and indented. It is also recommended to try and align the conditions. To do this, simply add a few spaces after the ''AND'' and ''OR'' keywords until the condition is aligned to the one in the previous line.<br />
<br />
<br /> Cumulative examples: <br /><br />
<br />
<pre><br />
SELECT a_column_1_i, a_column_2_l,<br />
a_column_3_i, a_column_4_n<br />
FROM a_table<br />
WHERE a_column_1_i > 5<br />
AND a_column_2_l = TRUE<br />
OR a_column_4_n = 10<br />
ORDER BY a_column_3_i;<br />
<br />
SELECT surname, forenames<br />
FROM employee<br />
WHERE depno =<br />
(SELECT depno<br />
FROM employee<br />
WHERE empno = 16)<br />
AND empno != 16<br />
<br />
DELETE FROM a_whatever<br />
WHERE mmm<br />
AND mmm<br />
OR mmm<br />
<br />
UPDATE a_whatever<br />
SET (mm1 = 'khasg kvjshdfbv jszhdvb kszjhvb ksjvhb asj,f abv,jfhv badfj',<br />
mm2 = (SELECT id<br />
FROM something<br />
WHERE something else)<br />
mm3, mm4)<br />
WHERE mmm<br />
AND mmm;<br />
</pre><br />
<br />
<br /> Table aliases can be named by using the first letter of every word in the table name (excluding unnecessary things like prefixes). If the same table is used twice in the query with two aliases, simply add a number at the end of the alias name to distinguish them, or name them in such a way as to separate them logically. <br /><br />
<br />
<span style="font-style: italic;">Never use </span>''SELECT * ''<span style="font-style: italic;">for a query in Petra!</span> This can cause a lot of data transfer! By not using it you can prevent errors, and also make life much easier for things like Typed DataSets.<br />
<br />
= Use Discretion! =<br />
<br />
'''These standards were set up to help us as programmers to better maintain the code. Please try to comply to these standards.''' <br />
<br />
'''We realise that there are times when the standards would actually have a negative effect, or maybe where the standards are not entirely clear. In these situations, please use your discretion to come up with a suitable alternative, and discuss it with the rest of the team before you use it.'''<br />
<br />
<br />
=Code Examples=<br />
<br />
==Brace placement example==<br />
<br />
<pre><br />
namespace ShowMeTheBracket<br />
{<br />
public enum TTheTestEnum<br />
{<br />
ttOne, ttTwo<br />
}<br />
<br />
<br />
public class TTestMeClass<br />
{<br />
TTheTestEnum FTestVar;<br />
<br />
<br />
public TTheTestEnum Test <br />
{<br />
get <br />
{<br />
return FTestVar;<br />
}<br />
<br />
set <br />
{<br />
FTestVar = value;<br />
}<br />
}<br />
<br />
<br />
void DoSomething()<br />
{<br />
if (FTestVar == TTestEnum.ttOne) <br />
{<br />
//...stuff gets done<br />
} <br />
else <br />
{<br />
//...other stuff gets done<br />
}<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
==Variable naming example==<br />
<br />
Instead of:<br />
<br />
<pre><br />
for (int i = 1; i < num; ++i) <br />
{<br />
meetsCriteria[i] = true; <br />
}<br />
<br />
<br />
for (int i = 2; i < num / 2; ++i) <br />
{<br />
int j = i + i;<br />
<br />
<br />
while (j <= num) <br />
{<br />
meetsCriteria[j] = false;<br />
j += i;<br />
}<br />
}<br />
<br />
<br />
for (int i = 0; i < num; ++i) <br />
{<br />
if (meetsCriteria[i]) <br />
{<br />
Console.WriteLine(i + " meets criteria");<br />
}<br />
}<br />
</pre><br />
<br />
<br />
...do name variables appropriately:<br />
<br />
<pre><br />
for (int Counter1 = 1; Counter1 < num; ++Counter1) <br />
{<br />
isPrime[Counter1] = true; <br />
}<br />
<br />
<br />
for (int Counter2 = 2; Counter2 < num / 2; ++Counter2) <br />
{<br />
int factorableNumber = Counter2 + Counter2;<br />
<br />
<br />
while (factorableNumber <= num) <br />
{<br />
isPrime[factorableNumber] = false;<br />
factorableNumber += Counter2;<br />
}<br />
}<br />
<br />
<br />
for (int Counter3 = 0; Counter3 < num; ++Counter3) <br />
{<br />
if (isPrime[Counter3]) <br />
{<br />
Console.WriteLine(Counter3 + " is prime.");<br />
}<br />
}<br />
</pre><br />
<br />
'''Note:''' indexer variables should generally be called Counter1, Counter2, etc. But in cases like this where it isn't quickly obvious what is going on with those loops, it may make sense to reconsider this rule: for instance, <code>Counter1</code> and <code>Counter3</code> could be renamed to <code>PrimeCandidate</code>, and <code>Counter2</code> to <code>Factor</code> to make the code more 'self-documenting'.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3129Translation documentation for Developers2012-08-09T04:08:03Z<p>Joejoe2010: /* Testing a translation */</p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Testing a translation =<br />
We provide a Nightly Build of OpenPetra. This integrates the changes on launchpad that has been made on the last 24 hours.<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.<br />
(There is a branch on bazaar that gets the translations once a day from launchpad. You can find it [https://code.launchpad.net/~jomammele/openpetraorg/translationfiles here].)<br />
<br />
= Update launchpad template =<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= Reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3128Translation documentation for Developers2012-08-09T04:07:31Z<p>Joejoe2010: </p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Testing a translation =<br />
We provide a Nightly Build of OpenPetra. This integrates the changes on launchpad that has been made on the last 24 hours.<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.<br />
(There is a branch on bazaar that gets the translations once a day from launchpad. You can find it [https://code.launchpad.net/~jomammele/openpetraorg/translationfiles here].)<br />
<br />
<br />
= Update launchpad template =<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= Reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3127Translation documentation for Developers2012-08-09T04:01:00Z<p>Joejoe2010: /* reviewing the launchpad template */</p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Synchronising Launchpad with version in bazaar =<br />
== Automatically ==<br />
We have a [http://ci-win.solidcharity.com/job/OpenPetraBuildWin Jenkins build-Server] that gets once a day the translations changed in the last 24 hours, integrates them into trunk and builds trunk. By this you can get on the next day an openpetra-setupfile that includes all the translations you made. <br />
(There is a branch on bazaar that gets the translations once a day from launchpad. You can find it [https://code.launchpad.net/~jomammele/openpetraorg/translationfiles here].)<br />
<br />
== Manually ==<br />
(Not needed any more)<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to get the latest translations into the official packaged version, and to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= Reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]<br />
<br />
= Testing a translation =<br />
We provide a Nightly Build of OpenPetra. This provides the changes on launchpad that has been made on the day before.<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3126Translation documentation for Developers2012-08-09T04:00:35Z<p>Joejoe2010: /* Automatically */</p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Synchronising Launchpad with version in bazaar =<br />
== Automatically ==<br />
We have a [http://ci-win.solidcharity.com/job/OpenPetraBuildWin Jenkins build-Server] that gets once a day the translations changed in the last 24 hours, integrates them into trunk and builds trunk. By this you can get on the next day an openpetra-setupfile that includes all the translations you made. <br />
(There is a branch on bazaar that gets the translations once a day from launchpad. You can find it [https://code.launchpad.net/~jomammele/openpetraorg/translationfiles here].)<br />
<br />
== Manually ==<br />
(Not needed any more)<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to get the latest translations into the official packaged version, and to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]<br />
<br />
= Testing a translation =<br />
We provide a Nightly Build of OpenPetra. This provides the changes on launchpad that has been made on the day before.<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3125Translation documentation for Developers2012-08-09T03:59:41Z<p>Joejoe2010: /* Synchronising Launchpad with version in bazaar */</p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Synchronising Launchpad with version in bazaar =<br />
== Automatically ==<br />
We have a [http://ci-win.solidcharity.com/job/OpenPetraBuildWin Jenkins build-Server] that gets once a day the translations changed in the last 24 hours, integrates them into trunk and builds trunk. By this you can get on the next day the translations you made. <br />
(There is a branch on bazaar that gets the translations once a day from launchpad. You can find it [https://code.launchpad.net/~jomammele/openpetraorg/translationfiles here].)<br />
<br />
== Manually ==<br />
(Not needed any more)<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to get the latest translations into the official packaged version, and to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]<br />
<br />
= Testing a translation =<br />
We provide a Nightly Build of OpenPetra. This provides the changes on launchpad that has been made on the day before.<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Jenkins_CI_Server&diff=3124Jenkins CI Server2012-08-09T03:49:44Z<p>Joejoe2010: </p>
<hr />
<div>==URLs==<br />
The openpetra-Jenkin-Servers can be found on<br />
* http://ci.openpetra.org/ and<br />
* http://ci-win.solidcharity.com/<br />
<br />
== Ubuntu ==<br />
* installed on Ubuntu 11.10 (Oneiric Ocelot)<br />
<br />
apt-get remove apache bind9<br />
<br />
== Mono ==<br />
* using Mono 2.10 for best support for c# 4.0 etc<br />
apt-get install mono-runtime mono-xbuild mono-gmcs<br />
<br />
* for msgfmt to work for the i18n, processing of language files, you need to run:<br />
ln -s /usr/bin/gmcs /usr/bin/mcs<br />
<br />
== other development tools ==<br />
apt-get install bzr doxygen graphviz sqlite3 postgresql libpg-java dos2unix fakeroot lintian nsis<br />
<br />
=== setup SchemaSpy ===<br />
* Download SchemaSpy_5.0.0.jar from http://schemaspy.sourceforge.net/<br />
<br />
cd /var/tmp/OpenPetraBuild<br />
vi /etc/postgresql/9.1/main/pg_hba.conf and add at top: <code>local all petraserver md5</code><br />
nant recreateDatabase resetDatabase -D:DBMS.Type=postgresql<br />
<br />
java -jar schemaSpy_5.0.0.jar -t pgsql -dp /usr/share/java/postgresql-jdbc4.jar -host localhost:5432 -db openpetra -u petraserver -p petra -s public -o outputDir<br />
<br />
== NAnt ==<br />
* apt-get install nant<br />
* then download latest NAnt, NAnt 0.91 Release<br />
* unpack tar.gz file to /usr/local/nant-0.91<br />
* modify /usr/bin/nant and point at /usr/local/nant-0.91/bin/NAnt.exe<br />
<br />
<br />
* somehow, there is a problem when building for mono-2.0 or mono-4.0. The solution is to have two NAnt profiles:<br />
the default <code>/usr</code> and the other is <code>/usr/local/nant-for-4.0</code><br />
<br />
/usr/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v2.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
/usr/local/nant-for-4.0/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v4.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
== Jenkins ==<br />
* http://pkg.jenkins-ci.org/debian-stable/<br />
<br />
wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -<br />
vi /etc/apt/sources.list:<br />
deb http://pkg.jenkins-ci.org/debian-stable binary/<br />
<br />
apt-get update<br />
apt-get install jenkins<br />
<br />
* change port to 80: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu<br />
** better to use lighttpd because Apache needs another 200 MB of RAM.<br />
** /etc/lighttpd/lighttpd.conf<br />
add mod_proxy to the server.modules list, and at the bottom:<br />
proxy.server = (<br />
"/" => (( "host" => "127.0.0.1", "port" => 8080)),<br />
)<br />
<br />
* setup security: https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup<br />
<br />
* installed plugins:<br />
** Bazaar Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Bazaar+Plugin]<br />
** DocLinks Plugin [https://wiki.jenkins-ci.org/display/JENKINS/DocLinks+Plugin]<br />
** Email-ext Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin]<br />
** Log Parser Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]<br />
** NAnt Plugin [https://wiki.jenkins-ci.org/display/JENKINS/NAnt+Plugin]<br />
** Build-timeout Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Build-Timeout+Plugin]<br />
<br />
=== backup ===<br />
see also https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins<br />
tar czf jenkins.tar.gz --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/javadoc/*' --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/schemaSpy/*' /var/lib/jenkins/<br />
<br />
== Jenkins on Windows ==<br />
* similar setup to Jenkins on Ubuntu<br />
* http://ci-win.solidcharity.com/<br />
* the jobs OpenPetraBuildWin and OpenpetraBuildTestWin have their own OpenPetra.build.config file, stored in eg. C:\Program Files (x86)\Jenkins\workspace\OpenPetraBuildWin<br />
<?xml version="1.0"?><br />
<project name="OpenPetra-userconfig"><br />
<property name="PostgreSQL.Version" value="9.1"/><br />
<property name="DBMS.DBHostOrFile" value="devdb.solidcharity.com"/><br />
<property name="DBMS.DBName" value="buildserver"/><br />
<property name="DBMS.Setup.DBName" value="openpetra_basedb2"/><br />
<property name="DBMS.UserName" value="buildserver"/><br />
<property name="DBMS.Password" value="???"/><br />
<property name="Server.DebugLevel" value="0"/><br />
<property name="Server.Port" value="9432" /><br />
</project><br />
<br />
== Nightly Builds for Translators ==<br />
Jenkins can also be a help translating openpetra.<br />
By this, translators can work on a translation online and on the next day get an installer including already their translated items. This makes it easier for translators because then they can see their translations right away.<br />
<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.<br />
<br />
=== Further Information ===<br />
* [http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch exporting translations to a bazaar branch]<br />
* [http://nsis.sourceforge.net/Convert_Inno_Setup_scripts_to_NSIS_scripts conversion tool from Inno Setup to NSIS scripts]<br />
* other option running wine in order to run InnoSetup on Linux. (This seems to be more complicated to me(Joachim) as there are several points where this way would fail. For example Xvfb (or ttydrv) would be needed as InnoSetup wants to use an X Window.)<br />
* [http://stackoverflow.com/questions/7070358/creating-an-installer-via-command-line-through-jenkins-execute-batch-command installer on jenkins]<br />
* (We tried "Nullsoft Install" for building Windows Installers but due to some complications there's now running aswell a windows-Jenkins which uses InnoSetup to build the windows Installer.)</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3123Documentation for Translators2012-08-09T03:49:01Z<p>Joejoe2010: </p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra into other languages.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010@users.sourceforge.net joejoe2010(at)users.sourceforge.net]<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here]. Please click on the language for which you want to provide more translations.<br />
In order to make changes on a translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
== Testing the translations ==<br />
We provide a Nightly Build of OpenPetra. This provides the changes on launchpad that has been made on the day before. You can get the Nightly Build here. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations. <br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3122Documentation for Translators2012-08-09T03:48:29Z<p>Joejoe2010: /* How to translate with launchpad */</p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra into other languages.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here]. Please click on the language for which you want to provide more translations.<br />
In order to make changes on a translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
== Testing the translations ==<br />
We provide a Nightly Build of OpenPetra. This provides the changes on launchpad that has been made on the day before. You can get the Nightly Build here. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations. <br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010@users.sourceforge.net joejoe2010(at)users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3121Translation documentation for Developers2012-08-09T03:47:34Z<p>Joejoe2010: /* Testing a translation */</p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Synchronising Launchpad with version in bazaar =<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to get the latest translations into the official packaged version, and to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]<br />
<br />
= Testing a translation =<br />
We provide a Nightly Build of OpenPetra. This provides the changes on launchpad that has been made on the day before.<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Reviewing_the_translation_template&diff=3120Reviewing the translation template2012-08-09T03:44:03Z<p>Joejoe2010: </p>
<hr />
<div>The following table shows comments to some items that may be unclear for translators.<br />
Feel free to add items that are unclear for you and we'll add a comment to it later on.<br />
<br />
If an entry doesn't need translation, please add "will not be translated" and wef'll add the entry later to \trunk\i18n\donottranslate.po<br />
<br />
You can also do a full text search with Notepad++ on the *.cs files in csharp\ICT\Petra and see where the strings are used, that might give you a clue if it should be translated or not, and what the context is (if the source doesn't appear yet anyway in launchpad)<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| Mailing Code = Zip Code<br />
| this is usually a reference to table p_mailing: http://openpetraorg.sourceforge.net/dbdoc/index.html?table=p_mailing&group=mailing. When a gift is received, and you know the donor has given because you have sent him a special letter, the mailing code which clearly identifies that letter, can be entered with the gift.<br />
|-<br />
| R.List Items<br />
| this is on the PartnerFind_Options screen. you can sort items to the right or to the left side. That screen does not even open yet from the Partner Find screen, I have deactivated it for some reason, I think it was not completely working without Petra.<br />
|-<br />
| L.List Items<br />
| see above.<br />
|-<br />
| Exact Partner &Key Match<br />
| this is on the Partner Find screen<br />
|-<br />
| &Bulk Address Report<br />
| this is for mass mailing, you want to get a bulk of addresses, ie. a huge number of addresses<br />
|-<br />
| Mails&ort Label Print<br />
| Mailsort: this seems to be a UK thing: http://en.wikipedia.org/wiki/Mailsort<br />
|-<br />
| Todo<br />
| something that still needs to be implemented/realized<br />
|-<br />
| Key Partner Data<br />
| this is displayed on top of the partner edit screen, and is meant as a group heading for the most important data pieces of the partner, ie. Name, partner key, partner class, partner status, etc.<br />
|-<br />
| (trailing 0 = --*)<br />
| this is about the lblPartnerKeyNonExactMatch on partner find.<br />
|-<br />
| Select Zoom<br />
| This is also on the preview window for reports. it is a combobox for seleting "Fit to Window", "100%", "75%", "50%"<br />
|-<br />
| Extract<br />
| Extracts are a list of partners. They are used as a result from a special filter. For example you can filter all partners that have given more then 50 euros in the past 6 months, and put all their partner keys and addresses into an extract, and send a mailing to all those people.<br />
|-<br />
| Depth<br />
| This is often used on the screens where you define parameters for a report: do you want a default, or a summary, or a detail report. This is the depth of the report.<br />
|-<br />
| FD Income by Fund<br />
| FD stands for financial development, ie. to get the numbers of past donations and to understand what the donors want and what they are interested in. The FD Income by Fund report shows how much money has come in for which fund, eg. how much money did we get for Finland, Sweden, or Turkey?<br />
|-<br />
| Lapsed Donor Report<br />
| lapsed donors are donors who have previously given, but we have not received any donations anymore for a while. We have not completely lost them yet, but we might need to send them a letter to remind them that we are still here...<br />
|-<br />
| No gifts in year:<br />
| donors who didn't give gift during the year<br />
|-<br />
| SYBUNT<br />
| SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| 'Gift given in year' must be less than 'No gifts in year'<br />
| This is related to a validation error message: wrong year entered, the donor has first to have given in some year, and in the following year has stopped giving<br />
|-<br />
| Top Middle Bottom<br />
| These are for radio buttons, for top donor, middle donor, bottom donor, for the TopDonorReport.<br />
|-<br />
| New Interest Category<br />
| We have categories for grouping interests. so it is a new catgory that should be created.<br />
|-<br />
| New Partner Interest<br />
| this is about the interest, that should be created for a partner. he is interested in ... cars.<br />
|-<br />
| Value One Direction:<br />
| this is about the exchange rates. The value for GBP to USD is one direction, USD to GBP the other direction.<br />
|-<br />
| Charged Field Report<br />
| this is about conferences, and participants are coming from several countries and fields. The fields are charged for the participants that they are sending, and the participants pay directly to the field, and the field forwards to money to the conference organisers. The conference organisers know what money to charge to each field, by this report.<br />
|-<br />
| Sign Off Lines:<br />
| this is also for the field reports for a conference. Should we print a line for the signature, so it can be signed with a pen by the one responsible to pay<br />
|-<br />
| If charged field is not set:<br />
| Same report parameter screen: what should we do if we don't know which field to charge because it is not set on the participant's record<br />
|-<br />
| Fellowship Groups<br />
| The participants of a conference are organised into smaller groups during the conference, for talking in a more smaller setting<br />
|-<br />
| Discovery Groups<br />
| similar to Fellowship groups. Probably this is conference specific. you might translate it with "small groups 2"<br />
|-<br />
| Find Conference / Conference Find May the second phrase be "conference found"?<br />
| The conference find screen has the title "Conference Find". It would be better both are "Find Conference"<br />
|-<br />
| Old Field Key:<br />
| this is for gift adjustments when the recipient has changed fields, ie. the money should not go to the previous, old field, but go to the current place where the recipient is working.<br />
|-<br />
| Parsing the hash value of the batch<br />
| The hash value is a checksum of the amounts in the batch. usually just a sum of all amounts.<br />
|-<br />
| Use Ta&x Acct+CC<br />
| This is on the Accounts Payable module. For an invoice that we have to pay. Should we use the tax account and cost centre for this invoice detail? there seems to be a hard coded combination of account and cost centre for taxes.<br />
|-<br />
| Misc Defaults<br />
| Accounts Payable. Edit Supplier. Miscellaneous defaults: several defaults, that should be used on invoices from this supplier.<br />
|-<br />
| Form Letters<br />
| form letters are the same thing as mail merge, for sending many letters with predefined context, sometimes with custom content per recipient. http://en.wikipedia.org/wiki/Mail_merge<br />
|-<br />
| FinDev {0} {1}<br />
| This is used on the main screen, for the Financial Development task item. {0} and {1} will be filled with the number and the name of the ledger that the financial development module should be opened for.<br />
|-<br />
| SYBUNT Report<br />
| Related to the same thing as above. About donors that have stopped giving. LYBUNT = Last Year But Unfortunately Not This Year; SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| PETRAServer is running and listening @ {0}:{1}<br />
| Status message telling you that the Petraserver is listening on a certain IP Address and certain port. those two values will be inserted into the placeholders {0} and {1}<br />
|-<br />
| You do not have access to Partners of Partner Class 'ORGANISATION' that are 'Foundations'!<br />
| some users won't have access to edit partners that are foundations. Foundations are a special type of organisation. They usually are important donors, and they should not be approached by any user in the office, but only by the person that has been assigned to do that job.<br />
|}<br />
<br />
<br />
Fixed items(comments are already applied in the source code):<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| guages): This may be the last part of the following line? 'Speaks (Languages):' Speaks (Lan-<br />
| Yes, that's true. The correct string would be: Speaks (Languages):<br />
|-<br />
| this.FDelegateGetPartnerShortName could not be called!<br />
| will not be translated. should probably be changed in csharp\ICT\Petra\Client\MPartner\Gui\UC_PartnerEdit_TopPart.ManualCode.cs to not call Catalog.GetString<br />
|-<br />
| Exception occured during manual load of Client AppDomain: {0}<br />
| will not be translated. This is quite an internal error, when there are huge problems with the server. they don't need translation.<br />
|-<br />
| Text Preview / Text Output<br />
| please add Text Output to not to be translated Text Preview is displayed for the tab of the text preview when looking at a report<br />
|-<br />
| eg. "TEN,01","TEN,02"<br />
| will not be translated<br />
|}</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3119Translation documentation for Developers2012-08-09T03:40:01Z<p>Joejoe2010: /* The translation process */</p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
= Synchronising Launchpad with version in bazaar =<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to get the latest translations into the official packaged version, and to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]<br />
<br />
= Testing a translation =<br />
* TODO: describe how to use nant to generate the appropriate resource dll containing the translations<br />
* TODO: describe how to set the Environment Variables to switch to another language than the system language to test other language files<br />
* TODO: this might be interesting for translators too so that they can test their translation even before a release? but it is probably too complicated to configure and use nant?</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3118Documentation for Translators2012-08-09T03:33:54Z<p>Joejoe2010: </p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra into other languages.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here]. Please click on the language for which you want to provide more translations.<br />
In order to make changes on a translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010@users.sourceforge.net joejoe2010(at)users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3117Documentation for Translators2012-08-09T03:32:09Z<p>Joejoe2010: /* How to translate with launchpad */</p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here].<br />
In order to make changes on the translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010@users.sourceforge.net joejoe2010(at)users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3116Documentation for Translators2012-08-09T03:31:41Z<p>Joejoe2010: /* How to translate with launchpad */</p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here].<br />
In order to make changes on the translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3115Documentation for Translators2012-08-09T03:30:25Z<p>Joejoe2010: /* How to translate with launchpad */</p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here].<br />
In order to make changes on the translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010(at)users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3114Documentation for Translators2012-08-09T03:29:27Z<p>Joejoe2010: </p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
== How to translate with launchpad ==<br />
Launchpad is a platform for making the process of translating easier.<br />
You can find the openpetra-template [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 here].<br />
In order to make changes on the translation a registration is needed. You can register [https://login.launchpad.net/+new_account here].<br />
If you are not sure with a translation please check "Someone should review this translation" so that another person can review the item later on.<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010[at]users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3113Documentation for Translators2012-08-09T03:25:23Z<p>Joejoe2010: /* General information */</p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010[at]users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3112Documentation for Translators2012-08-09T03:24:56Z<p>Joejoe2010: </p>
<hr />
<div>== General information ==<br />
You are welcome to help out translating openpetra.<br />
<br />
There are actually 3 different ways to provide some translation.<br />
The first one is the easiest and is described in the following. The other 2 options can be found on the page [[Translation_documentation_for_Developers]].<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
If you have questions or doubts feel free to contact the translation team: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010 [at] users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Translation_documentation_for_Developers&diff=3111Translation documentation for Developers2012-08-09T03:23:59Z<p>Joejoe2010: </p>
<hr />
<div>= Documentation for Translators =<br />
There is a separate page with [[Documentation for Translators]].<br />
<br />
= The translation process =<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
= Synchronising Launchpad with version in bazaar =<br />
The synchronisation process needs to be done by someone of the Core development team. The goal is to get the latest translations into the official packaged version, and to update the template on Launchpad with new strings to translate.<br />
<br />
First download the latest translations, in this case for german, in .po format: <br />
https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/de/+export<br />
You will get an email once the download is ready.<br />
<br />
Then generate a new template file:<br />
# Delete the file i18n/template.po, if it exists<br />
# make sure that your OpenPetra.build.config has <property name="Translation.TargetLanguage" value="template"/><br />
# <code>nant translation</code> will create the file U:\openpetraorg\i18n\template.pot<br />
# Upload the new template.pot file to Launchpad, using https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/+upload<br />
# a few hours later, the new template will be available (if it needs a manual review, it might take a day)<br />
<br />
All .po files in the i18n directory will be added to the installer automatically. OpenPetra will use the language settings on the workstation for determining which language file should be used.<br />
<br />
= reviewing the launchpad template =<br />
Please have a look at [[Reviewing the launchpad template]]<br />
<br />
= Testing a translation =<br />
* TODO: describe how to use nant to generate the appropriate resource dll containing the translations<br />
* TODO: describe how to set the Environment Variables to switch to another language than the system language to test other language files<br />
* TODO: this might be interesting for translators too so that they can test their translation even before a release? but it is probably too complicated to configure and use nant?</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Jenkins_CI_Server&diff=3110Jenkins CI Server2012-08-09T03:18:07Z<p>Joejoe2010: /* Nightly Builds for Translators */</p>
<hr />
<div>==URLs==<br />
The openpetra-Jenkin-Servers can be found on<br />
* http://ci.openpetra.org/ and<br />
* http://ci-win.solidcharity.com/<br />
<br />
== Ubuntu ==<br />
* installed on Ubuntu 11.10 (Oneiric Ocelot)<br />
<br />
apt-get remove apache bind9<br />
<br />
== Mono ==<br />
* using Mono 2.10 for best support for c# 4.0 etc<br />
apt-get install mono-runtime mono-xbuild mono-gmcs<br />
<br />
* for msgfmt to work for the i18n, processing of language files, you need to run:<br />
ln -s /usr/bin/gmcs /usr/bin/mcs<br />
<br />
== other development tools ==<br />
apt-get install bzr doxygen graphviz sqlite3 postgresql libpg-java dos2unix fakeroot lintian nsis<br />
<br />
=== setup SchemaSpy ===<br />
* Download SchemaSpy_5.0.0.jar from http://schemaspy.sourceforge.net/<br />
<br />
cd /var/tmp/OpenPetraBuild<br />
vi /etc/postgresql/9.1/main/pg_hba.conf and add at top: <code>local all petraserver md5</code><br />
nant recreateDatabase resetDatabase -D:DBMS.Type=postgresql<br />
<br />
java -jar schemaSpy_5.0.0.jar -t pgsql -dp /usr/share/java/postgresql-jdbc4.jar -host localhost:5432 -db openpetra -u petraserver -p petra -s public -o outputDir<br />
<br />
== NAnt ==<br />
* apt-get install nant<br />
* then download latest NAnt, NAnt 0.91 Release<br />
* unpack tar.gz file to /usr/local/nant-0.91<br />
* modify /usr/bin/nant and point at /usr/local/nant-0.91/bin/NAnt.exe<br />
<br />
<br />
* somehow, there is a problem when building for mono-2.0 or mono-4.0. The solution is to have two NAnt profiles:<br />
the default <code>/usr</code> and the other is <code>/usr/local/nant-for-4.0</code><br />
<br />
/usr/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v2.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
/usr/local/nant-for-4.0/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v4.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
== Jenkins ==<br />
* http://pkg.jenkins-ci.org/debian-stable/<br />
<br />
wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -<br />
vi /etc/apt/sources.list:<br />
deb http://pkg.jenkins-ci.org/debian-stable binary/<br />
<br />
apt-get update<br />
apt-get install jenkins<br />
<br />
* change port to 80: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu<br />
** better to use lighttpd because Apache needs another 200 MB of RAM.<br />
** /etc/lighttpd/lighttpd.conf<br />
add mod_proxy to the server.modules list, and at the bottom:<br />
proxy.server = (<br />
"/" => (( "host" => "127.0.0.1", "port" => 8080)),<br />
)<br />
<br />
* setup security: https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup<br />
<br />
* installed plugins:<br />
** Bazaar Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Bazaar+Plugin]<br />
** DocLinks Plugin [https://wiki.jenkins-ci.org/display/JENKINS/DocLinks+Plugin]<br />
** Email-ext Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin]<br />
** Log Parser Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]<br />
** NAnt Plugin [https://wiki.jenkins-ci.org/display/JENKINS/NAnt+Plugin]<br />
** Build-timeout Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Build-Timeout+Plugin]<br />
<br />
=== backup ===<br />
see also https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins<br />
tar czf jenkins.tar.gz --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/javadoc/*' --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/schemaSpy/*' /var/lib/jenkins/<br />
<br />
== Jenkins on Windows ==<br />
* similar setup to Jenkins on Ubuntu<br />
* http://ci-win.solidcharity.com/<br />
* the jobs OpenPetraBuildWin and OpenpetraBuildTestWin have their own OpenPetra.build.config file, stored in eg. C:\Program Files (x86)\Jenkins\workspace\OpenPetraBuildWin<br />
<?xml version="1.0"?><br />
<project name="OpenPetra-userconfig"><br />
<property name="PostgreSQL.Version" value="9.1"/><br />
<property name="DBMS.DBHostOrFile" value="devdb.solidcharity.com"/><br />
<property name="DBMS.DBName" value="buildserver"/><br />
<property name="DBMS.Setup.DBName" value="openpetra_basedb2"/><br />
<property name="DBMS.UserName" value="buildserver"/><br />
<property name="DBMS.Password" value="???"/><br />
<property name="Server.DebugLevel" value="0"/><br />
<property name="Server.Port" value="9432" /><br />
</project><br />
<br />
== Nightly Builds for Translators ==<br />
Jenkins can also be a help translating openpetra.<br />
By this, translators can work on a translation online and on the next day get an installer including already their translated items. This makes it easier for translators because then they can see their translations right away.<br />
<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.<br />
<br />
=== Further Information ===<br />
- [http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch exporting translations to a bazaar branch]<br />
- [http://nsis.sourceforge.net/Convert_Inno_Setup_scripts_to_NSIS_scripts conversion tool from Inno Setup to NSIS scripts]<br />
- other option running wine in order to run InnoSetup on Linux. (This seems to be more complicated to me(Joachim) as there are several points where this way would fail. For example Xvfb (or ttydrv) would be needed as InnoSetup wants to use an X Window.)<br />
- [http://stackoverflow.com/questions/7070358/creating-an-installer-via-command-line-through-jenkins-execute-batch-command installer on jenkins]<br />
- (We tried "Nullsoft Install" for building Windows Installers but due to some complications there's now running aswell a windows-Jenkins which uses InnoSetup to build the windows Installer.)</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Jenkins_CI_Server&diff=3109Jenkins CI Server2012-08-09T03:17:21Z<p>Joejoe2010: /* Nightly Builds for Translators */</p>
<hr />
<div>==URLs==<br />
The openpetra-Jenkin-Servers can be found on<br />
* http://ci.openpetra.org/ and<br />
* http://ci-win.solidcharity.com/<br />
<br />
== Ubuntu ==<br />
* installed on Ubuntu 11.10 (Oneiric Ocelot)<br />
<br />
apt-get remove apache bind9<br />
<br />
== Mono ==<br />
* using Mono 2.10 for best support for c# 4.0 etc<br />
apt-get install mono-runtime mono-xbuild mono-gmcs<br />
<br />
* for msgfmt to work for the i18n, processing of language files, you need to run:<br />
ln -s /usr/bin/gmcs /usr/bin/mcs<br />
<br />
== other development tools ==<br />
apt-get install bzr doxygen graphviz sqlite3 postgresql libpg-java dos2unix fakeroot lintian nsis<br />
<br />
=== setup SchemaSpy ===<br />
* Download SchemaSpy_5.0.0.jar from http://schemaspy.sourceforge.net/<br />
<br />
cd /var/tmp/OpenPetraBuild<br />
vi /etc/postgresql/9.1/main/pg_hba.conf and add at top: <code>local all petraserver md5</code><br />
nant recreateDatabase resetDatabase -D:DBMS.Type=postgresql<br />
<br />
java -jar schemaSpy_5.0.0.jar -t pgsql -dp /usr/share/java/postgresql-jdbc4.jar -host localhost:5432 -db openpetra -u petraserver -p petra -s public -o outputDir<br />
<br />
== NAnt ==<br />
* apt-get install nant<br />
* then download latest NAnt, NAnt 0.91 Release<br />
* unpack tar.gz file to /usr/local/nant-0.91<br />
* modify /usr/bin/nant and point at /usr/local/nant-0.91/bin/NAnt.exe<br />
<br />
<br />
* somehow, there is a problem when building for mono-2.0 or mono-4.0. The solution is to have two NAnt profiles:<br />
the default <code>/usr</code> and the other is <code>/usr/local/nant-for-4.0</code><br />
<br />
/usr/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v2.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
/usr/local/nant-for-4.0/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v4.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
== Jenkins ==<br />
* http://pkg.jenkins-ci.org/debian-stable/<br />
<br />
wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -<br />
vi /etc/apt/sources.list:<br />
deb http://pkg.jenkins-ci.org/debian-stable binary/<br />
<br />
apt-get update<br />
apt-get install jenkins<br />
<br />
* change port to 80: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu<br />
** better to use lighttpd because Apache needs another 200 MB of RAM.<br />
** /etc/lighttpd/lighttpd.conf<br />
add mod_proxy to the server.modules list, and at the bottom:<br />
proxy.server = (<br />
"/" => (( "host" => "127.0.0.1", "port" => 8080)),<br />
)<br />
<br />
* setup security: https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup<br />
<br />
* installed plugins:<br />
** Bazaar Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Bazaar+Plugin]<br />
** DocLinks Plugin [https://wiki.jenkins-ci.org/display/JENKINS/DocLinks+Plugin]<br />
** Email-ext Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin]<br />
** Log Parser Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]<br />
** NAnt Plugin [https://wiki.jenkins-ci.org/display/JENKINS/NAnt+Plugin]<br />
** Build-timeout Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Build-Timeout+Plugin]<br />
<br />
=== backup ===<br />
see also https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins<br />
tar czf jenkins.tar.gz --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/javadoc/*' --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/schemaSpy/*' /var/lib/jenkins/<br />
<br />
== Jenkins on Windows ==<br />
* similar setup to Jenkins on Ubuntu<br />
* http://ci-win.solidcharity.com/<br />
* the jobs OpenPetraBuildWin and OpenpetraBuildTestWin have their own OpenPetra.build.config file, stored in eg. C:\Program Files (x86)\Jenkins\workspace\OpenPetraBuildWin<br />
<?xml version="1.0"?><br />
<project name="OpenPetra-userconfig"><br />
<property name="PostgreSQL.Version" value="9.1"/><br />
<property name="DBMS.DBHostOrFile" value="devdb.solidcharity.com"/><br />
<property name="DBMS.DBName" value="buildserver"/><br />
<property name="DBMS.Setup.DBName" value="openpetra_basedb2"/><br />
<property name="DBMS.UserName" value="buildserver"/><br />
<property name="DBMS.Password" value="???"/><br />
<property name="Server.DebugLevel" value="0"/><br />
<property name="Server.Port" value="9432" /><br />
</project><br />
<br />
== Nightly Builds for Translators ==<br />
Jenkins can also be a help translating openpetra.<br />
By this, translators can work on a translation online and on the next day get an installer including already their translated items. This makes it easier for translators because then they can see their translations right away.<br />
<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.<br />
<br />
(We tried "Nullsoft Install" for building Windows Installers but due to some complications there's now running aswell a windows-Jenkins which uses InnoSetup to build the windows Installer.)<br />
<br />
=== Further Information ===<br />
- [http://blog.launchpad.net/general/exporting-translations-to-a-bazaar-branch exporting translations to a bazaar branch]<br />
- [http://nsis.sourceforge.net/Convert_Inno_Setup_scripts_to_NSIS_scripts conversion tool from Inno Setup to NSIS scripts]<br />
- other option running wine in order to run InnoSetup on Linux. (This seems to be more complicated to me(Joachim) as there are several points where this way would fail. For example Xvfb (or ttydrv) would be needed as InnoSetup wants to use an X Window.)<br />
- [http://stackoverflow.com/questions/7070358/creating-an-installer-via-command-line-through-jenkins-execute-batch-command installer on jenkins]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Jenkins_CI_Server&diff=3108Jenkins CI Server2012-08-09T03:07:40Z<p>Joejoe2010: /* Additional comments */</p>
<hr />
<div>==URLs==<br />
The openpetra-Jenkin-Servers can be found on<br />
* http://ci.openpetra.org/ and<br />
* http://ci-win.solidcharity.com/<br />
<br />
== Ubuntu ==<br />
* installed on Ubuntu 11.10 (Oneiric Ocelot)<br />
<br />
apt-get remove apache bind9<br />
<br />
== Mono ==<br />
* using Mono 2.10 for best support for c# 4.0 etc<br />
apt-get install mono-runtime mono-xbuild mono-gmcs<br />
<br />
* for msgfmt to work for the i18n, processing of language files, you need to run:<br />
ln -s /usr/bin/gmcs /usr/bin/mcs<br />
<br />
== other development tools ==<br />
apt-get install bzr doxygen graphviz sqlite3 postgresql libpg-java dos2unix fakeroot lintian nsis<br />
<br />
=== setup SchemaSpy ===<br />
* Download SchemaSpy_5.0.0.jar from http://schemaspy.sourceforge.net/<br />
<br />
cd /var/tmp/OpenPetraBuild<br />
vi /etc/postgresql/9.1/main/pg_hba.conf and add at top: <code>local all petraserver md5</code><br />
nant recreateDatabase resetDatabase -D:DBMS.Type=postgresql<br />
<br />
java -jar schemaSpy_5.0.0.jar -t pgsql -dp /usr/share/java/postgresql-jdbc4.jar -host localhost:5432 -db openpetra -u petraserver -p petra -s public -o outputDir<br />
<br />
== NAnt ==<br />
* apt-get install nant<br />
* then download latest NAnt, NAnt 0.91 Release<br />
* unpack tar.gz file to /usr/local/nant-0.91<br />
* modify /usr/bin/nant and point at /usr/local/nant-0.91/bin/NAnt.exe<br />
<br />
<br />
* somehow, there is a problem when building for mono-2.0 or mono-4.0. The solution is to have two NAnt profiles:<br />
the default <code>/usr</code> and the other is <code>/usr/local/nant-for-4.0</code><br />
<br />
/usr/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v2.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
/usr/local/nant-for-4.0/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v4.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
== Jenkins ==<br />
* http://pkg.jenkins-ci.org/debian-stable/<br />
<br />
wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -<br />
vi /etc/apt/sources.list:<br />
deb http://pkg.jenkins-ci.org/debian-stable binary/<br />
<br />
apt-get update<br />
apt-get install jenkins<br />
<br />
* change port to 80: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu<br />
** better to use lighttpd because Apache needs another 200 MB of RAM.<br />
** /etc/lighttpd/lighttpd.conf<br />
add mod_proxy to the server.modules list, and at the bottom:<br />
proxy.server = (<br />
"/" => (( "host" => "127.0.0.1", "port" => 8080)),<br />
)<br />
<br />
* setup security: https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup<br />
<br />
* installed plugins:<br />
** Bazaar Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Bazaar+Plugin]<br />
** DocLinks Plugin [https://wiki.jenkins-ci.org/display/JENKINS/DocLinks+Plugin]<br />
** Email-ext Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin]<br />
** Log Parser Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]<br />
** NAnt Plugin [https://wiki.jenkins-ci.org/display/JENKINS/NAnt+Plugin]<br />
** Build-timeout Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Build-Timeout+Plugin]<br />
<br />
=== backup ===<br />
see also https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins<br />
tar czf jenkins.tar.gz --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/javadoc/*' --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/schemaSpy/*' /var/lib/jenkins/<br />
<br />
== Jenkins on Windows ==<br />
* similar setup to Jenkins on Ubuntu<br />
* http://ci-win.solidcharity.com/<br />
* the jobs OpenPetraBuildWin and OpenpetraBuildTestWin have their own OpenPetra.build.config file, stored in eg. C:\Program Files (x86)\Jenkins\workspace\OpenPetraBuildWin<br />
<?xml version="1.0"?><br />
<project name="OpenPetra-userconfig"><br />
<property name="PostgreSQL.Version" value="9.1"/><br />
<property name="DBMS.DBHostOrFile" value="devdb.solidcharity.com"/><br />
<property name="DBMS.DBName" value="buildserver"/><br />
<property name="DBMS.Setup.DBName" value="openpetra_basedb2"/><br />
<property name="DBMS.UserName" value="buildserver"/><br />
<property name="DBMS.Password" value="???"/><br />
<property name="Server.DebugLevel" value="0"/><br />
<property name="Server.Port" value="9432" /><br />
</project><br />
<br />
== Nightly Builds for Translators ==<br />
Jenkins can also be a help translating openpetra.<br />
By this, translators can work on a translation online and on the next day get an installer including already their translated items. This makes it easier for translators because then they can see their translations right away.<br />
<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe and install it on your computer to see your new translations.<br />
<br />
(We tried "Nullsoft Install" for building Windows Installers but due to some complications there's now running aswell a windows-Jenkins which uses InnoSetup to build the windows Installer.)</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Nightly_builds_on_Jenkins&diff=3107Nightly builds on Jenkins2012-08-09T03:07:24Z<p>Joejoe2010: moved Nightly builds on Jenkins to Can be deleted</p>
<hr />
<div>#REDIRECT [[Can be deleted]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Can_be_deleted&diff=3106Can be deleted2012-08-09T03:07:24Z<p>Joejoe2010: moved Nightly builds on Jenkins to Can be deleted</p>
<hr />
<div>can be deleted</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Can_be_deleted&diff=3105Can be deleted2012-08-09T03:06:59Z<p>Joejoe2010: Replaced content with 'can be deleted'</p>
<hr />
<div>can be deleted</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Jenkins_CI_Server&diff=3104Jenkins CI Server2012-08-09T02:56:28Z<p>Joejoe2010: </p>
<hr />
<div>==URLs==<br />
The openpetra-Jenkin-Servers can be found on<br />
* http://ci.openpetra.org/ and<br />
* http://ci-win.solidcharity.com/<br />
<br />
== Ubuntu ==<br />
* installed on Ubuntu 11.10 (Oneiric Ocelot)<br />
<br />
apt-get remove apache bind9<br />
<br />
== Mono ==<br />
* using Mono 2.10 for best support for c# 4.0 etc<br />
apt-get install mono-runtime mono-xbuild mono-gmcs<br />
<br />
* for msgfmt to work for the i18n, processing of language files, you need to run:<br />
ln -s /usr/bin/gmcs /usr/bin/mcs<br />
<br />
== other development tools ==<br />
apt-get install bzr doxygen graphviz sqlite3 postgresql libpg-java dos2unix fakeroot lintian nsis<br />
<br />
=== setup SchemaSpy ===<br />
* Download SchemaSpy_5.0.0.jar from http://schemaspy.sourceforge.net/<br />
<br />
cd /var/tmp/OpenPetraBuild<br />
vi /etc/postgresql/9.1/main/pg_hba.conf and add at top: <code>local all petraserver md5</code><br />
nant recreateDatabase resetDatabase -D:DBMS.Type=postgresql<br />
<br />
java -jar schemaSpy_5.0.0.jar -t pgsql -dp /usr/share/java/postgresql-jdbc4.jar -host localhost:5432 -db openpetra -u petraserver -p petra -s public -o outputDir<br />
<br />
== NAnt ==<br />
* apt-get install nant<br />
* then download latest NAnt, NAnt 0.91 Release<br />
* unpack tar.gz file to /usr/local/nant-0.91<br />
* modify /usr/bin/nant and point at /usr/local/nant-0.91/bin/NAnt.exe<br />
<br />
<br />
* somehow, there is a problem when building for mono-2.0 or mono-4.0. The solution is to have two NAnt profiles:<br />
the default <code>/usr</code> and the other is <code>/usr/local/nant-for-4.0</code><br />
<br />
/usr/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v2.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
/usr/local/nant-for-4.0/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v4.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
== Jenkins ==<br />
* http://pkg.jenkins-ci.org/debian-stable/<br />
<br />
wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -<br />
vi /etc/apt/sources.list:<br />
deb http://pkg.jenkins-ci.org/debian-stable binary/<br />
<br />
apt-get update<br />
apt-get install jenkins<br />
<br />
* change port to 80: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu<br />
** better to use lighttpd because Apache needs another 200 MB of RAM.<br />
** /etc/lighttpd/lighttpd.conf<br />
add mod_proxy to the server.modules list, and at the bottom:<br />
proxy.server = (<br />
"/" => (( "host" => "127.0.0.1", "port" => 8080)),<br />
)<br />
<br />
* setup security: https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup<br />
<br />
* installed plugins:<br />
** Bazaar Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Bazaar+Plugin]<br />
** DocLinks Plugin [https://wiki.jenkins-ci.org/display/JENKINS/DocLinks+Plugin]<br />
** Email-ext Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin]<br />
** Log Parser Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]<br />
** NAnt Plugin [https://wiki.jenkins-ci.org/display/JENKINS/NAnt+Plugin]<br />
** Build-timeout Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Build-Timeout+Plugin]<br />
<br />
=== backup ===<br />
see also https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins<br />
tar czf jenkins.tar.gz --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/javadoc/*' --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/schemaSpy/*' /var/lib/jenkins/<br />
<br />
== Jenkins on Windows ==<br />
* similar setup to Jenkins on Ubuntu<br />
* http://ci-win.solidcharity.com/<br />
* the jobs OpenPetraBuildWin and OpenpetraBuildTestWin have their own OpenPetra.build.config file, stored in eg. C:\Program Files (x86)\Jenkins\workspace\OpenPetraBuildWin<br />
<?xml version="1.0"?><br />
<project name="OpenPetra-userconfig"><br />
<property name="PostgreSQL.Version" value="9.1"/><br />
<property name="DBMS.DBHostOrFile" value="devdb.solidcharity.com"/><br />
<property name="DBMS.DBName" value="buildserver"/><br />
<property name="DBMS.Setup.DBName" value="openpetra_basedb2"/><br />
<property name="DBMS.UserName" value="buildserver"/><br />
<property name="DBMS.Password" value="???"/><br />
<property name="Server.DebugLevel" value="0"/><br />
<property name="Server.Port" value="9432" /><br />
</project><br />
<br />
== Additional comments ==<br />
Jenkins can also be a help translating openpetra.<br />
By this, translators can work on a translation online and on the next day get an installer including already their translated items. This makes it easier for translators because then they can see their translations right away.<br />
<br />
You can get the Nightly Build [http://ci-win.solidcharity.com/job/OpenPetraBuildWin/ here]. Please download the exe-file OpenPetraSetup-x.x.xx.xxxx.exe<br />
<br />
(We tried "Nullsoft Install" for building Windows Installers but due to some complications there's now running aswell a windows-Jenkins which uses InnoSetup to build the windows Installer.)</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Jenkins_CI_Server&diff=3103Jenkins CI Server2012-08-09T02:52:40Z<p>Joejoe2010: /* Additional comments */</p>
<hr />
<div>== Ubuntu ==<br />
* installed on Ubuntu 11.10 (Oneiric Ocelot)<br />
<br />
apt-get remove apache bind9<br />
<br />
== Mono ==<br />
* using Mono 2.10 for best support for c# 4.0 etc<br />
apt-get install mono-runtime mono-xbuild mono-gmcs<br />
<br />
* for msgfmt to work for the i18n, processing of language files, you need to run:<br />
ln -s /usr/bin/gmcs /usr/bin/mcs<br />
<br />
== other development tools ==<br />
apt-get install bzr doxygen graphviz sqlite3 postgresql libpg-java dos2unix fakeroot lintian nsis<br />
<br />
=== setup SchemaSpy ===<br />
* Download SchemaSpy_5.0.0.jar from http://schemaspy.sourceforge.net/<br />
<br />
cd /var/tmp/OpenPetraBuild<br />
vi /etc/postgresql/9.1/main/pg_hba.conf and add at top: <code>local all petraserver md5</code><br />
nant recreateDatabase resetDatabase -D:DBMS.Type=postgresql<br />
<br />
java -jar schemaSpy_5.0.0.jar -t pgsql -dp /usr/share/java/postgresql-jdbc4.jar -host localhost:5432 -db openpetra -u petraserver -p petra -s public -o outputDir<br />
<br />
== NAnt ==<br />
* apt-get install nant<br />
* then download latest NAnt, NAnt 0.91 Release<br />
* unpack tar.gz file to /usr/local/nant-0.91<br />
* modify /usr/bin/nant and point at /usr/local/nant-0.91/bin/NAnt.exe<br />
<br />
<br />
* somehow, there is a problem when building for mono-2.0 or mono-4.0. The solution is to have two NAnt profiles:<br />
the default <code>/usr</code> and the other is <code>/usr/local/nant-for-4.0</code><br />
<br />
/usr/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v2.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
/usr/local/nant-for-4.0/bin/nant:<br />
#!/bin/sh<br />
#exec /usr/bin/cli /usr/lib/NAnt/NAnt.exe "$@"<br />
mono --runtime=v4.0 /usr/local/nant-0.91/bin/NAnt.exe "$@"<br />
<br />
== Jenkins ==<br />
* http://pkg.jenkins-ci.org/debian-stable/<br />
<br />
wget -q -O - http://pkg.jenkins-ci.org/debian-stable/jenkins-ci.org.key | sudo apt-key add -<br />
vi /etc/apt/sources.list:<br />
deb http://pkg.jenkins-ci.org/debian-stable binary/<br />
<br />
apt-get update<br />
apt-get install jenkins<br />
<br />
* change port to 80: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu<br />
** better to use lighttpd because Apache needs another 200 MB of RAM.<br />
** /etc/lighttpd/lighttpd.conf<br />
add mod_proxy to the server.modules list, and at the bottom:<br />
proxy.server = (<br />
"/" => (( "host" => "127.0.0.1", "port" => 8080)),<br />
)<br />
<br />
* setup security: https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup<br />
<br />
* installed plugins:<br />
** Bazaar Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Bazaar+Plugin]<br />
** DocLinks Plugin [https://wiki.jenkins-ci.org/display/JENKINS/DocLinks+Plugin]<br />
** Email-ext Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin]<br />
** Log Parser Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]<br />
** NAnt Plugin [https://wiki.jenkins-ci.org/display/JENKINS/NAnt+Plugin]<br />
** Build-timeout Plugin [https://wiki.jenkins-ci.org/display/JENKINS/Build-Timeout+Plugin]<br />
<br />
=== backup ===<br />
see also https://wiki.jenkins-ci.org/display/JENKINS/Administering+Jenkins<br />
tar czf jenkins.tar.gz --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/javadoc/*' --exclude '/var/lib/jenkins/jobs/OpenPetraCodeDoc/schemaSpy/*' /var/lib/jenkins/<br />
<br />
== Jenkins on Windows ==<br />
* similar setup to Jenkins on Ubuntu<br />
* http://ci-win.solidcharity.com/<br />
* the jobs OpenPetraBuildWin and OpenpetraBuildTestWin have their own OpenPetra.build.config file, stored in eg. C:\Program Files (x86)\Jenkins\workspace\OpenPetraBuildWin<br />
<?xml version="1.0"?><br />
<project name="OpenPetra-userconfig"><br />
<property name="PostgreSQL.Version" value="9.1"/><br />
<property name="DBMS.DBHostOrFile" value="devdb.solidcharity.com"/><br />
<property name="DBMS.DBName" value="buildserver"/><br />
<property name="DBMS.Setup.DBName" value="openpetra_basedb2"/><br />
<property name="DBMS.UserName" value="buildserver"/><br />
<property name="DBMS.Password" value="???"/><br />
<property name="Server.DebugLevel" value="0"/><br />
<property name="Server.Port" value="9432" /><br />
</project><br />
<br />
== Additional comments ==<br />
Jenkins can also be a help translating openpetra.<br />
By this, translators can work on a translation online and on the next day get an installer including already their translated items. This makes it easier for translators because then they can see their translations right away.<br />
<br />
<br />
[We tried "Nullsoft Install" for building Windows Installers but due to some complications there's now running aswell a windows-Jenkins which uses InnoSetup to build the windows Installer.]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=How-To:_Creating_a_Maintain_Table_screen&diff=3094How-To: Creating a Maintain Table screen2012-07-31T21:39:56Z<p>Joejoe2010: /* Step 5a: Adding the generated files */</p>
<hr />
<div>=Overview=<br />
<br />
'''A Maintain Table screen allows CRUD (Create, Read, Update, Delete [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete]) operations for a specific system table/lookup table of openPETRA.'''<br />
<br />
This tutorial outlines the basic steps that are involved in creating a Maintain Table screen, starting off with an existing Maintain Table screen which is then copied and modified.<br />
<br />
''Don't get intimidated by fact that are quite a few steps involved - once you have done them several times, you will remember them pretty quickly.''<br />
(A developer who has already done a few Maintain Table Screens will be able to do a new, simple Maintain Table Screen that is based on an existing Maintain Table Screen in about an hour or less.)<br />
<br />
<br />
==Types of Maintain Table Screens==<br />
There are three types of Maintain Table screens:<br />
* '''Maintain Table screens which are used for editing the values of a 'Cacheable DataTable'.'''<br />
** A 'Cacheable DataTable' usually contains the data of a ''single database table'' which is transferred to the Client once and is saved to a local file which resides at the client computer's harddisk at the first client request of the Cacheable DataTable. These datatables are also ''held in memory (RAM) for quick access''. The Cacheable DataTables are managed by a Cache Manager Class on both the client and server side, which make sure that all Cacheable DataTables of all clients are kept up-to-date and in sync, among other things. <br />
*** 'Candiates' for Cacheable DataTables, and therefore for Maintain Table screens which are editing the values of Cacheable DataTables, are database tables that are ''frequently accessed'' either by the server or the client or whose contents are ''frequently displayed'', e.g. values of frequently displayed ComboBoxes or Lists.<br />
** This type of Maintain Table screen is the '''easiest''' to do and '''needs the least programming''' because the Cache Manager Classes encapsulate most of the functionality that is needed. ''The person who creates such screens does not need know about the client-server architecture of openPETRA, and needs little programming know-how'' - therefore such Maintain Table screens are ideally suited for people who join the development of openPETRA.<br />
* '''Maintain Table screens which are used for editing the values of a single database table that ''is not'' a 'Cacheable DataTable'.'''<br />
** This type of Maintain Table screen is somewhat more involved than the Maintain Table screens which are editing the values of Cacheable DataTables. <br />
** '''More programming is needed''', since such a screen uses a WebConnector Class for reading and writing of data from/to the database. One WebConnector Class needs to be created for every screen. These Classes aren't hard to do and follow a standard pattern, but in order for creating those Clases, the '''programmer needs''' to know more about the client-server architecture of openPETRA and needs '''to be a more experienced openPETRA programmer'''.<br />
* '''''Special'' Maintain Table screens''' <br />
** which <br />
*** edit values of several database tables at once, ''or'' <br />
*** need to read in the values of several database tables in order to edit one database table, ''and/or''<br />
*** don't follow the standard 'list/detail' format of the typical Maintain Table screens, ''and'' <br />
*** have custom loading/saving routines to update the database.<br />
*** are unique within openPETRA and don't resemble each other, so a custom GUI needs to be developed for each screen.<br />
** Those screens' design and logic is usually similar to many Edit screens and therefore no general principle can be given how they are done. (Most likely a more involved WebConnector Class will be needed for such screens; some screens might even be better done with a UIConnector Class.)<br />
** For those reasons, '''an experienced openPETRA developer needs to do those kind of screens'''.<br />
** There are not that many Maintain Table screens which fall into this category.<br />
<br />
=Creating a new Maintain Table screen=<br />
The following ''general'' instructions can help in ''creating a simple'' new Maintain Tables screen ''based on a similar, existing Maintain Tables screen''. (Many Maintain Tables screens are rather simple and similar to existing ones. To start off with a completely new Maintain Tables screen that isn't based on an existing one is obviously more complicated. However, from Step 4 onwards, the same procedures would apply to such new screens as well.)<br />
<br />
==Step 1: Choosing a similar, existing Maintain Tables screen==<br />
* Start openPETRA.<br />
* Using the Navigation Panel, go to the Module (and perhaps Sub-Module) that contains the Area 'Setup' where a Task for a similar screen exists (in the Task List on the right hand side).<br />
** It is advisable to look for a similar screen in the Module where your new screen should end up as well - this makes it easier to copy the screen.<br />
* Open the screen that you think is similar and check that it indeed is similar to the screen that you are about to do.<br />
** Check for <br />
*** the overall appearance of the screen, <br />
*** that there is a similar number of data fields in the columns of the grid and <br />
*** that there is a similar number of data fields in the details section below the grid.<br />
** Should one or two columns in the grid or one or two data fields in the details section be different, this screen is still suitable for a 'similar screen' that we can start off with.<br />
<br />
<br />
==Step 2: Copying existing screen definition file to new screen==<br />
===Overview===<br />
All Maintain Table screens are based on a 'screen definition file', which is passed to a Generator. The Generator generates the C# source code and the Resource File (contains e.g. Icons) which form the actual screen in openPETRA.<br />
<br />
openPETRA's Screen Definition Files are plain text files which are structured in the [[https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Development_with_Code_Generation#YAML YAML]] syntax.<br />
<br />
By copying the screen definition file of the existing screen, we will get an exact copy of the layout and data of the existing screen - in a new file. This will be our starting point for the changes we need to make to change the data and layout into 'our' new Maintain Table screen.<br />
<br />
===Locating existing screen's screen definition file===<br />
* Recall what Module, Sub-Module and Area you chose, and which Task you chose from the Task List to bring up the existing, similar Maintain Table screen.<br />
* Open the following file in a text editor (e.g. Notepad, Notepad++)<br />
U:\openpetraorg\''NameOfYourFeatureBranch''\csharp\ICT\Petra\Definitions\UINavigation.yml<br />
* ''NameOfYourFeatureBranch'' is the name of the Feature Branch on which you are currently working. There will be one Feature Branch for each new Maintain Table Screen (or one Feature Branch for several Maintain Table screens if you are doing a batch of new Maintain Table screens). (Your mentor will have created that Feature Branch for you and you will need to have it checked out already.)<br />
* This file contains a structure that is used for builing the Navigation structure which you see in the Main Menu's Navigation Panel of openPETRA.<br />
* Scroll through the file until you find the Module, Sub-Module, Area and Task that describes the Task that you clicked to bring up the existing, similar Maintain Table screen (the hierarchy is created by indentation!).<br />
** The line that describes the exact Task contains the text 'ActionOpenScreen=', followed by text. That text, usually starting with 'TFrm...', is the ''Class Name'' of the existing, similar Form.<br />
** To find out the ''File Name'' of its 'screen definition file', leave out the 'TFrm' and take only the remainder of the text. Example: if the text is 'ActionOpenScreen=TFrmPartnerTypeSetup', the Class Name is 'TFrmPartnerTypeSetup' and the File Name is 'PartnerTypeSetup'.<br />
** append ".yaml" to get the full File Name including File Extension. Example: 'PartnerTypeSetup' becomes 'PartnerTypeSetup.yaml'.<br />
<br />
====Determining full file path of the existing screen's screen definitions file====<br />
* The line that describes the exact Task, or more likely the Elements who are one or two steps higher in the hierarchy (=one or two steps less indented), will contain the text 'Namespace='. It is followed by a text that ends in '.Setup', e.g. 'Ict.Petra.Client.MPartner.Gui.Setup'.<br />
* This tells you the last part of the folder where the screen definition file can be found: replace the dots ('.') with backslashes ('\'), precede this with 'U:\openpetraorg\''NameOfYourFeatureBranch''\csharp\', and add the File Name to get the full file path: '<code>U:\openpetraorg\''NameOfYourFeatureBranch''\csharp\ICT\Petra\Client\MPartner\gui\setup\PartnerTypeSetup.yaml</code>'.<br />
<br />
===Copying the screen definitions file===<br />
* Make a copy of the screen definitions file (whose full file name you just determined) in the same directory.<br />
** Should your new Maintain Table screen need to go into a different namespace, choose the appropriate directory (ending in 'gui\setup') and place the copied file there! <br />
*** Example: If your Maintain Table screen should go into the Ict.Petra.Client.MFinance.Gui.Setup namespace, the appropriate directory would be 'Ict\Petra\Client\''MFinance\gui\setup''.)<br />
* Name the file according to ''what'' the screen will maintain<br />
** Example: if the screen will maintain Partner Types, name the file 'PartnerTypeSetup.yaml' (please use the singular, not the plural form).<br />
** The name of the file should end with 'Setup.yaml'.<br />
<br />
<br />
==Step 3: Modifying screen definition file to suit the new screen's data and layout==<br />
Each YAML file has two distinct sections: 'Header information' and 'Data Fields and Layout'.<br />
<br />
===Header Information===<br />
The Header Information contains a few Elements. The ones that are particularly important for Maintain Table screens are explained in the following sections. A general overview of all the Elements can be found on page [[Documentation_YAML_for_OpenPetra_Forms]], in the 'Attributes of the root node' section.<br />
<br />
====FormTitle Element====<br />
The value of the 'FormTitle' Element is constructed as follows: take the file name of the YAML file, leave out the 'Setup' string and the '.yaml' extension, change it to plural form, put space characters between the words and prepend the string with 'Maintain '.<br />
<br />
Example:<br />
If the screen's YAML file is named 'MaritalStatusSetup.yaml', the 'FormTitle' will be 'Maintain Marital Statuses'.<br />
<br />
====DetailTable Element====<br />
The value of the 'DetailTable Element' is the 'Class Name' of the openPETRA Database Table whose records your Maintain Table screen maintains. It can be constructed from the name of the openPETRA Database Table as follows: capitalise the first character, capitalise the first character after all underscore characters ('_'), and then remove all underscore characters.<br />
<br />
Examples: <br />
p_partner becomes <code>PPartner</code>, pt_marital_status becomes <code>PtMaritalStatus</code>.<br />
<br />
Technical detail: the Class that you specify with the 'Class Name' represents a 'Typed DataTable', which is a C# object representation of the openPETRA Database Table.<br />
<br />
====CacheableTable Element====<br />
The 'CacheableTable' Element must be present for Maintain Table screens which are based on 'Cacheable DataTables'. For all other screens (be it regular screens or Maintain Table screens which aren't based on 'Cacheable DataTables'), the Element must be omitted.<br />
<br />
The value of the 'CacheableTable' Element must be set to the name of the Cacheable DataTable whose records the screen will maintain. You will either been given the correct name, or you should know it because you are a more advanced openPETRA developer.<br />
<br />
====Namespace and UsingNamespace Elements====<br />
The values of the 'Namespace' and 'UsingNamespace' Elements will likely ''not need to be changed'' if the YAML file which was used as a template for the new YAML file was copied within the same directory. <br />
<br />
=====Namespace Element=====<br />
The value of the 'Namespace' Element can be constructed by replacing 'xxx' with the name of the openPETRA Module in which the Maintain Table screen needs to go in the following string: 'Ict.Petra.Client.Mxxx.Gui.Setup'. <br />
Example: for the Partner Module, the 'Namespace' Element would be 'Ict.Petra.Client.MPartner.Gui.Setup'.<br />
<br />
Technical detail: The 'Namespace' Element specifies the C# Namespace that the generated Maintain Table screen will be placed into. The Generator uses it to put the screen's Class into the C# Namespace in the generated *.cs and *.Designer.cs files.<br />
<br />
=====UsingNamespace Element=====<br />
To get the value of the 'UsingNamespace' Element, check the values of 'UsingNamespace' Elements of other YAML files that are found in the directory where your YAML file is placed. <br />
* Find an existing YAML file that references an openPETRA Database Table that is in the same 'area' in the openPETRA DB documentation (the 'area' is denoted by the top-left selection box in the openPETRA DB documentation) than the openPETRA DataBase Table which you specified in the 'DetailTable Element'.<br />
* Copy the value of 'UsingNamespace' over into your YAML file.<br />
* If you can't find an appropriate existing YAML file, or if you are not sure what to put into the 'UsingNamespace' Element, seek help from other openPETRA developers in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 openPETRA Developer Forum].<br />
<br />
Technical detail: The 'UsingNamespace' Element specifies a C# Namespace that needs to be referenced in order to get the definition of the Class that is specified in the 'DetailTable' Element (the Class represents a 'Typed DataTable'). The Generator uses the 'UsingNamespace' Element to put a 'using' clause in the generated *.cs and *.Designer.cs files.<br />
<br />
Troubleshooting: Should you later run into compilation errors that mention that a Class that is named like the 'DetailTable' cannot be found, then the 'UsingNamespace' Element is not correct.<br />
<br />
===Layout and Data Fields===<br />
This section of the YAML file is introduced by the Element 'Actions' or 'Controls'. From here onwards, the YAML file specifies the layout, the Controls on the screen and the database columns that they are bound to.<br />
<br />
====Layout====<br />
Most 'Maintain Table' screens follow a ''standardised layout pattern''. Only more complicated Maintain Table screens (who have many or unusual controls or a different user interface concept altogether) should deviate from that layout. The purpose of the standardised layout is to create an easily understood and recognised layout pattern across the application. (A positive side effect is that it also simplifies and speeds up the creation of these screens, as you will see.)<br />
<br />
The standardised layout pattern describes the following:<br />
* Main Menu (File, Edit, Help)<br />
* ToolBar (Save and New ToolBarButtons)<br />
* Grid (List) Part<br />
* Details (Bottom) Part<br />
<br />
The following sections describe these parts of the user interface.<br />
<br />
=====Main Menu=====<br />
The usual MenuItems of Edit Screens (File, Edit and Help along with their sub-MenuItems) are automatically generated, and those are sufficient. ''You don't need to do anything in your YAML file for the Main Menus'' (unless you have a more complicated Maintain Table screens [who have many or unusual controls or a different user interface concept altogether] which may require additional MenuItems).<br />
<br />
=====ToolBar=====<br />
The ToolBar contains two ToolBarButtons - 'Save' and 'New xxx'. <br />
* The 'Save' Button lets the user save any changes to the database and is automatically generated, as this an Edit Screen. <br />
* The 'New xxx' Button lets the user create a new data row. This Button needs to be done by you, but there will be already a definition for it in the YAML file since you copied it from another Maintain Table screen, which will have the same Button.<br />
<br />
The definition for the ToolBar and the ToolBarButton looks like this:<br />
Toolbar:<br />
tbbNew:<br />
Label: New ''xxx''<br />
<br />
Change the 'xxx' in the text 'New xxx' to reflect ''what'' will be created new - this is the singular form of the FormTitle without the word 'Maintain'. The singular form is used since the user is creating ''one'' new data row, and the FormTitle will be plural because it lets the user see and edit ''many'' data rows.<br />
<br />
Example: If the 'FormTitle' is 'Maintain Business Codes', the Label of the tbbNew button should be '<code>Label: New Business Code</code>'.<br />
<br />
Technical detail: Since the ToolBarButton is called tbb''New'', the Generator automatically 'wires' it up with the Action act''New''. The result is that if the user presses this ToolBarButton, the Action 'actNew' is executed (which creates a new data row that can be edited in the Details Part).<br />
<br />
=====Grid (List) Part=====<br />
The Grid part contains a list of data rows. These are the rows of data that come out of the database table which your particular screen is maintaining. The Grid has several Columns, which display data fields from the database table. <br />
<br />
As the database tables have different data fields, the Columns will be different on each Maintain Table screen. You need to specify the data fields that make up the Columns of the Grid of your screen.<br />
<br />
Note: next to the Grid part is a Panel with an 'New' Button. ''You don't need to do anything in your YAML file for this Panel, as it is standardised. The 'New' Button is automatically 'wired' up by the Generator.''<br />
<br />
Here is an example that shows how the Grid is defined in the YAML file:<br />
grdDetails:<br />
Dock: Fill<br />
Columns: [DetailCode, DetailDescription, DetailDeletableFlag]<br />
ActionFocusRow: FocusedRowChanged<br />
<br />
The only thing that you need to change is the line that starts with '<code>Columns:</code>'.<br />
<br />
======Specifying the Columns of the Grid======<br />
The line in the YAML file that that starts with '<code>Columns:</code>' defines <br />
* which data fields from the database table that your screen is maintaining are displayed in the Grid;<br />
* in which order the data fields are displayed.<br />
<br />
In order to identify the names of the data fields from the database table that your screen is maintaining, you need to look at the definition of the database table. <br />
<br />
You will find the database table definition in the [[http://openpetraorg.sourceforge.net/dbdoc/ Database Design of OpenPetra.org]]. <br />
* Locate the database table in the list on the left hand side and click on it to show its definition on the right hand side. <br />
** In case you can't see the database table that your screen is maintaining, you will need to change the 'area' of the database that is displayed in the list on the right. Click on one of the 'areas' that is listed in the box on the top left of the page, above the list of database tables, to show a different list of database tables.<br />
* Maintain Table screens usually display all fields of the underlying database table, except the following fields (which are system fields that track which user changed what record, and when): <code> s_date_created_d, s_created_by_c, s_date_modified_d, s_modified_by_c, s_modification_id_c</code>.<br />
* Note down the names of the individual data fields that are remaining.<br />
* Change the name of each data field as follows: <br />
** remove the 'prefix', which is the first letter (or first two letters) followed by an underscore character ('_');<br />
** remove the 'suffix', which is the last underscore character in the name followed by a letter;<br />
** capitalise the first character, capitalise the first character after all underscore characters ('_'), and then remove all underscore characters. <br />
*** Examples: '<code>p_description_c</code>' becomes 'Description', '<code>p_deletable_l</code>' becomes 'Deletable', '<code>p_method_of_contact_code_c</code>' becomes 'MethodOfContactCode'.<br />
* Prefix the name of the data field with the word 'Detail'.<br />
** Example: 'DetailMethodOfContactCode'<br />
* Most of the times you will want to create Columns for all data fields in the Grid.<br />
** You might choose to not create Columns in the Grid for some of the data fields of the database table which your particular screen is maintaining, especially if this would result in creating more than four or five Columns. <br />
** Which Columns to show, and which ones not, really depends on what you deem to be important information that should be seen in the Grid, and not just the Detail part.<br />
<br />
<br />
Once you have got the names of the individual data fields and have decided which ones will be displayed in the Columns of the Grid, you can build the 'Columns:' Element as follows:<br />
* within the opening and closing brackets '[' and ']'<br />
** place the names of the data fields<br />
** in the order that they should appear in the Grid<br />
** and separate the names with ', '.<br />
<br />
Example: <br />
Columns: [DetailBusinessCode, DetailBusinessDescription, DetailDeletable]<br />
<br />
relates to the data columns <code>p_business_code_c</code>, <code>p_business_description_c</code> and <code>p_deletable_l</code> of the <code>p_business</code> database table.<br />
<br />
As for the order of the Columns, usually the data fields should be displayed in the order they appear in the database table. An exception to that is the 'deletable' data column, which should always go at the right hand of all the other columns, even if it is in the middle of other columns in the database table definition.<br />
<br />
Custom Headings for Columns<br />
<br />
The headings of the columns in the Grid are automatically derived from the names of the data fields. This is fine in many cases, but sometimes the name of the data field is 'technical' or doesn't reflect how it is usually named in the GUI.<br />
<br />
To change the heading of one or more columns, a '<code>CustomColumns</code>' Element needs to be present, following the '<code>Columns</code>' Element ''at the same indentation level''. After that, one or more column names can be listed on separate lines, indented by one indentation level. The column names are taken from the '<code>Columns</code>' Element and need to be given the '<code>Label</code>' attribute as shown in the following example:<br />
<br />
CustomColumns:<br />
DetailCode: {Label=Relationship Category Code}<br />
<br />
This renames the automatically derived column heading 'Code' to 'Relationship Category Code'.<br />
<br />
Custom Formatting of Data in Columns<br />
<br />
The data type of columns in the Grid is '<code>string</code>' by default. To display the content of any column as a different data type, list column names on separate lines as described in the section above, ''Custom Headings for Columns''. Instead (or in addition to) the '<code>Label</code>' Attribute, the Attribute '<code>Type</code>' needs to be used as in the following example:<br />
<br />
CustomColumns:<br />
DetailUnassignableDate: {Type=DateTime}<br />
<br />
This displays the 'UnassignableDate' column as a date instead of a string.<br />
<br />
Other commonly used '<code>Type</code>' values are: '<code>Boolean</code>', '<code>Decimal</code>' and '<code>PartnerKey</code>'.<br />
<br />
=====Details (Bottom) Part=====<br />
The Details part consists of a Panel, 'pnlDetails', on which several Controls are placed. Each of these Controls represents a data field of the database table which your particular screen is maintaining. <br />
<br />
As the database tables have different data fields, the Controls and the type of Controls (e.g. TextBoxes, CheckBoxes, ...) will be different on each Maintain Table screen. You need to specify the data fields that make up the Controls. These will be at least the data fields that are used for the Columns of the Grid of your screen, but possibly more, if you chose to leave out some Columns in the Grid for the data fields of the database table which your particular screen is maintaining.<br />
<br />
The next section describes the process of placing the controls in the Panel and how to influence the arrangement of the Controls on the Panel.<br />
<br />
====Data Fields====<br />
The description of how to add the data fields can be broken down into two aspects: <br />
# overall arrangement and layout<br />
# layout of the individual data fields<br />
<br />
=====Overall Arrangement and Layout=====<br />
This is best explained by first showing some example lines of a yaml file:<br />
pnlDetails:<br />
Dock: Bottom<br />
Controls:<br />
Row0: [txtDetailAbilityAreaName, txtDetailAbilityAreaDescr]<br />
Row1: [chkDetailUnassignableFlag, dtpDetailUnassignableDate]<br />
Row2: [chkDetailDeletableFlag]<br />
<br />
* '<code>pnlDetails'</code> is the Panel that holds all the Controls below the Grid. <br />
* All the Controls are arranged in invisible rows and columns in an invisible layout table (much like a web page Table in HTML).<br />
** A new Row is started by having an Element '<code>Row''X''</code>' (where ''X'' is a number starting at 0 for row 1) one indentation level deeper than the '<code>Controls</code> Element.<br />
*** Most Maintain Table screens will have three to five Rows. There is a minimum of one Row.<br />
** The '<code>Row''X''</code>' Element is followed by an opening bracket '[', then by a list of Controls separated by commas ',' and is ended with a closing bracket ']' (see 'Row0' and 'Row1' specification in the above example).<br />
*** In case there is only one Control in a Row, no comma must be put after this Control (see 'Row2' specification in the above example)<br />
**** The Control '<code>chkDetailDeletable</code>' (or a Control that is named differently [e.g. '<code>chkDetailDeletableFlag</code>' in the example above]), which is bound to a DB Table column that designates whether a record is deletable by the user, ''should always be put on its own in a separate Row at the end of all the other Rows!'' This is in order to maintain a consistent layout across the many Maintain Table screens.<br />
** Controls which should appear next to each other in a line need to be in the same '<code>Row''X''</code>' Element.<br />
** The invisible layout table is auto-sizing the column widths and row heights, which results in a good automatic layout in many cases.<br />
<br />
More information can be found [[https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Screen_scaffolding:_controls#Arranging_Controls here]].<br />
<br />
=====Layout of the Individual Data Fields=====<br />
Follwing the '<code>pnlDetail</code>' Element are the detail definitions of the Controls which were listed in the Row''X'' lines.<br />
<br />
This is again best explained by showing some example lines of a yaml file:<br />
txtDetailAbilityAreaName: {Label=Ability Area, CharacterCasing=Upper}<br />
txtDetailAbilityAreaDescr: {Label=Description, Width=250}<br />
chkDetailUnassignableFlag: {Label=Unassignable, OnChange=EnableDisableUnassignableDate}<br />
dtpDetailUnassignableDate: {Label=Unassignable Date, Enabled=false}<br />
chkDetailDeletableFlag: {Label=Deletable}<br />
<br />
It is necessary to list all the Controls which are mentioned in one of the Row''X'' lines! If there is a Control where you don't need to specify any Attributes (such as Label or Width) it still needs to be listed in a separate line in the following way: '<code>txtMyText:</code>'<br />
<br />
More information about the many layout options can be found [[https://sourceforge.net/apps/mediawiki/openpetraorg/index.php?title=Screen_scaffolding:_controls#Layout_of_Controls here]].<br />
<br />
<br />
==Step 4: Generating the screen's source code with the WinForms Generator==<br />
* Open a Command Prompt (a.k.a. 'DOS Window').<br />
* enter the following commands:<br />
U: <ENTER><br />
cd \openpetraorg\''NameOfYourFeatureBranch'' <ENTER><br />
* after that, verify that the 'nant' build system is working by entering<br />
nant help <ENTER><br />
* you should see a list of possible commands and their explanations on the screen<br />
** if you get an error message, then the setup of the development environment is not fully completed, or at least not working, on your computer. Refer to [[Setup_of_Development_Environment_for_Windows#NAnt]] for instructions to set nant up correctly.<br />
* enter the following command to go to the directory from which you can execute the WinForms Generator<br />
cd csharp\ICT\Petra\Client<br />
* enter the following command<br />
nant generateWinform -D:file=MPartner/gui/setup/YourYamlFileSetup.yaml<br />
- potentially replacing 'MPartner' with the name of another openPETRA Module, and replacing 'YourYamlFileSetup.yaml' with the actual name of your new yaml file.<br />
* the WinForms Generator will launch and process your new yaml file.<br />
** if the Generator continues to build a C# project and then launches the openPETRA Client, your yaml file doesn't contain any 'bad' errors.<br />
** if the Generator stops and issues an error message: try to find out and fix what is wrong, according to the text of the error message.<br />
** in case the Generator stops with an Exception, check the overall structure of your yaml file for any potential errors, such as: missing or misplaced brackets ('[' and ']') or curly braces ('{' or '}'), wrong indentation, missing colons (':') or missing or superfluous commas (',') or space characters (' ').<br />
** fix what you think is wrong and run the Generator again, until the Generator continues to build a C# project.<br />
** if you are 'stuck', seek help from other developers in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer area in the openPETRA Forums].<br />
<br />
==Step 5: Adding new source code files to corresponding C# Project==<br />
===Step 5a: Adding the generated files===<br />
The generated files now need to be added to the C# Project in which they belong so they can get compiled.<br />
<br />
* Start the SharpDevelop IDE<br />
* Run the Menu Command 'File' -> 'Open' -> 'Project/Solution...'<br />
* Select the file<br />
\openpetraorg\''NameOfYourFeatureBranch''\delivery\projects\sharpdevelop4\OpenPetra.Client.sln<br />
and choose 'Open'.<br />
* SharpDevelop will open a group of C# Projects that contain all the client-side program code of openPETRA. (Such a group of Projects is called a 'Solution', hence the '.sln' file extension.)<br />
* In the 'Projects' list, locate the C# Project that should contain the new Maintain Table screen. <br />
** The C# Project you need to choose will depend on where your new yaml file is in the folder structure of openPETRA.<br />
*** Example: if your new yaml file is located in U:\openpetraorg\''NameOfYourFeatureBranch''\csharp\ICT\Petra\Client\MPartner\gui\setup, then the corresponding C# Project file is called Ict.Petra.Client.MPartner.Gui.Setup<br />
* Right-click on the correct C# Project in SharpDevelop and choose 'Add' -> 'Existing Item...'<br />
* Locate the C# file that the Generator created and choose 'Open'. <br />
** The C# file is in the same folder as your new yaml file and is called the same, except that it's file extension is .cs, and not .yaml. <br />
*** Example: if the yaml file of the new screen is called 'LocationTypeSetup.yaml', the file that you should choose will be called 'LocationTypeSetup.cs'. (Be sure ''not'' to select the file that ends in '.Designer.cs'!) <br />
* Expand the C# Project by clicking on the '+' symbol in front of it.<br />
** You should now see a few nodes. One of that node is called like the C# file, with a '+' symbol in front of it.<br />
* Expand that node by clicking on the '+' symbol.<br />
** You will see that additional files got added automatically - one that is called like your C# file, but with the file extension '.Designer.cs', and a file that is called like your C# file, but with the file extension '.resx'. Those file were created by the WinForms Generator and are necessary for the form (but you will never need to touch them!).<br />
<br />
===Step 5b: Creation and adding of the *.ManualCode.cs file ===<br />
* Right-click on the node that represents your Maintain Table's C# file (this is the one you just expanded) and choose 'Add' -> 'Existing Item as Dependent Item...'.<br />
* In the 'Add existing files' dialog you will make a copy of an existing file before adding it:<br />
** Locate a file that is called like the yaml file of the existing, similar screen that you started off with, except that its file extension is '.ManualCode.cs' instead of '.yaml'. <br />
*** Example: if the yaml file of the existing, similar screen is called 'PartnerTypeSetup.yaml', the file that you should copy will be called 'PartnerTypeSetup.ManualCode.cs'.<br />
** Copy that file (e.g. by using the Context Menu entries 'Copy' and 'Paste') and rename the resulting file (e.g. by using the Context Menu entry 'Rename'):<br />
*** The name of the file should be like the file name of your new yaml file, except that the file extension should be '.ManualCode.cs' instead of '.yaml'.<br />
**** Example: if the new yaml file is called 'LocationTypeSetup.yaml', the new file name should be 'LocationTypeSetup.ManualCode.cs'.<br />
*** Be very careful when renaming the file: the first part of the name needs to exactly match the name of the yaml file, and it needs to end 'exactly' in '.ManualCode.cs' - if it is named only slightly different, e.g. because of a spelling mistake or a space character that shouldn't be there, the WinForms Generator will not detect this file, which will lead to problems at compilation time or run time!<br />
* Choose 'OK' to add the new '*.ManualCode.cs' file as a 'dependant item' to your form.<br />
<br />
===Step 5c: Modifying the new '*.ManualCode.cs' file ===<br />
In case the Maintain Table screen that you were copying from is nearly identical to the new screen that you are now working on, a modification of the '*.ManualCode.cs' file is likely to be unnecessary, '''except''' for replacing ''all occurrences'' of the DB Table Class Name of the existing Maintain Table screen with the DB Table Class Name of the new Maintain Table Screen (the DB Table Class Names are found in the DetailTable Element of the two YAML files!).<br />
<br />
However, if there are differences which affect more than the layout and the name of the DB Table Class there might well be the need to modify the '*.ManualCode.cs' file. As screens vary it is difficult to give general advice on what needs to be changed.<br />
Your best option in this case is to look through some other Maintain Table Screen's '*.ManualCode.cs' files to see what is in there and what particular things are addressed in them. Copy code lines or whole Methods which seem relevant to your screen as well and 'translate' those code lines into your situation (e.g. replacing the names of Controls). ''It is important to re-run the Generator after adding new Methods so it can 'wire them up' to the supporting framework of the screen, which ensures that they are actually called at runtime!''<br />
<br />
====Explanation of Commonly Used Methods in the ManualCode.cs File====<br />
* '<code>RunOnceOnActivationManual</code>' is necessary to prevent the user from changing the value of the Controls such as '<code>chkDetailDeletableFlag</code>'. The WinForms Generator does this automatically if a Control named '<code>chkDetailDeletable</code>' exists, but if the database field is named differently (for example if it ends with the suffix '<code>_flag_l</code>' then the Control would end with the suffix '<code>...Flag</code>'), the Generator cannot find it and therefore not deactivate it automatically.<br />
* '<code>EnableDisableUnassignableDate</code>' is enabling/disabling as well as clearing the content of Controls such as '<code>dtpDetailUnassignableDate</code>' if the user is changing the value of a related CheckBox Control such as '<code>chkDetailUnassignableFlag</code>'.<br />
* '<code>GetDetailDataFromControlsManual</code>': This method is needed ''only'' in case a column in a DB Table has the constraint 'NOT NULL' ''and'' if this column is not put on the Maintain Table screen. Under those circumstances an Exception would be thrown in case the user would try to save changed data using the 'Save' button. The reason for that is that openPETRA wouldn't assign a value to that DB Table column (not even empty string, "") as it is not used in the screen. '<code>GetDetailDataFromControlsManual</code>' gets around this problem by manually assigning an empty string value to such DB Table columns before the changed data is sent to the PetraServer for saving.<br />
<br />
If you don't get to where you think you need to get to or get errors at compile time or runtime, seek help from other openPETRA developers by posting your problem in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Area in the openPETRA Forum].<br />
<br />
===Step 5d: Compile C# Project ===<br />
* Right-click on the C# Project you are working with and choose 'Build'.<br />
** The IDE will compile any dependent projects and finally the C# Project you are working with.<br />
** If no errors are shown, you can continue with the next step.<br />
** If errors are shown, try to solve them by going again over the list of things that need to be changed in the *.ManualCode.cs file (Step 5c) and by checking for any general C# syntax errors. If you still get errors after getting rid of any errors you were able to fix for yourself, seek help from other openPETRA developers by posting your problem in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Area in the openPETRA Forum].<br />
<br />
<br />
==Step 6: Adding the new screen to the openPETRA main menu structure==<br />
* If you haven't got the following file still open, open it in a text editor (e.g. Notepad, Notepad++):<br />
U:\openpetraorg\''NameOfYourFeatureBranch''\csharp\ICT\Petra\Definitions\UINavigation.yml<br />
* Decide where your new screen should show up in the Navigation in the openPETRA Main Window:<br />
** We recommend that you start the openPETRA Client at that stage.<br />
*** Have a look at the Module, Sub-Module, ''Setup Area'' and Tasks that you might have already in mind. Check what Tasks are already there and decide whether your new screen should be listed among the existing Tasks, or not. If not, keep on looking for a more suitable place in the menu structure, or, if you can't find one, decide on the name of a new Task Grouping in an existing 'Setup Area' that fits best.<br />
*** Your new screen should usually be listed among Tasks of a fitting ''Setup Area''. If you think it should not go in a 'Setup Area', it is best to ask in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Area of the openPETRA Forum] for guidance.<br />
* Scroll through the <code>UINavigation.yml</code> file until you find the Module, Sub-Module, Area, Task Group where your new screen should be listed.<br />
* Choose any existing Task's text line in that Task Group and copy the whole text line.<br />
* Paste the copied text line in the place where you want your new screen to show up.<br />
** In case your screen should be displayed in a new Task Group, create a new Task Group by putting the name of the new Task Group in a separate line *before* the line of your new screen, followed by a colon (':'). Outdent (=the opposite of indent) the line for the new Task Group so that it starts in the same text column as other Task Groups do.<br />
* Modify the pasted text line<br />
** Change the text before the colon (':') so it reflects ''what'' your Maintain Table screen is maintaining. Leave out any space characters and capitalise the first letter of every word.<br />
*** Example: if your new Maintain Table screen is maintaining 'Location Types', change the text to 'LocationTypes'.<br />
** Change the text that follows 'Label=' to match how other Maintain Screens are showing up in the Task List.<br />
*** Example: if your new Maintain Table screen is maintaining 'Location Types', change the text to 'Setup Location Types'.<br />
** Change the text that follows 'Description=' to match how other Maintain Screens are described in the Task List.<br />
*** Example: if your new Maintain Table screen is maintaining 'Location Types', change the text to 'Maintain Location Types'.<br />
** Change the text that follows 'ActionOpenScreen' to match the ''Class Name'' of your new screen.<br />
*** You can find out the Class Name by looking it up in the *.ManualCode.cs file: look for the line that starts with 'public partial class '. The text that follows that declaration is the Class Name of your new screen.<br />
*** Example: if your new Maintain Table screen is maintaining 'Location Types', the Class Name is most likely 'TFrmLocationTypeSetup'.<br />
* Close the openPETRA Client, if you have it open.<br />
<br />
<br />
==Step 7: Opening the new screen in openPETRA for the first time :-)==<br />
* Start the openPETRA Client.<br />
* Go to the Module, Sub-Module and Setup Area to which you have added your new screen (in Step 6).<br />
* Ensure that the Task for your new screen is listed, and that is in the Task Group that you want it in.<br />
** If you can't see your new screen listed, check back in the <code>UINavigation.yaml</code> file to see where you put the text line that defines the Task for your new screen, and move the text line of your new screen to a text line of the Setup Area and Task Group that you wanted to see it appearing in. Restart the openPETRA Client to see if the change made the difference you wanted.<br />
** If you still can't see your new screen listed where you want it to appear, seek help from other openPETRA developers in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Forum in the openPETRA Forum].<br />
* Click on the Task for your new screen.<br />
** Your new Maintain Table screen should open and display a list of entries.<br />
*** If the screen opens: ''congratulations'', you have created and added your first Maintain Table screen to openPETRA ''':-)'''<br />
*** If the screen ''does not'' open: check the Status Bar of the Main Window of openPETRA for a message. That message should help you in finding the problem.<br />
**** The most likely cause for a screen not opening is that the Class Name and/or the Namespace in the <code>UINavigation.yaml</code> file are not correctly specified.<br />
***** Check the Class Name in the text line that defines your new screen and correct it if it is wrong. If you corrected it, save the <code>UINavigation.yaml</code> file and restart openPETRA. Check whether the screen opens after this change.<br />
***** Check the Namespace.<br />
****** The Namespace of a screen is specified by the word 'Namespace=', followed by text that denotes the exact Namespace in which the screen is located. <br />
****** Ensure that the text that follows the word 'Namespace=' specifies the namespace of your screen: switch back to the SharpDevelop IDE and bring up the *.ManualCode.cs file. Search for the line that starts with 'namespace '. Check the text that follows and compare it with the text after the word 'Namespace='.<br />
****** The word 'Namespace=' will most likely ''not'' appear in the text line that defines your new screen, but one or two steps higher in the hierarchy.<br />
******* If it appears one or two steps higher in the hierarchy and it fits the namespace declaration of your screen's *.ManualCode.cs file, ensure that there is no 'Namespace=' defined in the text line that defines your new screen.<br />
******* If it appears in the text line that defines your new screen, check that it is correct, and whether it is needed there at all - if the word 'Namespace=' appears one or two steps higher in the hierarchy and it fits the namespace declaration of your screen's *.ManualCode.cs file, then you should remove the 'Namespace=' declaration in the text line that defines your new screen because it is superfluous.<br />
****** If you corrected the Namespace, save the <code>UINavigation.yaml</code> file and restart the openPETRA Client. Check whether the screen opens after this change.<br />
*** If the screen does not open after your modifications (or the Class Name and the Namespace declarations in the <code>UINavigation.yaml</code> file seem to be right), seek help from other openPETRA developers in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Forum in the openPETRA Forum].<br />
<br />
<br />
==Step 8: Iterations: adjusting to needs, re-generate screen, re-open screen==<br />
* Once your new Maintain Table screen opens, it is time to check whether it produces the correct result by checking the following:<br />
** Screen<br />
*** Check that the screen's title is correct.<br />
**** It should follow the format 'Maintain xxx', where 'xxx' is the name that the user knows for the entries of the DB table, in plural.<br />
***** Example: if your new Maintain Table screen maintains 'Location Types', the screen's title should read 'Maintain Location Types'.<br />
*** Check that the size of the screen is appropriate.<br />
**** The width of the screen should be so that at least the first four columns are displayed without the need of scrolling to the right.<br />
**** The height of the screen should be so that at least 15-20 rows are displayed, or, if there are generally less entries in the DB table, that there isn't too much empty room (no more than for 4-5 lines) at the bottom of the list.<br />
** List<br />
*** Check that all the columns are displayed that should be displayed.<br />
*** Check that all the columns have correct Headings.<br />
*** Check that all the columns have the correct display format (e.g. plain text, CheckBox, Date, etc.).<br />
** Details section<br />
*** Check that all the Controls are displayed that should be displayed.<br />
*** Check that the Labels for all the Controls are correct.<br />
*** Check that the layout of the Labels and Controls closely follows the layout of other, similar Maintain Table screens.<br />
*** Check that appropriate Controls are used for the purpose: TextBoxes, CheckBoxes, RadioButtons, ComboBoxes, etc.<br />
*** For ComboBoxes<br />
**** Check that they are populated with the correct data items.<br />
**** Check that any label text that might displayed to the right of the CheckBox isn't cut off (you might want to open the ComboBox to select the entry with the longest description for that). (If label text is cut off, you will need to specify the 'ColSpan' Attribute for the ComboBox where this is the case.)<br />
*** If the DB table has a flag that is named something like 'Deletable', e.g. 'p_deletable_l' or 'p_type_deletable_l': the CheckBox for the flag should automatically be disabled, and automatically be ticked for new records. This is because a 'set' flag indicates 'System Records' that must not be deleted by the user. On the other hand, user's must not be allowed to create 'System Records'.<br />
**** If the flag is called 'p_deletable_l', the disabling of the CheckBox should happen automatically. Please verify that this is the case.<br />
**** If the flag is called something else than 'p_deletable_l', the disabling of the CheckBox needs to be done manually:<br />
***** Add the following Attribute to the Control definition in the yaml file:<br />
Enabled=false<br />
'''or'''<br />
Enabled: false<br />
** Buttons<br />
*** Check that the 'New' Button and the 'New xxx' ToolBarButton work - they both should create a new record that has a default code.<br />
**** The text of the 'New' Button should always be just 'New', with no further text.<br />
**** The text of the 'New xxx' ToolBarButton should should follow the format 'New xxx', where 'xxx' is the name that the user knows for the entries of the DB table, in singular.<br />
***** Example: if your new Maintain Table screen maintains 'Location Types', the text of the 'New xxx' ToolBarButton should read 'New Location Type'.<br />
** Saving of data<br />
*** Check that data that has been changed or added can be saved by<br />
**** 1) clicking the 'Save' ToolBarButton,<br />
**** 2) closing and re-opening your new Maintain Table screen,<br />
**** 3) checking that the changed/added data is still there.<br />
***** 4) make sure you check that every Control's data is saved and displayed again correctly!<br />
<br />
* If you noticed that something needs to change, go back to the screen's yaml file, make the necessary changes, save the file and run the Generator. Then check whether the changes have the desired effect on the screen in the openPETRA Client.<br />
* If you need help with any necessary changes, seek help from other developers by posting your problem in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Area of the openPETRA Forum]. Provide as much detail as possible and attach the yaml file of your new Maintain Table screen.<br />
* If you are not sure if the layout of the screen follows the standard that most Maintain Table screens follow, make a screenshot of your new screen and seek guidance from other developers by posting your problem in the [http://apps.sourceforge.net/phpbb/openpetraorg/viewforum.php?f=3 Developer Area of the openPETRA Forum]. Attach the screenshot and the yaml file of your new Maintain Table screen.<br />
* Repeat the steps above until you are satisfied with the new Maintain Table screen.<br />
<br />
Once you are happy with the appearance of the screen and how it works, you can move on to the next step!<br />
<br />
<br />
==Step 9: Commit new screen's files to your local Bazaar repository==<br />
TODO<br />
<br />
<br />
==Step 10: Integration of new screen into official openPETRA Bazaar repository ==<br />
There are two options, depending on whether you have or haven't write access to the official openPETRA Bazaar repository.<br />
<br />
''You can follow the instructions of 'Option B' only if you have write access to the official openPETRA Bazaar repository.'' If you don't, then you have to follow the instructions of 'Option A'.<br />
<br />
===Step 10, Option A: Creating a Patch and sending the Patch to the openPETRA core development team===<br />
One option to do this would be using launchpad. Please see [[How_to_commit_to_launchpad]] for further information.<br />
<br />
===Step 10, Option B: Committing the new screen's files directly to the openPETRA Bazaar repository===<br />
TODO</div>Joejoe2010https://wiki.openpetra.org/index.php?title=SourceGrid_specification_and_testing&diff=3089SourceGrid specification and testing2012-07-19T04:04:15Z<p>Joejoe2010: </p>
<hr />
<div>The SourceGrid control and its implementation in OpenPetra, has required that modifications be made to its event handling to ensure consistent and predictable event firing in relation to selecting, adding, deleting, sorting and saving rows in the grid. This includes detecting and cancelling repeating and unwanted events (mainly FocusRowLeaving event) and invoking events (mainly FocusedRowChanged) when no event is fired (when it should be). Below are the changes that have been introduced to the grid, the grid wrapper and the templates that affect use of the grid throughtout OpenPetra.<br />
<br />
== Event Handling ==<br />
The two events that have been the focus of the changes to the grid-related code are FocusRowLeaving (when the currently selected row loses focus) and FocusRowChanged (when a new row receives focus).<br />
<br />
===Event - Keyboard handling===<br />
The grid fires row-level events when the grid itself loses focus even though the current row had not changed. I remmed out two lines of code in the SourceGrid code that related to the user tabbing away or clicking away from the entire grid itself to stop the firing of these events. No other in-grid events are affected. Here are the changes found in GridVirtual.cs:<br />
<br />
<pre><br />
protected override void OnValidated(EventArgs e)<br />
{<br />
base.OnValidated(e);<br />
<br />
//NOTE: I use OnValidated and not OnLostFocus because is not called when the focus is on another child control<br />
// (for example an editor control) or OnLeave because before Validating event and so the validation can still be stopped<br />
<br />
if ((Selection.FocusStyle & FocusStyle.RemoveFocusCellOnLeave) == FocusStyle.RemoveFocusCellOnLeave)<br />
{<br />
//Changed by CT - 2012-07-03<br />
//Selection.Focus(Position.Empty, false);<br />
}<br />
<br />
if ((Selection.FocusStyle & FocusStyle.RemoveSelectionOnLeave) == FocusStyle.RemoveSelectionOnLeave)<br />
{<br />
//Changed by CT - 2012-07-03<br />
//Selection.ResetSelection(true);<br />
}<br />
}<br />
</pre><br />
<br />
The grid now responds to the INS and DEL key presses on the keyboard and attempts a row insert and delete respectively. To do this, it looks for the existence on the form of buttons called btnNew and btnDelete and executes their click event accordingly. To access this functionality, you obviously need the buttons named correctly, but this doesn't stop you changing the label of the button if New or Delete do not best fit the form's context, e.g. the GL Batch form uses buttons with labels Add and Cancel.<br />
<br />
Here is a typical yaml file section for the two buttons:<br />
<pre><br />
Actions:<br />
actNew: {Label=&New, ActionClick=NewRecord}<br />
actDelete: {Label=&Delete, ActionClick=DeleteRecord}<br />
Controls:<br />
pnlContent:<br />
Controls: [pnlGrid, pnlDetails]<br />
Dock: Fill<br />
pnlGrid:<br />
Dock: Fill<br />
Controls: [grdDetails, pnlButtons]<br />
pnlButtons:<br />
Dock: Right<br />
Controls: [btnNew, btnDelete]<br />
btnNew:<br />
Action: actNew<br />
btnDelete:<br />
Action: actDelete<br />
<br />
</pre><br />
And then in the manual code, you call the generated code to create/delete a record:<br />
<pre><br />
private void NewRecord(Object sender, EventArgs e)<br />
{<br />
CreateNewPInternationalPostalType();<br />
}<br />
<br />
private void DeleteRecord(Object sender, EventArgs e)<br />
{<br />
DeletePInternationalPostalType();<br />
}<br />
</pre><br />
<br />
===Event - FocusRowLeaving===<br />
This is the even that fires most often and needs to be curtailed and checked for repeats. Here's the code from the template with supporting methods etc.:<br />
<br />
<pre><br />
private bool FInitialFocusEventCompleted = false;<br />
private bool FNewFocusEvent = false;<br />
private bool FRepeatLeaveEventDetected = false;<br />
private int FDetailGridRowsCountPrevious = 0;<br />
private int FDetailGridRowsCountCurrent = 0;<br />
private int FDetailGridRowsChangedState = 0;<br />
<br />
private void FocusPreparation(bool AIsLeaveEvent)<br />
{<br />
if (FRepeatLeaveEventDetected)<br />
{<br />
return;<br />
}<br />
<br />
FDetailGridRowsCountCurrent = grdDetails.Rows.Count;<br />
<br />
//first run only<br />
if (!FInitialFocusEventCompleted)<br />
{<br />
FInitialFocusEventCompleted = true;<br />
FDetailGridRowsCountPrevious = FDetailGridRowsCountCurrent;<br />
}<br />
<br />
//Specify if it is a row change, add or delete<br />
if (FDetailGridRowsCountPrevious == FDetailGridRowsCountCurrent)<br />
{<br />
FDetailGridRowsChangedState = 0;<br />
}<br />
else if (FDetailGridRowsCountPrevious > FDetailGridRowsCountCurrent)<br />
{<br />
FDetailGridRowsCountPrevious = FDetailGridRowsCountCurrent;<br />
FDetailGridRowsChangedState = -1;<br />
}<br />
else if (FDetailGridRowsCountPrevious < FDetailGridRowsCountCurrent)<br />
{<br />
FDetailGridRowsCountPrevious = FDetailGridRowsCountCurrent;<br />
FDetailGridRowsChangedState = 1;<br />
}<br />
<br />
}<br />
<br />
private void InvokeFocusedRowChanged(int AGridRowNumber)<br />
{<br />
SourceGrid.RowEventArgs rowArgs = new SourceGrid.RowEventArgs(AGridRowNumber);<br />
FocusedRowChanged(grdDetails, rowArgs);<br />
}<br />
<br />
private void FocusRowLeaving(object sender, SourceGrid.RowCancelEventArgs e)<br />
{<br />
//Ignore this event if currently sorting<br />
if (grdDetails.Sorting)<br />
{<br />
FNewFocusEvent = false;<br />
return;<br />
}<br />
<br />
if (FNewFocusEvent == false)<br />
{<br />
FNewFocusEvent = true;<br />
}<br />
<br />
FocusPreparation(true);<br />
<br />
if (!FRepeatLeaveEventDetected)<br />
{<br />
FRepeatLeaveEventDetected = true;<br />
<br />
if (FDetailGridRowsChangedState == -1 || FDetailGridRowsCountCurrent == 2) //do not run validation if cancelling current row<br />
// OR only 1 row present so no rowleaving event possible<br />
{<br />
e.Cancel = true;<br />
}<br />
<br />
Console.WriteLine("FocusRowLeaving");<br />
<br />
if (!ValidateAllData(true, true))<br />
{<br />
e.Cancel = true;<br />
}<br />
}<br />
else<br />
{<br />
// Reset flag<br />
FRepeatLeaveEventDetected = false;<br />
e.Cancel = true;<br />
}<br />
}<br />
</pre><br />
<br />
Basically, the supporting code needs to identify the user action and behave accordingly, this includes selecting, sorting, adding and deleting rows. The InvokeFocusedRowChanged() method allows the calling of the FocusedRowChanged event code when it needs to be called manually.<br />
<br />
<pre><br />
private void FocusedRowChanged(System.Object sender, SourceGrid.RowEventArgs e)<br />
{<br />
FNewRecordUnsavedInFocus = false;<br />
<br />
FRepeatLeaveEventDetected = false;<br />
<br />
if (!grdDetails.Sorting)<br />
{<br />
//Sometimes, FocusedRowChanged get called without FocusRowLeaving<br />
// so need to handle that<br />
if (!FNewFocusEvent)<br />
{<br />
//This implies start of a new event chain without a previous FocusRowLeaving<br />
FocusPreparation(false);<br />
}<br />
<br />
//Only allow, row change, add or delete, not repeat events from grid changing focus<br />
if(e.Row != FCurrentRow && FDetailGridRowsChangedState == 0)<br />
{<br />
// Transfer data from Controls into the DataTable<br />
if (FPreviouslySelectedDetailRow != null)<br />
{<br />
GetDetailsFromControls(FPreviouslySelectedDetailRow);<br />
}<br />
<br />
// Display the details of the currently selected Row<br />
FPreviouslySelectedDetailRow = GetSelectedDetailRow();<br />
ShowDetails(FPreviouslySelectedDetailRow);<br />
pnlDetails.Enabled = true;<br />
}<br />
else if (FDetailGridRowsChangedState == 1) //Addition<br />
{<br />
<br />
}<br />
else if (FDetailGridRowsChangedState == -1) //Deletion<br />
{<br />
if (FDetailGridRowsCountCurrent > 1) //Implies at least one record still left<br />
{<br />
int nextRowToSelect = e.Row;<br />
//If last row deleted, subtract row index to select by 1<br />
if (nextRowToSelect == FDetailGridRowsCountCurrent)<br />
{<br />
nextRowToSelect--;<br />
}<br />
// Select and display the details of the currently selected Row without causing an event<br />
grdDetails.SelectRowInGrid(nextRowToSelect, TSgrdDataGrid.TInvokeGridFocusEventEnum.NoFocusEvent);<br />
FPreviouslySelectedDetailRow = GetSelectedDetailRow();<br />
ShowDetails(FPreviouslySelectedDetailRow);<br />
pnlDetails.Enabled = true;<br />
}<br />
else<br />
{<br />
e.Row = 0;<br />
FPreviouslySelectedDetailRow = null;<br />
pnlDetails.Enabled = false;<br />
}<br />
}<br />
}<br />
<br />
FCurrentRow = e.Row;<br />
<br />
//Event chain tidy-up<br />
FDetailGridRowsChangedState = 0;<br />
FNewFocusEvent = false;<br />
}<br />
</pre><br />
<br />
The above event ensures the correlation between the FCurrentRow variable and the current row, especially during sorting etc., and it also ensures, on a delete, that the record at the same index position (as determined by sort order) or 1 above is always chosen.<br />
<br />
==Adding Rows==<br />
Where the form templates contain code for adding records to the grid, changes have had to be made to control event firing. Here is an example:<br />
<br />
<pre><br />
private bool FNewRecordUnsavedInFocus = false;<br />
<br />
/// automatically generated, create a new record of {#DETAILTABLE} and display on the edit screen<br />
/// we create the table locally, no dataset<br />
public bool CreateNew{#DETAILTABLE}()<br />
{<br />
if(ValidateAllData(true, true))<br />
{ <br />
{#DETAILTABLE}Row NewRow = FMainDS.{#DETAILTABLE}.NewRowTyped();<br />
{#INITNEWROWMANUAL}<br />
FMainDS.{#DETAILTABLE}.Rows.Add(NewRow);<br />
<br />
FPetraUtilsObject.SetChangedFlag();<br />
<br />
grdDetails.DataSource = null;<br />
grdDetails.DataSource = new DevAge.ComponentModel.BoundDataView(FMainDS.{#DETAILTABLE}.DefaultView);<br />
<br />
SelectDetailRowByDataTableIndex(FMainDS.{#DETAILTABLE}.Rows.Count - 1);<br />
InvokeFocusedRowChanged(grdDetails.SelectedRowIndex());<br />
<br />
//Must be set after the FocusRowChanged event is called as it sets this flag to false<br />
FNewRecordUnsavedInFocus = true;<br />
<br />
FPreviouslySelectedDetailRow = GetSelectedDetailRow();<br />
ShowDetails(FPreviouslySelectedDetailRow);<br />
<br />
Control[] pnl = this.Controls.Find("pnlDetails", true);<br />
if (pnl.Length > 0)<br />
{<br />
//Look for Key & Description fields<br />
bool keyFieldFound = false;<br />
foreach (Control detailsCtrl in pnl[0].Controls)<br />
{<br />
if (!keyFieldFound && (detailsCtrl is TextBox || detailsCtrl is ComboBox))<br />
{<br />
keyFieldFound = true;<br />
detailsCtrl.Focus();<br />
}<br />
<br />
if (detailsCtrl is TextBox && detailsCtrl.Name.Contains("Descr") && detailsCtrl.Text == string.Empty)<br />
{<br />
detailsCtrl.Text = "PLEASE ENTER DESCRIPTION";<br />
break;<br />
}<br />
}<br />
<br />
GetDetailsFromControls(FPreviouslySelectedDetailRow);<br />
}<br />
<br />
return true;<br />
}<br />
else<br />
{<br />
return false;<br />
}<br />
}<br />
</pre><br />
You will notice that the grid's DataSource needed to be set to Null before being reset. This ensured removal of focus from a cell on the previous row. The code also invokes the FocusedRowChanged event as well as sending focus to the new row irrespective of sorting and then gives focus to the key value field and populates the description field if it exists.<br />
<br />
Also in another template method: SelectDetailRowByDataTableIndex(), the last line is changed that calls a new signature method in the wrapper that selects the specified row but without firing any events. The enumerator allows you to specify the event you would like to fire.<br />
<br />
grdDetails.SelectRowInGrid(RowNumberGrid, TSgrdDataGrid.TInvokeGridFocusEventEnum.NoFocusEvent);<br />
<br />
==Deleting Rows==<br />
The code for deleting rows is now in the templates:<br />
<br />
<pre><br />
private void Delete{#DETAILTABLE}()<br />
{<br />
bool allowDeletion = true;<br />
bool deletionPerformed = false;<br />
string deletionQuestion = Catalog.GetString("Are you sure you want to delete the current row?");<br />
string completionMessage = string.Empty;<br />
<br />
if (FPreviouslySelectedDetailRow == null)<br />
{<br />
return;<br />
}<br />
<br />
int rowIndexToDelete = grdDetails.SelectedRowIndex();<br />
{#DETAILTABLETYPE}Row rowToDelete = GetSelectedDetailRow();<br />
<br />
{#PREDELETEMANUAL}<br />
<br />
if(allowDeletion)<br />
{<br />
if ((MessageBox.Show(deletionQuestion,<br />
Catalog.GetString("Confirm Delete"),<br />
MessageBoxButtons.YesNo,<br />
MessageBoxIcon.Question) == System.Windows.Forms.DialogResult.Yes))<br />
{<br />
{#IFDEF DELETEROWMANUAL}<br />
{#DELETEROWMANUAL}<br />
{#ENDIF DELETEROWMANUAL}<br />
{#IFNDEF DELETEROWMANUAL} <br />
rowToDelete.Delete();<br />
deletionPerformed = true;<br />
{#ENDIFN DELETEROWMANUAL} <br />
<br />
FPetraUtilsObject.SetChangedFlag();<br />
//Select and call the event that doesn't occur automatically<br />
InvokeFocusedRowChanged(rowIndexToDelete);<br />
}<br />
}<br />
<br />
{#IFDEF POSTDELETEMANUAL}<br />
{#POSTDELETEMANUAL}<br />
{#ENDIF POSTDELETEMANUAL}<br />
{#IFNDEF POSTDELETEMANUAL}<br />
if(deletionPerformed && completionMessage.Length > 0)<br />
{<br />
MessageBox.Show(completionMessage,<br />
Catalog.GetString("Deletion Completed"));<br />
}<br />
{#ENDIFN POSTDELETEMANUAL}<br />
<br />
}<br />
</pre><br />
The autogenerated Delete{#DETAILTABLE} procedure can call up to 3 optional manual code methods that control the deletion process (see code below for example with description of arguments etc.):<br />
<br />
<pre><br />
/// <summary><br />
/// Performs checks to determine whether a deletion of the current<br />
/// row is permissable<br />
/// </summary><br />
/// <param name="ARowToDelete">the currently selected row to be deleted</param><br />
/// <param name="ADeletionQuestion">can be changed to a context-sensitive deletion confirmation question</param><br />
/// <returns>true if user is permitted and able to delete the current row</returns><br />
private bool PreDeleteManual(ref PInternationalPostalTypeRow ARowToDelete, ref string ADeletionQuestion)<br />
{<br />
/*Code to execute before the delete can take place*/<br />
ADeletionQuestion = String.Format(Catalog.GetString("Are you sure you want to delete Postal Type Code: '{0}'?"),<br />
ARowToDelete.InternatPostalTypeCode);<br />
return true;<br />
}<br />
<br />
/// <summary><br />
/// Deletes the current row and optionally populates a completion message<br />
/// </summary><br />
/// <param name="ARowToDelete">the currently selected row to delete</param><br />
/// <param name="ACompletionMessage">if specified, is the deletion completion message</param><br />
/// <returns>true if row deletion is successful</returns><br />
private bool DeleteRowManual(ref PInternationalPostalTypeRow ARowToDelete, out string ACompletionMessage)<br />
{<br />
bool deletionSuccessful = false;<br />
<br />
try<br />
{<br />
//Must set the message parameters before the delete is performed if requiring any of the row values<br />
ACompletionMessage = String.Format(Catalog.GetString("Postal Type Code: '{0}' deleted successfully."),<br />
ARowToDelete.InternatPostalTypeCode);<br />
ARowToDelete.Delete();<br />
deletionSuccessful = true;<br />
}<br />
catch (Exception ex)<br />
{<br />
ACompletionMessage = ex.Message;<br />
MessageBox.Show(ex.Message,<br />
"Deletion Error",<br />
MessageBoxButtons.OK,<br />
MessageBoxIcon.Error);<br />
}<br />
<br />
return deletionSuccessful;<br />
}<br />
<br />
/// <summary><br />
/// Code to be run after the deletion process<br />
/// </summary><br />
/// <param name="ARowToDelete">the row that was/was to be deleted</param><br />
/// <param name="AAllowDeletion">whether or not the user was permitted to delete</param><br />
/// <param name="ADeletionPerformed">whether or not the deletion was performed successfully</param><br />
/// <param name="ACompletionMessage">if specified, is the deletion completion message</param><br />
private void PostDeleteManual(ref PInternationalPostalTypeRow ARowToDelete, bool AAllowDeletion, bool ADeletionPerformed, string ACompletionMessage)<br />
{<br />
/*Code to execute after the delete has occurred*/<br />
if (ADeletionPerformed && ACompletionMessage.Length > 0)<br />
{<br />
MessageBox.Show(ACompletionMessage,<br />
"Deletion Completed",<br />
MessageBoxButtons.OK,<br />
MessageBoxIcon.Information);<br />
}<br />
else if (!AAllowDeletion)<br />
{<br />
//message to user <br />
}<br />
else if (!ADeletionPerformed)<br />
{<br />
//message to user<br />
}<br />
}<br />
</pre><br />
The DeleteRowManual()'s second argument, out string ACompletionMessage (which is passed local variable completionMessage), is always sent in empty. If it is populated in the method after a successful delete and there is no PostDeleteManual() method present, then a MessageBox displaying completionMessage string will appear. If you create a PostDeleteManual() method, completionMessage is passed in as an argument.<br />
<br />
==Saving Rows==<br />
The main issue with saving was ensuring that the sorting was correct after changing the key field. To do this the following code was added to the save event in the template:<br />
<br />
<pre><br />
//The sorting will be affected when a new row is saved, so need to reselect row<br />
if (FNewRecordUnsavedInFocus)<br />
{<br />
SelectDetailRowByDataTableIndex(FMainDS.{#DETAILTABLE}.Rows.Count - 1);<br />
InvokeFocusedRowChanged(grdDetails.SelectedRowIndex());<br />
}<br />
</pre><br />
Even though the FocusRowChanged event should not be needed, it is used to display the record (which may have moved due to sorting) and keep the FCurrent variable up to date.<br />
<br />
==Grid Testing==<br />
Testing needs to be setup where we can test the grid on all its basic functions in forms derived from each of the templates.<br />
<br />
Currently, all code generated from the templates compiles and a number of basic maintain screens have been tested for correct behaviour, but a smaller stand-alone application will also be needed to test the behaviour in isolation.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Notes_about_Bazaar&diff=3065Notes about Bazaar2012-06-21T14:26:53Z<p>Joejoe2010: /* bzr: ERROR: Failed to rename ... to ...: [Error 5] Access denied */</p>
<hr />
<div>= General instructions =<br />
* [[How to work with bazaar through the GUI on Windows]]<br />
* [[How to work with bazaar on the command line]]<br />
<br />
= Administration =<br />
* We used to have our own Bazaar server. The instructions are here: [[Administration of own bazaar server]]<br />
* Today, we are using Launchpad, which allows everbody to create his own branch without involvement of any administrator<br />
<br />
= Frequently asked questions =<br />
== bzr: ERROR: Could not acquire lock (remote lock) ==<br />
This can happen when cancelling during a commit, and probably in other situations too. You will get the error the next time your are attempting to commit.<br />
<br />
Solution: open the command line console (eg. cmd.exe), and change into the directory of your branch, and run:<br />
bzr break-lock<br />
<br />
== bzr: ERROR: paramiko.SSHException: lost ssh-agent ==<br />
If you get such an error on Windows 7 64-bit then try to run pageant not as Administrator but as normal user.<br />
<br />
== Could not open a connection to your authentication agent ==<br />
If you get such an error then please have a look [http://forum.slicehost.com/comments.php?DiscussionID=3385 here] or [http://www.finrik.at/content/sshadd-could-not-open-connection-your-authentication-agent here]<br />
<br />
== bzr: ERROR: Cannot lock LockDir(...): Transport operation not possible: http does not support mkdir() ==<br />
On getting such an error you've probably been trying to use something like lp:~username instead of bzr+ssh:// <br />
<br />
Solution1: Make sure you have pageant running (not as admin) and a key loaded.<br />
<br />
Solution2: Execute "bzr launchpad-login <username>" on a command line.<br />
<br />
Solution3: Perhaps you reinstalled your system. Then you need to create a new public/private-keypair. Possibly you need to execute bzr checkout ... afterwards to apply the new key.<br />
<br />
== bzr: ERROR: Failed to rename ... to ...: [Error 5] Access denied ==<br />
If you get such en error on checking out a branch then please disable your antivirus program, delete the .bzr-folder from your local branch and try again. See [https://answers.launchpad.net/bzr/+question/133362 here] for further information.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Notes_about_Bazaar&diff=3064Notes about Bazaar2012-06-21T14:26:32Z<p>Joejoe2010: /* bzr: ERROR: Failed to rename E:/openpetra/bzr/work-543/.bzr/checkout/limbo/new-5 to E:/openpetra/bzr/work-543/csharp: [Error 5] Access denied */</p>
<hr />
<div>= General instructions =<br />
* [[How to work with bazaar through the GUI on Windows]]<br />
* [[How to work with bazaar on the command line]]<br />
<br />
= Administration =<br />
* We used to have our own Bazaar server. The instructions are here: [[Administration of own bazaar server]]<br />
* Today, we are using Launchpad, which allows everbody to create his own branch without involvement of any administrator<br />
<br />
= Frequently asked questions =<br />
== bzr: ERROR: Could not acquire lock (remote lock) ==<br />
This can happen when cancelling during a commit, and probably in other situations too. You will get the error the next time your are attempting to commit.<br />
<br />
Solution: open the command line console (eg. cmd.exe), and change into the directory of your branch, and run:<br />
bzr break-lock<br />
<br />
== bzr: ERROR: paramiko.SSHException: lost ssh-agent ==<br />
If you get such an error on Windows 7 64-bit then try to run pageant not as Administrator but as normal user.<br />
<br />
== Could not open a connection to your authentication agent ==<br />
If you get such an error then please have a look [http://forum.slicehost.com/comments.php?DiscussionID=3385 here] or [http://www.finrik.at/content/sshadd-could-not-open-connection-your-authentication-agent here]<br />
<br />
== bzr: ERROR: Cannot lock LockDir(...): Transport operation not possible: http does not support mkdir() ==<br />
On getting such an error you've probably been trying to use something like lp:~username instead of bzr+ssh:// <br />
<br />
Solution1: Make sure you have pageant running (not as admin) and a key loaded.<br />
<br />
Solution2: Execute "bzr launchpad-login <username>" on a command line.<br />
<br />
Solution3: Perhaps you reinstalled your system. Then you need to create a new public/private-keypair. Possibly you need to execute bzr checkout ... afterwards to apply the new key.<br />
<br />
== bzr: ERROR: Failed to rename ... to ...: [Error 5] Access denied ==<br />
If you get such en error then please disable your antivirus program, delete the .bzr-folder from your local branch and try again. See [https://answers.launchpad.net/bzr/+question/133362 here] for further information.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Notes_about_Bazaar&diff=3063Notes about Bazaar2012-06-21T14:25:58Z<p>Joejoe2010: </p>
<hr />
<div>= General instructions =<br />
* [[How to work with bazaar through the GUI on Windows]]<br />
* [[How to work with bazaar on the command line]]<br />
<br />
= Administration =<br />
* We used to have our own Bazaar server. The instructions are here: [[Administration of own bazaar server]]<br />
* Today, we are using Launchpad, which allows everbody to create his own branch without involvement of any administrator<br />
<br />
= Frequently asked questions =<br />
== bzr: ERROR: Could not acquire lock (remote lock) ==<br />
This can happen when cancelling during a commit, and probably in other situations too. You will get the error the next time your are attempting to commit.<br />
<br />
Solution: open the command line console (eg. cmd.exe), and change into the directory of your branch, and run:<br />
bzr break-lock<br />
<br />
== bzr: ERROR: paramiko.SSHException: lost ssh-agent ==<br />
If you get such an error on Windows 7 64-bit then try to run pageant not as Administrator but as normal user.<br />
<br />
== Could not open a connection to your authentication agent ==<br />
If you get such an error then please have a look [http://forum.slicehost.com/comments.php?DiscussionID=3385 here] or [http://www.finrik.at/content/sshadd-could-not-open-connection-your-authentication-agent here]<br />
<br />
== bzr: ERROR: Cannot lock LockDir(...): Transport operation not possible: http does not support mkdir() ==<br />
On getting such an error you've probably been trying to use something like lp:~username instead of bzr+ssh:// <br />
<br />
Solution1: Make sure you have pageant running (not as admin) and a key loaded.<br />
<br />
Solution2: Execute "bzr launchpad-login <username>" on a command line.<br />
<br />
Solution3: Perhaps you reinstalled your system. Then you need to create a new public/private-keypair. Possibly you need to execute bzr checkout ... afterwards to apply the new key.<br />
<br />
== bzr: ERROR: Failed to rename E:/openpetra/bzr/work-543/.bzr/checkout/limbo/new-5 to E:/openpetra/bzr/work-543/csharp: [Error 5] Access denied ==<br />
If you get such en error then please disable your antivirus program, delete the .bzr-folder from your local branch and try again. See [https://answers.launchpad.net/bzr/+question/133362 here] for further information.</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Translators&diff=3062Documentation for Translators2012-06-20T15:07:40Z<p>Joejoe2010: /* General information */</p>
<hr />
<div>== General information ==<br />
There are actually 3 different ways to provide some translation.<br />
<br />
1.) Using the [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1 launchpad-platform]. To be able to make changes on the translation a registration is needed. If you are not sure with a translation please check "Someone should review this translation".<br />
<br />
<br />
2.) Using poedit: The following steps are needed.<br />
<br />
- Download poedit. The Version 1.4.6 is available [http://prdownloads.sourceforge.net/poedit/poedit-1.4.6-setup.exe here]<br />
<br />
- Download the .po-file (not .mo!!) . For Spanish it is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (after a registration at launchpad)<br />
<br />
- Edit the .po-file offline<br />
<br />
- Upload it again [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
Poedit allows working faster than the first alternative. In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
<br />
3.) Converting the po-file to csv and open it fe. with Microsoft Excel<br />
<br />
This might be the easiest way to provide the items for translators which are not familiar with 1.) or 2.)<br />
<br />
Please follow these steps:<br />
<br />
- Download an actual version of toolkit [http://sourceforge.net/projects/translate/files/Translate%20Toolkit/ here]. The file should be named translate-toolkit-…-setup.exe. <br />
<br />
- Install toolkit<br />
<br />
- Open a windows command line (Win+R) and adapt your path: for example with PATH=%PATH%;E:\Program Files\Translate Toolkit<br />
<br />
- Download the actual .po-file (not .mo!!) . It is available [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+export here] (for Spanish). You need to registrate first at launchpad.<br />
<br />
- Move to the folder where the file is safed on the windows command line<br />
<br />
- Execute po2csv. For example po2csv template1_template1-es.po template1_template1-es.csv --progress=verbose --errorlevel=message<br />
<br />
- eventually: save the csv as xls<br />
<br />
- provide the csv or xls-file to your translators<br />
<br />
- when you get it back you need to save the file as csv (using UTF-8); this is especially necessary for ú, é etc used in Spanish (fe.)<br />
<br />
- Execute csv2po. For example csv2po template1_template1-es.csv template1_template1-es_rückkonvertiert.po --progress=verbose --errorlevel=message<br />
<br />
- Upload the po-file [https://translations.launchpad.net/openpetraorg/trunk/+pots/template1/es/+upload here] (for Spanish)<br />
<br />
- Then launchpad checks the file and adds it to the launchpad-platform. This can take 1 or 2 days.<br />
<br />
In order to avoid that work is done double by several translators please contact the translation team before starting: [mailto:joejoe2010(at)users.sourceforge.net joejoe2010@users.sourceforge.net]<br />
<br />
== Language specific information ==<br />
<br />
* [[Spanish translation]]<br />
<br />
== Translation documentation for Developers ==<br />
* There is documentation for developers, how to handle translations in releases etc, at [[Translation documentation for Developers]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Literature&diff=3061Literature2012-06-20T15:05:01Z<p>Joejoe2010: /* C# */</p>
<hr />
<div>== C# ==<br />
An introduction to C# can be found [http://www.mycsharp.de/wbb2/thread.php?threadid=5904 here] (in German)<br />
<br />
== NUnit ==<br />
An introduction to NUnit-Testing can be found [http://www.infotest.by/documents/Pragmatic_unit_testing.pdf here]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Literature&diff=3060Literature2012-06-20T15:03:54Z<p>Joejoe2010: Created page with '== C# == An introduction to C# can be found [http://www.mycsharp.de/wbb2/thread.php?threadid=5904 here] == NUnit == An introduction to NUnit-Testing can be found [http://www.inf…'</p>
<hr />
<div>== C# ==<br />
An introduction to C# can be found [http://www.mycsharp.de/wbb2/thread.php?threadid=5904 here]<br />
<br />
== NUnit ==<br />
An introduction to NUnit-Testing can be found [http://www.infotest.by/documents/Pragmatic_unit_testing.pdf here]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Documentation_for_Developers&diff=3059Documentation for Developers2012-06-20T15:00:22Z<p>Joejoe2010: /* Tips and Tricks */</p>
<hr />
<div>== Projects ==<br />
Please read about what needs to be done, and how to take charge of a project here:<br/><br />
[[Summary of Projects]]<br />
<br />
<br />
==Development==<br />
=== Development Environment ===<br />
* [[Setup of Development environment]]<br />
* [[OpenPetra Developer's Assistant]]<br />
<br />
=== Programming ===<br />
* [[Coding Standard and Guidelines]]<br />
* [[Explanation of Directory Structure and Rules]]<br />
* [[Useful hints regarding coding in CSharp/.net]]<br />
* [[Development with Code Generation]]<br />
* [[Build system with our own NAnt tools and tasks]]<br />
* [[Preventing/getting around circular dependency problems]]<br />
<br />
=== Development Cycle ===<br />
* [[Build System for OpenPetra]]<br />
* [[Releases and Patching]]<br />
* [[Building and maintaining customized versions of OpenPetra]]<br />
* [[Migrating data from legacy systems]]<br />
* [[Working with NUnit tests]]<br />
<br />
=== Getting Started ===<br />
* [[HowTo develop a new screen]]<br />
* [[HowTo port a screen from Old Petra]]<br />
* [[HowTo develop a new report]]<br />
* [[Report Designer]]<br />
<br />
=== Tools Used ===<br />
This is a list of software that we use; some of it you will already have installed when you did your [[Setup of Development environment]].<br />
* [[Software tools for Developers]]<br />
* [[Memory profiling]]<br />
<br />
=== Tips and Tricks ===<br />
* [[Quicker development/debugging/testing turnaround with customised PetraClient startup]]<br />
* [[Specifying custom settings in Config Files for Development]]<br />
* [[Literature]]<br />
<br />
== OpenPetra Software Architecture ==<br />
* [[Overview openPETRA architecture]] <br />
** Taken from the old Petra wiki. Should be merged with the other articles!<br />
* [[n-tier architecture]]<br />
* [[Database access architecture]]<br />
* [[openPETRA Architecture Team]]<br />
<br />
=== Client Side ===<br />
* [[GUI development]]<br />
* [[Printing]]<br />
<br />
<br />
== Bug Tracking ==<br />
See [[Contributing_Source_Code_to_OpenPetra.org#Tracking_of_Bugs_and_Things_to_do|Tracking of Bugs]]<br />
<br />
<br />
== Database Structure Documentation ==<br />
* For the current database structure, check http://openpetraorg.sourceforge.net/dbdoc (see also [[SQL Diagram creation]])<br />
** There is a [http://openpetraorg.sourceforge.net/dbdoc/img/img_AccountsPayable.html?a_ap_document diagram for the Accounts Payable sub system]<br />
** We need volunteers do design more diagrams! Please also have a look at the old 2.1 diagrams ([http://openpetraorg.sourceforge.net/Petra21DBDiagrams.zip download 9 png files in a zip file]).<br />
<br />
* [[Base and Demo databases]]<br />
<br />
<br />
== OpenPetra Specifications & Requirements ==<br />
Please have a look at the specifications and add your own requirements in the appropriate sections (eg. Wishlist):<br/><br />
[[Specifications and Requirements]]<br />
<br />
<br />
== Project Infrastructure ==<br />
* Have a look at [[wordpress]]. The OpenPetra Website is running on Wordpress.<br />
* Continuous integration with [[Jenkins CI Server]]</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Reviewing_the_translation_template&diff=2966Reviewing the translation template2012-05-14T18:00:43Z<p>Joejoe2010: </p>
<hr />
<div>The following table shows comments to some items that may be unclear for translators.<br />
Feel free to add items that are unclear for you and we'll add a comment to it later on.<br />
<br />
If an entry doesn't need translation, please add "will not be translated" and wef'll add the entry later to \trunk\i18n\donottranslate.po<br />
<br />
You can also do a full text search with Notepad++ on the *.cs files in csharp\ICT\Petra and see where the strings are used, that might give you a clue if it should be translated or not, and what the context is (if the source doesn't appear yet anyway in launchpad)<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| Mailing Code = Zip Code<br />
| this is usually a reference to table p_mailing: http://openpetraorg.sourceforge.net/dbdoc/index.html?table=p_mailing&group=mailing. When a gift is received, and you know the donor has given because you have sent him a special letter, the mailing code which clearly identifies that letter, can be entered with the gift.<br />
|-<br />
| R.List Items<br />
| this is on the PartnerFind_Options screen. you can sort items to the right or to the left side. That screen does not even open yet from the Partner Find screen, I have deactivated it for some reason, I think it was not completely working without Petra.<br />
|-<br />
| L.List Items<br />
| see above.<br />
|-<br />
| Exact Partner &Key Match<br />
| this is on the Partner Find screen<br />
|-<br />
| &Bulk Address Report<br />
| this is for mass mailing, you want to get a bulk of addresses, ie. a huge number of addresses<br />
|-<br />
| Mails&ort Label Print<br />
| Mailsort: this seems to be a UK thing: http://en.wikipedia.org/wiki/Mailsort<br />
|-<br />
| Todo<br />
| something that still needs to be implemented/realized<br />
|-<br />
| Key Partner Data<br />
| this is displayed on top of the partner edit screen, and is meant as a group heading for the most important data pieces of the partner, ie. Name, partner key, partner class, partner status, etc.<br />
|-<br />
| (trailing 0 = --*)<br />
| this is about the lblPartnerKeyNonExactMatch on partner find.<br />
|-<br />
| Select Zoom<br />
| This is also on the preview window for reports. it is a combobox for seleting "Fit to Window", "100%", "75%", "50%"<br />
|-<br />
| Extract<br />
| Extracts are a list of partners. They are used as a result from a special filter. For example you can filter all partners that have given more then 50 euros in the past 6 months, and put all their partner keys and addresses into an extract, and send a mailing to all those people.<br />
|-<br />
| Depth<br />
| This is often used on the screens where you define parameters for a report: do you want a default, or a summary, or a detail report. This is the depth of the report.<br />
|-<br />
| FD Income by Fund<br />
| FD stands for financial development, ie. to get the numbers of past donations and to understand what the donors want and what they are interested in. The FD Income by Fund report shows how much money has come in for which fund, eg. how much money did we get for Finland, Sweden, or Turkey?<br />
|-<br />
| Lapsed Donor Report<br />
| lapsed donors are donors who have previously given, but we have not received any donations anymore for a while. We have not completely lost them yet, but we might need to send them a letter to remind them that we are still here...<br />
|-<br />
| No gifts in year:<br />
| donors who didn't give gift during the year<br />
|-<br />
| SYBUNT<br />
| SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| 'Gift given in year' must be less than 'No gifts in year'<br />
| This is related to a validation error message: wrong year entered, the donor has first to have given in some year, and in the following year has stopped giving<br />
|-<br />
| Top Middle Bottom<br />
| These are for radio buttons, for top donor, middle donor, bottom donor, for the TopDonorReport.<br />
|-<br />
| New Interest Category<br />
| We have categories for grouping interests. so it is a new catgory that should be created.<br />
|-<br />
| New Partner Interest<br />
| this is about the interest, that should be created for a partner. he is interested in ... cars.<br />
|-<br />
| Value One Direction:<br />
| this is about the exchange rates. The value for GBP to USD is one direction, USD to GBP the other direction.<br />
|-<br />
| Charged Field Report<br />
| this is about conferences, and participants are coming from several countries and fields. The fields are charged for the participants that they are sending, and the participants pay directly to the field, and the field forwards to money to the conference organisers. The conference organisers know what money to charge to each field, by this report.<br />
|-<br />
| Sign Off Lines:<br />
| this is also for the field reports for a conference. Should we print a line for the signature, so it can be signed with a pen by the one responsible to pay<br />
|-<br />
| If charged field is not set:<br />
| Same report parameter screen: what should we do if we don't know which field to charge because it is not set on the participant's record<br />
|-<br />
| Fellowship Groups<br />
| The participants of a conference are organised into smaller groups during the conference, for talking in a more smaller setting<br />
|-<br />
| Discovery Groups<br />
| similar to Fellowship groups. Probably this is conference specific. you might translate it with "small groups 2"<br />
|-<br />
| Find Conference / Conference Find May the second phrase be "conference found"?<br />
| The conference find screen has the title "Conference Find". It would be better both are "Find Conference"<br />
|-<br />
| Old Field Key:<br />
| this is for gift adjustments when the recipient has changed fields, ie. the money should not go to the previous, old field, but go to the current place where the recipient is working.<br />
|-<br />
| Parsing the hash value of the batch<br />
| The hash value is a checksum of the amounts in the batch. usually just a sum of all amounts.<br />
|-<br />
| Use Ta&x Acct+CC<br />
| This is on the Accounts Payable module. For an invoice that we have to pay. Should we use the tax account and cost centre for this invoice detail? there seems to be a hard coded combination of account and cost centre for taxes.<br />
|-<br />
| Misc Defaults<br />
| Accounts Payable. Edit Supplier. Miscellaneous defaults: several defaults, that should be used on invoices from this supplier.<br />
|-<br />
| Form Letters<br />
| form letters are the same thing as mail merge, for sending many letters with predefined context, sometimes with custom content per recipient. http://en.wikipedia.org/wiki/Mail_merge<br />
|-<br />
| FinDev {0} {1}<br />
| This is used on the main screen, for the Financial Development task item. {0} and {1} will be filled with the number and the name of the ledger that the financial development module should be opened for.<br />
|-<br />
| SYBUNT Report<br />
| Related to the same thing as above. About donors that have stopped giving. LYBUNT = Last Year But Unfortunately Not This Year; SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| PETRAServer is running and listening @ {0}:{1}<br />
| Status message telling you that the Petraserver is listening on a certain IP Address and certain port. those two values will be inserted into the placeholders {0} and {1}<br />
|-<br />
| You do not have access to Partners of Partner Class 'ORGANISATION' that are 'Foundations'!<br />
| some users won't have access to edit partners that are foundations. Foundations are a special type of organisation. They usually are important donors, and they should not be approached by any user in the office, but only by the person that has been assigned to do that job.<br />
|}<br />
<br />
<br />
Fixed items(comments are already applied in the source code:<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| guages): This may be the last part of the following line? 'Speaks (Languages):' Speaks (Lan-<br />
| Yes, that's true. The correct string would be: Speaks (Languages):<br />
|-<br />
| this.FDelegateGetPartnerShortName could not be called!<br />
| will not be translated. should probably be changed in csharp\ICT\Petra\Client\MPartner\Gui\UC_PartnerEdit_TopPart.ManualCode.cs to not call Catalog.GetString<br />
|-<br />
| Exception occured during manual load of Client AppDomain: {0}<br />
| will not be translated. This is quite an internal error, when there are huge problems with the server. they don't need translation.<br />
|-<br />
| Text Preview / Text Output<br />
| please add Text Output to not to be translated Text Preview is displayed for the tab of the text preview when looking at a report<br />
|-<br />
| eg. "TEN,01","TEN,02"<br />
| will not be translated<br />
|}</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Reviewing_the_translation_template&diff=2965Reviewing the translation template2012-05-14T17:58:52Z<p>Joejoe2010: </p>
<hr />
<div>The following table shows comments to some items that may be unclear for translators.<br />
Feel free to add items that are unclear for you and we'll add a comment to it later on.<br />
<br />
If an entry doesn't need translation, please add "will not be translated" and wef'll add the entry later to \trunk\i18n\donottranslate.po<br />
<br />
You can also do a full text search with Notepad++ on the *.cs files in csharp\ICT\Petra and see where the strings are used, that might give you a clue if it should be translated or not, and what the context is (if the source doesn't appear yet anyway in launchpad)<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| Mailing Code: = Zip Code?<br />
| this is usually a reference to table p_mailing: http://openpetraorg.sourceforge.net/dbdoc/index.html?table=p_mailing&group=mailing. When a gift is received, and you know the donor has given because you have sent him a special letter, the mailing code which clearly identifies that letter, can be entered with the gift.<br />
|-<br />
| R.List Items<br />
| this is on the PartnerFind_Options screen. you can sort items to the right or to the left side. That screen does not even open yet from the Partner Find screen, I have deactivated it for some reason, I think it was not completely working without Petra.<br />
|-<br />
| L.List Items<br />
| see above.<br />
|-<br />
| Exact Partner &Key Match<br />
| this is on the Partner Find screen<br />
|-<br />
| &Bulk Address Report<br />
| this is for mass mailing, you want to get a bulk of addresses, ie. a huge number of addresses<br />
|-<br />
| Mails&ort Label Print<br />
| Mailsort: this seems to be a UK thing: http://en.wikipedia.org/wiki/Mailsort<br />
|-<br />
| Todo<br />
| something that still needs to be implemented/realized<br />
|-<br />
| Key Partner Data<br />
| this is displayed on top of the partner edit screen, and is meant as a group heading for the most important data pieces of the partner, ie. Name, partner key, partner class, partner status, etc.<br />
|-<br />
| (trailing 0 = --*)<br />
| this is about the lblPartnerKeyNonExactMatch on partner find.<br />
|-<br />
| Select Zoom<br />
| This is also on the preview window for reports. it is a combobox for seleting "Fit to Window", "100%", "75%", "50%"<br />
|-<br />
| Extract<br />
| Extracts are a list of partners. They are used as a result from a special filter. For example you can filter all partners that have given more then 50 euros in the past 6 months, and put all their partner keys and addresses into an extract, and send a mailing to all those people.<br />
|-<br />
| Depth<br />
| This is often used on the screens where you define parameters for a report: do you want a default, or a summary, or a detail report. This is the depth of the report.<br />
|-<br />
| FD Income by Fund<br />
| FD stands for financial development, ie. to get the numbers of past donations and to understand what the donors want and what they are interested in. The FD Income by Fund report shows how much money has come in for which fund, eg. how much money did we get for Finland, Sweden, or Turkey?<br />
|-<br />
| Lapsed Donor Report<br />
| lapsed donors are donors who have previously given, but we have not received any donations anymore for a while. We have not completely lost them yet, but we might need to send them a letter to remind them that we are still here...<br />
|-<br />
| No gifts in year:<br />
| donors who didn't give gift during the year<br />
|-<br />
| SYBUNT<br />
| SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| 'Gift given in year' must be less than 'No gifts in year'<br />
| This is related to a validation error message: wrong year entered, the donor has first to have given in some year, and in the following year has stopped giving<br />
|-<br />
| Top Middle Bottom<br />
| These are for radio buttons, for top donor, middle donor, bottom donor, for the TopDonorReport.<br />
|-<br />
| New Interest Category<br />
| We have categories for grouping interests. so it is a new catgory that should be created.<br />
|-<br />
| New Partner Interest<br />
| this is about the interest, that should be created for a partner. he is interested in ... cars.<br />
|-<br />
| Value One Direction:<br />
| this is about the exchange rates. The value for GBP to USD is one direction, USD to GBP the other direction.<br />
|-<br />
| Charged Field Report<br />
| this is about conferences, and participants are coming from several countries and fields. The fields are charged for the participants that they are sending, and the participants pay directly to the field, and the field forwards to money to the conference organisers. The conference organisers know what money to charge to each field, by this report.<br />
|-<br />
| Sign Off Lines:<br />
| this is also for the field reports for a conference. Should we print a line for the signature, so it can be signed with a pen by the one responsible to pay<br />
|-<br />
| If charged field is not set:<br />
| Same report parameter screen: what should we do if we don't know which field to charge because it is not set on the participant's record<br />
|-<br />
| Fellowship Groups<br />
| The participants of a conference are organised into smaller groups during the conference, for talking in a more smaller setting<br />
|-<br />
| Discovery Groups<br />
| similar to Fellowship groups. Probably this is conference specific. you might translate it with "small groups 2"<br />
|-<br />
| Find Conference / Conference Find May the second phrase be "conference found"?<br />
| The conference find screen has the title "Conference Find". It would be better both are "Find Conference"<br />
|-<br />
| Old Field Key:<br />
| this is for gift adjustments when the recipient has changed fields, ie. the money should not go to the previous, old field, but go to the current place where the recipient is working.<br />
|-<br />
| Parsing the hash value of the batch<br />
| The hash value is a checksum of the amounts in the batch. usually just a sum of all amounts.<br />
|-<br />
| Use Ta&x Acct+CC<br />
| This is on the Accounts Payable module. For an invoice that we have to pay. Should we use the tax account and cost centre for this invoice detail? there seems to be a hard coded combination of account and cost centre for taxes.<br />
|-<br />
| Misc Defaults<br />
| Accounts Payable. Edit Supplier. Miscellaneous defaults: several defaults, that should be used on invoices from this supplier.<br />
|-<br />
| Form Letters<br />
| form letters are the same thing as mail merge, for sending many letters with predefined context, sometimes with custom content per recipient. http://en.wikipedia.org/wiki/Mail_merge<br />
|-<br />
| FinDev {0} {1}<br />
| This is used on the main screen, for the Financial Development task item. {0} and {1} will be filled with the number and the name of the ledger that the financial development module should be opened for.<br />
|-<br />
| SYBUNT Report<br />
| Related to the same thing as above. About donors that have stopped giving. LYBUNT = Last Year But Unfortunately Not This Year; SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| PETRAServer is running and listening @ {0}:{1}<br />
| Status message telling you that the Petraserver is listening on a certain IP Address and certain port. those two values will be inserted into the placeholders {0} and {1}<br />
|-<br />
| You do not have access to Partners of Partner Class 'ORGANISATION' that are 'Foundations'!<br />
| some users won't have access to edit partners that are foundations. Foundations are a special type of organisation. They usually are important donors, and they should not be approached by any user in the office, but only by the person that has been assigned to do that job.<br />
|}<br />
<br />
<br />
Fixed items(comments are already applied in the source code:<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| guages): This may be the last part of the following line? 'Speaks (Languages):' Speaks (Lan-<br />
| Yes, that's true. The correct string would be: Speaks (Languages):<br />
|-<br />
| this.FDelegateGetPartnerShortName could not be called!<br />
| will not be translated. should probably be changed in csharp\ICT\Petra\Client\MPartner\Gui\UC_PartnerEdit_TopPart.ManualCode.cs to not call Catalog.GetString<br />
|-<br />
| Exception occured during manual load of Client AppDomain: {0}<br />
| will not be translated. This is quite an internal error, when there are huge problems with the server. they don't need translation.<br />
|-<br />
| Text Preview / Text Output<br />
| please add Text Output to not to be translated Text Preview is displayed for the tab of the text preview when looking at a report<br />
|-<br />
| eg. "TEN,01","TEN,02"<br />
| will not be translated<br />
|}</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Reviewing_the_translation_template&diff=2964Reviewing the translation template2012-05-14T17:54:57Z<p>Joejoe2010: </p>
<hr />
<div>The following table shows comments to some items that may be unclear for translators.<br />
Feel free to add items that are unclear for you and we'll add a comment to it later on.<br />
<br />
If an entry doesn't need translation, please add "will not be translated" and wef'll add the entry later to \trunk\i18n\donottranslate.po<br />
<br />
You can also do a full text search with Notepad++ on the *.cs files in csharp\ICT\Petra and see where the strings are used, that might give you a clue if it should be translated or not, and what the context is (if the source doesn't appear yet anyway in launchpad)<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| Mailing Code: = Zip Code?<br />
| this is usually a reference to table p_mailing: http://openpetraorg.sourceforge.net/dbdoc/index.html?table=p_mailing&group=mailing. When a gift is received, and you know the donor has given because you have sent him a special letter, the mailing code which clearly identifies that letter, can be entered with the gift.<br />
|-<br />
| R.List Items<br />
| this is on the PartnerFind_Options screen. you can sort items to the right or to the left side. That screen does not even open yet from the Partner Find screen, I have deactivated it for some reason, I think it was not completely working without Petra.<br />
|-<br />
| L.List Items<br />
| see above.<br />
|-<br />
| Exact Partner &Key Match<br />
| this is on the Partner Find screen<br />
|-<br />
| &Bulk Address Report<br />
| this is for mass mailing, you want to get a bulk of addresses, ie. a huge number of addresses<br />
|-<br />
| Mails&ort Label Print<br />
| Mailsort: this seems to be a UK thing: http://en.wikipedia.org/wiki/Mailsort<br />
|-<br />
| Todo<br />
| something that still needs to be implemented/realized<br />
|-<br />
| Key Partner Data<br />
| this is displayed on top of the partner edit screen, and is meant as a group heading for the most important data pieces of the partner, ie. Name, partner key, partner class, partner status, etc.<br />
|-<br />
| (trailing 0 = --*)<br />
| this is about the lblPartnerKeyNonExactMatch on partner find.<br />
|-<br />
| Select Zoom<br />
| This is also on the preview window for reports. it is a combobox for seleting "Fit to Window", "100%", "75%", "50%"<br />
|-<br />
| Extract<br />
| Extracts are a list of partners. They are used as a result from a special filter. For example you can filter all partners that have given more then 50 euros in the past 6 months, and put all their partner keys and addresses into an extract, and send a mailing to all those people.<br />
|-<br />
| eg. "TEN,01","TEN,02"<br />
| will not be translated<br />
|-<br />
| Depth<br />
| This is often used on the screens where you define parameters for a report: do you want a default, or a summary, or a detail report. This is the depth of the report.<br />
|-<br />
| FD Income by Fund<br />
| FD stands for financial development, ie. to get the numbers of past donations and to understand what the donors want and what they are interested in. The FD Income by Fund report shows how much money has come in for which fund, eg. how much money did we get for Finland, Sweden, or Turkey?<br />
|-<br />
| Lapsed Donor Report<br />
| lapsed donors are donors who have previously given, but we have not received any donations anymore for a while. We have not completely lost them yet, but we might need to send them a letter to remind them that we are still here...<br />
|-<br />
| No gifts in year:<br />
| correct<br />
|-<br />
| SYBUNT<br />
| SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| 'Gift given in year' must be less than 'No gifts in year'<br />
| This is related to a validation error message: wrong year entered, the donor has first to have given in some year, and in the following year has stopped giving<br />
|-<br />
| Top Middle Bottom<br />
| These are for radio buttons, for top donor, middle donor, bottom donor, for the TopDonorReport.<br />
|-<br />
| New Interest Category<br />
| We have categories for grouping interests. so it is a new catgory that should be created.<br />
|-<br />
| New Partner Interest<br />
| this is about the interest, that should be created for a partner. he is interested in ... cars.<br />
|-<br />
| Value One Direction:<br />
| this is about the exchange rates. The value for GBP to USD is one direction, USD to GBP the other direction.<br />
|-<br />
| Charged Field Report<br />
| this is about conferences, and participants are coming from several countries and fields. The fields are charged for the participants that they are sending, and the participants pay directly to the field, and the field forwards to money to the conference organisers. The conference organisers know what money to charge to each field, by this report.<br />
|-<br />
| Sign Off Lines:<br />
| this is also for the field reports for a conference. Should we print a line for the signature, so it can be signed with a pen by the one responsible to pay<br />
|-<br />
| If charged field is not set:<br />
| Same report parameter screen: what should we do if we don't know which field to charge because it is not set on the participant's record<br />
|-<br />
| Fellowship Groups<br />
| The participants of a conference are organised into smaller groups during the conference, for talking in a more smaller setting<br />
|-<br />
| Discovery Groups<br />
| similar to Fellowship groups. Probably this is conference specific. you might translate it with "small groups 2"<br />
|-<br />
| Find Conference / Conference Find May the second phrase be "conference found"?<br />
| The conference find screen has the title "Conference Find". It would be better both are "Find Conference"<br />
|-<br />
| Old Field Key:<br />
| this is for gift adjustments when the recipient has changed fields, ie. the money should not go to the previous, old field, but go to the current place where the recipient is working.<br />
|-<br />
| Parsing the hash value of the batch<br />
| The hash value is a checksum of the amounts in the batch. usually just a sum of all amounts.<br />
|-<br />
| Use Ta&x Acct+CC<br />
| This is on the Accounts Payable module. For an invoice that we have to pay. Should we use the tax account and cost centre for this invoice detail? there seems to be a hard coded combination of account and cost centre for taxes.<br />
|-<br />
| Misc Defaults<br />
| Accounts Payable. Edit Supplier. Miscellaneous defaults: several defaults, that should be used on invoices from this supplier.<br />
|-<br />
| Form Letters<br />
| form letters are the same thing as mail merge, for sending many letters with predefined context, sometimes with custom content per recipient. http://en.wikipedia.org/wiki/Mail_merge<br />
|-<br />
| FinDev {0} {1}<br />
| This is used on the main screen, for the Financial Development task item. {0} and {1} will be filled with the number and the name of the ledger that the financial development module should be opened for.<br />
|-<br />
| SYBUNT Report<br />
| Related to the same thing as above. About donors that have stopped giving. LYBUNT = Last Year But Unfortunately Not This Year; SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| PETRAServer is running and listening @ {0}:{1}<br />
| Status message telling you that the Petraserver is listening on a certain IP Address and certain port. those two values will be inserted into the placeholders {0} and {1}<br />
|-<br />
| You do not have access to Partners of Partner Class 'ORGANISATION' that are 'Foundations'!<br />
| some users won't have access to edit partners that are foundations. Foundations are a special type of organisation. They usually are important donors, and they should not be approached by any user in the office, but only by the person that has been assigned to do that job.<br />
|}<br />
<br />
<br />
Fixed items(comments are already applied in the source code:<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| guages): This may be the last part of the following line? 'Speaks (Languages):' Speaks (Lan-<br />
| Yes, that's true. The correct string would be: Speaks (Languages):<br />
|-<br />
| this.FDelegateGetPartnerShortName could not be called!<br />
| will not be translated. should probably be changed in csharp\ICT\Petra\Client\MPartner\Gui\UC_PartnerEdit_TopPart.ManualCode.cs to not call Catalog.GetString<br />
|-<br />
| Exception occured during manual load of Client AppDomain: {0}<br />
| will not be translated. This is quite an internal error, when there are huge problems with the server. they don't need translation.<br />
|-<br />
| Text Preview / Text Output<br />
| please add Text Output to not to be translated Text Preview is displayed for the tab of the text preview when looking at a report<br />
|}</div>Joejoe2010https://wiki.openpetra.org/index.php?title=Reviewing_the_translation_template&diff=2963Reviewing the translation template2012-05-14T17:53:07Z<p>Joejoe2010: </p>
<hr />
<div>The following table shows comments to some items that may be unclear for translators.<br />
Feel free to add items that are unclear for you and we'll add a comment to it later on.<br />
<br />
If an entry doesn't need translation, please add "will not be translated" and wef'll add the entry later to \trunk\i18n\donottranslate.po<br />
<br />
You can also do a full text search with Notepad++ on the *.cs files in csharp\ICT\Petra and see where the strings are used, that might give you a clue if it should be translated or not, and what the context is (if the source doesn't appear yet anyway in launchpad)<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| Mailing Code: = Zip Code?<br />
| this is usually a reference to table p_mailing: http://openpetraorg.sourceforge.net/dbdoc/index.html?table=p_mailing&group=mailing. When a gift is received, and you know the donor has given because you have sent him a special letter, the mailing code which clearly identifies that letter, can be entered with the gift.<br />
|-<br />
| R.List Items<br />
| this is on the PartnerFind_Options screen. you can sort items to the right or to the left side. That screen does not even open yet from the Partner Find screen, I have deactivated it for some reason, I think it was not completely working without Petra.<br />
|-<br />
| L.List Items<br />
| see above.<br />
|-<br />
| Exact Partner &Key Match<br />
| this is on the Partner Find screen<br />
|-<br />
| &Bulk Address Report<br />
| this is for mass mailing, you want to get a bulk of addresses, ie. a huge number of addresses<br />
|-<br />
| Mails&ort Label Print<br />
| Mailsort: this seems to be a UK thing: http://en.wikipedia.org/wiki/Mailsort<br />
|-<br />
| Todo<br />
| something that still needs to be implemented/realized<br />
|-<br />
| Key Partner Data<br />
| this is displayed on top of the partner edit screen, and is meant as a group heading for the most important data pieces of the partner, ie. Name, partner key, partner class, partner status, etc.<br />
|-<br />
| (trailing 0 = --*)<br />
| this is about the lblPartnerKeyNonExactMatch on partner find.<br />
|-<br />
| Text Preview / Text Output<br />
| please add Text Output to not to be translated Text Preview is displayed for the tab of the text preview when looking at a report<br />
|-<br />
| Select Zoom<br />
| This is also on the preview window for reports. it is a combobox for seleting "Fit to Window", "100%", "75%", "50%"<br />
|-<br />
| Extract<br />
| Extracts are a list of partners. They are used as a result from a special filter. For example you can filter all partners that have given more then 50 euros in the past 6 months, and put all their partner keys and addresses into an extract, and send a mailing to all those people.<br />
|-<br />
| eg. "TEN,01","TEN,02"<br />
| will not be translated<br />
|-<br />
| Depth<br />
| This is often used on the screens where you define parameters for a report: do you want a default, or a summary, or a detail report. This is the depth of the report.<br />
|-<br />
| FD Income by Fund<br />
| FD stands for financial development, ie. to get the numbers of past donations and to understand what the donors want and what they are interested in. The FD Income by Fund report shows how much money has come in for which fund, eg. how much money did we get for Finland, Sweden, or Turkey?<br />
|-<br />
| Lapsed Donor Report<br />
| lapsed donors are donors who have previously given, but we have not received any donations anymore for a while. We have not completely lost them yet, but we might need to send them a letter to remind them that we are still here...<br />
|-<br />
| No gifts in year:<br />
| correct<br />
|-<br />
| SYBUNT<br />
| SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| 'Gift given in year' must be less than 'No gifts in year'<br />
| This is related to a validation error message: wrong year entered, the donor has first to have given in some year, and in the following year has stopped giving<br />
|-<br />
| Top Middle Bottom<br />
| These are for radio buttons, for top donor, middle donor, bottom donor, for the TopDonorReport.<br />
|-<br />
| New Interest Category<br />
| We have categories for grouping interests. so it is a new catgory that should be created.<br />
|-<br />
| New Partner Interest<br />
| this is about the interest, that should be created for a partner. he is interested in ... cars.<br />
|-<br />
| Value One Direction:<br />
| this is about the exchange rates. The value for GBP to USD is one direction, USD to GBP the other direction.<br />
|-<br />
| Charged Field Report<br />
| this is about conferences, and participants are coming from several countries and fields. The fields are charged for the participants that they are sending, and the participants pay directly to the field, and the field forwards to money to the conference organisers. The conference organisers know what money to charge to each field, by this report.<br />
|-<br />
| Sign Off Lines:<br />
| this is also for the field reports for a conference. Should we print a line for the signature, so it can be signed with a pen by the one responsible to pay<br />
|-<br />
| If charged field is not set:<br />
| Same report parameter screen: what should we do if we don't know which field to charge because it is not set on the participant's record<br />
|-<br />
| Fellowship Groups<br />
| The participants of a conference are organised into smaller groups during the conference, for talking in a more smaller setting<br />
|-<br />
| Discovery Groups<br />
| similar to Fellowship groups. Probably this is conference specific. you might translate it with "small groups 2"<br />
|-<br />
| Find Conference / Conference Find May the second phrase be "conference found"?<br />
| The conference find screen has the title "Conference Find". It would be better both are "Find Conference"<br />
|-<br />
| Old Field Key:<br />
| this is for gift adjustments when the recipient has changed fields, ie. the money should not go to the previous, old field, but go to the current place where the recipient is working.<br />
|-<br />
| Parsing the hash value of the batch<br />
| The hash value is a checksum of the amounts in the batch. usually just a sum of all amounts.<br />
|-<br />
| Use Ta&x Acct+CC<br />
| This is on the Accounts Payable module. For an invoice that we have to pay. Should we use the tax account and cost centre for this invoice detail? there seems to be a hard coded combination of account and cost centre for taxes.<br />
|-<br />
| Misc Defaults<br />
| Accounts Payable. Edit Supplier. Miscellaneous defaults: several defaults, that should be used on invoices from this supplier.<br />
|-<br />
| Form Letters<br />
| form letters are the same thing as mail merge, for sending many letters with predefined context, sometimes with custom content per recipient. http://en.wikipedia.org/wiki/Mail_merge<br />
|-<br />
| FinDev {0} {1}<br />
| This is used on the main screen, for the Financial Development task item. {0} and {1} will be filled with the number and the name of the ledger that the financial development module should be opened for.<br />
|-<br />
| SYBUNT Report<br />
| Related to the same thing as above. About donors that have stopped giving. LYBUNT = Last Year But Unfortunately Not This Year; SYBUNT = Some Year But Unfortunately Not This Year. <br />
|-<br />
| PETRAServer is running and listening @ {0}:{1}<br />
| Status message telling you that the Petraserver is listening on a certain IP Address and certain port. those two values will be inserted into the placeholders {0} and {1}<br />
|-<br />
| You do not have access to Partners of Partner Class 'ORGANISATION' that are 'Foundations'!<br />
| some users won't have access to edit partners that are foundations. Foundations are a special type of organisation. They usually are important donors, and they should not be approached by any user in the office, but only by the person that has been assigned to do that job.<br />
|}<br />
<br />
<br />
Fixed items(comments are already applied in the source code:<br />
{| class="wikitable" border="1"<br />
|-<br />
! item<br />
! comment<br />
|-<br />
| guages): This may be the last part of the following line? 'Speaks (Languages):' Speaks (Lan-<br />
| Yes, that's true. The correct string would be: Speaks (Languages):<br />
|-<br />
| this.FDelegateGetPartnerShortName could not be called!<br />
| will not be translated. should probably be changed in csharp\ICT\Petra\Client\MPartner\Gui\UC_PartnerEdit_TopPart.ManualCode.cs to not call Catalog.GetString<br />
|-<br />
| Exception occured during manual load of Client AppDomain: {0}<br />
| will not be translated. This is quite an internal error, when there are huge problems with the server. they don't need translation.<br />
|}</div>Joejoe2010