David Heffernan

I think the way I phrased the question should help your intuition! 😉 It's always worth double checking, but a lookup table involves working the answer out before you compile. I would imagine it is hard for runtime code to ever beat that.

How do you think it will compare against a lookup table? How would you expect computing an answer at runtime compare to computing the answer before compile time?

No guarantee that an out of bounds array access leads to an exception. You have just been unlucky that you've seen one every time you ran your code. Once again, nobody should ever write code like that.

Holding the nibble binary text in a fixed length array is rather nice, I approve of that. Good stuff.

Fields of a class are default initialised upon instantiation. That means, for an integer, a value of 0. If you want to assign a different value, you need to do that yourself, in the constructor.

I'd probably write it something like this: function HexToBin(const HexValue: string): string; const BinaryValues: array [0..15] of string = ( '0000', '0001', '0010', '0011', '0100', '0101', '0110', '0111', '1000', '1001', '1010', '1011', '1100', '1101', '1110', '1111' ); var HexDigit: Char; HexDigitValue: Integer; Ptr: PChar; begin SetLength(Result, Length(HexValue) * 4); Ptr := Pointer(Result); for HexDigit in HexValue do begin case HexDigit of '0'..'9': HexDigitValue := Ord(HexDigit) - Ord('0'); 'a'..'f': HexDigitValue := 10 + Ord(HexDigit) - Ord('a'); 'A'..'F': HexDigitValue := 10 + Ord(HexDigit) - Ord('A'); else raise EConvertError.CreateFmt('Invalid hex digit ''%s'' found in ''%s''', [HexDigit, HexValue]); end; Move(Pointer(BinaryValues[HexDigitValue])^, Ptr^, 4 * SizeOf(Char)); Inc(Ptr, 4); end; end; Some notes: A case statement makes this quite readable in my view. You really don't want to be wasting time using Pos to search within a string. You can get the value directly with arithmetic. I prefer to perform just a single allocation, rather than use repeated allocations with concatenation. You might want to consider how to treat leading zeros. For instance how should you treat 0F, should that be 00001111 or 1111? I'd expect that both would be desirable in different situations, so an option in an extra argument to the function would be needed.

Ugh. You can't rely on getting an AV. Don't ever write code like this.

Define a simple map from the 16 hex digits to the 4 character binary strings. Iterate over each hex digit and concatenate.

So it doesn't say that the dpr file is missing. It says that the system unit is missing. This is possibly an issue with how you installed delphi. Or some erroneous settings in the existing project files.

Absolute insanity to attempt cross process window parent / child relationships. Not supported by MS amongst many many problems. Read what Raymond Chen has to say on the matter. It blows my mind that people keep on suggesting this.

Cross process window parent relationships are something that in principle can be done, but in practise seldom work out. In reality the shortest route to your goal is almost certainly to replace the charting code. With an added benefit of also being the long term solution.

"Can 32bit dll with Form/Frame be used in 64 bit project?" No. You can't mix different bitness modules in the same process.

I've spoken to Marco enough times about this. Perhaps they'll have the sense to invite me anyway.

I can't sign up for the beta because I don't have a subscription. Does partaking in the beta have much impact?

I also would be ecstatic if this was delivered effectively.

Yeah in virtual mode you can't query the control, because it does not hold the data. You just query the data structure that does hold the data, a string list in your case.

Why are you trying to access the list views items when in virtual mode? That's directly against the concept of virtual mode.

try Foo := TFooBar.Create; ... finally Foo.Free; end; Consider the above. Suppose that TFooBar.Create raises an exception. In that case the finally block is executed, and `Foo.Free` is called on an uninitialised variable (Foo). That leads to undefined behaviour. So the correct pattern is Foo := TFooBar.Create; try ... finally Foo.Free; end; Here, if TFooBar.Create raises an exception, the try is never reached, and so the finally block never executes. Now another pattern was also mentioned Foo := nil; try Foo := TFooBar.Create; ... finally Foo.Free; end; This is also valid, because Foo is initialised before the try executes. And so in case of constructor exception we would call Free on a nil reference which is fine. However, this pattern is pointless and should be avoided in the scenario here where there is just a single object. It is useful sometimes if there are multiple objects and you want to avoid deep nesting. A better example of using this pattern is if the object is created conditionally: Foo := nil; try if someTest then begin Foo := TFooBar.Create; ... end; ... finally Foo.Free; end;

That would be nice. But in my experience, developing a program to work well with NUMA requires detailed knowledge from the programmer. I personally don't think there is any way round that.

You aren't going to get anywhere by just adding a new library, compiling, running, and hoping for magic. It's going to require in depth understanding if how to configure and use any library and how to adapt your own code.

Just remembered, doesn't FastMM5 have some features to support NUMA? Worth a look.

Yeah, NUMA requires a completely different memory allocation strategy. When I faced this problem I concluded that there was no memory manager available that could do what I needed. So I wrote my own that is essentially a wrapper around the Windows heap manager. The trick is to have different heaps for each NUMA node.

Can you describe how you want to perform this comparison? How you want to compare the 13 bytes in the array with the single byte in the AnsiChar variable.

Can you be precise about the types here. At the moment all we know is the name of the variables.

Packages do work. If you can't make them work in your setting, that's probably more a statement about the constraints that you are imposing.