System.JSON System enthält kein Element names JSON (XE8))

[leonreiser]

Zitat:

Zitat von Uwe Raabe (Beitrag 1352448)

Das liegt aber daran, daß diese Units in XE8 eben nicht vorhanden sind. Die sind erst mit Seattle dazugekommen.

Okay, hier liegt anscheinend der Hund begraben.
Mein nächster Versuch war nun alle System.JSON.* Dateien aus dem Ordner
C:\Program Files (x86)\Embarcadero\Studio\16.0\lib\win32\release meines Kollegen in meinen zu kopieren.
Da sind unter anderem auch
System.JSON.Writers.dcu
System.JSON.Builders.dcu
und
System.JSON.Writers.dcu
dabei.
Hat jedoch wie erwartet nicht so einfach geklappt.
Gibt es da trotzdem eine Möglichkeit. Muss ich villeicht noch was in der Registry, oder in irgendeinem
INI File was verändern, oder ist das ganze sowieso unmöglich weil XE8 nicht damit umgehen kann
(oder was auch immer)?

[himitsu]

Das klappt natürlich nicht.

DCUs sind compilerabhängig.
DCUs aus XE10.1 werden niemals in XE8 funktionieren können.
Abgesehn davon bauen diese Kompilate (DCUs) auf andere Units auf, bzw. hängen davon ab, die im XE8 ganz anders sind, als in XE10.


Lösung: Schau, wo und in welchen Units im X8 die JSON-Komponenten drin sind (Dateisuche und/oder in der OH suchen)
Oder verwende die JSON-Komponente eines anderen Herstellers.

[leonreiser]

Zitat:

Zitat von himitsu (Beitrag 1352458)

Das klappt natürlich nicht.
Lösung: Schau, wo und in welchen Units im X8 die JSON-Komponenten drin sind (Dateisuche und/oder in der OH suchen)
Oder verwende die JSON-Komponente eines anderen Herstellers.

Und wenn ich dann herausgefunden habe, in welchen Units die JSON-Komponenten sind, dann füge ich die als
Unit dem Projekt hinzu und dann kann ich sie verwenden ,oder wie ist das gemeint?
JSON-Komponente eines anderen Herstellers geht leider nicht, da wir durch das Projekt an diese Komponente gebunden
sind.

[bra]

Zitat:

Zitat von leonreiser (Beitrag 1352460)

Und wenn ich dann herausgefunden habe, in welchen Units die JSON-Komponenten sind, dann füge ich die als
Unit dem Projekt hinzu und dann kann ich sie verwenden ,oder wie ist das gemeint?
JSON-Komponente eines anderen Herstellers geht leider nicht, da wir durch das Projekt an diese Komponente gebunden
sind.

Warum willst du unbedingt die JSON-Komponente von Berlin in XE8 verwenden? Das wird vermutlich nicht ohne größeren Aufwand funktionieren. Nimm doch die bei XE8 enthalten JSON-Komponente und verwende sie entsprechend der Hilfe von XE8.

[leonreiser]

Oke, dann muss ich wohl einsehen, dass das so nicht funktionieren wird.

Zitat:

Zitat von bra (Beitrag 1352462)

Warum willst du unbedingt die JSON-Komponente von Berlin in XE8 verwenden? Das wird vermutlich nicht ohne größeren Aufwand funktionieren. Nimm doch die bei XE8 enthalten JSON-Komponente und verwende sie entsprechend der Hilfe von XE8.

Mir selbst ist der Hersteller der Komponente eigentlich total egal, besonders weil ich garnicht damit arbeite.
Aber das derzeitige Projekt, an dem ich etwas ändern soll, benutzt eben diese Komponente und ich kann das Programm nicht testen/compilieren, da
ich den entsprechenden Part zwar auskommentieren kann(um das Projekt kompilierbar zu machen), dieser jedoch maßgeblich zur Funktionalität beiträgt.

Aber naja, da kann man dann wohl wenig machen.
Trotzdem Danke an alle, für die schnelle Hilfe.

[himitsu]

In diesem Fall halt ins Uses 'nen IFDEF rein.

Delphi-Quellcode:

user AndereUnits, {$IFDEF VER290} XE8Units {$ELSE} XE10Units {$ENDIF};

Aber ich bin mehr für Größer/Kleiner-Vergleiche oder besser noch für sprechende Bezeichner.

Delphi-Quellcode:

user AndereUnits, {$IF CompilerVersion <= 290} XE8Units {$ELSE} XE10Units {$ENDIF};

Delphi-Quellcode:

user AndereUnits, {$IF CompilerVersion <= DelphiXE8} XE8Units {$ELSE} XE10Units {$ENDIF};

