Neuer Artikel bei mir: %HOMEDIR% - das unbekannte Verzeichni

[Chewie]

Zitat:

Zitat von mschaefer

Tja klingt gut, aber die Tücke liegt nahe. Wenn ich ein Programm habe, welches Standartmäßig für alle User laufen soll, und die Daten liegen im speziellen Userverzeichnis, dann kann ich das Ding ja jedesmal installieren -> Monotonie ind er Südsee...

Erstens musst du das Ding nicht jedesmal installieren, nur die Anwenderdaten sind pro Anwender verschieden. Und sollten alle Benutzer des Rechners die gleichen Daten benötigen, gibt es immer noch das "All Users"-Verzeichnis.
Und nebenbei, welches Programm läuft denn wie eine Standart :?:

[Sebastian Nintemann]

Also mich wundert, dass es so viele Einwände gibt...
Seit ich standardmäßig ein Benutzerkonto ohne Administratorrechte verwende merke ich, dass viele Software so einfach nicht funktioniert. Vorher hatte ich Winamp für ein gutes Stück Software gehalten. Ich musste feststellen, dass es ohne Adminrechte aus dem von Luckie genannten Grund schlichtweg nicht funktioniert. Es friert einfach ein. Das ist doch wohl inakzeptabel! Sicherlich gibt es Workarounds mit friemelei, aber soweit kommts noch, dass ich um ein Programm zu nutzen mein schönes System kaputtfriemlele. Ich finde es sollte eben nicht jedem Programmierer überlassen werden, wie er das Problem handhabt. Der %HOMEDIR% Ordner ist dafür vorgesehen, der Programme Ordner ist nicht dafür vorgesehen, basta, auch wenn es Argumente dagegen gibt. Als Benutzer ohne Adminrechte ärgere ich mich immer wieder darüber, einige Programme nicht nutzen zu können.
Das Argument, dass es praktisch ist, kleinere Tools in einem Ordner zu haben kann ich nachvollziehen. Dann muss es dieses entsprechende Programm aber auch als Archiv ohne Installer zum Download geben, da nur so klar ersichtig ist, was wo landet. 7zip ist da ein schönes Beispiel. Oder MirandaIM, wobei das auch in das %HOMEDIR% schreibt wenn mehrere Benutzer es nutzen wollen.

Viele Grüße,
Sebastian

[mirage228]

Hi,

also gründsätzlich bin ich auch dafür, dass Programme ihre Daten im Anwendungsaten-Ordner sicher sollten, obwohl ich auch mit solchen Rechten arbeite, die ein Schreiben im Programmverzeichnis erlauben.
Das machen heutzutage noch erstaunlich viele Programme so (einige meiner eigenen mit eingeschlossen), eben auch aus den genannten Gründen. Wenn es sich um ein kleines Tool handelt, kann ich da wohl noch drüber hinwegsehen, bei größeren Programmen erwarte ich einen ordnungemäßen Umgang mit einem Multi-User Betriebssystem.
Die Idee, wie die eingeschränkten Rechte bei Vista umgesetzt werden sollen, sind bei gute Implementierung auch nicht schlecht: Zugriffe auf den Windows Ordner zB werden auf den User-Ordner umgeleitet. Wie gut das jedoch im Endeffekt funktioniert, muss sich noch zeigen.

Just my 2 cents.

mfG
mirage228

[Jelly]

Wenn jedes Programm seine Daten im HomeDir speichert, bringt das aber auch die Gefahr mit sich, dass eventuell Konflikte zu bestehenden Datein aufkommen können. Speicher ich hingegen meine Dateien im Installationsverzeichnis, ist dies kein Problem.

Ich handhabe es zur Zeit so. Mit den nötigen Rechten werden meine Dateien, eigentlich ausschliesslich INI Dateien, im Intallationsverzeichnis gesichert. Schlägt dies fehl, so nehme ich auch das Heimverz. Naja, ist aber sicherlich auch nicht optimal. Besser wäre sicher die Registry.

Aber da spielt sich mir doch noch ne neue Frage auf. User spezifische Daten könnte man ja problemlos im HKCU Ast der Registry unterbringen. Aber was ist mit Rechnerspezifischen Daten. Denn der HCLM Ast ist prinzipiell für normale User zum Schreiben gesperrt, ebenso c:\Dokuemente und Einstellungen\All Users. Also wohin mit den Daten, damit ich sicher sein kann, dass das Schreiben auch funktioniert.

[NicoDE]

Zitat:

Zitat von Jelly

Wenn jedes Programm seine Daten im HomeDir speichert, bringt das aber auch die Gefahr mit sich, dass eventuell Konflikte zu bestehenden Datein aufkommen können. Speicher ich hingegen meine Dateien im Installationsverzeichnis, ist dies kein Problem.

