Codemancer

Habe das Problem nun in den Griff bekommen. Und zwar sieht das so aus, dass es eine mannigfaltige Anzahl an UserInfo-Strukturen gibt, die man in Kombination mit den NetUser***-Funktionen benutzen kann. Jedoch unterscheiden sich diese in dem, was sie können und was nicht (wobei das immer Property-Abhängig ist). Durch wälzen der Microsoft-Dokumentation, welche ziemlich verwirrend ist und auch erst nach 500-maligem Nachlesen die Informationen rausrückt, die man auch tatsächlich gebrauchen kann, habe ich heraus gefunden, dass für alles vor WindowsXP die UserInfo3 und für alles ab XP die UserInfo4 benutzt wird. Um den Flag UF_Passwd_Expired zu setzen, muss man diesen sowohl ins flag-Attribut reinsetzen, als auch das Attribut Password_Expired auf einen Wert ungleich 0 setzen, dann klappt es. Trotzdem Danke für die Mühe.

Der Rückgabewert beider Funktionen ist 0 ("Der Vorgang wurde erfolgreich beendet") Hier mal meine Eingabewerte: Comments "Script Normal Passwd_Expired " Flag 8389121 HomeDir "" Password "test" Password_age 0 PrivilegeLevel 1 Script_Path "" Username "250311-133432" Es klappt ja auch wirklich alles tadellos. Auch wenn ich andere Flags setze (z.B. UF_DONT_EXPIRE_PASSWD oder UF_ACCOUNTDISABLE) werden jene auch wirklich übernommen. Nur dieser eine Flag (AFAIK) nicht.

Es handelt sich hierbei um Lokale Benutzer.

Ich denke du verstehst da was falsch. Die Leute hier wollen dir nur einen Wink mit dem Zaunpfahl geben, dass das, was du da gerade vor hast, gehörig in die Hose gehen kann und du dir selbst keinen Gefallen damit tust - selbst wenn es gut gehen sollte. Konstruktiver geht es schon fast gar nicht mehr. Sie haben dir ihre Erfahrungen mitgegeben, dass Leute mit einer solchen "Abbruchleistung" nur schwer eine weitere Chance bekommen und Ratschläge gegeben, wie du die Sache am Besten durchziehen kannst. Ist deine Sache, wie du damit umgehst, aber stell die Leute hier bitte nicht als unfreundliche Säcke dar - das ist hier in diesem Thread nun gar nicht der Fall.

Servus, Beim setzen des UserFlags "UF_PASSWORD_EXPIRED" machen sowohl NetUserAdd als auch NetUserSetInfo genau gar nichts. Die beiden API-Funktionen werden an sich sauber ausgeführt (d.h. es wird alles so gesetzt, wie ich es haben will), jedoch nur dieser eine Wert nicht. Wenn ich den Flag in den entsprechenden Windows-Einstellungen setze, taucht er auch beim NetUserGetInfo-Aufruf auf. Die Flag-werte werden sauber ausgelesen ("UF_NORMAL_ACCOUNT" / "UF_SCRIPT" / "UF_PASSWORD_EXPIRED") aber wenn ich jetzt mal ganz doof genau diesen Wert setzen will, dann werden nur "UF_NORMAL_ACCOUNT" und "UF_SCRIPT" gesetzt... Ist euch da irgendeine Besonderheit bekannt? In der Documentation steht, dass dieser Wert von Win2k und WinNT nicht unterstützt wird. Ich selbst probiere es aber auf WinXP - und da Windows diesen Wert irgendwie setzt, muss man das doch über die API auch hin kriegen - zumal man ja jeden anderen Schrott auch setzen kann. MfG Enrico

Servus, Eine reine maschinelle Konvertierung ist zwar durchaus möglich, aber das Ergebnis wäre in meinen Augen nicht zufrieden stellend. Schon alleine, wenn man in VB.NET gewisse Dinge in nem drei-Zeiler Lösen kann, wo man sich in VB6 nen halben Arm ausgerissen hat. Auch was Strukturen angeht, ist VB.NET viel flexibler - weshalb sich ein Start von 0,5 eher lohnen würde. In unseren Unternehmen gehen wir dabei Schrittweise vor. Wir ersetzen nach und nach VB6 Projekte durch .NET und das klappt an sich recht gut. VB6 und VB.NET können durch relativ wenig Aufwand dazu gebracht werden, miteinander zu arbeiten...

