Lars Fosdal

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.

Well, every other piece of hardware is virtual in a VM, so why not the TPM?

Both AWS and Windows Server Hyper-V VMs can have virtualized TPMs. I would expect VMWare and others to go the same way. I am curious towards what you would need to do to move a VM from one workstation to another if it relies on a physical TPM. Perhaps an export/import thing? BTW: Currently, Generation 8 of Intel is the CPU cutoff point. For anything older than that, Windows 10 21H2 will be available and patched until 2025. https://www.theverge.com/2021/6/25/22550376/microsoft-windows-11-tpm-chips-requirement-security

I am pretty sure that the syntax of attributes won't change, so that discussion is not really interesting. Your suggested helper separates the attributes from the field/property declarations, which is not a good thing, IMO. As for cross platform - there would be two means of managing that. Defines around the attributes, or ensuring that values are appropriately scaled in the TGridView class (See last paragraphs). The attributes are just the means to change a default. I can (and do) change attributes of the fields in a Create method as well. I would have loved to be able to set all these from attributes as well, but the compiler won't allow it. If we had lambda expressions and the compiler would accept complex constants as arguments, I'd move of this to attributes. constructor TSiteGridSet.Create; begin inherited; LocationNo.Title := titles.LocationNo; GlobalLocId.Title := titles.GlobalLocId; Name.Title := titles.Name; Environment.Title := titles.Environment; Role.Title := titles.Role; AppServer.Title := titles.AppServer; LocationType.Title := titles.LocationType; DBInfo.Title := titles.DBInfo; BuildName.Title := titles.LocationType; LocationBuildTrack.Title := xlt.Create('Build'); LocationBuildTrack.Formatter := function (const aValue: TPSDLocationBuildTrack): string begin case aValue of lbtDefault, lbtLive : Result := 'Live'; lbtPilot : Result := 'Pilot'; lbtTrunk : Result := 'Trunk'; else Result := ''; end; end; RowStyler := HighlightOffline; Environment.SecondaryKeys := [LocationType, Role, Name]; Environment.Formatter := function(const aValue: TPSDEnviroment):String begin Result := aValue.ToString end; Name.ColumnStyler := Self.ServerNameColor; Role.SecondaryKeys := [LocationType, Environment, Name]; Role.Formatter := function(const aValue: TPSDServerRole):String begin Result := aValue.ToString; end; Role.CellStyler := ServerRoleColor; LocationType.SecondaryKeys := [Environment, Role, Name]; LocationType.Formatter := function(const aValue: TPSDLocationType):String begin Result := aValue.ToString; end; Param.OwnsReference := True; FComboLayout := Layout.AddLayout(xlt.Create('Combo'), [LocationNo, Name, Environment, LocationBuildTrack, Role, GlobalLocId]); end; FYI - the TGridSet is non-visual. There is a TGridView proxy class that takes a TGridSet and applies the visual stuff to the actual grid. TSiteQueryGrid = class(TGridViewPSD<TPSDLocation, TSiteGridSet>); Currently, the TGridView was written to only support TMS TAdvStringGrid, but could be refactored into a multiplatform/multigrid adapter.

I split the Attribute discussion into a separat thread