Hier geht es um benutzerspezifische Daten. Das Installationsverzeichnis ist praktisch für globale Einstellungen (die üblicherweise von Hauptbenuzern und Administratoren vorgenommen werden) - dort haben aber die Daten des Benutzers nichts zu suchen. Es geht also eher darum die Art der Konfigurationsmöglichkeiten sauber in benutzerbezogen und global zu unterscheiden und am jeweils passenden Ort zu speichern.
Falls ein Programm grundsätzlich nur im eigenen Verzeichnis arbeiten möchte, impliziert man, dass jeder Benutzer eine eigene Kopie installieren müsste um damit arbeiten können (es gibt genug Programme die nicht auf Mehrbenutzersysteme ausgelegt sind - beste Beispiel OpenOffice (und das ist nicht gerade 'klein')).

[Jelly]

Naja, auch rechnerspezifische Daten müssen manchmal von normalen Usern gespeichert werden. Wie handhabt man denn das am Besten.

[NicoDE]

Zitat:

Zitat von Jelly

Naja, auch rechnerspezifische Daten müssen manchmal von normalen Usern gespeichert werden. Wie handhabt man denn das am Besten.

Über die Rechteverwaltung des Betriebsystems (sprich: ein Hauptbenutzer/Administrator muss entscheiden, dass normale Benutzer die Datei bearbeiten dürfen).

[fkerber]

Hi!

Hoffe, es wurde noch nicht erwähnt:

Ich kopiere (man beachte: NICHT installiere) also ein Programm. Dann geh ich davon aus, dass ich es los bin, wenn ich den Ordner wieder lösche - zumal es ja auch kein uninstall gibt...
Allerdings ruhen fröhlich Daten im HomeDir und müllen es mir zu.

Was ist damit?

Ciao Frederic

[Brüggendiek]

Hallo!

Zitat:

Zitat von fkerber

Ich kopiere (man beachte: NICHT installiere) also ein Programm. Dann geh ich davon aus, dass ich es los bin, wenn ich den Ordner wieder lösche - zumal es ja auch kein uninstall gibt...
Allerdings ruhen fröhlich Daten im HomeDir und müllen es mir zu.

Tjaaa - das passiert normalerweise auch mit installierter Software - oder hangeln die sich beim Deinstallieren durch alle Homedirs und werfen ihre Dateien raus? Dasselbe passiert mit der Registry - ist da HKCU der übrigen User überhaupt zugänglich?

Im Gegensatz zu Registry-Einträgen sind Dateien im Homedir allerdings harmlos - die paar Byte (bei NTFS sind die Dateien klein) spielen ja bei Plattengrößen von über 100GByte kaum noch eine Rolle. Außerdem verlangsamen sie das System nicht (im Gegensatz zu Registry-Müll).

Allerdings wurde ein Aspekt bisher nicht angesprochen:
Zum Installieren von Programmen braucht man Administrator-Rechte, denn der Deinstallations-Eintrag muß ja in der Registry unter HKLM stehen. Zum Kopieren eines nicht installationspflichtigen Programmes braucht man keine Administrator-Rechte, denn irgendwo ("Eigene Dateien") hat jeder Benutzer Schreibrechte und darf normalerweise auch Ordner anlegen. Dann hat der das Programm kopierende eingeschränkte Nutzer auch Schreibrechte im Programm-Ordner (er hat ihn ja selber angelegt).

Nebenbei: Ich rege mich immer wahnsinnig auf, wenn beim Installieren das nach "C:\Programme" gehen soll. Bei mir heißt der Programm-Ordner "C:\SOFT" - und ich sortiere darin nochmal nach gekauften, Freeware, eigenen Programmen etc.

Und dann war da noch ein Security-Analyser aus zweifelhafter Quelle (irgendwas mit Winzig und Weich :mrgreen:). Das Ding läuft prinzipbedingt nur mit Administrator-Rechten, trägt sich aber in Startmenü und Desktop unter "All Users" ein :wall:

Gruß

Dietmar Brüggendiek

[Sharky]

Hai ihr,

um auch mal einen Beitrag zu leisen ;-)

Ich mache das ganz einfach so:
Wenn es im Verzeichniss der Exe eine INI für das Programm gibt und in dieser in einem bestimmten Abschnitt ein Pfad zu einem Datenverzeichniss steht wird dieser verwendet. Wenn dieser Eintrag nicht vorhanden (oder leer) ist wird das APPDIR verwendet.
Dadurch hat der Anwender die Möglichkeit zu bestimmen ob die Daten an einer von ihm bestimmten stelle stehen sollen.

Den Pfad zu dem Datenverzeichniss speichere ich dann einfach in einer globalen Variabel.

Delphi-Quellcode:

