Leaderboard

I read "branchless" and I cry - see RSP-21955

👍 programmerd2k response, and, with firedac, you can simplify his code to : procedure TForm1.Button1Click(Sender : TObject) begin Salestable.open('',[DateFrom.Date,Dateto.Date]); end;

using "Between" dates: Using "PARAMetrizations" in your FDQuery for example: procedure TForm1.Button1Click(Sender: TObject); begin SalesTable.Close; SalesTable.ParamByName('DateBegin').AsDate := StrToDate('06/01/2023'); SalesTable.ParamByName('DateEnd').AsDate := StrToDate('06/30/2023'); SalesTable.Open; end;

I was indeed going for something like a factory pattern (though simplified in that each child class provides static methods for construction instead of having a separate class for the sole purpose of construction). Rest assured, as mentioned above, I'm reducing a bunch of this. Reason for the factory style idea though was to return nil instead of raising an exception in the case of bad construction. I might still keep the static construction methods, but they will at least avoid the unnecessary polymorphism. The current task I'm working on is overhauling a logging system for a game (these are user facing reports). The messages have quite complicated construction and I'm trying to test the viability of removing the message generating from the game logic (this is beneficial in that it allows us to more easily and dynamically have actions like highlighting given units in the messages).

There is not bug in compiler, but in your code. When you say LCastedList.Add(TAncestorObject.Create) What will happen is equivalent of following code: var Tmp: IInterface := TAncestorObject.Create; LCastedList.Add(Tmp); This will be because LCastedList is declared as IGenericList<IInterface> and stores IInterface references. However when you retrieve stored reference you will call that on original list which is declared as IGenericList<IAncestorObject> and retrieved reference will be of type IAncestorObject and you can try to call LObj.ID on that retrieved reference. But in reality stored reference was IInterface, not IAncestorObject and it crashes when you call ID on it because that method (GetID) it simply does not exist there. Point of generics is that you have same type stored in the background, not to store incompatible types. even though there is same object behind those two interface references, those interfaces are completely different types represent different entry points to that object. Sometimes you can force "wrong" type to be stored at runtime, which is usually not what you should be doing, but if you do, you need to make sure that every time you retrieve something that might be "wrong" you cast it back to appropriate type. var LTmp := LList.First; var LObj: IAncestorObject; if Supports(LTmp, IAncestorObject, LObj) then var LID := LObj.ID ;

This has little to do with Delphi, per se, and more to do with using Delphi to access your payment procssor's API. It probably belongs in another part of the site as it has nothing to do with VCL. If you don't have any experience calling REST APIs in Delphi, then play around with some free ones first. Then find a payment processor you like that has a public API and use Delphi to access it. They'll probably have examples of several languages, like js, python, php, etc. Not likely any Delphi example. So what? If it's a REST API, just use Delphi's REST debugger and go from there. TMS Software has the VCL Cloud Pack which implements an API for PayPal. https://www.tmssoftware.com/site/cloudpack.asp They also have their FNC Cloud Pack (a cross-platform library) that supports PayPal and SumUp https://www.tmssoftware.com/site/tmsfnccloudpack.asp Stripe also has a REST API you could call with examples for several languages: Ruby, Python, PHP, Java, Node.js, Go, and .NET, as well as a basic Curl example. https://stripe.com/docs/api There's also a platform called Plaid that offers services to talk with several banking platforms: https://plaid.com/docs/api/ (There are actually a bunch of services similar to Plaid you can use.) But all of this is simply payment processing. If you're looking at using Delphi to build the next eBay, Amazon, or Shopify, that's a whole 'nuther can of worms, and I would not recommend Delphi as the implementation platform. That said, I've worked at a number of places that sold various services and did integrated billing -- some that supported healthcare providers like Doctors and Dentists, and others that just did various other specific services. Explain your use-case and you might get some more substantive insights.

Yes I really need it. With an old project with several million lines of code I need to restart more than 20 times a day (Out of memory, black screen etc.) . And sometime it's can corrupt my sources ! We are In 2023 : A 64 bits IDE should be the priority !