Leaderboard

UPDATE: I can confirm that Delphi 10.4.2 installs, builds and runs on a Mac M1 with a Parallels Desktop VM of WIndows 10 ARM (insider build). I successfully installed all my components (TMS, JVE, custom), build and ran both VCL (win32) and FMX (win32, MacOS64, Android32/64 and iOS64) perfectly. I'm going to keep using it for a while but if all goes well, this is a great solution and so much faster than my older Intel Macbook

You're in good company; We've all been there

Unfortunately inline vars are not always equivalent to "with". I'm currently working on a project that has, um.. let's be polite and say, "liberal" use of record arrays. So for example: type TFoo = record // Lots of stuff here end; TBar = record Foo: array of TFoo; // Even more stuff end; TFooBar = array of TBar; var FooBar: TFooBar; begin with FooBar[i].Foo[j] do WhatEver := 42; var Foo := FooBar[i].Foo[j]; Foo.WhatEver := 42; // Nope. end; Using an inline var to access an inner record will create a copy of the record while using "with" will use a reference to the record. Only way around that is to use record pointers but the code is horrible enough as it is.

I never said it was the fault of Application.ProcessMessages; it was mine for using it 🙂 Tbh I don't see a difference between running in a cycle of While thread.Terminated Do and dataset.Next millions of iterations. It just depends how much data you have. Sleep was originally uncommented, I think I could go down to 5 ms sleep before starting to eat up the CPU. But since I took a deep breath and started to get rid of this - I don't want to experiment to try to patch-the-patch to make it look better. This time I want to do it right 🙂

This is the exact thing I experienced. I took the shortcut when I converted my app to use background threads for operations. Instead of Connection.Connect; DoSomeStuff; I started a thread and did... StartConnectionInBackgroundThread; While Not thread.Finished Do Begin // Sleep(10); Application.ProcessMessages; End; DoSomeStuff; All was fine until only one code like this ran. In the moment two tried to connect simultaneously (not mentioning a couple of occasional deadlocks) connections took 5-10 times more than they normally would, if they connect by themselves. Also, UI was responsive, but sluggish. For 20+ builds now I'm in the process to get rid of this shortcut I thought was a good idea before. And while it did what I wanted to achieve on the surface - it did backfire on the long run. For 2+ weeks I'm making changes what the end user might not even realize, and these changes affect 20-30 source files per piece. I completely agree with @Dalija Prasnikar and some others on this matter - I wish I didn't know Application.ProcessMessages exists in the first place 🙂

Are you saying that it was in the end nothing to do with your SetLength calls and was just a defect somewhere else in your code that corrupted the heap?

I think that whenever you change the datasource / dataset on the DBGrid it reinitializes everything, including the column captions you set in design time. To change the column caption, you can change the field's DisplayLabel property: dataset.FieldByName('FNAME').DisplayLabel := 'Medlemsnr'; This will cause the DBGrid to display that as a caption automatically when it creates the column. You'll still have to manually change the caption to bold every time, that is.

No need for that. You can already write this instead of such a with-clause. begin var foo := some.long.long.nested.object; foo.bar := laz ... end; That doesn't help converting existing with constructs, though.

V3 works with VCL/command line/service. V4 *will* also support FMX (current development v4 version does not).

@Remy Lebeau The LStrFromPWCharLen entry indeed looks wrong - but the lines before and after that exactly match with the 10.3.3 code - I just checked. Maybe it's just a glitch in the stack walking code done by FastMM_FullDebugMode.dll Edit: Yep - I can repro the wrong entry in the call stack with this code: uses FastMM5, System.SysUtils; var x: TBytes; s: string; r: RawByteString; begin s := 'test'; r := RawByteString(s); SetLength(x, 10); Pointer(x) := nil; ReportMemoryLeaksOnShutdown := True; end. and get this report: This block was allocated by thread 0x432C, and the stack trace (return addresses) at the time was: 004128BA [FastMM5.pas][FastMM5][FastMM_DebugGetMem$qqri][7717] 0040476D [System.pas][System][@ReallocMem$qqrrpvi][5022] 00408181 [System.pas][System][DynArraySetLength$qqrrpvpvipi][36046] 00406E08 [System.pas][System][@LStrFromPWCharLen$qqrr27System.%AnsiStringT$us$i0$%pbius][26213] <-- ?!?! 004082C2 [System.pas][System][@DynArraySetLength$qqrv][36150] 004265D9 7732FA29 [BaseThreadInitThunk] 77E87C7E [RtlGetAppContainerNamedObjectPath] 77E87C4E [RtlGetAppContainerNamedObjectPath] My guess would be that the: PUSH ESP ADD dword ptr [ESP],4 in _DynArraySetLength is not properly handled by the stack walking code. Obviously, a defect in JclDebug LogStackTrace in FastMM_FullDebugMode.dpr - compiling FastMM_FullDebugMode.dll with madExcept gives this call stack as it just passes to madStackTrace.FastMM_LogStackTrace which seems to do a better job: 004128b5 +015 Project53.exe FastMM5 7717 +4 FastMM_DebugGetMem 00404767 +03f Project53.exe System 5022 +91 @ReallocMem 0040817c +16c Project53.exe System 36046 +70 DynArraySetLength 004082bd +005 Project53.exe System 36150 +3 @DynArraySetLength 7732fa27 +017 KERNEL32.DLL BaseThreadInitThunk Probably the bug is in GetRawStackTrace and madExcept is just able to fix it - I am not entirely sure - as far as I can see there is no method in JclDebug that can build a call stack from the data that FastMM_FullDebugMode GetRawStackTrace collects - that is why LogStackTrace simply iterates the entries and calls GetLocationInfo on each of them and just concats them. @Pierre le Riche fyi

