XP Usermanagers 6.1 Open Source

[Luckie]

Aktuelle Version: 6.1.0.25

Der UserManager dient dazu Benutzerkonten auf NT ff. Maschinen anzulegen, zu löschen, Benutzer Gruppen zu zuordnen und deren Konten zu verwalten. All dies kann man auch mit der Windows internen Benutzerverwaltung, nur nicht so übersichtloch, wie ich denke.
Man kann mit dem Usermanager auch lokale Benutzerkonten auf remote Computer im Netzwerk verwalten. Was allerdings nicht mit Windows XP Home funktioniert, da XP Home den remote Zugriff nicht gestattet.

Unterstütze Betriebssysteme:

• Windows NT 4.0, vermutlich, nicht getestet.
• Windows 2000
• Windows XP (32-Bit), Windows XP Home wird nicht remote unterstützt.
• Windows Vista 32-Bit
• Windows 7 32-Bit, 64-Bit

Features:

• Auswahl des zu bearbeitenden Computers (und ist damit netzwerktauglich)
• Anzeige des Betriebsystems des Remotecomputers
• Anzeigen des ausgewählten Computers und Benutzers in der Titelzeile
• Statusanzeige beim Übertragen der Konten und Kontendaten in der Statusleiste
• Auflistung sämtlicher Konten in einer Baumstruktur (einschließlich Systemkonten wie z.B. Hilfeassistent)
• Hervorheben von deaktivierten Konten durch ein anderes Symbol
• Ansicht kann zwischen Benutzern und Gruppen umgeschaltet werden
• Details mit Angabe des Benutzer-Namens, vollständiger Name, Beschreibung, Stammverzeichnis und Script
• Checkboxen zur schnellen Konfiguration des ausgewählten Kontos bezüglich Kennwort und anderen Daten
• Direkte Anzeige der Zuordnung zu Gruppen sowie Anzeige aller verfügbaren Gruppen
• Direkte Anzeige sämtlicher Parameter des Kontos
• Benutzer können in eine CSV Datei exportiert werden
• Es können mehrere Benutzer auf einmal über eine Vorlagendatei angelegt und wieder gelöscht werden
• Integrierte Gruppenverwaltung
• Toolbar mit Schaltflächen für die wichtigsten Funktionen
• Export der Benutzer von und Import von Benutzer aus einer XML-Dateien neu
• Modernere Icons neu
• Ausführliche kontextsensitive Hilfe

