Beiträge von Roalf

Diese Meldung dürfte dann auftreten, wenn du ein Dokument öffnest und die Maske die dieses Doc anzeigt eine "selbstgebastelte" ist. Sie sagt nämlich, das Notes in der Maske eine Grafik anzeigen will, die nicht dem "üblichen" Farbschema entspricht.
Sprich, du hast in der Maske "seltsame" Grafiken und müsstest die mal konvertieren. Versuche es statt GIF mit mit JPG.

ähh....vielleicht verstehe ich ja hier was völlich falsch. Aber den Servernamen in der Names.nsf zu ändern scheint mir ein recht obskures Unterfangen zu sein.

Wo kommt der neue Name her, wenn er nicht entsprechend "registriert" ist? Und wenn er über den Admin-Client registriert worden ist..steht er sowieso als Doc in der Names.nsf dort.

Einfach den Namen in der Names ändern, KANN nicht funktionieren! Da jeder Server eine Server.ID mit den entsprechenden Schlüsseln benötigt...und in diesers ID ist der Name integriert.

Also wenn ein Server einen neuen Namen haben soll: neuen Server registrieren...dann die Server-ID auf der Serverplatte austauschen...und alten Server löschen...nur so kanns gehen.

-----
Das den Moderatoren dieser simpele Umstand nicht bekannt ist, wundert mich doch etwas.

ein Blick in die Hilfe zeigt dir:
.
.

"@SetProfileField( profilename ; fieldname ; value ; uniqueKey )

value
Text. The value to which you want to set the field."
.
.

das du natürlich Text in Zahl..und nach der Incremetierung Zahl in Text umwandeln solltest....Im Profildokument solltest du ein TEXT-Feld haben.

zuerstmal Simpel...mit einem Profildok gehts. Aber bitte ein Userunabhängiges, sonst gehts inne Hose. Oder jedes andere beliebige normales Notesdokument welches du zentral über einen lookup suchst....
....wenn die Anwender sowieso nur Online auf einem einzigen Server arbeiten...aber dann solltest du dich fragen ob Notes nicht etwas deplaziert ist...und es eine relationale DB nicht besser tut.

DENN...

du bist dir Bewusst, dass du damit eine der wichtigsten Fähigkeiten von Notes verlierst? Nämlich die Möglichkeit der Replikation und das Offlinearbeiten mit lokalen Repliken. Denn z.b. wenn mehrere User lokal offline arbeiten, bekommen alle im ungünstigsten Fall die gleiche Nummer (was du sicher nicht willst). Da es in diesem Fall keinerlei Netzverbindungen zwischen den Usern gibt und somit keine Möglichkeit festzustellenn, ob die Nummer nicht vielleicht gerade schon von jemandem anders "gezogen" wurde.

Alternative: Um in jedem Fall eine eindeutige Nummer zu bekommen kannst du die dafür vorgesehen UNID benutzen....aber die ist nicht fortlaufend...aus gutem Grund.

Wenn es aber unbedingt eine fortlaufende Nummer sein soll und Notes nicht zu einer reinen Onlinedatenbank degeneriert werden soll....ist heftig viel Arbeit (z.B. mit einer Nummernkreisdatenbank...Temporärnummer...Hintergrundagentenabgleich e.t.c.) notwendig.

Problem gelöst...oder doch nicht?

Denke bei deiner Programmierung daran, dass Notes ein replikationsfähiges System ist. Die Nummer muss nach deiner Methode NICHT zwingend "fortlaufend" sein.

Das Problem beginnt nämlich immer dann, wenn von einer Datenbank mehrere Repliken über Server oder von lokale Usern existieren (Und dies ist bei Notes eher die Regel als die Ausnahme, weil es DAS feature von Notes ist).

Schon ist die ganze Idee hinfällig...weil das Profil auch an mehreren Stellen vorhanden....und damit das Chaos "programmiert" ist.

Wenn die fortlaufenden Nummer wichtig ist und du dir Kopfschmerzen wegen schwer aufzufindender Probs. ersparen möchtest, solltest du dir Gedanken über eine Nummernkreis-DB machen. Ist die fortlaufende Nummer nicht ganz so wichtig sondern eher die Eindeutigkeit der Nummer, solltest du die Notes-UNID benutzen.

das mit dem button..is so eine Sache. Du kannst ihn nicht auf simpelem Weg neu erzeugen.

Aber du kannst ihn zum beispiel aus einer verstecken quelle (z.b. profildokument) holen und ans Richtext anhängen. Das klappt aber nur solange wie in jeder mail der gleiche button mit gleicher funktion stehen soll.

Wenn du allerdings für jede mail eine angepasste @formel oder script im Button haben willst...wirds echt gemein. Dann ist eine Riesenarie mit den Notes-DXL-Exporter und DXL-Importerklassen notwenig.

Warum eine extra programmierte Ansicht?
Im Notes-menü "View/Show/Unread only" kann es der User für jede existierende Ansicht aktivieren/deaktivieren.
Und wenn der Menüpunkt für die User zu schwer zu finden ist...einfach einen Agent der diese Funktion aufruft: "@Command([ViewShowOnlyUnread]) ". Und...sogar ohne ins Design einzugreifen...mit einem entsprechenden Smaticon....kann der User hin und herschalten...bequem und simpel.

Ich befürchte, die Vorgabemaske ist nicht das was du wirklich willst.
Es scheint das du, als du die Maske designt hast, es versäumt hast dieser Maske einen Alias zu geben. Nun wird in jedes Dokument in das Feld "form" der Klartextname der Maske eingetragen. Nach der Umbenennaktion existiert diese Maske nun natürlich nicht mehr.

Deine beiden einzige Möglichkeiten diesen Design-Schwachpunkt nacträglich zu beheben:

1. diese Maske tatächlich zur vorgabemaske zu machen. Hat den nachteil, das du, wenn du neue Masken erstellt und dir ähnliche Design-Probleme einfängst dieses Problem potentierst. Diese Möglichkeit würde ein Handwerker als "Pfusch" bezeichen, weil du zwar die Auswirkung milderst, aber die Ursache bestehen bleibt, da du ab nun gleiche Dokumente mit unterschiedlichem Form-Feldern hast.

2. Die deutlich elegantere Möglichkeit ist jedoch, die schon existierenden Dokumente mit einem Agent zu bearbeiten der dort das Feld "form" auf den nun richtigen Namen setzt.

Tipp: zukünftig jedem Designelemt auch einen eindeutigen Alias verpassen...nur so kann dieses Element nachträglich ohne zusätzliche Arbeit umbenannt werden.

Hallo,

für dein Problem gibt es eine recht einfache Lösung: update das GEDYS Office (aktuell 5.6). Seid der Version 5.5 ist die MS-Office-Integration so deutlich verbessert worden, das sie anderen Lösungen in nichts mehr nachsteht.

Gruß
Roalf