A new VCL

Phil Cain
--

--

@
_ \<_
(*)/(*)
-----------------------
BORLAND-COREL The Deal is Kilt

There's plenty to build on.

John

"Philip Cain" <phil...@orelle.com> wrote in message
news:9l70kskhe0t4r4s5i...@4ax.com...

Greg Lorriman wrote:
>
> It's a bit old and crumbly.
>

You mean something like CLX?

btw, that's the new VCL for Kylix, built from the bottom up.

--
Wayne Menzie

Mark,

The VCL dates back to D1. Although there have been some changes,
notably in the data-aware components, it is still the first VCL
concept. It was written when there was no broad-based experience with
using them. Now we've had something like six or seven years of
experience by a lot of programmers. I wonder if it might be useful to
revisit the concept. Knowing what we know now, would VCL2 be any
different from the original?

Phil Cain
--

But the framework as a whole seems solid. At least in my eyes.

That is why I would like to see explicit examples of where the frame
fails. (Multithreading excluded, of course ;)
I consder seeing where others see the framework lacking as nothing but a
learning experience.

Mark

--

"Mark Bracey" <red...@interaccess.com> wrote in message
news:39402D4E...@interaccess.com...

--
Cheers,

Phillip Flores
PCF Consulting P/L
0416-118-734

And I think it will be in D6 as well. Someone wrote an article (or post)
about what Chuck J showed them at some conference/presentation.

Regards

Peter

The classic example would be better use of interfaces throughout the VCL.
The data-aware part of the VCL could particularly benefit from this.
Interfaces were added to Delphi3, and so the whole basis of the library was
designed without them. A 'ground-up' rethink using interfaces would likely
produce a quite different, even more reusable, more readily extensible
library. Put those years of experience to use!

The other thing I would hope to see is a greater understanding of the needs
of we poor BCB users. The VCL exerts many pressures on us and breaks our
standard language in many ways. In some respects dealing with VCL code
feels like using a crippled product. The worst part is when Delphi adds new
technologies that get around the restriction, that don't extent on to us
thinking interfaces here! ). A worthwhile redesigned would bear this in
mind up front as well.

A redesign just for the sake of it would be an expensive waste of time.
OTOH, a redesign to extend to new environments may or may not incorporate
some of teh above. Let's see what CLX delivers :¬ )

AlisdairM

IIRC, John Kaster also said as much when he was out here last month.

--
Wayne Menzie

Ever heard of CLX, which will be Qt-based?
--
Rudy Velthuis

Hardly built up from the bottom. It's based on Qt from TrollTech.
--
Rudy Velthuis

Well, the biggest problem with the VCL is that it isn't multi-platform
friendly. If they do CLX right, it should serve Windows just as well as
Linux, and *perhaps* other operating systems later.
--
Please respond only in the newsgroup. I will not respond
to newsgroup messages by e-mail.

Kind regards,
Joachim Engel.

I think that all of us could come up with a list of at least a hundred
little things we'd like done in a redesign. It wouldn't serve much to
pick over them here.

However, I would begin the redesign discussion with two questions.
First, can data-aware tools combined with non data-aware tools so
that there is no longer a distinction? That is can it be that the UI
can be designed without a database and then connected to a database
without changing components? This has heavy implications for RAD, I
think.

Second, what would components look like if designed from the UI
backwards instead of from the machine out? I've spent a lot of time
tweaking the UI to respond nicely to the user. The components are not
always very friendly there.

Phil Cain
--

I think Philip was looking for more significant changes. Personally, I
would like to see a rewrite with higher utilization of interfaces. This
would make VCL more flexible, and more robust for changes. Right now, any
change at the top of the hierarchy cascades to all descendants, so some of
needed changes are simply not possible, because they would break too much
of the existing code. Given these obstacles, they are still doing a
remarkable job in improving VCL from a release to release. But with
interfaces/composition their lives would be much easier.

I am sure that with the current focus on Kylix they don't have the time to
do anything right now, but sooner or later they will have to make a
rewrite.

