Delphi 12 ist offiziell da!!!

[blawen]

Zitat:

Zitat von himitsu (Beitrag 1529651)

Jupp, mittags war ich mal kurz drin,
vorhin dann kurz das Andere und nun wieder des Bekannte

Zitat:

Sorry, an error occurred trying to log you in - please try again.

Hatte kurz gesehn, dass es bei einem meiner BugReports eine Rückfrage gab, vor 2 Tagen ... nur beantworten kann ich's nun nicht mehr

Kann es sein, dass ein "lokales" Problem ist? Bei mir funktioniert der Zugriff aktuell ohne Probleme.

[jaenicke]

Zitat:

Zitat von HRolle (Beitrag 1529647)

Die auf dieser Seite aufgeführten Clients stehen nur als .vsix-Dateien (oder NuGet-Pakete) zur Integration in diverse VS-Versionen zur Verfügung. Siehe https://www.visualsvn.com/downloads/

Das stimmt nicht:
Anhang 56451

Interessanterweise liegt in dem separaten Zip mit dem Client zusätzlich die Datei libsvn_fs_x-1.dll, die im Serververzeichnis fehlt. Die tut aber nichts zur Sache. Aber kann es sein, dass du den Server schlicht als 64-Bit Version installiert hast? Die kannst du dann mit einem 32-Bit Programm wie der Delphi IDE natürlich nicht nutzen.

[HRolle]

Zitat:

Zitat von jaenicke (Beitrag 1529653)

Interessanterweise liegt in dem separaten Zip mit dem Client zusätzlich die Datei libsvn_fs_x-1.dll, die im Serververzeichnis fehlt. Die tut aber nichts zur Sache. Aber kann es sein, dass du den Server schlicht als 64-Bit Version installiert hast? Die kannst du dann mit einem 32-Bit Programm wie der Delphi IDE natürlich nicht nutzen.

Wenn ich mich recht entsinne, hat mir die Trialversion von Delphi 12 genau die von Dir genannte Datei als fehlend gemeldet.

Ich habe einen 64-Bit-Rechner, ein 64-Bit-Windows und alle wichtigen Programme, die ich installiert habe (außer Delphi CE11) sind 64-Bit-Programme. Wenn Delphi damit nicht in jedem Fall zurechtkommt, muss ich wohl oder übel warten, bis auch Delphi ein 64-Bit-Programm ist. Das wird hoffentlich nicht lange dauern, Lazarus gibt es ja auch als 64-Bit-Programm. Bis dahin...

[himitsu]

Bei Lazarus werden die Fremdkomponenten doch immernoch einkompiliert?

Für Delphi hängt es vor allem an den vorkompilierten DesigntimePackages, welche es nur als 32 Bit gibt.

[jaenicke]

Zitat:

Zitat von HRolle (Beitrag 1529656)

Ich habe einen 64-Bit-Rechner, ein 64-Bit-Windows und alle wichtigen Programme, die ich installiert habe (außer Delphi CE11) sind 64-Bit-Programme. Wenn Delphi damit nicht in jedem Fall zurechtkommt, muss ich wohl oder übel warten, bis auch Delphi ein 64-Bit-Programm ist. Das wird hoffentlich nicht lange dauern, Lazarus gibt es ja auch als 64-Bit-Programm. Bis dahin...

Wo liegt denn das Problem? Du brauchst doch einfach nur das Zip aus dem ersten Download bei VisualSVN an eine beliebige Stelle entpacken und Delphi auf dieses Bin-Verzeichnis konfigurieren. Welchen SVN-Server du dann installierst, hat damit dann nichts zu tun.

Delphi wird auf absehbare Zeit bei 32-Bit bleiben, denn abgesehen von der IDE selbst gehören dazu ja noch Unmengen an Komponenten, Experten usw., die alle für 64-Bit implementiert werden müssten.

[omnibrain]

Nachdem es im "What's new" Webinar bis jetzt nur um C++Builder geht: Ist eigentlich bekannt wie das Nutzerverhältnis von C++Builder zu Delphi ist?
"Draußen" trifft man doch ab und zu mal jemanden der noch Delphi macht oder mal gemacht hat. Aber ich kenne niemanden der C++ Builder nutzt oder genutzt hat.

[Lemmy]

