A.M. Hoornweg

Exactly.

Just declare class procedure MyFormShow(Sender: TObject); STATIC; That way the method does not have a hidden "self" parameter. Having no "self" parameter turns the class method into a regular procedure inside the namespace tTest (it is no longer a "procedure of object"). Static class methods are unable to access any members or methods that require a "self" parameter.

I for one would find it an advantage if stuff like local pointer variables would default to NIL, it would make the language just a little bit more memory safe.

As far as I know, when an object is created all its members are filled with zero. And for stack variables, all managed types are filled with zero upon entry of a method. However, wouldn't it actually save CPU time if Delphi simply wiped the local variables area of the stack upon entry of a method (a known fixed number of bytes - a simple REP STOSD will do) instead of determining which local variables are managed types and then wiping those individually?

Hello all, We're a small company, our Delphi developer team works largely remotely and I'm one of the members who actually lives in a different country from the rest of the team. We must frequently release updates of our various software products. Each team member uses Finalbuilder and Signtool to automate the process of compiling, code signing and generating setups. Some of our products consist of dozens of executables and dll's so the automation of the build-and-sign process is a must-have. Our Digicert EV code certificate expires in February 2025. We're now faced with the problem that certificate providers seem to expect you to have the certificate on a USB device which is kinda unpractical if developers work remotely from different countries. We need common access to the certificate and we need to be able to automate the signing process. I'd very much like to hear from other developer teams who are in the same boat, how they tackle this problem.

Hello all, just a short question: is System.Threading.tParallelarray not usable with interfaces? The following won't compile: Type iDownloadJob=Interface [{3d24b7a2-6111-46e7-a281-7fdc318be5c4}] procedure Download; end; procedure test; var x: array of iDownloadJob; temp:Integer; begin // ..... fill the array here .... temp:=tParallelArray.ForThreshold; tParallelArray.ForThreshold:=1; try tParallelArray.&For<iDownloadJob>(x, procedure (const AValues: array of iDownloadJob; AFrom, ATo: NativeInt) var i:NativeInt; begin for i:=AFrom to ATo do aValues[i].Download; end); finally tParallelArray.ForThreshold:=temp; end; end; It would be just my luck if such a nice new feature doesn't work for me 😞 .

This is a totally weird experience. Tuesday my compiler kept saying "There is no overloaded version of tParallelArray.For ... that can be called with these arguments" and I searched in vain for the cause. Then something came up and I had to abandon the project for a few days. Today I resumed working on it and it compiled just fine - I had changed nothing! I think that something got corrupted in the memory of the IDE process on Tuesday and the reboot just made it go away... I do have regular exceptions in the IDE since installing the inline update for 12.2 (build nr 29.0.53982.0329). Anyway, I'm thrilled that I can continue now.

Am I right that the the internal source code formatter is no longer there? It is still documented as a feature on Embarcadero's site though: https://docwiki.embarcadero.com/RADStudio/Athens/en/Source_Code_Formatter Is there a third-party formatter that handles generics correctly?

I have updated my Delphi 12.1 Enterprise to version 12.2, selecting the Windows, Android and Linux platforms in the installer. But the Linux platform seems to be missing in the IDE and fmxLinux is unavailable in GetIt. Am I missing something?

That's not what I read: "DigiCert KeyLocker is a cloud-based service that helps you generate and store the private key without a physical HSM (Hardware Security Module). It was developed to reduce certificate administrators’ efforts and strengthen private key security." (https://signmycode.com/blog/what-is-digicert-keylocker-everything-to-know-about)

I'm very interested!

The certificate is on the company name., having multiple ones would multiply the costs. I'm just reading up on Digicert Keylocker, which appears to be a cloud-based solution. If I understand correctly, Digicert keeps the USB device with the certificate and users can access it remotely. https://signmycode.com/blog/what-is-digicert-keylocker-everything-to-know-about https://www.digicert.com/blog/announcing-certcentrals-new-keylocker

