Herausfinden, welche Excelversion genutzt werden kann

[xZise]

Hallo ihr,
ich benutze zum Einlesen von Daten die Möglichkeit Exceltabellen einzulesen. Nun haben wir es bisher mit MSO 2003 und 2007 getestet. Und wie kann ich jetzt abfragen, ob Excel installiert ist (also 2003 oder 2007)? Bisher habe ich folgenden Code gefunden:

Delphi-Quellcode:

function TDatenbank.ExcelInstalliert: Boolean;
var
  tmp : TGUID;
begin
  // Test auf MSO 2k3, vielleicht geht es nicht für MSO 2k7?
  Result := Succeeded(CLSIDFromProgID(PWideChar('Excel.Application.11'), tmp));
end;

Nun habe ich leider hier weder 2003 noch 2007 und diese Funktion liefert auch False. Aber wie müsste ich das erweitern? Ich tippe mal auf eine OR-Verknüpfung und einer 12 im zweiten Eintrag, statt der 11.

Achso möglichst so, dass ich auch überprüfen kann, um welche Version es sich handelt, sofern dies hier "stimmt".

MfG
xZise

[mkinzler]

Excel 2007 müsste beide COM-Klassen anbieten

[xZise]

Das heißt, mit MSO 2k7 würde das auch True zurückgeben? Kann ich dann herausfinden, ob ich OpenXML öffnen kann?

MfG
xZise

[mkinzler]

Zitat:

Das heißt, mit MSO 2k7 würde das auch True zurückgeben?

Ja.

Zitat:

Kann ich dann herausfinden, ob ich OpenXML öffnen kann?

Es müsste möglich sein. Obwohl ich gelesen habe, das O2k7 anders wie die Vorgänger nicht 100%ig abwärtskompatibel sind. Aber ein simples Open sollte er eigentlich verstehen

[xZise]

Naja, bisher könnten wir die Daten erfolgreich auch mit MSO 2007 einlesen. Aber es war halt eine normale Tabelle. Und nun hatte ein Lehrer gefragt ob er auch das neue Format öffnet, und heute ist mir eingefallen, das er das sozusagen automatisch unterstützt. Ich müsste halt nur herausfinden, ob ich MSO 2k7 oder MSO 2k3 benutzen kann (zur Laufzeit) und dann entsprechend im Öffnen-Dialog auch xlsx anbieten.

Und genau den Schritt zum Herausfinden, ob auf dem Rechner auf MSO 2k7 zurückgegriffen werden kann fehlt mir.

MfG
xZise

[mkinzler]

O2k7 bieten alle Klassen an O2k3, die von O2k7 nicht. Zudem gibt es ja auch ein Converter-Pack für ältere Office-Pakete, das diesen erlaubt OpenXML zu Laden.

[xZise]

Ich verstehe gerade nicht was du meinst :D

Ich dachte daran:

Delphi-Quellcode:

type
  TExcelVersion = (ev2003, ev2007, evNone);

function ExcelVersion : TExcelVersion;
begin
  Result := .... (hier bitte den Code :D )
end;

procedure DoSmth;
begin
  case ExcelVersion do
    ev2003 : OD.Filter := 'xls|*.xls';
    ev2007 : OD.Filter := 'xls(x)|*.xls;*.xlsx';
    else begin
      ShowMessage('Nix Excel');
      Exit;
    end;
  end;  
  if OD.Execute do
    ...
end;

Weil konvertieren wollte ich die Datei nicht :D

MfG
xZise

[mkinzler]

O2k3 implemnetiert Excel.Application.12 nicht.
Konvertiern meint in diesem Fall Laden

[xZise]

Zitat:

Zitat von mkinzler

O2k3 implemnetiert Excel.Application.12 nicht.

Achso ;) Das "hätte" ich mir gedacht :P Ich habe mich aber halt gefragt ob MSO 2k7 dies implementiert ;)

Zitat:

Zitat von mkinzler

Konvertiern meint in diesem Fall Laden

Also ich hatte mal kurz gegooglet und ich hatte halt nur OOX <-> OD Konverter, aber halt dann nicht als Zwischenschicht, sondern als seperates Programm.

MfG
xZise

[mkinzler]

Der Converterpack ist von MS und erweitert ältere Versionen um Import/Export-Filter für die OpenXML-Dateiversionen

[xZise]

Hallo,

Also es funktioniert nicht so ganz. Also bei mir funktionierts (D2k9), aber TurboDelphi meckert:

Zitat:

[Pascal Fehler] UWerkzeuge.pas(89): E2089 Ungültige Typumwandlung

Und zwar ist das in der ersten If-Bedingung und auch in der zweiten.

Delphi-Quellcode:

function GibExcelVersion : TExcelVersion;
var
  tmp : TGUID;