ich kenne eine Firma die mit c++ Builder arbeitet, aber was sagt das schon.
Ich finde es nicht verkehrt, wenn Emba sich auch um die anderen Tools kümmert - und wenn ich ehrlich bin: Den Visual Assist für Delphi fände ich geil...
Wenn der halt für c++ einfach einzubinden ist, fällt da vielleicht auch mal für uns was ab...

[HRolle]

Zitat:

Zitat von jaenicke (Beitrag 1529659)

Wo liegt denn das Problem? Du brauchst doch einfach nur das Zip aus dem ersten Download bei VisualSVN an eine beliebige Stelle entpacken und Delphi auf dieses Bin-Verzeichnis konfigurieren. Welchen SVN-Server du dann installierst, hat damit dann nichts zu tun.

Ich habe alles so gemacht, wie Du geschrieben hast. Beim Versuch, ein simples Beispielprojekt unter Versionskontrolle zu stellen, kam der Fehler: "193 %1 ist keine zulässige Win32-Anwendung: libapr-1.dll".

Bleibt also alles beim Alten, vielleicht funktioniert es dann unter CE12. Delphi64 würde ich gern noch kennenlernen, aber ich bin schon 73...

[jaenicke]

Zitat:

Zitat von HRolle (Beitrag 1529670)

Ich habe alles so gemacht, wie Du geschrieben hast. Beim Versuch, ein simples Beispielprojekt unter Versionskontrolle zu stellen, kam der Fehler: "193 %1 ist keine zulässige Win32-Anwendung: libapr-1.dll".

Das kann eigentlich nur heißen, dass diese DLL aus einem 64-Bit Verzeichnis geladen wird. Vermutlich ist ein solches Verzeichnis im System-PATH enthalten.
Das kannst du leicht prüfen, indem du diesen Befehl auf der Konsole eingibst:

Code:

where libapr-1.dll

Dann bekommst du eine Liste der passenden Dateien im System-PATH.

[HRolle]

Zitat:

Zitat von jaenicke (Beitrag 1529671)

Das kann eigentlich nur heißen, dass diese DLL aus einem 64-Bit Verzeichnis geladen wird. Vermutlich ist ein solches Verzeichnis im System-PATH enthalten.

Nein, die Datei ist unter den von VisualSVN heruntergeladenen Apache-DLLs. Die Suche auf C: verlief ergebnislos.

[bnreimer42]

Zitat:

Zitat von BigAl (Beitrag 1529582)

Das mit den Multiline-Strings ist zwar cool (hatte mich da drauf gefreut da ich viel SQL-Code nutze), aber wurde leider mal wieder nur halbherzig umgesetzt. Sobald man z.B. den code formatieren lässt (Ctrl-D) ist der Quelltext dermaßen verunstaltet dass er sich nicht mehr kompilieren lässt. Inline-Variablen werden nach wie vor nicht sauber formatiert.

Hauptsache neue Features reingepackt. Aber das "drumrum" sollte halt auch angepasst werden. So ist das leider nicht für mich nutzbar...

Bin gespannt, ob der Refactor mal endlich wieder funktioniert (habe ich noch nicht getestet).

Das ist als Fehler wohl bekannt und ist durchgerutscht.

[Uwe Raabe]

Der Code-Formatter ist momentan deprecated und ist wie auch das Refactoring bei der Installation abwählbar (Modeling), daher war in dem Bereich auch nicht viel zu erwarten. Ein zukünftiger Ersatz soll dann wohl auch die neuen Sprachfeatures unterstützen.

[BerndS]

Ich habe gerade Multiline-Strings mit CnPack (Ver: 1.2.8.1155_Unstable) Quelltext Formatierer getestet.
Der lässt diese Art von Strings unangetastet. Dafür zieht er D12 öfter in den Abgrund.

[jziersch]

Habt Ihr auch ein Problem bemerkt wenn man im Code ein Control.Visible := false bzw true setzt?

Das funktioniert unter 32 bit aber nicht unter 64 bit. (Auch bei deaktivierten VCL Stilen)

[Harry Stahl]

Zitat:

Zitat von jziersch (Beitrag 1529681)

Habt Ihr auch ein Problem bemerkt wenn man im Code ein Control.Visible := false bzw true setzt?

Das funktioniert unter 32 bit aber nicht unter 64 bit. (Auch bei deaktivierten VCL Stilen)

