P.S.: ich musste den destructor deaktivieren. hat leider nicht so funktioniert wie ich dachte (Version um 16:45 geändert)
Kannst Du das präzisieren?
Ich habe bei mir mal in einem Code nachgesehen:
Sub Delete
If Not Isempty(xlApp) Then
xlApp.DisplayAlerts = False
xlApp.Quit
Set xlApp = Nothing
End If
End Sub
Was es mit dem DisplayAlerts auf False auf sich hat, hab ich damals leider nicht kommentiert >:( ::)
Vermutlich hatte Excel einen Fehler geworfen unter manchen Umständen.....
Für Erweiterungsideen und andere Kommentare/verbesserungen wäre ich sehr dankbar :)
Gerne ;)
Grundsätzlich wären denke ich folgende Quellen hilfreich:
- Alle Dokumente einer View
- Ausgewählte Dokumente einer View (also db.UnprocessedDocuments)
- @Formel Suchstring (db.Search)
Notes-Daten auslesen dann optional
a) entweder aus den Dokumenten der DocCollection selbst (also die Items die als Property per String-Array mitgegeben werden)
b) Anhand Export-View (also Spalten / Zellenwerte wie in der View angegeben)
Grund: View lässt sich oft schneller zusammenklicken, und man kann da einfach Spaltenformeln angeben.
zu (a): Hier noch eine Möglichkeit, alternative Spaltentitel mitzugeben, und nicht die Itemnamen verwenden.
Außerdem: Möglichkeit, Inhalte nach Bedingung anzuzeigen. Angenommen man hat einen Radiobutoon, dort ist hinterlegt "Ja|0, Nein|1". Beim Auslesen bekommt man dann nur 0 oder 1. Im Excel-Export sollte aber "Ja" oder "Nein" erscheinen. Quasi wie in einer View-Spaltenformel, wo man schreiben würde @If(_Feld = "0"; "Ja"; "nein").
Wie man das vernünftig umsetzen könnte, muss ich mir noch Gedanken machen....
Was es mit dem DisplayAlerts auf False auf sich hat, hab ich damals leider nicht kommentiert >:( ::)
Vermutlich hatte Excel einen Fehler geworfen unter manchen Umständen.....
Damit schaltet man Warnmeldungen ab. In deinem Fall wolltest du mit Sicherheit verhindern, dass beim Beenden von Excel Meldungen angezeigt werden, wie z.B. das diese Arbeitsmappe noch nicht gespeichert wurde.
BTW:
In einem Destruktor Excel zu beenden, halte ich nicht für so geschickt. In bestimmten Fällen kann das durchaus Sinn machen. Allerdings schreibt man ja Klassen um sie relativ einfach wiederverwenden zu können. Oftmals ist es aber so, dass Excel nach der Übergabe der Daten offen bleiben soll, damit das Sheet weiterbearbeitet werden kann. Rufst du dann den Destruktor der Klasse auf, wird Excel in deinem Fall beendet.
Ich hab's mir angewöhnt eine zusätzliche Methode EndExcel (oder so ähnlich) einzubauen, mit der ich bei Bedarf Excel beenden kann. Im Destruktor steht dann nur noch so was wie Set xlApp = Nothing.
Axel
Jo, stimmt, hast Recht.
Im Prinzip muss man oft nur im Fehlerfall abbrechen und Excel beenden. Sonst hängen noch Excel-Tasks im Taskmanager, wenn ein User während dem Export z.B. Strg+Untbr drückt.
Aber wenn Excel nach dem Export geöffnet bleiben soll recht ja wohl ein:
ExcelApp.Range("A1").Select
ExcelApp.Application.ScreenUpdating = True 'hat man natürlich vorher abgeschaltet
ExcelApp.Visible = True 'hat man natürlich vorher abgeschaltet
ExcelApp.StatusBar = "Excelexport erfolgreich bla bla"
Set ExcelApp = Nothing