Rollo62

You could use a setter for sQuery, that sets up the SQL before showing the form. That would not nee FormShow.

Perhaps they already have better AI than you and me 🤔

Thanks, this is a great library and introduction. Can your libFPC also be configured to generate and run an Pascal code in memory at specific periodic schedules, lets say like every 1st of April or so?

Yes, good choice too, but I would prefer a slightly more modern PC, like the Sinclair ZX81 Basic language: https://github.com/andrivet/zx81-typescript-emulator/blob/master/Documents/Sinclair ZX81 BASIC Programming.pdf This is at least an evolved high level language, whereas RPG is probably not. Also the vast amount of memory in this product makes it mode suitable for modern 3D and AI tasks, IMHO.

Yes, of course. My consideration was that Macos & Co might have their similar credential API worth to abstract then here under one umbrella: Nevermind, thanks for clarification.

Thanks, nice piece of code. 👍 I have two questions: 1. You keep the secret as String in the class, wouldn't it make sense to hash it, so that at least not a simple memory dump might offer a readable password? 2. You're implemented Windows-specific, are you going to implements other platforms too ( it looks a bit like that ) ?

I'm not on D12.3 yet, but 12.1 + Patches, and I've made some tests with TThreadedQueue in the past, finally moving to Spring4D. Another useful technique for your decision could be, try to grep where this class is used in other projects or libraries: - I only find one occurence in Datasnap.DSServer. This seems not to be a well tested class yet, IMHO.

I would agree, if we talk about 100% compiler managed code. BTW: This warning really only appears with custom CMR, if I replace this by a "normal" Delphi Record, then there is no warning, which I would expect too. Now I can use this warning to find places where custom CMR might cause issues, which would become handy to debug sporadic, unclear issues maybe, where you got no idea where to look at. So I like the warnings and don't think all of them were bogus, at least for the CRM records. Imagine you have an only half-implemented CMR record assignment operator, then you might be pointed to this issue a bit. This could be a perfectly fine, accepted behaviour by design, but good to see these warnings as reminders. Yes, I could make a hint about such special-design decisions in the record itself, but then I wouldn't backtrack the places where it is used so easily. Nevermind, if there is nothing wrong with the code, I will keep it like that. I was looking for a perhaps better implementation, like SmartPointer, Getter, or the like ... returning plain Records as result is maybe never the best idea, only for readability. But the overhead of those other solutions over a simple Record doesn't make it better, IMHO ( and yes, I'm not looking for highest-performance design here, just normal code ).

Thanks, but I think this can still have a true core. From my understanding, this warning tells us, that there is a temporary object, which will be automatically assigned by the custom assignment operator, where the compiler cannot really check the assignment, because its "custom". So in my opinion this warning maybe has some good reasons behind and could be helpful. It would be great if I could take control with the [Result: unsafe] attribute, by telling the compiler: "Nevermind, I know how to handle this case, just keep silent about it." Since I only look into this from time to time, I keep it like that, but maybe for some hard debug sessions this might be useful to switch it on and find some good hints to look into. I'm still in a 50:50 position here.

Perhaps you don't have activated them in the project I try from time to time to cleanup all warnings, but with these "unsafe" checked I've got a huge list with myriads of warnings. Thats why I try to find a better design, how to remove them. Since I usually see warnings same as errors, I try to remove them all, but with these settings nearly every unit ( System units too ) produce massive warnings. All in all they were maybe not so critical, or came from a different ARC-era, but still they point towards some possible flaws in code. I think its always worth to try to find better solutions.

What I have found is that aside the usual [unsafe] there is a specific [Result: unsafe] attribute, which can be used before member functions, where I have assumed that this might suppress the warnings. https://docwiki.embarcadero.com/Libraries/Seattle/en/System.UnsafeAttributehttps://docwiki.embarcadero.com/Libraries/Seattle/en/System.UnsafeAttribute This should be applicable to functions as well, but it doesn't suppress these unsafe typecase warnings But it also says: There is also the unsafe method modifier, or maybe unsafe keyword how Marco called it, which can be added behind a function. This does more than just compiler magic, but it seems to modify reference counting. So this is not what I'm looking for, but mybe with Recors it does this job? Is the [Result: unsafe] attribute maybe a leftover from the mobile ARC stuff and nowadays has no meaning? I'm unsure what this really should do, except suppress warnings. There was an old whiteparer "The Delphi Language for Mobile Development" from 2013, which seems not available any more. What I'm looking for is a selective way to suppress the warnings a Record level, to tell the compiler that I take the responsibility.

