Delphi 12 ist offiziell da!!!

[Bbommel]

Da kann es eigentlich keine zwei Ansichten geben. Das Ergebnis, das jetzt erzeugt wird, ist schlicht falsch.

Wenn du beispielsweise die erwähnte Microsoft Graph API benutzt, dann bekommst du ab einer bestimmten Zahl von Einträgen einen "nextLink", um weitere Einträge abzurufen. In diesem NextLink sind dann ggf. auch Mandantennamen oder andere IDs kodiert und Microsoft sagt in den Dokus explizit, man soll diese angegebene Adresse einfach nehmen und verwenden und sie nicht selber parsen.

Das ginge so aber nicht mehr, da man selbst die Parameter parsen müsste, um sie dann wieder neu hinzuzufügen, damit Delphi keinen Mist macht. Das ist nicht nur überflüssiger Blödsinn, sondern widerspricht auch der Doku. Solche Fälle gibt es öfter in APIs.

[Uwe Raabe]

Zitat von Bbommel:

Da kann es eigentlich keine zwei Ansichten geben. Das Ergebnis, das jetzt erzeugt wird, ist schlicht falsch.

Wie Stefan schon erwähnt hat gibt es dafür einen entsprechenden Parameter - der ist allerdings nicht neu und hätte in dem Fall auch schon vorher gesetzt sein sollen. Das es vorher auch ohne ging war ein Fehler.

[Bbommel]

Zitat von Uwe Raabe:

Zitat von Bbommel:

Da kann es eigentlich keine zwei Ansichten geben. Das Ergebnis, das jetzt erzeugt wird, ist schlicht falsch.

Wie Stefan schon erwähnt hat gibt es dafür einen entsprechenden Parameter - der ist allerdings nicht neu und hätte in dem Fall auch schon vorher gesetzt sein sollen. Das es vorher auch ohne ging war ein Fehler.

Sorry, sehe ich anders. Jeder Browser bekommt den genannten Aufruf problemlos hin - und Delphi bis zumindest 11.2 auch. Das man den von dir erwähnten QP-Eintrag fixen wollte, verstehe ich, hat das aber falsch gemacht. Das Problem ist ja nicht, dass man jetzt ein Prozentzeichen kodiert, sondern dass man doppelt kodiert. Ich habe mir das ja im Debugger angeguckt (siehe mein Betrag in Beta-RSB). Wenn in der URL der Text "hello world" steht, dann macht Delphi daraus in einem ersten Schritt "hello%20world", also völlig korrekt. Er merkt sich dann aber nicht, dass er das schon getan hat, sondern geht dann ein zweites Mal drüber und macht daraus dann "hello%2520world". Du willst mir doch nicht ernsthaft erzählen, dass das der richtige Lösungsansatz für den von dir genannten QP-Eintrag ist.

Prinzipiell müsste man nach der ersten Kodierung ggf. ein internes (oder auch das öffentliche) Kennzeichen AlreadyEncoded setzen - macht man aber nicht und dadurch taucht jetzt der Fehler auf. Ist früher nicht aufgefallen, da man von einem % die Finger gelassen hat und klar, das war so natürlich auch falsch.

[Uwe Raabe]

OK, dann solltest du (sobald das geht) einen neuen Eintrag in QP machen, da der bisherige Beta-Eintrag voraussichtlich als erledigt markiert und gar nicht publiziert wird.

[Bbommel]

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).

[Bbommel]

Zitat von Bbommel:

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?

[jaenicke]

Zitat von Bbommel:

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.

[himitsu]

Nicht wundern / nicht zu früh freuen !

In der Professional lässt sich Linux auswählen,
aber es wird leider nicht installiert.


Es sieht bisher nach 909 Requests aus.
https://quality.embarcadero.com/brow...updated%20DESC
[edit] neee, 911
https://quality.embarcadero.com/proj...versions/14300



Schon beim Starten der Installation den Marco Cantù gefragt, ob es denn so geplant sei. (der saß zufällig grade vor mir)
Leider ist es immernoch nicht geplant es dort beizupacken.


Bei mir 'ne stunde geladen/installiert .... war aber zwischendurch weg.

Zitat von Stevie:

Die CE gibt es nie zeitgleich mit dem Release der kostenpflichtigen Version sondern eher erst spät im Produktzyklus ...vielleicht auch besser, dann ist einiges wenigstens gepatcht

Letztes Mal was sie sehr schnell da ... davor dauerte es so ein Jahr, bis schon die nächste Version raus war.

[Stevie]

Zitat von himitsu:

Letztes Mal was sie sehr schnell da ... davor dauerte es so ein Jahr, bis schon die nächste Version raus war.

Die 11 CE gab es (Ende April 2023) erst nachdem 11.3 (Ende Februar 2023) released wurde. Das Release von 11.0 war Mitte September 2021 - so viel zu "sehr schnell".