ReportPro 2.x - MacroCompiler does not accept umlaut

Bernhard Mayer · Post by **Bernhard Mayer** » Tue Jul 30, 2019 10:01 am

Dear fellow Vulcans and XSharp'ers!

I have a very strange problem regarding Vulcan.NET (3.0.303.0) and ReportPro 2.x (.NET as well). One of our customers' just got a new client and when the user starts a ReportPro Report (With RPT designer file), any variable which has an umlaut in the init expression - e.g. "Übertrag" - will show an ReportPro error "Invalid initial expression 'Übertrag'". The finished ReportPro preview/print document itself does not have any problems with umlaut characters, they all are displayed properly, so the problem is more annoying than dangerous.

The same issue happens when opening such a RPT file with the RP designer on the concerning client (Whereas there is no SetNatDLL call within ReportPro, at least none of which I'm aware of). When editing the concerning variable in the expression window, pressing the "Test" button will lead to a "There is an error within the expression" message.
The client itself is a german Win 10 with German-IT settings.

All other clients do not have this problem, the application components are equal. Our application has a SetNatDLL("German.DLL") "compatibility loading call" which was sufficient so far for the MacroCompiler to get along with all german special characters.

Does anyone have an idea what could be causing this issue or how to get this problem solved?

Best regards,
Bernhard

Chris · Post by **Chris** » Tue Jul 30, 2019 4:54 pm

Hi Bernhard,

Maybe the "System Locale" setting in control panel (which is different than the basic international regional setting) is set to something different than German?

ArneOrtlinghaus · Post by **ArneOrtlinghaus** » Wed Jul 31, 2019 6:11 am

Yesterday a customer could not start our program because of some regional settings - it was something regarding the correct number formatting, where the number 50.1 was formatted like "50,1." using _Str. It was new Windows 10 installation with the newest function update 1903. I did not have the time to verify all registry/country settings, but I realized that it is difficult to understand what can be changed using the control panel settings dialogs and what may be in the registry.

lumberjack · Post by **lumberjack** » Wed Jul 31, 2019 6:33 am

Hi Arne,

ArneOrtlinghaus wrote:Yesterday a customer could not start our program because of some regional settings

Yes this is one of the gremlins of international settings. On top of that in SA we don't really stick to the ZA standards, e.g.:

Code: Select all

"," - In most documents/cases you will find "." used
"DD/MM/YYYY" -  Some people prefer "YYYY/MM/DD" and it is not strange to find both used

I have on numerous times with new computers have my applications not working again, luckily by now I have realised it is due to Technical support never bothering to change the Date format from American "MM/DD/YYYY". In the end it almost feel one need to "hardcode" every piece of anomaly around these locale settings to force a standard for business applications...

ArneOrtlinghaus · Post by **ArneOrtlinghaus** » Wed Jul 31, 2019 7:11 am

In our case I have received now the following description from the customer:
The customer made the installation of windows using an administrator account with English settings. The final user used German. In previous installations this situation did not create any problems. When setting up the client computer with an administrator in German it worked. It is not clear if it was exactly this together with this build of Windows 10, but it is not excluded.