const
  Programmname = 'Test';

var
  AppDir:      string;

procedure TDataModule1.ProgrammInit;
var
  IniFile: string;
  myIni: TIniFile;
begin
  IniFile := ChangeFileExt(ParamStr(0), '.ini'); // Ininame = Exename
  AppDir := '';
  myIni := TIniFile.Create(IniFile);
  try
    AppDir := myIni.ReadString('programm', 'appdir', '');
  finally
    myIni.Free;
  end;
  if (AppDir = '') then
  begin
    AppDir := GetShellFolder(CSIDL_APPDATA);
    AppDir := AppDir + 'Sharky\' + Programmname;
  end;
  AppDir := IncludeTrailingBackslash(AppDir);
end;

procedure TDataModule1.DataModuleCreate(Sender: TObject);
begin
  ProgrammIni;
end;

Die Ini:

Code:

[programm]
;datadir = c:\test

[Luckie]

Was macht ihr das eingentlich immer daran fest, ob es ein große oder kleines Tool ist? Meine LuckieDIPS würde ich auch als eher klein bezeichnen, aber was nütz mir das Programm, wenn ich im Anwendungsverzeichnis keine Schreibrechte habe? Aber auch wenn ich sie hätte, und es mehrere Benutzer auf dem System gibt, dann würden sich die Benutzer ja immer gegenseitig die gesicherten Iconpositionen überschreiben.

Es geht einzig und alleine darum, ob eine Programm von mehreren Benutzer genutzt werden soll oder nicht. Und nicht, ob Schreibrechte vorhanden sind oder nicht.

Dass es auch Außnahmen gibt, habe ich ja schon eingeräumt, zum Beispiel Software, die unteranderem speziell für den USB Stick zum mitrumschleppen konzipiert wurde.

[MathiasSimmack]

Anregung für einen neuen Artikel, Luckie: "Readme-Dateien, unbekannt und doch hilfreich" :stupid:

Zitat:

Zitat von NicoDE

(es gibt genug Programme die nicht auf Mehrbenutzersysteme ausgelegt sind - beste Beispiel OpenOffice (und das ist nicht gerade 'klein')).

Wenn du das Openoffice(.org) meinst, das ich kenne, dann musst du das Setup mal mit dem "-net"-Parameter starten, Nico, und du wirst staunen. :mrgreen: Edit: ~130MB global installierte Dateien, und nicht ganz 2 MB im Benutzerverzeichnis.

[NicoDE]

Zitat:

Zitat von MathiasSimmack

dann musst du das Setup mal mit dem "-net"-Parameter starten, Nico, und du wirst staunen. :mrgreen: Edit: ~130MB global installierte Dateien, und nicht ganz 2 MB im Benutzerverzeichnis.

[ot] Schön wär's, dann wird auf meinem Rechner nur die Hälfte installiert... (1.1.5 und 1.9.125) [ot]

[Assun]

Zitat:

Zitat von Sharky

Hai ihr,

um auch mal einen Beitrag zu leisen ;-)

Ich mache das ganz einfach so:
Wenn es im Verzeichniss der Exe eine INI für das Programm gibt und in dieser in einem bestimmten Abschnitt ein Pfad zu einem Datenverzeichniss steht wird dieser verwendet. Wenn dieser Eintrag nicht vorhanden (oder leer) ist wird das APPDIR verwendet.
Dadurch hat der Anwender die Möglichkeit zu bestimmen ob die Daten an einer von ihm bestimmten stelle stehen sollen.

Den Pfad zu dem Datenverzeichniss speichere ich dann einfach in einer globalen Variabel.

Delphi-Quellcode:

const
  Programmname = 'Test';

var
  AppDir:      string;

procedure TDataModule1.ProgrammInit;
var
  IniFile: string;
  myIni: TIniFile;
begin
  IniFile := ChangeFileExt(ParamStr(0), '.ini'); // Ininame = Exename
  AppDir := '';
  myIni := TIniFile.Create(IniFile);
  try
    AppDir := myIni.ReadString('programm', 'appdir', '');
  finally
    myIni.Free;
  end;
  if (AppDir = '') then
  begin
    AppDir := GetShellFolder(CSIDL_APPDATA);
    AppDir := AppDir + 'Sharky\' + Programmname;
  end;
  AppDir := IncludeTrailingBackslash(AppDir);
end;

procedure TDataModule1.DataModuleCreate(Sender: TObject);
begin
  ProgrammIni;
end;

Die Ini:

Code:

[programm]
;datadir = c:\test

Bei mir bringt er mir dann immer

Zitat:

[Fehler] MultiKey_uMain.pas(59): E2003 Undefinierter Bezeichner: 'GetShellFolder'
[Fehler] MultiKey_uMain.pas(59): E2003 Undefinierter Bezeichner: 'CSIDL_APPDATA'

