Lars Fosdal

It depends on how you wait? I meant kernels as in logical processors. Typically twice the number of cores on an Intel CPU.

There are too many unknowns to suggest a complete design. Are multiple queries done on the same connection, one after the other - or shall each query make a new connection? Is there a limit to the number of parallel slow query/responses? Is order of sequence for the query a crucial factor? Is order or sequence for the response processing a crucial factor? I would be thinking along the lines of a request queue of objects containing the connection and any other necessesary payload. A request thread pool would be processing the request queue and moving the objects to a wait queue. A receive event would copy the response payload to the object, close the connection, and move the object to the response processing queue. A response thread pool would process the objects from the response queue, populate the data used by the UI, and signal the UI that an update has arrived. The UI thread would throttle the actual update/repaint activity to an acceptable rate. IMO, the thread pool sizes does not need to exceed the number of kernels as long as the threads themselves are not idle looping.

https://quality.embarcadero.com/browse/RSP-36887

@Roger Cigol I designed it. It is intended for inhouse use, but there is no confidentiality, nor is it explicitly copyrighted.

I remember beginning in a new position and I spotted and corrected a misspelled parameter in the SQL in Delphi, while it actually was misspelled in the database, so... that didn't really help. Since I am a bit of a petimeter, I mentally spell check my names all the time and get a bit miffed when I stumble on the mistakes of others, but I don't always correct them anymore 😛

What kind of error do you get?

It is sad that HighDPI seems so hard to do - regardless of choice of toolbox.

Discourse is a nice piece of forum software which behaves that way, but IMO Invision (this board) isn't bad. Every board system has its own quirks and challenges.

The link "Unread content" is on the upper right side of the desktop browser forum view. If you are on mobile, it is the sheet icon to the right of the home icon. Perhaps not entirely intuitive, but ... I like to spelunk new websites to get to know them 😉

o.0

https://en.delphipraxis.net/discover/unread/

Sliding into off-topic, but I avoid parameters to constructors. The primary reason is that parameterless constructors are a good fit for polymorphic constructs, as well as instantiations for generics. For configurations, I often give the instance an interface to fetch its own config from. DI FTW.

So, basically try var MyThing := TThing.Create; try MyThing.DoIt; finally MyThing.Free; end; except // deal with it end; // instead of var MyThing := TThing.Create; try try MyThing.DoIt; except // deal with it end; finally MyThing.Free; end; I prefer the latter since I can handle the problem in the context of which it occurs. IMO, exceptions that you let "bubble up the stack" become increasingly difficult (Edit: and expensive) to manage, since you are less and less aware of the exception context, the further out you get.

Also, if you accept that exceptions may occur in the constructor - doesn't that mean that this model is not generally applicable anymore, and you have to wrap that in an exception handler as well? var MyThing := TThing.Create; try MyThing.DoIt; finally MyThing.Free; end;

Which means that you must add exception handling in all levels of the destructor chain? destructor TMyThing.Destroy; begin try inherited; finally try // destroy my things except // this was unfortunate end end; end;

If you construct something complex that allocates memory in multiple sub-objects or blocks, how do you prevent it from leaking if an exception is raised during construction? By having exception handling in the constructors?

I prefer NOT to raise exceptions in constructors - class nor otherwise. It makes securing the build up of the instance hierarchy too complicated. A lack of connectivity or functionality should only be addressed at the time of use, not at the time of instancing, considering their absence may be temporary. There is one case though - during testing, assertions may be used to check for stuff that SHOULD be in place.

That worked better.

Hmm... Wordpress is acting up and sending me to my own site when I try to follow the link.

Just my two cents: The migration to FireDAC is very much worth it, just to avoid all the BDE pitfalls. Not to forget that it also gave us a massive performance boost for our MS SQL Server use.

Dave, you are a goldmine 🙂 There appears to be several must do, should do, could do (or do not's) that would help the fledgling developer to get started in a good way, and I bet those were hard earned learning points? I would love to see you author an article (or a book) on the ins and outs of doing an Android app with Delphi! Thank you for all your contributions, and a Happy New Year to you!

Daniel is on it.

For algorithms to be maintainable and testable, they need to be separated from the UI. The UI can deliver inputs, but the math/logic needs to be black boxed seen from a UI perspective.

I use only TMS VCL UI Pack and FastReports for VCL. The more third-party libs you use, the more dependencies you have on the next major upgrade, and the more testing you must do on the arrival of new versions of the libs. Less is more.

I disagree. Security is a major factor. Ref. Apple app store for macOS is not limited like iOS. You can distribute stand-alone installation packages for macOS, but not for iOS.