begin
  // Test auf MSO 2k3 / MSO 2k7
  Result := evKeine;
  if Succeeded(CLSIDFromProgID(PWideChar('Excel.Application.11'), tmp)) then
    Result := ev2003
  else if Succeeded(CLSIDFromProgID(PWideChar('Excel.Application.12'), tmp)) then
    Result := ev2007;
end;

Wenn man das aber "aufteilt" also etwa so:

Delphi-Quellcode:

var
  s : string;
  pw : PWideChar;
  i : Integer;
begin
  s := 'Excel.Application.11';
  pw := PWideChar(s);
  i := CLSIDFromProgID(pw, tmp);
  if Succeeded(i) then

Das liefert keinen Fehler, aber das liefert auch kein Succeeded.
Ich muss dazu sagen, dass die aufgeteilte Version so sein sollte, aber ich kann dafür meine Hand leider nicht ins Feuer legen :D

MfG
xZise

[marky522]

Hallo,

also ich mach das immer so:

Delphi-Quellcode:

 excel2007:=false;
 try
  Excel:=CreateOleObject('excel.Application');
  if Excel.Version = '12.0' then excel2007:=true;
  Excel.quit
 except
  excole:=false;
 end;

Der Code liefert in der Variable excel2007 "true",
wenn Excel2007 gestartet werden konnte.

Mfg
Markus

[RWarnecke]

Hallo Fabian,

warum gehst Du nicht über die Registry ? Dazu nutze ich diese Tabelle :

Delphi-Quellcode:

{-----------------------------------------------------------------}
{- Programm       - Release Ver - SP 1      - SP 2      - SP 3   -}
{-----------------------------------------------------------------}
{- MS Office 2000 -  9.0.2      -  9.0.3    -  9.0.4    -  9.0.6 -}
{- MS Office XP   - 10.0.2      - 10.0.3    - 10.0.4    - 10.0.6 -}
{- MS Office 2003 - 11.0.5      - 11.0.6    - 11.0.7    - 11.0.8 -}
{- MS Office 2007 - 12.0.4      - 12.0.6215 - 12.0.6425 -        -}
{-----------------------------------------------------------------}

Für MSO XP und höher brauchst Du diese beiden Registry Key:

Zitat:

HKLM\SOFTWARE\Microsoft\Office\x.0\Registration
HKLM\SOFTWARE\Microsoft\Office\x.0\Common\ProductV ersion

Für x einfach die Version eintragen.

Bei Office 2000 musst Du die FileVersion von der Datei mso9.dll auslesen.

[xZise]

Okay über die Registry könnte ich auch gehen. Aber muss ich beide Einträge überprüfen?

Und eine theoretische Frage: Was ist wenn zwar Excel nicht installiert ist, aber das OleObjekt?

MfG
xZise

[mkinzler]

Zitat:

Und eine theoretische Frage: Was ist wenn zwar Excel nicht installiert ist, aber das OleObjekt?

Dann wäre etwas falsch gelaufen

[xZise]

Naja aber in der Theorie könnte doch auch eine andere Office Suite das Objekt zur Verfügung stellen oder?

MfG
xZise

[mkinzler]

Ich kenne keine andere Office-Suite, welches eine Excel-Com-Klasse bereitstellt. Und wenn eine das machen würde, müsste die sich ja kompatibel verhalten.

[RWarnecke]

Zitat:

Zitat von xZise

Okay über die Registry könnte ich auch gehen. Aber muss ich beide Einträge überprüfen?

Über den Schlüssel Registration kann die Edition ermittelt werden und über den Schlüssel Common\Productversion ermittelst Du die Versionsnummer.

[sx2008]

Zitat:

Zitat von RWarnecke

warum gehst Du nicht über die Registry ?

Die Funktion CLSIDFromProgID() geht auch über die Registry.
Allerdings ist die Registry eine Abstraktionsebene tiefer.
Es ist softwaretechnisch eine Ungeschicktheit eine tiefere Abstraktionsebene als nötig zu wählen.
Man möchte ja nicht wissen, was in der Registry steht, sondern welche COM-Klassen zur Verfügung stehen.

Delphi-Quellcode:

function ClassIDExists(classID:WideString):Boolean;
var
  tmp : TGUID;
begin
  Result := Succeeded(CLSIDFromProgID(PWideChar(classID), tmp));
end;

function GibExcelVersion : TExcelVersion;
begin
  // zuerst prüfen, ob Excel 2007 vorhanden - Reihenfolge ist wichtig
  if ClassIDExists('Excel.Application.12') then
    Result := ev2007;
  else if ClassIDExists('Excel.Application.11') then
    Result := ev2003
  else
    Result := evKeine;
end;

[xZise]

