Lars Fosdal

Since it often is the actual thread interaction in a multithreaded server that is the cause for debugging - freezing other threads would be undesirable. I'd settle for a way to have breakpoints thread context aware so that I can choose to have breakpoints active in specific threads. A way to easily enable/disable breakpoints per active thread context.

He recently and briefly resurfaced in Teams. https://www.theverge.com/2019/3/22/18276923/microsoft-clippy-microsoft-teams-stickers-removal

Totally agree on the lure of RAD UI design and how it causes newbies to write code that is both relying on states in the UI as well as in their business model, instead of the UI reflecting states from the internal model and delivering changes to that model. As far as possible, I try to write my code without a UI, and I try to make the interfacing between the internal business logic and the UI as simple as possible, with the UI as far as possible being oblivious about why its values and settings are what they are. I often have separate reusable classes as glue between the UI and the biz objects, so that they remain isolated. The debugger is not fine when you venture past 32-bit single UI thread. The 64-bit Delphi debugger leaves so much to be desired, that it is better to do the debugging in a 32-bit version of the app. Multi-threaded debugging - combined with anonymous methods - often causes also the 32-bit debugger to stop working - such as not resuming after a break, or no longer breaking where it was supposed to. Debugging code that runs multiple identical threads is a challenge as there is no simple way to specify that you only want to debug a specific thread instance.

I may exaggerate the problem, but there is a lot of abuse of the Flat UI as the new mantra of UI design. Windows 10 is packed with crappy flat UI, and so are a lot of web UIs too. F.x. I really miss proper use of ellipsis in menus and on buttons. I really miss the use of actual buttons - i.e. something that clearly appears as clickable. IMO - Applications are running on an OS-specific platform and should adhere to the OS behavior - so that when I change my OS skin, the application will follow, and clickable elements look the same everywhere. It is called consistency and helps with guiding the user. The ideal UI is "invisible" - and that does not mean that the button element is not visible, but that the behavior is so natural, you don't have to think about it. The UI should not get in the way of what you are using it for but lead and guide you through it so that you only need to think about what you are doing, and not about how you are doing it. For me, the best kind of skinning is the type that is able to visually adapt to the OS UI settings. My least favorite skinning is elements that visually distract from the flow of a UI, or that interfere with the "normal" UI metaphor for a platform. The great thing about DelphiStyles is that if the developer using it does it right - I can select a style that is pretty close to the standard OS style.

We sure do, because this makes me cringe. Too much clutter. That said - I also hate the currently popular naked "flat UI" design philosophy which takes away most UI guidance and makes you guess if something is a link, a button, or just text - and you have to hover and/or click in the right places to find out.

I am at a loss for words. Do people actually use such styles?

That said - there may be other NNTP servers out there that propagate content from the usenet/alternet groups that also are on Google Groups, but if the group was initially made on Google Groups, it is not necessarily so that it is propagated out of Google Groups. Anyways - NNTP appears to be a thing of the past and there are other federation protocols replacing it in some arenas. IMO, it would have been nice if they revamped it with the necessary security/authentication measures.

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!