Globalizacja i lokalizacja rozwiązań programu Excel
Ta sekcja zawiera informacje o specjalnych zagadnieniach dotyczących rozwiązań programu Microsoft Office Excel, które będą uruchamiane na komputerach z ustawieniami systemu Windows spoza języka angielskiego. Większość aspektów globalizacji i lokalizowania rozwiązań pakietu Microsoft Office jest taka sama jak podczas tworzenia innych rodzajów rozwiązań przy użyciu programu Visual Studio. Aby uzyskać ogólne informacje, zobacz Globalize i lokalizowanie aplikacji.
Domyślnie kontrolki hosta w programie Microsoft Office Excel działają poprawnie w dowolnym regionalnym ustawieniu systemu Windows, o ile wszystkie dane przekazywane lub manipulowane przy użyciu kodu zarządzanego są formatowane przy użyciu formatowania języka angielskiego (Stany Zjednoczone). W projektach przeznaczonych dla programu .NET Framework 4 lub .NET Framework 4.5 to zachowanie jest kontrolowane przez środowisko uruchomieniowe języka wspólnego (CLR).
Dotyczy: informacje w tym temacie dotyczą projektów na poziomie dokumentu i projektów dodatków VSTO dla programu Excel. Aby uzyskać więcej informacji, zobacz Funkcje dostępne przez aplikacja pakietu Office lication i typ projektu.
Formatowanie danych w programie Excel przy użyciu różnych ustawień regionalnych
Przed przekazaniem ich do programu Microsoft Office Excel lub odczytania danych z kodu w projekcie pakietu Office należy sformatować wszystkie dane, które mają poufne ustawienia regionalne, takie jak daty i Stany Zjednoczone waluta.
Domyślnie podczas tworzenia rozwiązania pakietu Office w programie Visual Studio model obiektów programu Excel oczekuje formatowania danych o identyfikatorze ustawień regionalnych 1033 (jest to również nazywane blokowaniem modelu obiektów na identyfikatorze ustawień regionalnych 1033). To zachowanie jest zgodne ze sposobem działania programu Visual Basic for Applications. Można jednak zmodyfikować to zachowanie w rozwiązaniach pakietu Office.
Dowiedz się, jak model obiektów programu Excel zawsze oczekuje ustawień regionalnych o identyfikatorze 1033
Domyślnie rozwiązania pakietu Office tworzone przy użyciu programu Visual Studio nie mają wpływu na ustawienia regionalne użytkownika końcowego i zawsze zachowują się tak, jakby ustawienia regionalne to angielski (Stany Zjednoczone). Jeśli na przykład uzyskasz lub ustawisz Value2 właściwość w programie Excel, dane muszą być sformatowane tak, jak oczekiwano identyfikatora ustawień regionalnych 1033. Jeśli używasz innego formatu danych, możesz uzyskać nieoczekiwane wyniki.
Mimo że używasz formatu angielskiego (Stany Zjednoczone) dla danych przekazywanych lub manipulowanych przez kod zarządzany, program Excel interpretuje i wyświetla dane poprawnie zgodnie z ustawieniami regionalnymi użytkownika końcowego. Program Excel może poprawnie sformatować dane, ponieważ kod zarządzany przekazuje identyfikator ustawień regionalnych 1033 wraz z danymi, co wskazuje, że dane są w formacie angielskim (Stany Zjednoczone), dlatego należy ponownie sformatować, aby dopasować ustawienia regionalne użytkownika.
Jeśli na przykład użytkownicy końcowi mają ustawienia regionalne ustawione na ustawienia regionalne Niemiec (Niemcy), spodziewają się daty 29 czerwca 2005 r., która ma być sformatowana w ten sposób: 29.06.2005. Jeśli jednak rozwiązanie przekazuje datę do programu Excel jako ciąg, musisz sformatować datę zgodnie z formatem języka angielskiego (Stany Zjednoczone): 29.06.2005. Jeśli komórka jest sformatowana jako komórka Date, program Excel wyświetli datę w formacie niemieckim (Niemcy).
Przekazywanie innych identyfikatorów ustawień regionalnych do modelu obiektów programu Excel
Środowisko uruchomieniowe języka wspólnego (CLR) automatycznie przekazuje identyfikator ustawień regionalnych 1033 do wszystkich metod i właściwości w modelu obiektów programu Excel, które akceptują dane poufne dla ustawień regionalnych. Nie ma możliwości automatycznego zmiany tego zachowania dla wszystkich wywołań do modelu obiektów. Można jednak przekazać inny identyfikator ustawień regionalnych do określonej metody przy użyciu metody InvokeMember w celu wywołania metody i przekazując identyfikator ustawień regionalnych do parametru kultury metody .
Lokalizowanie tekstu dokumentu
Dokument, szablon lub skoroszyt w projekcie prawdopodobnie zawiera tekst statyczny, który musi być zlokalizowany oddzielnie od zestawu i innych zasobów zarządzanych. Prostym sposobem wykonania tej czynności jest utworzenie kopii dokumentu i tłumaczenie tekstu przy użyciu programu Microsoft Office Word lub Microsoft Office Excel. Ten proces działa nawet wtedy, gdy nie wprowadzisz żadnych zmian w kodzie, ponieważ dowolna liczba dokumentów może być połączona z tym samym zestawem.
Nadal musisz upewnić się, że każda część kodu, która wchodzi w interakcję z tekstem dokumentu, jest nadal zgodna z językiem tekstu, oraz że zakładki, nazwane zakresy i inne pola wyświetlania umożliwiają ponowne sformatowanie dokumentu pakietu Office, które było niezbędne do dostosowania pod kątem innej gramatyki i długości tekstu. W przypadku szablonów dokumentów zawierających stosunkowo mały tekst warto rozważyć zapisanie tekstu w plikach zasobów, a następnie załadowanie tekstu w czasie wykonywania.
Kierunek tekstu
W programie Excel można ustawić właściwość arkusza tak, aby renderować tekst od prawej do lewej. Kontrolki hosta lub dowolna kontrolka RightToLeft , która ma właściwość, która jest umieszczana w projektancie automatycznie pasują do tych ustawień w czasie wykonywania. Program Word nie ma ustawienia dokumentu dla tekstu dwukierunkowego (wystarczy zmienić wyrównanie tekstu), więc nie można zamapować kontrolek na to ustawienie. Zamiast tego należy ustawić wyrównanie tekstu dla każdej kontrolki. Można napisać kod, aby przejść przez wszystkie kontrolki i wymusić renderowanie tekstu od prawej do lewej.
Zmień kulturę
Kod dostosowywania na poziomie dokumentu zwykle udostępnia główny wątek interfejsu użytkownika programu Excel, więc wszelkie zmiany wprowadzone w kulturze wątków mają wpływ na wszystkie inne elementy uruchomione w tym wątku; zmiana nie jest ograniczona do dostosowania.
Kontrolki Windows Forms są inicjowane przed uruchomieniem przez aplikację hosta dodatków VSTO na poziomie aplikacji. W takich sytuacjach należy zmienić kulturę przed ustawieniem kontrolek interfejsu użytkownika.
Instalowanie pakietów językowych
Jeśli masz ustawienia inne niż angielski dla systemu Windows, możesz zainstalować pakiety językowe środowiska uruchomieniowego Visual Studio Tools dla pakietu Office, aby wyświetlić komunikaty środowiska uruchomieniowego Visual Studio Tools dla pakietu Office w tym samym języku co system Windows. Jeśli użytkownicy końcowi uruchamiają rozwiązania z ustawieniami innych niż angielski dla systemu Windows, muszą mieć poprawny pakiet językowy, aby wyświetlać komunikaty środowiska uruchomieniowego w tym samym języku co system Windows. Pakiety językowe środowiska uruchomieniowego Visual Studio Tools dla pakietu Office są dostępne w centrum pobierania firmy Microsoft.
Ponadto pakiety językowe pakietu redystrybucyjnego .NET Framework są niezbędne dla komunikatów ClickOnce. Pakiety językowe programu .NET Framework są dostępne w centrum pobierania firmy Microsoft.
Ustawienia regionalne i wywołania COM programu Excel
Za każdym razem, gdy zarządzany klient wywołuje metodę w obiekcie COM i musi przekazać informacje specyficzne dla kultury, robi to przy użyciu CurrentCulture ustawień regionalnych (ustawień regionalnych), które są zgodne z bieżącymi ustawieniami regionalnymi wątku. Bieżące ustawienia regionalne wątku są domyślnie dziedziczone z ustawień regionalnych użytkownika. Jednak po wywołaniu modelu obiektów programu Excel z rozwiązania programu Excel utworzonego przy użyciu narzędzi programistycznych pakietu Office w programie Visual Studio format danych języka angielskiego (Stany Zjednoczone) (identyfikator ustawień regionalnych 1033) jest automatycznie przekazywany do modelu obiektów programu Excel. Przed przekazaniem ich do programu Microsoft Office Excel lub odczytaniem danych z kodu projektu należy sformatować wszystkie dane, które mają poufne ustawienia regionalne, takie jak daty i Stany Zjednoczone waluta.
Zagadnienia dotyczące przechowywania danych
Aby upewnić się, że dane są poprawnie interpretowane i wyświetlane, należy również wziąć pod uwagę, że problemy mogą wystąpić, gdy aplikacja przechowuje dane, takie jak formuły arkusza programu Excel, w literałach ciągów (zakodowanych na twardo) zamiast w obiektach silnie typiowanych. Należy użyć danych sformatowanych przy założeniu niezmiennego stylu kultury lub angielskiego (Stany Zjednoczone) (wartości LCID 1033).
Aplikacje używające literałów ciągów
Możliwe wartości, które mogą być zakodowane na twardo, obejmują literały dat pisane w formacie angielskim (Stany Zjednoczone) oraz formuły arkusza programu Excel zawierające zlokalizowane nazwy funkcji. Inną możliwością może być zakodowany ciąg zawierający liczbę, taką jak "1000"; w niektórych kulturach jest to interpretowane jako tysiąc, ale w innych kulturach reprezentuje jeden punkt zero. Obliczenia i porównania wykonywane w niewłaściwym formacie mogą spowodować nieprawidłowe dane.
Program Excel interpretuje wszystkie ciągi zgodnie z identyfikatorem LCID przekazywanym za pomocą ciągu. Może to być problem, jeśli format ciągu nie odpowiada przekazanemu identyfikatorowi LCID. Rozwiązania programu Excel utworzone przy użyciu narzędzi programistycznych pakietu Office w programie Visual Studio używają identyfikatora LCID 1033 (en-US) podczas przekazywania wszystkich danych. Program Excel wyświetla dane zgodnie z ustawieniami regionalnymi i językiem interfejsu użytkownika programu Excel. Język Visual Basic for Applications (VBA) działa również w ten sposób; ciągi są formatowane jako en-US i VBA prawie zawsze przekazuje wartość 0 (neutralną dla języka) jako identyfikator LCID. Na przykład następujący kod VBA wyświetla poprawnie sformatowaną wartość 12 maja 2004 r., zgodnie z ustawieniem ustawień regionalnych bieżącego użytkownika:
'VBA
Application.ActiveCell.Value2 = "05/12/04"
Ten sam kod, używany w rozwiązaniu utworzonym przy użyciu narzędzi programistycznych pakietu Office w programie Visual Studio i przekazywany do programu Excel za pośrednictwem międzyoperacyjności modelu COM, generuje te same wyniki, gdy data jest sformatowana w stylu en-US.
Na przykład:
Zawsze, gdy jest to możliwe, należy pracować z silnie typinymi danymi zamiast literałów ciągów. Na przykład zamiast przechowywać datę w literału ciągu, zapisz ją jako Double, a następnie przekonwertuj ją na DateTime obiekt w celu manipulowania.
Poniższy przykład kodu przyjmuje datę, którą użytkownik wprowadza w komórce A5, przechowuje jako element , a następnie konwertuje go Doublena DateTime obiekt do wyświetlania w komórce A7. Aby wyświetlić datę, należy sformatować komórkę A7.
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);
}
}
Funkcje arkusza programu Excel
Nazwy funkcji arkusza są tłumaczone wewnętrznie dla większości wersji językowych programu Excel. Jednak ze względu na potencjalne problemy z międzyoperacją języka i modelu COM zaleca się używanie tylko angielskich nazw funkcji w kodzie.
Aplikacje korzystające z danych zewnętrznych
Każdy kod, który zostanie otwarty lub w inny sposób używa danych zewnętrznych, takich jak pliki zawierające wartości rozdzielane przecinkami (pliki CSV) wyeksportowane ze starszego systemu, może również mieć wpływ, jeśli takie pliki są eksportowane przy użyciu dowolnego formatu oprócz en-US. Dostęp do bazy danych może nie mieć wpływu, ponieważ wszystkie wartości powinny być w formacie binarnym, chyba że baza danych przechowuje daty jako ciągi lub wykonuje operacje, które nie używają formatu binarnego. Ponadto w przypadku konstruowania zapytań SQL przy użyciu danych z programu Excel może być konieczne upewnienie się, że są one w formacie en-US, w zależności od używanej funkcji.