Hello, fpc-developer list.

Some time ago I posted here proposal to extend platform keyword. You gave a hostile reception to that proposal.

Later Florian in private conversation with me suggested better idea of property attributes. Indeed, attributes are more general solution than platform keyword.

Lets discuss this proposal.

What is the purpose: extend rtti (or another structures that can be accessed at run time) with list of user defined Name=Value items.

How it can be used: since it is generic solution different tools can use it in their own way. For example in LCL we can use attribute 'widgetset' to define widgetset specific properties and show such properties on another Tab of Object Inspector or with different colors (or show hints and so on).

Attached file (open document format can be opened by OpenOffice) contains proposed syntax diagrams and declaration examples.

Paul Ishenin wrote

Attached file (open document format can be opened by OpenOffice) contains proposed syntax diagrams and declaration examples.

Sorry, seems odt is not well known format but hope rtf is :(

In attach same file in rtf.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Later Florian in private conversation with me suggested better idea of property attributes. Indeed, attributes are more general solution than platform keyword.

That's a very interesting idea. I can see many uses for it, especially if you can query the values via RTTI.

BTW: Is that something similar to what VB6 (I think) does. I remember from many years back that when you selected a property to edit, in the bottom of the Object Inspector (whatever it was called in VB) it showed a description of that property. As far as I remember that description was part of the class definition - Delphi never supported something like that.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

VB) it showed a description of that property. As far as I remember that description was part of the class definition - Delphi never supported something like that.

I don't think you want to carry around complete property descriptions in your final executables ;-).

Micha

Micha Nelissen пишет:

Later we can invent new switch to control inclusion of such extended rtti into final executable.

Best regards,
Paul Ishenin.

IMO rtti is not strictly needed for this concept. It could also go the the ppu (and then you can apply attributes to more symbols)

Marc

Marc Weustink пишет:

Maybe the problem is that I dont know what is ppu (yes, I saw such extension on my file system) and how to query that ppu from lazarus.

Best regards,
Paul Ishenin.

odt is not well known format

