Leaderboard

Hi All A few weeks ago I did a zoom presentation about DPM to the Australian Delphi User Group (Melbourne branch, but anyone could attend). A link to the recording of that presentation is available on the ADUG website - https://www.adug.org.au/meetings/melbourne-meeting-november-2020/ along with some notes about dpm The video is nearly 2hrs long, but the presentation part is only the first 50 min or so (the rest is q&a/discussion). If you want to skip past the boring slides to the demo it starts at 24:40 😉

You'll get no complaint from me on that.

What if we could write optimized code right from the start and would not have to deal with all that shit because the compiler has the intelligence of a rock. What if good coding practices could be tought by the editor via suggesting things (look at quick actions in Visual Studio that will help you with many different things - from fixing formatting to suggesting some refactoring) Much backwards compatibility is eyewash and simply means: "we did not change the signature but sacrificed some firstborn to make it still work". If you provide - there is it again - tooling to detect and guide you with moving forward (yes, often backwards compatibility is nice because I don't have to ifdef my code for a dozen different versions) then breaking changes are not bad.

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 ...

Mine looks like this type Generic = class public class function IfThen<T>(Value: Boolean; const TrueResult, FalseResult: T): T; static; end; I don't think the name is that great, but my motivation was to use the same naming as the RTL. How I wish we could have generic functions outside of classes or records. Note that you should make this a static class method so that the class reference does not get passed.

I disagree - this is exactly the mindset that we got trained all these years because we did not know any better - the world moved on - heck there are people working on programming tools based on ML so it can suggest refactorings based on refactorings you have done in the past! And yet here we are mostly doing yolo driven development - "if it aint break it might be ok" (ok, I am exaggerating here). If the tooling can point out possible optimizations because they understand what you are doing that can just be good regardless of how much of a measurable improvement that will make. And if its just for some junior coders at Embarcadero slapping together some ... ahem ... non ideal code that never gets properly reviewed because lack of time. It took them years and an actual change of the FreeAndNil function to find bugs in their code that static code analysis could have found ages ago.

I'm deeply interested on this, and would like if anyone here is using/used homegrown MVVM implementations, and wich was/is your experience. Works fine? Is not woth the effort? Is the best since sliced bread? Please, share your experience Thank you!

This is pretty flaky mind you. Sometimes type inference works, sometimes it doesn't and you have to be explicit. It is something that may have improved in more recent releases, but IIRC some issues remain.

I'm not sure what looking through assembly would tell you. If performance was your motivation then you'd time the code in a realistic setting, and if it was a hotspot then you'd do something about it.

There was a thread on SO that summarized pascal funniest syntax but unfortunately I couldn't find it. Instead I found this : http://delphi.org/2014/02/hidden-features-in-the-delphi-object-pascal-language/

@Anders Melander I meant it in a ascii art way 😄

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;

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.

https://en.wikipedia.org/wiki/Principle_of_least_astonishment And now imagine some compiler that turns that into proper code with as little conditional jumps as possible: https://godbolt.org/z/KqhKnx

[badmorning mode] Yes the Delphi IDE performs at is best as: - You create all components manually - Do not use form/frame inherentance - Disable all code- and error insight features. - Use external compiler it's Embarcadero's believe that the IDE is best used as a luxury notepad. (but then you better use notepad++) 🙂 but hey, what else you gonna do with the few thousand dollars of the cost of Delphi 🙂 [/badmorning mode]

The sources are in C:\Program Files (x86)\Embarcadero\Studio\21.0\source for a standard installation. No idea if sources are delivered with trial version. Try with Community Edition.

That depends on which keep-alive you are referring to. If you mean the TCP level keep-alive, then it is a setting of the local TCP stack, so I would suggest enabling it on both ends, for good measure. But, if you are referring to a keep-alive in your protocol level communications, then who initiates the keep-alive depends on the particular design of that protocol. That is a protocol-level keep-alive. If your server is already doing that, then you don't need to enable a TCP level keep-alive on the server end. If it sends a "Hello" and does not get a response back within a few seconds, close the connection. On the client side, if it knows it is idle and should be expecting "Hello" packets, then you don't really need to enable a TCP keep-alive on the client end, either. Just start a timer for 5-ish seconds and if it elapses before a "Hello" packet is received then close the connection, repeating for each expected "Hello". Does the client ever send its own "Hello" packets to the server, if it doesn't see any server-sent "Hello"s for awhile?

Without knowing anything about your architecture I would say that you need to move the content of each of the tabs into individual frames and then create and destroy these frames on-demand.

Probably because receiving RTF emails is not common. Formatted emails typically use HTML instead. Assuming the RTF is in the email body itself, and not in a separate TNEF attachment (winmail.dat, etc), then it is really no different than handling HTML emails. If the top-level TIdMessage.ContentType is RTF then read the TIdMessage.Body property, otherwise search the TIdMessage.MessageParts collection, in MIME order, looking for a TIdText object that has an RTF media type and then read its Body property. There is no *unit* for handling RTF, unless TNEF is involved, in which case you would have to use the TIdCoderTNEF class to parse the TNEF attachment to extract its inner email into another TIdMessage, and then you can process that email as needed. RTF and "enrighted text" ('text/richedit' is the predecessor to 'text/enriched') are separate formats. It is up to you whether you want to handle them all or not. 'text/rtf' is likely to be the more common format you encounter, if any. See above. That, I can't really answer. I don't know how RTF email encode images. I think they are embedded directly inside the RTF markup itself, not referred to using separate attachments, like in HTML emails. But I'm not sure.

I think I'll put that on a t-shirt: "Hope - Helping Delphi survive since 1996"

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.

If it's a byte array, why don't you just write that to file? Why do you need to convert it to a string variable?

Example. Start a new VCL app, drop an Edit and a Button on a form. In the click event of the button: procedure TForm7.Button1Click(Sender: TObject); var x:TArray<Byte>; begin x := TEncoding.Unicode.GetBytes(Edit1.Text); ShowMessage(IntToStr(Length(x))); end;