Lars Fosdal

Afaik, that info is outdated. Browsing other results for "google groups nntp" indicates there is none.

My favorite approach is to have a connection thread handler that implements the "protocol" for the connection - using a input queue and an output queue to communicate with the owning thread, which in this case could be the main thread. This pattern is often called using mailboxes. I.e. the main thread posts a "task" to the thread input queue aka inbox, the thread loops with a small sleep to poll the inbox and deals with connects/disconnects and sends whatever needs to be sent over Indy to the remote host, collects the answer, and places it in the output queue aka outbox. The outbox can be polled in the main thread, or you can design the queue to post a message to the main thread, which then polls the outbox on receving the message. Protocol errors can also be posted as outbox events.

It was pretty much dead, except for "new component spam".

Google Groups do threading and there used to be NNTP support - but - it was a really bad spam hole so they removed the NNTP support.

For an old thread with new content, you are positioned at the first unread new comment. If all new comments are shown on that page, the thread is marked as read. In the case that the following new comments "spill over" into one or more new pages of comments, I am not sure if you have to visit each page?

True. But changing the type of an xml field also requires the consuming xml parser to know that type has changed. So - if your client used the field as a number, converting the value into a double or integer - changing the content to a string would still be a breaking change, right? Hence, that is not really a feature of the format, since the actual interpretation depends on convention i.e. specification of parsing- and if the specification has changed, and your parser is still using the old spec - it breaks. But, yeah - we are off topic.

From what point of view? The standard XML parser barfs when a property appears that it is not aware of, while the TJson parser simply ignores it - so in that respect, Json appears as more resilient than XML. Edit: FYI, We generally pass most, if not all, numeric values as a string, since that gives us the NULL we need for numeric values as well.

My Bad - I had forgotten that you can't use GetDC for a printer. You need to use CreateDC. https://docs.microsoft.com/en-us/windows/desktop/printdocs/printer-output

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.

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

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

@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?

Regardless of closed or open source - the Delphi Windows compilers and debuggers need a significant overhaul - not to mention the insight background "compiling" - which IMO just as well could be using the actual compiler and background compilation.

I haven't seen this exact problem - but the debugger periodically stops working after a number of build/debug/edit/build cycles. Another issue that annoys me more, is that after debugging you have to compile again to have code completion work again. You don't even need a full compile, just Ctrl-F9 and Esc to interrupt it, and code completion is back in function.