Cosmo wrote:
Wenn es jetzt für einzelne Gruppen dann doch unterschiedliche Ergebnisse gibt, gehört das in die Kategorie "überraschend", und "überraschend" kann potentiell auf "falsch" hinweisen.
Solche Einstellungs-Schlenker gehören folglich in die Dokumentation.
Jepp, irgendwie schon.
Cosmo wrote:
Denn wo ist die Logik, bei einem Teil der Befehle zu sagen: Das dürfen die und die sowieso nicht, bei einem anderen Teil das aber nicht zu sagen, obwohl dasselbe zu 100% zutrifft?
Die Inkonsistenzen sind blöd, aber leider nicht leicht zu vermeiden.
Die Kontext-Menüs für Ordner erzeugt SuRun dynamisch über eine Shell-Erweiterung.
Diese Erweiterung schaut, ob der Benutzer das Menü sehen soll und zeigt es dann evtl. an.
Die Kontext-Menüs für exefile, cmdfile, cplfile, mscfile, batfile, Msi.Patch, Msi.Package, regfile, CLSID\\{21EC2020-3AEA-1069-A2DD-08002B30309D} (Systemsteuerung) stehen in "HKCR" und werden immer und bei allen Benutzern angezeigt.
Dass das so statisch ist, hat nur einen Grund: Ich starte manche Verknüpfungen mit Kommandozeilenparametern.
Diese Parameter verschluckt Windows, wenn es Shell-Erweiterungen für Ziele von LNK Dateien aufruft.
Ich könnte SuRun so umschreiben, dass Registry-Einträge bei Aufnahme eines Benutzers in die SuRunners in HKCU\Software\Classes (also nur für genau den Benutzer) erzeugt werden. Das würde aber Power-User, die eben diese Registry Geschichten ändern, nicht freuen.
Bisher ist es halt nicht konsistent. Vielleicht fällt mir noch ein, wie es einfach besser zu machen geht.
Cosmo wrote:
[OutLook Express]
Was spricht gegen meine Idee? Einfach zu realisieren, ebenso einfach reversibel (obwohl es dafür keinen Bedarf gibt).
Der SuRunner, der in diese Situation kommt, hat nicht einmal die Chance irgendwo (auch das steht aber gar nicht in der Dokumentation) nachzugucken, daß er Strg-Alt-Entf drücken soll. Er wird vor dem Monitor sitzen und denken: "Früher ging das immer sofort - also ist hier ein Fehler." Und wenn dann der SuRun-Desktop erscheint, wem wird er den Fehler zuordnen? Das sieht nicht nach etwas aus, was lange in einer "Nachdenken-Liste" bleiben darf.
Das ist nicht OE spezifisch. Mik.c.OS hatte schon mal diesen Fehler nachdem er Daemon-Tools installiert hat.
Wenn ein Installer per RunOnce Registry Key gestartet wird, schaltet WinLogon scheinbar den Desktop nicht um.
Ich muss raus bekommen, wie das doch geht und keine Ausnahme vorgeben.
Steht schon auf der ToDo-Liste ;-)