Lars Fosdal

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.

For actual images, I usually try a google search that starts with "image creative commons" then a description of what I am looking for.

Currently in quarantine myself. Got a message on the anonymous tracking app that I had been near someone that had Corona. Getting tested today. Hoping that it was a red herring, since I've already had Covid in March and have gotten two shots since then.

https://www.flaticon.com/ has an insane number of SVG icons, many of which are free. Using SVG plugins for Delphi, or Inkscape (free image editor) to convert to any format you need,

I am an Android user, and I never use anything except the Google Play appstore. I have done a few sideloads, but that has been from sources that I trust fully. Apple doesn't allow other app stores nor does it allow/enable sideloading - unless you void any remaining warranty and jailbreak your iOS device. My personal advice would be to stay away from unofficial "stores" as they are likely to be ripe with exploits and will drag you down into the mud.

Is the second computer logged in with a different user? Does that user have access to the share? How are the files opened? Make sure you open them read only, deny none. If the files are opened in a third party tool, you might not have control over that. Using the SysInternals Process Monitor may offer insights to what it is that goes wrong.

Timely info from EMBT: <crickets>

To reap the benefits.

Uwe is the maintainer of the tool. His decision has been made clear. Ref. code visibility challenges: Dependency Injection (DI) can solve the challenge of doing form specific actions from a unit that ideally should not know anything about the form instance. unit uTransparencyManager; ... type TProcHandler = reference to procedure; THanderList<T> = class(TList<T>) procedure Execute; // loop through handlers and call each of them end; TProcHandlerList = class(THandlerList<TProcHandler>); var ResetHoverColor: TProcHandler; implementation { THanderList<T> } procedure THanderList<T>.Execute; begin for var Handler in Self do try Handler(); except // log end; end; initalization ResetHoverColor := TProcHandler.Create; Here, TForm1 could register their method with the ResetHoverColor.Add(Self.ResetHoverColor) during FormShow and unregister with ResetHoverColor.Remove(Self.ResetHoverColor) during FormClose (or wherevere appropriate). Drawbacks - DI requires a little scaffolding code. Benefits - uTransparencyManager does not need to know each form - TForm1 does not need to expose internal properties - Only the forms that actually are in use will be added to the handler list. - The ResetHoverColor.Execute loop can have a common exception handling wrapper to deal with misbehaving proc handler code (form = nil, errata in the injected code, etc)

@mvanrijnen - I wish you a speedy recovery!