Dalija Prasnikar

You can find simple demo how to use threads with Indy here: https://github.com/dalijap/code-delphi-thread-safety/tree/master/Part3/19 Indy This demo is using anonymous thread, but you can also use regular threads or TTask from Parallel Programming library, too. If you can post your code I can give you more detailed advice.

Uh.... this is such far fetched speed optimization that it is not even worth thinking about. And if you start measuring particular solutions, you may easily find that you will not get very far with them.

Memory management has nothing to do with number of parameters in constructors. There are other reasons why having too many parameters is considered "bad", but those are all in line that having too many parameters can be indication that your class is doing too much - violates Single Responsibility Principle. In real life, having classes and functions that require a lot of parameters and that are not in violation of SRP, nor can be adequately split, are quite common, and often workarounds for solving such "issues" are more convoluted than having few parameters over the top. If there is really a need to have class fully initialized during construction and too many parameters poses an issue that cannot be meaningfully solved by splitting the class, then Builder pattern can be suitable solution. There is usually a lot of repetitive code involved in writing a Builder class, so it is useful only if you need to construct particular class in plenty of places across your application. The main problem with many parameters, especially when they are of same type, is that you can easily pass the wrong data to wrong parameter. This could be solved on IDE level, by showing names of the parameters as hints within code - not visible outside the IDE,, so calling the constructor or function would look like TPerson.Create(AFirstName: 'John', ALastName: 'Doe'); Another similar feature on language level are named parameters, where you can or must explicitly write parameter name in the code, similar to the above.

Implementation section where your TTracksAddEditForm class is declared. Just like with any other method that is declared in a class, its implementation must be included inside that unit implementation section.

Oops... I forgot to copy-paste that part of the code... constructor TTracksAddEditForm.Create(AOwner: TComponent; const AsMode: string; AiAlbum: integer; const AsTrack: string); begin inherited Create(AOwner); FsMode := AsMode; FiAlbum := AiAlbum; FsTrack := AsTrack; end;

Your code can be simplified in several ways. I will write each step separately, so you can more easily adapt your code if you need additional functionality beyond the code shown here. First, as I mentioned in previous post, you don't need to write getter and setter functions at all, if you just read or write field in those and noting more. First optimization would be removing all that redundant code. This is not just speed optimization, but also makes cleaner code that is easier to read and follow. This code is functionally completely equivalent to your declaration and you would create and initialize the form the same way you do now. TTracksAddEditForm = class(TForm) private FsMode: string; FiAlbum: integer; FsTrack: string; public property sMode: string read FsMode write FsMode; property iAlbum: integer read FiAlbum write FiAlbum; property sTrack: string read FsTrack write FsTrack; end; Your next question was whether you need to have both getters and setters. If you are just setting property, then you don't need getter. Similarly, if you have read only property that you will just read, then you don't need setter. So next optimization would be following. There is no difference in how you create and initialize your form. TTracksAddEditForm = class(TForm) private FsMode: string; FiAlbum: integer; FsTrack: string; public property sMode: string write FsMode; property iAlbum: integer write FiAlbum; property sTrack: string write FsTrack; end; procedure TAudioForm.btnInsertTrackClick(Sender: TObject); begin TracksAddEditForm := TTracksAddEditForm.Create(Self); TracksAddEditForm.sMode := 'Insert'; TracksAddEditForm.iAlbum := Albums.FieldByName('Index').AsInteger; TracksAddEditForm.sTrack := TracksView.FieldByName('Title').AsString; TracksAddEditForm.Show; end; But, the best way to initialize any class that you will construct through code (without bringing in dependency injection) would be declaring all required information as parameters to the constructor, Such code would also require different code when constructing form. TTracksAddEditForm = class(TForm) private FsMode: string; FiAlbum: integer; FsTrack: string; public constructor Create(AOwner: TComponent; const AsMode: string; AiAlbum: integer; const AsTrack: string); reintroduce; end; procedure TAudioForm.btnInsertTrackClick(Sender: TObject); begin TracksAddEditForm := TTracksAddEditForm.Create(Self, 'Insert', Albums.FieldByName('Index').AsInteger, TracksView.FieldByName('Title').AsString); TracksAddEditForm.Show; end; The advantage of passing all required data as parameters during construction process is that you cannot accidentally forget to initialize some required field. If some fields are optional, then you can stick to initializing through properties, but using simplified examples before this last one.

Getters and Setters are methods called when you get (read) or set (write) property. In Delphi you don't need to have getter and setter methods. Properties can be directly connected to a field. You use getters or setters when you want to run additional code besides directly reading or writing some field value. Following is basic property declaration without any getters or setters. When you access property, compiler just directly reads or writes from associated field. TFoo = class protected FValue: Integer; published property Value: Integer read FValue write FValue; end; Following is property declaration with setter method (you can have any combination you need and you don't need to declare both methods if you just need one of them) TFoo = class protected FValue: Integer; procedure SetValue(AValue: Integer); published property Value: Integer read FValue write SetValue; end; Because getters and setters are methods, they will be a bit slower than directly using a field. If your setter is just setting a field and does nothing more, then you don't really need it. Same goes for getter. If it just returns the field then it is not needed. procedure TFoo.SetValue(AValue: Integer); begin FValue := AValue; end; If for instance you don't want to allow setting Value to zero, you might have following code in a setter. procedure TFoo.SetValue(AValue: Integer); begin if AValue <> 0 then FValue := AValue; end; You can even raise an exception if you set property to invalid value or similar. The only time when you would need to use getters and setters that just read or write to a field, is when your property needs to be accessible through interface. Interfaces require that getters and setters are methods.

