Beiträge von water

Perfekt, so machen wir das

Das klingt doch schon sehr gut!

Peter S. Taler hat mich noch auf einen Punkt gebracht.

Zu Punkt 1
Der "normale" Benutzer hat auf das Verzeichnis mit den Meldungen nur Lesezugriff ("Dieses Verzeichnis hat der Client im Lesezugriff.")

Um jedoch Meldungen erstellen zu dürfen, muss er Schreibrechte besitzen. Die Frage ist nun, wieviele Benutzer Meldungen erstellen müssen (Management etc.) und ob Du die Rechte problemlos über eine AD-Gruppe bei den zuständigen Admins anfordern kannst.

Weiteres "Problem":
Derzeit zeigt das Programm jedem alle noch nicht gelesenen Meldungen an, als auch dem Ersteller z.B. dem Management. Das könnte das Management verwirren.

Das GUI zur Erstellung einer Nachricht

• setzt daher beim erstellenden User die Nachricht sofort auf gelesen, somit wird sie bei ihm nicht angezeigt
• dokumentiert in der ersten Zeile der Nachricht den Ersteller inkl. Datum/Uhrzeit (falls es Bedenken hinsichtlich DSGVO geben soll, entfällt der Punkt)

Das Design wird langsam etwas komplex. Wenn Du nach der Abstimmung mit Deinen Admins das OK gibst, dann machen wir daher eine Konversation auf und dokumentieren das Projekt sauber.

Zitat von Peter S. Taler

Ob die Geschäftsleitung sich den Speicherpfad, den Speicherort usw merken kann - halte ich für fraglich.

Muss ja nicht sein.

Bei meinem letzten Post handelt es sich nur um eine grobe Skizze meiner Ideen.

Ein kleines GUI für das Management ist schnell geschnitzt.

Wenn es problemlos läuft kannst Du davon ausgehen, dass die IT und andere Abteilungen sehr schnell den Bedarf erkennt.

bazii

Hier mal ein grobe Skizze meiner Idee. Was hältst Du davon?

Generell:

• Alle Dateien beginnen mit DM_ (das steht für Domain Messenger). Sollten Dir die engl. Abkürzungen und Namen nicht gefallen, kann ich das noch ändern.
• Es gibt zwei Typen von Konfigurationsdateien: DM_Config_Global.ini (für alle Benutzer gültige Einstellungen) und DM_Config_Local.ini (für einen einzelnen Benutzer gültige Einstellungen)

Serverseitig:

• Verzeichnis: Das Logon-Skript weist dem Benutzer bestimmte Server-Laufwerke zu (das ist unabhängig vom DM). Auf einem dieser Laufwerke wird ein Verzeichnis angelegt in dem alle Dateien für DM abgelegt werden. Dieses Verzeichnis hat der Client im Lesezugriff.
  Hier werden alle Dateien abgelegt: exe, ini, txt.
  
• DM_Startup.exe: Das Logon-Skript kopiert/überschreibt die Datei DM_Startup.exe in ein lokales Verzeichnis jedes PCs der sich an der Domäne anmeldet. Dann wird vom Logon-Skript die lokale DM_Startup.exe gestartet.
  Damit gibt es auf dem Server nach dem Client-Login keine langlaufenden Programme.
• DM_Config_Global.ini: Hier werden globale Einstellungen gespeichert. Z.B.
  • Lokales Verzeichnis in das DM installiert werden soll
  • Zeiten für die Prüfung nach Meldungen mit Priorität normal und high
  • Filter um PCs von DM auszuschließen oder zu inkludieren
  • etc.

Clientseitig:

• DM_Startup.exe: Das vom Login-Skript gestartete Programm kopiert weitere notwendige Daten vom Server auf den Client und startet dann DM_Client.exe. Sollte DM_Startup bereits laufen, so wird DM_Client.exe erst gecancelt und dann gestartet.
• DM_Client.exe: Dieses Programm führt die Verarbeitung der Meldungen durch
• DM_Config_Local.ini: Damit kann die lokale Installation konfiguriert werden. Z.B.
  • Einstellungen für das Logging wenn bei einem einzelnen PC Probleme auftreten
  • etc.

Meldungen:

• Bei den Meldungen handelt es sich um normale Textdateien. Sie werden mit dem Befehl MsgBox angezeigt. Formatierungen bei der Anzeige (fett, Farben etc.) sind derzeit nicht vorgesehen.
• Prioritäten: Damit die Verarbeitung möglichst schnell abläuft gibt es für die Meldungen zwei Prioritäten: normal und high die im Dateinamen hinterlegt sind.
  In der Konfigurationsdatei DM_Config_Global.ini ist definiert, wie oft nach Meldungen mit Priorität normal bzw. high gesucht werden soll (z.B. high alle 60 Sekunden, normal alle 10 Minuten). Damit soll sich die Systembelastung im Rahmen halten.
• Dateiname: Dieser muss eindeutig sein und lautet: DM_<Priorität>_<JJJMMTT>_<nnn>.txt.
  • Priorität: normal oder high
  • JJJJMMTT: Jahr Monat und Tag z.B. 20230307
  • nnn: Dreistellige laufende Nummer, damit mehere Meldungen pro Tag abgehandelt werden können.
• Die erste Zeile der Datei enthält informationen, wie mit der Nachricht umzugehen ist. Beispielsweise:
  • Standort(e) für den die Meldung gültig ist
  • Anzeige endet nach n Sekunden automatisch
  • Anzeige muss mit OK bestätigt werden
  • Anzeige muss 2x mit OK bestätigt werden
  • etc.