Michael

Rudy Velthuis wrote:
>
> Philip Cain wrote...

This would give them cross-platform support.

Regards
Praful
(Remove spam-spoiler "ABC" from email address)

> Phil Cain
> --

Then we'll be sure to do it right.

--
John Kaster, Borland DevRel, http://community.borland.com
Help me raise money to fight cancer
http://homepages.borland.com/jkaster/tnt/index.html

Michael,

What kind of changes would you like to see?

Phil Cain
--

bottom := Qt;

<g>

--
Wayne Menzie

-Brion

Yes, but what about compared to MFC

Actually Interfaces would make inheritance is more of a pain since we would
have to inherit all of the interface. We could not override what had been
defined in the interface we could only change its implementation or create a
new interface.

I really see no advantage in this.. For your own classes I see an advantage
for sometimes using interfaces (especially for a class which implements more
than one interface).But for a library, I see none or extremely little. In
fact it would become more of nuisance in most cases.

But perhaps you could point some advantages out for us.

news:rge2ksciakm663jt4...@4ax.com...

You can modify standard TDBEdit for use it with and without active
datasource (as a standard TEdit)
It's required one property and 6 lines of hack code :)

with best regards,
Ilya Andreev AKA Andre
DelphiCity Team
www.delphicity.net

news:6k26kss721v5pmq1q...@4ax.com...
> Marco Menardi <mme...@lycosmail.com> wrote:
>
> >I agree with you, but I don't necessary think about a completely new
> >one, but a improved one.
>
> Marco,
>
> Thanks for your interesting list. I especially liked the comments on
> TEdit and TDBEdit. I would like to combine those two so that there
> would be only one TEdit and you could use that for database data or
> ordinary string data. I don't think we cold do that without a
> completely new VCL.
>
> Phil
> --

Ilya,

Yes, I understand that. But that is not the same as eliminating the
difference between data aware and non-data aware components generally.

We have always been able to fiddle with the code and that is a good
thing. My view, however, that there is too much fiddling required to
make the components work well. I believe that a general redesign of
the entire VCL set could boost programmer performance materially.

Phil Cain

--

Good luck! =;->

Kind regards,
Joachim Engel.

> I will also need:
> - A better DBGrid

YES! YES! YES!
You're not alone! I strongly second that!
(and the other points, too)

The hint from Borland to use 3rd party stuff,
is just hiding their own failures.

Grids are one of most used controls
in database development.
To enhance grids is so much work to do.

Kind regards,
Joachim Engel.

Well, as I'm already said, we have the controls (editors, comboboxes, etc -
inhertited _from standard_ components), that working as db-aware or
non-dbaware, therefore, we havn't any problem :)
But, will be very nice to have interfaces for dbaware, build in low-level
components. (e.g. TControl), and provide standard properties (such
DataSource, FieldName etc). Yes, we also did it ourself, but...

"Eugene Mayevski" <maye...@eldos.org> wrote in message
news:8i68nr$ab...@bornews.borland.com...

> Philip,
>
> Delphi is not stuck with DB. And, thanks God, it's not only DB-aware.
> For example, I never used it for DB development, and I'm quite happy
> with this fact. Why do I have to carry additional DB code in my
> application? the approach of having a separate DB-controls is very good.
>
>
> --
> Sincerely yours,
> Eugene Mayevski
> http://www.eldos.org - the source of original software
>

I am aware that there are actually Delphi programmers who don't do any
DB development<g>.

And I agree with you that it's not good to carry unnecessary code. (I
don't like the fact that D5 programs seem to be fatter than D3
programs with the same source code, for example.)

But having one TEdit component that can be used for either data-aware
or non data-aware does not mean that the component has to carry around
a lot of DB code when the programmer doesn't want it. It might mean
that, if the component were badly designed. But it's possible to
design a TEdit that can be used both way without the burden of DB code
and that's what I want.

Phil Cain
--

Ilya,

