Board index » delphi » Re: Top 3 VCL Request

Re: Top 3 VCL Request


2007-06-08 06:07:40 AM
delphi16
In article <XXXX@XXXXX.COM>,
XXXX@XXXXX.COM says...
Quote
Nick Hodges (CodeGear) writes:

>Russ writes:
>
>>2) Thread Safe VCL - Multicores are becoming the norm and software
>>needs to adapt.
>
>Can you guys expand a bit on what exactly you mean here? What does it
>mean for a GUI framework to be "threadsafe"? What are you guys asking
>for, exactly? For instance, how deep down the hierarchy are you
>talking about? What thread-safety does, say, a TEdit need to have?

I would strongly speak AGAINST that. The effort to get this running and then
also the runtime penalties imo far outweigh the benefit. There IS already a a
synchronize call that can be used if needed.


Agreed
 
 

Re: Top 3 VCL Request

"Russ Holcomb" wrote
Quote
My app always have a main form, what a better place for the message
loop is there?
Some apps don't, but to the main question:
The issue is not so much having a message loop, but the additional functions
and plumbing that Delphi supplies 'above' the main form: the code context,
for example, of the dpr. The hidden application window already exists when
the dpr code is called and begins to execute (generally constructing the
programmer's designated main for as one of its tasks). The main form is only
a client of this system, like any other form.
CodeGear could no doubt rework all this--but unless it were done in the
context of a total 'VCL 2.0' effort of equal magnitude, I can think of a lot
of things I would rather they spent their time on.
bobD
 

Re: Top 3 VCL Request

"Xavier" wrote
Quote

IMO the application window and "main" form architecture should be
entirely replaced with solid parent-child relationships between forms.
I'm not saying I disagree, it is simply a matter of triage: there are a great
many other things I would want changed first.
None of this is as easy as the injuncton to "break away!" suggests, however.
On the one hand, I greatly appreciate Borland's (and now CodeGear's)
historic commitment to backwards compatibility. On the other, nothing is
perfect, and I am reminded of the cliche that friends come and go, but
enemies accumulate: fundamental architectural mistakes are like enemies, and
the VCL has had time to accumulate several. I would like to see basic changes in
the way interfaces are implemented, RTTI, support for generics, a rethink of
some classes entirely (TCollection comes to mind), quite a bit, really.
Personally I would love to see a CodeGear commitment to a VCL 2.0--and that's
really what I mean, not the an attempt to compete with the entire .NET FCL,
but a fundamental, ground-up rethink of the VCL, because it does have real
advantages over an FCL-like structure that attempts to be all things to all
people.
bobD
 

Re: Top 3 VCL Request

"William Tucker" wrote
Quote

Maybe this attempt to explain myself will be better received.
It's excellent OO design and quite well expressed--visual controls should
never be anything but subsribers to underlying code.
Whether it is practical or not is another issue, however. Consider how much
of the VCL consists of wrappers around MS Windows controls that already
violate the separation you're describing.
bobD
 

Re: Top 3 VCL Request

Lord Crc writes:
Quote
On Thu, 07 Jun 2007 12:17:55 +0100, "Barry Kelly (CodeGear)"
<XXXX@XXXXX.COM>writes:

>If Delphi had support for lambdas with lexical closure, this would be
>possible today. it is a more general language extension, and has
>applications outside asynchronous calls.

Just seemed to me to be much more work, and thus less chance of being
implemented :) But yes, something like this would be much neater.

- Asbjørn
Agree completely.
m. th.
 

Re: Top 3 VCL Request

Barry Kelly (CodeGear) writes:
Quote
Xavier writes:

>Lord Crc writes:
>>AsyncCall(Form.SomeMethod, Param1, Param2, Param3);
>async Form.SomeMethod(Param1, Param2, Param3);
>?

How about an equivalent to the existing C#-style of:

Form.BeginInvoke((ThreadStart) delegate
{
Form.SomeMethod(Param1, Param2, Param3);
// other arbitrary code to execute in GUI context
});

