XProfan X4 mit JSON-Unterstützung

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Information: Kostenloser Download! Alle Neuerungen des Creators Updates in einem Flipbook Schau gleich mal rein!

    • Michael Wodrich schrieb:

      Warum, macht man das in einer Datenbank anders? Da bekommst Du auch die ganze Datenbank.
      Json ist eigentlich auch nur zum Austausch gedacht.
      In jeder DB kann man satzweise zugreifen, sonst würde es ja auch
      keinen Sinn machen. Dann reicht ja auch eine einfache Textdatei,
      in der die Sätze aneinander gereiht sind. Die kann man auch wunderbar
      rausfriemeln.

      Also, für mich macht Json, mal abgesehen von der Austauschbarkeit,
      keinen Sinn. Da bleibe ich lieber bei einer DB oder speichere mir
      Strukturen, die ich mit eigenen Funktionen auslesen kann.
    • JSON ist kein Dartenbankersatz, sondern dient zum Datenaustausch, unter anderem auch mit Datenbanken.

      Und wenn man es richtig organisiert, kann man auch satzweise zugreifen. Etwa, indem man einen Datensatz zu einem Objekt macht und in eine Liste aus Objekten einfügt. So kann man nachher bequem über den Index auf die einzelnen Sätze zugreifen. (So werden z.B. auch mit den Datenbankbefehlen SQLExec, FBExec und SLExec die Selectergebnisse als JSON-Datei exportiert, wenn man im Modus 2 als SQLFile eine Datei mit der Endung JSON verwendet.)

      Gruß
      Roland
      Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD / ATI Radeon HD4770 512 MB / Windows 7(32) - XProfan X3
      AMD Athlon II X2 2,9 GHz / 3 GB RAM / 500 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X3


      http://www.xprofan.de
    • INI-Dateien sind auch gut, sogar besser geeignet.
      Damit hatte ich mal vor ein paar Jahren eine DB gemacht.
      Das ging ganz gut.

      Einfach eine Datei mit der Rubrik

      [Datensätze]
      Anzahl = 0


      und dann die Sätze numerieren :
      [1]
      Name = "..."
      Nummer = Str$(nummer)
      usw.
      [2]
      ........

      Dann einfach in einer WhileLoop Schleife schreiben bzw. lesen
      (WriteIni, ReadIni).
      Wenn es keine Tausende DS sind, geht das wunderbar.
    • Ich denke, daß Roland sowieso die Profile-Funktionen
      nutzt. Die werden nur mit WriteIni und ReadIni$ gekapselt.
      Wenn ich mal so ältere VB(A) - Codes anschaue, wird das
      dort auch schon mit ProfileString gemacht.

      Aber ich denke, daß Roland schon einen Grundstein
      gelegt hat. Er hat ja schon die HKEY_ - Klassen implementiert.
      Die werden bestimmt mit den Profile-Funktionen in die
      Registry geschrieben.

      Wäre vielleicht jetzt für X4 so eine Gelegenheit dafür,
      es mit den Profile-Funktionen umzuleiten, falls noch nicht
      geschehen.

      Das größere Problem ist, daß MS das irgendwann mal so ändert,
      daß nur noch in die Registry geschrieben werden kann.
    • Irgendwie verstehe ich deinen Beitrag nicht.
      Writeini und Readini$ greifen auf zwei unterschiedliche API Sätze zu - je nachdem, was als erster Parameter eingetrgen ist.

      1.Parameter Registry Hauptschlüssel in der Registry:
      1.Parameter Dateiname:
      Was soll da wie umgeleitet werden - und warum überhaupt????
      PPFScanner PPFS Android MisterXMail@web.de
      Mfg AHT

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von AHT ()

    • H.Brill schrieb:

      Das größere Problem ist, daß MS das irgendwann mal so ändert,
      daß nur noch in die Registry geschrieben werden kann.
      Warum sollte MS das tun? Ist doch eigentlich klar definiert, was MS macht:

      https://msdn.microsoft.com/en-us/library/windows/desktop/ms725501(v=vs.85).aspx schrieb:

      The system maps most .ini file references to the registry, using the mapping defined under the following registry key:HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows NT CurrentVersion IniFileMappingThis mapping is likely if an application modifies system-component initialization files, such as Control.ini, System.ini, and Winfile.ini. In this case, the function writes information to the registry, not to the initialization file; the change in the storage location has no effect on the function's behavior.
      Hinzu kommt dann PrivateProfile... für die heute gar nicht mehr existente WIN.INI.

      Es geht nur um die Windows-Einstellungen. Und nur um Kompatibilität zu alten 16-Bit-Programmen zu wahren. Betrifft ein 64-Bit-System gar nicht und ein 32-Bit-System nur soweit, wie 16-Bit-Anwendungen ausgeführt werden. Was da in VBA gemacht wurde, damit nicht jeder Office-Macro eine eigene INI-Datei erstellt, wenn er mal einen Wert ablegen will, ist dann wieder eine ganz andere Frage. habe ich nur der Vollständigkeit halber erwähnt, daß es sowas gibt.

      Gruß Volkmar