Befehle:

Mit bestimmten Textdateien sollen Aktionen bei den Clients ausgeführt werden. Befehle werden wie Meldungen mit Prioriät high behandelt.

Beispiele:

• Restart: Startet DM bei allen Clients neu. Dies wird verwendet um sofort eine neue Version von DM zu verteilen (also nicht auf den nächsten Login zu warten).
• Exit: Beendet DM bei allen Clients
• etc.

Zitat von Peter S. Taler

ist aber wichtig, damit das Programm nicht rund um die Uhr läuft.

Tut es aber, da es kein Exit aus der While-Schleife gibt. Sleep verhindern, dass die Schleife ungebremst läuft und so die gesamte CPU-Leistung auffrisst.

An Taskscheduler habe ich auch schon gedacht. Mein aktueller Vorschlag ist einfacher aber schlußendlich entscheidet der OP was ihm besser gefällt.

Programm und zu verteilende Nachrichten liegen am Server, die Programmausführung erfolgt lokal. Die Protokollierung der bereits gesehenen Nachrichten ebenfalls.

"Wartezeit bis zum nächsten Durchlauf" ist doch eindeutig, oder?

Siehe Punkt eins und (nun) den letzten Punkt meiner Liste oben

Hier mal meine Gedanken dazu:

Voraussetzung: Ein Verzeichnis, auf das alle User in der Domäne Zugriff haben.

Ansatz:

• Das login-Skript startet ein im gemeinsamen Verzeichnis abgelegtes Program. In einer Ini-Datei sind variable Parameter abgelegt (Wartezeit bis zum nächsten Durchlauf etc)
• Jede anzuzeigende Meldung wird in einer eigenen Datei mit eindeutigem Namen (z.B. Datum plus laufende Nummer) hinterlegt z.B. 2023-03-07-001.msg
• Das Programm prüft, ob im gemeinsamen Verzeichnis solche msg-Dateien existieren.
• Falls ja, wird für jede Datei geprüft, ob sie bereits angezeigt wurde (durch Prüfung einer EIntragung in einer INI-Datei)
• Falls nein, wird jede msg-Datei in einem PopUp angezeigt. Dann wird in der INI mit Datum/Uhrzeit gespeichert, dass die msg angezeigt wurde
• Nun wartet das Programm die angegebene Zeit und prüft dann erneut auf Meldungen

Das ließ sich mit wenig Aufwand programmieren und flexibel anpassen.

Die Idee dahinter ist, dass alle veränderlichen Informationen nicht im Skript abgelegt werden, sondern in einer Textdatei. Dadurch muss bei Änderungen nicht das Programm geändert, sondern nur die INI-Datei mit einem Texteditor angepasst werden.

Aber um der Lösung Deines Problems näher zu kommen hätte ich noch folgende Fragen:

• Welche der oben vorgeschlagenen Lösungsansätze möchtest Du verwenden? Excel, INI-Dateien, CSV?
• Musst Du irgendwelche Daten speichern (z.B. welches Gerät wann retour kam bzw. ob es mehrfach retourniert wurde etc.)?

Zitat von Workflow

Ich persöhnlich habe noch nie mit Makros oder AutoIT gebarbeitet, daher bin ich totaler noob .

Ob die RegExp für den OP einfacher sind als die Excel UDF

Danke für Deine Beschreibung. Damit können wir starten.
Hier mal ein Vorschlag von mir zur Diskussion. Wenn er dann für Dich passt, ist es schnell in AutoIt umgesetzt.

1. Konfigurationsdaten werden in einer INI-Datei abgelegt, damit sie bei Bedarf leicht geändert werden können und das Skript nicht jedes mal angepasst werden muss.
2. Excel wird gestartet bzw. eine bestehende Excel Instanz verwendet.
3. Es wird geprüft, ob das Excel-Arbeitsblatt bereits offen ist. Falls ja, verbindet sich das Skript mit diesem Arbeitsblatt. Falls nein, wird das Arbeitsblatt geöffnet
4. GUI wird angezeigt. Das Skript verwendet nicht den Excel Suchdialog (Strg-f) sondern ein eigenes GUI (damit wir die volle Kontrolle haben).
5. Wenn im GUI OK gedrückt wird, beginnt die von Dir beschriebene Verarbeitung (diesen Punkt gehen wir später an)
6. Zurück zu Punkt 4 für die nächste IMEI

Passt das so für Dich?

Um zu prüfen, ob Deine Excel-Version Automatisierung unterstützt, rufe bitte die Hilfe von AutoIt mit F1 in SciTE auf, suche nach _Excel_Open und führe das Beispielskript 1 aus.
Du bekommst eine Fehlermeldung, wenn Excel COM nicht unterstützt (was ich leider befürchte).

Dann gilt es eine der von BugFix Andy vorgeschlagenen Alternativen zu prüfen.

Weitere Alternative:
https://www.autoitscript.com/f…-xlsx-files-without-excel

Da wird es bei mir leider dünn werden, da ich mich mit GUI und WinAPI leider kaum bis gar nicht auskenne

Tweaky Hier die übersetzten Dateien aus Paket 06:

Tweaky Sorry, mein Fehler. Hab's nochmals hochgeladen.

Schau Dir dazu mal das wiki im engl. Forum an.

Tweaky Hier die übersetzten Dateien aus Paket 05:

Sehr schön

Ist vorgemerkt! Wird aber etwas dauern, da ich derzeit voll eingespannt bin