? (The cast is needed because of the method signature; with a different
signature, it could be removed.)

Yes, something like
Invoke (ThreadStart) sync|async do
...our code here executed in other thread's context.
end; //invoke
Quote
If Delphi had support for lambdas with lexical closure, this would be
possible today. it is a more general language extension, and has
applications outside asynchronous calls.

Do it! You have all my support! :-)
Quote
-- Barry

 

Re: Top 3 VCL Request

Lord Crc writes:
Quote
On 6 Jun 2007 13:30:45 -0700, "Nick Hodges (CodeGear)"
<XXXX@XXXXX.COM>writes:

>That's kind of what I am saying. I am not entirely sure what it means to
>have a "thread-safe VCL", and I am not entirely sure that people
>understand the implications of what they are asking for.

Personally I don't need a thread-safe VCL, but I could use something
that would make it easier for my thread code to interact with the
visual part of the application...
<snip>
Another usage case for using threads is for doing intensive DB actions (reports,
data changes aso.)
It would be very nice here to have a TThreadModule (much like a TDataModule) in
which we can visually create (and set up using Obj Inspector) our components.
This is especially neat for DB stuff (datasets, SQL commands, connections aso.).
Also, using the Obj Inspector we can set up easily the thread properties.
hth,
m. Th.
 

Re: Top 3 VCL Request

Not if you only read these global variables. And why would you want to
update them?
Dmitry Streblechenko (MVP)
www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
"Robert Marquardt" <XXXX@XXXXX.COM>writes
Quote
Russ schrieb:

>1) Unicode - This does not affect me directly now but will in the future.
>I know it is major for others.


>3) Get Rid of the Application Window - Wow, I have battled that origin
>Delphi hack for years but never heard many others complain much. All the
>trouble they went through in Delphi 2007 to work around should have made some
>light bulbs go off.

Best also get rid of several global variables also. Application,
DecimalSeparator and many more. Ideally all global variables.
Their main problem is that they hamper thread safety.
 

Re: Top 3 VCL Request

Dmitry Streblechenko writes:
Quote
Not if you only read these global variables. And why would you want
to update them?
If the system tells you to update them, you should.
--
Pax,
Anthony Frazier
Victor Printing, Inc.
 

Re: Top 3 VCL Request

Sure. But realistically, how many bugs did you ever have to fix that made
your app crash because one of the threads in your app was accessing a
decimal separator global variable while it was being updated from the main
thread in response to the notification sent by Windows?
If that were the case, I would prefer to fix my own code rather than ask CG to
provide a fix and subject everybody else to a mess of critical sections.
There are a lot more pressing issues.
Dmitry Streblechenko (MVP)
www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool
"Anthony Frazier" <afrazier AT victorptg DOT com>writes
Quote
Dmitry Streblechenko writes:

>Not if you only read these global variables. And why would you want
>to update them?

If the system tells you to update them, you should.

--
Pax,

Anthony Frazier
Victor Printing, Inc.
 

Re: Top 3 VCL Request

m. Th. writes:
Quote

It would be very nice here to have a TThreadModule (much like a
TDataModule) in which we can visually create (and set up using Obj
Inspector) our components. This is especially neat for DB stuff
(datasets, SQL commands, connections aso.). Also, using the Obj
Inspector we can set up easily the thread properties.
A TDatamodule is not a visual component at runtime, so there should be no
problem with a thread creating and using a TDatamodule instance. I know I
have done so in years past without problems.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Some see private enterprise as a predatory target to be shot, others
as a cow to be milked, but few are those who see it as a sturdy horse
pulling the wagon." - Winston Churchill
 

Re: Top 3 VCL Request

On Thu, 07 Jun 2007 18:27:16 +0200, Arthur Hoornweg
<XXXX@XXXXX.COM>writes:
Quote
Nick Hodges (CodeGear) writes:

>Right -- that is what Synchronize is for.
>
>So how should the VCL handle this internally? I don't think folks want
>critical sections around every data and field access in the VCL -- I
>shudder to think what that would do to code bloat and performance.