Delphi-Quellcode:

user AndereUnits, {$IFDEF DelphiXE8AndLower} XE8Units {$ELSE} XE10Units {$ENDIF};

Letzte Beiden geht leider nur mit Fremdcode, da Delphi diesbezüglich keine sprechenden DEFINES bereitstellt.

[leonreiser]

Zitat:

Zitat von himitsu (Beitrag 1352467)

In diesem Fall halt ins Uses 'nen IFDEF rein.

Delphi-Quellcode:

user AndereUnits, {$IFDEF VER290} XE8Units {$ELSE} XE10Units {$ENDIF};

Aber ich bin mehr für Größer/Kleiner-Vergleiche oder besser noch für sprechende Bezeichner.

Delphi-Quellcode:

user AndereUnits, {$IF CompilerVersion <= 290} XE8Units {$ELSE} XE10Units {$ENDIF};

Delphi-Quellcode:

user AndereUnits, {$IF CompilerVersion <= DelphiXE8} XE8Units {$ELSE} XE10Units {$ENDIF};

Delphi-Quellcode:

user AndereUnits, {$IFDEF DelphiXE8AndLower} XE8Units {$ELSE} XE10Units {$ENDIF};

Letzte Beiden geht leider nur mit Fremdcode, da Delphi diesbezüglich keine sprechenden DEFINES bereitstellt.

Ähm ist mit user jetzt uses gemeint?

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1352467)

Aber ich bin mehr für Größer/Kleiner-Vergleiche oder besser noch für sprechende Bezeichner.

Delphi-Quellcode:

user AndereUnits, {$IF CompilerVersion <= 290} XE8Units {$ELSE} XE10Units {$ENDIF};

Delphi-Quellcode:

user AndereUnits, {$IF CompilerVersion <= DelphiXE8} XE8Units {$ELSE} XE10Units {$ENDIF};

Delphi-Quellcode:

user AndereUnits, {$IFDEF DelphiXE8AndLower} XE8Units {$ELSE} XE10Units {$ENDIF};

Letzte Beiden geht leider nur mit Fremdcode, da Delphi diesbezüglich keine sprechenden DEFINES bereitstellt.

Wie sollte ein Compiler für XE7 oder vorher, bei dem CompilerVersion < 290 ist, denn ein Define für DelphiXE8 oder DelphiXE8AndLower bereitstellen? Der aktuelle Compiler kann ja auch nicht wissen, wie die Version in drei Jahren heißen wird.

Alternativ kann man aber die fehlenden Units auch einfach als leere Dummy-Units anlegen. Dann ist der Compiler auch zufrieden und man spart sich die IFDEFS. (Habe ich schon erwähnt, daß IFDEFs in uses-Anweisungen eine Erfindung des Teufels :twisted: sind?)

Man kann auch für die fehlenden Units Unit-Aliase im XE8-Projekt anlegen, die dann alle auf System.JSON verweisen.

[himitsu]

Nee, das nicht, aber man kann problemlos die "Versionskonstanten" der nächsten 2, 3, 4 oder mehr Jahre vorbelegen
und zwar entweder eine Nummer größer als man selber oder besser noch mit einer ganz großen Nummer wie z.B. 666.0 :oops:

Alles was größer ist als ich muß ich nicht ganz genau kennen ... es ist so oder so immer größer und um wie viel größer ist eigentlich egal.

Man könnte auch bestimmte Versionsnummern erraten, aber das geht dann schief, wenn mal wieder jemand da dran rumspielt.
Zwischennummern für Majorversionen oder Versionen überspringen, wie es zweimal mit Version 13 gemacht wurde.
Delphi 10.3 wird vermutlich Compilerversion 33.0 und Produktversion 26.0, bzw. IDE-Version 20.0, da die 10.1 eine 31.0/24.0/18.0 ist.
Aber Delphi 2009 war Produktversion 12.0 und 2010ist eine 14.0, weil man Angst vor der 13 hatte.
Oder auch XE8 zu DX10, bzw. Windows 8 und Windows 10 ....


Das einzige Problem ist dabei nur, wenn man auf die geile Idee kommt und das Benamungsschema ständig ändert.

Aber Emba kann auch einfach seine Möglichkeiten nutzen und soeine Editions-Liste/Unit in die Versionsverwaltung legen, welche auch ältere Delphis als "Update" bekommen könnten. (GetIt, bzw. Git/SVN, wo auch schon die Demos liegen)

[jaenicke]

Man braucht doch gar keine Versionskonstanten für zukünftige Versionen, es würde ja reichen, wenn so etwas ginge:

Delphi-Quellcode:

{$IFDEF DelphiXE8OrHigher}
...