Beiträge von oklink

    Hallo RockWilder!


    Zitat


    RockWilder schrieb:
    Diese Heinis würde ich achtkantig rausschmeißen. ... Du solltest dich da erkundigen, ob das tatsächlich so ist, wie die behaupten und das dann deinem Chef mitteilen.


    Tja. Da habe ich leider nicht viel mitzureden. Das ist die Verbands-Revision. Die kann man nicht einfach rauswerfen.
    Aber wir haben dieses Jahr noch eine Sonderprüfung von einer anderen Firma. Da werde ich das mal zur Sprache bringen.


    Zitat


    RockWilder schrieb:
    Meinst du nicht, es wäre sinniger wenn du von der DB Archive anlegst? In den Archiven spielt es dann keine Rolle, wie der aktuelle Stand aussieht. Diese Dokumente und Design unterliegen dann einem Freeze, da kommt niemand mehr dran. Wie häufig werden denn bei euch die Design verändert? Vermutlich nicht wöchentlich?


    Das Archivieren scheidet als Möglichkeit IMHO aus, weil dann ja die laufenden Workflows nicht zu Ende bearbeitet werden können. Außer die User rufen die dann womöglich direkt aus dem Archiv auf, aber das trägt nicht unbedingt zur Übersichtlichkeit bei den Usern bei.
    Und was das Ändern der Masken angeht: Es sind eben eine ganze Menge Masken, so dass zumindest bisher mindestens einmal im Monat Änderungen zu machen waren.


    Naja, ich sehe schon, mit meiner Konstruktion bin ich alleine auf weiter Flur. Da muss ich mir doch mal Gedanken über eine andere Architektur machen.


    CU,


    Oli

    Hallo Dirk!


    Zitat


    Diali schrieb:
    Schreib die Version doch in den Namen der Maske und arbeite mit einem Alias ohne Version.


    Die aktuelle zu verwendende Maske bekommt dan den Alias ohen Versionsnummer und alle anderen Masken haben keinen Alias.
    Nach die Masken aus dem Erstellen Menü verschwinden lassen und dem Anwender einen Aktion mit einem Compas auf den Alias schreiben, den Alias einmalig in alle betroffenen Dokumente schreiben (Agent) fertig.


    Vielen Dank für Deine Antwort, aber ich glaube ich habe das Prinzip noch nicht ganz verstanden. :-?


    Wenn die aktuelle Maske den Alias ohne Versionsnummer hat, dann wird dieser Alias doch bei jedem damit erstellten Dokument als Form eingetragen.


    Ergo hätte ich zwar für die Erstellung der Dokumente verschiedene Versionen der Maske verwendet, beim Öffnen zieht aber der Alias und das Dokument wird mit der aktuellen Maske geöffnet. Um das zu verhindern müsste ich dann nach dem speichern das Form-Feld mit dem eigentlichen Masken-Namen überschreiben.


    Meinst Du das so oder habe ich da was falsch verstanden?


    CU,


    Oli

    Hallo RockWilder!


    Zitat


    RockWilder schrieb:
    Nur ich verstehe beim besten Willen nicht, warum alte Dokumente mit alten Masken geöffnet werden sollen.


    Warum ändere ich eine Maske? Ich ändere eine Maske, weil Informationen hinzukommen, oder wegfallen, oder weil ich die Darstellung ändere. Ok, alles Tagesgeschäft soweit. Nur: warum wohl würde ich ein ein Jahr altes Dokument mit den damals als wichtig, aber heute entweder nicht mehr ausreichenden oder gar obsoleten Informationen sehen wollen? Wie das Design, die Darstellung vor einem Jahr aussah, ist nicht kriegsentscheidend, kann aber bei unbedarften Anwendern Verwirrung auslösen: heute steht Feld X links oben, vor einem Jahr aber war es rechts unten und dann geht das Gesuche los, wenn in alten Datenbeständen nach etwas gesucht wird...


    Natürlich ist all das, was du da versuchst machbar. Aber ich finde das doch ziemlich strange. Um nicht zu sagen: Frickelkram, dessen Aufwand durch keinerlei Nutzen gedeckt wird. Ergo: bestenfalls als ABM zu bezeichnen...


    Das Öffnen von alten Dokumenten mit alten Masken hat zwei Gründe:


    1. Revisionssichere Archivierung
    Auch wenn ich die Dokumente in 3 Jahren aufmache, dann müssen die noch so aussehen wie zu dem Zeitpunkt, zu dem sie erstellt wurden. Und die Version der Maske muss jeweils angezeigt werden. So will es die externe Revision.


    2. Laufende Workflows
    Es handelt sich hier um eine Workflow-Anwendung. Wenn ich jetzt in einer Maske ein zusätzliches Pflichtfeld definiere fehlt das möglicherweise bei bereits gestarteten Workflows oder ist nicht / nicht korrekt ausgefüllt. Können diese alten Dokumente mit den alten Masken weiter bearbeitet werden läuft alles problemlos. Mit der neuen Maske würde dagegen das nicht ausgefüllte Pflichtfeld reklamiert werden. Die aktuelle Station im Workflow hat aber unter umständen gar nicht das Recht, das reklamierte Feld zu bearbeiten. Wobei ich das Problem in den Griff kriegen könnte, indem ich die Pflichtfelder in Abhängigkeit der Station prüfe.


    CU,


    Oli

    Hallo RockWilder!


    Zitat


    RockWilder schrieb:
    Verstehe ich nicht, warum die Maske unbekannt sein sollte? Entweder, ich gehe mit @Compose dran, da muss ich zwangsläufig eine Maske angeben. Oder ich baue mir ein Dokument in LS zusammen und auch da gebe ich die Form an. Oder missverstehe ich gerade etwas gewaltig?


    Die Aktion, die ein neues Dokument z.B. mit Compose erstellt muss natürlich wissen, welche Maske verwendet werden soll.


    Mir geht es darum, dass dies auch das neu erstellte Dokument bzw. die von dem neuen Dokument aufgerufenen Scripte aus der Script-Bibliothek wissen sollen.


    Klar kann ich auch den Maskennamen fest reincodieren, wenn ich den irgendwo brauche. Aber dann muss ich das halt auch bei jeder Namensänderung manuell nachziehen. Und sowas ist halt eine typische Fehlerquelle.


    CU,


    Oli

    Hallo Bernhard


    Zitat


    koehlerbv schrieb:
    Irgendwie erscheint mir das aber nicht ganz stimmig. Wenn Du andauernd den Formname änderst, bekommst Du doch sowie eine Menge Folgeeffekte (Ansichtsselektionsformeln zum Beispiel), und auch die von Dir angesprochene ScriptLibrary muss dann ja dauernd manuell nachgezogen werden.


    Warum ändert Ihr überhaupt Formnames? Das ist ja nicht gerade best practice ...


    Folgeeffekte gibt es auf jeden Fall. Die versuche ich ja gerade zu minimieren. :P


    Die Masken haben dann Aliase in der Form "Name_V123".
    Bei der Selektion kann ich dann nur den Namensteil berücksichtigen und lasse die Versionsnummer außen vor.


    Bei uns werden eben die Masken leider ziemlich häufig geändert (Vorgabe von oben) und wenn da nun z.B. einfach ein zusätzliches Pflichtfeld eingefügt wird, das bei den bestehenden Dokumenten fehlt oder nicht ausgefüllt ist, dann kommt es im weiteren Verlauf des Workflows zu Problemen. Deswegen arbeite ich eben mit Versionen der Masken. So können bestehende Dokumente die Maske weiterverwenden, mit der sie erstellt wurden und neue Dokumente werden mit der neuen Maske erstellt.


    Falls es einen besseren Weg gibt, außer die Maske im Dokument zu speichern, dann immer her damit.


    Viele Grüße,


    Oli

    Hallo taurec!


    Zitat

    Mach in eine Maske ein berechnetes Feld Form und schreib dort den Alias Namen der Maske rein. Dann hast du sogar direkt nach dem Anlegen Zugriff darauf


    Natürlich kann ich den Namen manuell irgendwo reinschreiben. Das bedeutet aber, dass ich den auch immer manuell ändern muss, wenn sich der Name der Maske ändert. Da wir mit Versionsnummern arbeiten und die Maske bei allen relevanten Änderungen eine neue Versionsnummer erhält ist da schnell mal eine Änderung vergessen. Das ist ja gerade der Sinn, warum ich das irgendwo automatisiert auslesen wollte.


    Trotzdem Danke erstmal für die Antwort.


    Oli

    Hallo!


    Ich hatte schon öfters das Problem, dass ich in einem neu erstellten Dokument wissen wollte, mit welcher Maske das Dokument erstellt wurde. Dies ist z.B. wichtig, wenn ich im QuerySave ein Script aus der ScriptBibliothek aufrufen will und dort je nach Maske unterschiedlich verzweige.


    Ist das Dokument mal gespeichert kann ich ja leicht über das Form-Feld auf den Maskennamen zugreifen, aber vor dem Speichern ist das Feld anscheinend noch nicht gesetzt.


    Kennt jemand eine andere Methode, um den Namen der verwendeten Maske auszulesen?


    CU,


    Oli

    So, hier kommt mal eine funktionierende Version eines Scripts.


    In dem Konfigurations-Dokument ist der Administrations-Server hinterlegt. Hintergrund ist, dass man Termine nicht nur für sich selbst eintragen kann, sondern auch für andere User - und deren Mail-File wird dann über den Registrierungs-Server abgefragt.



    Das Dokument wird nach dem Speichern noch dem Ordner ($Alarms) hinzugefügt und dies ebenfalls gespeichert. Soweit ich bisher herausgefunden habe ist dies nötig, damit der Alarm auch tatsächlich funktioniert.


    Wenn es hierfür eine elegantere Lösung gibt oder wenn ihr sonst noch Verbesserungsvorschläge habt, dann immer her damit!



    Viele Grüße,


    Oli

    Hallo!


    Zitat


    bofh schrieb:
    ad [1]: Um dem Protokoll genüge zu tun :rtfm: und weil ich darauf angesprochen wurde:
    Das war weder böse noch überheblich oder als persönlicher Angriff gemeint.


    Kein Angst das hatte ich auch nicht so verstanden.


    Zitat

    IMHO ist das verlinkte Dokument eine der besten Dokus zum Thema C&S und man sollte es daher, wenn man sich mit diesem Bereich beschäftigt, gelesen haben.


    Die Doku ist tatsächlich sehr gut. Schade, dass die Suche auf der IBM-WebSite das Dokument nicht findet. Da hätte ich mir einige Arbeit erspart.


    Zitat

    Und noch ein PS: Oliver, kannst Du mal den relevanten Code pfosten, in dem Du die Felder befüllst?


    Den Code habe ich bisher bewusst nicht gepostet, weil ich die Diskussion um die notwendigen Felder nicht beeinflussen wollte. ;)


    Ich werde jetzt den Code mal überarbeiten und dann posten.



    CU,


    Oli

    Hallo Dirk,


    Zitat

    Lass mal die Zeile mit ComputeWithForm weg und ertselle ein Kalenderdokument. Danach erstellst Du ein Kalenderdokument per Hand und vergleichst die Felder (Typen und Inhalte) über die Eigenschaftsbox.


    wir Du oben lesen kannst habe ich das bereits gemacht. Zusätzlich habe ich die Felder auch mit dem Tool "Document Viewer" von MayFlower Software verglichen, was noch etwas ausführlicher ist.


    Leider konnte ich keinen Fehler finden.



    Viele Grüße,


    Oli

    Hallo!


    Ich habe verschiedene Anwendungen entwickelt, die in den Kalender eines bestimmten Users per LotusScript einen Termin bzw. eine Veranstaltung eintragen sollen.


    Die Kalender-Dokumente werden komplett im Backend erzeugt und direkt in die Datenbank des entsprechenden Users gespeichert.


    Unter Notes R5 hat das auch problemlos funktioniert.
    Seit der Umstellung auf R6.5 bekomme ich allerdings immer eine Fehlermeldung, wenn ich vor dem Speichern ComputeWithForm aufrufe. (Als Form habe ich natürlich "Appointment" im neuen Dokument eingetragen.)


    Die Fehlermeldung lautet: "Falscher Datentyp für Operator oder @Funktion: Zahl erwartet."


    Wenn ich das trotzdem gespeicherte Dokument dann aber ganz normal im Kalender öffne sieht alles ok aus und es gibt auch keine Fehlermeldung. Auch nicht, wenn ich das Dokument mit F9 neu rechnen lasse, was hier im Forum schonmal empfohlen wurde, oder das Dokument nach einer Änderung neu speichere oder wenn ich über Ansicht / Maske wechseln nochmal explizit die Maske Kalendereintrag auswähle.


    Ich habe auch schon alle von mir gesetzten Felder mit den Feldern eines normal erzeugten Kalendereintrages verglichen. Soweit ich sehen kann stimmt alles. Es könnte höchstens sein, dass ein Feld fehlt. Das bringt mich dann zum nächsten Problem.


    Ich bin jetzt seit anderthalb Wochen auf der Suche nach einer brauchbaren Doku, wie ein Kalendereintrag korrekt zu erstellen ist. Aber leider stehen in jeder Doku bzw. in jedem Bericht teilweise unterschiedliche Felder und unterschiedliche Werte, die diese Felder haben sollen. (In dem WM-Script hier im Forum wird z.B. das Feld "Duration" gesetzt. Das taucht aber bei mir weder auf, wenn ich einen Eintrag manuell erstelle noch steht das in den Dokus, die ich habe.)
    :-?


    Wer weiß Rat?



    Vielen Dank im voraus,


    Oli