This is more like what I had in mind. Some new property, let's call it
TDataValue, that every component would have is the right idea.
Something with the same sense as the Text property.

This TDataValue could be a string or a link to a TField through a
datasource, perhaps. The programmer would have the choice. Or perhaps
there could be more than one kind of datasource component, including
one that was not data-aware.

The objective would be to separate the data source from the interface.
Programmers could then concentrate on UI development as a completely
separate issue and so very sophisticated UIs wouldn't have to be
restructured to accommodate a different data source. All s/he would
have to do is to change the source that feeds TDataValue.

What a boost to RAD this would be!

Phil Cain
--

My problem with this route would be the added overhead and final
exe size. Now, if the compiler stripped out these features if not
used, that would be okay.

--
Daniel J. Wojcik
It looked so nice out this morning...
...I decided to leave it out all day!
--

And how would you do that?

Mike Orriss (TeamB)
(No e-mail replies, please, unless explicitly requested!)

It doesn't have to be all or nothing -- there is a middle ground.

Data aware controls are not the only case of a view which needs to be
kept in sync with a model. If the concept was abstracted a little
further, the "datasource" could be useful to non-DB programmers.

-Craig

--
Craig Stuntz Vertex Systems Corporation
Senior Developer http://www.vertexsoftware.com

Daniel,

TDataValue need not have much overhead at all. The idea is that it's
simply a portal to allow attaching any kind of data input. E.g.:
TEdit.DataValue := 'hello world';
or
TEdit.Datavalue := TField.DisplayText;
or
TEdit.Datavalue := TField;
or
TEdit.Datavalue := MyStringList;

TDatavalue would have one job: recognize the type on the assignment
and pull in the appropriate value from that type.

However it works, it need not have the functionality of the thing
assigned. It just has to communicate. The objective, of course, is to
have exactly one TEdit in the interface and so exactly one TEdit set
of interface behaviors with no need to change fundamental components
to accommodate data sources.

My guess would be that we already have the bits and pieces we need.
What is lacking is the decision to put them together. However, I don't
think this can be done without breaking current code. And so I
suggested a new VCL.

Phil Cain
--

So what do you want here, Mike, a free gratis answer?<g>

Specifically, of course, I don't know how I would do it. What I have
for sure is a burning need to separate UI development from data
development and to take a big step forward in RAD. It's got to be
possible and the payoff would be huge, for me anyway.

Conceptually, it seems possible to make a property (I called it
TDataValue elsewhere) that could take any form of data input (direct
assignment of a string or number, reference to another object
including TField, for example).

TDatavalue could be designed to figure out what type of thing was
assigned and to fetch the displayable data and to pass changes back to
the assigned type if appropriate. This is a 'portal' approach and
would require a corresponding discipline in other objects generally to
handle the conversation, which is only the passing of a data value.

Alternatively, it's possible to think of a TDatasource set of objects.
Some of them could be data-aware and some not, but this set could be
compatible with the TDataValue portal.

I don't claim to be a component guru, only to have read enough
component code not to be afraid of it any more. My feeble conceptual
solutions here are pretty clumsy but I have to believe that this is
doable by a crew of experts who could focus on it.

I'll say again for the record that I know this breaks a ton of code
and that's why I mentioned the possibility of VCL2.

Phil Cain
--

We try to do that too. Loading the form is independent of the actual UI
controls used, and data access is independent of the actual storage
mechanism thanks to the use of a DataModule.

>There are several easy techniques for doing that now.

Mike,

That's the right idea, but among the difficulties and limitations are:

1. Loss of TField and Dataset properties and/or references at the
component level.
2. Loss of ability to use third-party products and features - like
incremental search.
3. Non-trivial LoadData/SaveData adaptations for things like lookup
combos.
4. The grid thing.

As long as we're on grids, the basic grid design doesn't allow easy
detection of movement from cell to cell. The row-wise and column-wise
orientation are just not good enough for best practice in UI
development. This corresponds roughly to the lack of field-to-field
events in the data-aware controls. There, the row-wise orientation
just doesn't have the granularity for the best work.