Muss man da noch was einbinden ?

(sry wenns bissl OT is)

[MathiasSimmack]

Wie lange bist du schon hier? :gruebel:

1. Off-topic!
2. Suchfunktion?

[SirThornberry]

Zitat:

Zitat von Jelly

Naja, auch rechnerspezifische Daten müssen manchmal von normalen Usern gespeichert werden. Wie handhabt man denn das am Besten.

Auch das ist möglich, dafür gibt es den Ordner "Dokumente und Einstellungen\All Users" und dort haben dann auch alle Nutzer schreibrechte. Diesen besagten Ordner kann man auch per api ermitteln.

[Jelly]

Zitat:

Zitat von SirThornberry

Auch das ist möglich, dafür gibt es den Ordner "Dokumente und Einstellungen\All Users" und dort haben dann auch alle Nutzer schreibrechte. Diesen besagten Ordner kann man auch per api ermitteln.

Auf meinem XP haben die normalen User auch da nur Leserechte.

[Olli]

Zitat:

Zitat von NicoDE

[ot] Schön wär's, dann wird auf meinem Rechner nur die Hälfte installiert... (1.1.5 und 1.9.125) [ot]

[ot]Ich kann Mathias' Beobachtungen bestätigen - auf ziemlich vielen Rechnern im PC-Pool und zwar mit ziemlich vielen Benutzern und seit ziemlich vielen Versionen. Unattended Installs eingeschlossen![/ot]

[Phoenix]

Zitat:

Zitat von Jelly

Ich handhabe es zur Zeit so. Mit den nötigen Rechten werden meine Dateien, eigentlich ausschliesslich INI Dateien, im Intallationsverzeichnis gesichert. Schlägt dies fehl, so nehme ich auch das Heimverz. Naja, ist aber sicherlich auch nicht optimal. Besser wäre sicher die Registry.

Nein. Die Windows-Registry ist schon so gut wie tot.
Man sieht doch, wohin es gehen soll (schon mit .NET heute):

1.) Applikationen lassen sich per xcopy 'installieren'.
(Ja, der ausführende User muss Adminrechte haben wegen Startmenu-Eintrag z.B., aber installieren sollte imho eh nur der Admin dürfen).
2.) Einstellungen werden im User-Dir gespeichert
3.) Registry ist pfui

Stand heute würde ich es so machen:
Die Applikation speichert ihre Daten nur im User-Verzeichnis. Es gibt eine Backup-Funktion die die Userdaten des aktuellen Users in das AppDir (in ein Unterverzeichnis 'UserName') kopiert - auf wunsch verschiebt - sofern Adminrechte vorhanden sind. Es lässt sich (sofern Adminrechte vorhanden sind) in einer Configdatei direkt im Appverzeichnis einstellen, dass hier der Default-Speicherort ist. Diese Option ist da, sofern es Sinn macht das Programm z.B. auf USB-Stick mit sich zu führen und man die Einstellungen mitnehmen will.

Ich halte es so: Die Styleguides gibt es nicht umsonst. Halte ich mich an die aktuellen Styleguides von MS, so habe ich letzten Endes die kleinsten Probleme, das meine Applikation auch unter Vista und Folgesystemen laufen wird (meine laufen alle ohne Probleme drunter (aktuelle Beta), bei manchen Programmen anderer Hersteller sieht das leider schon wieder gaaaanz anders aus).

Gerade unter .NET laufen solche Applikationen dann aber auch mit dotGNU ohne dass man plattformspezifischen Code einbauen muss. Gerade in Bezug auf Pfade und Rechte des ausführenden Users...

Diese Styleguides gibts halt nicht umsonst ;-)

[leddl]

Darf ich mal kurz anmerken, daß das DP-eigene SwapIt! ebenfalls versucht, das Ergebnis im Programmverzeichnis zu speichern? Zudem legt es genau das Verhalten an den Tag, das Luckie bemängelt hat und läßt sich nur über den Taskmanagager abschießen, wenn man keine Schreibrechte hat :stupid: Soviel nochmal dazu :mrgreen:

[sakura]

Zitat:

Zitat von leddl

Darf ich mal kurz anmerken, daß das DP-eigene SwapIt! ebenfalls versucht, das Ergebnis im Programmverzeichnis zu speichern? Zudem legt es genau das Verhalten an den Tag, das Luckie bemängelt hat und läßt sich nur über den Taskmanagager abschießen, wenn man keine Schreibrechte hat :stupid: Soviel nochmal dazu :mrgreen:

Nun ja :angel: Nichts ist perfekt, oder :zwinker:

...:cat:...

[mschaefer]

Moin, moin,

das kann man nur mit einem Lächeln kommentieren:

