XE 2 Unit scope name

[bernhard_LA]

wenn ich meine Projekte sowohl unter Delphi XE2 als auch unter D 2010 oder sogar noch D7 kompilieren will komme ich um :

uses {$ifdef VER230} // compile with Delphi XE2
Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
Vcl.Controls, Vcl.Forms, Vcl.Dialogs
{$else} // use any old DELPHI compiler
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs,
{$endif}


wohl nicht herum ??????? oder ????

[DeddyH]

Kannst Du nicht Unit-Aliase festlegen?

[daywalker9]

Du kannst auch weiterhin die "normalen" Unitnamen nutzen.

Es ist kein Zwang die Unit-Scopes zu nutzen

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1122072)

Kannst Du nicht Unit-Aliase festlegen?

Besser geht das mit "Projektoptionen - Delphi-Compiler - Unit-Gültigkeitsbereichsnamen".

[DeddyH]

Kann ich nicht kennen, gibt es unter XE noch nicht ;)

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1122078)

Kann ich nicht kennen, gibt es unter XE noch nicht ;)

Dort hieß das noch "Standard-Namespace". Trägt man dort z.B. "Generics" ein, genügt in der uses dann ein einfaches "Collections".

[DeddyH]

Ach, dafür ist das. Danke für die Aufklärung.

[bernhard_LA]

ohne unit scope names kann ich nicht im x64 bit modus kompilieren ... ist das richtig so ?

[Uwe Raabe]

Zitat:

Zitat von bernhard_LA (Beitrag 1122083)

ohne unit scope names kann ich nicht im x64 bit modus kompilieren ... ist das richtig so ?

Das wäre mir jetzt neu. Soweit ich weiß, gibt es die Unit-Scope-Names eher wegen FireMonkey (VCL vs. FMX).

Grundsätzlich habe ich ja nichts gegen einen einmaligen Port, dafür wird es sicher bald auch Tools geben. Schwierig wird es nur, wenn man z.B. für Komponenten-Bibliotheken kompatibel zu den älteren Delphi-Versionen bleiben muss/will.

[mquadrat]

Zitat:

Zitat von daywalker9 (Beitrag 1122073)

Du kannst auch weiterhin die "normalen" Unitnamen nutzen.

Es ist kein Zwang die Unit-Scopes zu nutzen

Sicher? Bei einer alten Version der TMS hat XE2 DBTables nicht mehr akzeptiert

[mjustin]

Zitat:

Zitat von mquadrat (Beitrag 1122092)

Zitat:

Zitat von daywalker9 (Beitrag 1122073)

Du kannst auch weiterhin die "normalen" Unitnamen nutzen.

Es ist kein Zwang die Unit-Scopes zu nutzen

Sicher? Bei einer alten Version der TMS hat XE2 DBTables nicht mehr akzeptiert

DBTables liegt im Unit-Gültigkeitsbereichsnamen 'BDE', d.h. man kann BDE in den Projektoptionen angeben oder bei -NS;...;BDE;... bei Verwendung des Kommandozeilenkompilers. BDE wird zwar nicht mehr unterstützt, aber einige BDE Unitnamen sind noch in der XE2 Liste enthalten, die alle Units nach ihrem Unit-Gültigkeitsbereichsnamen getrennt aufführt:

http://docwiki.embarcadero.com/RADSt...sbereichsnamen

[daywalker9]

Zitat:

Zitat von mquadrat (Beitrag 1122092)

Zitat:

Zitat von daywalker9 (Beitrag 1122073)

Du kannst auch weiterhin die "normalen" Unitnamen nutzen.

Es ist kein Zwang die Unit-Scopes zu nutzen

Sicher? Bei einer alten Version der TMS hat XE2 DBTables nicht mehr akzeptiert

DBTables gibt es meines wissens für x64 aktuell nicht.

Im Pfad der DCUs von x64 ist die DCU dafür nicht vorhanden (C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\lib\win64)