At this point, it might be instructive to look at TopGrid. AFAIK, this
is the only grid component on the market that can be used for both
data-aware and non-data-aware sources. This looked like just the right
thing but I stopped using it because switching from one mode to the
other was difficult.

All data in TopGrid is external. That's good because the grid is all
interface and it should have been possible to tune the interface
finely and then add the data. I had rolled my own dynamic array
(before they had one) to hold dummy data while working on the
interface. But then changing from the array to the dataset wasn't just
the simple matter of pointing a property to the source. Dataset
sources required using different methods in different ways. That
changed the UI behavior in subtle ways. I finally gave up on it
because I didn't think the improved functionality was worth the sweat
investment.

Even so, TopGrid contains a number of conceptual improvements over
basic VCL design. It does have cell granularity and it does give more
information in the methods and events about direction of motion and
who started the event (user or program). These UI improvements aren't
just added functionality. I believe that they are basic things that
came from experience that didn't exist when the VCL was first
designed.

And that, at last is my point. I am not looking for a way to fix my
code here. I believe that the programming community has outgrown the
VCL and it's time for a new one.

Giving OOP it's due, the VCL is not infinitely extensible. We can add
things, but we are always tied to the assumptions of the original
design. Because of the limitations of TComponent and the
interdependencies that are built in to data-aware components and
sources, it's not feasible to simply morph a TEdit into a TNewDBEdit
or TBiModalEdit.

The VCL was a good design, then. But now we have more experience. Now
we no we can do more. Now we need more. Now we can make a rather long
list of things that components should be, things we didn't know 8
years ago. A new design focus for the UI and data sourcing could put
us a quantum leap ahead of where we are now and where we can't go with
the current tools.

Phil Cain
--

Joachim Engel wrote:

--
Spam Guard:
All replies sent to this address from hotmail.com will be deleted.

Please send me an email where you have a priavte that you want protected and
I'll look into it.

>
> But the framework as a whole seems solid. At least in my eyes.

It is a great framework! and it is updated and tweaked each release. The
main reason why it doesn't seem to change is that it is a solid framework
that doesn't need to be changed.

-- Robert Kozak (Borland)

-- Robert Kozak (Borland)

"Joachim Engel" <jen...@engel-edv.de> wrote in message
news:39410A...@engel-edv.de...
> Mark Reichert wrote:
> >
> > Well, the biggest problem with the VCL is that it isn't multi-platform
> > friendly. If they do CLX right, it should serve Windows just as well as
> > Linux, and *perhaps* other operating systems later.

> Kind regards,
> Joachim Engel.

Use the venerable model/view/controller paradigm to keep the visual
display and its data separate. This was difficult to implement in D1 and
D2, but ceased to become so once interfaces were introduced in D3.

Or create an new TDataSource-type component. Mmmmm, call it
TDataIO.

It would contain a list of fields in the DataSet, and a list of
components that would handle the display of the data (TEdit with
its .Text property or whatever) that are mapped to the DataSet
fields.

Wouldn't be as easy as stated, but not that hard, either, for
someone who knows what they are doing regarding notification
events (me not being one such person).

Daniel J. Wojcik
http://www.genjerdan.com/index.htm

> > Use the venerable model/view/controller paradigm to keep the visual

This is both more complicated and less flexible than MVC because MVC
will work with any data type, not just database fields.

> But the request was for support for a TEdit that was optionally data-aware
> but without the database overhead if you use it in a non data-aware
> fashion.

Which can easily be done with MVC. Standard edits come with a default
data model that holds a string, and DB-aware is handled by supplying a
data model with a TField instance that you pass to the standard edit,
thereby replacing its internal string model. The beauty of this approach
is (a) you can write custom data models that allow a control to display
and edit any appropriate data type without ever having to subclass the
control itself; (b) the data validation and manipulation code is kept
separate
from the UI; (c) a data model written for one control can usually be
"plugged into" various others, so you get enhanced code reuse; and (d)
you can have several simultaneous views of the same model, thereby
giving the sort of synchronization we now have with datasets to _all_
types of data.