Servus, ich habe auf der Arbeit erstmals mit dem Visual Basic 2005 Handbuch von Microsoft Press gelernt. Ist sogar ziemlich verständlich und da sind auch viele Codebeispiele drinne. Für die Grundlagen reicht das allemal, da die bei allen Framework-Versionen eh gleich sind. Afaik wird bei den Frameworks eh nur hinzugefügt und selten bis gar nicht irgendwas rausgehauen. Aber sobald du einmal die Grundlagen drinne hast, wird dir kaum ein Buch noch übermäßig viel bringen. Da biste meistens im Internet schneller bei einem Ergebnis.

Naja aus diesem Grund benutzen wir mit .NET ja ein Framework. Ich denke in diesem Fall ist das Verhalten schon eindeutig. Das ist ja der Sinn von Standards Im Endeffekt muss sowas eh getestet werden. Du kannst im Prinzip nur mit den Systemen testen und entwickeln, die du auch tatsächlich vorhanden hast. Alles andere wird sich halt leider als Fehler zurückmelden. Aber ich mag an dieser Stelle nicht über solche Grundsätze diskutieren. Selbst wenn dieses "System" nicht beim TE zutrifft, so hat er wenigstens schon mal einen Ansatzpunkt, um das Problem vielleicht selbst zu lösen. Allemal besser als gar nicht antworten ;P

Naja, optimieren musst du das Ding schon selbst Aber ein, zwei Tipps kann ich dir geben: Du hast mehrere Funktionsblöcke, die bis auf ein Paar Variablen völlig identisch sind. Solche Blöcke kannst du z.B. in eine eigene Methode auslagern, sodass du nur diese aufrufst und die entsprechenden Variablen einfach als Parameter übergibst. Dann benutzt du einen unnötigen With-Block. Zumindest, soweit ich das gesehen hab. Du benutzt nur einmal ein .Find, ansonsten nichts in der Richtung. Prüfe dies. Letztendlich kommentierst du zu ausgiebig. Naja okay, ist geschmackssache, aber zu viele Kommentare blähen den Code auf und machen das Gegenteil von dem, was sie eigentlich sollen: Übersicht und Klarheit verschaffen. Ein Beispiel: Da, wo du die Hintergrundfarbe festlegst. Die beiden Zeilen sind sich ziemlich ähnlich und können zusammen gefasst werden. Im Prinzip interessiert auch nicht wirklich, wo genau du jetzt was machst, sondern nur was du machst und das wo steht dann im Code. Aber diese Zeilen hast du eh komplett auskommentiert, also kannst du sie auch raushauen, insofern sie wirklich nicht mehr benötigt werden.

Das ist so nicht richtig. Ich habe gerade mal ein bisschen herumprobiert um zu verstehen, was du meinst. Dabei ist mir aufgefallen, dass die markierten Dateien grundsätzlich in der richtigen Reihenfolge in die Textbox (und letztendlich dem FileNames-Array) landen, jedoch immer die zuletzt markierte Datei als erstes Element angezeigt wird. Dies hat vermutlich den Grund, dass der Anwender bei einem MultiSelect immer sofort sieht, welche Datei er zuletzt markiert hat. Leider wurde dieses Feature nicht zu Ende gedacht, sodass man das erste Array-Element "per Hand" ans Ende stellen muss. Eindeutig ist sie schon, sie unterliegt halt ungewohnten, logischen Regeln. Mir ist das auch erst klar geworden als ich mir ganz blöd 6 nummerierte Dateien erstellt habe und diese eine nach der anderen ausgewählt habe.

Servus, Wenn du mit Listenfeld eine ListBox meinst, dann fügst du deine "Bilder" (wohl eher die Dateinamen bzw. Pfade) vermutlich mit ListBox.Items.Add hinzu, was bewirkt, dass die jüngsten Einträge unten angefügt werden. Wenn du aber willst, dass die neuesten Einträge oben >eingefügt werden, dann ist ListBox.Items.Insert dein Mittel der Wahl. Damit kannst du einen Eintrag an einer beliebigen Stelle einfügen (in diesem Fall die Stelle 0) Hier ein Beispiel (angenommen die ListBox1 gibt es schon) ListBox1.Items.Add("C:\Bild1.jpg") ListBox1.Items.Insert(0, "C:\Bild2.jpg") Die Einträger der ListBox wären dann folgende: Bild2.jpg Bild1.jpg Selbiges Funktioniert auch bei der "normalen" List(of [Type]) List.Insert(0, [Eintrag])