Leaderboard

I'm here!

We use Mercurial and TortoiseHg. It'sworks very well in Windows environment.

@Stefan Glienke Just checked your suggestion, brilliantly! proc := fld.GetValue(TabSet1).AsType<TWndMethod>(); No compiler errors.

Really nice to see you here.

No. You might want to look at Perl for that. 😉

Result := Result or (condition);

Yes, the examples leak. I didn't want to clutter it up with too much housekeeping code. Thank you, Uwe, for enlightening me on variable vs value capture. IMO, the compiler could need a hint or warning if a variable capture happens in a loop, because it is really easy to overlook. I use a number of variations on this to do dependency injection. It really helps with avoiding pulling too much project specific code into general code and keep the libraries isolated from each other. This code in particular is part of a web server that (now correctly) supports a configurable collection of JsonRPC protocol handlers. The web server knows nothing about Json, and the protocol handlers knows almost nothing about http.

There is nothing wrong with using threads in general, you just have to understand WHEN and HOW to use them effectively. You can't write really high performant software without them. Especially on mobile platforms. I've been writing commercial software for 20 years as well, and have written many multi-threaded applications, just using Delphi's 'TThread' class. I don't use a version that has Embarcadero's "Parallel Processing Library" available (I would never trust it anyway, it has had too many bugs over the years!), and I don't use 3rd party threading libraries, like OmniThreadLibrary, etc (not that there is anything wrong with them, I just never got into them).

I don't want to hijack this thread but this is such a cool example, there is something I can't understand. I have completed it with the corresponding destructors and free's, and it still leaks. Is this an expected leak? Are TFoo and TBar instances stucked? Edit: Okay, this could be also a deficit of the SCCE. Maybe he is managing them in his actual code. Anyway, the trick using an abstract class to passing its method as an anon proc is really great.

Lars also showed a valid approach in his blog post. There is nothing wrong with using variables. As always you have to know what you do.

This is not a bug, but expected behavior: This is what variable capture with anonymous methods is all about. But I agree, this can sometimes be hard to spot and lead to unexpected results as in your case.

You are on right track. What happens is something like this: procedure TTest.ConfigLoop; var Handler: THandlerClass; hType: THandlers; hRef: TOnHandle; begin Writeln; Writeln('--- ConfigLoop'); Broker.Clear; for hType in [foo, bar] do begin case hType of foo: Handler := TFoo.Create; bar: Handler := TBar.Create; // wtf: ; end; hRef := Handler.OnHandle; // Capture does no discern between the foo instance and the bar instance Broker.AddHandler(hRef); end; end; and then this bridging assignment from plain method to anonymous method is expanded to hRef := procedure begin Handler.OnHandle(); end; Where before mentioned rules about capturing references (variables) and not values apply.

Now I have seen the link to the sample code. Will look into it.

I imagine what is happening and I assume it to be expected behavior, although I admit one has to know how variable capturing works to get it. It is even documented (Variable Binding Mechanism) There is still a lot of guessing about what is THandlerClass, OnHandle and how AddHandler is defined and what it does with its parameter, so it is difficult to give a detailed analysis.

Can't you just define defaults for those fields in the db?

It probably is lacking the `()` there which it sometimes needs when invoking a method that returns an invokable type.

@Mike Torrettinni Check my demo app (attached). Works as needed in Windows 7 (I haven't Win10 here, sorry). Look at the project source: program SplashApp; uses SysUtils, Vcl.Forms, uSplashMain in 'uSplashMain.pas' {Form1}, uSplashForm in 'uSplashForm.pas' {Form5}; {$R *.res} begin Application.Initialize; Form5 := TForm5.Create(nil); try Application.MainFormOnTaskbar := True; Form5.Show; Form5.Update; Application.CreateForm(TForm1, Form1); Sleep(3000); finally Form5.Free; end; Application.Run; end. Form5 is a splash form, and Form1 is a app's main form. Also check menu Project | Options | Application | Forms. The splash Form5 is in the list of available forms (the right list). SplashApp.zip

I expect to see no splash form on the taskbar in the first place - neither with or without icon. When I create a new VCL application I have an additional line after Application.Initialize which leads to that behavior: Application.MainFormOnTaskbar := True;