Wer auf dem eigenen Rechner mit SwapIT keine Schreibrechte hat, der sollte sich mal gedanken darüber machen,
über was er überhaupt noch etwas zu sagen hat. Ja, für die Kandiaten gilt: Schweigen ist Gold.

:mrgreen: // Martin

[leddl]

Zitat:

Zitat von mschaefer

Moin, moin,

das kann man nur mit einem Lächeln kommentieren:

Wer auf dem eigenen Rechner mit SwapIT keine Schreibrechte hat, der sollte sich mal gedanken darüber machen,
über was er überhaupt noch etwas zu sagen hat. Ja, für die Kandiaten gilt: Schweigen ist Gold.

:mrgreen: // Martin

:gruebel: Muß man das kommentieren? Wurde bereits alles diskutiert. Und schließlich muß es sich auch nicht immer um den eigenen Rechner handeln :roll:

[Jens Schumann]

Hallo Luckie,
über diese Diskussion bin ich hier hergekommen.
Bei der function GetShellFolder ist mir folgendes aufgefallen:

Delphi-Quellcode:

function GetShellFolder(CSIDL: integer): string;
var
  pidl                   : PItemIdList;
  FolderPath             : string;
  SystemFolder           : Integer;
begin
  SystemFolder := CSIDL;
  if SUCCEEDED(SHGetSpecialFolderLocation(0, SystemFolder, pidl)) then
  begin
    SetLength(FolderPath, max_path);
    if SHGetPathFromIDList(pidl, PChar(FolderPath)) then
    begin
      SetLength(FolderPath, length(PChar(FolderPath)));
    end;
  end;
  Result := FolderPath; // <- Welchen Wert hat FolderPath wenn
                        // SUCCEEDED einen Fehler zurückgibt ???

  // Hier wird pidl nicht freigeben -> Funktion erzeugt Speicherleck

end;

Zitat:

Zitat von MSDN

ppidl
[out] A pointer to an item identifier list (PIDL) specifying the folder's location relative to the root of the namespace (the desktop). The calling application is responsible for freeing this pointer with the Shell's IMalloc interface (see SHGetMalloc).

Etwas besser wäre es so:

Delphi-Quellcode:

function GetShellFolder(CSIDL: integer): string;
var
  pidl                   : PItemIdList;
  FolderPath             : string;
  SystemFolder           : Integer;
  Malloc                 : IMalloc; // Interface für IMalloc
begin
  Malloc:=Nil;
  FolderPath:=''; // Initialisieren damit Result immer definiert ist
  SHGetMalloc(Malloc); // Interface holen damit am Ende pidl freigegeben werden kann
  If Malloc=Nil then
    begin
    Result:=FolderPath;
    Exit;
    end;
  Try
    SystemFolder := CSIDL;
    if SUCCEEDED(SHGetSpecialFolderLocation(0, SystemFolder, pidl)) then
    begin
      SetLength(FolderPath, max_path);
      if SHGetPathFromIDList(pidl, PChar(FolderPath)) then
      begin
        SetLength(FolderPath, length(PChar(FolderPath)));
      end;
    end;
    Result := FolderPath;
  Finally
    Malloc.Free(pidl); // Speicher freigeben
    end;
end;

Ich schreibe Artikel oder Tutorials wenn 100%tig weiss was ich schreibe. Deshalb habe ich noch nie einen Artikel oder ein Tutorial geschrieben.

[Luckie]

Oh besten Dank, ist mir irgendwie immer entgangen.

[Thanatos81]

Hi Luckie,

hab gerade ein kleines Tool geschrieben und konnte deine Funktion dabei gut gebrauchen. Beim erneuten Lesen deines Artikels ist mir ein Verbesserungsvorschlag gekommen, verlinke doch auf die MSDN und zwar auf "Shell Constants, Enumerations, and Flags".

Da findet der Leser gleich eine Liste der CSIDLs und kann sich die raussuchen die er benötigt.

Schönen Gruß,

[Nicolai1234]

@Luckie
Jetzt wollte ich mal einen deiner Artikel verlinken (hier) und dann ist der einfach weg :cry:
Bei den anderen Artikeln auf deiner Seite hat sich ja das Design ein bisschen verändert, aber diesen hier kann ich nirgends mehr finden.
Wäre schön, wenn du den wieder herstellen könntest :)

[Luckie]

Da ist er doch: http://www.michael-puff.de/Developer.../HOMEDIR.shtml

[Go2EITS]

Ich hätte zwei Vorschläge zu:
http://www.michael-puff.de/Developer.../HOMEDIR.shtml

a) ein Aufrufbeispiel wäre schön
und
b) die Konstantenliste und die Pfade, die man dazu bekommt.

Hier die KonstantenListe:

