What new features would you like to see in Delphi 13?

[Stefan Glienke 2030]

You are comparing Win32/Debug with Win64/Release *cough*

[shineworld 79]

4 hours ago, Lars Fosdal said:

@shineworld That is bigger than "fairly large", I'd say. 

May I ask how much of the code is generated vs hand-crafted?

I use a lot of third-party libraries and exclusively from source so the compiled code grows a lot. I may not have understood what is meant by “code is generated” but it is almost all hand-made code. This also includes compilers of various languages used by the system, for which, yes some of it is auto-generated (I use Gold Parser), but a few thousand lines. The program also different script languages, server types, and there the code grows. Empirically maybe I wrote 40% by hand, the rest is libraries, data, and different versions of UI.

 

Edited January 13 by shineworld

[Charlie Heaps 2]

I'd love to see:
 

1. VCL Compiler for Windows ARM.

2. Improvements to high DPI and styles. Getting font sizing to work properly is still difficult and standard windows dialogs (e.g. TAdvDialog) do not adopt the app's current style.  (There is an open source component set called  "VCL Styles Utils" that attempts to patch these dialogs but it does not work reliably - at least for me).  Would hope Embarcadero might adopt this and make it more reliable.

3. A consistent, well-designed, and reliable context-sensitive help system: and help/encourage 3rd party component developers to adopt it. 

 

 

 

[Brandon Staggs 332]

12 hours ago, Charlie Heaps said:

2. Improvements to high DPI and styles. Getting font sizing to work properly is still difficult and standard windows dialogs (e.g. TAdvDialog) do not adopt the app's current style.  (There is an open source component set called  "VCL Styles Utils" that attempts to patch these dialogs but it does not work reliably - at least for me).  Would hope Embarcadero might adopt this and make it more reliable.

The irony for me is that I have been so frustrated with the inadequacies of VCL multi-monitor-DPI support than I have long since solved all of the issues myself, and every time Embarcadero tries to improve their support, they break my fixes. So, maybe a bit selfishly, I hope they stop messing with it! Just kidding, this is definitely an area they still need to improve. 

[EugeneK 20]

I think first priority should be Windows on ARM support

[Darian Miller 367]

On 1/16/2025 at 12:21 PM, Brandon Staggs said:

The irony for me is that I have been so frustrated with the inadequacies of VCL multi-monitor-DPI support than I have long since solved all of the issues myself, and every time Embarcadero tries to improve their support, they break my fixes.

Hopefully your fix count going down over time.  What's your feeling there...is it getting slowly better?  Have you published your latest fixes anywhere?

[Brandon Staggs 332]

21 hours ago, Darian Miller said:

Hopefully your fix count going down over time.  What's your feeling there...is it getting slowly better?  Have you published your latest fixes anywhere?

Some of my stuff is in the QA portal (menu fixes I think) and I still have to use it despite the reports being marked "fixed." But most of my workarounds are done on-the-fly with my own inherited form and frame classes and would be too much bother for me to pull out to show anybody. I guess if I were to share a "feel" for how it's going, I'd say it's getting better. I think Embarcadero should force their developers to use their own IDE in a mixed-DPI environment in various configurations and not stop fixing scaling issues until they can do everything seamlessly. Who knows, maybe they already have, and they just aren't exposing the problems I run into.

[dummzeuch 1553]

1 hour ago, Brandon Staggs said:

I think Embarcadero should force their developers to use their own IDE in a mixed-DPI environment in various configurations and not stop fixing scaling issues until they can do everything seamlessly.

Hear hear! 

1 hour ago, Brandon Staggs said:

Who knows, maybe they already have

I doubt that very much.

[johnnydp 25]

Possibility to align caption text on buttons and other controls (easy way)

[jesu 0]

-Make updates less painful. At least save a list of GetIt components installed and reinstall them automatically in next version.
-Add animations to VCL
-And/or add an option to FMX to create Windows-only applications that allow to use native Windows controls like TToolBars and alike
-Find a way to do the same that anonymous methods can do but without the same problems for readability.

And sponsoring updating third party controls like JVCL and others to be in line with current UI could be an incentive for some people to upgrade.

Edited February 13 by jesu

[TigerLilly 18]

- Allow configuration of all Short-Cuts (including 3rd party)

- PreProzessor

- enhanced source code navigation, eg "live" window with references

- AI integration for search in Delphi docs and references

- AI integration like Google NoteBookLM for internal docs and internal source code

[dummzeuch 1553]

24 minutes ago, TigerLilly said:

- enhanced source code navigation, eg "live" window with references

I guess that comes from some other tool that does it. Since I haven't really an idea what it means, could you please elaborate? Or maybe point to a video that shows how it works in this other tool?

[HeartWare 3]

On 2/19/2024 at 3:43 PM, Lars Fosdal said:

Not per se. However, the problem is that once you use the DPI aware IDE, the measurements and coordinates in forms are according to your current Windows DPI and scaling settings. Which means that when someone with a different DPI or scaling opens the form, it looks like shit and the changes that someone makes, will again be impacted by their settings. So if two people with two different settings, takes turn in changing a form, you can get a form that keeps on growing or shrinking during the design.

 

Personally, I would prefer that such a thing doesn't happen - so that I can benefit from HighDPI also in the IDE.

 

