Benutzer mit den meisten Antworten
Hilfe zur Umsetzung

Frage
-
Hallo
Tut mir leid, für den etwas wenig aussagekräftigen Titel.
Folgende Situation, die ich gerne in mein Projekt übernommen hätte, weiß aber nicht genau wie.
Im neuen Visual Studio gibt es mit den Aufgaben ein geniales Feature, bei dem die Arbeit im Code unterbrochen werden kann. Der "Status" des Arbeitsfortschrittes wird gespeichert. - Man arbeitet an anderem Code weiter und kann dann wieder zurück einchecken.
Der Clou an der Sache ist, dass sich Visual Studio (mit TeamFoundation) genau merkt (inkl. Ansicht, Codezeile usw.) wo der Benutzer stehen geblieben ist.Jetzt dachte ich mir, das wäre etwas ganz tolles für mein neues Projekt. Wenn ein Mitarbeiter sich am Terminal eincheckt kann er das Programm so nutzen, wie er es gewohnt ist. - Möchte ein anderer Mitarbeiter am selben Terminal schnell eine Aufgabe erledigen, checkt der Mitarbeiter A aus, Mitarbeiter B ein, erledigt seine Arbeit und bei wieder einchecken von Mitarbeiter A sieht der Bildschirm aus, wie er ihn verlassen hat. (inkl. Eingabe der Daten - ob gespeichert oder nicht)
Wie setzt man so etwas um? Ich meine das eher allgemeiner Natur, da mir im Moment jeder Umsetzungsansatz fehlt (Mir ist klar, dass es keine leichtes Unterfangen ist!)
DANKE für Tipps im Voraus - Schöne Feiertage
Antworten
-
Hi.
Ich habe soetwas neulich selbst auch mal versucht. Mein Ansatz war der folgende:
Zunächst habe ich überlegt, was den aktuellen Status ausmacht, sprich was das Programm laden müsste, um den aktuellen (Daten-Be)Stand wieder herzustellen. Da gab es ca. 4-5 Datei-Arten, die jeweils geladen wurden innerhalb eines Projektes. Ich habe also eine Art Projektklasse angelegt, darin die Dateien vermerkt, die geladen wurden. In Intervallen habe ich (quasi als Auto-Backup, in deinem Fall müsste dies eben beim "Switchen des Benutzers" passieren) alle Dateien mit einem ".tmp" versehen und gespeichert.
Würde man also ein Projekt einladen, das genau diese ".tmp" Dateien enthält (es gab am Ende dazu auch eine Projektdatei, die man direkt öffnen konnte, und die dann das "Nachladen" aller Teildateien veranlasste), wäre der Stand inhaltlich(!) genau derjenige vor dem Verlassen.
Der zweite Punkt ist, dass das Programm optisch nachher genauso aussehen sollte wie vor dem Verlassen. Dazu habe ich Fensterpositionen, Fensterzustände (minimiert-maximiert), Fenstergrößen und evtl. sonstige ungespeicherte Einstellungen ebenfalls gespeichert (in meinem Fall noch Farben, Spracheinstellungen, Zeilenpositionen). Bei jedem Beenden des Programmes bzw. bei jedem ".tmp"-Speicherstand.
Je nach dem, was dein Programm an Daten verwaltet, wie komplex die GUI und die Datenstruktur sind, kann das ein erheblicher Aufwand sein, einen Programmstatus so abzuspeichern und später wieder abrufbar zu machen. Eventuell kann man auch eine Master-Klasse erstellen mit Doubletten aller wichtigen Informationen aus verschiedenen anderen Klassen (als Referenz), und diese irgendwie mit XML serialisieren. Ob das die Prozedur allerdings einfacher macht, bin ich mir unsicher.
In mobilen Endgeräten wird das ganz gerne mal als Mini-Speicherdump realisiert, also wie ein 1:1 Abbild, das dann in den Programmspeicher geladen wird. Das halte ich aber für um ein Vielfaches schwieriger (wenn auch sicher schneller in der Ausführung). Es sei denn, man realisiert das irgendwie über Virtualisierung, wo man sich den schon existierenden Prozess der Speicher-Abbildsicherung zu Nutze machen kann oder einfach nur den Benutzer B als zweite Maschine anmeldet, ohne den ersten wirklich abzumelden.
Hoffe das hilft bei den weiteren Überlegungen.
LG, Dennis.
- Als Antwort markiert Zero-G. _ Freitag, 21. Dezember 2012 16:41
Alle Antworten
-
Hi.
Ich habe soetwas neulich selbst auch mal versucht. Mein Ansatz war der folgende:
Zunächst habe ich überlegt, was den aktuellen Status ausmacht, sprich was das Programm laden müsste, um den aktuellen (Daten-Be)Stand wieder herzustellen. Da gab es ca. 4-5 Datei-Arten, die jeweils geladen wurden innerhalb eines Projektes. Ich habe also eine Art Projektklasse angelegt, darin die Dateien vermerkt, die geladen wurden. In Intervallen habe ich (quasi als Auto-Backup, in deinem Fall müsste dies eben beim "Switchen des Benutzers" passieren) alle Dateien mit einem ".tmp" versehen und gespeichert.
Würde man also ein Projekt einladen, das genau diese ".tmp" Dateien enthält (es gab am Ende dazu auch eine Projektdatei, die man direkt öffnen konnte, und die dann das "Nachladen" aller Teildateien veranlasste), wäre der Stand inhaltlich(!) genau derjenige vor dem Verlassen.
Der zweite Punkt ist, dass das Programm optisch nachher genauso aussehen sollte wie vor dem Verlassen. Dazu habe ich Fensterpositionen, Fensterzustände (minimiert-maximiert), Fenstergrößen und evtl. sonstige ungespeicherte Einstellungen ebenfalls gespeichert (in meinem Fall noch Farben, Spracheinstellungen, Zeilenpositionen). Bei jedem Beenden des Programmes bzw. bei jedem ".tmp"-Speicherstand.
Je nach dem, was dein Programm an Daten verwaltet, wie komplex die GUI und die Datenstruktur sind, kann das ein erheblicher Aufwand sein, einen Programmstatus so abzuspeichern und später wieder abrufbar zu machen. Eventuell kann man auch eine Master-Klasse erstellen mit Doubletten aller wichtigen Informationen aus verschiedenen anderen Klassen (als Referenz), und diese irgendwie mit XML serialisieren. Ob das die Prozedur allerdings einfacher macht, bin ich mir unsicher.
In mobilen Endgeräten wird das ganz gerne mal als Mini-Speicherdump realisiert, also wie ein 1:1 Abbild, das dann in den Programmspeicher geladen wird. Das halte ich aber für um ein Vielfaches schwieriger (wenn auch sicher schneller in der Ausführung). Es sei denn, man realisiert das irgendwie über Virtualisierung, wo man sich den schon existierenden Prozess der Speicher-Abbildsicherung zu Nutze machen kann oder einfach nur den Benutzer B als zweite Maschine anmeldet, ohne den ersten wirklich abzumelden.
Hoffe das hilft bei den weiteren Überlegungen.
LG, Dennis.
- Als Antwort markiert Zero-G. _ Freitag, 21. Dezember 2012 16:41
-
Danke für Deine Antwort.
Also, eine 1:1 Kopie funktioniert leider unter Windows nicht (Hat was mit dem Mutex zu tun...)
Deine Idee ist schon sehr hilfreich, aber auch (wie du selbst sagst) sehr aufwendig.
Ich glaube, dass das Beste dabei wäre, einen Speicherpunkt immer nur an bestimmten vordefinierten Stellen zu zulassen. Dann kann man die Arbeit in Grenzen halten & trotzdem eine sehr interessante Arbeitsweise zulassen.
Ich werde mal in den nächsten Tagen darüber brüten - aber ich glaube, dass so einige Gedanken mittlerweile in die richtige Richtung gehen
DANKE für Deine Hilfe