Brandon Staggs 231 Posted February 23 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. Share this post Link to post
dummzeuch 1456 Posted February 23 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. Share this post Link to post
Brandon Staggs 231 Posted February 23 (edited) 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 Share this post Link to post
Brandon Staggs 231 Posted February 23 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 Share this post Link to post
shineworld 73 Posted February 23 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. Share this post Link to post
dummzeuch 1456 Posted February 23 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. Share this post Link to post
Uwe Raabe 1979 Posted February 23 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. Share this post Link to post
Edwin Yip 154 Posted February 24 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! Share this post Link to post
Edwin Yip 154 Posted February 24 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! Share this post Link to post
shineworld 73 Posted February 24 (edited) For me: arm64 compiler for Linux a better refractory tool (often fails also with 100% compilable project) that can work also at a project group level. grep as like as available in GExperts sort lines as like as available in GExpers set version info (to fastly manage version info in a group of projects) as like as in DDevExtension an Embarcadero-managed OpenGL / Vulkan library, like GLScene, for VCL. a more simple way to create ActiveX (to migrate Delphi-made visual components to other platforms). Edited February 24 by shineworld Share this post Link to post
Lars Fosdal 1765 Posted February 24 @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 Share this post Link to post
dummzeuch 1456 Posted February 24 (edited) 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 Share this post Link to post
Gord P 7 Posted February 24 (edited) 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 Share this post Link to post
Lars Fosdal 1765 Posted February 24 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? Share this post Link to post
Gord P 7 Posted February 24 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. Share this post Link to post
shineworld 73 Posted February 24 (edited) 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 Share this post Link to post
Lars Fosdal 1765 Posted February 24 Valid points. I too wish FMX was on a better maturity level. 1 Share this post Link to post
Anders Melander 1705 Posted February 24 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.... 5 Share this post Link to post
Lars Fosdal 1765 Posted February 24 We all know maturity is not related to age 😏 I am living proof of that. 😜 1 Share this post Link to post
Darian Miller 353 Posted February 24 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 1 Share this post Link to post
emileverh 21 Posted February 25 forward declaration of records, just like a class Share this post Link to post
Vandrovnik 204 Posted February 25 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. 4 Share this post Link to post
emileverh 21 Posted February 25 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. Share this post Link to post
Uwe Raabe 1979 Posted February 25 There is a reason why that is not supported: type TRecA = record; TRecB = record FieldA: TRecA; end; TRecA = record FieldB: TRecB; end; 1 Share this post Link to post
emileverh 21 Posted February 25 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.... Share this post Link to post