LV-Applikationen erstellen die VISTA kompatibel sind

Danke Rolf,

' schrieb:VISTA könnte da noch eine extra Sicherheit haben und einer Applikation nur diese Extrabehandlung zukommen lassen wenn sie ein INI File im selben Directory anpassen will als die Applikation selber ist.

Ist vermutlich nicht so, da eine dieser Applikationen in c:Programme seine INI-Datei in c:windows ablegt. Diese befindet sich nun auch in c:user...VirtualStoreWindows.

' schrieb:Windows hat dafür auch ein spezielles API GetPrivatProfile....() and friends (die automatisch die INI Datei der Applikation anspricht). Ich gehe mal davon aus dass VirutalStore nicht ein Mechansimus ist der auf File API Niveau ausgeführt wird sondern auf oben genannten API and friends. LabVIEW verwendet aber für die INI File VIs nicht dieses API sondern implementiert dies auf den normalen File IO Primitives. Etwas anderes wäre im Sinne der Multiplatformkompatibilität der INI file VIs auch nicht möglich, da die PrivateProfile APIs kein arbiträres INI File zulassen sondern immer nur das Applikations INI File ansprechen (exename mit path und mit der exe Endung in ini umbenannt).

Das habe ich auch schon auf lavag.org von dir gelesen, ich will es einfach nicht glauben

Wenn ich extra eine VISTA kompatible LV-IDE einsetzen muss (LV8.2) erwarte ich auch von dieser, das diese mit dem OS zurechtkommt. Da hätte ich auch bei lv_71 bleiben können, nur das diese eben angeblich nicht mehr auf VISTA läuft.
Na gut, dann werde ich mich mal mit den "API's and friends" rumschlagen, und schauen, ob es damit geht.
Das mindeste was ich nun von NI erwarte, dass diese API's zum Download bereitgestellt werden.

Oder kann ich diese von der LabVIEW.exe via CLF-Node aufrufen?

' schrieb:Etwas anderes wäre im Sinne der Multiplatformkompatibilität der INI file VIs auch nicht möglich, da die PrivateProfile APIs kein arbiträres INI File zulassen sondern immer nur das Applikations INI File ansprechen (exename mit path und mit der exe Endung in ini umbenannt).

Windows VISTA wäre auch ein OS in einer Plattform

' schrieb:PS: wenn ich mich nicht irre wird die standard Behandlung des INI Files für die LabVIEW eigene INI schon beachtet da LabVIEW dafür die GetPrivatProfileAPI verwendet.

Das wird wohl das "VISTA kompatibel" sein, mehr nicht
Das nützt mir in der eigenen LV-App. aber leider nichts, zudem habe ich LV in c:NILabVIEW installiert. Es wird damit einfacher die LV-IDE anzupassen, nur eine LabVIEW.ini für mehrere Benutzer, VI.lib und User.lib zu ergänzen usw.

Anzeige

' schrieb:Danke Rolf,
Das habe ich auch schon auf lavag.org von dir gelesen, ich will es einfach nicht glauben

Es ist aber so. Es macht einfach keinen Sinn und wäre sogar tödlich wenn VirtualStore auf Win32 File API Niveau ausgeführt würde. Das würde jeglichen Zugriff auf Files innerhalb des Applikationsdirectories für nicht Administratoren unmöglich machen.

Zitat:Wenn ich extra eine VISTA kompatible LV-IDE einsetzen muss (LV8.2) erwarte ich auch von dieser, das diese mit dem OS zurechtkommt. Da hätte ich auch bei lv_71 bleiben können, nur das diese eben angeblich nicht mehr auf VISTA läuft.

Vista Kompatibilität hat ganz andere Dinge als die "Unterstützung" der Virtual Store zum Ziel.lv71kann durchaus als Applikation auf Vista laufen wenn man den aufpasst wo man Files in der eigenen Applikation hinpflanzt, aber da gibt es gewisse Dinge mit Netzwerk, User Berechtigungen usw. die eben komisch oder gar nicht mehr laufen wenn man es nicht genau so macht wie MS sich das für Vista ausgedacht hat.

Zitat:Na gut, dann werde ich mich mal mit den "API's and friends" rumschlagen, und schauen, ob es damit geht.
Das mindeste was ich nun von NI erwarte, dass diese API's zum Download bereitgestellt werden.

Oder kann ich diese von der LabVIEW.exe via CLF-Node aufrufen?

Natürlich. Sind ganz normale Windows APIs, warum sollte da die CLF Node nicht funktionieren?

Zitat:Windows VISTA wäre auch ein OS in einer Plattform

Nein Windows Vista is architekturmässig noch immer ganz einfach ein NT Kernel. Nur sind viele APIs so kastriert worden dass man sie plötzlich auf früher ganz gültige Weise nicht mehr benützen kann.

Zitat:Das nützt mir in der eigenen LV-App. aber leider nichts, zudem habe ich LV in c:NILabVIEW installiert. Es wird damit einfacher die LV-IDE anzupassen, nur eine LabVIEW.ini für mehrere Benutzer, VI.lib und User.lib zu ergänzen usw.

Na dann geht PrivateProfileString eventuel so oder so in die Hose. Das ist kein Vista sanktionierter Installationspfad für Applikationen.

Rolf Kalbermatter

' schrieb:Natürlich. Sind ganz normale Windows APIs, warum sollte da die CLF Node nicht funktionieren?

Ich meinte, da NI das ja braucht für das LabVIEW.INI, könnten sie es den Anwendern auch zur Verfügung stellen. (CLF mit LabVIEW.EXE anstelle von Kernel32.dll)
GetPrivateProfile ist relativ schlecht dokumentiert auf MSDN, jedenfalls für win32, oder ich finde es nicht. Die Rückgabewerte fehlen mir.
Mit .NET wäre auch noch eine Möglichkeit.