Hallo sx2008,
aber da gibt es das Problem, das er es nicht kompilieren kann. Zumindest unter Turbo Delphi Explorer. Mit Delphi 2009 kann ich das kompilieren.
Aber wenn man das aufteilt (siehe oben), dann kompiliert er zwar, meldet dann aber das weder MSO 2007 noch MSO 2003 installiert ist (also nicht bei mir, sondern bei einem Freund der das mitentwickelt).

MfG
xZise

[mkinzler]

Ersetz mal PWideChar() durch PChar()

[xZise]

Hmm, aber unter Turbo Delphi will er auch ein PWideChar als Übergabeparameter. Also im Moment kann ich das leider nicht testen, weil hier nicht Turbo Delphi installiert ist.

Aber ich werde nachher wahrscheinlich mal zu Vista rüberbooten, da habe ich dann Turbo Delphi.

MfG
xZise

[sx2008]

Zitat:

Zitat von xZise

aber da gibt es das Problem, das er es nicht kompilieren kann.

Fehlermeldung?

Aber es sollte klar sein, dass man auf jeden Fall eine Funktion wie ClassIDExists() benötigt.
Man kann ja nicht für jede Abfrage den Code erneut hinschreiben wie das in Beitrag #11 anklingt.

Die Deklaration von CLSIDFromProgID() aus Unit ActiveX sieht unter Delphi 2007 so aus:

Delphi-Quellcode:

type   POleStr = PWideChar;
...
function CLSIDFromProgID(pszProgID: POleStr; out clsid: TCLSID): HResult; stdcall;

Ich vermute das Problem jetzt mal beim Parameter pszProgID.
Hier eine Änderung (compiliert unter D2007 ebenfalls)

Delphi-Quellcode:

function ClassIDExists(classID:WideString):Boolean;
var
  tmp : TGUID;
begin
  Result := Succeeded(CLSIDFromProgID(POleStr(classID), tmp));
end;

[xZise]

Zitat:

Zitat von xZise

Hallo,

Also es funktioniert nicht so ganz. Also bei mir funktionierts (D2k9), aber TurboDelphi meckert:

Zitat:

[Pascal Fehler] UWerkzeuge.pas(89): E2089 Ungültige Typumwandlung

Und zwar ist das in der ersten If-Bedingung und auch in der zweiten.

Delphi-Quellcode:

function GibExcelVersion : TExcelVersion;
var
  tmp : TGUID;
begin
  // Test auf MSO 2k3 / MSO 2k7
  Result := evKeine;
  if Succeeded(CLSIDFromProgID(PWideChar('Excel.Application.11'), tmp)) then
    Result := ev2003
  else if Succeeded(CLSIDFromProgID(PWideChar('Excel.Application.12'), tmp)) then
    Result := ev2007;
end;

Wenn man das aber "aufteilt" also etwa so:

Delphi-Quellcode:

var
  s : string;
  pw : PWideChar;
  i : Integer;
begin
  s := 'Excel.Application.11';
  pw := PWideChar(s);
  i := CLSIDFromProgID(pw, tmp);
  if Succeeded(i) then

Das liefert keinen Fehler, aber das liefert auch kein Succeeded.
Ich muss dazu sagen, dass die aufgeteilte Version so sein sollte, aber ich kann dafür meine Hand leider nicht ins Feuer legen :D

MfG
xZise

[sx2008]

@xZise: das ist auch nicht der Code, den ich in Betrag #19 gepostet habe!

[xZise]

Aber warum sollte dann der Fehler nicht mehr auftreten?

MfG
xZise

[sx2008]

Delphi-Quellcode:

function ClassIDExists(const classID:WideString):Boolean;
var
  tmp : TGUID;
begin
  Result := Succeeded(CLSIDFromProgID(PWideString(classID), tmp));
end;

Weil der Übergabeparameter den Datentyp WideString hat.
WideString und PWideString sind kompatibel; der Compiler weiss wie er die Typumwandlung vornehmen muss.
String, genauer gesagt AnsiString und PWideString sind nicht kompatibel.
Untehalb D2009 gilt: String=AnsiString
Ab D2009 gilt: String=WideString (das ist der Grund weshalb PWideString('irgendein Text') erlaubt ist)
Bei den älteren Delphi Versionen nimmt der Compiler die Konvertierung zwischen String und WideString
beim Aufruf einer Funktion oder Procedure automatisch vor.
Nimm einfach obige Funktion und es funktioniert für alle Delphi Versionen.

[xZise]

Ah stimmt. Das heißt ein Cast nach WideString hätte aber auch funktioniert... Ich hatte eigentlich gedacht so eine unbedenkliche Umwandlung, besonders weil das ja Quasi eine Konstante ist, wird automatisch durchgeführt.

Okay ich frage mal meinen Kumpel ob es jetzt funktioniert.

MfG
xZise

[xZise]

Okay, es lag tatsächlich daran!

MfG
xZise