Excel Automation

[Cogito]

Zitat:

Zitat von Lemmy (Beitrag 1141216)

Hi,

Zitat:

Zitat von Cogito (Beitrag 1141165)

mit der Fehlermeldung ..."Operator ist auf diesen Operandentyp nicht anwendbar!" Ausserdem steht im Tutorial ExcelWorkbook1 (siehe Fettdruck), was ja wohl auch falsch ist.
Kann mir jemand weiterhelfen oder hat einer noch einen anderen Vorschlag ?

warum falsch? Was soll dann da stehen? Das Tutorial habe ich mit MSOffice 2000 geschrieben - keinen PLan ob das aktuell auch mit der 2007er oder 2010er läuft - habe ich leider nicht. Wenn Du die Komponenten hast, dann sollte es ein leichtes sein, den Fehler zu finden - habe ich nichts gegen einen Hinweis, dann würde ich das Tutorial aktualisieren...

Grüße

Ich habe ja oben die fehlerhafte Zeile und die Fehlermeldung aufgelistet. Ich benutze Delphi 2010 und auf meinem Rechner ist Office 2010 installiert.

[p80286]

Zitat:

Zitat von Cogito (Beitrag 1141213)

Das ist aber eigentlich nicht so fein... falls die Excel Sheets beispielsweise in einem Verzeichnis mit ungenügenden Schreibrechten liegen, kracht's jedesmal. Gibt's denn keine Möglichkeit die Anzeige des Dialogs zu unterdrücken ? Ich lese aus den Sheets ja nur aus.

Sowohl Word als auch Excel haben eine sehr eigene Auffassung von "Änderungen" darum quitiere ich beide immer mit "nicht speichern" wenn es keine Datenänderung gibt.
Ich habe leider kein Excel zur Hand, aber es müßte einen Parameter "NoSave" oder so ähnlich geben. Schau doch mal in die VBA-Hilfe, da solltest Du eigentlich alles notwendige finden.

Gruß
K-H

Edith:
@Lemmy
Es sieht wirklich nach einem Tippfehler aus:

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
var sValue, filename: String;
begin
  filename:=ExtractFilePath(ParamStr(0))+'Mappe1.xls';
  ExcelWorkbook.ConnectTo(ExcelApplication.Workbooks.Open(filename,
    emptyParam, emptyParam, emptyParam, emptyParam, emptyParam, emptyParam,
    emptyParam, emptyParam, emptyParam, emptyParam, emptyParam,
    emptyParam, flcid));
  ExcelWorksheet.ConnectTo(ExcelWorkbook1.Sheets.Item[1] as
    ExcelWorkSheet);
  sValue:=ExcelWorksheet.Range['B1','B1'].Value;
  MessageDlg(sValue, mtInformation, [mbOK], 0);
end;

Edith2:
Hier kann man sich den richtigen Paramer raussuchen:
http://www.ozgrid.com/VBA/prevent-save-prompt.htm

[FrankJ28]

Hallo,
saveas in einem temporären Verzeichnis (User, sollte da ja Schreibrechte haben) und dann die Datei löschen.
Sobald das Sheet mehr als nur ein einfacher Datensammler ist (eingebettete Funktionen etc.), ist immer gleich eine Änderung vorhanden.
Ciao
Frank

[Cogito]

Zitat:

Zitat von p80286 (Beitrag 1141219)

Zitat:

Zitat von Cogito (Beitrag 1141213)

Das ist aber eigentlich nicht so fein... falls die Excel Sheets beispielsweise in einem Verzeichnis mit ungenügenden Schreibrechten liegen, kracht's jedesmal. Gibt's denn keine Möglichkeit die Anzeige des Dialogs zu unterdrücken ? Ich lese aus den Sheets ja nur aus.

Sowohl Word als auch Excel haben eine sehr eigene Auffassung von "Änderungen" darum quitiere ich beide immer mit "nicht speichern" wenn es keine Datenänderung gibt.
Ich habe leider kein Excel zur Hand, aber es müßte einen Parameter "NoSave" oder so ähnlich geben. Schau doch mal in die VBA-Hilfe, da solltest Du eigentlich alles notwendige finden.