Important: a memleak report just tells where the memory was allocated that got leaked not the code that actually caused the leak. You need to review the code in NodeGetBase64Value and check what it does with the result of Mime64Decode and where it passes that.

The code that we can see can't leak. There is likely a bug in some other code, probably your code. If you show a minimal repro we'll find it easily.

OnFieldchange for the field linked with dbCombobox1. I would also compare the field value, not the DBCombobox1.text.

The Ryzen 5 processor is more than capable of running VM's on your PC. If it's not for gaming, go for a business PC, they have better hardware quality.

Update: I am no longer one-armed, but have about 1.65+ arms 😉 Mobility is decent and pain is limited, but there will be weeks of training to get back the strength and full use. To add insult to injury, I also caught the SARS-Cov-2 English mutation around March 16th, but I was lucky and got a very light progression, almost like a mild flu - but with an unusual amount of fatigue. Wife and stepson also got it, and they lost all sense of taste and smell, while I kept mine. Wife is currently getting her smell/taste back, but stepson still complains about food having no smell/taste or wrong taste, and that toothpaste tastes awful. We have no idea where we got it from, but I was visiting the hospital on that date, so it may even have been from there. The hardest part has been the fatigue. All my adult life, I have never been one to take a nap during the day, and typically have slept around 7 hours every night. The last weeks I've slept 7-8 hours during the night, and on several occasions 3-4 hours in the afternoon. I've been drained, both physically and mentally, and I still tire quickly, but it gets better every day. I highly recommend NOT contracting this shit! Keep your distance, wear that mask, wash those hands - and get vaccinated.

We have lots of legacy code that still uses "with" and I'm hesitant to touch this code because of this (Guess what's also missing? Unit tests. I add them when I find the time, but progress is slow.) A tool that reliably removes "with" statements would be awesome. Unfortunately it's also far from trivial.

The code where you call Application.ProcessMessages procedure TMainForm.BtnClick1(Sender: TObject); begin DoFoo; DoBar; DoFork; end; procedure TMainForm.BtnClick2(Sender: TObject); begin DoFoo; Application.ProcessMessages; DoBar; Application.ProcessMessages; DoFork; end; procedure TMainForm.BtnClick3(Sender: TObject); begin TThread.CreateAnonymousThread( procedure begin DoFoo; DoBar; DoFork; end).Start; end; Problem with Application.ProcessMessages is that code that would execute in one block without interruptions, like in first example, can now be interrupted and some other code can start running in the middle of it. For instance you can click same button twice. Or you can close form and destroy it while other code is still running and using it. Now moving in background thread does not solve those issues, because you can still click the button twice and you can close the form while you running something in the background. But, there are few things to consider here. First, while code with ApplicationProcessMessages can be interrupted at any point, code in background thread will run serially, one line after the other, just like the code that does not call Application.ProcessMessages. It is far easier to follow the logic (and debug) such code. One of the arguments for Application.ProcessMessages was that it is easy to use, comparing to multithreading. That is true only on the surface, it seems easy and that is why we were all using it. So you have beginner developer writing all kind of poor code in event handlers and application becomes unresponsive, so he is advised to use ApplicationProcessMessages, and he sprinkles his code with those and application might work better (seemingly). In the reality, he learned nothing, his code is really bad, and sooner or later when some user clicks something unexpected everything will fall apart. When you have to move code to the background thread, you need to think more about it and you need to isolate it better. Mere process of isolating functionality will make that code better. Now, you can still have developer that will just move the whole thing to the background without doing any of that, but that code will not seemingly work (that rarely happens) and it will not work properly, which will hopefully trigger the developer to ask for help and learn how to do that properly. There is a difference. If the UI reacts slowly that means when you drag the window and it will not drag smoothly, when you click the button you may not get immediate response, so you will click it again. Background thread does not block the UI so it does not matter how long it takes to cancel the operation. You can write your code in such manner that when action is canceled, user can immediately continue doing something else. You don't have to move data between threads - data is not contained within threads (unless you specifically create thread local data), you just need to prevent multiple threads changing the same data simultaneously.

You know that annoying person constantly interrupting and asking you the status of some very busy task you are performing? That person is called Application.ProcessMessages

This is bad idea. First, Application.ProcessMessages has some global side effects that can bite you in behind when you least expect them. Next, depending on the code, it is possible that some pieces still take too long to keep UI fully responsive. Using background threads for simple operations is not rocket science and at the end when you take all pros and cons it is not more complicated than using Application.ProcessMessages.