Re: Sorry, but not happy with D2007

David Erbas-White opined:

The IDE crashes often enough that I automatically hit the 'save' key
every few minutes

So it seems that the first solution is to make sure the IDE is very
stable and won't crash on you so often. I think in D2007 that has been
largely accomplished. It's probably the most stable Delphi I've ever
seen (going right back to Delphi 1). Even versions of Delphi that
people think of 'stable' (such as 5 and 7), usually crashed several
times a day on me, particularly when third party components and add-ins
are introduced. I have had a much better experience with D2007.
That's not to say I don't ever see any problems, just that I no longer
worry about the IDE crashing on me. So, the bad habit that we've made
of saving every few minutes is one that we can break, and is now OUR
issue, not CodeGear's.

and there are often times I prefer to put a
program stub in place to 'remind me' that I intend to put an event
handler there. For example, if I drop an item on a form I typically
put stubs in the event handlers that I believe I'll need so that I
don't forget about them.

I do the same thing. I'm sure many people do. I think the real
solution here is for there to be an IDE option to turn off the
'automatically wipe out empty event handlers'. This is the real
solution, in my opinion, and maybe add a 'clean' menu item or keystroke
that will do it manually in case you really DO want to nuke the empty
ones.

The fact that you've tried to make this 'seamless' fails on two
fronts. Because you 'automatically' remove all empty events, it
forces me to take the EXTRA time to always had a comment line in each
event, which I wouldn't have to do otherwise. And because the IDE
crashes so often, means that I have to take the extra actions of
saving, PLUS I don't have the advantage of 'trying out' things
without extra stuff being added in.

Premise 1: You aren't FORCED to do it. You choose to do it to avoid
having to go back to the inspector and dbl click the event handler slot
to re-create it. I agree with you that I'd like to see this be an
optional behavior. I think saying "forced" is a bit of a stretch
though.

Premise 2: Again, "the IDE crashes so often" does not apply to D2007.
Even D2006 was pretty stable, but D2007 is much better even than 2006.

One of my current programs is (frankly) a mess because of the 'crap'
that's been added 'automatically' over the years -- but it's too much
trouble to actually try and go through and see which items that are
included are actually NEEDED.

There are utilities that do this. On the Delphi side, Pascal Analyzer
and various other little utilities will do USES analysis and other
metrics to help you clean up your code.

What would be far better (aside from the obvious of improving
stability) is that these options be able to be specified by the user.
It should remove empty events, or not, based on a checkbox -- and
there should be a method to FORCE removal of empty events.

You and I are obviously on the same page here.

My concern in seeing this is that there was no 'advent' of Error
Insight that just occurred through natural selection. At some point
there should have been some hard, concrete thought put into how
adding items such as Error Insight would AFFECT these early design
decisions. At the very least, AT THAT POINT IN THE DECISION PROCESS,
cleaning up those design decisions should have been put on the 'to
do' list. The fact that a software tools company appears to have
been caught 'off guard' by the 'advent' of these new features does
not engender a feel of security in the development process...

Actually, if you really want to go to where I'd like to see long time
issues fixed, I'd rather Codegear spend a little time with their
confirmation dialog systems in the IDE, where it could gather the state
of things and present ONE dialog rather than any number of individual
Yes/No dialogs. You want to talk about something that drives me batty,
it's the lack of a unified confirmation dialog that handles any number
of open files, for example.

Randy
.

Relevant Pages

  • Re: Delphi 2005 update 1 is out!
    ... Delphi 2005 Update 1 Fixes ... When importing an assembly if the types Pointer or Exception are used ... bdpDataAdapter can cause the IDE to lose all key stroke events until ... Using a remote data module may cause an Access Violation. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Update one... are you serious?
    ... Delphi 2005 Update 1 Fixes ... When importing an assembly if the types Pointer or Exception are used ... bdpDataAdapter can cause the IDE to lose all key stroke events until ... Using a remote data module may cause an Access Violation. ...
    (borland.public.delphi.non-technical)
  • Re: Why arent you upgrading?
    ... Stable IDE - this is first and foremost before anything else. ... MS alternate choice - As I see it the reason Delphi became so ... better database support ... Then announce that 64-bit native compiler is in progress and started. ...
    (borland.public.delphi.non-technical)
  • Re: So Long and Thanks for all the Fish!
    ... I think Borland and Delphi needs a .NET story of some kind, ... I'm not so sure the market is engrossed with .NET any more than it was ... The IDE is already very much a .NET IDE ... Refactoring and Together are easy enough to replace if CodeGear is ...
    (borland.public.delphi.non-technical)
  • Re: The alternative Delphi roadmap to success
    ... Delphi 4 is a pretty fast and stable IDE that even runs stably ... Unfortunately Borland is behind right now, ... The Explorer Edition is exactly the same as the Professional ...
    (borland.public.delphi.non-technical)