' schrieb:Na dann geht PrivateProfileString eventuel so oder so in die Hose. Das ist kein Vista sanktionierter Installationspfad für Applikationen.

Daran habe ich gar nicht gedacht, habe nun wieder alles "richtig" installiert.

Gibt es eigentlich von NI eine Richtlinie, wie eine eigene LV-Applikation organisiert werden muss?
Wohin EXE, wo Supportdateien, wo Programmeinstellungen, wo Benutzereinstellungen usw. Registry (wo) oder weiterhin INI

Ich mache das noch so wie immer, alles in den Applikations Ordner, das geht so scheinbar nicht mehr mit den LV-EXE's. (fremde C-Programme schon)

Die Programm Einstellungen als INI-Datei werde ich nun ändern nach LOCAL_APPDATA , bei VISTA c:user<username>AppDataLocal
Somit hätte ich Problem1 gelöst, das ein nicht Admin auch seine Einstellungen speichern kann.

Macht Ihr das auch so?

Nun noch das Problem2:

Die fremde Applikation, hat sein EXE und sein INI in c:Programme. Wenn ein nicht Admin nun das Programm startet und Einstellungen schreibt oder liest, nimmt es die Datei vom VirtualStore.
(genau das möchte ich ja für die LV-EXE auch haben, geht aber nicht, wie Rolf geschrieben hat)

So, nun habe ich das lesen der fremd-INI in LV mit GetPrivateProfileString versucht. LV liest aber von der INI in c:programme.
Irgendwie weis die fremde Applikation, das sie nicht mehr im c:programme lesen soll.
Das müsste meine LV-App auch wissen.

Ob das mit WritePrivateProfileString nun die Datei von VirtualStore schreiben würde kann ich noch testen, aber diese Funktion brauche ich gar nicht.

So, nun brauch ich ein

Danke und Gruss
RoLe

' schrieb:Ich meinte, da NI das ja braucht für das LabVIEW.INI, könnten sie es den Anwendern auch zur Verfügung stellen. (CLF mit LabVIEW.EXE anstelle von Kernel32.dll)
GetPrivateProfile ist relativ schlecht dokumentiert auf MSDN, jedenfalls für win32, oder ich finde es nicht. Die Rückgabewerte fehlen mir.

Das interne API scheint nicht durch LabVIEW exportiert zu werden in einer Weise die durch die CLN zugänglich ist. Und es ist ganz simpel ein Wrapper um GetPrivateProfileString.

GetPrivateProfileString ist recht gut dokumentiert on MSDN aber mit dem Kommentar dass man das nicht mehr verwenden sollte . Aber ich weiss nicht was für einen Hokus Pokus es machen könnte. Eventuel ist die Umleitung in den Virtual Store abhängig von der Mondstellung oder funktioniert nur wenn die Applikation ein File innerhalb des eigenen Applikationsdirectories ansprechen will.

Rolf Kalbermatter

Anzeige

' schrieb:GetPrivateProfileString ist recht gut dokumentiert on MSDN aber mit dem Kommentar dass man das nicht mehr verwenden sollte . Aber ich weiss nicht was für einen Hokus Pokus es machen könnte. Eventuel ist die Umleitung in den Virtual Store abhängig von der Mondstellung oder funktioniert nur wenn die Applikation ein File innerhalb des eigenen Applikationsdirectories ansprechen will.

Danke Rolf,
heute habe ich die Doku auf MSDN beim ersten Klick gefunden, gestern eben nicht. Ist doch recht gut beschrieben, wenn man es findet.
Aber, die goldene Lösung ist es nicht, und wie du gesagt hast, veraltet.

Ich denke, ich gebe hier auf, und mache es einfach das es irgendwie geht, und bei Windows7 ändere ich wieder und bei Windows8, usw.
Wenn ich noch was finde, werde ich das hier posten.

Danke an alle Helfer und Leser
Gruss
RoLe

Wenn das möglich ist, kann man das externe Program nicht unter c:/Programme installieren, sondern in irgendeinen anderen Ordner installieren. Dann macht Vista nicht mehr mit den ini-Dateien rum und alle User bekommen die gleiche Datei.

' schrieb:Wenn das möglich ist, kann man das externe Program nicht unter c:/Programme installieren, sondern in irgendeinen anderen Ordner installieren. Dann macht Vista nicht mehr mit den ini-Dateien rum und alle User bekommen die gleiche Datei.

Danke RxT, das ist mir soweit klar, und vermutlich die einfachste Lösung.
Ich will ja, das die LV-EXE mit den INI-Dateien rummacht, nur erreiche ich das nicht.

Gruss
RoLe

' schrieb:Danke RxT, das ist mir soweit klar, und vermutlich die einfachste Lösung.
Ich will ja, das die LV-EXE mit den INI-Dateien rummacht, nur erreiche ich das nicht.

Gruss
RoLe

Das ist die letzte und authorative Weisheit auf diesem Gebiet von einem der es wissen muss. Adam Kemp arbeitet bei NI in Austin im LabVIEW Team. Kam heute in der Info-LabVIEW mailingliste:

' schrieb:LabVIEW does explicitly turn off the virtual store, and I believe LabVIEW apps do the same. To change that you can use Microsoft tools to write a new manifest into your LabVIEW-built applications.

Sadly, LabVIEW also currently makes its install directory world-writeable, so we do still put our .ini file right next to the .exe.

As for the Get System Directories feature, I can't comment on when or if any specific feature will be available in future versions of LabVIEW. For current versions of LabVIEW, there are multiple 3rd party VI libraries to do this.

Rolf Kalbermatter