However, it’s nice to have a distinctly separate HTML archive of them, too.

If it is implemented as compiler magic, the class-scope global variables will not be visible to or accessible by other code in the class, even though behind the scenes it’ll still be implemented as such.

That’s what I would like to achieve - a transparent way of updating UI elements from a secondary thread. I should be allowed to just write MainForm.ProgressLabel.Caption:=’…’ and the compiler should wrap this into a synchronize call without me knowing about it.

That way we could *appear* to have thread-safe VCL, even though it isn’t *really* thread-safe (just like compiler magic auto-boxing in .NET allows you to type cast away between managed and unmanaged types in Delphi.NET, if I understand it correctly).

with TBitmap.Create do
begin
Canvas.Textout(’test’)
Free;
end;

Above example is not possible, because canvas is not threadsafe. But it is not visible at all!

To call VCL functions from a secondary thread without calling Synchronize, use QueueUserAPC. For a complete example, see my comment on Allen’s blog entry on Spot the deadlock.

Someling like:

PROCEDURE SetLabelCaption(L : TLabel ; Caption : STRING); Threaded;
BEGIN
L.Caption:=Caption
END;

and if the compiler could even detect it within a TThread descendant automatically (for example by having a Threaded clause to classes that would activate the compiler magic) so that in any method within the class that touches non-threaded classes, it would do a synchronize behind-the-scenes.

I do not object to the use of "Synchronize", only to the need for me to know about it :-).

Ideally, I’d like to be able to create those forms with a PopupOwner from a different thread.

That’s not what I’m looking for. I would just like to be able to create GUI on multiple threads. The VCL currently only allows you to create GUI on the primary thread; I want to be able to spin up secondary threads and create GUI from there. Trivial in WinForms, impossible in VCL (because there’s one shared TApplication, one shared TScreen, etc., and they don’t have any critical sections).

The problem with what you want is that it would be mean putting locks around /every/ VCL property call, and I’m sure you can imagine what that would do to performance.

Nick

Indeed I do. Corrected.

Nick

not to be nitpicking:
"(As an aside, David Dean is an outstanding edition to the CodeGear team, and first came to our attention via his great work in QC.)"

You probably meant "addition", do you?

twm

I don’t know what "a lot of customers" mean by this, but what *I* would like is the ability to call VCL functions from a secondary thread without the need for Synchronize, and the ability for a secondary thread to hook into a VCL event.

It can be done - sort of - by using class-scope global variables (f.ex. if you want to update a TLabel’s caption, I usually code it something like this:

PROCEDURE SetLabelCaption(L : TLabel ; Caption : STRING);
BEGIN
ClassGlobalStringVar:=Caption;
ClassGlobalLabelVar:=L;
Synchronize(SetLabelFunc)
END;

PROCEDURE SetLabelFunc;
BEGIN
ClassGlobalLabelVar.Caption:=ClassGlobalStringVar
END;

but it would be much nicer to be able to just do

MainForm.Label.Caption:=’Progress: ‘+IntToStr(Percent)+’%’

So, that’s what *I* mean by "thread-safe VCL"…