Formatieren von Daten in Excel mit verschiedenen regionalen Einstellungen
Alle Daten mit gebietsschemaabhängigen Formatierungen, z. B. Datumsangaben und Währungen, müssen mit dem Datenformat Englisch (USA) (Gebietsschema-ID 1033) formatiert sein, bevor sie an Microsoft Office Excel übergeben oder durch Code im Office-Projekt ausgelesen werden.
Betrifft: Die Informationen in diesem Thema betreffen Projekte auf Dokument- und auf Anwendungsebene für Excel 2007 und Excel 2010. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.
Standardmäßig wird beim Entwickeln einer Office-Lösung in Visual Studio vom Excel-Objektmodell eine Datenformatierung mit Gebietsschema-ID 1033 erwartet (wird auch als Sperren des Objektmodells in Gebietsschema-ID 1033 bezeichnet). Dieses Verhalten entspricht der Methode, die auch für Visual Basic for Applications (VBA) verwendet wird. Dieses Verhalten kann in den Office-Lösungen jedoch geändert werden.
Grundlegendes dazu, wie das Excel-Objektmodell immer Gebietsschema-ID 1033 erwartet
Standardmäßig werden mit Visual Studio erstellte Office-Lösungen vom Gebietsschema des Endbenutzers nicht beeinflusst. Sie verhalten sich stets, als wäre das Gebietsschema Englisch (USA). Wenn Sie beispielsweise die Value2-Eigenschaft in Excel abrufen oder festlegen, müssen die Daten gemäß Gebietsschema-ID 1033 formatiert sein. Ein anderes Datenformat führt u. U. zu unerwarteten Ergebnissen.
Obwohl Sie für Daten, die durch verwalteten Code übergeben oder geändert werden, das Format Englisch (USA) verwenden, werden die Daten in Excel gemäß den lokalen Einstellungen des Endbenutzers interpretiert und angezeigt. Excel kann die Daten korrekt formatieren, weil der verwaltete Code zusammen mit den Daten den Gebietsschema-ID 1033 übergibt, sodass klar ist, dass die Daten das Format Englisch (USA) besitzen und entsprechend den lokalen Einstellungen des Benutzers neu formatiert werden müssen.
Wenn Endbenutzer z. B. ihre Regionaloptionen auf das Gebietsschema Deutsch (Deutschland) festgelegt haben, erwarten sie, dass das Datum 29. Juni 2005 folgendermaßen formatiert wird: 29.06.2005. Wenn die Lösung jedoch das Datum als Zeichenfolge an Excel übergibt, muss das Datum gemäß dem Format Englisch (USA) formatiert werden: 6/29/2005. Wenn die Zelle als Datumszelle formatiert wird, zeigt Excel das Datum im Format Deutsch (Deutschland) an.
Übergeben von anderen Gebietsschema-IDs an das Excel-Objektmodell
In Projekten, für die als Zielversion .NET Framework 4 festgelegt wird, wird von der Common Language Runtime (CLR) die Gebietsschema-ID 1033 automatisch an alle Methoden und Eigenschaften im Excel-Objektmodell übergeben, für die gebietsschemaabhängige Daten akzeptiert werden. Es gibt keine Möglichkeit, dieses Verhalten für alle Aufrufe im Objektmodell automatisch zu ändern. Sie können jedoch unter Verwendung von InvokeMember zum Aufrufen der Methode und durch Übergeben der Gebietsschema-ID an den culture-Parameter der Methode eine andere Gebietsschema-ID übergeben.
In Projekten, für die als Zielversion .NET Framework 3.5 festgelegt wurde, übergibt Visual Studio Tools for Office-Laufzeit die Gebietsschema-ID 1033 standardmäßig an das Excel-Objektmodell. Allerdings kann dieses Verhalten mithilfe von Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute geändert werden.
Ändern von .NET Framework 3.5-Projekten, damit die Gebietsschemaeinstellungen des Endbenutzercomputers verwendet werden
Sie können das Gebietsschema-ID-Verhalten für das gesamte Excel-Objektmodell in Office-Projekten entsperren, für die als Zielversion .NET Framework 3.5 festgelegt wurde. Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute ermöglicht die Steuerung des Excel-Objektmodellverhaltens in diesen Projekten. Standardmäßig ist das Attribut auf true festgelegt, sodass das Excel-Objektmodell gesperrt ist und stets eine Datenformatierung nach Gebietsschema-ID 1033 erwartet wird. Wenn dieses Attribut auf true festgelegt wird, werden alle Excel-Objekte umschlossen, die von der Lösung in einem Proxyobjekt instanziiert werden, das stets die Gebietsschema-ID 1033 an Excel übergibt. Wenn Sie das Attribut auf false festlegen, werden diese Proxyobjekte nicht verwendet, und das Excel-Objektmodell verwendet das Gebietsschema des Endbenutzers.
Wenn Sie das Attribut auf false festlegen, können Sie nach wie vor mithilfe von Reflektion erzwingen, dass für bestimmte Aufrufe von Excel-Eigenschaften und -Methoden das Datenformat Englisch (USA) (Gebietsschema-ID 1033) verwendet wird. Weitere Informationen finden Sie unter Gewusst wie: Sicherstellen der richtigen regionalen Verwendung von Zeichenfolgenliteralen in Excel mithilfe der Reflektion.
Tipp
Wenn Sie das Attribut auf false festlegen, weist die Projektmappe bei Endbenutzern mit einem anderen Gebietsschema als Englisch (USA) möglicherweise ein unerwartetes Verhalten auf.
Um das Objektmodell zu entsperren, legen Sie in Ihrem Projekt in der Datei "AssemblyInfo.vb" bzw. "AssemblyInfo.cs" das Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute-Attribut auf false fest.
<Assembly: ExcelLocale1033(False)>
[assembly: ExcelLocale1033(false)]
Tipp
Da die Visual Studio Tools for Office-Laufzeit alle systemeigenen Excel-Objekte mit einem Proxyobjekt umschließen, wenn Microsoft.Office.Tools.Excel.ExcelLocale1033Attribute den Wert true aufweist, können sich einige Vorgänge mit systemeigenen Excel-Objekten verlangsamen. In diesen Fällen können Sie die Leistung verbessern, indem Sie mithilfe der Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Unwrap(System.Object)-Methode das Excel-Objekt ohne Proxy abrufen und anschließend den Vorgang mit diesem Objekt ausführen. Beachten Sie in diesem Fall, dass das von Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Unwrap(System.Object) zurückgegebene Objekt die Gebietsschema-ID des aktuellen Threads und nicht die Gebietsschema-ID 1033 verwendet.
Siehe auch
Aufgaben
Gewusst wie: Lokalisieren von Excel-Projektmappen
Konzepte
Erweitern von Metadaten mithilfe von Attributen
Übersicht über die Visual Studio Tools for Office-Laufzeit