Also hier funktioniert z.B. das setzen eines Labels als visible oder nicht visible zur Laufzeit ohne Probleme (sowohl FMX als auch VCL), getestet unter Windows.

Worum handelt es sich bei Dir genau?

[jziersch]

Zitat:

Habt Ihr auch ein Problem bemerkt wenn man im Code ein Control.Visible := false bzw true setzt?

Danke, ich hab es in zwischen eingegrenzt. Es lag an fremden code der noch ein Cardinal() cast drin hatte. Klassiker.

[paule32.jk]

Hallo, gerade was entdeckt ...

- ich habe ein neues C++ Builder Projekt angelegt und wollte dann per BATCH Dateien hinzufügen
- bei dem Dateinamen "new.cpp" spricht mich dann die IDE mit folgender Message an:
"new ist ein reserviertes Wort."

- ich mein, was hat das mit Dateinamen zu tun ?
- ich verwende noch Rad 11

- ist das in Rad 12 behoben ?

[Uwe Raabe]

Der Dateiname ist ja in der Regel identisch mit dem Unit-Namen.

[paule32.jk]

ja, bei Delphi.
Aber unter C++ Builder sollte das doch egal sein ?

[dummzeuch]

Ist das neu in Delphi 12?
Ctrl+PfeilRunter bzw. Ctrl+Mausklick springt zu der Zeile mit "procedure" und nicht zum Anfang des Codes:

Delphi-Quellcode:

procedure TMyObjekt.MyMethod(); // <== hierher
var
  bla: integer;
begin
  Some;                         // <== statt hierher 
  Code;
end;

Das war zumindest bis Delphi 10.2 noch anders und war mir bisher in Delphi 11 nicht aufgefallen.
Ich bin mir noch nicht sicher, was mir lieber ist.

[BigAl]

Zitat:

Zitat von dummzeuch (Beitrag 1529731)

Ist das neu in Delphi 12?
Ctrl+PfeilRunter bzw. Ctrl+Mausklick springt zu der Zeile mit "procedure" und nicht zum Anfang des Codes:

Delphi-Quellcode:

procedure TMyObjekt.MyMethod(); // <== hierher
var
  bla: integer;
begin
  Some;                         // <== statt hierher 
  Code;
end;

Das war zumindest bis Delphi 10.2 noch anders und war mir bisher in Delphi 11 nicht aufgefallen.
Ich bin mir noch nicht sicher, was mir lieber ist.

War auch schon in 11.3 so. Hmmm. Ich mag es trotzdem nicht.

[t2000]

Ist Geschmackssache. Ich finde es so besser. Änderungen in den Prozedurköpfen gehen schneller. Und einen großen Block an Variablen oder Unterroutinen (bei denen es besser wäre) habe ich selten.

[himitsu]

Nja, bei dieser Funktion (Deklaration suchen) ist wohl der seltenste Fall, dass man die Signatur verändern will.
Eher will man meistens ja in den Code gucken, was der da eigentlich macht.

Zitat:

Zitat von t2000 (Beitrag 1529736)

Und einen großen Block an Variablen oder Unterroutinen (bei denen es besser wäre) habe ich selten.

Ach, einfach alles auf InlineVariablen und globale Variablen umbauen, schon passt es wieder.


Was auch noch nie ging,
z.B. die Deklaration einer WinAPI suchen (weil man wieder das CodeInsight nicht arbeitet),
da landet es immer in der Implementation, wo nur der Funktionsname und die Importanweisung stehen.

Hoch, ins Interface, zur Deklaration der Parameter, will es nicht (Strg+Shift + Hoch/Runter).

[Uwe Raabe]

Ich hatte mich erst gewundert, warum Strg-Shift-Up/Down hier in der Zeile nach Begin landet, aber dann fiel mir ein, dass das ja in MMX gemacht wird...

[lxo]

Wie kann man denn jetzt diesen dependencie graph erstellen in Delphi 12?

Da steht was von "--graphviz" in die Projektoptionen eintragen, nur wo genau?

https://glooscapsoftware.blogspot.co...hing-unit.html

[BerndS]

Siehe Anhang:

[lxo]

Zitat:

Zitat von BerndS (Beitrag 1529760)

Siehe Anhang:

Danke, funktioniert.
Kann jemand einen Viewer empfehlen.
Die ganzen Online-Viewer kommen mit unserem riesen Projekt nicht klar.:-D

