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

[Brandon Staggs 278]

5 hours ago, 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.

I don't know why I was thinking it just let Windows scale the output (ie, the window is treated as DPI unaware). Obviously I agree that editing the form that way is very suboptimal.

[dummzeuch 1505]

2 minutes ago, Brandon Staggs said:

I don't know why I was thinking it just let Windows scale the output (ie, the window is treated as DPI unaware). Obviously I agree that editing the form that way is very suboptimal.

As far as I know you cannot set a single window to DPI unaware and have the rest of the program be DPI aware. I tried that with GExperts because I didn't want the hassle of making all Windows scale correctly (especially because that was buggy as h**l with Delphi 11.0). I failed miserably. But maybe that's just me.

[Brandon Staggs 278]

9 minutes ago, dummzeuch said:

As far as I know you cannot set a single window to DPI unaware and have the rest of the program be DPI aware.

That is not correct. DPIv2 allows exactly that, and that is when Embarcadero added this option, and I vaguely recall testing it to satisfaction on my Surface Laptop. I have not returned to that to look at it since, though, as I don't do any real dev work there.

 

https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows?redirectedfrom=MSDN#mixed-mode-dpi-scaling-sub-process-dpi-scaling

 

https://learn.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser-setthreaddpiawarenesscontext

 

It is entirely possible that Delphi does not do it this way and I am mistaken. I can't really remember. I think I might check, out of curiosity.

Edited February 23 by Brandon Staggs

[Brandon Staggs 278]

7 minutes ago, Brandon Staggs said:

It is entirely possible that Delphi does not do it this way and I am mistaken. I can't really remember. I think I might check, out of curiosity.

Well, turns out this works exactly as @dummzeuch presumed it would. Which actually makes sense, I suppose. I doubt the IDE refactoring that they would have to do to support sub-process DPI awareness in the form editor is something they would want to tackle. That's too bad. Still, it offers some form of mitigation of DPI scaling dfm disasters if you can put up with the drawbacks during editing

[shineworld 73]

When you have collected all the ideas, it would be interesting to add a pool where everyone gives one or more preferences. Just to understand what is really needed.

[dummzeuch 1505]

1 hour ago, Brandon Staggs said:

That is not correct. DPIv2 allows exactly that, and that is when Embarcadero added this option, and I vaguely recall testing it to satisfaction on my Surface Laptop. I have not returned to that to look at it since, though, as I don't do any real dev work there.

 

https://learn.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows?redirectedfrom=MSDN#mixed-mode-dpi-scaling-sub-process-dpi-scaling

 

https://learn.microsoft.com/en-us/windows/desktop/api/Winuser/nf-winuser-setthreaddpiawarenesscontext

 

It is entirely possible that Delphi does not do it this way and I am mistaken. I can't really remember. I think I might check, out of curiosity.

SetThreadDpiAwarenessContext is exactly the API call I tried to use back then. I couldn't get it to work. Mostly probably because as an IDE plugin GExperts does not have any control over the API calls in other parts of the IDE. I spent several weekends trying to get this to work and then I gave up.

[Uwe Raabe 2057]

SetThreadDpiAwarenessContext has to be wrapped around the creation of a top level window handle to work correctly. All child windows then inherit the context of the top level one. This rules out any docked forms or frames, which explains why it is not feasible for the Embedded Designer. (Fun fact: an undocked designer window would have worked with that.)

 

A solution for this problem could be SetThreadDpiHostingBehavior and AFAIK that is something Embarcadero is investigating in.

[Edwin Yip 154]

On 2/23/2024 at 1:07 AM, Oleksandr Skliar said:

Both, the most time it's D11.3 and D12 for pet projects. I just can say D12 works worse than D11.3, sync methods literally doesn't work. In case you use generics a lot, LSP stops working. So my another wish - to support third-party LSP servers for Delphi code.

I'm so disappointed to hear that!

[Edwin Yip 154]

On 2/23/2024 at 1:07 AM, Oleksandr Skliar said:

Both, the most time it's D11.3 and D12 for pet projects. I just can say D12 works worse than D11.3, sync methods literally doesn't work. In case you use generics a lot, LSP stops working. So my another wish - to support third-party LSP servers for Delphi code.

I'm so disappointed to hear that!

[shineworld 73]

For me:

1. arm64 compiler for Linux
2. a better refractory tool (often fails also with 100% compilable project) that can work also at a project group level.
3. grep as like as available in GExperts
4. sort lines as like as available in GExpers
5. set version info (to fastly manage version info in a group of projects) as like as in DDevExtension
6. an Embarcadero-managed OpenGL / Vulkan library, like GLScene, for VCL.
7. a more simple way to create ActiveX (to migrate Delphi-made visual components to other platforms).

 

Edited February 24 by shineworld

[Lars Fosdal 1792]

@shineworld

2. I assume you meant "refactoring", not "refractory"?

3/4. Why not simply use GExperts?

