Hallo Besucher, der Thread wurde 11k mal aufgerufen und enthält 70 Antworten

letzter Beitrag von Phasengleich am

Project One - unexpected Error unter Windows 7

    Software, die nicht wenigstens optional auch "portable" zu machen ist, für Leute die es gerne portable haben wollen, gehört eigentlich nur noch geschlagen. Der Zwang zum Userverzeichnis ist eine Seuche nicht minder ätzend als die Registry.


    (z.B. mittels "wenn Konfigurationsdatei/INI/wasauchimmer im Programmverzeichnis gefunden wird, dann portable; wenn nicht, dann meinetwegen AppData" o.s.ä.)

    Zitat von Tale-X

    Bei den INIs hatte man dann seine (selbstgeschriebene) Klasse verwendet, wo man die zu speichernden Variablen registriert hat und dann via load- bzw. save-Methode geholt oder geschrieben hat

    So Im Sinne von "myIni.register(A$)", und bei Programmende wird das automatisch gespeichert? Kann ich mir in VB6 schwer vorstellen. Mit Objekten vielleicht, aber auch da bliebe die Frage, wann man wieder lädt.

    Zitat von syshack

    Ja, ja, grundsätzlich richtig..... In einer restriktiven Firmenumgebung ist das kaum anders lösbar...
    Trotzdem:
    Wieviel mal habe ich die an sich portable Applikationen wie z.B. "C64 Studio" gesichert als ganzes Verzeichnis und dann rumgespielt und die Settings vermurkst um dann festzustellen, dass die Einstellungen im %userprofil% drin waren und definitiv futsch waren....
    Da finde ich den Ansatz von http://www.portableapps.com besser, wo die Registry und %userprofile& virtualisiert im Programmverzeichnis liegen und damit auch wirklich portabel sind.

    Zitat von GenerationCBM

    Software, die nicht wenigstens optional auch "portable" zu machen ist, für Leute die es gerne portable haben wollen, gehört eigentlich nur noch geschlagen. Der Zwang zum Userverzeichnis ist eine Seuche nicht minder ätzend als die Registry.


    (z.B. mittels "wenn Konfigurationsdatei/INI/wasauchimmer im Programmverzeichnis gefunden wird, dann portable; wenn nicht, dann meinetwegen AppData" o.s.ä.)

    In den 20 Jahren seit Win95 sind schon so viele Schweine durchs Dorf getrieben worden, die dann auf der anderen Dorfseite gestorben sind - es wundert mich, dass XML nicht schon durch irgendwas noch beknackteres ersetzt wurde. Ini-Dateien, Registry, heute Appdata oder diese Syswow-Sache, die geänderte Dateien einspiegelt (ausser manchmal).


    Persönlich mag ich portable Apps, gerne auch mit einem Installer, der Dateiendungen registriert und Menüeinträge erstellt.
    In Photoline ist das so gelöst: Gibt es im Programmverzeichnis einen Ordner "Usersettings", dann wird der für alle Einstellungen verwendet, ansonsten halt Appdata oder was auch immer gerade auf dem OS hip ist. Wer gerne Appdata sichert, kann das tun, wer portabel arbeiten will kann das tun, und Schreibrechte auf das egentlich Programmverzeichnis muss man auch nicht geben.

    Ich schreibe den ganzen Tag neben SQL auch viel XML, weil ich damit für meine Kundenprojekte die ganzen Business- und ETL Prozesse in XML-Dateien für eine Engine von uns konfiguriere,
    deshalb bin ich etwas XML "geschädigt"...für mich gibt es nichts Einfacheres halt... :bgdev


    Zitat von Hoogo

    Persönlich mag ich portable Apps, gerne auch mit einem Installer, der Dateiendungen registriert und Menüeinträge erstellt.

    Das ist aber keine "Portable App" per se mehr, weil es Dein System verändert.
    Diese Explorer Hooks für die Kontextmenü Commands sind in der Registry abgelegt, ebenso die Verknüpfung der Datei-Extensions mit einem Programm.


    Wo man die Settings ablegen soll, kann man auch dem User überlassen:
    Bei der Installation der App eine kleine Settings-Datei MeineApp.ini im Programmverzeichnis, welche auf die eigentliche Settings-Datei verweist, also entweder im %userprofile%\AppData oder im Programmverzeichnis:
    AppSettingspath=%userprofile%\AppData\Roaming\MeineFirma\MeineApp\settings.ini
    oder
    AppSettingspath=settings.ini


    Ich habe hier mal INI gewählt, um Eure Aversion gegen XML nicht zu überstrapazieren... :rolleyes:

    Hoogo: ich bin in C++ unterwegs, da scheint man paar mehr Möglichkeiten zu haben (aber Referenzen sollte VB eigentlich auch kennen). Das Praktische beim Registrierungsansatz - Du kannst es beliebig ausbauen (individuelle Gültigkeitsbereiche, Hierarchien etc...).


    Noch ein kleiner Nachtrag, welche Daten ich ggf. direkt beim Programm speichere: das kundenspezifische Customizing (z.B. Definitionen für Bildschirmmasken und Logiken). Die sind beim Kunden Standard. Der Bearbeiter kann dann darauf basierend in einem engeren Rahmen seine Einstellungen vornehmen.

    Habe gerade herausgefunden das man Project One unter Windows 10 doch ans laufen bekommt mitlerweile und zwar darf man es nicht auf der C intallieren, einfach auf D oder woanders hin Installieren und dann als ADMIN starten und Tadaaaaaa es läuft wieder, habe es gerade durch zufall rausgefunden, nachdem ich mich nicht mit abfinden wollte das es nicht mehr läuft unter Win 10.


    Vielleicht hilft es jemanden.

    Habe es seit Monaten wieder zum Laufen gekriegt. Ich glaube eher, dass es an einem Windows 10 Patch/Update liegt, weil ich es früher am gleichen Ort nicht zum Laufen gekriegt hatte.