Vincent Parrett

Project Loom looks really interesting https://developer.okta.com/blog/2022/08/26/state-of-java-project-loom They are calling them Virtual Threads - but the effect is the same - I actually quite like the design they have come up with. Coroutines/fibers/virtualthreads etc are really useful in high concurrency server applications, or under the hood in other libraries - if you are still dropping db components on forms then they probably would not impact you (directly at least).

Just getting back to purchasing a new certificate - finding it very difficult to determine which usb tokens the CA's are providing with the certificates. If anyone has purchased recently, can you post from which site and token kind you got? Also, do not recommend this site - they have substantially ripped off my blog post from Oct 2022 with no attribution at all - I was actually browsing their site looking to buy when I came across the blog post and immediately recognised my work - at least one image was directly taken from my post (byte for byte idendical). Anyway back to the tokens - I do see a lot more references to CA's using Yubikeys now than I did last year - but have still yet to find a resource on automating code signing using one. Hence my concern about which phyical token kind they are issuing.

Of course I am biased, but everyone should have a build server 😉 FinalBuilder makes setting version info trivial https://www.finalbuilder.com/resources/blogs/managing-delphi-version-info-with-finalbuilder

I have a loading flag variable that I set in the form create and then check in the event handlers - clear the flag when done initialising the controls. Crude, but simple.

Yes, I'm aware of those, some things just couldn't be refactored out without major breaking changes. Some of those are also new since I last refactored 🤷‍♂️ That does indeed look like very useful information.

Does it actually support Delphi, couldn't find any mention of it on their site. Also, if I have to contact a vendor for a price I immediately lose interest... that always smells like their sales people rubbing hands - "ooh lets research the prospect and see how much they can afford to pay". There is a saying.. "If you have to ask, you can't afford it".

This ^^^ - it's one of the first things I look to do when refactoring code. Units with 15K lines - well that's a code smell - units that long are horrible to work with. As an example, VirtualTrees.pas from Virtual-TreeView used to be 38K lines long. Reviewing the code it was easy to see why it was so long.. because of circular references between classes (often unnecessarily) and the heavy use of friend access to private variables. Refactoring it was not easy and did require some minor breaking changes - but the code is now much more manageable - VirtualTrees.pas is now only 2K lines and code is split into units that make sense.

Is it just my delphi applications that behave poorly when handling dpi changes? This is when setting high dpi in the manifest to PerMonitorV2. I have verified that the controls (many of them mine) are handling this as they should (override ChangeScale). When dragging the application between monitors with different dpi's, it takes 3-4 seconds while the window flickers and repaints multiple times - the dragging operation pauses while it does this, and then the window eventually jumps to where you actually dragged it. I've been looking at other applications (that ssupport PerMonitorV2) to see how they behave, even explorer stutters a little, due I guess to the ribbon control - but the stutter is around the 200ms mark. Thunderbird seem to repaint twice but very fast. After some debugging, as far as I can tell, this is caused by all controls getting their ChangeScale method called (as you would expect) which results in calls to SetBounds, which invalidates the control causing more painting! TWinControl.ScaleControlsForDpi appears to be doing the right thing (control alignment is a perf hog), but calling EnableAlign inevitably invalidates the control, again. procedure TWinControl.ScaleControlsForDpi(NewPPI: Integer); var I: Integer; begin DisableAlign; try for I := 0 to ControlCount - 1 do Controls[I].ScaleForPPI(NewPPI); finally EnableAlign; end; end; This really show up an inherent design flaw in the vcl, there is no BeginUpdate/EndUpdate design pattern in the vcl that allows a control (or form) to disable child controls painting until it's done. Many controls implement this pattern individually, but that doesn't help in this scenario. The situation isn't helped by my using Vcl Themes either - resize (setbounds) causes serious flicker in some controls and I'm sure this is coming into play here too. I tried to fudge a BeginUpdate/EndUpdate with this : procedure TMainForm.WMDpiChanged(var Message: TWMDpi); begin SendMessage(Self.Handle, WM_SETREDRAW, NativeUInt(False), 0); try inherited; finally SendMessage(Self.Handle, WM_SETREDRAW, NativeUInt(true), 0); RedrawWindow(Self.Handle, nil, 0, RDW_INVALIDATE or RDW_UPDATENOW or RDW_ALLCHILDREN); end; end; It cut's out the visible repainting, but doesn't speed things up much If anyone has any ideas on how to tackle this I'm all ears.

Well kind of, since then I got a new pc which has an amd processor - uprof is nowhere near as useful as vtune 😞 But still, it's nice to have that option now!

Yes, works about as well as it did with my hack, it's essentially doing the same thing. Still nowhere near as smooth as other applications though.

I can't offer advice on where to buy from, but I am also about to go through this process again in the next few months, so interested to hear people's experiences. FWIW, I blogged about code signing with hardware based certificates last year - https://www.finalbuilder.com/resources/blogs/code-signing-with-usb-tokens

If you use CI or automated builds, avoid using yubikeys as there is no way with the client software (built in windows smartkey client) to automate the code signing - you cannot get past the prompt for the certificate password.

This is a known issue with VCL Styles, there are several threads here where this is discussed. It's gotten slightly better with 11.x but still an issue with some controls. See also - https://quality.embarcadero.com/browse/RSP-30639

Strange. I am logged in, and can view issues, but clicking on create redirects me to that page.

Actually they can't

My experience over the last 20 years is that many new devs just do not want to learn delphi. I lost count of how many times people I was interviewing had either never heard of Delphi, or were surprised to hear it was still arround. People want to learn languages which they see a future in, which are modern and supports modern development targets. These days that is the web or mobile.

looks interesting - but for historical reasons I'll probably not use anything from them (currently working on replacing SBB).

Tokens are not free - so vendors will pass on the costs of the token (probably with a nice margin built in) - so in 3yrs time that 5yr cert you paid for will end up costing again, unless they charge you up front for a token now. If you really want to, you can read the info here : https://cabforum.org/wp-content/uploads/Baseline-Requirements-for-the-Issuance-and-Management-of-Code-Signing.v3.2.pdf Not an easy document to read though.

When it comes to certificates, there really is no such thing as a renewal process - you are effective buying a new one each time. I would love to think that once you have bought one from a vendor before, the renewal process (the validation part) would be a little smoother but that has not been my experience in the last 20 yrs. The change to hardware only based keys is fast approaching. Since I blogged about his last year the date was extended to 1 June 2023 - a lot of the vendors had already stopped selling software keys, but with the extension they opened up again. Our standard certificate expires in Oct - I'm half tempted to renew for 3yrs before June 1 just to kick the can down the road a for a while.

Rebuilt all my third party libs and my main project - so far so good. LSP seems a bit better, navigation between projects in a group seems to be working better than before.

Using conditionals compilation in a dpk or dpr is problematic - the IDE does not handle it well.

That's intersting, I tried it today and it didn't work, not sure what I did wrong but will try it again. There is another property for dll's - OutputExt (in the dproj) - in the IDE it's called "Target file extension" - for dcc32 it needs a command line option. Not sure when it was introduced, need to investigate for finalbuilder. Thanks.

DLL projects do not support LibSuffix, so if you want to generate dll's with a different naming convention (with the default being the same for every dproj) - how do you do that if you are just copying a single dproj. Sure you can do that during the copy/generation of the projects if you code it, but where do you configure that (rather than hard coded in the generator)? BTW, I can no longer see UweRaabe/PackageMagician on github?

ok, perhaps it's just me that needs that.

looking through my projects on github - I found one example so far - I need to change the name of the project and output dll for expert dll's - if I'm just rehashing a single dproj then where do I configure that?