If you start by 0, I would also say no, this should not be underestimated, If your question goes in the direction of an existing ERP bringing to web technology, I would say yes. Otherwise C#, PHP/Laravel or even Python will close that gap nowadays. Even large ERP systems were developed with web-technologies much faster and much more capable than desktop, before we even can start an *.EXE file This is just my opinion, perhaps there were different opinions or experiences too.

Hi there, I'm trying a bit with with custom records and have here some minimal example. Its about the API to work with such records. I wonder what will be the right way, to use it in the following scenario, without warnings: unit UMyCustomRecordDemo; interface type TMyCustomRecord = record public type TMyEnum = ( meFalse, meTrue ); private FValue: TMyEnum; public // Standard-Operators for Custom Managed Records class operator Initialize(out Dest: TMyCustomRecord); class operator Finalize(var Dest: TMyCustomRecord); class operator Assign(var Dest: TMyCustomRecord; const [ref] Src: TMyCustomRecord); // Factory-Method, which shall prepare a new record, that can be used with inline variables and intrinsic type evaluation class function Make_Record: TMyCustomRecord; static; end; implementation class operator TMyCustomRecord.Initialize(out Dest: TMyCustomRecord); begin Dest.FValue := meFalse; end; class operator TMyCustomRecord.Finalize(var Dest: TMyCustomRecord); begin // Finalize if necessary end; class operator TMyCustomRecord.Assign( var Dest : TMyCustomRecord; const [ref] Src : TMyCustomRecord ); begin // Simple copy of internal values Dest.FValue := Src.FValue; end; class function TMyCustomRecord.Make_Record : TMyCustomRecord; begin // This shall prepare a new record Result.FValue := meFalse; end; end. And it would be used like that procedure TestMyCustomRecord; var LRec1: TMyCustomRecord; begin // This assignment throws the warning: W1048 Unsafe typecast of '%s' to '%s' (Delphi) //Yes, it may be caused by temporary object and assignment, which is not most performant. LRec1 := TMyCustomRecord.Make_Record; //I would like to use this, as elegant way to make and prepare a new variable var LRec2 := TMyCustomRecord.Make_Record; end; My question is, are CustomManagedRecords not intended to be used in Function results, because there is no nice easy way to get rid of these warnings? How about functions returning Records in general, this is not the most efficient way, I know, the pro's are its readability. Would there be an elegant way out of this problem (maybe by records using classes or smartpointers internally, but would such overhead be worth it for simple records? And yes, I know that a "getter" would solve it, but not as elegant as above API: TMyCustomRecord.Make_Record( LRec );

Thanks for these enlightments. If Spring4D already optimizes to 14ms, how did you get the only 2nd best results at 22ms? Is there any configuration setting needed, to switch on or off the Hash-Algorithm, how to use Spring4D in the right way with Integers?

I'm unsure what advantages to expect from this Are'nt these just several independent server layers between the client and the LLMs, to unify the LLM communications? Currently they talk only about Claude, it seems very Claude centric to me. Do these MCP servers have any REST API or whatsoever, maybe I have overseen this? For the use of agents, wouldn't it make more or same sense to have these features built in the client SDK ( Delphi Code ) in the first place? Then your app would have local, full control over all LLM's and DB's. Yes, a server solution might have some advantages too, but they are not good pointing them out very precisely. I would start with unifying access to different LLMs by implementing a general Delphi Interface for several LLM implementations, to have a compatible interface between several LLM ( if that will be really possible ). Perhaps I completely misunderstood the deeper idea behind this additional layer of complexity, then please let me know.