Programming multinationally, choosing region settings dynamically 1

[MatsHulten]

When coding ASP you can use an object called Session to dynamically set the region settings for the output regardless of what the computer uses (when running the application under IIS that is).

The following code will write £125 to the calling browser, regardless of the regional settings of the server that executes the script:
<%
Session.LCID = 2057
Dim curNumb
curNumb = FormatCurrency(125)
Response.Write (curNumb)
%>

Is it possible to write code that behaves in the same way, without using IIS. That is write a business object that will behave as the regional settings are set up for England (UK), regardless of the regional settings locally on the computer, without altering the local settings?

-Mats Hulten

 

[RickSpr]

Web applications are outside my ken, but can't you just use Format(125, &quot;£##0&quot? Rick Sprague

 

[chiph]

I guess you're talking about a business object that is called by IIS?

In that case, your ASP code would need to pass the LCID along to the component. Otherwise the component has no way of knowing where the caller is.

You can call GetDateFormat (a Win32 API) to find out what the date format is for a given LCID. Same thing with currency format (GetCurrencyFormat) and GetCalendarInfo (to find out what the names of the days of the week are called).

Chip H.

 

[MatsHulten]

I am not talking about an object that can be called only by IIS. I want this object to be able to be standalone in any application, using any region settings.
The only reason I gave ASP/IIS as an example, was that I found the code there.

Rick, I'm aware of the format functions, but consider this scenario:
* You are building an application wich are to be run on a server where IIS is not installed.
* The applications main goal is to send a pricelist for an airline via FTP to clients around the world.
* The data is stored in a database without any data redundancy.
* The data must be formatted properly according to the country standard of the calling client.
Obviously there is a lot more to be done here but format the data correctly (like calculate the price, using the local currency rate), but it should give you a hint of what I'm looking for.

The output could be something like theese two lists:

(USA list)
DESTINATION  DEPARTURE          PRICE  
=======================================
Barcelona    4/26/2001 9:30 PM  $150.00
...
(EOF)

(Swedish list)
DESTINATION  DEPARTURE          PRICE  
==========================================
Barcelona    2001-04-26 21:30   1500,00 Kr
...
(EOF)

Formatting the data manually like

Format(125, "£##0")

is not a viable solution as it would require me to manually enter all date, time and currency formats.
And besides, MS has already done this for me...

What I would like to do is to some way tell the different formatting functions dynamically what region formats to use, for these calls. But at the same time, it is a must that it doesn't change the systems overall settings.

Using IIS/ASP, I can do this with a call to the Session object as described above, but can it be done without using those?

-Mats

 

[chiph]

Your component can still be used outside of IIS. You'd just have to pass the LCID in.

In a web-based application, you'd do as you've described. In a client-server application, the client executable would have to pass it to your component. In a traditional standalone app (runs on the user's PC), you'd use the Win32 constant LOCALE_USER_DEFAULT to use the user's current LCID.

Rereading your message, it looks like you want to prepare export files in each LCID you plan on supporting. In that case, I'd loop through the list of LCIDs you care about, calling your component each time. Look in the MSDN library (

http://msdn.microsoft.com/library/default.asp)

under National Language Support.

You might want to encode the LCID into the file/directory name so that you can keep them separate.

Chip H.

 

[MatsHulten]

Thanx chiph! The function SetThreadLocale was exactly what I was looking for.

-Mats

 

[chiph]

Well, I guess that would work, too!

Glad you got your problem solved.

Chip H.