OLE und Delphi 2007

SchwinneZ · Hält's aus hier Beiträge: 2

Hallo,

ich habe Delphi 2007 und will Excel per OLE starten und steuern.

Das folgende Beispiel welches man auf fast jeder Seite findet funktioniert bei mir nicht:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:

procedure TForm1.Button1Click(Sender: TObject);
var excel:Variant;
begin

try
Excel := CreateOleObject('Excel.Application');
except
ShowMessage('Excel konnte nicht gestartet werden !');
//Ende:=true;
end;
Excel.Workbooks.Add;
Excel.Cells[1, 1].Value:='Hallo Welt';

end;

Wenn ich das ganze über Komponenten also TExcelApplication & Co mache, bekomme ich das Programm zwar gestartet aber die Befehle, Klassen usw. scheinen komplett anders zu funktionieren als das hier überall steht.
Kann das sein das seit Delphi 2007 die OLE Automatisierung komplett geändert wurde?

Kennt jemand ein gutes Tutorial?

Moderiert von Narses: Code- durch Delphi-Tags ersetzt

zuma · Verfasst: Mi 17.06.09 10:47

kann dir mit Excel nichts sicher sagen, aber mit Word mach ich es so:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

uses
 ... Word97, Word2000 ...

implementation

...
var FWordApp : TWordApplication;
begin 

FWordApp := TWordApplication.Create(aOwner);

(bsp.)
olePrinterName         := MsOffImageDrucker;       // Druckername
drucker                := FWordApp.ActivePrinter;  // aktuellen Drucker merken
FWordApp.ActivePrinter := olePrinterName;          // anderen Drucker in Word setzen
(/bsp.)
....

_________________
Ich habe nichts gegen Fremde. Aber diese Fremden sind nicht von hier! (Methusalix)
Warum sich Sorgen ums Leben machen? Keiner überlebts!

bummi · Verfasst: Mi 17.06.09 11:10

ComObj hast Du in den uses drin ?

Excel.Visible := true; auch;
Läufst Du in die Exception?
Ich kenne derartige Probleme wenn DCOM verbogen wurde

Xentar · Verfasst: Mi 17.06.09 11:16

Hab auch D2007, und gerade kurz ausprobiert.
Das Excel.Visible := True; fehlt in deinem Code, dann geht das auch..

Edit:
Ein Blick in den Task Manager hätte übrigens schon geholfen, denn da sieht man, dass Excel.exe zwar gestartet wird, aber eben nicht sichtbar ist.

Edit 2:
Was meinst du eigentlich damit, dass sich die ganzen Befehle geändert haben..? Bis auf das Visible geht oben gezeigter Code bei mir, Delphi 2007 + Office 2007.

_________________
PROGRAMMER: A device for converting coffee into software.

Chemiker · Verfasst: Mi 17.06.09 22:14

Hallo SchwinneZ,

SchwinneZ hat folgendes geschrieben:

Wenn ich das ganze über Komponenten also TExcelApplication & Co mache, bekomme ich das Programm zwar gestartet aber die Befehle, Klassen usw. scheinen komplett anders zu funktionieren als das hier überall steht.

Der Grund dafür ist, dass es 2 Varianten für den Zugriff auf Excel gibt. Dein Quellcode ist die frühe Bindung, mit den Komponenten wird die späte Bindung benutzt.
Dadurch kommt es zu etwas unterschiedlicher Syntax.

Bis bald Chemiker

delfiphan · Beiträge: 2684 Erhaltene Danke: 32

Chemiker hat folgendes geschrieben :

Dein Quellcode ist die frühe Bindung, mit den Komponenten wird die späte Bindung benutzt.

Nein, es ist doch genau umgekehrt. CreateOleObject('Excel.Application'); ist late-binding (Automation). Deswegen auch einem Variant zuweisbar. Der Zugriff wird über IDispatch gesteuert (Variant von Typ varDispatch).
Wie die Komponenten implementiert sind, weiss ich jetzt nicht, aber ich gehe stark davon aus, dass dort early-binding oder zu mindest dispid-binding zum Einsatz kommt.

Die zwei Zugriffsmöglichkeiten haben nichts mit Delphi zu tun sondern sind fester Bestandteil von COM (siehe dual interfaces).

Es gibt nicht viele Gründe, in Delphi late-binding zu verwenden. Das wurde eher für Sprachen wie VB oder JScript gemacht, um den Zugriff zu vereinfachen.

Wenn du eine COM/ActiveX Komponente in Delphi verwenden willst, kannst du die mit wenigen Klicks als Komponente importieren. Delphi kreiert dir dann eine Unit aus der TypeLibrary der Komponente.

Chemiker · Verfasst: Fr 19.06.09 01:07

Hallo dephiphan,

dephiphan hat folgendes geschrieben:

Nein, es ist doch genau umgekehrt.

Ja, ist genau umgekehrt.

dephiphan hat folgendes geschrieben:

Es gibt nicht viele Gründe, in Delphi late-binding zu verwenden. Das wurde eher für Sprachen wie VB oder JScript gemacht, um den Zugriff zu vereinfachen.

Der wichtigste Grund ist, dass man den Quellcode bei verschiedenen Excel-Versionen nicht ändern braucht, bei der frühen Bindung aber schon. Dafür ist der Zugriff langsamer und man hat in der Delphi IDE keine Unterstützung bei den Befehlen.

Die späte Bindung hat den Vorteil, dass man Excel-Objekte, Methoden usw. nutzen kann, die in älteren Excel-Versionen noch nicht vorhanden sind, und wenn der Code abwärtskompatibel sein soll.

Bis bald Chemiker

delfiphan · Beiträge: 2684 Erhaltene Danke: 32

Teilweise einverstanden. Du machst natürlich auch bei late-binding die Annahme, dass die Signaturen der Methoden sich nie ändern werden. Wenn die Annahme stimmt, mag das praktisch sein, diese ist aber durch nichts garantiert.

Chemiker hat folgendes geschrieben :

... dass man Excel-Objekte, Methoden usw. nutzen kann, die in älteren Excel-Versionen noch nicht vorhanden sind, ...

Was du damit meinst habe ich nicht verstanden. Wenn eine Methode nicht vorhanden ist, kann man sie auch nicht nutzen.

Chemiker · Verfasst: Fr 19.06.09 14:30

Hallo delfiphan,

ist vielleicht etwas unglücklich ausgedrückt.

Aber nehmen wir den Fall an, Dir würde nur Excel 2000 zur Verfügung stehen, Du kennst Dich mit den Befehle von Excel 2007 aus, so ist es möglich z.B. über die Versionsnummer von Excel, Befehle zu steuern die nur in Excel 2007 vorkommen. z.B.: die Begrenzung der Spalten und Zeilen pro Sheet.

Da man in der Regel nicht weis, welche Excel-Version auf den Zielrechner vorhanden ist, kann man mit demselben Quelltext arbeiten, ohne für jede Excel-Version eine separate Unit zu schreiben.

Bis bald Chemiker

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme