Leaderboard

Definitely not ! Use UIntPtr (Alias to NativeUInt) which is a type especially created for that purpose.

No, it is not.

In your example, HTML is a field variable of the TReportEnums structure with the specific type defined to be THTMLType. You are trying to access it as an Enumeration and not as a variable. Delphi offers meta classes where you can define a variable to be a class type such as: TMySomethingClass = class of TMySomething, and you can define a variable of type TMySomethingClass, but this only works with classes. AFAIK there's no similar thing for records. Not a great solution, but if you could group your defines in one class you could get code completion from a master class like: TMasterRecordTypes = class type THTMLType = (htTemplate, htStatic, htHeader, htCustom); TSecondRecordType = (srOne, srTwo, srThree); end; vHTMLReportType := TMasterRecordTypes.THTMLType.htTemplate; Or just put all your related record types into a particular unit and use the unit name as the scope, which is how it's normally done. vHTMLReportType := MyUnitName.THTMLType.htTemplate;

He wants to _find_ the appropriate enum and not obfuscate it deeper. It should be a task for the IDE which fail big time in it, even the help provided by emba is trying to hide which are the possible values. Still, I would not say that your example is a "better way" but you are mixing variables with types. So it should be something like: type TGEnums = class type THTMLType = (htTemplate, htStatic, htHeader, htCustom); end; var x: TGEnums.THTMLType; begin x := TGEnums.THTMLType.htTemplate; --- or --- type THTMLType = (htTemplate, htStatic, htHeader, htCustom); TGEnums = class type HTMLType = THTMLType; end; var x: THTMLType; begin x := TGEnums.HTMLType.htTemplate;

This is how it looks like for me (Delphi Rio 10.3.3). Unit Aliases is something I have never needed to use so far.

I have everything installed on my main PC that you mentioned above ( except VsCode ) and it work with no problems. I also have a lot of other tools ( php,composer,laravel,swoole,servers apache ngnix, android studio, + a lot of android vm's and more....) and everything works fine .. I mean if u dont want to risk and u have time install it on separate VM I never used Chocolate and i installed everything manually .. Thats all that i can say from my experience, hope it helps

Wouldn't be the NativeInteger the right cast for a pointer ? Matching the right bitness on 32- and 64-Bit machines, to the same pointer bitness ?

You missed step 1. Step 1: identify the bottleneck. It's a common mistake.

The best test bench is your program. Try both variants on real data and compare results.

You don't need to but you can. It's not really a SVG imagelist. It's an imagelist that also supports SVG meaning it can contain SVG, PNG, BMP, etc. This also mean that you can have one imagelist for low-res containing a mix of SVG and PNG and another for hi-res. I find that PNGs are often better for small (e.g. 16x16) low-res images.

Formatter.EXE, the Command Line Formatter

The Delphi integrated formatter offers that as well.

My own personal logic would be: author doesn't support minimal readme and description => he is very lazy => project will be very poorly maintained => I'll better look for another one.

Then maybe now is a good time to upgrade to the latest Delphi version😉

Well, if you come to Pasadena, you can visit and see it running beautifully 😀 We have a bank of 5 servers. Each one is 24 cores and 200GB of ram. They each run about 75 headless windows machines each in a citrix environment. We have 4000 visual tests that are run multiple times per day and it takes about 1.5 hours to complete a full run on that bank. The key is that we wrote our own GUI automation over the years. All we do is send keystrokes and mouseclicks to the UI. However, there are several caveats that we have developed over the years to make it work. 1. the test case NEVER contains screen coordinates. We have methods like ClickOnMenu(aMenu:TMenu,'File|Open'). That method queries the TMenu and finds coordinates of the 'file' menu item, clicks on it and finds coordinates of the open menu item, then clicks on it. Similar is ClickOnControl(form:TForm;control:TControl). The testing system finds the open form, finds the control. finds the coordindates and then sends a mouse click in the middle of the control. There are other variants if you dont exactly want to click in the middle. So in the test is says ClickOnControl(form1, form1.button1). That way, if the developer changes the form, i.e. moves button1 around, then the test is fine. If they delete button1, the test stops compiling. That being said, we wrote tons of these types of methods that are specific for the controls we use, to accommodate their oddities, like virtual string tree etc. It did not happen overnight. 2. We have a small delay after every input except certain cases. This small delay is generally enough. We also have hooked into the idle processing of the program so after sending a mouseclick / keyboard press it waits for the onIdle so the program is not processing more messages. There are a few more tricks as well. However, the upshot is that we rarely have a problem with timing any longer. For really variable processes, we have our GUI automation thread wait on a TEvent in the program and the program triggers the TEvent when the process is done so that the test knows to continue. But that is rare. Not so similar from an end user, that just sits there waiting for the screen to refresh. So, the upshot is that it was a lot of work, and likely only worth it if you are going to maintain the same program for a long time. But it can be done and today, new developers in our company have no idea the hard work that went into it and they just write scripts in a fairly high level way and the infrastructure does the rest. The test cases find the problem they are designed to test, about 50% of the time. The rest of the failures are because of bugs that are involved in things the test was doing to get to the point where it was trying to test. The other upshot is that we very, very rarely have regressions. The vast, vast majority of bugs that make it to production are in new features that have not (in hindsight) been sufficiently testing.

I'm using Spring4D all the time. Run the Test without debugger...... for me It is one of the best, correction, the best library for Delphi.

The first point of entry is the readme. If the readme doesn't convince a potential user then I'm pretty sure they won't bother with the source. We're all busy. Why should you care? Because more users means more people that are likely to contribute.

Would be nice to localise the disabling of overflow checks to just the hashing routines.