Lars Fosdal

For some it can be daunting to get started on multi-threading and asynchronous applications. @Dalija Prasnikar can help with that. https://dalijap.blogspot.com/2020/11/just-released-ebook-delphi-event-based.html

We do extensive use of client-side threading. Lengthy UI blocking jobs, such as querying for data or generating output, are delegated to a thread - culminating in a UI refresh to display the updated data. "Not responding" UI messages are so last decade.

These temporary component inclusions of EMBT are bullshit. Free and included, my rear end...

JMIW - djay-meeve - Just Make It Work

This brings up my pet peeve with Generics - the lack of an Enumeration constraint for the generic type T. If you put something else than an enumeration as T in the call, it will blow up, but putting <T> on the methods allows you to do what you want? If you are running multiple sets, but the class basically does the same, can you use this? TBSCatalogBuilderSet = class(TBSCatalogBuilder) public // constructor Create; // Does what you need it do to, but stays away from the generics bits procedure Build<T>(ACatalogId: Integer; const AName: String; ADefault: T); end; procedure TBSCatalogBuilderSet.Build<T>(ACatalogId: Integer; const AName: String; ADefault: T) var V: TValue; Ordinal: Integer; begin V := TValue.From<T>(aDefault); Ordinal := V.AsOrdinal; // You already have the TypeInfo example above for extracting the range of T, or the name of the type as well // so the rest of your magic happens here end;

Or even DuGet 😄

I am still not sure what you want to achieve or what it is that is the actual problem? Do you need to validate that the second parameter is valid for the first parameter? Or is it converting to/from an integer? if it compiles, aValue is a member of T function TFoo.IsMember<T>(const aValue:T): Boolean; begin Result := True; end; Convert it to an integer? function TFoo.ToInteger<T>(const aValue:T): Integer var V: TValue; begin V := TValue.From<T>(aValue); Result := V.AsOrdinal; end;

Or... VuGet (name play on NuGet)

My unsolicited suggestion: VPAM (vee-pam)- Vincent's PAckage Manager aka Vincent Parrett's Asset Manager 🙂 VPAM currently gives less than 300k hits on Google and the existing ones appear not to be in the software/IT sector.

Embt cannot read your local license data - so if it is mentioned in the email, that is something on their side. License Manager will only affect which licenses that are present for your local installation.

@ertank - If you do that, the trial license may still be hanging around, but can be removed using the LicenseManager. C:\Program Files (x86)\Embarcadero\Studio\<version>.0\bin\LicenseManager.exe

The Byte example shows that flakiness, but it does seem to work well in 10.4.1 - also with regards to Error Insight.

Makes sense, I suppose. Personally, I am not enthusiast enough to rummage through the variations the resulting assembly code for everything I do - so I ask.

Any improper observations are purely in the head of the observer.

Q: Is there a point to slapping Inline; on after Static; ?

I just remembered a major reason to put the generic type on the method: Type inference. type Use = record public class function When<T>(const aBool: Boolean; const WhenTrue: T; const WhenFalse: T): T; static; end; { Use } class function Use.When<T>(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end; procedure Test(Cond: Boolean); type TObjectClass = class of TObject; var i: Integer; b: Byte; c: Cardinal; w: Word; s: String; d: Double; o: TObjectClass; begin // if type inference is not able to understand your code, you get // [dcc32 Error]: E2532 Couldn't infer generic type argument from different argument types for method 'When' s := Use.When(Cond,'True', 'False'); // Type inference makes the <T> argument to When optional when the parameters are the same type s := Use.When(Cond, 1, 2).ToString; i := Use.When(Cond, 1, 2); b := Use.When<Byte>(Cond, 1, 2); // Needs <Byte> or you get the inference error - not sure why c := Use.When(Cond, 1, 2); w := Use.When(Cond, 1, 2); d := Use.When(Cond, 3.14, 42.0); // 42 without decimals gives the inference error unless you specify When<Double> o := Use.When<TObjectClass>(Cond, TObject, TStringList); end;

As the one on top: No comment ...

Come to think of it, you could rename Condition<T> to Use<T> to shorten the code a tad. i := Use<integer>.When(cond, 1, 2); Edit: There are good arguments for putting <T> on the method instead of the type, since it allows you to put overloaded methods under the same umbrella as the generic methods, but it doesn't read quite as nice. Then again, you can have both type Use = record end; Use<T> = record end;

Well., you can do the same with both class and record, i.e. put the generic type on the type declaration or the method declaration. I try to make my code read as much like normal language as possible - simply because reading comprehension.

@Marco Cantu - Can you clarify the appropriate way of renewing a Community Edition license?

You had me at "yolo driven development". I am all for static code analysis.

type Conditional<T> = record public class function When(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; static; end; { Conditional<T> } class function Conditional<T>.When(const aBool: Boolean; const WhenTrue, WhenFalse: T): T; begin if aBool then Result := WhenTrue else Result := WhenFalse end; procedure Test; var i: integer; s: string; c: TVirtualStringTree; begin i := Conditional<integer>.When(i=1, 1, 2); s := Conditional<string>.When(i=1, '1', '2'); c := Conditional<TVirtualStringTree>.When(i=1, vst1, vst2); end; More verbose, but easiser to read, IMO.

Design-time live data components can be real killers as well.

We are experiencing a really weird problem. We have a TIdTCPClient socket that connects to a server of ours - which uses the TIdTCPServer component. The client side code and server side code is unchanged since prior to 2017 - and has been running well up until when we rolled out our first version built with Delphi 10.4.1. We started getting complaints that the clients didn't update when expected. The server connection list no longer shows the clients as connected - so that makes sense in a way. What doesn't make sense is that the client does not discover the disconnect on IdTCPClient.Connected nor on IdTCPClient1.Socket.InputBufferIsEmpty. What is even more crazy is that IdTCPClient.Socket.Write(OutBuf); also executes happily without care about there being nothing on the other end. Edit: Actually - that Write did cause a Debug Output: TCP Client error: Encapsulation event: Unrecoverable throw caught. Trying to rectify by recreating TCP-Client..... @ TPSD.MyHandlerForReceptionOfTCPClientTlgs (logid: 82911125) - it just had to time out, and suddenly we are reconnected - but for how long. We are not able to willfully reproduce the disconnect, by taking down the server, or breaking the VPN connection for a freshly started client. If we do that, the client reconnects, so it seems to be related to having an idle connection for some period of time It works in 10.3.3 - Are there changes in Indy for 10.4.1 that are breaking somehow?

@Remy Lebeau - My network guy came back and revealed that they had changed firewalls from one brand to another, and that the new firewalls had a much shorter keep-alive default - so that explained the why this problem suddenly revealed itself. Thank you for your kind help!