David Heffernan

Same as always. Numerical programming. And when there exists huge amounts of code in a language, it can be hard to leave. A phenomenon well known to us Delphi programmers!

Different use cases will suit different libraries. You gave no indication of what your motivations and goals are.

Or when calling into a Delphi DLL.

That's Embarcadero's fault. They've known how to fix this for at least 10 years, and my patched version of the RTL fixes it. That said, the real issue isn't really a language issue. It's a platform issue. It all stems from the way floating point is implemented on x86 and x86-64 hardware.

Clearly the OP is using short string because the compiler says so. My question is to the OP. Why use short string?

Is there a reason to use shortstrings? It's 2024 now....

Does it even compile, and if so what does it mean?

What problem does this solve?

Delphi doesn't know that you want [] to be an array rather than a set. Because the language has been designed iteratively and there is ambiguity. Delphi literals are a bit of a mess. In any case are you sure that you want to use = with a reference type? That's reference identity and not value identity. You will need to test for Length(a)=0 or not Assigned(a) or a = nil

Top down memory allocation, which is what I presume this setting is, was how I found most pointer truncation bugs back in the day. It also broke just about every anti virus software that we tried, until I settled on the MS tool!

It's just that the reason isn't to do what you did

Please provide a link to this post and if it's wrong then we can correct it. Or perhaps you didn't interpret it correctly.

Hmm, maybe it's not fixed .....

Well, good, they fixed that one!

FWIW this is what I see with Delphi 11.3, and toolbar drop downs. I'm actually at 175% dpi, and running Delphi DPI aware. If I click on the left hand side of the drop down button next to the open icon, I get a file dialog. If I click on the right hand side of the drop down button I get the menu dropped down. I think that the same happens in my app if I use the VCL menu code, although it's so long since I looked that I don't remember the exact details. I'd be interested to know if the latest versions of Delphi IDE manage to handle this drop down hit detection correctly. Other problems I saw with VCL styles drawing menus was failure to scale check marks in high dpi scenarios. I ended up patching Vcl.Menus so that it uses Windows to draw the menus rather than VCL styles which even for the standard Windows theme is what you get for menus. This was gnarly with high DPI because I need to create and cache PARGB32 bitmaps, because that's how you get alpha blended menu icons in system drawn windows: Themed menu’s icons, a complete Vista and XP solution (updated) - nanoANT

Maybe they fixed it. My experience has been that every time they fix one bug, there's another one around the corner.

I tried recently and the toolbars still aren't right. Classic example is the behaviour of drop down buttons which open menus in high DPI. Try the file open drop down in, say 250 or 300%. You have to click on the very right hand side of the drop down. Context menus are a mess too. Coming up on the wrong screen. It mostly works, but there's just enough that doesn't for it to be no good. I'd like to offer my clients a dark mode but cannot.

VCL styles are still not fit for purpose and probably never will be

That's evaluated to a quietnan at compile time, just as it has always been

Ultimately, if exceptions are masked then there's no behavioural difference between SNaN and QNaN. Seems an odd design choice for x86 to change the NaN type though. Presumably there's a reason I'm not aware of. Normally I think I know my way around floating point, but when exceptions are masked is the great unknown for me. I've never been there. And when I explored moving to 12 I just unmasked them!!!

I don't have anything later than 11.3 installed. So there are likely changes that I'm not familiar with. The one thing that jumps to my mind is the ABI. Floating point return values travel via ST(0) in x86 but by a general purpose register in x64 (can't remember which). This means that it has traditionally not been possible to return SNaN by function return value in 32 bit, although it is possible to in 64 bit. That's because loading into ST(0) triggers invalid op. But now fp exceptions are masked by default. Anyway, that's all I know right now, not at a computer.

Not even sure if this is a bug.

I don't know why you don't attempt to debug your code.

You don't need this tool.

The original code looks fine. But you only showed an excerpt. Show a reproduction of an error and then somebody can tell you what is actually going on. Don't fix things until you understand them.