Excel OLE - Problem nach Speichern

[SearchBot]

Hallo,

ich habe ein Excelsheet (xlsx auf Excel2013; Bereiche sind Kennwortgeschützt und Mappe ist freigegeben, was aber die Bearbeitung nicht behindert), das ich in meiner Anwendung öffne, bearbeite und speichere. Klappt erstmal super :-D

Wenn ich nun das gespeicherte Sheet wieder öffne, bekomme ich von Excel einen Namenskonflikt (Siehe Screenshot1) und ich muss 1-2 Namen eintippen.
Dieses Problem gibt es schon lange (google Suche nach "Excel Namenskonflikt Print_Area" bzw. .."Print_Title") - aber es scheint nicht klar zu sein, woher das Problem kommt (sonst hätte es MS wohl schon gefixt!?).

Ich kann wohl wenig falsch machen, wenn ich das Sheet wie folgt erfolgreich öffne:

Delphi-Quellcode:

 
//ich verwende die TExcelApplication-Komponente, die ich einfach "xls" genannt habe
//global habe ich da noch:
var  
  wb: _WorkBook;
  ws: _WorkSheet;
  lcid: Integer;

//dann in einem OnClick:
 xls.Connect;
 lcid := GetUserDefaultLCID;
 wb:=xls.Workbooks.Open(
  format('%s\RMA_%s.xlsx',[le_pfad.text,le_RMAnr.text]),
  emptyParam,  emptyParam,  emptyParam,
  emptyParam,  emptyParam,  emptyParam,
  emptyParam,  emptyParam,  emptyParam,
  emptyParam,  emptyParam,  emptyParam,
  lcid);
 ws:=xls.Sheets[1] as _worksheet;

Später speichere ich meine Änderungen beim Schließen des Programms

Delphi-Quellcode:

 wb.Save(lcid);
 xls.Quit;

Alles gut, keine Fehlermeldungen. :-D

Öffne ich nun das Sheet in Excel direkt und sehe mir mit Strg+F3 die definierten Namen an (weil ich darauf beim googlen gestoßen bin), stehen da plötzlich 2 neue definierte Namen (Siehe Screenshot), nämlich "Print_Area" und "Print_Title", während meine deutschen Namen "Druckbereich" und "Drucktitel" nach wie vor darin stehen und jeweils zeigen sie auf die gleichen Bereiche.

Während es keine Fehlermeldung gibt, wenn ich es nur mit Excel öffne, bekomme ich dieses bekannte Problem angezeigt, wenn ich es mit meinem Programm öffne :pale:

Für mich sieht das so aus, als würde beim Einlesen ein Sprachkonflikt die neuen Namen anlegen und somit in der gespeicherten Datei dann auftauchen. Beim erneuten Einlesen versucht Excel das nochmal und da ist ja dann schon dieser Name und man muss manuell einen anderen eintippen. :?

Wie aber kann man das Problem vermeiden? Liegt es an der Komponente? Oder an der OLE (falsche Sprachversion?), oder ein Bug im Excel beim Einlesen?

Oder - wie immer - mache ich was falsch?:roll:

[Jumpy]

Machst du denn in deinem Programm auch irgendwas mit dem Excel-Sheet? Du wirst es ja nicht nur öffnen und speichern? Vllt. entsteht dabei das Problem (neuer Druckbereich festlegen o.ä.).

[SearchBot]

Ja klar, ich lese darin bestimmte Zellen aus und füge hier und da Daten ein.

Der Druckbereich ist aber fest definiert und wird zu keiner Zeit verändert.
Mein Programm legt auch keine neuen Namen an (zumal ich garnicht wüsste, wie ich das hätte programmieren sollen!?) - bis zum Auftreten des Problems war mir garnicht bewusst, daß das überhaupt geht :roll:

[p80286]

Ganz entfernt war da mal was.
Versuch doch mal das Abspeichern mit

