Definitely the buggy Error Insight!

I guess anybody who uses a D2005 or newer knows this bug... you are writing code that compiles well but Error Insight tells you it can't resolve a unit name or you use an undeclared identifier etc...

This bug still exists in Rad Studio 2010! Unbelievable (I am experiencing it right now)!

To the shame of Borland/Codegear/Embarcadero/ (funny thing, this bug survived every sale :D ) a third party developer managed to fix this bug... Who doesn't know Andreas Hausladen ^[1]?

Edit: This seems to be #QC33546 ^[2] (the first one I found, but I bet this has been reported more than once)

Not having UNDO in the forms editor. Can't believe nobody else mentioned that!

You play a bit with the controls in the forms editor, move them here, move them there, then click undo, then move them elsewhere... oooops... did I say "undo"? What's that? Not something you'll use in Delph Forms Editor.

I vote for UNDO to be removed from Notepad, Visual Studio and Photoshop as well. If you screw up your form, just make it again from scratch. That's the way to design forms in 21st century.

1. Ctrl+Click
2. Nothing happens
3. Goto 1

I simply want a CASE statement working with anything and not just ordinal types !

The IDE removing {$ifdef} statements and units from the unit list in the dpr file.

This is especially painful with a large dUnit "test" project I work on. The project (which I've inherited) includes a number of unit, integration and regression tests. I don't want my CI server to run the regression tests every time somebody checks in code, so I use {$ifdef}/{$endif} statement around the units. FinalBuilder then defines that conditional before building the project.

If the item is not currently {$defined}, Delphi will remove ALL of the units between the {$ifdef} and {$endif} whenever a unit is added to the project.

If the value is {$defined}, Delphi will remove the {$ifdef} and {$endif} statements from the unit list, but all of the units will be kept.

One of my biggest nitpicks is the help file. I almost never have a satisfying answer and need to search further. Hopefully it will get better.

No regex support. I would love to have regex support in the IDE using a modern regex flavor and in the language without having to look for third parties components, DLLs and such.

Update: Delphi XE now has TRegEx in the language.

The default comments in new form classes for the public and private sections.

What a waste!! And what a terrible example of how to use comments!!

Please stopit!!

I hate that control-clicking something doesn't take you to its declaration when debugging.

Resource compiler's inability to handle "Vista-style" icons.

Not that Microsoft is blameless. After two iterations of Visual Studio you still can't include a png compressed icons.

Packages

• Design time packages
• Runtime packages
• DsgnIntf.dcu not found
• File not found: 'DesignIntf.dcu'
• having to even install packages

Visual Studio you just have a Component in your project, and it's available on the tool pallet.

WITH

Without a doubt :-). With is pretty evil as it leads to confusing and hard to maintain code. Of course one never uses it oneself, and undoubtedly it should be classified as a language feature you should never use, but it tends to pop up far to often in code examples, particularly for beginners who then use it liberally only to learn from experience later that this is not a good idea. OK it's a Pascal thing, but it could, should, have been dropped.

I spent a decade coding Delphi pretty intensively from version 1.0 (and I used to use Turbo Pascal too) up to 7 when I largely moved elsewhere, and in that whole time I think I found one single occasion when I needed a with to pass a pointer to the correct member of a very complex structure to a function.

I hate it when I open a project form and it wants to delete components on my form because Delphi IDE doesn't care about helping me keep my packages installed and up to date.

A much better solution would be for project files to declare their dependency on a particular set of components, by name, and then having the ability to search the installed component set, and find all missing component names, and install the components that are missing.

Imagine that beside each myproject.dproj file there was a myproject.d14_pkg file, and any time that a component is added to a form in my project, the bpl and dcp files are added to that .d14_pkg file (seven zip format). Then when you open your project folder on another computer where that bpl and dcp file are missing, the project will auto-install the bpl and dcp files into their required working locations, and your form opens.

Circular References

There's no reason why you can't get rid of this problem.

Any explanation for it's existence includes, "because the compiler..."

Circular Reference Example

Customer.pas:

unit Customer

uses
    Invoice;

type
   TCustomer = class(TObject)
   public
      ...
      procedure SetMyselfFromInvoice(Invoice: TInvoice);
   end;

Invoice.pas

