Fortschrittsbalken verwenden

[Florian P.]

Hallo zusammen,

ich hoffe jemand kann mir sagen ob man diesen schönen Fortschrittsbalken den Notes, z.B. bei der Anlegung einer neuen Replika, verwendet auch in eigene Anwendungen aktiv einbauen kann. Ich habe zur Zeit das Problem das eine statistische Auswertung bei uns derzeit über ein paar tausend Dokumente rennt und dabei natürlich einige Zeit in Anspruch nimmt. Um den Endanwender nun auch zu zeigen das etwas passiert und der Thread seines Clients nicht im Nirvana gelandet ist würde ich gerne den Statusbalken einblenden. Die StatusBar als Kommunikationsmedium find ich zu unauffällig und Msgbox etc. halten den Prozess ja an der entsprechenden Stelle an und warten auf Nutzerinteraktion.

Ob das nun über LotusScript oder @Formulas wäre ist mir eigentlich egal. Nur Java komplexere Strukuten sollten es nach Möglichkeit nicht sein. Zur Not würd ich mir ein eigenes Form basteln und die Menubar darin emulieren, aber wäre ja schöner die internen Funktionen zu nutzen .

Viele Grüße,

Florian

[eknori]

http://www.notes411.com/dominosource/faq.nsf/0/40BB60FE6491291A80256D6E007AC182!OpenDocument

http://www.nsftools.com/tips/JavaTips.htm#javadialog

[LN4ever]

Hallo Florian,

jeder, der einmal den Fortschrittsbalken à la carte du Notes eingebaut hat, hat ihn spätestens dann wieder ausgebaut, wenn er im Designer zum siebten Mal auf einen Fehler lief und feststellen mußte, daß er einen hängenden Thread hat.

Ich helfe mir heute viel lieber mit simplen Punktreihen als Print (wobei Print ein Speicherfresser ist - nicht zu viele nehmen).

Gruß

Norbert
 

[Axel]

Ich benutze in fast allen Datenbanken den einbauten Progressbar von Notes. Die Klasse habe ich irgendwann mal aus dem Web gefischt. Ich habe sie mir in eine Script-Bibliothek gepackt.

Bibliothek mit Progressbar

Das Ganze läuft seit Jahren ohne irgendwelche Probleme.


Axel

[LN4ever]

Hallo Axel,

genau diesen Code meinte ich, als ich schrieb, daß der den Entwickler in den Wahnsinn treiben kann.

Schon das Beispielprogramm enthält keinen Errorhandler, der ein
Delete cProgress
erzwingt. Und wenn das fehlt, hast du einen hängenden Task. Und das passiert beim Testen im Debugger andauernd. "Boot tut gut".

Die Auslagerung in eine Script-Library gefällt mir aber gut - und ich überlege mir, ob ich mir dies - erweitert um einen "Test"-Parameter, nicht doch einmal in die Sammlung aufnehme. Dann kann man mit einem Schalter aus dem aufrufenden Programm entscheiden, ob man das heikle Konstrukt ansteuert oder die Test-Primitiv-Variante wählt. Denn Eines ist klar: Chic ist der, und in einer ausgetesteten Umgebung mit zentralisierter Error-Rotine, die nie vergißt, das Delete cProgress anzusteuern, würde ich ihn auch einsetzen. Aber halt auch erst dann.

Gruß

Norbert

[Thomas Schulte]

Ich helfe mir heute viel lieber mit simplen Punktreihen als Print (wobei Print ein Speicherfresser ist - nicht zu viele nehmen).

Print ist nicht nur ein Speicherfresser (lokal) sondern auch ein gewaltiger Performancefresser wenn es in Agents die auf den Server eingesetzt werden intensiv verwendet wird. Jeder Print auf die Konsole wird nämlich auch ins Log geschrieben.

[Axel]

Schon das Beispielprogramm enthält keinen Errorhandler, der ein
Delete cProgress
erzwingt.

Da hast du mit Sicherheit recht. Ich hatte mir immer wieder mal vorgenommen die ganze Sache zu optimieren und eben ein Fehlerbehandlung einzubauen. Bei dem guten Willen ist es leider bisher geblieben. Teilweise aus Zeitgründen und auch aus dem Grund, dass bei uns leider die Entwicklungsarbeit ganz massiv zurückgefahren wurde.