Richard,

That sounds like a good idea. What's MVC and why couldn't a new VCL
include that kind of functionality?

Phil Cain
--

http://www.fourbit.com/products/fab/papers/fab_mvc_clients.html

Enjoy!

OK, so it's a component library for C++ ( or so it seems).

What I need, I believe, is a better component library for Delphi. MVC
shows only that such things are possible. I don't know if I would take
exactly the MVC approach in Delphi, but I do wish that Borland would
come to the conclusion that a new library is a necessary and a good
thing.

Phil
--

The reference I gave describes one particular implementation of MVC,
which happens to be for Java (not sure where C++ camer from). There's
nothing C++ specific about the idea of MVC.

Philip Cain wrote:

> Craig,

No it isn't - MVC (model-view-controller) was originally implemented
in Smalltalk a couple of decades ago as a way to support the concept of
building UIs out of "pluggable" reusable components - it is a design
pattern,
not a library for a specific language. The idea is that you separate the
code for a
UI into three separate classes which handle display logic, data, and the
messaging between the two (and user interaction therewith) respectively.

Delphi's data-aware controls are _almost_ MVC based in that you have a
view (control), model (a TDataSet, or in most cases, A TField), and a
controller (TDataSource), but the design is poor because operations that
should
be implemented in the model are in views, operations that should be in
the controller
are in the models and views, etc. - it is thus a special-purpose solution
which only
works in one specific scenario instead of a generic one that can be used
in any
scanario.

A true Delphi MVC solution would offer the capability of being able to
build visual data
components out of any data type, plus visual controllers that encapsulate
much of the
UI-specific code (which can be re-used with any data model, and most
views) , and the
ability of using these to connect the visual data models to any number of
synchronized views
(e.g. having an integer value that is connected to both an edit control
and a scroll-bar,
without having to write a single line of code, and with the same live
design-time viewing
capabilities that we now have with data-aware components). In other
words, non-DB
data and UI code become part of the same rapid-prototyping system that we
now use
for databases, while at the same time replacing much of the
domain-specific code from
the current data-aware controls with a single pointer to a specialist
Controller sub-class,
and some method calls. You thus end up with significantly more RAD power
than we
have now from half the number of controls, and the resultant framework is
both more
flexible and much easier to extend than the current system because you
only ever have
to write one version of any control, and that control will be even
simpler than many of
the current non-DB-aware versions, let alone their DB-aware counterparts.

Any 3rd parties taking this approach? I believe there is no reason this
could not be derived from TControl / TComponent using the existing
tools...

Failing that, it just may be time to see if we can get an Open Source
project going. The idea sounds far too useful to pass up. Of course,
finding the time for such an OS project is another matter, never mind
firing up other contributors! Maybe something will spark at the
conference this year. With CLX on the way. people may be a little more
willing to look into VCL replacements, even ones built on top of the
VCL!

AlisdairM

No, it's an architecture, Model-View-Controller, which is probably
implemented by many libraries. There are other libraries that use a
simplified architecture, Document-View (MFC and the C++ OWL use that).
--
Rudy Velthuis

If you are interested, maybe JEDI VCL would be a venue to do it?

http://www.delphi-jedi.org/Jedi:VCLVCL

We don't have much activities at this moment, but maybe something like this
would be a good start to create something cool <g>

Michael

Craig and Richard,

Thanks for your comments. This certainly shows that such a design can
be done. I agree with you that there is an important improvement in
programmer productivity and program quality because of the impact on
RAD. (By "important" I mean always that I can make more money.)

However, I think I need that functionality in the Delphi VCL. I would
be reluctant to move to what looks like a third-party replacement for
the VCL if only that there is a terrific infrastructure of value-added
products for Delphi's library. I would not want to cut myself off from
that.