We moved away from a build server several years ago; we work on several independent projects and kept getting in each other's way.

Same here. Works in 32-bit, does not work in 64-bit.

Hello all, I have the situation where I have a dynamic array containing small fixed-size records (17 bytes in size, no managed types). The array behaves like a queue, new elements get appended at the end, old elements get removed from the start. This happens 24/7 and the application is mission critical. There may be anything from 0-5000 elements in the array. My logic for appending is simply "MyArray:=MyArray+[element]" and my logic for removing the oldest element is simply "Delete(MyArray,0, 1)". I'm worried that there might be a risk of excessive memory fragmentation and I'd like to hear your opinions on this. Thanks in advance!

Access to the queue is only done by a single thread. A circular buffer is not handy because this queue keeps growing until a certain condition is met. Then a number of elements are removed from the beginning of the queue until the condition is no longer met.

My worry is, whenever I delete an element at the beginning, would the RTL just allocate a new block and copy the old array minus the first element to the new location? .

Hello all, I am using Delphi 11 & 12 inside a VMWare Workstation 17 Pro VM which currently runs Windows 11. This VM has the VMWare tools installed. This setup used to work extremely well but since about 6 weeks I notice that VCL drawing is abnormally slow, both inside the Delphi IDE itself and inside my own programs. This slowness only happens in a VM running Windows 11, it does not happen in other VM's running Windows 10. I attach a GIF file here. It shows what happens when I switch the Delphi 11 IDE between code view and form view. The form is just a simple tFrame with a groupbox and some checkboxes, nothing fancy. You can literally see the checkboxes being drawn. I have already tried a "repair installation" of the operating system but that fixes nothing. I'd be grateful if anyone has an idea what might be the cause of this.

I've found the solution. Turning OFF 3-D acceleration in the VM made the issue disappear completely!

Just out of interest, what tool do you use to create GIF's like this?

Hey, that's actually really cool!

You could put a tScrollbox on your form and put the rest of your components on top of that. The scrollbox can be larger than the form itself and you can simply use the scrollbars to scroll the components into view.

Hello all, I've noticed that an application I'm working on was behaving differently when compiled in Delphi 11 or 12. In Delphi 12 I was getting all sorts of overflows and unexpected behavior. It took me a while to figure out the cause. Now the surprising thing: The cause wasn't even in this executable I was working on, it was in a DLL that my program is using. This DLL was built with a previous version of Delphi. This particular DLL expects that a FP error such as a division by zero will throw an exception. A breaking change in Delphi 12 is that the executables it produces mask the FP exceptions. This change in behavior affects all code running in the process, including all DLLs. In other words, this DLL no longer threw exceptions where it was supposed to. My workaround was to re-enable FPU exceptions in the executable and the situation instantly went "back to normal". But it got me thinking, how does one write code that copes with both FP situations and can run safely with *any* Delphi version? Should I do something like this? Try c:=SomeHighlyComplexCalculation(); if IsNan (c) then raise eDivByZero.Create('Something went wrong'); except // the exception is triggered either automatically (Old Delphi version) or manually (New Delphi version) end; Currently, my gut feeling tells me to manually enable FPU exceptions in all my Delphi exe projects to prevent such nasty surprises in the future. I use tons of tried-and-tested DLLs written in Delphi and I really don't want them to break.

It would be a can of worms for me I'm afraid. I am thinking of all my Delphi COM DLL's that expose interfaces and class factories (see image). Each interface is basically an object that can have dozens of methods so we're not talking about just a few functions, it's more like hundreds of exposed methods. And many of these methods call each other, which complicates matters further because setfpcr/restorefpcr would have to support nesting. And multi-threading would make matters even more complicated.

"Take control on entry and restore on exit" would be very cumbersome in the case of DLL's written in Delphi. It would need to be done in every exposed function / method. (edit) or at least in every method that has to do with FP calculations.