Anders Melander

This might sound crazy, but hear me out 🙂 Buy: A nice Mini-PC mainboard with integrated graphics. A CPU, some RAM, NVMe SSD. The smallest fanless PSU that meets the power requirements of the above. Put it all in cardboard box (or whatever). Remember to make some holes for airflow. Profit! You can do this really cheap and I can testify, from personal experience, that it is a possible setup. I once worked on a system a bit like this for six months. I didn't implement the luxury version with the cardboard box though. Instead I just placed the mainboard (which was full AT size) on a wooden breadboard and bolted all the components to it. Why did I do this, you ask? Well, my wife had a meltdown over something related to time spent with her vs. time coding (Women, pfft! 🙄 Amiright?) and completely smashed my full tower case with a rolling pin, I shit you not. Anyway, of course you still have to decide on the specs for the components but you will have to figure that out for yourself. It's impossible to give any clear recommendations as the specs will depend on what and how you use the system. Just get the best you can within your budget.

How does that address "I am thinking of buying a mini PC"?

Okay, so I would recommend that you simply start with the RTL TThread. Mainly because it appears that you have no prior threading experience (or you probably wouldn't have asked in the first place) and it would be best to learn the basics before trying something more advanced. Threading might seem easy but it's actually really difficult if you don't know and understand the many things that can go wrong. I would also avoid the various 3rd party threading libraries, even though I'm sure they can do some nice things, so you don't introduce external dependencies and get locked in to their way of doing things. Once you know a bit more you can make an educated decision about which way to go. The PPL was introduced in XE7 but I think it took a while for it to become reliable(ish). I stayed clear of all the versions between XE2 and Delphi 10 so I don't have first-hand experience with those versions. These days I seldom use TThread directly. Most of my thread tasks are short lived so they benefit from the TTask thread pool (and TTask is just so much nicer to use).

You might be right but that's not the impression I get from the topics posted.

OP is on Delphi 2007...

To be clear: You can insert a stream of pre- and postfix bytes by declaring pure asm functions containing these bytes just before and after the function. You just just can't control the exact offset of them. The compiler is free to place them anywhere (it doesn't) and it's free to take alignment into account when placing them (which it does). For example this code: procedure Prefix; asm db $01, $02, $03, $04, $05, $06, $07, $08, $09, $0a, $0b, $0c, $0d, $0e, $0f end; procedure Test; begin WriteLn('Hello world'); end; procedure Postfix; asm db $11, $12, $13, $14, $15, $16, $17, $18, $19, $1a, $1b, $1c, $1d, $1e, $1f end; begin // Dummy references to ensure prefix/postfix procs get linked in if (@Prefix <> @Postfix) then Test; end. is compiled to this: Project46.dpr.9: db $01, $02, $03, $04, $05, $06, $07, $08, $09, $0a, $0b, $0c, $0d, $0e, $0f 00000000009BEEF0 0102030405060708090A0B0C0D0E0F Project46.dpr.10: end; 00000000009BEEFF C3 ret 00000000009BEF00 <...junk...> Project46.dpr.13: begin 00000000009BEF00 55 push rbp 00000000009BEF01 4883EC20 sub rsp,$20 00000000009BEF05 488BEC mov rbp,rsp Project46.dpr.14: WriteLn('Hello world'); 00000000009BEF08 488B0DB1310000 mov rcx,[rel $000031b1] 00000000009BEF0F 488D1526000000 lea rdx,[rel $00000026] 00000000009BEF16 E8B573FFFF call @Write0UString 00000000009BEF1B 4889C1 mov rcx,rax 00000000009BEF1E E80D75FFFF call @WriteLn 00000000009BEF23 E8E85FFFFF call @_IOTest Project46.dpr.15: end; 00000000009BEF28 488D6520 lea rsp,[rbp+$20] 00000000009BEF2C 5D pop rbp 00000000009BEF2D C3 ret 00000000009BEF2E <...junk...> Project46.dpr.19: db $11, $12, $13, $14, $15, $16, $17, $18, $19, $1a, $1b, $1c, $1d, $1e, $1f 00000000009BEF60 1112131415161718191A1B1C1D1E1F Project46.dpr.20: end; 00000000009BEF6F C3 ret The problem here is the <...junk...> it inserts to maintain alignment. If you are really desperate it should be possible to take this into account and, given the offset of the pre- and postfix markers, find the actual start and end of the function if that is what you're after.

You are going to own that claim yourself because the quoted changelog doesn't confirm anything of the sort. They just mean that they need a Delphi ARM64 compiler before they can implement top-level menus.

The point was that since it was originally (refs "to begin with") declared as an integer, not a nativeint, the original intent obviously wasn't that it could be used for pointers. It just so happened that it could.

Except it wasn't... Prior to XE2 it was an integer.

You can't seriously expect them to change the compiler codegen based on the information in that issue (or this thread for that matter).

*zing* 🔥

You need to capture the mouse in order to receive messages for mouse activity outside the form. See also: SetCapture You should be able to figure it out with that info.

And yet you asked it.

Nice and simple. Lovely!

FWIW, I once, as an experiment, implemented string interning using a dictionary in an application that contained hundred of thousands of strings with about 75% duplicates. It was a 32-bit application which was hitting the 4Gb limit and running out of memory. Sure, it saved a few hundred megabytes but the overhead of the dictionary lookup completely killed the performance. With 64-bit and virtual memory I can't see any reason at all to do this exerciser.

It's still hardware and nothing in the various software APIs require the use of shortstring.

Um.. RS232 is a hardware standard.

The TFDParam parameter is an object reference (i.e. a pointer). You are not modifying the object reference; You are modifying a property on the object. So drop the var. I would also change the TComboBox parameter to an integer and pass TComboBox.ItemIndex instead; There's no reason to create a dependency on TCombobox when all you need is the ItemIndex.

Btw, you should probably check out Agner Fog's vector library. Here's the pow implementation (but RTFM ) https://github.com/vectorclass/version2/blob/f4617df57e17efcd754f5bbe0ec87883e0ed9ce6/vectormath_exp.h#L1493

I don't use C++ anymore but I assume that like everybody else (Delphi for one) it's using pow(x, y) = exp(y * log(x)) and I doubt that you'll find anything faster than that. Here's an implementation: https://github.com/lattera/glibc/blob/master/sysdeps/ieee754/dbl-64/e_pow.c Looks pretty optimized to me. Of course you'll need a decent compiler to turn it into something that actually takes advantage of the processor features.

It's impossible to suggest a good solution without knowing more about the context. If it's just a case of either setting or clearing a TParam value then just pass the TParam to the function and let the function operate directly on that.

I'm pretty sure that anyone asking for help with something as basic as this isn't handling, or even aware of, NaN. Regardless, I personally wouldn't solve the problem with a magic value.

NaN

I don't believe this is true at the Windows API level; AFAIK Windows will not destroy a window handle unless you tell it to do so. But as you know, the VCL on the other hand will do so if it needs to change some attributes that can only be set by CreateWindow(Ex).

If you mean the, undocumented, TextScaleFactor setting then no, that doesn't do it.