Delphi-Quellcode:

  CSIDL_DESKTOP                       = $0000;
  CSIDL_INTERNET                      = $0001;
  CSIDL_PROGRAMS                      = $0002;
  CSIDL_CONTROLS                      = $0003;
  CSIDL_PRINTERS                      = $0004;
  CSIDL_PERSONAL                      = $0005;
  CSIDL_FAVORITES                     = $0006;
  CSIDL_STARTUP                       = $0007;
  CSIDL_RECENT                        = $0008;
  CSIDL_SENDTO                        = $0009;
  CSIDL_BITBUCKET                     = $000a;
  CSIDL_STARTMENU                     = $000b;
  CSIDL_DESKTOPDIRECTORY              = $0010;
  CSIDL_DRIVES                        = $0011;
  CSIDL_NETWORK                       = $0012;
  CSIDL_NETHOOD                       = $0013;
  CSIDL_FONTS                         = $0014;
  CSIDL_TEMPLATES                     = $0015;
  CSIDL_COMMON_STARTMENU              = $0016;
  CSIDL_COMMON_PROGRAMS               = $0017;
  CSIDL_COMMON_STARTUP                = $0018;
  CSIDL_COMMON_DESKTOPDIRECTORY       = $0019;
  CSIDL_APPDATA                       = $001a;
  CSIDL_PRINTHOOD                     = $001b;
  CSIDL_ALTSTARTUP                = $001d;         // DBCS
  CSIDL_COMMON_ALTSTARTUP         = $001e;         // DBCS
  CSIDL_COMMON_FAVORITES          = $001f;
  CSIDL_INTERNET_CACHE            = $0020;
  CSIDL_COOKIES                   = $0021;
  CSIDL_HISTORY                   = $0022;

Zugegeben: Eigentlich sind die Bezeichnungen schon aussagekräftig genug.

Damit erübrigen sich dann einige Fragen in der DP sehr schnell.
Mit besten Grüßen
Go2EITS

[negaH]

Zitat:

Nun, Martin redet von Programmen, die sich ausschließlich in ihrem eigenen Ordner abspielen und da muss ich auch sagen, dass dies absolut praktisch ist. Es gibt nur ein Verzeichnis, welches es bei Bedarf zu packen/löschen/verschieben/kopieren gilt.

Beide Positionen haben etwas für sich - aus pragmatischer Sicht sehe ich dies ebenso wie Martin.

Dem kann ich nur zustimmen. Viel schlimmer noch:

1.) was wenn die Software selber die Benutzer verwalten muß und dazu in einer einzigsten Datei deren Passwörter etc. abspeichern möchte. Diese Datei kann man nicht für jeden Benutzer duplizieren da die Software Zugriff auf diese Einstelungen für alle Benutzer gmeinesam haben muß

2.) was ist wenn man die Software in einem Netzwerk installiert, aus administrativen Gründen der Fernwartung

3.) was ist wenn man die Software durch kopieren des Ordners packen, installieren, backupen will ? Muß man sich dann diese Benutzereinstelungen alle wieder verteilt auf den Rechnern zusammensuchen ?

4.) was ist wenn die Software Benutzerabhängig aber Computer-Unabhngig in einer Netzwerkinstalation arbeiten soll ? Dh. egal an welchem Rechner sich der Benutzer anmeldet wer findet immer seine individuellen Einstellungen vor.

5.) was ist wenn diese Konfigurationsdaten durch die eigene Sofware verändert werden müssen, aber Benutzer-Unabhängig weil es keine Benutzerdaten sind sondern global gültige Einstellungen ?

Ja, man könnte jetzt sagen dann installiere deine Netzwerk-Domäne richtig, was dann zwangsläufig einen Windows Server vorraussetzt. Funktioniert bei einfachen Netzwerken als Fileserver eben nicht mehr. Und wir haben wiederum das Problem das die Benutzereinstellungen auf dem Lokalen Computer gespeichert werden.

Ich preferiere immer noch das Speichern der Daten relativ zum Programpfad, wenn die Software eine eigene Userverwaltung benutzt oder eben gobale für alle Benutzer gültige Einstellungen speichern möchte.

Gruß Hagen

[Luckie]

@Go2EITS: Ich habe den Artikeln im MSDN verlinkt, es sollte also kein Problem sein weitere Informationen zu suchen.

@Hagen: Natürlich gibt es Situationen in denen es sinnvoll sein kann, nicht das %HOMEDIR% zu benutzen. Mein Artikel richtet sich in erster Linie an die Programmierer, die benutzerspezifische Einstellungen im Programmpfad abspeichern, sei es aus Bequemlichkeit oder Unwissenheit. Es ist genaus wie mit dem goto, es kann sinnvoll sein, muss aber nicht.

[negaH]

