Re: Sorry, but not happy with D2007

Mark Smits wrote:

From a fresh start, I selected New Project, VCL Forms Application.
Then I dropped a Button, an OpenDialog, and a RichEdit onto the
form.

Switched to code view, and CLANG!! Two errors reported:

'Undeclared identifier TButton...'
'Undeclared identifier TRichEdit...'

D2006 does the same for me, it's not just D2007. Units are not added
to the "uses" when placing these components on the form. For example
saving or invoking code completion will add the units at that moment
and you will be fine.

This has been the case since day-one of Delphi. The intent here is
that until you save or compile, the dropped components aren't
"committed." This was a specific design decision since once the uses
clause was updated, it is difficult to distinquish between which units
the user intended to be there and which ones are only there because of
components. On the surface this seems easy, right? The problem comes
in when the user manually adds a unit to that list and then later drops
a component on the form from that same unit, then deletes that
component. Do we keep the unit in the uses list? Do we delete it?
There was a *lot* of thought that went into this design back in
1993-'94. A very similar thought process was involved surrounding the
auto-removal of empty event handlers when saving or compiling. The
simple idea was to allow the user to "try out" lots of things without
introducing "cruft" from previously abandoned changes. It is not until
the user saves or compiles the source do we consider that they are
"done playing" and the changes are then made permanent. It also allows
the user to easily correct a change like dropping a TButton on the form
when they really wanted a TBitBtn (or vice versa).

Fast-forward to today with the advent of Error Insight and continuous
background compilation. While the unit is in this "uncommitted" state,
the background parser only sees the source as it exists in the unsaved
editor buffer. So the uses list hasn't been updated, which causes the
"false" errors you're seeing. I definately can see why this would tend
to confuse the unintiated. This has even tripped up the long-time
Delphi users, since many of them have never really noticed or worried
about this intermediate "uncommitted" state. The source was always
updated, just-in-time so that when saved or compiled everything was
just fine.

This is clearly an area where we should look at improving the
user-experience. One thought would be to hand this "uncommitted" data
off to the background parser that it would then use to "fill in the
blanks" during this intermediate phase.

--
Allen Bauer
CodeGear
Chief Scientist
http://blogs.borland.com/abauer
.