aehimself

Without manually modifying the pointer as you suggested and properly released owner... how exactly you can cause a memory leak with Strings? I always thought records, arrays behave like interfaces and are automatically discarded when their lifetime is over.

In my personal experience, leaks pointing to some kind of a Sting routine are never the leaks you have to pay attention to. They are never the cause, they are the side effect - especially if the allocation is initiated in a in a component (let's hope 🙂 ). As @Kas Ob. said, most probably you forgot to release an instance which is keeping the reference count high. Unless if you are playing with reference counts yourself, that is. And again supporting the statement above mine - I never had a leak which could be fixed in the same method. Because of messed up design, sometimes releasing the object had to go to a different unit! Always handle allocation call stacks as a pointer only. You have to know what was allocated and why - and when that specific instance can be released.

That is exactly how it looks like from the webapp's perspective. A is logged on, B is not. Well, not security context but it has a valid session open. But effectively yes. Having your username / password is always going to be way more easy. Normally session identifiers can distinguish between browser instances running on the same PC with the same user. Which means, even if you can "catch" that session ID somehow, it's not going to work from your Delphi app. I'd just drop a TWebBrowser / TEdgeBrowser on a form, make the users use this program to use the ticketing system. From within the program you can easily get the page source, discover and download attachments automatically within the exact same session. Even without drag & drop.

You can try: http(s)://ticketing.system.local/images/imagetobedownloaded.jpg?username={URL_Encoded_Username}&password={URL_Encoded_Password} or, add a header to the request: Authorization=Basic {Base64_Encoded username:password} or, if you are lucky, there will be a (now unhandled) onAuth event in the component. When it fires, you can set the username / password to access the resource. These all require though that the system allows these kind of authentications. If you are unlucky, you still can "log on" first and then download the picture with the component. Just make sure you re-attach the session cookie in the second request.

One connection per thread is like an unwritten rule. I experimented with one connection for 7 workers, but gave the idea up quickly. One thing I found strange is that if I called dataset.Open in a background thread, I had to call .FetchAll too, otherwise it still froze the VCL thread upon accessing .RecordCount. But the jumping between records error still makes me believe that the connection is going to be the issue - if FireDAC works similar to the components I use.

You don't need much time - it's about 200 lines 🙂 As I said I tried to keep it as simple as possible. If someone needs more, the code is easy enough to be extended with someone's own needs. Completely agreed. That's one reason I chose to hand over the code to the Zeos team. I wrote a custom DB management app and I needed to keep the GUI responsive even if the user entered a hour-long query. That's when I came up with the idea of pushing it to a background thread. It does nothing though if you can not gracefully end it so aborting running operations was born. I needed it to satisfy my colleagues needs using my tool and it felt good to finally give something back to the component I was using for long years now. Effectively a win-win situation.

@Dany Marmur I used to have one but I decided to discontinue my own website as it started to be a burden to maintain. The idea is to be as simple as possible: Type TProcedureOfObject = Procedure Of Object; TErrorEvent = Procedure(Sender: TObject; Error: Exception) Of Object; TZMethodThread = Class(TThread) private _runmethod: TProcedureOfObject; _onerror: TErrorEvent; protected Procedure Execute; Override; public Constructor Create(inMethod: TProcedureOfObject; inErrorEvent: TErrorEvent; inFinishEvent: TNotifyEvent); ReIntroduce; End; Constructor TZMethodThread.Create(inMethod: TProcedureOfObject; inErrorEvent: TErrorEvent; inFinishEvent: TNotifyEvent); Begin inherited Create(False); _runmethod := inMethod; _onerror := inErrorEvent; Self.OnTerminate := inFinishEvent; End; Procedure TZMethodThread.Execute; Begin Try If Assigned(_runmethod) Then _runmethod; Except On E:Exception Do If Assigned(_onerror) Then _onerror(Self, E); End; End; And then there is a "wrapper" around this, where you just pass a dataset and it is creating a TZMethodThread with Dataset.Open for example. I hope I can say this and it's not considered an advertisement; the latest version of the unit is included in Zeos 7.3 (look for ZMethodInThread.pas) which is although "specialized" can easily be ported back to use a standard dataset. Or throw the wrapper out and just use the thread with any procedure of object - with the necessary caution to VCL synchronization, of course.

This is exactly what I started to do lately. All my applications business logics are basically a TObject-descendant, and service initializations or console launchers only create an instance of them. I find this structure really easy to test, to port, to maintain or extend. This might be my own personal preference, though.

This is something I can not c ompare. The first thing I always did on a fresh Delphi installation is to disable error insight altogether as it made the IDE unbearable slow with 1500+ units and 20-30 custom components. Therefore I don't know how bad it was before - I had hopes with 10.4 and LSP - it did not come up to my expectations, unfortunately. I personally like Delphi's IDE a lot more than Visual Studio, but VS's error insight works a lot better (even with large projects), unfortunately. It hogs up the system more too, though. When refactoring, I'm following these guidelines too. As least visibility to properties as absolutely needed, cutting out excess things from the Uses list, etc. As I said - unfortunately - my experience is far from yours. With a low number of units and 3rd party components wiggly lines are likely there to stay until execution / IDE restart 😞 Hopefully this week I'll start to check how Delphi 10.4 handles a big project at work... with poorly written code, interfaces here and there, 10+ depth in dependencies... that will be the true test, though. It will decide if we move or stay on 10.3.

I don't use FireDAC, but a 3rd party library to connect to databases, Unfortunately though, they work in async mode only, so a huge query with lots of blob fields could take up to a couple of hours (!!!) to load through the Internet. God bless those SELECT * FROM ... JOIN ... JOIN ... JOIN ... type queries. My solution was to unhook all datasets from any datasources, and call the dataset's .Open method in a separate thread, Once the thread finishes it executes a callback routine to hook the datasets back to the datasources. This resulted a completely unblocked VCL thread, and I even could implement a button to execute the "Abort" command through the same connection if the user does not want to wait until the end of the query. You can create a custom TThread descendant with a parameter of a dataset, but I chose to take an incoming Procedure Of Object parameter instead. This way, I can execute the same thread with a Dataset.open, Dataset.Post or Connection.Commit when I please, leaving the application as responsive as ever.

Error insight (and code navigation) is still unreliable, unfortunately. I'm test-driving 10.4 with small projects (maximum 15 units) and sometimes the red wiggles stay until I restart Delphi (or run the application). Code navigation completely fails for some 3rd party components if the (system wide) library path is pointing to DCUs only and debug source path and browsing path is set to the source files. It usually can navigate to the first unit, but not to the second one from there (unless if it is already open)

This was my plan all along, I just did not see the "Custom themes" subkey 🙂 Thank you, @Lars Fosdal; this method works like a charm!

By mistake I already discovered this option and disabled it. It shows as off in Dephi IDE and ToggleTheme in Registry values stores 0. Still, color values in Editor \ Highlight \ * are being reset to the values of the scheme selected.

So I started to experiment with Delphi 10.4. When we switched to 10.3, I immediately installed the VS code color theme (https://blog.grijjy.com/2017/12/29/alternative-dark-editor-themes-for-delphi-10-2-2/) via the Migration Tool as I think it's the most eye-friendly scheme - plus I got used to it already. My issue is that Delphi 10.4 simply does not want to accept this. I tried to manually update the values in Registry but as soon as the IDE restarts they are being overwritten. Does anyone know where Delphi 10.4 stores the saved color schemes? I would try to create a new one and set it as a default for my dark theme; I just don't know where to put them 🙂

Give TDirectory.GetFiles (System.IOUtils) a try. It drastically improved the time it took to discover everything compared to my recursive FindFirst / FindNext in my backup application.

It's fixed now. At the time of the original post my Edge reported it unsafe too, but now it goes there without an issue.

Hello, I'm in the process of fixing some unusual amount of memory leaks and code errors in a legacy codebase. We have a custom TDBImage descendant, which was leaking TJPEGImages like there's no tomorrow. The code used to look like this: constructor TMyDBImage.Create(AOwner: TComponent); begin […] Picture.Graphic := TJPEGImage.Create; […] end; procedure TMyDBImage.DataChange(Sender: TObject); begin Picture.Graphic := TJPEGImage.Create; FPictureLoaded := False; if FAutoDisplay and (DataSource.DataSet.State <> dsInactive) then LoadPicture; end; procedure TMyDBImage.LoadPicture(ARefreshDataSet: Boolean = False); begin […] if not DataSource.DataSet.EOF and DataLink.Field.IsBlob then Picture.Graphic.Assign(DataLink.Field) else Picture.Graphic := TJPEGImage.Create; // Empty picture end; I guess they wanted to clear the image, so I changed all those TJPEGImage.Create-s with a simple nil assignments (Picture.Graphic := nil). I also changed the loading mechanism: procedure TMyDBImage.LoadPicture(ARefreshDataSet: Boolean = False); Var jpeg: TJPEGImage; begin [...] if not DataSource.DataSet.EOF and DataLink.Field.IsBlob then Begin jpeg := TJPEGImage.Create; Try jpeg.Assign(DataLink.Field); Picture.Assign(jpeg); // Picture.Bitmap.Assign(jpeg); This does not work either Finally jpeg.Free; End; End else Picture.Graphic := nil; // Empty picture end; The leaks are gone, but the picture is not shown in the component. I already confirmed that "jpeg" is filled correctly (stop with debugger, execute a .SaveToFile and check the result) but I can not really make the DBimage's Picture to load it. Based on my previous codes the Picture.Bitmap.Assign should be fine; I guess in this case it's the nil assignment of the .Graphic property which is not letting it to work? Where is my logic wrong? Thanks!

My preference is to have as low amount of files in my built applications as possible. Therefore I usually include the admin area. I really do dislike the pure "it depends" answers, but here yes, it depends on lots of different factors, including security, end-user needs and of course your own personal preference. Security, because the admin area might contain references you don't want an average "Hacker Henry" to see with a decompiler, not even as assembly code. End user needs, as for 3 checkboxes and a language selector the user might find it disturbing having to navigate somewhere else. Personal preference - which codebase is easier for you to maintain? Multiple applications with less code, or one application with more? And these are just the first ones which pop up in my mind, so treat this list as severely incomplete 🙂

This makes no sense to me. I was in the belief that a code either works or not. Unless if it's a problem with TDBImage and/or VCL of course; but that is out of my reach anyway. If I can manage to reproduce the issue somehow, I will attempt to fix it with DIBNeeded and will not forget to share the result.

@Kas Ob. Often the experience gathered during the journey is more valuable than reaching your destination. Noone will actually see that I worked on this component, but I'm richer with a bit of knowledge. Yes, I would be more than willing to check your idea, however... Today, when I restored the faulty TJPEGImage assignments, it simply started to work...?! Noone else touched this code, the image is the same. Yesterday it was an empty white rectangle, today the image shows up...

If any future visitor is wondering, a simple Picture.Assign(DataLink.Field); solved the problem, there was no need for a middle TJPEGImage. It's still a mystery for me though, why it is not working with a TJPEGImage and working without. Especially since they were all loaded correctly. Especially since the above works fine with a normal TImage, but not from inside a TDBImage descendant.

I know. This is why I am attempting to get rid of it. Well, it is working if we are leaking TJPEGImages, which I find really strange. Also attempting to Self.Invalidate / Self.Repaint / Self.Refresh after loading the picture makes no difference.

Good idea. Commented the .Free out: jpeg := TJPEGImage.Create; Try jpeg.Assign(DataLink.Field); Picture.Assign(jpeg); Finally // jpeg.Free; End; Bad thing is, it still does not work (picture isn't shown) and it leaks a TBitmapImage, a TJPEGImage, a TBitmap, a TJPEGData and a TMemoryStream object upon destruction 😞

Yep. As I'm .nil-ing that, it'd throw an AV. The loading has been re-written, and is now: Picture.Assign(jpeg);

Procedure TAEMultiSQLMainForm.ConnectionClick(inSender: TObject); Var ts: TTabSheet; sqf: TSQLConnectionFrame; s: String; Begin s := (inSender As TMenuItem).Caption; ts := TTabSheet.Create(Display); ts.Caption := s; ts.ImageIndex := 1; ts.PageControl := Display; sqf := TSQLConnectionFrame.Create(ts, Settings.Connections[s], Log); sqf.Parent := ts; RecolorSQLFrame(ts); Display.ActivePage := ts; ChangeFocus; sqf.ReconnectButton.Click; End; This is the code snipplet I use in a tabbed SQL browser to open a new connection; which is also a frame. I am creating a tabsheet and a frame without a name and never got an error concerning component names. That's the only reason I asked.