David Heffernan

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.

Using packages would achieve that

If you really want to reduce the size of what you deploy then use runtime packages instead of DLLs and you won't duplicate RTL/VCL classes. Likely that would save you far more than you would save by stripping RTTI in the RTL/VCL code that you link, were it even possible for you to do that.

Why would it be duplicated? Why would the same RTTI be found in different DLLs? Why are you singling out the RTTI here? Isn't the fundamental issue that you have duplicated code. If the duplication of the code bothers you, don't have duplicated code. And guess what. You then won't have duplicated RTTI. Or am I missing something?

Why does it make a difference whether or not the code is in a DLL?

@Stefan Glienke is not suggesting that you use a class method. He's just pointing out that the title of this topic is misleading.

You can read the documentation to find out: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Methods_(Delphi)#Class_Methods

I don't think RTTI doubles or triples the size of your executables. I also think that people worry overly about the size of the executables. Certainly worry about this on mobile platforms, but generally on desktop platforms you should be less concerned of the increases due to RTTI.

Presumably it's because of your RTTI settings, which by default allow public methods to be called from RTTI, but not private.