Can you please post that as Q/A on Stack Overflow. It will be more easily found there.

Loading resource strings should be thread-safe. Issue probably happens because you are loading string resource to a shared string variable. Without seeing your code it is impossible to tell exactly.

I don't think you can avoid that 'with' has many pitfalls and replacing code that does not use 'with' with code using 'with' is not something I would recommend doing. You have to ask yourself what is the purpose of FreeAndNil? In the case of local variable the reason (regardless whether we consider it valid or not) is to prevent accidental access of the object instance after it has been released. In such cases we hope that accessing nil reference would crash immediately revealing the obvious bug in the code. However, when you use 'with' you no longer have explicit reference to the object that you can accidentally access outside the 'with' block. Yes, if you are really sloppy, you can still call Free first and that call some other code if call to Free is not the last thing you do in the 'with' block. Main point is compiler hides the reference, there is nothing you can nil here, and compiler will certainly not access the instance outside the 'with' block by mistake.

Calling Destroy in destructor without having nil check first is definitely incorrect code that can lead to memory leaks as destructor needs to be able to handle partially constructed instances. That is why Free is commonly used as it does not require sprinkling destructors with nil checks before calling Destroy. But, very likely this bad code in the destructor is not the primary cause of the issues you are seeing and that there is more going on. If the destructor is at fault, then this means that the instance was not properly constructed and that construction raised an exception. Otherwise the core problem is in some other code we don't see here.

This is appropriate solution. Code that runs inside those anonymous methods will run in the context of the main thread (this is defined by first boolean parameter passed to ExecuteAsync - if you pass False there then that code will run in the context of the background thread). Because it runs in the context of the main thread it will be thread-safe the same way the same way your original function is thread-safe if you run it from the main thread. The only thing you need to pay attention to, is that RESTRequest, RESTClient, and RESTResponse used for making asynchronous request can only handle single request at the time in thread-safe manner. That means, you cannot run UserRESTRequest.ExecuteAsync again while the previous request is not yet completed. Once the request completes, you can reuse those REST components to make another request.

There are two separate concerns here. First, main application code block can exhibit some weird behavior for global variables declared there, including inline variables. If you want to make proper test of some behavior, I suggest wrapping the code in additional procedure. Second, inline variables had (and maybe still have) some problems and sometimes using them does not work as expected. If you encounter an issue, usually solution is to declare local variable instead of inline. Your text case does not work correctly in 10.3.3 when code runs in main code block. If moved to the procedure, then it behaves as it should. In 10.4.2 and and 11.2 it works correctly in all scenarios, so the issue was fixed in the meantime.

They route license increase to Sales and Renewals, and of course, Sales will try to sell you a subscription, but AFAIK you don't have to purchase it and they will bump your license count. Still, this is confusing practice and sometimes you need to be persistent.

What you want to do is impossible in Delphi (without bringing bad coding practice like Application.ProcessMessages in the process) You cannot have function that will return the result of some asynchronous operation. Period. Asynchronous REST request has events that will run when request is successfully or unsuccessfully finished. In those events you can add logic that needs to run as the result of the operation. procedure TMainForm.ButtonClick(Sender: TObject); begin RESTRequest.ExecuteAsync( procedure begin Memo.Lines.Add(RESTResponse.Content); end, True, True, procedure(Error: TObject) begin Memo.Lines.Add(Exception(Error).Message); end); end; Another way, by running request in task or another thread uses similar approach. In such case you would transform your function into a procedure and pass callback (procedure, method or anonymous method) that will run within thread after the request is completed. If you need to run that code in the context of the main thread you can use TThread.Synchronize or TThread.Queue

Bug report is now available to public: Cannot expand columns or rows while expand style is in fixed size https://quality.embarcadero.com/browse/RSP-39228

That is known (reported issue). There is some problem with migrating or applying Welcome screen layout after migration. When you launch IDE click Edit Layout on Welcome Screen. Reset Welcome Screen to default layout and then adjust it again the way you like it. Next time you start IDE it should run normally.

There are some scenarios where which helper will be visible does not work as expected. Last helper in scope is not always visible https://quality.embarcadero.com/browse/RSP-38448

I don't use Python4Delphi so I cannot accurately tell what can and what cannot be done with it in context of threads. But there is one thing definitely wrong in your code and that is constructing TMemo in the context of the background thread. VCL controls can only ever be used from the main thread. Because how that memo control is connected to the Python engine sounds like it is TComponent based. Just being TComponent based does not necessarily mean that it cannot be used in the background threads, but in such cases all related components must belong to the same thread. If we know that TMemo must be used in the main thread, then if you connect it to the Python engine implies that such configured Python engine also must be constructed and used from the main thread. Just because you managed to "make it work" without obvious error (if you ignore the leak), does not mean that this kind of setup actually works.