//Edit:

Es kommt auch ein Fehler wenn BDE.DBTables eingebunden wird: "bde.dbtables.dcu not found (unit scope bde inidcates Win32 Only)

[Uwe Raabe]

Zitat:

Zitat von daywalker9 (Beitrag 1122137)

DBTables gibt es meines wissens für x64 aktuell nicht.

Genau, die BDE gibt es nicht für 64-Bit und daran wird sich wohl auch nichts ändern.

[bernhard_LA]

ich nehme mal an dass man hier eine Fehlermeldung bzw. unit scope names sieht :

[DCC Fataler Fehler] Project_numeric_toolbox.dpr(23): F2048 Falsches Unit-Format: '..\..\bin\unit_TIntegerList.dcu' - Erwartete Version: 23.0, Windows Unicode(x64) Gefundene Version: 23.0, Windows Unicode(x86)


bin am debuggen ...

[daywalker9]

Zitat:

Zitat von bernhard_LA (Beitrag 1125483)

ich nehme mal an dass man hier eine Fehlermeldung bzw. unit scope names sieht :

[DCC Fataler Fehler] Project_numeric_toolbox.dpr(23): F2048 Falsches Unit-Format: '..\..\bin\unit_TIntegerList.dcu' - Erwartete Version: 23.0, Windows Unicode(x64) Gefundene Version: 23.0, Windows Unicode(x86)


bin am debuggen ...

Nein, Du hast die Platform gewechselt und legst die DCUs im gleichen Verzeichnis ab. Die DCUs unterscheiden sich von der Platform her.

Einfach neu erzeugen und dann funktioniert das wieder.

Ggf. die DCUs mit Platzhaltern wie $PLATFORM (bin mir grade nicht sicher) definieren.

[Uwe Raabe]

Zitat:

Zitat von bernhard_LA (Beitrag 1125483)

ich nehme mal an dass man hier eine Fehlermeldung bzw. unit scope names sieht :

[DCC Fataler Fehler] Project_numeric_toolbox.dpr(23): F2048 Falsches Unit-Format: '..\..\bin\unit_TIntegerList.dcu' - Erwartete Version: 23.0, Windows Unicode(x64) Gefundene Version: 23.0, Windows Unicode(x86)

Ich vermute eher, daß da eine 32-Bit DCU vom 64-Bit Compiler gefunden wird.

[RWarnecke]

Zitat:

Zitat von bernhard_LA (Beitrag 1125483)

ich nehme mal an dass man hier eine Fehlermeldung bzw. unit scope names sieht :

[DCC Fataler Fehler] Project_numeric_toolbox.dpr(23): F2048 Falsches Unit-Format: '..\..\bin\unit_TIntegerList.dcu' - Erwartete Version: 23.0, Windows Unicode(x64) Gefundene Version: 23.0, Windows Unicode(x86)

Das Problem sollte bei neuen Projekten eigentlich gar nicht auftreten, da in der Grundeinstellung für die EXE und die DCU-Dateien immer $(Config)\$(Platform) steht. Wird die Ausgabe für die DCU-Dateien sauber getrennt, so trat bis jetzt bei mir die Fehlermeldung nicht mehr auf.
Desweiteren stelle ich bei alle alten Units auf die neue Namenskonvention um, die ich unter XE2 benutze. Damit habe ich bis jetzt diese Fehlermeldung nicht mehr erhalten.

[daywalker9]

Die Meldung sieht aber nicht nach einem neuen Projekt aus, oder er hat die DCU-Pfade selber geändert bei dem neuen Projekt.

[bernhard_LA]

ich bin am konvertieren von 30 projekten, bisher landeten alle *.dcu immer im \Bin Folder wie auch die *.exe solange die Entwicklung noch nicht abgeschlossen ist.

[Uwe Raabe]

Zitat:

Zitat von bernhard_LA (Beitrag 1125523)

