Dela via

Globalisering och lokalisering av Excel-lösningar

Det här avsnittet innehåller information om särskilda överväganden för Microsoft Office Excel-lösningar som ska köras på datorer som har icke-engelska inställningar för Windows. De flesta aspekter av att globalisera och lokalisera Microsoft Office-lösningar är desamma som när du skapar andra typer av lösningar med Hjälp av Visual Studio. Allmän information finns i Globalisera och lokalisera program.

Som standard fungerar värdkontroller i Microsoft Office Excel korrekt i alla regionala Windows-inställningar, så länge alla data som skickas eller manipuleras med hanterad kod formateras med formatering på engelska (USA). I projekt som riktar sig mot .NET Framework 4 eller .NET Framework 4.5 styrs det här beteendet av CLR (Common Language Runtime).

Gäller för: Informationen i det här avsnittet gäller för projekt på dokumentnivå och VSTO-tilläggsprojekt för Excel. Mer information finns i Funktioner som är tillgängliga efter Office-program och projekttyp.

Formatera data i Excel med olika regionala inställningar

Du måste formatera alla data som har språkkänslig formatering, till exempel datum och valuta, med hjälp av dataformatet engelska (USA) (språkvariant-ID 1033) innan du skickar dem till Microsoft Office Excel eller läser data från koden i ditt Office-projekt.

När du utvecklar en Office-lösning i Visual Studio förväntar sig Excel-objektmodellen som standard språk-ID 1033-dataformatering (detta kallas även för att låsa objektmodellen till språkvariant-ID 1033). Det här beteendet matchar hur Visual Basic för program fungerar. Du kan dock ändra det här beteendet i dina Office-lösningar.

Förstå hur Excel-objektmodellen alltid förväntar sig språkvariant-ID 1033

Som standard påverkas inte Office-lösningar som du skapar med hjälp av Visual Studio av slutanvändarens nationella inställningar och beter sig alltid som om språkvarianten är engelska (USA). Om du till exempel får eller anger Value2 egenskapen i Excel måste data formateras på det sätt som språk-ID 1033 förväntar sig. Om du använder ett annat dataformat kan du få oväntade resultat.

Även om du använder formatet engelska (USA) för data som skickas eller manipuleras av hanterad kod tolkar och visar Excel data korrekt enligt slutanvändarens nationella inställningar. Excel kan formatera data korrekt eftersom den hanterade koden skickar språkvariant-ID 1033 tillsammans med data, vilket indikerar att data är i engelskt format (USA) och därför måste formateras om för att matcha användarens nationella inställningar.

Om slutanvändarna till exempel har sina regionala alternativ inställda på det tyska språket (Tyskland) förväntar de sig att datumet den 29 juni 2005 formateras på det här sättet: 29.06.2005. Men om din lösning skickar datumet till Excel som en sträng måste du formatera datumet enligt engelskt format (USA): 2005-06-29. Om cellen är formaterad som en datumcell visar Excel datumet i tyskt format (Tyskland).

Skicka andra lokal-ID:n i Excel-objektmodellen

Common Language Runtime (CLR) skickar automatiskt språk-ID 1033 till alla metoder och egenskaper i Excel-objektmodellen som accepterar språkkänsliga data. Det finns inget sätt att ändra det här beteendet automatiskt för alla anrop till objektmodellen. Du kan dock skicka ett annat locale-ID till en specifik metod genom att använda InvokeMember för att anropa metoden och genom att skicka locale-ID:t till metodens culture-parameter .

Lokalisera dokumenttext

Dokumentet, mallen eller arbetsboken i projektet innehåller förmodligen statisk text, som måste lokaliseras separat från sammansättningen och andra hanterade resurser. Ett enkelt sätt att göra detta är att göra en kopia av dokumentet och översätta texten med Hjälp av Microsoft Office Word eller Microsoft Office Excel. Den här processen fungerar även om du inte gör några ändringar i koden, eftersom valfritt antal dokument kan länkas till samma sammansättning.

Du måste fortfarande se till att alla delar av koden som interagerar med dokumenttexten fortsätter att matcha språket i texten, och att bokmärken, namngivna intervall och andra visningsfält passar alla omformateringar av Office-dokumentet som var nödvändiga för att justera för olika grammatik- och textlängder. För dokumentmallar som innehåller relativt lite text kanske du vill överväga att lagra texten i resursfiler och sedan läsa in texten vid körning.

Textriktning

I Excel kan du ställa in en egenskap för kalkylbladet för att visa text från höger till vänster. Värdkontroller, eller någon kontroll som har en RightToLeft-egenskap, placeras i designverktyget så att de automatiskt matchar dessa inställningar vid körning. Word har ingen dokumentinställning för dubbelriktad text (du ändrar bara textjusteringen), så kontrollerna kan inte mappas till den här inställningen. I stället måste du ange textjusteringen för varje kontroll. Det går att skriva kod för att gå igenom alla kontroller och tvinga dem att återge text från höger till vänster.

Ändra kultur

Anpassningskoden på dokumentnivå delar vanligtvis huvudgränssnittstråden i Excel, så alla ändringar du gör i trådkulturen påverkar allt annat som körs i tråden. ändringen är inte begränsad till din anpassning.