Flicker in VCL Styles can have many root causes depending on the controls used and their settings. It is hard to tell what exactly causes it here and how to fix it. It seems like here it is caused by a form (or whatever control you have as a main container) clearing its canvas with white (default) color before painting dark style. First step would be to check all combinations of various settings on both form and other controls (especially if you have another container control that host other controls) (you may want to create simple test project for that) like ParentBackground, DoubleBuffering,... Also setting explicit background color to the dark one could help but that would also require adjusting StyleElements and removing seClient from them. If that does not work then another way would be to start playing with WM_ERASEBKGND messages in a container control (frame or panel) that is not styled. Fix mentioned in RSP-24415 has some issues on Windows 11 and non styled controls like combo boxes (I haven't tested with styled ones) that are not properly refreshed and they need their repainting and erasing tweaked. It is possible that you will be able to find some satisfactory fix by simple property changes and figuring out proper combination for that form, but it is also possible that fix would require more complicated hacks.

Right... my brain is fried...

This code is not 100% correct, though. If constructor fails, Free will be called on an uninitialized reference. In order for it to work properly, IdHTTP should be initialized to nil before calling constructor. begin IdHTTP := nil; IdHTTP := TIdHTTP.Create(nil); ... Edit... forget about that.... brain fart... if the exception is raised IdHTTP.Free will never be called.

Weak references are integral part of ARC as memory management system. Because ARC was not main memory management system in classic compiler and was just an "add on", most code didn't require them or could use pointers that are equivalent of unsafe attribute. Support for weak references in classic compiler was added only after they were added on mobile ARC compiler which requires weak references in order to have functional memory management system. Proper coding pattern for ARC memory management would indeed require using weak attribute in the similar circumstances (code) OP had. In other words, if we would rewrite RTL and VCL to follow ARC rules then the OP original code would be the correct one, and we would not need nor have TComponent notification system.

Weak attribute only works on interface references, not on object references. In your case, with TComponent reference, compiler just ignores weak attribute.

If you are having trouble managing objects memory, then using interfaces is a bad option as using them requires even more knowledge. Yes, they can manage memory for you, but there is so much fine print attached I wouldn't recommend it as a starting point. Your drawing object list class also has some unnecessary code as it inherits from generic TObjectList that already automatically handles all that. I have simplified your code and added some basic workflow. uses System.Generics.Collections; type TDrawingObjectType = (doChild, doBackground); TDrawingObjectsList = class; //Forward Declaration TDrawingObject = class private FObjectType: TDrawingObjectType; FDrawingObjectsList: TDrawingObjectsList; public constructor Create(AObjectType: TDrawingObjectType); destructor Destroy; override; property ObjectType: TDrawingObjectType read FObjectType write FObjectType; property DrawingObjectsList: TDrawingObjectsList read FDrawingObjectsList; end; TDrawingObjectsList = class(TObjectList<TDrawingObject>) public procedure DrawDraw(ACanvas: IskCanvas); procedure LoadDrawingObjects; end; procedure BuildList(List: TDrawingObjectsList); var Root: TDrawingObject; implementation constructor TDrawingObject.Create(AObjectType: TDrawingObjectType); begin FDrawingObjectsList := TDrawingObjectsList.Create(True); end; destructor TDrawingObject.Destroy; begin FDrawingObjectsList.Free; inherited; end; procedure BuildList(List: TDrawingObjectsList); var Item: TDrawingObject; begin List.Clear; // build list Item := TDrawingObject.Create(doChild); // set Item data // ... // Add Item to List List.Add(Item); Item := TDrawingObject.Create(doChild); // set Item data // ... // Add Item to List List.Add(Item); end; initialization Root := TDrawingObject.Create(doBackground); BuildList(Root.DrawingObjectsList); finalization Root.Free; end. FDrawingObjectsList list will handle lifetime of any drawing object added to the list, so you don't have to deal with them. Please note that you cannot add same drawing object to multiple lists as it will be released twice, causing exception. Next, FDrawingObjectsList belongs to its drawing object instance and as such it should be constructed in constructor and destroyed in destructor of TDrawingObject. Nobody else should free that list nor assign anything to its reference there is no reason for it to be writeable property. Constructing/destroying part is the simplest and safest possible, there are other more complex coding patterns that involve lazy initialization, but they require more code and there is more room for bugs. Unless you need to preserve memory as much as possible, you don't need to deal with more complicated code. And if needed you can easily add that later on. There is additional mistake in your destructor declaration. You are missing override directive. Without it destructor will never be called and you will have memory leaks. I have created global Root object and populated it in initialization section. You don't have to make it a global, this is just to illustrate how to work with Root object and how to populate its data. BuildList takes TDrawingObjectsList as a parameter and populates existing list without constructing new one. if the list already has some items it will be cleared - you can omit clearing the list if you know you will populate it only once, or you can clear it in outside code before calling BuildList. I am not going to comment on the interface part as it would be a really long write.