Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: Aladdin Sane am 16.11.04 - 21:07:37
-
Ich habe das Forum schon durchsucht - bin aber nicht fündig geworden:
Ich möchte gerne ein Excel-File als Objekt in einem RT-Feld führen. Die Kollegen sollen darin
Einträge machen. Per Script soll dan eine Routine das File auslesen und Felder von bestimmten
Dokumenten mit dem Inhalt gewisser Zellen versorgen.
Der Import von einer Datei, die "normal" irgendwo auf der Platte oder im Netz liegt ist kein
Problem.
Kennt jemand irgendwo ein Beispiel, wo das so gemacht wurde?
pASCAL
---
Das Thema steht auch irrtümlich in der Rubrik "Problem in R5".
Kann da ruhig gelöscht werden...
-
Kennt jemand irgendwo ein Beispiel, wo das so gemacht wurde?
Kenne ich nicht, aber ich denke Deine Anforderung ist auch sehr speziell.
Frage:
Nachdem ja ein Programmcode bestimmte Excelfelder auslesen soll, müssen diese ja fest definiert werden (z.B. immer Zelle E3, F11, G25).
Warum arbeitest Du nicht mit normalen Feldern? Die könntest Du einfach befüllen von einer Excel-Datei aus.
Ich mag solche Excelobjekte eigentlich immer nicht so recht aus diversen Gründen (Performance, was ist wenn auf einer Maschine kein Excel installiert ist, evtl. Kompatibilitätsprobleme zwischen einzelnen Excel-Versionen, etc. etc.).
-
Ich habe sowas mal gemacht (Code müsste ich heraussuchen. Äh, Code natürlich nicht, aber die Algorithmen). Aber ich bin auch von den OLE-Objekten abgekommen, da es die doch ab und "zersägt" - nicht gerade die stabilste Notes-Komponente. Wir sind dann auf Attachments, die auf Button-Befehl zur Bearbeitung, Speicherung und anschliessender Übernahme in die entsprechenden Felder des Notes-Docs umgestiegen.
@Matthias: Man muss keine absoluten Zelladressen verwenden, es gehen auch Bereichsnamen. Das erscheint mir sicherer (aber natürlich auch nicht "sicher").
Bernhard
-
@Matthias: Man muss keine absoluten Zelladressen verwenden, es gehen auch Bereichsnamen. Das erscheint mir sicherer (aber natürlich auch nicht "sicher").
Hast Recht, Bernhard ;)
Wie auch immer: Interessant wäre, ob es nicht reicht, eine Excel-Datei so (ohne OLE) auszulesen und Zellinhalte in Notes-Doc-Items zu schreiben. Wäre imho die 1. Wahl - wenn es die Situation zulässt.
-
Matthias, da es zwischen einem Excel-OLE-Object und einem Excel-Attachment keinen Unterschied hinsichtlich Inhalten oder Schutz vor Replizierkonflikten gibt, würde ich hiermit unseren gemeinsamen Vorschlag nochmals bekräftigen: Bitte ein Attachment verwenden.
Hirnschmalz muss sowieso in beide Verfahren stecken ...
Bernhard
-
Jo, Bernhard :)
Ein Nacht-Gruß ist unterwegs nach Oberbayern.... ;)
Matthias
-
Und ein ebensolcher ist unterwegs an die "Donau-Küste" !
Vergessen möchte ich hier aber nicht: "AladdinSane" und "Aladdin Sane" haben beide heute Geburtstag. Meine herzlichen Glückwünsche ! Und wenn wir jetzt für die beiden einen Vornamen hätten, um sie anreden zu können ... Das tut aber den Glückwünschen keinen Abbruch !
Bernhard
-
Nur so zur Ehrenrettung von Notes (was zwar bei Bernhard nicht wirklich nötig ist :) ): das Zersägen von OLE Objekten ist nicht ein Notes-Problem, sondern sind ganz generelle Probleme der Olé - Technik, deshalb sollte man der so oft wie nur möglich "olé" (im Sinne von Tschüss) sagen ......
-
@koehlerbv
Vielen Dank für die Glückwünsche.
Bürgerlich heiße ich Pascal - steht aber in jedem Eintrag auch drin.
Der zweite Login "AladdinSane" ist irgendwie redundant.
Aber ich sah keine Möglichkeit den zu löschen.
Ein Admin kann den sonst auch gerne eliminieren.
Zurück zum Thema:
Das mit der Unsicherheit bzgl. eingebetteten Excel-Objekten ist mir auch schon
aufgefallen.
Ich kann das aber leider nicht
gleich in Notes implementieren, weil die Mitarbeiter ihre Kalkulationen im ersten
Schritt auf jeden Fall in Excel machen möchten.
@TMC
Was meinst du mit "normale Felder"?
-
Hallo, Pascal,
sorry, dass ich das mit dem Namen nicht geschnallt habe.
Ich denke, Matthias "TMC" meint mit "normalen Feldern": Warum machst Du die Berechnung nicht gleich "native Notes" - also nix Excel-Sheet, sondern gleich entsprechende Felder in der Maske bereitstellen.
Nach meiner praktischen Erfahrung reicht das aber nicht immer - manchmal muss man dem User mehr Möglichkeiten zur Verfügung stellen. Das hierfür eine lokale Excel-Installation (oder was auch immer) zwingend erforderlich ist, kann man ja in solchen Fällen voraussetzen.
Ich bin hierbei folgenden Weg gegangen:
- Vorlage mit Excel-File als Setup-Dokument
- Beim Erstellen des Dokuments wird die leere Excel-Vorlage in das Dokument übernommen (nicht bearbeitbares RTF)
- Per Button wird das Excel-Sheet abgehangen, Excel gestartet (wenn es nicht schon läuft), gelöstes Excel-Sheet übergegeben
- Wird Excel beendet, wird das geänderte Sheet wieder angehangen.
Natürlich sind dabei etliche andere "Feinheiten" zu beachten ;)
Aber wie gesagt: Das ist nicht trivial. Wenn man es aber hinbekommen hat, hat man eine wirklich sehr stabile Lösung.
Bernhard
-
@TMC
Was meinst du mit "normale Felder"?
Genau so wie von Bernhard schon vermutet wie ich das meinte, also Felder direkt in der Maske. ;)
-
Felder direkt in der Maske füllten geht leider tatsächlich nicht.
Bernhard, gibt es bei Dir, nachdem das Excelsheet wieder angehängt wurde, die
Möglichkeit eine Importfunktion aufzurufen, die dann aus dem Excel-Sheet bestimmte
Werte aus Zellen ausliest?
pASCAL
-
Jo, genau das ist das Prozedere. Dabei werden - um Manipulationen des Sheets durch die User auszuschliessen, keine fixen Zellen, sondern (geprüfte) Bereichsnamen ausgelesen.
Bernhard
-
Bei mir verläuft der Import noch über die Angabe einer Datei auf der Platte:
Set Excel = CreateObject("Excel.Application.9")
Excel.Workbooks.Open filename
Wie kann ich dem Excel-Object denn als Quelle das Excel-File im RT-Feld übergeben?
-
Wenn wir jetzt vernünftigerweise OLE ausschliessen: Gar nicht. Du musst erst lösen (Filename sollte sinnigerweise die UNID des Dokuments sein, und nach er Aktion muss das File wieder gelöscht werden). Dein Verfahren passt also schon, Pascal.
Bernhard