Delphi-Quellcode:

 excel.ActiveWorkbook.SaveAs(Filename:=excfile,FileFormat:=$38 {xlExcel8});

Wenn ich mich recht erinnere, war danach Ruhe, allerdings brauchte ich das auch um Kompatibilität zu den verschiedenen Versionen zu behalten.

Gruß
K-H

[Jumpy]

Was macht den die LCID Geschichte, MSDN ist gerade nicht zu erreichen. Hat das was mit Localisation zu tun, dann lass das doch mal weg, sprich nur:

wb:=xls.Workbooks.Open(format('%s\RMA_%s.xlsx',[le_pfad.text,le_RMAnr.text]));

[kompi]

Ich hatte dieses Problem auch schon mal in einer Anwendung. Diese Namenskonflikte tauchen immer dann auf, wenn man Excel - Dateien in dem neuen Dateiformat (ab Excel 2007) öffnen will.

Die Lösung besteht darin, statt Workbooks.open Workbooks.openxml zu verwenden. Dann sollte der Spuk vorbei sein.

Mit Workbooks.openxml lassen sich eben nicht nur XML Dateien öffnen, sondern auch die Excel Dateien im neueren Format.

Ich habe dies jedoch bisher nur mit Excel 2010 ausprobieren können.

Gruß
Kompi

[SearchBot]

Zitat:

Zitat von Jumpy (Beitrag 1355392)

Hat das was mit Localisation zu tun, dann lass das doch mal weg, ...

Ich nutze die Komponente, da kann ich keine Parameter weglassen.
Für LCID bekomme ich auf dem verwendeten System 1031. Wenn ich wüsste, was das Excel für eine Lokalisierung benötigt, nähme ich den gleichen Wert und gut?

Zitat:

Zitat von kompi (Beitrag 1355422)

Die Lösung besteht darin, statt Workbooks.open Workbooks.openxml zu verwenden. Dann sollte der Spuk vorbei sein.

Die Komponente hat nur .open und .opentext

Zitat:

Zitat von p80286 (Beitrag 1355390)

Ganz entfernt war da mal was.
Versuch doch mal das Abspeichern mit

Delphi-Quellcode:

 excel.ActiveWorkbook.SaveAs(Filename:=excfile,FileFormat:=$38 {xlExcel8});

Die Komponente erlaut dieses Format nicht.

Ich glaube langsam, ich sollte die Komponente in die Tonne treten..!? Ihr macht das alle ohne das Ding?

[Chemiker]

Hallo SearchBot,

bei EXCEL 2013 hast Du bei Workbooks.Open 15 Parameter. In Deinen Code sind es aber nur 13 Parameter.

Bis bald Chemiker

[SearchBot]

Zitat:

Zitat von Chemiker (Beitrag 1355435)

Hallo SearchBot,

bei EXCEL 2013 hast Du bei Workbooks.Open 15 Parameter. In Deinen Code sind es aber nur 13 Parameter.

Bis bald Chemiker

Die Komponente, die bei Berlin 10.1 dabei ist, beruht wohl auf Excel2000 und nimmt nicht mehr Parameter.

Ich habe mir jetzt einen Bugfix gebastelt, indem ich "einfach so frech bin" und vor dem Speichern in meinem Programm die von Excel fälschlich angelegten Namen lösche :stupid:

Danach habe ich keinen Namenskonflikt mehr, weil beim erneuten Öffnen Excel zwar wieder die Namen anlegt, die ich aber danach einfach wieder lösche :lol:

[Chemiker]

Hallo SearchBot,

es werden doch 2 Komponenten-Arten angeboten, wenn Du statt „MS Office 2000 Beispiele für gekapselte Komponenten für Automatisierungsserver“ den „MS Office XP …“ wählst sollte auch Workbooks.Open mit den richtigen Parametern arbeiten.
Und wenn man ganz unabhängig von der EXCEL-Version arbeitet, sollte man statt der späten Bindung die frühe Bindung benutzen.

Bis bald Chemiker