[Bbommel]

Zitat:

Zitat von Bbommel (Beitrag 1529232)

Ja, werde wohl einen neuen QP-Eintrag machen. Und ggf. den Code anpassen, damit alles klappt, bis das gefixt ist.

Letzter Nachtrag noch, dann ist auch gut. Auch mit den "%" ist das Ergebnis falsch. Ausgabe unter D12:

Code:

hello%25world
hello%world

Wenn man also "hello%world" als Parameter hat, macht er daraus zunächst (korrekt) "hello%25world" und danach dann "hello%2525world". Das Problem ist also, dass die "TNetEncoding.Url.EncodeQuery" isoliert betrachtet jetzt korrekte Ergebnisse liefert, aber eingebettet in einen RESTRequest gibt es den Fehler durch die doppelte Umwandlung, die es schon immer gab, aber die früher nie auffiel. Betrifft auch "nur" den RESTRequest - der HTTPClient scheint zu funktionieren.

So, jetzt ist gut, bin dann ruhig mit dem Thema (bis ich den QP habe).

Kleiner Nachtrag hierzu. Leider war in letzter Zeit auf der Arbeit ein bisschen viel auf einmal los, so dass ich erst jetzt dazu gekommen bin, das Ganze in einem neuen QP-Eintrag aufzubereiten. Da isser: https://quality.embarcadero.com/browse/RSP-43450

[jziersch]

Bei der Verwendung von TParalell.For in einem TTask kommt es bei mir später zu einer hohen CPU Belastung in GetCPUUsage.

Mir ist aufgefallen, dass
TThread.Sleep(TThreadPool.MonitorThreadDelay);

in ThreadPool.TThreadPoolMonitor.Execute mit

Signaled := FThreadPool.FMonitorThreadWakeEvent.WaitFor(TThrea dPool.MonitorThreadDelay) = TWaitResult.wrSignaled;

ersetzt wurde. Ich verstehe allerdings nicht so recht wieso das besser ist als das Sleep. Habt Ihr auch Probleme mit TParalell beobachtet?

[himitsu]

z.B. wenn ein Thread beendet werden soll ... damit das "Sleep" dafür sofort unterbrochen wird und somit jemand schnellstmöglichst reagieren kann.

[jaenicke]

Zitat:

Zitat von Bbommel (Beitrag 1529950)

Kleiner Nachtrag hierzu. Leider war in letzter Zeit auf der Arbeit ein bisschen viel auf einmal los, so dass ich erst jetzt dazu gekommen bin, das Ganze in einem neuen QP-Eintrag aufzubereiten. Da isser: https://quality.embarcadero.com/browse/RSP-43450

Das ist ein wirklich gut geschriebener Eintrag. :thumb:

[Alex_ITA01]

Hallo zusammen,
habt ihr auch das Problem, dass nach Deinstallation von Delphi 11 und Installation von Delphi 12 (ISO), das MigrationTool zwar noch angezeigt wird in den Windows Anwendungen aber es nicht startbar ist? Also Klick auf das Windows Symbol in der Taskleiste, "Migration" eingeben und versuchen das Tool zu starten -> nichts passiert. Habe mir extra die Einstellungen von Delphi 11 gesichert und kann sie nun nach Delphi 12 nicht übernehmen.

[MEissing]

Ist die Datei/das Executable
"C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\migrationtool.ex e"
denn da?

Über die Verknüpfung gestartet: Was sagt Dateispeicherort (rechte Maustaste)? Verweist die Verknüpfung auf das (vorhandene?) Executable?

[himitsu]

Zitat:

Zitat von MEissing (Beitrag 1530161)

Was sagt Dateispeicherort ...

Jupp, da ja nie alles deinstalliert wird und immer Reste zurück bleiben, bzw. wenn du es im D11 schonmal gestartet hattest, dann gibt es da noch eine Kopie in "zuletzt verwendet"
und schon könnte es sein, dass es z.B. noch auf's alte D11-Verzeichnis zeigt.

[Alex_ITA01]

Das scheint irgendein Windows Bug zu sein.
Es wird mir gar kein Speicherort angezeigt oder irgendwas zu dem Tool (siehe Anhang).
Die Datei selber auf C:\... existiert und von dort lässt es sich auch starten.
Dann habe ich wenigstens meine Einstellungen wiederherstellen können.
Trotzdem komisches Verhalten

