Leaderboard

Yes ist must be the last unit, but the real problem is the IDE not finding the correct Unit....... We should not need a third-party tool for these kind of functionality. It should be work out of the Box, that's the reason for a IDE!!!

If I had a dime for every time some "simple test code" ended in production... 😋

Heh, I actually donated that SafeGuard code to JCL many years ago. They modified the name a little, but not the concept. It works, but I am not sure if all guarded objects will be released on an exception. You'll have to test that. The advantage is indeed that you don't have to cast or anything. You use the original object you created. Yesterday, I even wrote a better approach, using records an implicit and explict casts. That one is certain to work and does not need a cast and the pointer can be used as if it were the actual object (by implicit cast). type IObjectGuard<T: class> = interface function Value: T; end; TObjectGuard<T: class> = class(TInterfacedObject, IObjectGuard<T>) private FValue: T; public constructor Create(Obj: T); destructor Destroy; override; function Value: T; end; SmartPtr<T: class> = record private FGuard: IObjectGuard<T>; public class operator Explicit(const Obj: T): SmartPtr<T>; class operator Implicit(const Ptr: SmartPtr<T>): T; end; { TObjectGuard<T> } constructor TObjectGuard<T>.Create(Obj: T); begin FValue := Obj; end; destructor TObjectGuard<T>.Destroy; begin FValue.Free; inherited; end; function TObjectGuard<T>.Value: T; begin Result := FValue; end; { SmartPtr<T> } class operator SmartPtr<T>.Explicit(const Obj: T): SmartPtr<T>; begin Result.FGuard := TObjectGuard<T>.Create(Obj); end; class operator SmartPtr<T>.Implicit(const Ptr: SmartPtr<T>): T; begin if Ptr.FGuard <> nil then Result := Ptr.FGuard.Value else Result := nil; end; And it can be used like: var Bob, Fred, Jack: TTalking; begin Bob := SmartPtr<TTalking>(TTalking.Create('Bob')); Fred := SmartPtr<TTalking>(TTalking.Create('Fred')); Jack := SmartPtr<TTalking>(TTalking.Create('Jack')); Fred.Talk; Bob.Talk; raise Exception.Create('Error Message'); Jack.Talk; Writeln('This is the end of the routine'); end; As you can see, this also creates guards. They do work, even with the Exception. All are freed when the exception occurs.

Yes. Check that 67372036 is the same as hex $04040404, in other words, 4 bytes, each with value 4. FillChar fills bytes, even if you pass a UInt32 or even a UInt64. It will only take the low byte and multiplicate that.

There is an unofficial download available for MMX Code Explorer with Delphi 10.3 Rio support. Unofficial because it didn't have had much testing yet due to some incompatibilities found during the beta phase. One of this results in the loss of the MMX editor context menu entry. Another big change ist that MMX version 14.x only supports Delphi 10 Seattle and higher. For that, version 13 will still be available for download and installations for older Delphi versions should keep working. I had to make this cut to avoid wasting too much time just to make it work and test it on those older versions. Nevertheless there are some features and bug fixes: Unit Dependency Analyzer is now dockable (so you can see immediately when you introduce cyclic dependencies) New settings page Project Options (currently contains only the setting for Uses Clause Sorting). These settings are stored per project in a separate section of the dproj file. Uses Clause Sorting accepts lists like (ToolsApi,DesignIntf) as one group. This only affects grouping, so the order inside this list is not relevant. Uses Clause Sorting accepts wildcards like Rz* (for Raize Components) or Id* (for Indy) to better handle non-dotted unit names New sorting options "group class members" - keeps the class methods together fix: Wrong result when renaming parameter during Extract Method fix: Add Local Variable now also works with For-In clause fix: Hard coded string scan check for min length works correct now fix: Paste Interface in empty class just works now fix: Consolidated behavior of selected file in Open/Use Unit dialog fix: Creational Wizard follows static/non-static when suggesting destructors Some work has been done for supporting themes, but that is still a long road to go. Please report any bugs and problems found either here or via support@mmx-delphi.de.

Actually, I would hate reading such code. It is distracting and extends the amount to read with no real information gain. It's a TButton - I don't care where it is declared. If I want to know I use Code Insight. There already is such an AddIn and it is called Pascal Expert. The corresponding report is STWA2:

Then you would need a very large truck!

