The Toolkit requires that the decimal separator for the locale it uses be a period (.) so that INP files can be read and written correctly. This is normally the default for C programs. I discovered that on Linux, if client code that calls the Toolkit is running under a locale that doesn't use the period as a decimal separator (such as in many European countries where a comma is the separator), the Toolkit functions will use the calling program's decimal separator and will fail to read or write INP files correctly. (For some reason, perhaps due to a difference in compilers, this doesn't happen on Windows, and the Toolkit continues to use C's default period separator.)
To prevent this from happening I propose adding the following line at the top of the EN_init function:
setlocale(LC_NUMERIC, "C");
As long as EN_init is called first, this will force the Toolkit to use a period as the decimal separator for all I/O and string conversion functions.
I tested this on Ubuntu Linux using the new EPANET-UI app (which uses calls to the Toolkit to manage all project data) under a system format setting for Denmark (which uses a comma as the separator). With the current Toolkit v2.3.5 the app correctly displayed numbers with a comma separator in its various UI elements but failed to read any numeric data contained in a INP file. When I made the EN_init change noted above and rebuilt the Toolkit, the new UI was then able to read and write INP files correctly while still displaying the comma separator in all its forms and dialogs.
If anyone has a better way of addressing this issue please let us know.
The Toolkit requires that the decimal separator for the locale it uses be a period (.) so that INP files can be read and written correctly. This is normally the default for C programs. I discovered that on Linux, if client code that calls the Toolkit is running under a locale that doesn't use the period as a decimal separator (such as in many European countries where a comma is the separator), the Toolkit functions will use the calling program's decimal separator and will fail to read or write INP files correctly. (For some reason, perhaps due to a difference in compilers, this doesn't happen on Windows, and the Toolkit continues to use C's default period separator.)
To prevent this from happening I propose adding the following line at the top of the
EN_initfunction:As long as
EN_initis called first, this will force the Toolkit to use a period as the decimal separator for all I/O and string conversion functions.I tested this on Ubuntu Linux using the new EPANET-UI app (which uses calls to the Toolkit to manage all project data) under a system format setting for Denmark (which uses a comma as the separator). With the current Toolkit v2.3.5 the app correctly displayed numbers with a comma separator in its various UI elements but failed to read any numeric data contained in a INP file. When I made the
EN_initchange noted above and rebuilt the Toolkit, the new UI was then able to read and write INP files correctly while still displaying the comma separator in all its forms and dialogs.If anyone has a better way of addressing this issue please let us know.