[himitsu]

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\
wie gesagt alter Müll

Ich seh bei mir noch ein 10.4 ... OK, da liegt nur eine Desktop.ini drin, welche das Setup nicht erstellt hatte und demnach auch nicht löscht
aber auch noch ein 10.2, mit Desktop.ini, Samples und "RAD Studio Command Prompt" :freak:

OK, und noch XE, aber das ist wirklich noch installiert :lol:

[UliBru]

Moin zusammen,

ich hab mir nun auch die 12 installiert. Wie immer geht damit auch das Übersetzen und Einbinden aller möglichen Pakete los. Bis das fertig und geprüft ist will/muss ich die 11 weiter verwenden.
Nun habe ich mir in der 12 das ZipMaster installiert. Und sinnvollerweise dabei ein eigenes Verzeichnis für die Bibliothek verwendet, die Delphi-Versionen sollen ja völlig unabhängig voneinander laufen. Soweit ok.
Wenn ich nun Delphi 11 aufrufe gibt es eine Fehlermeldung, dass die ...\Studio\22.0\Bpl\ZipMasterD23.bpl nicht geladen werden kann, obwohl die Datei vorhanden ist. Eine Neuinstallation des Pakets in 11 endet mit einer Fehlermeldung 'Zugriffsfehler in Mdodul rtl290.bpl'. Das Modul gilt aber für Delphi 12, während Delphi 11 ja das rtl280.pbl verwenden sollte.
Erst wenn ich nun in 12 das ZipMaster entferne dann klappt wiederum alles mit dem ZipMaster in 11.

Ich habe keinerlei Ahnung wieso Delphi 11 auf einmal auf das rtl290.bpl der 12-er Version zugreift. Siehe die Markierung im Anhang. Das Bild zeigt ebenfalls dass vorher der Zugriff auf die rtl280.bpl möglich war.

Weiss jemand an welcher Stelle es da irgendwelche Querverbindungen gibt und wie man diese vermeidet?

[himitsu]

Diese Fehlermeldung kann, aber muß nicht bedeuten, dass "diese" Datei fehlt.
Die Fehlermeldung kommt, weil LoadLibrary sagt es ging nicht (aber außer dem Fehlercode keine Zusatzinfo liefert, was wirklich nicht ging)
und dann wird als Nam das verwendet, was als Parameter ins LoadLibrary ursprünglich rein ging.

Diese BPL lädt andere BPL/DLL und Diese wiederrum weitere BPL/DLL usw.
Und wenn davon irgendwo was nicht ging ............


Wenn garnichts hilft, dann ProcessMonitor (SysInternals) nehmen und schauen, was wirklich gefunden wurde oder nicht
und wenn wo es gefunden wurde und wo es vorher gesucht wurde
uvm.

[UliBru]

Zitat:

Zitat von himitsu (Beitrag 1530222)

Diese Fehlermeldung kann, aber muß nicht bedeuten ...

Danke, ich hab die Ursache gefunden. Fehler 40 (sitzt 40 cm vor dem Bildschirm :)).
Wenn man ein Projekt kopiert und in einer anderen Delphi-Version lädt, sollte man alle Projektdateien im neuen System sicherheitshalber zuerst nochmals explizit im neuen Verzeichnis speichern.
Das habe ich vergessen. Insofern wurden das Projekt wieder im Ursprungsverzeichnis gespeichert und das alte überschrieben. Nun ändert die neue Version wiederum einiges. Und dann passten die Dinge irgendwie nicht mehr zusammen. Nun habe ich sichergestellt, dass Libsuffix, DLLsuffix etc. nicht identisch sind und schon läuft es.
Eigentlich fehlt mir seit jeher eine Art Projektimport, die sicherstellt, dass existierende Projekte nicht überschrieben werden.

[himitsu]

Für LibSuffix gibt es inzwischen die Variable '$(AUTO)' bzw. auch in den Projektoptionen. (seit Delphi 10.1)
Damit wird das Suffix automatisch an die aktuelle Delphi-Version angepasst.

{$IFDEF} mit mehreren LibSuffix, für mehrere DelphiVersionen in der DPK funktionierte leider nur bedingt.
Einmal das Projekt gespeichert, schon macht Delphi das IFDEF kaputt und die DPK funktionierte nur noch mit dieser Verison.