Ist ja auch korrekt so ;)

Wenn diese Benutzerdaten nicht gerade 10Mb Bilder sind so sollte man eigentlich die Registry nehmen. Mit TRegIniFile() oder TRegistry() stellt die VCL einen komfortablen Zugriff zur Verfügung. Besser als es dann umständlich nach Nutzern in eine INI Datei im Programmpfad abzulegen.

Meine Hinweise sind einfach Erfahrungswerte die ich sammeln durfte bei der Entwicklung kommerzieller Projekte. Multiuser, Netzwerklauffähigkeit und Computerunabhängige Anmeldungen sind dort ein muß. Bei solchen Projekten ist die Abspeicherung der Nutzerdaten so wie es MS vorgesehen hat ein absoluter Albtraum für jeden Fernwartungs-Admin.

Noch ein Tipp: Wenn man eh mit Datenbanken im Projekt arbeitet, eventuell sogar mit Server-Datenbanken, dann speichern wir viele Einstellung in dieser DB ab.

Gruß Hagen

[Luckie]

Jupp. Habe ich jetzt erst auch so gemacht bei einem Programm für die Firma. Da handelt es sich um globale Einstellungen für das Programm, die nur der Admin machen darf. Da wäre es Quatsch, diese Datei in das %HOMEDIR% des Benutzers zu legen.

[Hansa]

Zitat:

Zitat von negaH

Ich preferiere immer noch das Speichern der Daten relativ zum Programpfad, wenn die Software eine eigene Userverwaltung benutzt oder eben gobale für alle Benutzer gültige Einstellungen speichern möchte

Was meint ihr denn jetzt da ? Zwischen den Zeilen lese ich Kritik an M$. Viele hängen sich an einen vermeintlichen MS-"Standard" dran. Was ist mit den DAUs ? Wenn jemand weder weiß, was ein User ist und ihn nicht mal die Windows Version interessiert ? Würde mich mal interessieren.

[Luckie]

Ich lese da keine Kritik. Es ist wie mit dem Reisebus zum Einkaufen zu fahren. Praktischerweise nimmt man dazu den PKW, aber wer nichts anders kennt, nimmt eben seinen Reisebus. ;)

Man muss eben abwägen bzw. entscheiden, ob es benutzerspezifische Dten sind onder globale für alle Benutzer des Programmes, das der Administrator einmal einrichtet.

[negaH]

Gute Argument, mein Prinzip lautet:

Software preisgünstiger machen und dafür mehr Support leisten ;) Um so wichtiger wird der Supporter als Fernadministrator und die Möglichkeit der eigenen Software sehr leicht administriert zu werden. Vorteile sind:

1.) wir sind konkurrenzfähig im Preis
2.) wir verdienen an der Dienstleistung "Support"
3.) unsere Software lässt sich leichter administrieren unabhängig vom OS

4.) der Kunde hat einen preisgünstigen Einstieg in unsere Software
5.) der Kunde muß sich nicht ums System und unser Sofwtareadministration kümmern

Daraus ergeben sich konkrete Forderungen an die Softwareentwicklung und eine sehr wichtig ist: Schei. auf Microsofts Ideen wie sie meinen das die Benutzer ihre Daten zu speihcern haben. Das wird sich in den nächsten 5 Jahren mindestens noch 10 mal ändern und immer mehr widerspänstige Odrner und Icons werden den Anwender stören und uns Support kosten.
Da unsere Software eh Multiuserfähig ist, da sie eh Server Datenbanken benutzt und eh am besten im Netzwerk installiert wird oder als Terminalsession läuft, sind uns die Benutzerfolder ziemlich egal. Wir minimieren dadurch auch noch den administrativen Supportaufwand unserseits.

Klar ist aber auch das sich das alles ändern kann, denn es hängt von der Software und dem Vermarktungskonzept ab. Bei einem Freeware oder Shareware Tool sollte man natülich MS Vorgaben benutzen. Es lässt sich aber denoch stark bezweifeln ob der von MS eingeschlagene Weg wirklich so Nutzerfreundlich ist wie es die Marketingexperten uns weis machen wollen. Erst letztens habe ich WinXP zweimal installieren dürfen. Während des Setups liest man ja über die tollen neuen Features von denen ich gleich im Anschluß wieder 90% deaktiviert habe !!

Gruß Hagen

[Hansa]

Ist halt nicht so einfach, den M§-Standard einzuhalten. User ist 0 = Null = Nichts. Keinerlei Ahnung, also quasi Supper-GAU-DAU. :mrgreen: Was ist jetzt mit dem ? MS-Standard, oder zwinge ich ihn das Programm in meinen Zwangsordner zu kopieren ? :shock:

@roter Kasten : kommt meiner Einschätzung recht nahe ! Die Frage ist deshalb, was zu tun oder zu lassen ist.

