Leaderboard

https://xkcd.com/292/ just saying

Spring4D is not negatively affected by Patch2

Hi all, I'd like to share that my new book is almost out. Apress is working hard to put it in the market. We always discuss how we can bring new people to Delphi so I thought it would be a good idea to ease their way in by providing a quick up-to-date guide on the basics of the language. The book covers new features introduced in 10.4 Of course, a reference book is always useful to experienced coders as well; we all need a refresher every now and then 🙂 I would like to cordially thank Dr. Holger Flick for reviewing the chapters; his experienced view guided me during the writing of the book. Regards, John 9781484261118.tif

Hi, just for you guys to weigh in, we have located a bug in the Delphi 10.4 compiler, that removes a totally valid assign statement in RELEASE mode, believing, that the code will never be executed. The actual method is from the mORMot library in releases before last week (unit SynCommons.pas, method TSynAnsiFixedWidth.AnsiBufferToUTF8. A full discussion is available at the mORMot-Forum: https://synopse.info/forum/viewtopic.php?id=5520 . I have reported the bug to Embarcadero: https://quality.embarcadero.com/browse/RSP-30088 . Please check out my report and try to confirm and weigh in there. It should be reproducible. --- Note, the compiler will tell you (Hint H2077), that the value assigned is never used and thus, in RELEASE mode, with optimizations enabled, drop the code completely. Thanks for your time and support 👍

This procedure takes 76% of time in my case 2694 procedure TfrxPDFExport.ExportViaVector(const Memo: TfrxCustomMemoView); and was called because GapY was -1 if (Memo.ReducedAngle <> 0) or (Min(Memo.GapX, Memo.GapY) < 0) then ExportViaVector(Memo) With Gap=0 for some of memo components ExportViaVector() takes 44% of time and the report looks the same but the PDF is generated in 6 seconds vs. 13 seconds Edit: Better take a profiler and don't lose the time guessing.

By popular request of a single gentleman (*) there is now a button "Ignore All this Session". The exception class name is now also a regex. Empty matches any exception. (* I'm not sure this really carries the meaning of the German joke "Auf vielfachen Wunsch eines einzelnen Herrn ..." )

Thank you. I haven't found the repair option yet - sometimes software offers repair in the Add/Remove Programs window. But I could only see Uninstall offered there. I tried setting file associations manually via the Windows right-click Open With... option, but couldn't get the setting to stick. Windows kept displaying the Open With... dialog in a never ending loop. Not sure why. Luckily I found an answer in another post on this forum. Just in case it helps someone else: In Delphi IDE Options there is a section listing File Associations. Unticking them all, then ticking them again seems to have fixed the issue. Phew!

You probably have to use an IOTADebuggerNotifier to detect ProcessCreated/ProcessDestroyed - there you have to add/remove IOTAProcessNotifier and get ThreadCreated/ThreadDestroyed and you can already guess it add/remove an IOTAThreadNotifier which has ThreadNotify where you are interested in TOTANotifyReason.nrException. The corresponding IOTAThread instance has all the required information like the OSThreadID or Handle properties

I've got tired restarting the IDE because of the recurring AV when I was adding a new unit/form etc.. to the current project. Looks like it was fixed in 10.3 https://quality.embarcadero.com/browse/RSP-15471 I don't know, because I'm still on 10.1 U2, and there will be never an official patch for that. The problem is crystal clear: 2203A97A E861C7E6FF call $21ea70e0 ; FindTopEditView 2203A97F 8B4044 mov eax,[eax+$44] not checking against "nil" in EAX. (Why this returning nil after an amount of time is a different question and it's not something we could ever fix in the binaries) the fix is almost as easy as spotting the problem, detouring the call, and do some check: procedure PatchStructuralHighlighterCode; asm call FindTopEditView TEST EAX, EAX JNE @ok call PErrorProc // debug logging jmp ReturnNil @ok: jmp Return end; Now, @FindTopEditView, @ReturnNil and @Return are version specific values, obviously, I have the addresses only for my IDE version. As I don't feel the urge for maintaining and supporting fixes for Delphi but I would share the details if anybody is interested.

@Uwe Raabe I got it! I managed to repeat the effect a few times, I recorded the screencast: https://www.youtube.com/watch?v=PmsQHrr3muU&feature=youtu.be

Add a Caption: string to TResult and try again. It will set TResult.Caption to A, and you get no hint or warning that there is a name space collision. Using inline variable declarations - you can eliminate with without a lot of extra code. procedure TForm1.FormCreate(Sender: TObject); begin var r := GetResult; Caption := r.A; end; var p := GetComponent as TPanel;

Primoz is psychic 😉

Just remove the : record constraint from FromRecord and it will work. Just don't pass anything but a record then :p

Given that so much that is actually important is broken, this should be way down the list of priorities.

Hi Thomas, The issue has returned. Haven't used it for a bit but did today after updating to rev 3236. It occurs in both 10.3.3 & 10.4. Regards, Ian

I reported the regression and added a suggestion how to fix this kinda properly (without going too deep into the rabbit hole of extending constraints): https://quality.embarcadero.com/browse/RSP-30078

Custom Managed Records Coming in Delphi 10.3 (deferred to 10.4) Custom Managed Records Coming to Delphi 10.4 Custom Managed Records New in Delphi 10.4 Sydney Custom Managed Records

No I don't think it does make them managed records. I don't really understand how such simple code could break the compiler. It's as if Embarcadero don't have comprehensive tests in place.

Issue has been solved. 🙂