Lars Fosdal

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!

No, not currently. There has never been a need. The test last night shows that all the test clients remained connected after enabling the 5 second Hello on the server side. That means I can go to the networking guys to ask them to dig a little deeper, unless... there was something in a Windows patch. We don't use timers - but waiting threads. I'll put the TCP level keep-alive in the back of my head for future exploration. @Kas Ob. The apps and servers run in a closed network with a limited number of clients and telegrams. A hello every 5 seconds doesn't add much load, and at this time, I think I will keep it server side as it works well enough. That said - the timeout period is a parameter, so we can increase it if we want to.

Thank you, @Remy Lebeau! I also asked our networking team about any recent changes to the network firewalls and routers. Which is preferable - the client or the server initiating the keep-alive? We did actually start with a server side test today, as it was designed in - but it has been configured off for years. If idle, it will send a "Hello" packet every 5 seconds.

Not in Delphi, for sure.

If it exists, it can be abused.

I also use IfThen a lot - but only for string constants. A ternary operator - or lambdas without the verbosity would have been so nice.

That one was new to me - and it looks pretty brand spanking fresh too. Ver.0.99. Pricing model is a bit simplistic. Needs a team license with source code.

If your main window pops up immediately, you may not need that splash at all. What is it supposed to tell the user? Why not put the db connections in threads? Everything and anything can be asynchronous if you do it right.

Rule #1 was meant to be a joke, but the point is - all that work needs to be done. If you do it before you display the window or after, will matter for the perception of the user. If you are waiting for it to start because it is prepping all the data before showing the first visible hint of running, it is per user perception - slow - or in the worst case if things take long, the user will assume it failed to start. If you first show the window, the user will know it responded and is working. If you show progress information after, the user will know it is still working on something, and people will perceive the "lost time" as less of a nuisance. The total startup time from launch to ready to use, will be the same - but for the user, it will feel faster.

Actually, it does work that way. First the window comes up, then it fills the list.

Why? Because not seeing the application work is easy to confuse with seeing the application not working.

Rule #1 - Don't do shit before your application has loaded and displayed itself. After the initial display, you can show various "Preparing good stuff - % complete" messages and do stuff in threads, allowing basic interaction with the app - such as doing an immediate exit. Speed is mostly about perception.

The magicians at Grijjy made something for iOS and Android. https://github.com/grijjy/JustAddCode/tree/master/ErrorReporting Nothing for MacOS or Linux yet. IMO, basic cross platform stack tracing should come out of the box from EMBT. MadExcept and EurekaLog could still make a living, dealing with more bells and whistles and with the reporting bit.

@Dmitry Arefiev - is there something planned for mitigating this? @BruceTTTT - Check the quality portal and add an issue if it is not already there. Edit: Wait a sec - we are using the MSOLEDBSQL driver - why doesn't it work for you?