Lars Fosdal

An instance is a value of a class type that has been constructed with a call to Create. A class var is shared across all instances of the class - and they are accessible directly from the uninstanced type as TCompany.ClassVarName. The drawback is that you can only have one value for all the TCompany instances. If you need to have multiple companies in memory, you need to do a TCompany.Create and load up the instances ordinary fields/props per company.

Just curious - since the data has to be imported - why bother with class vars instead of using a regular instance with regular fields?

https://filezilla-project.org/ aka "The free FTP solution" has both a client and a server. Open source, and pretty good. Configurable connections, including source and target folders. Quick, easy and reliable - and you can set a throttle for the transfer rates if you need to. Edit: One significant drawback - the client is not suitable for command line scripting. If you need to do that, you need to use WinSCP or PowerShell.

I don't mind the compiler throwing hints and warnings - as I always fix them as they appear. I even set some warnings to be errors - since they most likely are severe enough to dictate a no-tolerance policy.

Just a minor detail, based on the wisdom in the Framework Design Guidelines book: I would call the property Enabled, and not Enable. Enabled is a state. Enable is an operator. Also - I would not use FThing - but Thing. If it is publicly accessible as a property, I'd use the prop ref, not the field ref, unless the FThing getter did lazy initialization. If it is not for public use, I'd place it under private or strict private and not use the F prefix. Avoiding prefixes also helps for readability. Thing.Enabled := True; Thing.Execute( 1 ); // or Thing.Enable; Thing.Execute( 1 ); // or - Enable could be a function to set Enabled to true, that returns true if it succeeded. if Thing.Enable then Thing.Execute( 1 );

I wonder why an account was created to post the link, and then the account requested to be deleted?

Good to see you back, @Sherlock! I hope you are recovering ok.

Other advantages: Properties can be read-only. Since you can opt to have methods for the setter and getter of a property, you also have a place to monitor the activity of the said property - with a breakpoint that simply counts accesses, a method that logs the accesses, or an actual breakpoint Using the get method, a property can allow for lazy instance generation, so that if it is never used, the connected instance is never instantiated Using the set method - the validity of a property value can be decided on assignment, without needing that validation to be spread around on the calling code

As I write this, my laptop runs 523 processes with 7600+ threads on a 12-kernal (6 core) i7. If all those threads were check/sleep/loop based - I'd be at 100%. Instead, most of them are idle, just waiting for something to happen.

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?