Lars Fosdal

Even professionals can't really do much without actual source code. Can you reproduce the problem in a self contained compilable example?

In some aspects VS is terrible. It is just a different terrible than the terrible RAD Studio.

The If and Case statements expressions are indeed pretty nice.

It works for global vars, though. unit MiscTestMore; interface uses System.SysUtils; type TOutput = reference to procedure(const aText: string); TRec = record a: string; b: integer; end; const c_TRec: TRec = (a:'A'; b:1); // Works c_TRec2: TRec = (a:'A2'); var v_TRec: TRec = (a:'A3'; b:2); // Works v_TRec2: TRec = (a:'A4'); procedure RecordConstTest(const Output:TOutput); implementation function Fmt(const aTitle: string; const aRec: TRec):String; begin Result := Format('%s a:"%s" b:%d', [aTitle, aRec.a, aRec.b]); end; procedure RecordConstTest(const Output:TOutput); begin Output(Fmt('c_TRec ', c_TRec)); Output(Fmt('c_TRec2', c_TRec2)); Output(Fmt('v_TRec ', v_TRec)); Output(Fmt('v_TRec2', v_TRec2)); // var l_TRec1: TRec := (a:'A5'; b:3); // Fails // var l_TRec2: TRec := (a:'A6'); var l_TRec: TRec := v_TRec; // Works Output(Fmt('l_TRec ', l_TRec)); end; end. Output: c_TRec a:"A" b:1 c_TRec2 a:"A2" b:0 v_TRec a:"A3" b:2 v_TRec2 a:"A4" b:0 l_TRec a:"A3" b:2

I like clarity. Brevity is not always clarity.

There is documentation, but it is meagre on examples of use. http://docwiki.embarcadero.com/Libraries/Sydney/en/EMS.Services.TEMSLoggingService

Lots of good advice and my kind of humor, Joe! Great interview!

Can you verify that you are not calling Click from other methods / event handlers? Is it triggered from OnClick, or from OnMouseUp/OnMouseDown?

My first PC as well. Well, technically - the Memotech MTX512 belonged to my dad, but guess who used it the most?

Yup.

Interesting. I wonder why it was limited to the OLE/COM scope?

@Pat Foley - That is something entirely different. I was talking about naming parameters to a method.

I sometimes wish I could call Delphi code in SQL style. Run(aText2='my text'); i.e. specify individual parameter(s) and leave the rest as their default.

I was working with various kinds of financial data, weather data and power data (prices, volumes, etc), and thousand separators usage was variable. Spaces, commas, dots, the lot. It was a hodge-podge of formats since very few standard exchange formats existed at the time. Even vendors that you had contractual agreements with, would change the format on the fly, without notice. "Yeah, we changed the format. Nobody told you?"

The common trait is that both floats and dates have separator character challenges. For floats, the only reliable solution is to KNOW the input format and do the necessary stripping/replacement before passing the string to the converter. In some of my older input parsers, I stripped spaces, then checked for the presence of , and . and did the following processing - if only one exists, don't touch it - if more than one of a kind exists, remove them all - if both exists - remove all but the last one Which still is hopeless if the 1,000 is 1000 and not 1 with three decimals.

I am still waiting for nullable types so that I can rewrite more code 😛

This may be because 10.4 has introduced "MirrorMode" and you changed/saved the form in 10.4. If "MirrorMode" does not exist in 10.3, you would get that kind of error. But - why would you switch back and forth between versions for the same forms? The only safe way is to stick with the latest version you have access to.

These things are perpetual headaches, as is the time and date separators. The default Norwegian Windows language setting is using period for both, which confuses the hell out of the Delphi string to datetime decoders.

We need a truly immutable typed const.

@Fr0sT.Brutal - Same for records. {$WRITEABLECONST OFF} const TypedConst: xlt = (no:'Norsk'; se: 'Svensk'; en:'English'); type pxlt = ^xlt; procedure TForm1.TestTypedConst; procedure Show(const aConst: xlt); begin Memo1.Lines.Add(aConst.no +', '+ aConst.se +', '+ aConst.en); end; begin Show(TypedConst); pxlt(@TypedConst)^.se := 'Deutsch'; Show(TypedConst); end; Output Norsk, Svensk, English Norsk, Deutsch, English So, the answer is a definitive no. Edit: Note that with WRITEABLECONST OFF TypedConst.se := 'Deutsch'; gives a [dcc32 Error]: E2064 Left side cannot be assigned to while it compiles with WRITEABLECONST ON.

That last point would a major concern. Source code is necessary for third party libs. Are they wrapping some DLL or ActiveX class that is shared across the supported platforms?

I've butted my head against this, and sadly there currently is no way to pass a typed const to an attribute. There are reports for problems with typed consts - so please vote. https://quality.embarcadero.com/browse/RSP-13921 likewise, for dynamic arrays https://quality.embarcadero.com/browse/RSP-32488

https://www.nsoftware.com/ipworks/iot/ supports AMQP 1.0 and 0.9.1 Doc for Delphi: https://cdn.nsoftware.com/help/IOF/dlp/ I haven't tried it. @jeroenp - Did you find a AMQP 1.0 compatible lib elsewhere?

That sounds likely. I stumbled on similar problems with formatting of json strings in other languages when I googled.

Not sure why it would barf on %, but you can replace % with \u0025 (Unicode escape) See also https://stackoverflow.com/questions/19176024/how-to-escape-special-characters-in-building-a-json-string/27516892 What happens if you put a double %% or %25 (Similar to \u0025) or \%