Open Document format is an ISO standard. (That is why Microsoft's "Open XML" hopefully will not be accepted as a concurrent "standard" for the same purpose.)

-Michael

Michael Schnell пишет:

> odt is not well known format Open Document format is an ISO standard.

yes, I know, but at least two developers complained about it, so rtf for those who have no OpenOffice.

Best regards,
Paul Ishenin.

To those two developers.... It's FREE. Download it and get with the program! ;-)
I bet you those two are MS Office users [..ducking and hiding..]

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I bet you those two are MS Office users [..ducking and hiding..]

Should be no (I'm not an MS-Office user :-) ), there is a free plugin that enables even M$-Office to read and write standard conform files (i.e. Open Document ODT).

-Michael

I think it is better to send a RTF document than a ODT document:
* it is smaller
* more programs can read it
* no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in installed.

Vincent

Valid considerations, but regarding this, PDF is a much better option. (BTW.: Open Office does write PDF without any plugins or external programs.)

-Michael

Except, if you want others to extend / adjust / improve your document. In that case PDF is worthless.

Vincent

Then why have a standard, if no-one is going to use it ?

Michael.

Oh, come on. An OpenOffice created PDF would have had about 30K+ size after base64 encode. :P

And that for data which could most easily have been provided as plain text inside the mail:

-- 8< --
PropertyDeclaration ::= PROPERTY Identifier [PropertyInterface] [PropertySpecifiers]
[Directives]

PropertySpecifiers ::= [ ... ]
                       [ ... ]
                       [ATTRIBUTES AttributesArray]
AttributesArray ::= '[' (AttributeDeclaration
                    [, AttributeDeclaration]) ']'
AttributeDeclaration ::= ''''<string>':'<string>''''

Declaration examples:

TmenuItem = class(...)
...
property Detachable: Boolean read FDetachable
write SetDetachable
attributes ['widgetsets:qt,gtk,win32',
'implementor:Vasya Pupkin',

               'creation-date:01.01.2007'];

...
end;

TxxxDatabase = class(...)
...
property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel

   attributes ['engines:firebird,oracle,sybase-asa'];

...
end;
-- 8< --

Of course, the syntax highlighting is now missing but as the intended target audience are the developers and not managers, the missing blue won't lose you information, I'd say.

Vin"How big is that whole mail now?"zent.

I see no problem with this proposal from a language point of view. The only problem is the storage. Your 'runtime access'.

I don't think it belongs in the RTTI. RTTI ends up in the binary, and we get already enough complaints about binary size. A switch to leave it out is not really a good solution, it shouldn't be in there in the first place (apart from the technical feasability)

Also, the only place where this extended information is useful, is in the Lazarus IDE (or any other IDE) Therefor I propose to simply write it to the .ppu file, or - like the resource strings - to a separate file: one per unit. (a .ppi file: "pascal property information").

Since the Lazarus IDE must one day learn to read .ppu files anyway, it seems more logical to add the information there. You need the .ppu files in each case to compile a binary, so storing it in the ppu makes sure it is available to the IDE, but is not in the binary. Since you cannot have a working IDE without the .ppu files of the RTL/FCL/LCL, you are guaranteed that the information is always present.

Now, if you want to have it in RTTI regardless of these arguments:

In that case I propose to reverse the switch you mentioned: People should actually ask the compiler to have the extra property information included. This way, normally only the lazarus IDE needs to be compiled with this switch. It also makes sure the switch is implemented as part of the feature :-)

To achieve that, I think the extra RTTI will have to be written in tables totally separate from the RTTI table (just like the message and resource string tables). But that is a technical issue.

Michael.

Ok, no problem - lets it be ppu. We only need some way of accessing that data. Is ppu reading methods already exists in RTL or another fpc package?

Best regards,
Paul Ishenin.

One simple idea I just had is that this could be added to the documentation. The IDE can look at the docs and show whatever is needed for each different property on each class. The downside is that the component would require docs in the same format as the lcl/rtc/fcl ones, althougth that shouldn't be a big problem.

The good thing is that no new language feature is needed.

regards,

The ppu unit does what you need. It is used by the compiler and dumppu program provided by FPC. Maybe we should make a copy of this unit in the packages, and extend it with some search methods/classes.

Michael.

The bad thing that this will not work. I am developer Felipe, not technical writer. I dont know how to write helps and moreover I will not write them.

BUT, I know what how the code work and I want an easy way to add small hints to that code (and this hints must be understanded by IDE). Moreover that hints can be used later by help/documentation tools when they will generate their output.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

The bad thing that this will not work. I am developer Felipe, not technical writer. I dont know how to write helps and moreover I will not write them.

I actually consider that what you wish to achieve *is* documentation. You desire to pass more information to the user of LCL then what is on the function parameters and other code parts.

This information can be: Works on the following widgetsets: X, Y, Z

But it could also be anything else desired.

Some code documentation systems work by parsing comments which go in the source code itself, like javadoc, and that would probably make things easier for you as you don't need to leave the code editor to add documentation information, and shows an advantage of this documentation system.

If we were using such a system we could have a comment like this:

{Function X

Description: blablabla

Widgetsets: win32 wince

}
function x()
begin
....

I always liked the comments in-code approach a lot better, but I doubt that we will change now.

Particularly lazarus uses lazde to edit the documentation, which is in XML files that can be outputed into HTML files. It's not particularly easy to work with.

The help is already integrated into the object inspector, pressing F1 shows (or attempts to) show a url with the respective docs. From there we could extract the widgetset information or anything else and then it can be shown this in whatever way desired.

If our current documentation system is too hard an alternative idea would be adding a hint to the IDE on the code.

Maybe:

procedure MethodX; {%widgetsets win32 wince}

This should be quicker and easier to implement then extending the ppu files.

thanks,

Actually I need this to make lazarus ide more user friendly. For example to distinct unsupported by widgetset properties from supported, to show another hints for properties (if that hints named as properties attributes are defined).

Docemntation generation is just an example of another application of this nice feature.

Best regards,
Paul Ishenin.

(...)

Amen, brother Felipe ;-)
The only downside to is that it'll probably be necessary to keep some duplicated parser code...