I've always had the need to translate my apps in many languages and it's not something that's already integrated in the IDE. Or better, you can localize your VCL projects but there is no support for FMX (and thus, no support for Android/iOS). I have decided to create a component that works with VCL and FMX and can be used to localize your win/android/ios applications. Once the components has been installed in the IDE, it load a json file with all the various translations. This particular json will be created and maintained using the editor I've created. GitHub repo In the repo you can find a quick install guide, a simple tutorial and the source code. I have decided to use this approach because a .json file is easy to maintain and it's basically a text file so the file size is, in general, not a problem at all. Here's an usage example extracted from github: procedure TForm1.FormCreate(Sender: TObject); begin //The 'jsonResourceId' is the Identifier of the .json file that contains the //translated strings. It has to be loaded in the IDE as resource (RCDATA) Language1.setSource('jsonResourceId'); Language1.setLanguage('Default'); end; procedure TForm1.Button1Click(Sender: TObject); begin Language1.setLanguage('it'); //The caption is now 'casa' Label1.Caption := Language1.localize('home'); Language1.setLanguage('fr'); //The caption is now 'maison' Label1.Caption := Language1.localize('home'); end;

 @Primož GabrijelčičAt least in Rio it seems to work OK: program Project2; {$APPTYPE CONSOLE} uses WinApi.Windows, System.Diagnostics, System.Threading; procedure TestParallel; Var TaskArray: array [1..100] of ITask; begin for var I := Low(TaskArray) to High(TaskArray) do TaskArray[I] := TTask.Create(procedure begin Sleep(100); end).Start; TTask.WaitForAll(TaskArray); end; begin var SW := TStopWatch.StartNew; //TThreadPool.Default.SetMinWorkerThreads(50); TestParallel; WriteLn(SW.ElapsedMilliseconds); WriteLn; Var TPS := TThreadPoolStats.Default; WriteLn('WorkerThreadCount: ', TPS.WorkerThreadCount); WriteLn('MinLimitWorkerThreadCount: ', TPS.MinLimitWorkerThreadCount); WriteLn('MaxLimitWorkerThreadCount: ', TPS.MaxLimitWorkerThreadCount); ReadLn; end. Output on an 8 processor machine: 1370 WorkerThreadCount: 9 MinLimitWorkerThreadCount: 8 MaxLimitWorkerThreadCount: 200 Output with TThreadPool.Default.SetMinWorkerThreads(50); 233 WorkerThreadCount: 50 MinLimitWorkerThreadCount: 50 MaxLimitWorkerThreadCount: 200 With TParallel.&For it works differently and the number of threads created relate to the number of processors.

Nowadays you can use code like this: procedure TForm1.Button1Click(Sender: TObject); begin ScaleBy(14, 10); end; But make sure, that you do not call this too often, because all sizes of VCL controls are integers. That is why, when you call ScaleBy, some rounding happens, and over time you will get loss of precision.

At the moment we have 667 members.

Such a curiosity Code insight caused an exception in Delphi Tokyo, I pay attention to the path in the call stack. See screen:

And they still ship the .jdbg files from the compiler's DEBUG build.

Please amend the title. The title should IMO reflect the contents of the post, which "-------" does not.

Not possible. Only the resource ID, type and content is stored in the executable. In other words: After a resource has been linked into an application there's no way of knowing where it came from.

https://github.com/M3wP/ParticleSystem

This release addresses problems with disabled IDE themes and Delphi 10.2 Tokyo releases below 10.2.3 (and some smaller bugs): https://www.mmx-delphi.de/2018/12/31/bugfix-release-for-mmx-code-explorer/

Of course not. However parallel programming is not a piece of cake. There are so many ways you can shoot yourself in the foot and then blame the library.

Please allow me to disagree. I have made non-trivial use of System.Threading in PyScripter (used by thousands of users) without any problems. The main issue I know of with the library is RSP-11267. You can see a fix in that report, but even without the fix you can work around the issue by using a different mechanism for signalling task to stop As for Parallel.For I have not used it extensively, but you can see some code of mine in this StackOverflow question that I think is now used in a commercial product. An issue with thread creation by Parallel.For (RSP-21177) has been fixed in Rio. Advantages of System.Threading: By far the easiest way to use tasks (as opposed to threads) in your delphi application Nice interface using anonymous methods Avoids third-party dependencies It provides usage statistics that can be used for diagnostic purposes Nowadays, it provides good performance out of the box, but you can still fine-tune the way it works if you are prepared to dig-in It uses state-of-the-art synchronization techniques @Primož Gabrijelčič can correct me on this, but by reading his book "Delphi High Performance", I think, that depending on the type of use, is competitive if not faster than his own OmniThreadLibrary The Parallel library, like many other new features of Delphi (e.g. Generics) got a bad reputation, due to the many bugs in the early days. Unfortunately. trust is easy to lose and very hard to rebuild. But the library does deserves some love from Embarcadero (fixing remaining issues) and Delphi users.

You are working with Unicode strings so you will always get varUString. I don't know what you have against varUString. Surely you don't want to go back to ANSI strings which is what varString represents. VarAsType returns a variant. That's why you need a typecast to obtain other types. The entire question seems massively over complicated. In fact this is a common theme of the questions you ask. Don't take that the wrong way. But my most important advice to you is to try to simplify. You seem regularly to get tied in knots because you don't reduce the complexity in your thinking. In this instance, surely, you should be working with the user input as text. No need at all for variants in my opinion. Simply use TryStrToInt to check if a string value can be treated as an integer. And if there really is some need for variants due to motivations we cannot see then take care to understand what types they can hold. Make sure that you only ever add Unicode strings and integers and therefore only need to deal with those two var types. Raise assertion exceptions if you encounter other types. Make sure that you have good testing in place. Now, you probably think that you haven't got time for testing but what many people don't realise is that testing saves you time. Testing is what allows you to make changes to code without fear of breaking it.

Interestingly, that is quite similar to one of the reasons why "with" was invented in the first place: when accessing the record memory is costly. From Pascal User Manual and Report (emphasizes by me):

Thank you so much for updating this great tool