5. Why not use a tool like Continua CI for setting version for multiple projects at once? Added bonus - compile, package, distribute automatically on commit to git.

6. FMX already has that covered?

7. ActiveX doesn't work well on other platforms than Windows

[dummzeuch 1505]

7 hours ago, Lars Fosdal said:

3/4. Why not simply use GExperts?

Simle answer: Because GExperts has fallen behind in quality and update frequency since it has become a one man show (me).

There is only an Alpha release availabled for Delphi 12 and that one contains many bugs. Some of these bugs have been fixed, but in order to get these fixes, you need get the sources and compile your own dll.

 

Edit: I just took this as an opportunity to release a new Beta version for Delphi 12. But I'm still trying to catch up with High DPI.

Edited February 24 by dummzeuch

[Gord P 14]

8 hours ago, shineworld said:

6. an Embarcadero-managed OpenGL / Vulkan library, like GLScene, for VCL.

7 hours ago, Lars Fosdal said:

6. FMX already has that covered?

He specified for VCL.  And I second that.

(although I recognize posting wishes here is next to useless - but it is interesting to see what people are looking for).  

Edited February 24 by Gord P

[Lars Fosdal 1792]

3 minutes ago, Gord P said:

8 hours ago, shineworld said:

6. an Embarcadero-managed OpenGL / Vulkan library, like GLScene, for VCL.

7 hours ago, Lars Fosdal said:

6. FMX already has that covered?

He specified for VCL.

Why would you try to shoehorn 3D graphics into a 2D framework?

[Gord P 14]

5 minutes ago, Lars Fosdal said:

Why would you try to shoehorn 3D graphics into a 2D framework?

It is obviously doable - eg. GLScene that Shineworld previously quoted.  (Then you might ask why not use that -  but that has its own issues, which is why I think Shineworld specified "Embarcadero managed ... (Sorry if I am putting words in your mouth)).

 

Also, The pro version of TChart handles 3D fine.  Personally I am looking for 3D chart capabilities but at this point don't want to shell out dollars for a yearly subscription for the pro version.

 

 

[shineworld 73]

1. Sorry for mistakes in post, I never studied English.

2. I use GExpert, and I've to thank the project manager, but I would like to have a better grep in the native IDE. 

3. Usually mine are very big project subdivided in many customized versions managed as project group with shared sources. To manage manually the versions info for single project is an hard work which requires jumps as like as a monkey in the three. DDExpert does something to simplify.

4. OpenGL and 2D mix is not so unusual in industry automation related projects, where Delphi, at least in Italy, is yet used also by big firms. I k know FMX, but it's not a level of VCL for many reasons, at least in my cases.

 

Some samples on how VCL + OpenGL can live and be happy:

https://youtu.be/3IC15XM_8ow?si=RLuDHZmpU9PgdFj7

 

And as VCL + OpenGL + Python are a good team:

https://youtu.be/ehyZanI54c8?si=dCV6nZd3kbLHa2K4

Edited February 24 by shineworld

[Lars Fosdal 1792]

Valid points. I too wish FMX was on a better maturity level.

[Anders Melander 1783]

1 hour ago, Lars Fosdal said:

I too wish FMX was on a better maturity level.

I think you'll have to wait a bit; It's only just entered puberty. 13 years old....

[Lars Fosdal 1792]

We all know maturity is not related to age 😏

I am living proof of that. 😜

[Darian Miller 361]

My top 3 'wish' list items:

- MCCGA.  Make ctrl-click great again (and actually work.)

- A code formatter that handles all language features.  AND don't add another language feature that isn't accompanied with an update to the code formatter to support it.  

- Refactoring tools that handles all language features.  AND don't add another language feature that isn't accompanied with an update to the refactoring tools to support it.  

 

You have to be able to navigate code and I have wasted too many hours of life with a ctrl-click that does nothing. 

You shouldn't have to spend precious brain cycles on code formatting tasks. 

If refactoring doesn't work - the IDE doesn't work.

 

Others:

- Much more focus on debuggers

- Quality, quality, quality

- Keep current with platform support

 

[emileverh 21]

forward declaration of records, just like a class

[Vandrovnik 214]

3 hours ago, emileverh said:

forward declaration of records, just like a class

In forward declaration of a class, compiler immediatelly knows the size of that type. For records, their size would be unknown in forward declaration.

[emileverh 21]

53 minutes ago, Vandrovnik said:

In forward declaration of a class, compiler immediatelly knows the size of that type. For records, their size would be unknown in forward declaration.

That can be true, but that is 'not my problem' how to solve it. I use records a lot for several reasons (speed, memory management,....). And it would be VERY nice to have that.  

[Uwe Raabe 2057]

There is a reason why that is not supported:

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;

 

[emileverh 21]

49 minutes ago, Uwe Raabe said:

There is a reason why that is not supported:

type
  TRecA = record;
  TRecB = record
    FieldA: TRecA;
  end;
  TRecA = record
    FieldB: TRecB;
  end;

 

I know it's a compiler problem, but why can they do it with classes and not with records....