[negaH]

@Hansa:

Wo ist denn dein Problem ? oder ich verstehe dich einfach nicht.

Was ich propagiere ist:

1.) je nach Anwendung und dem dahinterstehenden Marketing/Support wird man es entweder so machen wie es MS vorgibt oder aber zb. so machen wie wir in unseren großen Projekten

2.) aber es darf nicht so sein das MS sein OS so umbaut das man auch als Entwickler nicht mehr die Entscheidungsfreiheit hat es anders machen zu wollen als es MS vorgibt, bzw. meint wie es richtig wäre.

3.) und ich bezweifle das es so wie es jetzt ist wirklich benutzerfreundlich sein soll. Ich zb. benutze die f..k "Eigenen Dateien" überhaupt nicht. Gut, ich will sie nicht und es ist ein echter Krampf sie im Explorer raus zu bekommen. Bzw. genauer gesagt nicht auszublenden sondern nur das der Explorer sie nicht ständig öffnet sondern den letzten Zustand wieder herstellt. Ein kleines Feature mit viel Wirkung also, wenn es denn MS irgendwann mal schafft das zu integrieren. Naja, dürfte aber unwahrscheinlich sein, da ja bunte Gimmecks, transparante Fenster usw. wichtiger sind.

4.) hast du schon mal ein XP so konfiguriert das mehrere Hauptbenutzer zugriff auf alle installierten Programme haben und zudem noch alle Startmenu/Link Einträge mit einem Schlage eingerichtet werden können ?
Schätze nicht, denn sonst weis man auch das man an 100 verschiedenen Stellen irgendwas einstellen kann was an anderer Stelle negative Auswirkungen haben kann. Das man Stunden damit verbringt für 5 Benutzer deren Startmenus, Windowseinstellungen etc.pp. einzurichten. Da hilft auch nicht der sogennante "Default User".

Gruß Hagen

[Michael Habbe]

Mahlzeit miteinand,

Zitat:

Zitat von Luckie

Man muss eben abwägen bzw. entscheiden, ob es benutzerspezifische Dten sind onder globale für alle Benutzer des Programmes, das der Administrator einmal einrichtet.

diesen Satz hättest Du vieeeeel eher bringen müssen. Ich denke, die meisten haben gedacht, Du willst nur noch %HOMEDIR% benutzen und es somit falsch verstanden.

Hagen hat eigentlich alles zusammengefasst, was es mit benutzer- oder auch nicht-benutzer-abhängiger Speicherung aus sich hat.

Aber dies noch:

Zitat:

Zitat von negaH

3.) und ich bezweifle das es so wie es jetzt ist wirklich benutzerfreundlich sein soll. Ich zb. benutze die f..k "Eigenen Dateien" überhaupt nicht. Gut, ich will sie nicht und es ist ein echter Krampf sie im Explorer raus zu bekommen. Bzw. genauer gesagt nicht auszublenden sondern nur das der Explorer sie nicht ständig öffnet sondern den letzten Zustand wieder herstellt. Ein kleines Feature mit viel Wirkung also, wenn es denn MS irgendwann mal schafft das zu integrieren. Naja, dürfte aber unwahrscheinlich sein, da ja bunte Gimmecks, transparante Fenster usw. wichtiger sind.

Ich nutze sie auch nicht dafür, wofür M$ es mal gedacht hat. Dieses Verzeichnis wird von allen Programmen mit irgendwelchem Müll zugeschi..en, den man wirklich nicht braucht. Vor allem kann man sich nicht aussuchen, welches Programm wann das was reinschreibt (mag sein, dass man es bei manchen ändern kann).

Ich nutze die "Eigenen Dateien" mittlerweile zum Ablegen von Verknüpfungen zu allerei Verzeichnissen (gibt ja fast überall diese Schaltflächen links in den Dialogen). So kann man schnell von diesem in ein anderes Verzeichnis springen, um Daten zu laden bzw. speichern.

Die Ironie an der Sache: So bekommt dieses Verzeichnis doch noch seine Daseinsberechtigung. :gruebel:

mfg
Michael

[negaH]

Hm, du meinst das der Öffnen-Dialog ja sowieso immer auf Eigene Dateien zeigt und du dort als Links wichtige Ornder verlinkt hast. Jo das werde ich wohl so auch machen da es wirklich einen Vorteil bringt. Statt sich immer umständlich durch alles durchklicken zu müssen. Sehr gute Idee.

Übrigens lege mal einen Link auf den Desktop zu Explorer.exe
Öffne die Eigenschaften dieses Links und probiere mal folgende Einstellungen aus bei der Pfadangabe

explorer
explorer /e
explorer /e,
explorer /e, "d:\"

Gruß Hagen