unit Invoice

uses 
   Customer;

type
   TInvoice = class(TObject)
   public
      ...
      procedure SetCustomer(Customer: TCustomer);
   end;

Workaround #1

Declare both types as TObject in the interface section, and do a checked cast at runtime to ensure it's what you want:

procedure GetMyselfFromInvoice(Invoice: TObject{TInvoice});
procedure SetCustomer(Customer: TObject{TCustomer});

Workaround #2

Strand one object, not making it away of the other:

   TCustomer = class(TObject)
   public
      ...
   end;

   TInvoice = class(TObject)
   public
      ...
      procedure SetCustomer(Customer: TCustomer);
      procedure UpdateCustomerFromMyself(Customer: TCustomer);

   end;

Workaround #3

Strand the other object, not making it away of the other:

   TCustomer = class(TObject)
   public
      ...
      procedure SetMyselfFromInvoice(Invoice: TInvoice);
      procedure SetInvoiceCustomer(Invoice: TInvoice);
   end;

   TInvoice = class(TObject)
   public
      ...
   end;

Workaround #4

Merge two units into one large unit:

Everything.pas:

unit Everything

type
   TInvoice = class; //forward

   TCustomer = class(TObject)
   public
      ...
      procedure SetMyselfFromInvoice(Invoice: TInvoice);
   end;


   TInvoice = class(TObject)
   public
      ...
      procedure SetCustomer(Customer: TCustomer);
   end;

Workaround #5

Use the TPersistent/Assign anti-pattern:

   TCustomer = class(TPersistent)
   public
      ...
      procedure Assign(Source: TPersistent);
   end;


   TInvoice = class(TPersistent)
   protected
      procedure AssignTo(Dest: TPersistent);
   end;

Workaround #6

Use a separate helper class:

CircularReferenceFixer.pas:

unit CircularReferenceFixer

uses
   Invoice, Customer;

type
    TCircular = class(TObject)
    public
       class procedure CopyCustomerInfoToInvoice(
            Customer: TCustomer; Invoice: TInvoice);
       class procedure SetInvoiceCustomerInfoFromCustomer(
            Customer: TCustomer; Invoice: TInvoice);
   end;

All controls on a form should be private by default.

Controls on a Delphi form always have published visibility, and this can not be changed, because streaming from/to DFM requires it. But IMHO it violates the Encapsulation / 'Information Hiding' principle, and also floods us with information: if a developer types Form1., the IDE will present her a list with all controls, when she only wants to see one (or two) public methods to show and execute the form. Update: let's call these published properties 'Unsolicited (SPAM) properties' ;)

I keep mentioning this (it's in QC etc) and I hope that one day, someone in the IDE team will take pity on me. I'd REALLY REALLY REALLY like to be able to change the colour of the red wavy-underline error-insight marker.

I'm colourblind and struggle to see the underline on anything other than a white-background, really. With all the other customisations possible in the IDE, not being able to change this particular element is remarkably frustrating - especially because most of the time, the error-insight marker is damn useful!

I've voted up various other answers here that I agree with - I don't know if I have the latest and greatest hacks for the help files, but the help system is very frustrating in D2007 - so much useless boilerplate Microsoft stuff, auto-generated rubbish that doesn't tell you anything of any value. I've bought D2010 but not yet used it in anger so don't know if this is something they've already improved. :-)

Edit: In QC, 61780 ^[1] and also 27135 (related) ^[2]

Let embarcadero look what's cooking in the community and don't reinvent the wheel. If there is something nicely implemented in the community, contact the owner and use it.

Let all of the elements of Delphi be documented. Undocumented elements doesn't exist.

And I'm sorry but please hire a marketing & image company immediately.

Disappearing of the "blue dots" in the code editor after an application is ran under the debugger. Have to compile again to see them again, even when the source is not modified.

This is with D2007 though, maybe it has changed.

One that just bugs me is SysUtils.StringReplace. The last parameter ought to be declared with a default value of [].

My biggest nitpick is the inability for the editor/debugger to sync properly when a file containing non standard CR+LF line delimiters is loaded. Unfortunately, some of the tools used to edit code do not generate the proper line endings. When a file with mismatched line endings is loaded and compiled, the blue instruction marks while debugging do not line up with the proper line of code....this makes setting break points difficult.