It is not a trivial problem to solve. Pixel perfection becomes very hard once you have to deal with design time as well as runtime scaling.

They should do what we did in our designer. Always work internally (and store) values for 96dpi (100%) in the designer, only scaling it up for display. The issue comes if you scale from (f.ex.) 150% to 200% and then back to 100%. But you can always scale correctly if you go via 100%, ie. to go from 150% to 200%, you go 150% -> 100% -> 200%, then you can always get back to 100%.

That is my wish - An IDE designer mode that works in 100% (96dpi) but scales the visual designer to the monitor's DPI (yes, that will affect your pixel-perfect alignment in 150% during design, but it will be pixel-perfect in whatever scale the final monitor is at, since everything can always be consistently scaled UP from 100% to any DPI). And if your .DFM is stored in 100% values and you start the program on a 150% monitor and then move it to a 200%, it will be scaled back to 100% before being scaled up to 200%.

[HeartWare 3]

On 2/23/2024 at 12:38 PM, Cristian Peța said:

Yes, but imagine someone with 200% display scale with a magnifying glass trying to adjust something on a form because the form is half the size.

Which is why I suggest a mode that works internally in 96dpi but shows (and allows edit) in the monitor's native DPI. Yes, it will mean that you are restricted to placing components on a 2x2 grid if your monitor is at 200% and the grid will be unsymmetrical if you're at 150%, but since all components will be locked into the same grid, you can still align the positions and sizes.

[Uwe Raabe 2090]

1 hour ago, HeartWare said:

Always work internally (and store) values for 96dpi (100%) in the designer, only scaling it up for display.

Yes, upscaling and downscaling by the same factor keeps all values intact (I provided a mathematical proof for that), but downscaling and upscaling does not. That was the main reason for my feature request: RSP-35301 - Option to design in Screen PPI but save in 96 PPI

[Rollo62 548]

What features are most wanted:

Under all platforms (Win32, Win64, Macos, iOS, Android, Linux, ...) I would wish to have

- A debug experience, that is reliable and shows and behaves consistently under all platforms

- A rock solid debugging function, with at least breakpoint, step-over, step-into ... likely the full feature set

- A rock solid and consistent debug inspection view, with ability to show on mouseover or inspect, for all structures in the same way

- A debug inspection view, that is able to decode all sub-structures of classes or records correctly and is fast and easy to access its underlaying members

- A debug inspection view, that defaults to human readable data representation first, while there were options to watch single variables in many views.

- A debug inspection view or watch, that can reliably switched between decimal or hex view at least (and even more integer/hex/string/byte array,pointer,... )
- A debug inspection view or watch, maybe on the breakpoint level, that can define the preferred view representation of the current session permanently, for all different views (hoover, inspect, watch,...)

 

The Win32 behaviour is more or less the best reference so far, while other platforms are still not there.

 

[HeartWare 3]

1 hour ago, Uwe Raabe said:

Yes, upscaling and downscaling by the same factor keeps all values intact (I provided a mathematical proof for that), but downscaling and upscaling does not. That was the main reason for my feature request: RSP-35301 - Option to design in Screen PPI but save in 96 PPI

Ooooh - someone else had the same idea 🙂 

[David Heffernan 2377]

8 hours ago, Uwe Raabe said:

Yes, upscaling and downscaling by the same factor keeps all values intact (I provided a mathematical proof for that), but downscaling and upscaling does not. That was the main reason for my feature request: RSP-35301 - Option to design in Screen PPI but save in 96 PPI

I guess problems still arise when forms move back and forth at runtime. Because then you can't avoid down scale and then up scale. 

[dummzeuch 1553]

25 minutes ago, David Heffernan said:

I guess problems still arise when forms move back and forth at runtime. Because then you can't avoid down scale and then up scale. 

But you can: Simply store the size of the unscaled form and its components and calculate the new scaling based on that.

[Uwe Raabe 2090]

56 minutes ago, David Heffernan said:

I guess problems still arise when forms move back and forth at runtime. Because then you can't avoid down scale and then up scale. 

It depends on the way you do the scaling. If the form is created and loaded with 96dpi and you scale up there is non loss. When it comes to another scaling, you need to downscale to 96 dpi first and then upscale to the required scaling. This assures that the positions and sizes for each scale are consistent.

[TigerLilly 18]

23 hours ago, dummzeuch said:

I guess that comes from some other tool that does it. Since I haven't really an idea what it means, could you please elaborate? Or maybe point to a video that shows how it works in this other tool?

No, no tool I know of. But I often wanted, when editing, to have a window where - without any interaction from my side - in formation about the context I am in, is shown. Some of this is already avail, but cluttered around:

- current method/class

- type definition

- qs metrics (already initalized, created, defined, ..., code metrics)

- hints (remember to free, ...)

- references inside, outside

 

One more thing, I valued much, long ago (MicroFocus Cobol Debugger :- ) The ability to restrict the level of step into when using F7.

[JonRobertson 76]

5 hours ago, TigerLilly said:

The ability to restrict the level of step into when using F7.

Although not quite the same, the Selective Debugging expert allows you to select units that you don't want to step into. It can be helpful to avoid stepping into low level routines such as string conversions.

[A.M. Hoornweg 147]

I want "F2084 Internal Error L902" gone !!!