Ja stimmt, man braucht lediglich Close(0) aufzurufen und die Zwischenfrage entfällt.
Vielen Dank !

[ASM]

Zitat:

Zitat von p80286 (Beitrag 1141219)

Ich habe leider kein Excel zur Hand, aber es müßte einen Parameter "NoSave" oder so ähnlich geben.

Korrekt heißen die dafür benötigten, als OleVariant-Parameter zu übergebenden Konstanten:

Code:

Const 
  wdDoNotSaveChanges = 0;
  wdSaveChanges = -1;
  wdPromptToSaveChanges = -2;

Sehr gut geht es aber auch so (MSExel ist die als 'Excel.Application' eröffnete OleVariant):

Code:

procedure CloseExcel(SaveChanges: Boolean=true);
begin
  if VarIsEmpty(MSExcel) = false then
  begin
    // speichert, wenn SaveChanges = TRUE; 
    // speichert nicht (ohne Rückfrage), wenn SaveChanges = FALSE
    MSExcel.DisplayAlerts:= SaveChanges;
    MSExcel.quit;
    MSExcel:= Unassigned;
  end;

[Chemiker]

Hallo,

Delphi-Quellcode:

if VarIsEmpty(MSExcel) = false then

nicht auf TRUE oder FALSE prüfen, dass kann zu Probleme führen.
besser:

Delphi-Quellcode:

if not (VarIsEmpty(MSExcel) then

DisplayAlerts wird auf TRUE oder FALSE gestellt, mit SaveChanges hat das nichts zu tun.

Excel schließen ohne nachfragen:

Delphi-Quellcode:

excel.ActiveWorkBook.Saved:= TRUE; 
excel.Workbooks.Close;
excel.Quit;
excel:= Unassigned;

Bis bald Chemiker

[Bernhard Geyer]

Zitat:

Zitat von Chemiker (Beitrag 1141345)

Hallo,

Delphi-Quellcode:

if VarIsEmpty(MSExcel) = false then

nicht auf TRUE oder FALSE prüfen, dass kann zu Probleme führen.

Kannst du ein beispiel liefern wie man dieses Problem in Delphi herstellen kann.
In C/C++ ist klar. Da wird ja in jeder Bibliothek mindestens 10* TRUE und FALSE neu wenn du pech hast mit FALSE=0; TRUE=1 neu definiert.

Zitat:

Zitat von Chemiker (Beitrag 1141345)

Excel schließen ohne nachfragen:

Delphi-Quellcode:

excel.ActiveWorkBook.Saved:= TRUE; 
excel.Workbooks.Close;
excel.Quit;
excel:= Unassigned;

Bis bald Chemiker

wenn man mit Variants arbeitet kann man ein Exceldatei mittels

Delphi-Quellcode:

FWorkBook.Close(SaveChanges:=False);

schließen und die Rückfrage vermeiden.

[p80286]

Hallo Bernhard,

mach doch mal

Delphi-Quellcode:

if boolean(4) then showmessage('4 ist true');
if boolean(4)=true then showmessage(inttostr(integer(true)) ist gleich 4');

Gruß
K-H

[Chemiker]

Hallo,

Zitat:

Kannst du ein beispiel liefern wie man dieses Problem in Delphi herstellen kann.
In C/C++ ist klar. Da wird ja in jeder Bibliothek mindestens 10* TRUE und FALSE neu wenn du pech hast mit FALSE=0; TRUE=1 neu definiert.

http://www.delphi-treff.de/tutorials...faengerfehler/

Bis bald Chemiker

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1141455)

Hallo Bernhard,

mach doch mal

Delphi-Quellcode:

if boolean(4) then showmessage('4 ist true');
if boolean(4)=true then showmessage(inttostr(integer(true)) ist gleich 4');

Gruß
K-H

Autsch. An diese harten Casts auf ungültige Enumwerte hatte ich gar nicht mehr gedacht.
Aber wer macht auch solche fehleranfälligen Konstrukte. :-)