Prüfen, ob Excel installiert ist

[KodeZwerg]

Zitat:

Zitat von p80286 (Beitrag 1411425)

Zitat:

Zitat von Luckie (Beitrag 1411363)

Warum bei einer einfachen True/False Abfrage eine Exception missbrauchen? Exceptions sind eigentlich dazu gedacht Fehler zu behandeln, die man nicht selbst beeinflussen kann. Netzwerkstecker wird gezogen, Festplatte voll, Diskette wird vom Benutzer ausgeworfen. Und die kein sinnvolles weiter Ausführen des Codes an der Stelle erlauben. Und du verschachtelst sogar noch zwei Exceptions.

Und was wäre die Alternative?

Delphi-Quellcode:

olevExcel := GetActiveOleObject('Excel.Application');
  if oleexcel=unassigned then.....

Gruß
K-H

Anhang 49817
Testet Ihr eigentlich das?
Eine Test-Möglichkeit wäre das 'Excel.Application' mit Quatsch zu ersetzen und schauen was passiert.
Ob nun als exception wie beim Chemiker oder Fehler wie das obige,
man will doch eigentlich genau so etwas verhindern?

Zitat:

Zitat von p80286 (Beitrag 1411425)

Und was wäre die Alternative?

Post #2 und #4

[KodeZwerg]

Zitat:

Zitat von API (Beitrag 1411426)

Und CreateOleObject('Excel.Application') erzeugt eine Excel Instanz, welche im Hintergrund weiterläuft, falls diese nicht beendet wird.

Soweit ich weiß beenden sich solche Objekte von alleine oder wenn man, was auch immer vor " := CreateOleObject()" steht einen anderen Wert zuweist, in beiden Fällen sollte es beendet sein, wann auch immer.

Ist das falsch?

[Delphi.Narium]

Delphi-Quellcode:

uses
  ActiveX;

function IsInstalled(AValue : String) : Boolean;
var
  ClassID: TCLSID;
begin
  Result := CLSIDFromProgID(PWideChar(WideString(AVAlue)), ClassID) = S_OK;
end;

function IsExcelInstalled : Boolean;
var
  ClassID: TCLSID;
begin
  Result := CLSIDFromProgID(PWideChar(WideString('Excel.Application')), ClassID) = S_OK;
end;
// oder:
function IsExcelInstalled : Boolean;
begin
  Result := IsInstalled('Excel.Application');
end;

procedure TForm1.WelcheProzedurAuchImmer(Sender: TObject);
begin
  // Prüfen, ob Excel installiert ist:
  if IsExcelInstalled then ShowMessage('ja') else ShowMessage('nein');
  // Prüfen, ob die als Parameter übergebene Software installiert ist:
  if IsInstalled('Excel.Application') then ShowMessage('ja') else ShowMessage('nein');
  if IsInstalled('Word.Application') then ShowMessage('ja') else ShowMessage('nein');
end;

[Delphi.Narium]

Zitat:

Zitat von KodeZwerg (Beitrag 1411428)

Zitat:

Zitat von API (Beitrag 1411426)

Und CreateOleObject('Excel.Application') erzeugt eine Excel Instanz, welche im Hintergrund weiterläuft, falls diese nicht beendet wird.

Soweit ich weiß beenden sich solche Objekte von alleine oder wenn man, was auch immer vor " := CreateOleObject()" steht einen anderen Wert zuweist, in beiden Fällen sollte es beendet sein, wann auch immer.

Ist das falsch?

Dann erstell' doch mal in 'nem Programm Excel und beende Dein Programm, ohne Excel "aufzuräumen." Was bleibt im Taskmanager übrig?

Wenn Excel vorher schon lief?
Wenn Excel vorher noch nicht lief?
Wenn Du vorm Programmende der "Excelvariabel" was anderes zuweist?

[KodeZwerg]

Gesagt, getan, verstanden.:oops:

[p80286]

Zitat:

Zitat von KodeZwerg (Beitrag 1411427)

Zitat:

Zitat von p80286 (Beitrag 1411425)

Zitat:

Zitat von Luckie (Beitrag 1411363)

Warum bei einer einfachen True/False Abfrage eine Exception missbrauchen? Exceptions sind eigentlich dazu gedacht Fehler zu behandeln, die man nicht selbst beeinflussen kann. Netzwerkstecker wird gezogen, Festplatte voll, Diskette wird vom Benutzer ausgeworfen. Und die kein sinnvolles weiter Ausführen des Codes an der Stelle erlauben. Und du verschachtelst sogar noch zwei Exceptions.

Und was wäre die Alternative?

Delphi-Quellcode:

olevExcel := GetActiveOleObject('Excel.Application');
  if oleexcel=unassigned then.....

Gruß
K-H

Anhang 49817
Testet Ihr eigentlich das?
Eine Test-Möglichkeit wäre das 'Excel.Application' mit Quatsch zu ersetzen und schauen was passiert.
Ob nun als exception wie beim Chemiker oder Fehler wie das obige,
man will doch eigentlich genau so etwas verhindern?

Zitat:

Zitat von p80286 (Beitrag 1411425)

Und was wäre die Alternative?

Post #2 und #4

Das wäre ein anderer Weg, aber es geht darum, nicht mit Exceptions zu arbeiten.

Gruß
K-H

[Chemiker]

Hallo zusammen,

@ Luckie: Also, in meinen Programmen machte es absolut keinen Sinn, ohne Excel weiterzuarbeiten. Aus diesem Grund kann man eine Exception verwenden.

@KodeZwerg: Mit Deinem Code (der veraltet ist) baust Du CreateOleObject/GetActiveOleObject eigentlich nur nach.


Bis bald Chemiker

[KodeZwerg]

Zitat:

Zitat von Chemiker (Beitrag 1411483)

@KodeZwerg: Mit Deinem Code (der veraltet ist) baust Du CreateOleObject/GetActiveOleObject eigentlich nur nach.

Eigentlich ruft mein Code die Registry HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID ab soweit ich mich erinnern kann und der OLE Created/Getted nichts.

Ich muss mal debuggen um das nachzuvollziehen was Du da schreibst.

Veraltet? Wie lautet bitte NextGen Befehl der meinen Ersetzt? (CLSIDFromProgID)

[MHaitz]

Vielen Dank schon mal für die vielen Vorschläge.
ich hab mich mal für die Version:
'Result := CLSIDFromProgID(PWideChar(WideString('Excel.Applic ation')), ClassID) = S_OK;'
entschieden.
Noch eine weitere Frage.
Auf neuen Rechnern mit Windows 10 ist meist eine vorinstallierte, aber nicht voll funktionsfähige Excel Version vorhanden, welche wohl zum Kauf einer Volllizenz animieren soll.
In beiden Fällen liefert obige Funktion True.

Gibt es eine Möglichkeit, die 'vorläufige' Version von einer Vollversion vom Programmcode aus zu unterscheiden?

Gruß
MHaitz

[KodeZwerg]

Ich habe leider keine Demo Version davon, aber mein erster Gedanke wäre mich durch die Registry zu wühlen.

Hier siehst Du einen Ansatz dazu.

edit
Ps:
Um nach einer gezielten Registry zu fahnden, hier erfährst Du welche Versionsnummer Du in Registry abfragen musst.