für sowas mal nen Formmanager als Komponente bauen. Der könnte dann auch gleich eine Liste aller offenen Formulare halten und eine Log-Datei mitführen in der nachlesbar ist, welches Formular von welchem Benutzer wann geöffnet oder wieder geschlossen wurde. Als freundlichen Nebeneffekt könnte der auf gleich das Userlogin über eine Datenbank regeln.
Dabei ist das eigentliche Hauptformular praktisch nur das Mainmenu, je nach Userlogin kann das dann auch eingeschränkte Bedienung zur Folge haben.
Anbei mal sowas aus einem Delphi-Projekt. Das sollte sich leicht nach Lazarus übertragen lassen.
#Edit
Ist sowohl unter Delphi7 und Lazarus in der vorliegenden Form installierbar.
Ich versteh dich jetzt richtig ? Man soll protokollieren am besten über eine Datenbank villeicht auch noch Oracle wer in meiner Anwendung wann ein Formular öffnet ? Es ist doch gar nicht möglich das Unterschiedliche benutzer in einer Anwendung unterschiedliche Fenster öffnen ?!
Nicht in der Datenbank protokollieren, lediglich in einer Log-Datei. Ansonsten nimm einfach an, die Anwendung wird morgens mitsamt dem Rechner gestartet, dann könnten sich zu verschiedenen Zeiten auch verschieden Personen anmelden. Sind die eine Weile nicht aktiv werden sie von der Anwendung ausgeloggt. Zu diesem Zeitpunkt könnte die Person mehrere Formulare geöffnet haben, kehrt sie nun zurück und meldet sich erneut an kann das System die Formulare wieder öffnen die vorher geöffnet waren. Gleiches gilt für eine Person die in der Zwischenzeit bei der Anwendung angemeldet war und sich ebenfalls nicht abgemeldet hat.
Auf diese Weise könnten auch 2 oder mehr Personen in der Anwendung angemeldet sein und zwischen diesen kann gewechselt werden. Sie erhalten jeweils ihren letzten Zustand hergestellt sobald der Benutzer wechselt.
Meldet sich der Benutzer richtig ab wird die Abmeldung in der Log-Datei mitgeführt. Gleiches gilt wenn die Anwendung vollständig geschlossen wird, dann werden alle aktiven aber zwangsausgeloggten Benutzer zwangsabgemeldet und auch das protokolliert. Das gilt natürlich auch für den Fall, das der Benutzer längere Zeit nicht aktiv war und von der Anwendung ausgeloggt wird.
Für die Mimik innerhalb des Formulars, z.B. aktive Daten im Formular, ist dann das Formular selbst verantwortlich. So könnte das Formular z.B. einen bestimmten Datensatz aus einer Tabelle gezeigt haben als das Zwangslogout eintrat. Wird das Formular vom User reaktiviert zeigt es den aktuellen Zustand des Datensatzes.
Nur die Anmeldedaten für den einzelnen User könnten aus einer Datenbank stammen. Denkbar wäre auch ein SSL-Login, ganz nach belieben.
Das ist zwar für LINUX nicht unbedingt von Nöten, bei Windoofs macht das aber durchaus Sinn. Die Anwendung wird per FormularManager multiuserfähig gemacht, das ist nicht mal sonderlich aufwendig. Nimmt man noch einen Kartenleser zur Hilfe wird das Ding sogar richtig elegant.
Was noch fehlt wäre eine Komponente für Log-Dateien. Was man dann genau dort protokolliert bleibt jedem anheim gestellt. Aber auf diese Weise wäre eine Arbeitszeitkontrolle prima zu realisieren. Auch könnte man verhindern, das ein User an mehreren Plätzen angemeldet ist.
Denk dir aus was du möchtest, denkbar ist alles. Das einzige was nötig ist, das man ein neues Formular nur über den FormularManager öffnet, damit es auch richtig eingetragen wird. Dazu dient die Struktur TFormDescriptor, die man ganz nach Wunsch noch erweitern kann.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.
Also als Standart hätte ich das nicht gesehen. Das ist ziemlich Speziell und der einzige Sinn, der mir dafür einfällt ist eine BDE. Und dafür implementier ich das dann doch lieber auf meine Anwendung angepasst.
Sieh es Dir einfach an. Das sind nur wenige Routinen. Das Szenario hat man sich etwa so vorzustellen:
1. Man deklariert ein Formular als FormManager
2. darauf setzt man die Komponente
3. der Formmanger initialisiert die Variable FormularManager aus dem Modul
4. Alle neuen Formulare laden uFormularManager und haben damit Zugriff auf den Manager
5. Für Jedes Formular das geöffnet wird deklariert man FormDescriptor und übergibt die Struktur an die Komponente. Diese erzeugt das Formular und sorgt für die Darstellung.
6. Jedes Formular kann sich selbst schließen oder von außen geschlossen werden, die Komponente biegt einfach OnFormClose auf eigene Routinen um und kümmert sich um die geeigneten Mechanismen.
7 welche Formulare geöffnet sind wird in FormManager in einer TMemo-Komponente protokolliert. Eine geeignete Struktur vorausgesetzt kann man diese dann gezielt aufrufen und sichtbar machen oder ganz schließen.
@Christian
Ich seh das mehr als zentrale Schaltstelle für beliebige Anwendungen. Auf dem Modell setzt mein Zahnarzt-Praxensoftware auf. Bei der ist grundsätzlich niemand an einen bestimmtem PC gebunden. Zahnärzte haben heute häufiger mehrere Behandlungsräume und können so 2-3 Patienten parallel behandeln. Die Kartenleser dienen dabei der Zeiterfassung. Man kann auf diese Weise später dem Arzt anbieten, die tatsächliche Behandlungszeit aufzuschlüsseln. Nach ca. 6 Monaten hat man damit genügend Daten um für einzelne Behandlungsschritte eine Zeitvorgabe zu machen. Das hilft beim planen von Terminen, das System kann auf diese Weise aus den geplanten Behandlungsschritten die Termindauer ermitteln und nach einem geeigenten Termin suchen.
Da auch die Helferin ihre Personalkarte im Behandlungsraum stecken muß, kann man auch deren effektiven Einsatz besser planen. Manche Helferinnen sind für bestimmte Behandlungen halt besser geeignet als andere.
Gleichzeitig kann ohne geeignete Karte keiner in die Daten gucken.
Eine ganze Menge Einsatzmöglichkeiten also.
Humor ist der Knopf, der verhindert, daß uns der Kragen platzt.
Ich versteh immer noch nicht so ganz was bei der Sache die Komponente zu tun hat. Wenn sich ein benutzer abmeldet und ein anderer anmeldet, brauch ich doch dazu keinen formularmanager ?!
Und deine Featureliste hört sich so an wie Application.Forms
Dafür gibt es auch noch einfacherer Wege. Gut, eine Anwendung besteht aus vielen Formularen.
Dann musst du halt ein Server bauen an den sich mehrer Clients Anmelden.
schnullerbacke hat geschrieben:Nicht in der Datenbank protokollieren, lediglich in einer Log-Datei. Ansonsten nimm einfach an, die Anwendung wird morgens mitsamt dem Rechner gestartet, dann könnten sich zu verschiedenen Zeiten auch verschieden Personen anmelden. Sind die eine Weile nicht aktiv werden sie von der Anwendung ausgeloggt. Zu diesem Zeitpunkt könnte die Person mehrere Formulare geöffnet haben, kehrt sie nun zurück und meldet sich erneut an kann das System die Formulare wieder öffnen die vorher geöffnet waren. Gleiches gilt für eine Person die in der Zwischenzeit bei der Anwendung angemeldet war und sich ebenfalls nicht abgemeldet hat.
Auf diese Weise könnten auch 2 oder mehr Personen in der Anwendung angemeldet sein und zwischen diesen kann gewechselt werden. Sie erhalten jeweils ihren letzten Zustand hergestellt sobald der Benutzer wechselt.
Meldet sich der Benutzer richtig ab wird die Abmeldung in der Log-Datei mitgeführt. Gleiches gilt wenn die Anwendung vollständig geschlossen wird, dann werden alle aktiven aber zwangsausgeloggten Benutzer zwangsabgemeldet und auch das protokolliert. Das gilt natürlich auch für den Fall, das der Benutzer längere Zeit nicht aktiv war und von der Anwendung ausgeloggt wird.
Für die Mimik innerhalb des Formulars, z.B. aktive Daten im Formular, ist dann das Formular selbst verantwortlich. So könnte das Formular z.B. einen bestimmten Datensatz aus einer Tabelle gezeigt haben als das Zwangslogout eintrat. Wird das Formular vom User reaktiviert zeigt es den aktuellen Zustand des Datensatzes.
Nur die Anmeldedaten für den einzelnen User könnten aus einer Datenbank stammen. Denkbar wäre auch ein SSL-Login, ganz nach belieben.
Das ist zwar für LINUX nicht unbedingt von Nöten, bei Windoofs macht das aber durchaus Sinn. Die Anwendung wird per FormularManager multiuserfähig gemacht, das ist nicht mal sonderlich aufwendig. Nimmt man noch einen Kartenleser zur Hilfe wird das Ding sogar richtig elegant.
Was noch fehlt wäre eine Komponente für Log-Dateien. Was man dann genau dort protokolliert bleibt jedem anheim gestellt. Aber auf diese Weise wäre eine Arbeitszeitkontrolle prima zu realisieren. Auch könnte man verhindern, das ein User an mehreren Plätzen angemeldet ist.
Denk dir aus was du möchtest, denkbar ist alles. Das einzige was nötig ist, das man ein neues Formular nur über den FormularManager öffnet, damit es auch richtig eingetragen wird. Dazu dient die Struktur TFormDescriptor, die man ganz nach Wunsch noch erweitern kann.
Sieh es Dir einfach an. Das sind nur wenige Routinen. Das Szenario hat man sich etwa so vorzustellen:
1. Man deklariert ein Formular als FormManager
2. darauf setzt man die Komponente
3. der Formmanger initialisiert die Variable FormularManager aus dem Modul
4. Alle neuen Formulare laden uFormularManager und haben damit Zugriff auf den Manager
5. Für Jedes Formular das geöffnet wird deklariert man FormDescriptor und übergibt die Struktur an die Komponente. Diese erzeugt das Formular und sorgt für die Darstellung.
6. Jedes Formular kann sich selbst schließen oder von außen geschlossen werden, die Komponente biegt einfach OnFormClose auf eigene Routinen um und kümmert sich um die geeigneten Mechanismen.
7 welche Formulare geöffnet sind wird in FormManager in einer TMemo-Komponente protokolliert. Eine geeignete Struktur vorausgesetzt kann man diese dann gezielt aufrufen und sichtbar machen oder ganz schließen.
@Christian
Ich seh das mehr als zentrale Schaltstelle für beliebige Anwendungen. Auf dem Modell setzt mein Zahnarzt-Praxensoftware auf. Bei der ist grundsätzlich niemand an einen bestimmtem PC gebunden. Zahnärzte haben heute häufiger mehrere Behandlungsräume und können so 2-3 Patienten parallel behandeln. Die Kartenleser dienen dabei der Zeiterfassung. Man kann auf diese Weise später dem Arzt anbieten, die tatsächliche Behandlungszeit aufzuschlüsseln. Nach ca. 6 Monaten hat man damit genügend Daten um für einzelne Behandlungsschritte eine Zeitvorgabe zu machen. Das hilft beim planen von Terminen, das System kann auf diese Weise aus den geplanten Behandlungsschritten die Termindauer ermitteln und nach einem geeigenten Termin suchen.
Da auch die Helferin ihre Personalkarte im Behandlungsraum stecken muß, kann man auch deren effektiven Einsatz besser planen. Manche Helferinnen sind für bestimmte Behandlungen halt besser geeignet als andere.
Gleichzeitig kann ohne geeignete Karte keiner in die Daten gucken.
Eine ganze Menge Einsatzmöglichkeiten also.
Interessanter Ansatz, das heisst Du löst die Benutzerzugriffsverwaltung auf Formularebene ?!
Ich bin des halb auf einen neuen Thread gegangen, weil es mit dem Ursprünglichen nichts zu tun hat.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
der FormularManager ist das MainForm und initialisiert die Anwendung. Also Verbindung zum SQL-Server herstellen usw.. Ist das gelungen ruft er automatisch den Login-Screen auf, meldet sich jemand erfolgreich an speichert er dies und überprüft beständig die Aktivität. Wird die maximale Inaktivitätszeit erreicht oder die Karte gezogen wird der User als ausgeloggt gekenzeichnet aber der FormularManager kennt alle vom User zuletzt geöffneten Formulare und setzt sie auf Hide, das ist der Teil in der Komponente.
Das kann man entsprechend erweitern, sodass auch mehrer User gleichzeitig angemeldet sein dürfen aber nicht gleichzeitig aktiv sein können. Das wäre auch nur schwer möglich(ein Bildschirm, eine Tastatur usw.). Beendet ein User sein Login wird alles geschlossen was ihm gehört und das ganze in eine Log-Datei geschrieben.
Das gibt eine sehr effektive Aktivitätskontrolle und sorgt gleichzeitig dafür, das jemand nach seine Frühstücks- oder Mittagspause alle seine zuletzt geöffneten Formulare wiederfindet. Sollten die Formulare einen DB-Zugriff machen, müssen sie sich selbst um ein refresh kümmern. Dazu sollte in FormDescriptor noch ein Verzeichnis angegeben sein in das die Formulare auf User-Ebene ihre Daten speichern und wieder abrufen können.
Die Login-Kontrolle wird über den SQL-Server gesichert. Das kann natürlich auch per SSL passieren. Bei den gängigen SQL-Servern gibt es allerdings meistens auch SSL, man kann sich also auf den SQL-Server beschränken.
Das ist für Linux zwar nicht unbedingt nötig, hier könnte jeder sein Login auch über das BS machen. Bei Windoofs allerdings wird damit das Verhalten von Linux emuliert, da kann ja auch jeweils nur ein User aktiv sein.
Der Witz an der Sache, das hast du ganz richtig erkannt, der FormularManager gibt dir jeweils nur deine Formulare wieder zurück. Das Spiel kann man auch weiter treiben und z.B. die Ausführung auf User-Ebene beschränken. Die Helferin kann im Zahnarzt-Beispiel keine Behandlungsplanung machen, die Buchhaltungskraft bekommt keinen Zugriff auf den Behandlungsteil usw..
Insgesamt könnte man auf diese Weise einen Programmrumpf aufbauen der en SplashScreen, Login und FormularManager enthält. Dann kann man sich auf die Programmierung der Formulare beschränken. Das läßt sich natürlich auch auf ganze Module erweitern.
Ich häng Dir einfach mal den jetzigen Stand an. Das läßt sich bereits unter Delphi7 und Lazarus als Komponente einrichten. Wenn Du willst verschieben ich das auch gerne auf einen SVN-Server. Das muß halt nur noch etwas allgemeiner gemacht werden. Also beim Programmstart eine Ini- oder XML-Datei aufrufen, in der die entsprechenden Angaben zur Application stehen.
schnullerbacke hat geschrieben:
Anbei mal sowas aus einem Delphi-Projekt. Das sollte sich leicht nach Lazarus übertragen lassen.
Hallo Schnullerbacke, was für 'ne Lizenz hat das Ding. LGPL ? Den geschrieben wurde es 'hardy' und 'root', aber ohne explizite Angabe einer Lizenz, damit kann man unter OpenSource nichts anfangen. Ist leider so, denn heutzutage musst du ja schon jeder Datei/Projekt eine Opensource Lizenz geben, sonst kannst du es ja nicht wirklich 'frei' verwenden, besonders nicht in Software die später ev. auch Produktiv eingesetzt wird.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).
Verein
Links
Suche