Windows Forms-kontroller initieras innan VSTO-tillägg på programnivå startas av värdprogrammet. I dessa situationer bör kulturen ändras innan du anger användargränssnittskontrollerna.

Installera språkpaketen

Om du har icke-engelska inställningar för Windows kan du installera Visual Studio Tools for Office Runtime Language Packs för att se Visual Studio Tools for Office-körningsmeddelanden på samma språk som Windows. Om några slutanvändare kör dina lösningar med icke-engelska inställningar för Windows måste de ha rätt språkpaket för att se körningsmeddelanden på samma språk som Windows. Språkpaket för Visual Studio Tools för Office-körning är tillgängliga från Microsoft Download Center.

Dessutom är de omdistribuerbara .NET Framework-språkpaketen nödvändiga för ClickOnce-meddelanden. Språkpaketen för .NET Framework är tillgängliga från Microsoft Download Center.

Nationella inställningar och Excel COM-anrop

När en hanterad klient anropar en metod på ett COM-objekt och den måste skicka in kulturspecifik information, gör den det med hjälp av lokalen som matchar den aktuella trådens lokal. Det aktuella trådspråket ärvs som standard från användarens nationella inställningar. Men när du gör ett anrop till Excel-objektmodellen från en Excel-lösning som skapats med hjälp av Office-utvecklingsverktygen i Visual Studio skickas dataformatet för engelska (USA) (språkvariant-ID 1033) automatiskt till Excel-objektmodellen. Du måste formatera alla data som har språkkänslig formatering, till exempel datum och valuta, med hjälp av det engelska dataformatet (USA) innan du skickar dem till Microsoft Office Excel eller läser data från projektkoden.

Överväganden för att lagra data

För att säkerställa att dina data tolkas och visas korrekt bör du också tänka på att problem kan uppstå när ett program lagrar data, till exempel Excel-kalkylbladsformler, i strängliteraler (hårdkodade) i stället för i starkt typerade objekt. Du bör använda data som är formaterade som kulturoberoende eller i engelskt format (USA) (LCID-värde 1033).

Program som använder strängliteraler

Möjliga värden som kan vara hårdkodade är datumliteraler som är skrivna i engelskt format (USA) och Excel-kalkylbladsformler som innehåller lokaliserade funktionsnamn. En annan möjlighet kan vara en hårdkodad sträng som innehåller ett tal som "1 000". i vissa kulturer tolkas detta som tusen, men i andra kulturer representerar det en punkt noll. Beräkningar och jämförelser som utförs i fel format kan resultera i felaktiga data.

Excel tolkar alla strängar i enlighet med den LCID som skickas med strängen. Detta kan vara ett problem om formatet på strängen inte motsvarar den LCID som skickas. Excel-lösningar som skapats med hjälp av Office-utvecklingsverktygen i Visual Studio använder LCID 1033 (en-US) när du skickar alla data. Excel visar data enligt de regionala inställningarna och Excel-användargränssnittsspråket. Visual Basic for Applications (VBA) fungerar också på det här sättet. strängar formateras som en-US och VBA passerar nästan alltid 0 (språkneutral) som LCID. Följande VBA-kod visar till exempel ett korrekt formaterat värde för 12 maj 2004 i enlighet med den aktuella inställningen för användarspråk:

'VBA
Application.ActiveCell.Value2 = "05/12/04"

Samma kod, när den används i en lösning som skapats med hjälp av Office-utvecklingsverktygen i Visual Studio och skickas till Excel via COM-interop, ger samma resultat när datumet formateras i en-US stil.

Till exempel:

this.Range["A1"].Value2 = "05/12/04";

Du bör arbeta med starkt skrivna data i stället för strängliteraler när det är möjligt. I stället för att till exempel lagra ett datum i en strängliteral lagrar du det som en Doubleoch konverterar det sedan till ett DateTime objekt för manipulering.

Följande kodexempel tar ett datum som en användare anger i cell A5, lagrar den som en Doubleoch konverterar den sedan till ett DateTime objekt för visning i cell A7. Cell A7 måste formateras för att visa ett datum.

private void ConvertDate_Click(object sender, EventArgs e)
{
    try
    {
        double dbl = (double)(this.Range["A5"].Value2);
        System.DateTime dt = System.DateTime.FromOADate(dbl);
        this.Range["A7"].Value2 = dt;
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

Excel-kalkylbladsfunktioner

Kalkylbladsfunktionsnamn översätts internt för de flesta språkversioner av Excel. På grund av potentiella problem med språk och COM-interop rekommenderar vi dock att du endast använder engelska funktionsnamn i koden.

Program som använder externa data

All kod som öppnar eller på annat sätt använder externa data, till exempel filer som innehåller kommaavgränsade värden (CSV-filer) som exporteras från ett äldre system, kan också påverkas om sådana filer exporteras med valfritt format förutom en-US. Databasåtkomsten kanske inte påverkas eftersom alla värden ska vara i binärt format, såvida inte databasen lagrar datum som strängar eller utför åtgärder som inte använder binärt format. Om du skapar SQL-frågor med data från Excel kan du också behöva se till att de är i en-US format, beroende på vilken funktion du använder.

Relaterat innehåll