The official way to report bugs and file feature requests is through CodeGear's Quality Central. The ideas presented in this wiki are for discussion purposes. Where applicable, links to QC reports will be provided in the hopes that the community will vote for changes/additions to Delphi.

IDE Extensibility[edit | edit source]

a greater extensibility of the IDE, the possibility to just extend everything from the designer to the compiler, an oo view of the source code, possibility to use a third parts or open source compiler in order to go on new platform (if borland can do it)

Debugger[edit | edit source]

A crazy idea would be to allow the debugger to go *back*, (see the videos : Video 1 and Video 2) one idea on how to implement this is by using an interpreter storing all variable values at each line of code, as well as a history of line execution.

XAML[edit | edit source]

- support xaml format natively, probably accept it as another format for DFM files (Text/Binary/XAML) for both Win32 and .net

Intelligent Uses[edit | edit source]

Units that are not really used in the Uses of a Unit should be automatically removed unless a special {$USE} is present (for dynamic use).

Code Formatter[edit | edit source]

Maybe integrate Jedi's Formatter in Delphi's IDE, needs:

  • Variable Capitalization: All variables will be capitalized as: as first defined, uppercase, lowercase, camelcase
How do you propose to generate camelcase capitalization? I think that's just impossible to automate. --Dummzeuch 09:59, 29 October 2006 (UTC)
One idea is to have a list of words (maybe something similar to GNU's /usr/share/dict/words/), try to find the longest words, and capitalize the first letter. This needs to include words from both British and American English.

Alternatively take the one from GExperts. In contrast to the JCF it can handle partially correct syntax.

Easier i18n, l10n[edit | edit source]

Embed something like multilizer, but faster, and built-in

  • Generate One Multilang EXE (automatic switching, or call a procedure in System to change the language)
  • Generate One Simple EXE, and Language DLLs (automatic switching, or call a procedure in System to change the language)
  • Generate One EXE per language

Version Control[edit | edit source]

Better integration with non-borland SCMs such as subversion, cvs, vss ...etc. It would be more natural and integrated if it was in the file menu:

 Open Project
 Save Project
 Checkout Project 
 Commit Project
 Branch Project
 Merge Project

Classic IDE[edit | edit source]

Option to revert to a real "Classic" Delphi IDE Style, with tabbed component palette and floating windows.

Arguably, the primary reason for the widespread desire for the old tabbed component palette is ignorance of the "CTRL-P,(Start typing part of the desired component name and the component list gets filtered in real-time)" in the new IDE.

Similarly, it is likely that the desire for the old floating windows is because of ignorance or misuse of the "Desktop Configuration/Layout" manager on the tool palette.

While ease-of-use is a subjective criterion, both changes listed above appear to be significantly easier to work with in the newer versions of Delphi.

Component Creation[edit | edit source]

Easier Component Creation, Create a form, put components, => Convert to "Real Component"

For an already working example see the Custom Containers Pack on CodeCentral.

Note also that Frames provides a lot of this (and more) functionality already. However, knowledge of how to use frames in not very widespread.

Form Editor[edit | edit source]

Multi-Level Undo in Form Editor

Object Property Binding[edit | edit source]

Objective: Simplify the creation of a GUI whose controls are required to both update and reflect the property values of another object.

Problem: GUI controls are often required to adjust the properties of a separate object (a model) and to also simultaneously reflect the current state of that model. At present this entails writing GUI code in OnChange events to update the model, and also to have code that can detect any changes in the model and reflect those changes by updating controls in the GUI (without accidentally triggering such control's OnChange event again). For a large number of GUI controls, this can involve a lot of repetitive code writing.

Potential Solution: Implement an object/object property binding system that enables the developer to bind properties of one object to the properties of other objects.

For example, it would be very useful to be able to bind the Position property of a TTrackBar to the Height property of an instance of a TSkyScraper class.

Dragging the trackbar slider at runtime will then update the skyscraper Height property automatically, since the two properties are bound to each other. The reverse is also true: if the skyscraper object loads its state from a file and its Height property changes as a result, then the binding ensures that the Position property of the trackbar slider updates to reflect the new height value. All this without writing any code.

The binding can be made either in the IDE at design time (when both objects are visual and already exist on a form), or at runtime after an object has been created.

Taking this further, a group of controls on a form can be bound to various properties of the TSkyScraper class itself at design-time, even though no instance of TSkyScraper will be created until runtime. Assigning any instance of TSkyScraper to this group at runtime instantly binds the all the controls to the relevent skyscraper properties automatically. You can then have a listbox of skyscrapers assigned to the group, and whichever skyscraper is currently selected in the list will be bound to the GUI controls.

This will make GUI design and implementation so much quicker and easier.

Code Editor[edit | edit source]

I suggest the next delphi's IDE support an auto-correct function like MS Word. For example, when the user typed "ebd;" or "endl", the auto-correct function will change to "end;". Also there should be a undo correction function, make it easy to change it back, so when user is writing their code, they don't need to bother too much about the correct keywords or functions name, they can pay more attention to what they are writing.

A "Force standardized indent" option would be nice too. Where it would correct your current code to fit the standard, not just make new code correctly. Line up matching begin...end's, indent code within begin...end's correctly... etc etc)

automatic resolution of semicolon errors option. if a line is missing a ; either prompt the user "would you like to add one?" instead of just telling them about the problem, offer the obvious solution to it and do it for them if they want.

Integrate Gexperts, Begin-End Highlighting

Todo[edit | edit source]

Better Todo, maybe linked to a function/procedure/method/line#

Source Docs[edit | edit source]

DelphiDoc, a system similar to JavaDoc.

Modular Delphi[edit | edit source]

Easily Split DataModules, Units, ...etc into separate DLLs/Libraries/Assemblies. with a simple directive , this would allow ISVs to simply separate parts of their systems and deploy whatever their customer has purchased.

Glyph Libraries[edit | edit source]

This Would allow a developer to re-use sets of glyphs cross-project

Profiler[edit | edit source]

A Built-in code profiler

Multiple Screen Support in the IDE[edit | edit source]

Delphi's Help[edit | edit source]

Only Show help topics for the current language and platform, When a project is Delphi/Win32, disable the .Net Help and C++/C# ...etc, also a better help engine, probably built with Delphi.... the one with Delphi 2006 is too slow. Maybe Lucene and HTML? how about a wiki (only when you're online, and the user must be able to disable it, see , for inspiration)

Help[edit | edit source]

Integrating a help building system in Delphi would be nice, targeting, WinHelp, CHM, HTML, and printed docs.

So you could have a Help Project in your Project Group.

Portable Environment[edit | edit source]


1. Make it easy for a developer to take their Delphi environment with them on the road, so that they can work on their projects from any location and on any computer with Delphi installed. This would also enable a single environment to be shared across a number of developers systems making it easy for multiple developers to work on a single project with a standardised set of installed components.

2. Make it easy to open, modify and compile past projects - even if the developer's environment has changed significantly since the project was last opened.


1. A developer's Delphi environment is built up gradually over time - preferences are tweaked, desktop layouts created and custom/3rd party controls are installed to meet the needs of projects the developer is working on. If a project is then taken to a different computer, it usually will not compile, because required components are no longer present.

2. It is difficult to resurrect past projects to make minor alterations. Over time the developer's environment changes, custom/3rd party components are upgraded or replaced, and as a result old projects can no longer open or compile successfully.

Potential Solution:

Create a portable environment that the developer save and can take with them together with their project. The portable environment can include settings, layouts and all installed components that are not part of the default Delphi install. All the developer needs to do is start Delphi on any computer and point it to their portable environment before opening their project.

The ability to save a portable environment enables completed projects to be archived with the exact environment in which they were originally built. This means that at any future date a developer can open, edit and compile any past project in its original environment with the same version of custom/3rd party controls available.

Other thoughts: Delphi on a USB stick? Environment syncing?

Community content is available under CC-BY-SA unless otherwise noted.