Lars Fosdal

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 \%

I usually do this as a two pass operation. I first start a thread that fills a memory structure. Once the thread is done, I trigger an update in the main thread that fills the UI from the memory structure. I have nothing but negative experiences with doing UI updates directly from threads.

Your English is fine. Most of the APIs we use, require OAuth 2.0, hence my question.

OAuth 1.0 only?

That is waaay to familiar. As a developer, you never run out of chances to own yourself.

I've had issues with having multiple allocated hWnds and messaging. Ended up with a single allocated hWnd and a custom message broker/router for my user messages.

https://blogs.embarcadero.com/rad-studio-11-is-coming-new-version-announcement-and-beta-invite-for-update-subscription-customers/

A company that offers registration tools i.e. licensing tools for developers?

Still unable to reproduce (10.4.2).

A-Z. AA-ZZ, AAA-ZZZ

Assuming the Tag value of each checkbox can be set to the ordinal of it's enum, you could walk the enums and check if you find a checkbox under Filters for each of them. If you don't find it - you change the caption of "Filters: to "Filters is INCOMPLETE" or log it or whatever. But - it would be runtime, preferably in the debug code. Likewise, you could easily take a set of enum values to get or set the states of the check boxes. It is a little inconvenient to do this in Generics, since we don't have a constraint for enumerated types - which means we can't really use Low, High or Ord, but it is possible.

Very thin description. Are we talking design time in source code?

Link rot - the scourge of the internet 😛

Has Andy's site gone belly up?

Originally a comment to I find Attributes to be an excellent feature of Delphi. Saves me a lot of variations of init code which instead is done with attributes.

I see that I've cut off the source I pasted. If you had the full source, you would have seen that the numbers are the default widths in pixels. This is the initial default value. I.e. those you need before you have a config to load. The same default as you would define in a constructor or design in the form editor. Likewise, with the type of the field, there is a default alignment which can be overridden with the attribute. These are indeed presentation properties and they are defaults explicitly bound to each instance of a field. The idea is to keep the default properties together with the field declarations instead of having them spread out through the code or defined in the .dfm. Unfortunately, I cannot use record constants to initialize the titles or specify the secondary sorting columns due to limitations in the language.

The grid sets are multipurpose. I can create gridsets dynamically from an SQL query, or dynamically from records or objects, or I can specify the design as in the example. All the actual grids have the same features, look and feel and the same behaviour. Visual inheritance is a nightmare. Just the same way as values in a constructor or in a designtime form are hardcoded. Except - the values are in code, right next to the declaration. Please elaborate? Where and how? As for torture of fingers. It is not like you need a huge amount of square brackets and using them is no different from when using them for arrays. [InitField(50, hcLeftJustify), UniqueField, DefaultSortField, ReadOnlyField] GlobalLocId: TFieldInteger; Anyways... Don't be blinded by one man's implementation in a specific context tailored for his needs. Attributes can be very useful and applied for a wide range of purposes.

AWS and Azure already have virtual TPMs for VMs.