Lars Fosdal

The book is on my desktop, under the 70-762 Developing SQL Databases book. I need to start reading.

A more common issue could be if the file is accessible for read or not. Being written or otherwise held locked from another app, f.x. and whether a retry is desirable or not.

You are right. I was confusing it with the i++ vs ++i effects.

@David Heffernan, isn't there a variation where the iteration is done before the statement?

Can you set the TImage canvas info to the same properties as the printer canvas? From experience, the PPI / resolution / dimension puzzle comes into effect, and if the TImage is operating with different world coordinate resolution than the printer, you run into problems with scaling. If you use WinAPI GetDC and GetDeviceCaps on the printer - you should be able to get the info you need.

It could be that Windows 10 gives better scaling results than the ancient Windows 7, since it is better at dealing with multiple displays and varying DPI.

I am totally for expanding FPC to cover everything Delphi can do and more. I would welcome it and applaud it. I don't think EMBT would mind, either. Giving up their own compiler is completely different thing. However, I don't believe FPC will ever catch up. Look at attributes which are still not supported. My Delphi code won't even compile on FPC, and that is not a EMBT problem.

All of this is basically a fantasy. The odds that EMBT/Idera would consider doing it, are slim to none, IMO.

Ok, Thanks for taking time to check it out!

Also - I guess a non-generic class inbetween will be needed for "is" checks. i.e. TJsonElement = class abstract ... end; TJsonList = class abstract (TJsonElement); TJsonList<T> = sealed class (TJsonList) ... end;

Updated JsonListTestCase.pas and removed the test data initialization from the constructor 😛 to make the restore test more credible. JsonListTestCase.pas

Yes - that is the goal. Remain compatible with the original format, but have reusable code for lists. In theory, it is probably better to have the internal type being a TObjectList<T> to get more functionality "for free". The conversion would break if you add other properties to the TJsonList<T> class - but I can safeguard against that f.x. by sealing the class etc. Test project attached (Note that the test classes does not do proper memory management on free). JsonListTest.dpr JsonListTestType.pas JsonListTestCase.pas Output: TTestArray Original: { "things":[ { "prop":"A1" }, { "prop":"B1" } ] } TTestArray Restored: { "things":[ { "prop":"A1" }, { "prop":"B1" } ] } TTestList Original: { "things":{ "items":[ { "prop":"A2" }, { "prop":"B2" } ] } } TTestList Restored: { "things":{ "items":[ { "prop":"A2" }, { "prop":"B2" } ] } } Press Enter: JsonListTestCase.zip

I unabashedly summon the wisdom of @Uwe Raabe and hope he has some answers for me 🙂 I have a base class that wraps the to/from JSON conversion for me and also contain some other helper functions type TJsonElement = class public class function CreateFromJson<T: TJsonElement, constructor>(const aJson: string): T; class function LoadFromFile<T:TJsonElement, constructor>(const aFileName: String):T; class function PrettyFormat(const aJsonString: String; const AsHTML:Boolean = False; const UnEscapeJson:Boolean = False):String; function AsJsonString: string; end; And I am currently using TArray<T> to do lists, but it gets old writing helpers for each TArray<T> variation, so I'd like to do something like this and wrap a TArray to do all the chores of insert, add, clear, remove, delete, etc. once and for all I'd add these explicitly as methods of TJsonList. type TJsonList<T: TJsonElement, constructor> = class(TJsonElement) type JArray = TArray<T>; private FItems: JArray; function GetItem(Index: Integer): T; procedure SetItem(Index: Integer; const Value: T); public function Add: T; function Add(const aItem: T): T; procedure Remove(const aItem: T); // etc etc property Items{Index:Integer]: T read GetItem write SetItem; default; end; type TThing = class(TJsonElement) private Fprop: string; public property prop: string read Fprop write Fprop; end; // current way TThingArray = TArray<TThing>; TArrayContainer = class(TJsonElement) private Fthings: TThingArray; public property things: TThingArray read Fthings write Fthings; end; // new way TThingList = class(TJsonList<TThing>); TListContainer = class(TJsonElement) private Fthings: TThingList; public property things: TThingList read Fthings write Fthings; end; So, what is the problem? Assume that the two objects have been created and a couple of TThing elements added. TArrayContainer.ToJsonString will output { "things": [{ "prop": "A" }, { "prop": "B" }] } Without a converter/reverter, TListContainer.ToJsonString will output { "things": { "items": [{ "prop": "A" }, { "prop": "B" }] } } So, Challenge 1: Can I make a converter/reverter that will not output things as an object, but hide items and simply output an array of TThing? Challenge 2: Can I make the conversion override permanent, so that I don't have to use an attribute for every instance and descendant of TJsonList<T>?

@Dmitry Arefiev - Can you shine some light on this? Is it a bug or "as designed"?

That looks like a bug. Create a QP entry, perhaps?