Der XP Usermanager ist ab sofort Freeware. Im Archiv befindet sich noch eine paf.exe zur Installation für PortableApps (http://portableapps.com/)

[Luckie]

Die CompilerSwitches.inc ist da drin, weil ich den Kommandozeilencompiler für die Batch nutze. Aber deines Debugging-Problems war ich jetzt auch etwas ratlos.

[nahpets]

Zitat von Delphi-Laie:

{$I CompilerSwitches.inc} Diese entfernt bzw. auskommentiert, und schon sind die Haltepunkte da!

Würd' ich nicht so machen, da man dann nie weiß, ob durch andere Schalter nicht irgendwelche Nebeneffekte auftreten. Ändere lieber in der {$I CompilerSwitches.inc} den Debugschalter ab, dann gilt das solange für alle Stellen, an der die {$I CompilerSwitches.inc} eingebunden ist, bis Du die Änderung dort zentral wieder rückgängig machst.

Der Sinn der Includedatei ist es ja, die Änderungen zentral durchführen zu können und nicht nach dem Motto: Entweder alles oder nichts.

Und da die Includedatei in der ersten Zeile ein {.$define DEBUG} enthält, wäre es sinnvoller dort den . zu entfernen, da in der Datei über diesen Compilerschalter weitere Abhängigkeiten berücksichtigt werden.

Interessant wäre es zu prüfen, ob der von Dir entdeckte Fehler nach dem Aktivieren der Include-Datei weiterhin auftritt oder ob es sich hierbei um einen Nebeneffekt handelt, der durch die Änderung der Compilerschalter auftritt.

[Luckie]

Zitat von nahpets:

Und da die Includedatei in der ersten Zeile ein {.$define DEBUG} enthält, wäre es sinnvoller dort den . zu entfernen, da in der Datei über diesen Compilerschalter weitere Abhängigkeiten berücksichtigt werden.

Genau so habe ich es auch immer gemacht. Wenn ich dran gearbeitet habe, habe ich so das Debugging aktiviert und später wieder aktiviert, wenn ich die Version zum Veröffentlichen compiliert habe.

[jaenicke]

Zitat von Delphi-Laie:

Der Fehler passiert in der Funktion "ImportXMLThread" und erstaunt mich insofern, als daß dort doch mit "try..finally" ihm entgegengewirkt wird.

Oh, böse.
Die Methode Import liefern zwar einen Boolean zurück, schmeißt aber bei Misserfolg eine Exception.
Da das eine Threadmethode ist, landet die dann direkt in den aufrufenden Windows-Routinen.

Bei der Konstellation macht es gar keinen Sinn eine Exception zu werfen. Dazu kommt, dass Exception.Create in Unit Exceptions inherited nicht aufruft und somit die Message der Exception noch dazu leer ist.

try..finally sorgt ja nur dafür, dass Import.Free noch ausgeführt wird, behandelt aber den Fehler nicht.

Und CoDOMDocument40.Create ist auch etwas veraltet, das gibt es auch neueren Systemen vermutlich gar nicht mehr.

Ich schaue mal sobald ich dazu komme. Sollte schnell gehen.

[Luckie]

Zitat von jaenicke:

Zitat von Delphi-Laie:

Der Fehler passiert in der Funktion "ImportXMLThread" und erstaunt mich insofern, als daß dort doch mit "try..finally" ihm entgegengewirkt wird.

Oh, böse.

Ich war jung und brauchte den Code.

[Delphi-Laie]

Zitat von Aviator:

Du könntest ein Pull/Merge-Request auf GitHub erstellen damit Sebastian das einpflegen kann.

Warum einfach, wenn es auch ganz "hochoffiziell" möglich ist?

In meinen Augen gehört das eher zur Rubrik "issues". Ist jetzt jedenfalls dort als solcher auf höchst "intermediate English" eingetragen.

Danke für den Hinweis!

[jaenicke]

Zitat von Luckie:

Ich war jung und brauchte den Code.

Och, das passiert öfter als du vielleicht denkst.
Und solange man dann in diesem Fall nicht eine solche Fehleingabe macht, merkt man es ja auch nicht.

[Delphi-Laie]

Zitat von jaenicke:

Bei der Konstellation macht es gar keinen Sinn eine Exception zu werfen. Dazu kommt, dass Exception.Create in Unit Exceptions inherited nicht aufruft und somit die Message der Exception noch dazu leer ist.

Naja, ich glaubte bisher eigentlich, daß "try" einen solchen fehlerbedingten Programmabsturz zuverlässig bzw. immer verhindert.

Daß "except" im Fehlerfalle, und zwar unmittelbar danach, aktiv wird, ist klar.

Demnach hatte ich bisher bei "try...finally" eine solche Funktionalität im Hinterkopf, daß Fehler abgefangen, aber im Fehlerfalle (wird der Rest im try nach dem Fehler noch ausgeführt?) keine weitere Aktion erfolgt, danach aber in jedem Falle der Code im finally-Teil ausgeführt wird.

[jaenicke]

Zitat von Delphi-Laie:

Demnach hatte ich bisher bei "try...finally" eine solche Funktionalität im Hinterkopf, daß Fehler abgefangen, aber im Fehlerfalle (wird der Rest im try nach dem Fehler noch ausgeführt?) keine weitere Aktion erfolgt, danach aber in jedem Falle der Code im finally-Teil ausgeführt wird.

Beides macht das gleiche, wenn b mal angenommen eine Exception wirft und mal nicht:

Delphi-Quellcode:

a;
try
  b;
finally
  c;
end;

// und:
a;
try
  b;
  c;
except
  c;
  raise;
end;

In beiden Fällen wird c ausgeführt und der Fehler wieder geraised und somit weitergereicht. Finally bewirkt das nur automatisch.

[Luckie]

Mein Gedankengang war wohl, dass man auch nur vom Usermanger erstellte XML-Dateien importiert, deswegen habe ich die Fehlerbehandlung an dieser Stelle etwas vernachlässigt. Vielleicht wollte ich sie auch noch einbauen, habe es aber nur vergessen.