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.
Renew the VCL[edit | edit source]
- a renew of the optimal but old VCL, but more an abstraction layer for portability on other platforms, windows native made from borland and from third parts or open source on other platforms (if borland can do it) - diminish the technological gap between vcl and dot net framework that with version 2 it begins to become enormous like generics, heavy use of interface, ...;
It is unclear exactly what the technological gap is, if it even exists. For instance, one might argue that there is a huge technological gap between lisp (50 years old) and .NET (presumably C#?) because lisp allows inline code syntax redefinition, or between python and .NET because of syntactical language features like list comprehensions. One might even argue that .NET (presumably C#) needs to catch up with Delphi regarding code execution speed (certainly initialisation speed). Let not .NET be the guiding light for VCL renewal (which is needed); rather, let's aim for better.
Maybe TTimer should also have its own thread.
ECO for Win32/Win64/Linux[edit | edit source]
Interfaces[edit | edit source]
The VCL should make more use of interfaces... maybe even the DataSet should be changed to be an interface.
the use of *is* could also check if a class has a specific interface:
for i in Form.Components do if (i is iDataSet) and (i.Active=false) then i.Open;
we could have a huge list of generic interfaces that could be implemented by multiple components:
Themes[edit | edit source]
full XP/Vista Theming, not just a manifest that messes-up your panels
Scaling[edit | edit source]
Better ImageLists[edit | edit source]
32-bit PNG support in TImageList/TImage. Many current third party components support this but it should be supported natively in Delphi.
MutiCast Events[edit | edit source]
Allow events to fire multiple methods, which can be disabled at runtime/designtime.
p:=DataSet1.OnAfterUpdate; DataSet1.OnAfterUpdate:=nil; //Do Something Here DataSet1.OnAfterUpdate:=p;
for p in DataSet1.OnAfterUpdate do p.Enabled:=false; //this disables all events here //Do Something Here for p in DataSet1.OnAfterUpdate do p.Enabled:=true; //this disables all events here
Databases[edit | edit source]
- Allow a dataset to work when the structure changed slightly... I hate it when the whole EXE is useless because that varchar(100) became a varchar(200) or Text or clob, we would need an error when compiling this project to avoid an impression that all's well.
- Better cross-database support.
- Easier runtime data export/import for any database.
- Integration between Embarcadero's Database tools and Delphi.
- A transformation layer between .NET's ADO.NET DataSets and the VCL ClientDataSet.
Accessibility[edit | edit source]
Unicode VCL[edit | edit source]
New DBGrid[edit | edit source]
A newer DBGrid that looks good, and has optional:
- Owner-Draw cells (with the possibility of having different heights).
Assert[edit | edit source]
assert is available in Delphi, isn't it?
ClientDataSet[edit | edit source]
Improvements on ClientDataSets.
Document the binary format of the Client Data Set otherwise it is not usable from any other programing language.
TCanvas Enhancements[edit | edit source]
Objective: Make it easy to draw state of the art vector and bitmap graphics on any visual control supporting TCanvas.
Problem: The graphics capabilities provided by TCanvas, TImage, TImageList etc. would benefit from updating to enable display and manipulation of graphics to a quality expected by users of modern applications. In particular support for high-quality resampling and alpha channel based opacity would be of great benefit.
Potential Solution: Update TCanvas to provide high performance graphics capabilities that are easy to make use of. Capabilities could include fast anti-aliased vector drawing with opacity, gradient and bitmap fills, shadows. Maybe even make this object based, so vector objects can be moved around the canvas and edited. Bitmaps with alpha channels, bicubic bitmap resizing/resampling. Transforms such as rotate and skew. Filters such as blur, bevel, grayscale. TImage with layers?
Thoughts: Maybe look at Quartz on OS X for inspiration. If TCanvas could make use of DirectX, and have even standard Windows controls drawn to this updated TCanvas, then performance could be really good. Might even open the possibility for GUI skinning.
TIcon Enhancements[edit | edit source]
Objective: Make it possible to use modern icons in Delphi projects when designing the application GUI.
Problem: Modern icon files can contain icons in 24-bit colour with an 8-bit alpha channel. It would be great if Delphi could support such icons in its visual controls, especially alpha transparency, enabling developers to create applications with a more polished professional appearance. It is difficult to have icon images appear with smooth anti-aliased edges when only single-colour (chromakey) transparency is supported. Other example: Delphi application icon don't support 256x256 icons.
Potential Solution: Update TIcon to support the full range of icon types used on the Windows platform today, including 24-bit PNG with 8-bit Alpha. Other visual controls such as TBitButton, TSpeedButton, TToolButton and TTreeView - in fact any control that displays icon images - might need updating to reflect this. TIcon would also support saving multiple icons to a .ico file (or alternatively a TIconLibrary class, similar to a TImageList, could support this functionality).
TTreeList[edit | edit source]
Objective: A non-visual class that makes it easy to create and maintain a hierarchy/tree of other objects.
Details: Similar to a TObjectList, but with a Children property (in addition to Owner and Parent) where new branches can be added. The class also has methods to iterate through itself and any children streaming data out to XML, and loading that data back in again from a stream of XML. Loading the data back into an empty TTreeList will recreate the original tree of objects. The streaming format could be plugable, provided by another class, enabling other formats besides XML to be supported. There would need to be a mechanism for each object in the tree to indicate what data it should stream (i.e. what data the object wants to persist or save/load in addition to its class name).