-Flávio

yeah, and then we compile the source and poof, gone. lazarus doesn't want to parse the sourcefiles forever, eventually we will use the ppu.

Marc

Getting these informations at runtime is definitely a _powerful_ _feature_, it's no more than
.Net's attributes or java's annotations.
Their generation could be activated by a compiler switch like the RTTI {$M+} and {$M-} so in debug mode it will be activated for the LCL code and deactivated in release mode. For
example the following compiler directives could be put at the begining of the LCL units.
So you pay for what you use, and don't have to pay and don't pay for what you don't use.

{$IFDEF DEBUG}
  {$ANNOTATION+}
{$ENDIF}
{$IFNDEF DEBUG}
  {$ANNOTATION-}
{$ENDIF}

By the way why not adopt the Delphi attributes's syntax instead of creating a new one with
incompatibilties ?

Personaly I could use it in the WST to declare entities's serialization style (attribute
properties, embedded array, external elements names ...), SOAP operation encoding (
litteral or encodded ), SOAPAction ....

Flávio Etrusco wrote

The only downside to is that it'll probably be necessary to keep some duplicated parser code...

Actually code tools should already have all parsing capability necessary

so the sample code becomes ( using Delphi's attribute syntax )

TxxxDatabase = class(...)
...
[Engines(List='firebird,oracle,sybase-asa')]
property TransactionModel: TTransactionModel read FtransactionModel

                                            write SetTransactionModel;

...
end;

how is [...] coupled to TransactionModel ?

Just because it happens to be declared the line in front of it ?

Marc

how is [...] coupled to TransactionModel ? Just because it happens to be declared the line in front of it ?

Yes, the attribute declaration is placed imediately prior to the element it applies to.
Example at http://hallvards.blogspot.com/2007/09/dn4dp14-net-only-attributes-support.html

Another usage sample at http://dn.codegear.com/article/36962 In the document, the "[ServiceContract]" is used by the .Net runtime to define service
interface( see bellow ).

type
[ServiceContract]
ISimpleCalc = interface

    [OperationContract]
    function Add(a, b: integer): integer;
    [OperationContract]
    function Subtract(a, b: integer): integer;
  end;

These idiots had to do it totally against the Pascal Language specs. With each addition they butcher it more and more :/ Directives are always placed behind the property/procedure/variable/whatever.

Michael.

This is not Pascal language anymore. This is Delphi language.

That doesn't look like language syntax to me, more like a comment?

Isn't

property TransactionModel: TTransactionModel read FtransactionModel
  write SetTransactionModel attribute Engines: List =
    'firebird,oracle,sybase-asa';

much more logical ?

Micha

Indeed. Exactly my point.

Michael.

exactly my idea, even more since [{ are pretty similar

otoh, it looks a bit like a pragma now

Marc

As attributes is meant to be used with allmost any construct( class, field, property, method
orprocedure parametters, method or procedure, module... ), I think it is a reasonable
syntax;
How would one apply attributes for example to parametters ( don't forget that a parametter
can have one or more attributes )
Also note that this syntax does not add new keyword(s).

They borrow this syntax from C#

[AttributeForTheClass]
class SomeClass
{
[AttributeForTheField]

	int SomeField;
	[AttributeForTheMethod]
	int SomeMethod(
		[AttributeForTheParameter]int someParam)
	{
		...
	}

}

Delphi or Delphi.NET? Does native Delphi do more with it than ignore it?

(like the dotted unit names introduced in D7)

It IMHO isn't, since it is prefixed, like C#, while Pascal (AND variants) usually have directives and modifiers AFTER the keyword.

__cdecl int func(void)

vs

function func:integer; cdecl;

function func:integer; cdecl;

Most of the time yes, sometime no like the following :

procedure proc( CONST AParametter : integer );

IMHO this time, Delphi compatibility is a very strong point.

Op Thu, 18 Oct 2007, schreef Inoussa OUEDRAOGO:

It is a strong point.

On the other hard keeping the language clean is an important responsible task we have. We never planned to be compatible with Delphi.NET. (I have never considered Delphi.NET a real Pascal implementation; it departs rather far from what Wirth designed). While .NET features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features.

Daniël

Marco van de Voort wrote

>> These idiots had to do it totally against the Pascal Language specs. > This is not Pascal language anymore. This is Delphi language. Delphi or Delphi.NET? Does native Delphi do more with it than ignore it?

Delphi.net in this case.

(like the dotted unit names introduced in D7)

Yup. D7 introduced the Delphi Language and killed Object Pascal, perhaps because of the .net stuff.

I dont like idea of maintaining code more than in one place. The best way is to create sone unit to read/write that ppu files and use it in all places: in compiler, dumppu and later in lazarus. Of maybe it is not possible (for fpc I am simple user)?

Btw, is proposed syntax need modification or it looks ok?

Best regards,
Paul Ishenin.

I have a great respect toward FPC devel team. And I do anderstand and respect that FPC team do not plan to be compatible with Delphi.Net.

But IMHO, if a new langage feature have to be introduced, a feature already implemented in Delphi, it will be good to make it compatible. Mainly for code sharing.

I tend to agree, but Borland has neglected Delphi for so long that I really wonder if anything above Delphi7 (or even D5) is truly relevant...

-Flávio

Is there anything to be compatible with? Does Delphi/win32 use this in any way?

No. Win32 delphi complains about such syntax during compilation.

Best regards,
Paul Ishenin.

Well, the unit is in the compiler directory, and is not meant for distribution. It can only be in the compiler directory, otherwise it's impossible to bootstrap the compiler (i.e. compile the compiler the first time).

Btw, is proposed syntax need modification or it looks ok?

For me it is OK. It's more pascal than the construct introduced in Delphi. It's also more like the construct we use for procedures [public,Alias:'some']; and interfaces [GUID], so for me this is very OK.

If you implement this, I suggest you also implement it in pscanner in fcl-passrc, or fpdoc will stop working as soon as you use it in the LCL.

Michael.

But IMHO, if a new langage feature have to be introduced, a feature already implemented in Delphi, it will be good to make it compatible. Mainly for code sharing.

There already is a Delphi compatibility compiler switch. There could be a Delphi.NET (and maybe a Chrome) compatibility compiler switch that allows for the appropriate syntax (and maybe disables incompatible native FP syntax).

-Michael

But why?

Michael Van Canneyt wrote

Well, the unit is in the compiler directory, and is not meant for distribution. It can only be in the compiler directory, otherwise it's impossible to bootstrap the compiler (i.e. compile the compiler the first time).

The RTL is always compiled before the compiler is, so the compiler can use the "new" RTL.

Micha

It's not a good idea to make the compiler dependent on features not available in the RTL of the previous release, as this can complicate debugging quite a bit.

Jonas

Indeed. In this particular case, the code duplication is just a safety precaution. It also allows us to change the interface of the 'public' ppu file at will, so it is more suitable for use in the IDE or whatever library requires it.

Michael.

Jonas Maebe wrote

It's not a good idea to make the compiler dependent on features not available in the RTL of the previous release, as this can complicate debugging quite a bit.

Elaborate please ? You mean debugging of the compiler, but don't you always work on new compilers ? When debugging, you could copy the ppu to the "old" RTL if you're using an old RTL with a new compiler ?

Micha

My global install of FPC 2.2.0 does not include this unit. Compiling it with 2.2.0 and adding it to my global installation is what I consider needlessly complex (not to mention that it pollutes my 2.2.0 install so I can no longer use it to test 2.2.0 bug reports, as I may see different things than someone who installed the actual release), and this practice can easily lead to a complete mess of cascade dependencies on newer versions of units (hoping in case such a unit in itself also starts depending on other new features of the new RTL).

Jonas

This was not my intention. I thought you meant with "debugging difficulty" you were trying to debug the RTL by comparing the compiler behaviour with two different RTLs or so.

Since the compiler is always compiled using its own RTL (you only need a starting compiler binary, but you know this of course); I don't see where the global installed RTL is used (and would perhaps need modification) ?

Micha

This is not true. You can perfectly compile a compiler using the previous' release rtl. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason.

Jonas

Is there anything to be compatible with?

Yes, that is syntax used by Delphi.Net

Does Delphi/win32 use this in any way?

No, but if someday Delphi/win32 has to support attributes it will certainly use the same syntax
and FPC will be ready.

Jonas Maebe wrote

This is not true. You can perfectly compile a compiler using the previous' release rtl.

Sure this is not the question.

E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl).

Adapt the project to use the new RTL ? Anyway, seems "dangerous" to me, not testing possible RTL regressions then.

A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason.

I see the reason is not really coming out, but I'll stop now.

Micha

It is the question because this is actually done by several people.

It's exactly the other way around: you do this when there is a bug in the compiler, and want to exclude extra variables (such as the new rtl) from the equation in order to make it easier to find the bug. You don't do this for testsuite runs.

Jonas

Well, I'd certainly have one (more) reason not to
put it into RTL - I don't think that support for
.ppu file format is something so general and
commonly used by (Free) Pascal programmers that
it should become part of our RTL.

Tomas

And another:
A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name?

Mattias

Op Sat, 20 Oct 2007, schreef Mattias Gaertner:

Only the global structure stays the same. Fields are being added and removed from defs and syms all the time and compiler development progresses.

Daniël

Then I vote for using a copy, which is manually updated from time to time.

Coming back to the real problem:
Searching and reading the ppu is as expensive as reading the sources or reading the fpdoc xml files. So, there is no need to put the property information into the ppu - except for closed sources.

RTTI: The RTTI as storage has the advantage, that you don't need to explore the code.

Comment/Pragma/IDE directive: Using a 'comment' has the disadvantage of expensive finding/reading the source and the advantage, that you don't need the ppu (easier cross exploring, more independent of missing units).

Mattias

It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks.

So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name?

I think such a unit could best go in the packages, since it is tightly bound to FPC, and definitely non-visual ?

Michael.

Are we talking about a complete ppu parser or something to only read the property info?

Well, it should be bound to FPC, but it should not be bound to a specific FPC version.

Mattias

Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't "know" a block, you can 'skip' it. (If memory serves me right, of course)

Exactly. That's why we need a copy. The copy (ppuparser or whatever) can maintain knowledge of past versions, as far as that is needed.

Michael.

Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:

This is not true. Take for example:

    procedure tarraydef.ppuwrite(ppufile:tcompilerppufile);
      begin
         inherited ppuwrite(ppufile);
         ppufile.putderef(_elementdefderef);
         ppufile.putderef(rangedefderef);
         ppufile.putaint(lowrange);
         ppufile.putaint(highrange);
         ppufile.putsmallset(arrayoptions);
         ppufile.writeentry(ibarraydef);
      end;

If the arrayoptions for example becomes a large set (>32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus.

Daniël

Op Sun, 21 Oct 2007, schreef Mattias Gaertner:

Coming back to the real problem: Searching and reading the ppu is as expensive as reading the sources or reading the fpdoc xml files. So, there is no need to put the property information into the ppu - except for closed sources.

ppu's are supposed to be magnitudes faster as you don't need to do any parsing.

Daniël

If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration.

In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years.

IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools.

Mattias

Is the newer ppureader be able to read older ppu?
In other words: Does a current ppureader contains the code to read the old format too?

Mattias

No.

I discussed this already with Paul. My proposal is generate a separate xml file containing the attributes. This xml can be used by IDEs or included in the final executable if necessary.

Op Sun, 21 Oct 2007, schreef Mattias Gaertner:

No, the read code is similar to the write code, no version checks.

Daniël

I understand, but what do you want to say with this ?

Michael.

That was my idea of the .ppi file. Looking at all the discussion, that option now seems best. As you say, it can always be included in the binary, if someone wants it. XML would also allow to merge files easily.

I'm currently looking at a resource library implementation by Giulio Bernardi, which would make that extremely easy to do. It's completely cross-platform, and looks like a very good replacement for the current ELF-only implementation (to which it is compatible).

Michael.

Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian/Paul suggested.

Mattias

I suggested :) Paul didn't like it that much

He started also a wiki page: http://wiki.freepascal.org/Property_attributes

One way to read .ppu files from multiple compiler versions would be a "ppu meta file", which describes the fields written for each sym and def. The will be one meta file per ppu version. An IDE or tool that wants to read a ppu then processes the meta file for the ppu version to know how to find a certain field in the ppu.

Daniël

I still thinking that RTTI is much more useful than separate files. To use separate files you need some framework to find them and parse. If it is RTTI then existing tools can be easily extended to use new feature. In case of Lazarus ppu, xml, rtti is not so different.

But lets think of other applications of property attributes. For example FastScript components (scripting engine of FastReports co.) use RTTI to automatically describe pascal classes in order to use them in script. Property attributes can store descriptions, value area, and another useful info.

Or my example with database components.

TxxxDatabase = class
property TransactionModel: TTransactionModel attributes ['engines:
ms-sql, oracle, sybase-asa'];
end;

Using such attribute database components can easily check whether this property applied to current engine.
If this is stored in ppu, xml it will not used by component developers. And once again - for Lazarus it is not a big difference.

Best regards,
Paul Ishenin.

I got a practical question:
Where and how should the hint be used/shown in the OI? If it is queried only manually (e.g. user moves mouse over property and waits for a hint), then a find declaration can be done and the comment next to the property can be shown. That's easy and we don't need any change or new syntax.
OTOH if you want to check these flags in property editors to color misused properties, then TPropertyEditors must be extended.

Mattias

Such properties can be moved to separate Tab of object expector (like Events and Favorites) or marked with color.

Best regards,
Paul Ishenin.

I discussed with Paul to and I'm not really pro reading and parsing yet another file. Since I think attibutes are valid for more than only published properties/methods putting them in RTTi would be to limited. Besides that, as already stated, it's not really necesary to put this info in the final executable.
Therefore I suggested to put the info in the ppu, something what popped up in a previous discussion. IMO, lazarus will be capabable of reading ppus someday to get rid of the requirement that you can only have autocompletion etc. when all the sources are readable and parsable.

From the current discussion I realize that different versions of ppu files need to be parsed, current formats and future formats. The latter case will bring some difficulties.

With this in mind, I think indeed that a compiler generated second file with xml info about the unit is a better solution. Given that all the info a 3rd party like lazarus would read from source or ppu would be available in that info file. This way all info is quickly available by one file.

Marc

Hello, fpc-developer list.

As "Events" (i.e callbacks at the time being) are syntactically done as properties, could it be possible that property attributes on the long run could help implementing "thread Events" (i.e. a class "fires" an event not as a callback (usually using a the main thread, but if programmed like that using a thread it defines) but uses a thread the program that sets the handler property defines ? Here the programmer does not need to write code that passes the parameters to the thread: the RTL does all this dirty stuff, helping less advanced programmers to do threaded applications <like it's usually done with ADA>.)

-Michael

Are you sure this would make things easier? Code in the handler needs to be thread safe. Starting a thread is very easy, with TThread?

Or do you mean you want something like work queues?

Micha

Are you sure this would make things easier? Code in the handler needs to be thread safe. Starting a thread is very easy, with TThread?

If you use common resources of course you do need to take create to do it in a thread save way.

But if you want to off-load some kind of work to one or more threads you need to do the communication - especially notifications between the threads - in a way everybody needs to invent for himself. Mostly you will (or even need to) use non-portable methods (Windows-Messages) for that. I always feel that it's not "nice" that when doing a thread you can't use event-driven programming (as everybody does in the main thread), but need to do your own work-loop per thread. (I do know that modifying this would be a _major_ RTL enhancement. So I'm not suggesting to start working on that right here. I'm just thinking about a means to integrate it into the language at a future point in time.)

Some predefined, portable and easy to understand (i.e. very similar to main-thread programing) way to work with threads would be a nice enhancement over what any other Delphi-Language successor provides right now. Here I can imagine extending Events (including may those of the standard libraries provide) to working as threads could be a way to go.

Or do you mean you want something like work queues?

Supposedly some queuing mechanism needs to be used to provide parameters to the thread and to pass results back to the program that defined the event would be used.

-Michael