hi,
das alte problem.
habe mich schon oft drüber geärgert.
private ansichten sind m.e. die einzige lösung, wenn du nur ansichten verwenden möchtest.
ansonsten könnte es sinnvoll sein, aber nur wenn deine daten sich nicht so schnell ändern, für jede 'kategorie' ein summen-dokument (!)periodisch erstellen zu lassen.
gruß, freddy
moin moin,
wie heisst es so schön : 'kaum macht man's richtig - schon funktioniert's '.
in den ziel-dokumenten (nur termine) muss man das feld 'apptunid' ebenfalls auf die neue universal-id anpassen.
scheint irgendein code im postopen zu geben, der hier noch eine verbindung herstellt.
besten dank und viele grüße,
freddy
Hi,
ich kopiere unter nd 6.53 termine und mails von mail-file a nach mail-file b.
- lotus script - copytodatabase
- ich passe on the fly jeweils chair und principal auf den neuen owner an
folgendes passiert:
ich kann in der ziel-db den termin/die mail einmal öffnen. beim zweiten öffnen kommt 'Dokument wurde geöscht'. Eigenschaften kann ich ebenfalls nicht abrufen.
aktualisiere ich jetzt die ansicht per f9 ist alles ok - sprich ich kann das dokument öffnen bis der arzt kommt.
mir gehen jetzt nach bislang erfolgloser suche in knowledge base und foren die ideen aus ( btw: soft deletion flag in ziel db hat keine auswirkung )
danke für neue ideen, freddy
ok -
wenn du über methoden der domino/notes-entwicklung schreiben möchtest, vielleicht die bei euch / durch dich praktizierte methode anhand einer notes-datenbank, die die verschiedenen phasen der entwicklung begleitet, illustrieren.
ich kenn da 'ne kollegin, die hat dieses thema in ihrer arbeit behandelt. wir arbeiten jetzt mit der ergebnis-datenbank und stellen unseren entwicklungsprozess dar.
funzt gut.
besten gruß, freddyk
hallo umit,
diplomarbeit a) uni b) fh oder wak ? reine theorie oder mit anwendungsbeispiel ( ich weiss: leichtes vorurteil 
)
anmerkung: wenn es dein prof gestattet, würde ich aus erfahrung empfehlen, nicht zu sehr zu verallgemeinern sondern deine aufzählung der inhalte mit genau einer konkreten lösung / teillösung zu verbinden.
besten gruß, freddy
5 habe ich irgendwie verpasst - war beim kunden nie thema
hi taurec,
gibt' s da noch die magische 9er grenze ?
mam musste ja unter 4 mit einem timer-objekt dafür sorgen, dass notes zeit genug hatte, das uidoc.close auszuführen, damit nie mehr als 9 fenster offen waren.
ich meine, unter 6 ist es aufgehoben, aber wie sieht der workplace aus, wenn du 500 dokumente druckst ?
gruss, freddy
hi,
in einer älteren n4-datenbank löse ich das problem per folgender formel:
@Command([FilePrint] ; "" ; "" ; "" ; "" ; "" ; "" ; "pagebreak" ; "" ; ""; "")
das druckt alle markierten docs nacheinander aus.
ich weiss nicht, obs in 6 schon was komfortableres gibt.
per script wird es glaube ich immer noch schwierig, aus dem backend vernünftig zu drucken.
gruss, freddy
moin,
as far as i know gibt's diese möglichkeit bei navigatoren leider nicht.
du wirst, wenn dieses feature kritisch ist, auf ein frameset umstellen müssen. dort kannst du den rahmen dann fixiert einstellen.
beste grüße, freddy
moin,
nein, der agent belastet einen gut dimensionierten server nicht wirklich. wir haben hier einige ähnliche routinen am start.
hängt natürlich von der anzahl der zu erstellenden termine ab.
ja, ein kleines flag im dokument abspeichern hilft, um den agenten nicht mehrmals über ein dokument laufen zu lassen.
bei einer period. routine seien übrigens die fälle ' termin wieder löschen' und 'termin ändern' bedacht, die den aufwand für die programmierung deutlich erhöhen.
also - viel erfolg
freddy
moin,
ja, mit script kann man den termin auch in fremden kalendern erstellen.
natürlich benötigt der supporter dann den entsprechenden zugriff a) auf den ziel - mailserver und b) auf das ziel-mailfile.
ansonsten könntest du doch auf einen period. agenten ausweichen, der die termine regelmäßig sammelt und im schwung erstellt. dort müsste dann 'nur' der signer den zugriff auf alle mailfiles haben. ( admin-id, signer-id oder im namen des servers)
besten gruss, freddy
hi,
stimmt, das mit dem doppelklick.
frage mich jetzt natürlich, warum die zielrahmen-definition im emb. view bei 'doppelklick' nicht funktioniert.
habe gerade mal kurz die workspace-variante getestet - hier wird sich das problem ergeben, dass du ein handle zum markierten dokument im emb. view benötigst.
das soll irgendwie mit caretID funktionieren - teste ich mal irgendwann.
viel erfolg, freddy
hi,
danke für deine erläuterung.
wie wäre es denn mit einem embedded editor in deiner form, die die embedded views enthält ?
je nach markiertem dokument gibt's ja dort dann die möglichkeit, direkt, auch datenbank übergreifend, zu editieren.
ich weiss nicht, wie gut du ihn dann formatieren kannst, aber bei mir sträubt sich igendwas gegen die dialogbox-lösung.
gruss, freddy
hi,
interessante frage - kannst du vielleicht erklären, was für einen vorteil ggü. einem 'normalen' öffnen du erreichen möchtest ?
gruss, freddy
die maske sollte 'Appointment' heissen und der weg scheint mir der richtige.
gruss, freddy
hallo,
ja natürlich, ich vergaß - der befehl ist nicht direkt.
vor dem compose den @command([MailOpen]) ausführen - der öffnet dann die mail-db des aktuellen anwenders.
voraussetzung: korrekte einstellungen in der arbeitsumgebung.
gruss, freddy
hi,
wenn der anwender sowieso einen haken setzen soll, warum dann nicht eine kleine schaltfläche zum drücken bauen.
dahinter einen kleinen script-agenten der per openmail die mail-db des anwenders mit einem kalendereintrag bestückt.
ich verfahre immer 'lege alle felder im backend an und hole den kalendereintrag zum schluß in den vordergrund'.
achte hier auf die erforderlichen $felder, abhängig von der eingesetzten version, sonst gibt's nebeneffekte wie 'wird nicht in der kalenderansicht angezeigt' oder 'erscheint im entwurfsordner.'
es funktioniert übrigens auch mit formeln, - einfach felder entsprechend den einträgen im helpdesk vorbelegen. der anwender muss dann zwar noch speichern, aber das ist ja schnell erledigt.
die befehle findest du in der designer-help
gruss, freddy
hi,
gebe dnotes grundsätzlich recht.
wir haben aber auch 'gesündigt', daher meine empfehlung: 'die erweiterungen konsequent in teilmasken entwickeln'.
die kann man relativ bequem in die neue schablone übernehmen.
gruss, freddy
jaja, speichern ist (fast) immer gut
gruss, freddy
und hi again,
der erste ansatz ist richtig. ( keine zuweisung mit (0), nur auslesen ).
mal vorsichtig gefragt - speicherst du das doc nach der zuweisung ?
gruss, freddy