Axel

[LN4ever]

Thomas' Einwand mit der Warnung vor dem Fortschrittsbalken im Background-Agent ist ja eine süße Vorstellung. Damit der Server auch immer weiß, wie lange ich ihn wohl noch quälen werde, zeigt er mir unmißverständlich an, daß ich ihn quäle.

Aber wenn man die Idee genauer verfolgt, dann ist der Einwand gar nicht so unsinnig, denn man verwendet den gleichen Code manchmal im Userinterface (wo ein Fortschrittsbalken Sinn macht), aber auch in einem Hintergrundagenten (wo man den Sinn eines Fortschrittsbalkens - höflich formuliert: hinterfragen muß). Und dann kommt man zu einer Frage, die bis heute zu den "offenen Fragen" bei mir gehört: wie finde ich heraus, ob es im momentanen Kontext ein UserInterface gibt ? Funktioniert so etwas wie der folgende Code ? Muß man das in eine separate Lib packen ? Was sagt denn ein Agent dazu ?

Function HasUI As integer
Dim xUIws as Variant
On Error Goto NoUI
Set xuiws=New NotesUIWorkspace
HasUI=True

ENDE:
Exit Sub

NoUI:
HasUI=False
Resume ENDE
End Sub

Gruß

Norbert

[Glombi]

Das mache ich so:

To get: flag = notesSession.IsOnServer
Legal values
True indicates that the script is running on a server.
False indicates that the script is running on a workstation.


Damit lassen sich auch UI-Klassen in einem Agenten verwenden, der sowahl im UI als auch als Backend läugt (bspw. Web Agenten).
Bsp:
If Not session.IsOnServer then
Dim ws as NotesUIWorkspace
....

End If


Ist nicht sauber, ich weiß. Aber ich musste mal auf die Schnelle einen Agenten, der nur für das UI war, zum Web Agenten machen.

Andreas

[diali]

ein zeitgesteuerter Agent wird dann nicht mehr funktionieren, da UI-Klassen verwendet werde.

Eine Idee ist es den Agenten mit dem Servername zu unterzeichenen, auf dem der Agent laufen soll, dann kann der Username aus der Session mit dem Servername aus der DB verglichen werden. Sind diese identisch, wird der Agent auf dem Domino ausgeführt.

Zu Print.
Da kann die Performance gesteigert werden, indem man vorher ein IF-Abfrage macht und nur jede x. Print-Meldung ausgibt. Z.B.:

Code

If i mod 20 = 0 then
   Print i & " / " & dc.Count
End If

[LN4ever]

Andreas' Tip hilft schon viel weiter (solange man keine lokalen Backgroundagenten in die Planung einbeziehen muß). Zu Dirks Einwand muß man anmerken: LS ist und bleibt eine Interpretersprache, d.h. ein  Hintergrundagent fällt erst aufs Maul, wenn du eine UI-Klasse als solche deklarierst oder versuchst sie zu verwenden, wenn es nicht zulässig ist. Wenn man den zu benutzenden UIWORKSPACE als Variant deklariert (und im Background-Umfeld nicht verwendet), passiert nichts. Auch Andreas' Abfrage schafft das.

Zu Dirks Zusatz zum Print: dc.Count kann richtig lange dauern. Wenn man das Ergebnis davon mehrfach verwendet, gehört das IMMER in eine eigens definierte Variable. Die "20" als Schrittweite fürs Abhusten ist recht willkürlich.

Ich teste derzeit an einem Konstrukt mit folgendem Aufbau:
Zwei Script-Libraries LIBBACKEND und LIBUI.
In LIBBACKEND wird die Variable UI als globale Variable deklariert (und als False initialisiert).
In LIBUI steht in den OPTIONS
Use "LIBBACKEND"

und in Initialize
UI=TRUE

Mal sehen, ob das zu guten Ergebnissen führt.

Gruß

Norbert

[diali]

die 20 war willkürlich gewählt. Hier mache ich es immer von dem äbhängig von dem, was das Script tut.

Und ja der dc.Count gehört in eine Variable und zwar gleich nachdem die NotesDocumentCollection erzeugt / geändert wurde.