May I point out a feature that is already in Delphi 2006/
2007: "class helpers".

I can imagine that a class helper could simplify matters, adding
additional threadsafe getters/setters/properties to tcustomedit
etc. without having to change the existing VCL source.

Instead of "edit1.text:=xxx" one would do "edit1.threadsafeText:=xxx"
I don't think this could work. The other methods would have to be
protected.
 

Re: Top 3 VCL Request

On Thu, 7 Jun 2007 21:14:48 -0500, "Bob Dawson" <XXXX@XXXXX.COM>
writes:
Quote
"William Tucker" wrote
>
>Maybe this attempt to explain myself will be better received.

It's excellent OO design and quite well expressed--visual controls should
never be anything but subsribers to underlying code.

Whether it is practical or not is another issue, however. Consider how much
of the VCL consists of wrappers around MS Windows controls that already
violate the separation you're describing.
Yeah--it's a nice idea that won't work until Microsoft shapes up.
 

Re: Top 3 VCL Request

On Thu, 07 Jun 2007 23:27:15 +0200, danny heijl
<danny_dot_heijl_at_telenet_dot_be>writes:
Quote
Dan Downs schreef:

>This probably isn't what you want to hear, but after a little playing around
>I much prefer sending messages back to the main thread than using
>synchronize.

I think this is what everyone is doing (or should be doing) since D6.
I would go as far as saying that Synchronize should be marked
depreciated.
 

Re: Top 3 VCL Request

Wayne Niddery [TeamB] writes:
Quote
m. Th. writes:
>It would be very nice here to have a TThreadModule (much like a
>TDataModule) in which we can visually create (and set up using Obj
>Inspector) our components. This is especially neat for DB stuff
>(datasets, SQL commands, connections aso.). Also, using the Obj
>Inspector we can set up easily the thread properties.

A TDatamodule is not a visual component at runtime, so there should be no
problem with a thread creating and using a TDatamodule instance. I know I
have done so in years past without problems.

Yes, but what if in a TDataModule someone puts a dialog component and tries to
call from the Thread context dlgOpen.Execute?
This is another interesting thing: Each TThread descendant to have a boolean
property like 'OwnMessageQueue' or a way to execute in the thread's context
entire forms. Even if I think that this could be tricky, is a nice possibility
to have since many programs tend to have a star (snowflake) architecture with a
main form in the middle of some secondary forms. Having also a group of controls
assigned to a thread is also nice but perhaps then the performance penalty will
be much bigger.
my 2c,
m. th.
 

Re: Top 3 VCL Request

m. Th. writes:
Quote

Yes, but what if in a TDataModule someone puts a dialog component and
tries to call from the Thread context dlgOpen.Execute?
The whole point of TDatamodule is to be a non-visual container for
non-visual components. So trying to display a dialog from one is clearly a
problem in this case - you shouldn't do it.
Creating a "threadDatamodule" doesn't solve the problem - one can still
write the same problem code.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"Nature abhors the vacuum tube." - J.R. Pierce, Bell Labs engineer who
coined the term 'transistor'
 

Re: Top 3 VCL Request

Quote
Back to TEdit (one thing at a time ;-)): you should be able to:
- read from it
- write to it (.text)
at any time you like and from any thread you like. Also the visibility
and enabled state should be such things.
IMHO, the VCL should never be "thread-safe". The needs of the many outweigh
the needs of the few and by far a majority of access would be non-threaded
or from a single thread. Since there is significant runtime cost in serializing
such work, I wouldn't even spend the effort.
Instead, I'd think that it should be much simpler to implement a global
VCL MultiReadExclusiveWriteSynchronizer. This object would be checked in
the main message loop as required. Then setting a VCL property form any
thread would be as simple as entering the MREWS before setting it. If you
wanted to really get cute, you could make a compiler keyword that did it
automagically on the back end. something like:
threadsafe Edit1.text := 'my text';
or
threadsafe
begin
Edit1.text := 'my text';
Edit2.text := 'more text';
end;