Lars Fosdal

There are ways to do that - but none of them are easy or backwards compatible.

Took me a while to get past all the Ios island travel tips before finding this: https://developer.apple.com/design/human-interface-guidelines/live-activities Not sure if supported in Delphi?

IDE and Compiler: Pretty hard! That would not be a recompile. VCL and RTL: Should be possible to port, assuming the Windows APIs are mostly "the same" for ARM as for x64.

If the form designer of Delphi could be called out-of-process, it could be paired with VSCode, and personally, I really like VSCode. Then again, the shortcuts in the BDS IDE are engrained in my muscle memory...

Are you looking for a mechanism that is general, and can be applied to many queries? What is the expected lifecycle for the DataObject, use as discardable parameter only, or extend with more properties and methods and store in other data structures? I assume you want type safety so that an int/float/date/string in the db is represented as an int/float/date/string in the DataObject? The obvious choice is to create a custom class tailored to the query. Upside is performance and custom adaptation. Downside is that you need to implement a new class and handcraft the conversion for every query. A more flexible, but less performant approach, would be to use RTTI to map DB Fields to DataObject properties. either into a class or into a record type. Basically, you would use RTTI to examine the property in the DataObject and use the name to look it up in the query, and the type to make the appropriate copying. However, the distinct needs you have would have to be explained in more detail before we could detail the appropriate solution.

My workmachine is not quite JRE free, due to IBM ACE. But in general, I don't install Java apps if I can avoid it.

Fun observations on the GoTo topic: https://jerf.org/iri/post/2024/goto/

If there is a new version or patch for the IDE, it also will show up on the Welcome page.

Frequent scenario function Test: integer; var i: integer; begin try i := 1; // do something finally; Result := i; end; end; i needs to be initialized before the try block.

Peganza is another possible tool to find out which unit that drags in another unit.

@riev96 cglm.ini file will not help you. There is no license info in that file. SLIP files, on the other hand, are personal, and not to be shared.

Personally, I shun LiveBindings. In my experience, they are slow and fragile. Disclaimer: I haven't tried them since the version of Delphi when they first arrived.

I've never tried working with subforms, so I can't say much about that.

Another benefit is that we usually wait with initializing the frames until they are actually used. Saves init time on app startup.

We use a lot of frames, but we almost always instantiate, reparent and connect them at runtime. Usually, we have a panel as a "host" for the frame, which lets the panel deal with the in-form alignment, so that the frame can use alClient. As @Davide Angeli mentions, loss of events has been a key factor for deciding to do it that way.

MS Copilot might be able, but, yeah, elbow grease FTW.

That feels almost like you're advocating the use of FreeAndNil 😄

Which again makes me wonder why not SELECT SUM(Field1) AS Total FROM YourSourceView but as mentioned, I suspect the example differs from the real world need...

Doh, you are right, Uwe!

Not sure if Totalling fields is the best example for the use case, as that is far more efficient to do in the queries By API, do you mean the interface section of the class? The challenge is that you need a predictable way to associate the fields with the field name. You could write a routine like this procedure ConnectFields(Query: TDataSet; const Fields: TArray<TField>; const Names: TArray<string>); begin Assert(Length(Fields) = Length(Names), 'Number of fields and number of names must match'); for var ix := 0 to Length(Fields) - 1 do begin Fields[ix] := Query.FieldByName(Names[ix]); if not Assigned(Fields[ix]) then raise Exception.Create(Format('Field %s not found.', [Names[ix]]); end; end // usage var Field1, Field2, Field3, Field4: TField; begin ConnectFields(Query, [ Field1, Field2, Field3, Field4], ['Field1', 'Field2', 'Field3', 'Field4']); ... which doesn't save you that much code, really.

Are you doing this within a class or multitude of classes, or is it within a method or multitude of methods? Is TField your own class?

So it is not about visual use? If not, I need to understand more about how the TFields will be used.

There are many ways to do this. Will you need to reference the TField components in any way, or are they just for display or editing? Will there be a need for different data format handing for different fields? Different titles, sizes, validation, etc?

I got a Lenovo P16 (i7)64Gb/ 1TB+500GB Workstation Laptop, and run "corporate" Windows 10 latest patches on the WS and Win11 Pro on a Hyper-V VM. This machine is my regular work machine and it runs an SQL Server instance on the primary OS as well. I also have a private MacBook Pro M1 16" with 32GB and 2TB, running Parallels and Win 11 for ARM on a VM, and RHEL on a VM. Delphi installs and runs just fine on both Win 11 VMs. Interestingly, the MBP is faster than the P16 for the VMs, staying cool and silent, while the P16 spins up the fans like a turbine. I haven't tried dongles on my VMs, since signing happens on the corporate build server, but both VM hosts can pass through USB ports, so I would expect it to work.

In theory, the AIs might be able to pull out such data.