The solution is to save the file and reload using something like Notepad+ to convert the non-standard line endings to normal CRLF ones, then reload AND recompile the project. This unfortunately takes more time for something that should be corrected in the IDE.

(this weeks blog entry by Jeff Atwood ^[1] covered this exact issue, or at least the history of why it is one).

^Click browsing of the code usually brings you to the the wrong place (often the end of the file). it was broken in delphi 2005 and even in 2009 (haven't tried 2010).

in delphi 2009, they added a new bug--when it's busy in code completion, it often "eats" keystrokes. when it's busy you better stop typing since it's not listening anyway. mix that with slow code completion, and you have a real recipe for irritation.

one other thing--the TRibbon control is rather frail & hard to work with. i've had corrupted form files and plenty of time trying to figure out how to get the designer to let me edit/add/move something.

refactoring to add/remove parameters tends to destroy the code.

i sure wish the TActionManager showed more than just caption! how about Name, Caption, Icon, Catogory? some sorting ability sure would help too.

An array defined with no defined boundaries but an initializer containing n elements such as

Foo array [] of int = {0, 2, 3, 4};

should compile and default to [0..(n-1)]

And by extension,

Foo array [5..] of int = {0, 2, 3, 4};

should default to [5..8]

Making class completion better in order to change parameters in a method.

Press Ctrl+shift+c and the method will be corrected in the class. (and vice versa if you are in the class, it should be corrected in the implementation.

When debugging, I use the Evaluate/Modify (Ctrl+F7) dialog a lot, and would like to see a simple extension : Actual type evaluation.

Let me explain; Up until now, when evaluating a variable of some class-type, I have to play out this scenario:

After I invoke the dialog with Ctrl+F7, I have to :

• Focus the 'Expression' edit box (either by mouse, or with Alt+E)
• Append ".ClassType" to the variable name
• Press 'Evaluate' (either by mouse, or with Alt+V)
• Focus the 'Result' box (either my mouse, or with Alt+R)
• Select and copy the shown type into the clipboard (either my mouse, or with Ctrl+C)
• Focus the 'Expression' edit box again (you'll know how by now)
• Paste that before the variable (Ctrl+V)
• Put parenthesis around the variable and remove the ".ClassType" part again

Only after these (easily automated) steps, I get to see the actual type in all it's detailed glory. And that with a mere 26 keystrokes! (If I counted them right, I could be off a few) ;-)

You'll understand this has become very tedious, and it would be my #1 improvement to Delphi.

PS: The same functionality should be added to the watches, local variable and object-inspector views too.

Constants are not constant enough for the compiler:

const
   SLCT = 'Large Cash Transaction';

...

const
   SAdd = 'Create a new '+SLCT+' report';
   SEdit = 'Edit a new '+SLCT+' report';
   SDeleteConfirm = 'Are you sure you wish to delete this '+SLCT+'?';

Complains that SLCT isn't a constant expression.

While:

const
    clGlassColor = $00963228;

...

const
    clGlassBorderColor = clGlassColor;

works fine. Some constants are constant enough for the constant constants.

I upgraded to Delphi 2010 in December but really tried it just a week ago.

I haven't done much work in Delphi for years and then only in D7, which had been a crass historical touch regarding the tool set and editors I've grown accustomed to in .Net every time I used it over the recent years.

So, I did have high hopes for 2010, especially since everyone was raving about it.

Well, new project -> intellisense for units not working properly. (Wouldn't provide me with the generics.* unit names or StrUtils, .. )

I thought, well, they must have figured out how to get rid of those unnerving search paths, mustn't they? So, I created a package and an application and then told Delphi, that the exe will require the package (not as runtime pck, just the build thingy) Now, I thought I might just be able to use the units of the package in my exe without having to tinker with either search paths (yuck!) or adding the code files to the exe project as well. I had to use add the search path...

Okay, they added all this RTTI, debug visualizers, etc and I read somewhere how much improvement that gave to the debugging experience... So, simple console app, created a TDictionary<String, SomeSampleClass>, checked out the drill-down hint during debugging and did it provide me with a view of this dictionaries' data? Nope, I did get the fields of it, yes. But nothing useful. No built-in visualizers for anything useful, that I had tried. Phew!

Inspecting components is even more disillusioning. You won't even get the caption from a menuitem without typecasting or fiddeling with it...

Then, I thought: Hey, they integrated a file browser, so they would surely allow me to navigate easily to my project directory or to the file, I had open. Nope, as with almost anything, that I thought would have been the most basic user expectation from feature XYZ, I ended up, being completely disappointed.

Oh, and btw: The Delphi project explorer will still not allow to create folders and drag files around/into it to move/copy them between folders. The project managaer had always been a pet hate of mine in D7, and it didn't get much more useful in 2010 at all.

I just bought Delphi 2010, so that I might get a cheaper upgrade to native x64 or xplat in the future. So I better not use it too often until then, or I might loose interest in even those 2 prospects...

2010 is a big step forward, after all. But only compared to Delphi 7, which felt very old and dated when it was new. Compared to current IDEs like Netbeans and VS, Delphi 2010 feels a bit too cheap and unsophisticated (e.g. It still won't allow complete shortcut customization of all commands, has no highlighting for classes, interfaces, records, ..). However, I always hated the window clutter that D7 created, so this at least got much better.

Phew that was a lot more venting than I originally thought, I would end up doing... o_O

p.s.: I won't even start with "with" or the joys of single-pass compilation that requires force feeding everything in exact the right order, kinda like being a human pre-compiler.

I've mentioned this a few times before, but IMO properties need a little bit of work.

Properties are an abstraction that allows you to write code as if you're addressing public fields while preserving encapsulation. Since properties are supposed to look (from the outside, at least) like fields, there's no reason why you should ever be unable to pass a read/write property to a var parameter.

If read and write both point to the same internal field, it's trivial. Otherwise, read a copy of the value, pass it to the function, then take the result and write it to the property. The compiler should be able to handle this transparently in every case, instead of rejecting it.

One of my biggest nitpicks is the lack of simple Delphi examples in the help file.

Compiler will not emit symbols compatible with WinDbg, ntsd, Visual Studio, etc.

Edit:

The problem being that Windows Error Reporting (WER) and WinQual cannot be used. Also, the crash dumps created with the DbgHelp library generally make no sense without some crutch. This, however, is not limited to Delphi (see here ^[1]). Nevertheless Delpi (and C++ Builder) are commercial tools (as opposed to MinGW or OpenWatcom) and thus I think it would be feasible to license the means from Microsoft.

If you ever had the pleasure of using WinQual, you know the true benefit of using these symbols.

madExcept and friends (for Delphi) are only partially useful. With proper symbols I could even take a memory dump of a running process using a tool like procdump.exe from Sysinternals and then inspect that dump. This is very useful for long-running processes.

If I open a read-only file, and then mark it not read-only, the editor does not know about it. I have to manually right-click and uncheck the "read only in editor" box. Several other editors do this for you, like Notepad++ or Toad for Oracle (which is itself written in Delphi).

Number of elements differs from declaration.

Just tell me how many elements to put in the array!

I want auto-invoked Code Completion to insert whatever I've selected when I type a separator - a dot, a semicolon, whatever. It does this when I invoke it manually with Ctrl-Space, but not with auto-invoke.

It's a small bug that was introduced a few versions back and drives me crazy. Having used Delphi for may years I became accustomed to having my Object Properties list in alphabetical order, as opposed to by groups.

When the IDE Properties Editor is changed to the 'By Name' View and scrolled, it just falls apart. This becomes quite noticeable when selecting controls on a form (when the list has to scroll) and expecting the Properties editor to display the correct object and value.

The properties don't align and focus gets all mixed up, generally requiring multiple click to rectify the situation.

W1035 Return value of function 'xxx' might be undefined.

It isn't undefined (you can put Result:=0 on the very first line of the function and still get this warning). I believe this warning happens if the function has over a certain number of parameters and locals vars. It can be fixed with {$WARN NO_RETVAL OFF}, but still annoying. We're still using Delphi 2007, so hopefully it has been fixed in newer versions.

I would say my biggest nitpick is the inability to follow the open source community. MySQL and PostGRE, which I've been using with c/python/perl/php for years. Regular expressions the same. Support for cvs/subversion/git. libtiff, libpng, libjpeg, libsvg, zlib and so on.

When I've started using Delphi I had no idea what most of the supported database types where. Never heard of them, and probably will never use them. While it's nice to support legacy systems, it is not so nice when you can't connect to the current application database 'cause it is using a too new tech.

Yes one can interface dll:s and so on and make them work. But I want to use them straight out of the box, like one other commented above regarding regular expressions. I want to be able to use what everyone else is using, then their problems would be my problems as well and I would feel that I could contribute, rather than inventing the wheel over and over again.

When a extract method refactoring removes the last local variable in the "original" method, it leaves the Var statement causing a compilation error.

e.g

Procedure TSomething.DoIt;
Var
Begin

SOAP support is not up to par, partucularly with namespaces. SoapUI is the de-facto tool used in many enterprises to test/mock/develop soap services. If your XML request (coming out of Delphi) doesn't work, but output from SoapUI does, guess what? It's your problem. I have recently done a large project that involved dozens of StringReplace calls to modify the serialized object so that I could copy/paste into SoapUI, have it validate, and be accepted by the server. Not cool. If Delphi were able to serialize the XML in the same manner as SoapUI (with declared namespaces at the top, and no in-line namespaces), then that would be a HUGE benefit to anyone doing webservices in a mixed (.net, java, delphi) environment, where the only common reference is SoapUI. I'm venting here because I just got done sharing my code with another guy who has the same issue... http://stackoverflow.com/questions/2473051/delphi-soap-envelope-and-wcf

No auto formatting of code! I do a lot of .NET development and some delphi as well so this is an annoyance to me.

Refactoring -> Find Unit - not really finding it many times.

And to add another one: lack of 64 bit support. I know it high is on the wishlist. But our customers need it ASAP.

The disappearing Syntax Check button.

I put this button on my toolbars and use it a lot. When I close a project, the button disappears. When I open a project, the button fails to reappear. Yes, I can get it back easily enough, by using the Project menu. But I use lots of test projects, I close and open them a lot, and this wretched button drives me up the wall.

I don't think there's been much improvement in the base DataSet components, and they could make some great time-saving improvements with relatively little work, I think.

For instance, why do I have to open up a TStrings editor to check the SQL inside a Query component? Why can't I just move my mouse over it and have it displayed as a hint - along with any defined parameters, while you're at it?

Come to think of it, if I move my mouse over any TDataSet, TDataSetProvider or TDataSource component, why not highlight in some subtle way the other components that are linked to it?

Couple of small things on code completion.

We work with interfaces a lot and it would be good to have code completion in these 2 scenarios:

Adding properties to interfaces

If I write the following code:

IMyInterface = interface(IInterface)
    property MyProp: Integer;
end

It would be good to hit Ctrl+shift+c and the IDE would write the declarations for the getter and setter methods.

Implementing an interface in a class

Similar to VS.net if I say a class implements an interface it would be good to automatically get the IDE to pull in all the methods and properties from the interface in to the class to save my copy and pasting them. (I think you press TAB to do this in VS.net)

Not the biggest, but a pain is the use of the same syntax for Open array parameters and dynamic arrays.

procedure TForm2.FormCreate(Sender: TObject);
var
  a : array of Integer;
begin
  setlength(a, 10);
  test(a);
end;

procedure TForm2.Test(x: array of Integer);
begin
  SetLength(X, 5); // <--- Compiler error
end;

My biggest problem (and this may be related to 5 only, I don't know) is that Delphi has to unload and reload something every time I run my application from the debugger. As soon as I quit the program, I have to wait 5 to 10 seconds for Delphi to do something on disk before I can start in on the code again.

When using the Declare Field recfatoring (Shift-Crtl-D) then the field is added to the top class, not necessarily the correct class.

e.g.

type 
  T1 = Class
    Procedure P1;
  End;

  T2 = Class
    Procedure P1;
  End

Implementation

Procedure T1.P1;
Begin
End;

Procedure T2.P1;
Begin
  **** WHen Declaring a field here it will be placed in the T1 class. ****
End;

Forward declarations.

This is really a rebuttal on the previous post about circular references.

I USED to gripe about it's inability to handle circular references but I've come to realize that they most likely reflect a design deficiency--when you find yourself in an A uses B, B uses A situation the most likely situation is that they should be both siblings under C.

The real problem is a lack of long range forward references. Every beef I've had about a circular reference would be solved if I could declare the interface and implementation in entirely separate units.

It wouldn't break the single-pass nature of the compiler and I don't think it would be that hard to implement. Add a keyword Delayed before Implementation--if the compiler finds it it stops compiling that file and goes on with whatever else it wanted to do. Only once everything else is done does it go back and finish compiling anything that was left behind. The compiler has everything it needs in the interface, it can go on and come back to finish the job.

If I add a public property to a class that has a strict private and public section and press ctrl+shift+c bds 2006 messes up my class. I get an extra private section for the property setter and variable. This often leads to code that no longer compile.

Does anybody know the reason why private isn't really private when it comes to delphi? Why are components on a form visible to other forms? One of the reasons it annoys me is that it clutters the code completion list. If I were to mention the others this quickly becomes a rant.

Where I work we have all projects in one project group, there are about ten of them. Building them all eats a gig of memory and delphi dies a violent death, at least on my machine. Why, I have 4 gigs of memory?

By biggest nitpick about Delphi 2010 is the change to Find in the text editor. I agree that it's a bit nicer and a more modern way of working, but it completely throws me every time. I think its because the OK button on the find dialog isn't in my face, and I have to go looking for the options. It would be great if you could just hit F3 from within the search box, to initiate the find (as that's usually what you press next)

I still think that when there is a new Delphi version, that we shouldn't have to buy new components. If there isn't any major change (like Unicode), components should work from version to version. I know it will be detrimental to the third-party component vendors, but now they'll have to improve the components from time to time, instead of just updating the same old component so that it will work with the new version of Delphi.

It annoys me somewhat that I can't define a floating point value in hexadecimal (hex values are interpreted as integers)

When code insight for parameters pops-up, and you want to place your cursor in the statement above, code insight blocks your sight.

Like this:

Stream.Seek(0, soFromCurrent);
if FileExists( {press control+space here, and then press up}

Sometimes when I undo a change in the code editor (Ctrl+Z), the text in the editor gets corrupted. A lot of strange characters appear, and you simply have to close the file (maybe even the entire RAD Studio) and reopen the last saved version of the file.

The horizontal scrollbar on the Project Manager disappeared in D 2010!

That the incremental search (Ctrl+E) doesn't take numbers from the numpad.

Instead of searching, the numbers gets inserted into the source!
Aaargh!

Code templates

A nice idea in theory but I've about decided to turn them off because they are so stupid in how they work. When you're in the interface section or a class declaration and type Procedure or Function it puts the Begin End in there!

Pressing F7 in the debugger for a Step Into, causing Delphi to go to 100% cpu and after a minute or so ending up in totally unexpected code or an unstoppable sequence of Access Violations, which only can be stopped by resetting the program. Most of the time caused because there is no source file to step into.

This is on Delphi 7, maybe it's fixed in later versions, but it is certainly very annoying.

Edit: Andreas Hausladen fixed this issue with the release of Delphi Speedup 2.8 ^[1]. Also, the Access Violations were caused by DEP (Data excuction prevention). Turning it off will end the Access Violation problem.

1. Remote debugging that works (Like Delphi 7).
2. Ships with a (basic) installer. I might not use it but for its money, Delphi should give you everything you need to create and deploy an Application.

dbExpress Firebird driver not included in Delphi 2010 Professional.

A nitpick, picking on small things:

• Borland
• Imprise
• CodeGear
• Embargadero

Pick a name and stick with it.

Improvement of the Add Unit dialog (ALT-F11), making it possible to type in a unit name, and choose wheter you want it added to the interface or the implementations uses clause.

Delphi as a product has been dead in the water for too long, and there's no indication that this will change any time soon.

For a while, I thought Delphi would be the best programming language for all time. For a brief period of time, in my opinion, it was. Then it lapsed. This is my "nitpick". Management took over, tried to set a new future for Delphi, and not only failed horribly, but it's like they failed with a big negative sign before it.

It all started when the biggest features of the new Delphi versions was all the new and shiny tools they bundled with it, but if you took the time to go and browse the bug-lists, the top 100 bugs, ranked by "how many are actually being affected by this bug", was still there, by and large. Things like intellisense not working, mouse-hover on variables that would go into an endless loop failing to resolve the symbol (and reading other posts here it looks like this problem hasn't been solved even today), crashing IDE, no unicode support in the component libraries (but hey, we got a shiny new data modelling tool instead! COOL!), they all cemented the feeling that they (as in, the owners of Delphi) didn't really care, instead they had about a thousand feature requests and bug reports on their todo lists, and asked the developers "now, what are the things you want to work on?" as in "now, what are the most shiny new things you want to work on, if we disregard the fact that actual people are using our product".

These days, Embarcadero (or whatever company name is currently owning the Delphi license by the time you read this), is playing catch-up. They're adding generics, and other things other platforms are doing, but they're behind. They will always be behind.

If you need to use Delphi because you already have a large code-base, stay with the Delphi version you already have.

If not, go with something else.

My "nitpick" is that Delphi was a great tool. was!

These days, Delphi is like Tony Curtis, the reptile man ^[1], way past its prime, but not exactly seeing the writing on the wall.

In the spirit of the question, let me list the minor annoyances I have with Delphi:

• No backwards compatibility for the .DCU file format. For some versions of Delphi, they changed the version number, and nothing else. This meant that component vendors had to recompile their component libraries for a new version of Delphi for no reason whatsoever except for selling licenses.
• Intellisense not working, simply because the compiler is one part of the product, and all the code that interprets the code for intellisense is another, separate, part of the product. Both have their own bugs, but considering that the compiler is the most important part of the entire product, where do you think most of the bugs are? Correct. Delphi 2007 had major problems with mouse-hovering over variables and procedures and would frequently either use lots of CPU, or just go into the endless clickety-click loop most Delphi-developers have come to lov^h^h^h know. Oh, you're using Delphi 2010? Tell me, is intellisense working correctly? No? Funny that...
• A command line for the compiler that is so long that the tooltip for the output log isn't capable of showing the entire thing. Makes automating the compile step a real treat. Works wonders for everyone that likes continous integration. Or, wait...

Not being able to embed variables in strings and have them expanded. I never knew I was missing this until I learnt php. It would be so much easier than using format.

For those unfamiliar with PHP - this is possible.

$Message = 'Go to the Zoo';

$Full = "I said '$Message'";

echo $Full;

will output

"I said 'Go to the Zoo'

In Delphi (and virtually every other if not every other compiled language) this would require either string concatination (which is a pain) or use of the format function (which is also a pain).

It would be a nice to have.

The new resource-compiler still generates loads of .tmp files when the .rc files are read from a readonly folder.

After a few days of building the various branches I work on, I have to delete 30.000+ .tmp files. That in itself is not a big problem, but the fact that a collision in .tmp filenames causes the build to fail, is!

Mind you, I have about 20 branches of the same codebase on my machine; This codebase consists of 51 projects, build from 1300+ .pas files, good for about 15 MB of code alone. The culprit are the measly 24 .rc files which invoke the resource compiler, which generates not-so-temporary .tmp files, which on their behalf break the build when a .tmp file can't be overwritten. (They seem to inherit the readonly flag from their parent folder).

Well... Pressing Control-Shift-F like it is the salute to god on such a regular basis (not to mention Control-Shift-S like it is a itch that won't stop) I have grown to dislike how after a search, the search results treeview nodes are all collapsed.... and I have yet to figure out how to bring some kind of single key focus to search results view to then keyboard navigate the results.... after keeping your hands on keyboard coding it is a bother to reach for the mouse to hand navigate a treeview....

geeze I must sound like a little *^%3 "ohh I don't want to reach for the mouse" but seriously I am sure it wouldn't take much to get the results to open automatically like how a Astrix * will Open all the TreeNodes in Explorer and the like.....

any suggestions on injecting some code to make the nodes autoopen?

Here is another one I just am encountering... I mean if this is where I should give my public 2bits..

** wicked upgrade #2 **

in the Object Explorer... There are lots of components that have property/value tree's and by default all trees(nodes) are closed.... so on the root(parent) property of the property set/tree there is a little identifier usually in Brackets... eg:

... Font | (TIWFONT)
...

for a hand of god to come down and do a quick property scan and fill in some helper text after the Type definition that is in brackets..... so for in the case of Font it would be a day of celebration to see:

...
Font | (TIWFONT) clblue/10
...
or similar

...
SubTitle | (HTMLString) "FooBarTitle..."
...

or a color identifier that would shade the properties that are "empty/null"

I know it is after Christmas and all..... It would be sweet to get a job developing the compiler so one could do such changes in a moments time. Whoo hooo

The included dbExpress driver does not support milliseconds in InterBase timestamp fields. So all other applications which write these fields in the database have to set the timestamp millisecond part to zero, or else the record will not be found when optimistic locking is used. For details see: dbExpress does not read the milliseconds part of TimeStamp fields ^[1]

After more than 15 years of releases, service packs and bug fixes Delphi's form streaming system still can't reliably resolve data aware components to their data sources if those data sources are located in a separate file. (There are other cases of the streaming system falling all over itself. This is just the most common.)

I've seen this manifest in a couple different ways.

• The editor drops the data sources when the dfm is opened. When the dfm is next saved all the data sources have been stripped from the components.

• Even more frustratingly, the IDE exhibits no noticeable problems at all yet when the form is displayed at runtime none of the data aware controls display any data.

In either case the runtime behavior is the same. Data controls suddenly become zombies staring off into the abyss displaying nothing but empty fields. And it usually doesn't start happening until you invested an enormous amount of time into designing a data module and the forms that rely on it.

Yes there are work arounds for it:

• Always open the datamodule or form hosting the data sources before opening the form hosting the data aware controls

OR

• Assign the data sources using code in the form's constructor, OnCreate or OnShow handlers.

OR

• Avoid external control dependencies by placing data components in the same form as the controls that rely on them.

But lets face it all three of these workarounds should be unnecessary given the length of time this bug has existed (I've seen reports in newsgroups going back to at least Delphi 3)

The inability to put labels (comments) on the DFM file of a data module.

Some additional graphics elements like lines or rectangles would be nice too.

Add shortcut key to the Evaluate/Modify debug command.

Another nitpick:

Why do we still have inadequate handling of file modes?

Why can't we append nonexistent text files? Why can't we reset nonexistent binary files?

Sure, we would need new names to avoid breaking old code but that wouldn't be that hard. Just let me Open any file!

My daily annoyance is the IDE editor's Ctrl+Tab behaviour. It just cycles through the tabs, a real pain if you have multiple files open, and want to toggle between a specific two. You have to manually drag-rearrange the tabs, then use Ctrl+Tab and Ctrl+Shift+Tab. It should be that Ctrl+Tab, Ctrl+Tab toggels between the last two viewed, and Ctrl+Tab+Tab continues the cycle. Have a look at Windows (Alt+Tab), VS, Firefox, etc.

Since it hasn't been mentioned among the rest of these very pertinant issues, I wish the forms editor wasn't so clueless.

There are click browsing bugs aplenty - click on anything in the structure panel while editing a form and it takes a quantum leap to someting miles away in your list. You have to scroll back to what you wanted to click on originally and click it again. Annoying!

Drop a component on your form and it takes a quantum leap into another groupbox or frame or whatever, often hiding behind a bunch of your other components. To fix it you have to go to the structure panel, find your new component, click on it (go to paragraph 1) bang your head, and then put it where you dropped it in the first place.

Try getting components to align in the form editor? Snap to grid doesn't snap, alignment anchors will try to align to something half way across the form instead of the component that is ten pixels away - it's like wrestling a Russian bear. Headhunt some people from Adobe if you have to, Embarcadero, but just make it work intelligently!

It's not so bad if you're doing simple things, but my apps are generally for control systems and I've got frames with dozens upon dozens of components - indicators, buttons, controls, readouts. The amount of time I waste trying to make it look like something other than a kindergarten seashell mosaic or impressionist Picasso is madenning. Typically it means manually typing in origin coordinates for every single component.

It's based on Pascal. :)

Seriously, I went to a Borland conference many years ago where Anders Hjelsburg was demo-ing the new Delphi (2.0) that was about to come out. People loved it, but the Q&A session was almost entirely, "Why didn't you use C?", "Will you be coming out with a C version soon?", etc.