ich bin am konvertieren von 30 projekten, bisher landeten alle *.dcu immer im \Bin Folder wie auch die *.exe solange die Entwicklung noch nicht abgeschlossen ist.

Entweder du stellst dann für 64-Bit einen anderen DCU-Pfad ein oder du löscht alle DCU-Dateien beim Wechsel der Plattform.

Wenn du die Exe immer an einer bestimmten Stelle brauchst, kannst du das natürlich machen, aber die DCU-Dateien würde ich plattformabhängig in unterschiedlichen Verzeichnissen ablegen.

[RWarnecke]

Zitat:

Zitat von Uwe Raabe (Beitrag 1125539)

Zitat:

Zitat von bernhard_LA (Beitrag 1125523)

ich bin am konvertieren von 30 projekten, bisher landeten alle *.dcu immer im \Bin Folder wie auch die *.exe solange die Entwicklung noch nicht abgeschlossen ist.

Entweder du stellst dann für 64-Bit einen anderen DCU-Pfad ein oder du löscht alle DCU-Dateien beim Wechsel der Plattform.

Wenn du die Exe immer an einer bestimmten Stelle brauchst, kannst du das natürlich machen, aber die DCU-Dateien würde ich plattformabhängig in unterschiedlichen Verzeichnissen ablegen.

Ich würde sogar noch ein STück weitergehen und das Build und die DCU Dateien nach der Plattform aufteilen. Da für die EXE kein extra Name oder ein Präfix vergeben werden kann, wenn man für mehrere Plattformen kompilieren will.

[Borck]

Zitat:

Zitat von bernhard_LA (Beitrag 1125483)

ich nehme mal an dass man hier eine Fehlermeldung bzw. unit scope names sieht :

[DCC Fataler Fehler] Project_numeric_toolbox.dpr(23): F2048 Falsches Unit-Format: '..\..\bin\unit_TIntegerList.dcu' - Erwartete Version: 23.0, Windows Unicode(x64) Gefundene Version: 23.0, Windows Unicode(x86)


bin am debuggen ...

Ich HATTE das selbe Problem und die Ursache bei mir war eine fehlerhafte Konfiguration das Rad Studios. Genauer hat sich die Priorität der Pfade für die 32bit Bibliothek vorab falsch eingestellt. Unter diesen Pfaden hat sich ein Pfad zu der 64bit-Bibliothek eingeschlichen welcher vor dem Pfad der 32bit Version stand. Dadurch fand der Compiler die 64bit Version der DCU-Datei vor der 32Bit Version und hat diese fälschlicherweise verwendet.

Lösung des Problems:

• Klicks auf: Tools->Optionen->Umgebungsvariablen->Delphi-Optionen->Bibliothek
• Wichtig ist nun das unter "Ausgewählte Platform" die "32-Bit-Windows"-Platform ausgewählt ist.
• Nun auf den Button "..." am Ende der Zeile "Bibliothekspfad" klicken.
• Im folgenden Fenster befindet sich ein Pfad Names: "<jcl_installs>\lib\d16\win64" wobei "<jcl_installs>" den Pfad zu den Installationsdateien der JCL darstellt.
• Dieser Pfad muss entweder:

• gelöscht oder
• per Pfeil-Buttons unter den Pfad "<jcl_installs>\lib\d16\win32" verschoben werden.

Hinweis: Die Lösung des Problems kann in deinem Fall etwas abweichen. Grundsätzlich musst du aber darauf achten das der Pfad zur 32bit Version der Datei vor dem der 64bit Version kommt.

lg Borck :wink:

[Insider2004]

Einfache Lösung: Lass deine Sourcen und die IDE-Einstellungen wie sie sind. Delphi XE2 ist abwärtskompatibel. Die Scopes kann man nutzen, man muss aber nicht. Ich übersetze mein Projekt mit D7 und DXE2. Ohne eine Änderung.