Additionally, the separation of component from data source is only the
beginning for me. My new VCL would have a simpler, more consistent
programmer interface (at least in the IDE) and be more user-focused.
Unlike many programmers I suppose, I look at a component (or any
object) from the outside in, not the inside out. That means that I put
the end-user conversation first and the mechanics of the code second.
Every day I code my list for those kinds of changes gets a little
longer.

Phil Cain

--

Michael,

This looks promising. I don't know what kind of coding contributions I
could make (I don't consider myself an expert component coder.) But I
would be interested in doing what I could to define requirements for
user orientation and data awareness.

I also have an interest in the vocabulary used for names. For example,
a "click" event might be reserved for mouse clicks only and not
allowed to become collective events (e.g. TListBox).

I might also be interested in editorial standards for help files.

Is any of that useful?

Phil Cain
--

Probable the best would be to subscribe to JEDI-VCL mailing list, and start
a discussion about it:

http://www.egroups.com/group/JEDI-VCL

I think, it would be nice to have an "Interface Repository" with standard
interfaces defined, so the developer wouldn't have to reinvent the wheel.
Following your example, it could contain something like:

IClickEvents = Interface(IUnknown)
procedure Click;
procedure DblClick
end;

If you want to start something like this, please let me know.

We have a Help Team and your involvement would be great. Please contact
Kevin Gallagher <gall...@teleport.com>.

You can also check out our Team pages:
http://www.delphi-jedi.org/Jedi:TEAMSMAIN
and contact teams in your areas of interest

Michael

> I'm sold, where to I buy my 'MVCL'? :¬ )

I did see one Delphi library that used MVC, but it was I think a complete
VCL replacement - this is IMO not really an option for most Delphi
developers, who have a considerable amount of both learning time,
and legacy code invested in VCL.

You could indeed derive an MVC framework from the existing control
hierarchy. Interfaces would I think be a key technology here, plus good
use of the OpenTools APIs to provide wizards that can help automate
building data models, controllers, etc. thereby allowing newbies to derive
the relevant plug-in classes without having to do extensive OO coding
by hand. This need for a fair degree of OO knowledge has traditionally
been the biggest barrier to MVC gaining wide-scale acceptance, but
RAD tools can overcome this even more easily than they did when they
made Windows programming into something that wasn't restricted to
a few massochistic specialists.

I.m sure Michael Beck would love the idea!

That's my problem at the moment - no time.

I'm eagerly awaiting CLX just to see what Borland have done this time
around.
They've got the benefit of both the hindsight that having had to revise and
redesign
the VCL over the years has given them, plus plenty of experience with other

non-Delphi systems like Java's Swing, so I have a sneaking feeling that
there'll
be some very pleasant surprises inKylix.

Absolutely! <vbg>

Michael

Phil Cain
--

My worry is that in the attempt to bring us Delphi on Linux they may feel
too constrained by the heritage, never mind the time-to-market pressures.
I'm too am hoping for a bit of a remodelling, but expect to see little more
than a facelift to support cross-platform development.

The one advantage of setting your expectations low is that often you get a
pleasant surprise. :¬ )
I'm hoping this is one of those occasions, but certainly not banking on it.

Hopefully we'll be a little wise in 3 weeks time! (post conference)

AlisdairM

On the other hand, I've seen a number of NG posts by Borlanders which say
that they're pretty much determined to "do things right" with CLX. As the old
saw says, hindsight is 20/20, and Borland are at least as aware as anyone of
the scalability and maintainability problems that the VCL has: while this
might
not result in something as radical as MVC in CLX, it may well indicate that
there will be an improved architecture that will make implementing something
like MVC rather easier in Kylix than it is in Delphi.

This is true!

I don't think Borland can afford to drop the ball with Kylix, and they know
it - I thus have rather high expectations for the product.

Yes - it promises to be an exciting event. Unfortunately, I can't get there
because of prior commitments, but I'm sure that the web and these NGs
will have plenty of "after the event" info.