Leaderboard

@bravesofts Maybe you would have better chances of convincing people if you would write your own thoughts instead of letting AI write them for you Delphi already has VCL and FMX frameworks. Feature wise it makes very little sense for Embarcadero to introduce yet another visual framework. Wrapping WinUI can be done through 3rd party, it doesn't have to be supported by Embarcadero. I would prefer that they focus on things that cannot be provided by 3rd party, like: compiler, debugger, language features, IDE functionality....

Not quite. See for instance Ohh...WinUI3 is really dead! - When can we expect the announcement? · microsoft/microsoft-ui-xaml · Discussion #9417 The Microsoft strategy for GUI App development is utterly messed up: WinForms WPF Xamarin Forms UWP WinUI3 MAUI And there is no longer a GUI designer. You have to develop XAML in a text editor. Discussion: WinUI 3.0 XAML Designer · Issue #5917 · microsoft/microsoft-ui-xaml

Have you considered joining Embarcadero's marketing team?

Tried to create a SIMD (AVX2 based) Quicksort: https://github.com/mikerabat/SimdQSort For anyone who is interested... It supports Int32, Int64, Single and Double Array sorting - no custom struct size nor user defined compare procs. Speedup for large random arrays is up to 3.5 🙂

Joel Spolsky has written about this some 23 years ago in his famous "Fire and Motion" article. In short, Microsoft "invents" new technology, and while devs try to adapt to that, Microsoft just drops that for a "newer, better" technology. And so on, and so on.

NexusDB components are now available in the new 64 bit IDE 👍 v4.7514 adds - 64 bit Designtime Support - Replication (Beta) Find the best Delphi Database at NexusDB

@bravesofts Place a feature request at EMBT's JIRA. Nothing is decided on this board.

Embarcadero has been having too many coals in the fire for years now. Instead of opening the next can of worms, they should be fixing basics like code completion. I remember being in the Microsoft Technology Adoption Program where you got Teams meetings with the developers behind WinUI and other Windows components, got shown not yet released roadmaps and got to ask questions. Back then, it was basically impossible to properly use WinUI outside of Microsoft's Visual Studio (not sure if it was WinUI2 or 3). At that time, they openly replied to me that they had no plans to change that. Except WebView2 has been usable for basically everybody from everywhere, and it's actually good. You can see it being used in a lot of software, not just Microsoft's own products. Just look at how much stuff Microsoft has abandoned in the last couple of years, how much of the "Universal Windows" approach has been dialled down or completely removed already. Not to mention that new GUI stuff has been highly dependant on the most current Windows version. WebView2 even works in Windows 7. I honestly was interested in WinUI around 2018 to 2020 or so, but it certainly never took off. I firmly believe it is not relevant anymore.

The above posts make a perfect case for why Ctrl+B should be used sparingly.

Indeed there are: Set TControl.RaiseOnNonMainThreadUsage := True This will raise an EInvalidOperation when CheckNonMainThreadUsage is called for a control. This is automatically done inside CreateWnd.

Can I participate with a program written 25 years ago? https://github.com/MarcoDelphiBooks/MasteringDelphi5/tree/master/WebBonus/22/MINES

Use it 😃 for FMX https://github.com/HemulGM/DelphiWinUI3

That's why they pay us the big bucks 🙂 Here's some links that might be relevant: https://learn.microsoft.com/en-us/office/troubleshoot/access/cannot-use-odbc-or-oledb https://how-to.aimms.com/Articles/129/129-MSACCESS-32bit-64bit.html

🔍 Will GUI-Based Development Go Extinct? 🤔 Some argue that GUI-based development is fading away in favor of code-centric or terminal-driven development. However, the reality is quite different: GUI development is evolving, not disappearing. 🧐 Why GUI-Based Development Won't Disappear? 1️⃣👨‍💻 Humans Prefer Productivity and Speed People naturally gravitate towards tools that enhance efficiency and reduce complexity. Development environments like Delphi and RAD Studio provide rapid application development, a demand that won't fade away anytime soon. Even with AI-powered coding assistants, GUI tools remain a time-saving necessity in many domains. Most developers prefer being productive rather than just looking like hackers typing endlessly in a green-on-black terminal. Writing code should be about building real solutions efficiently, not about proving how much you can type without a mouse! 2️⃣ 🚀 AI Is Enhancing GUI-Based Development, Not Replacing It AI-powered tools like GitHub Copilot, JetBrains AI, and AI-driven refactoring are deeply integrated into GUI-based IDEs. Delphi, C#/.NET, and Python IDEs now leverage AI to accelerate development, proving that GUI-based environments remain essential. 3️⃣ 🏢 Businesses Need Ready-to-Use Tools, Not Just Code In the real world, businesses prioritize rapid, efficient software development. Companies aren’t interested in reinventing the wheel—hence, RAD (Rapid Application Development) environments remain highly relevant. Delphi, C#/.NET, and even Java-based UI frameworks continue to play a critical role in enterprise solutions. 4️⃣ 🛠️ Clean Code and GUI Development Are Not Mutually Exclusive Some mistakenly believe that GUI development leads to messy, unstructured code, which is far from true. Modern Delphi supports clean architecture, OOP principles, design patterns (MVVM, MVP, SOLID), and well-structured projects. Many Delphi projects today adhere to clean coding practices just as rigorously as C# or Java applications. ----------- 🔹 The False Comparison Between Delphi and VB ✅ Delphi is NOT just another "Visual Basic"—it is a professional-grade development environment that offers: Full-fledged OOP (Object-Oriented Programming) support. Robust architectural patterns (MVVM, Layered Architecture, SOLID, Dependency Injection). Comprehensive libraries like FireMonkey and VCL for cross-platform and native development. Seamless integration with Windows APIs and modern OS features. ❌ On the other hand, VB had fundamental limitations in its OOP and architectural capabilities. 📌 Comparing Delphi to VB is completely inaccurate and misleading. 🟢 Delphi Is Continuously Evolving ✅ Delphi Has Strong OOP and Architectural Support Delphi has long evolved beyond just "drag-and-drop" development. It supports Dependency Injection, Unit Testing, and scalable architectures. ✅ Seamless Integration with Windows APIs, Including WinRT While Embarcadero has not natively included full WinUI support, they have provided highly professional WinRT integration using TWinRTGenericImport. This approach is similar to their work on Android libraries, offering a clean and efficient way to interact with WinRT. ✅ The Delphi Community Is More Active Than Ever GitHub repositories, Stack Overflow discussions, and Delphi-focused YouTube content demonstrate the language’s ongoing evolution. Modern Delphi development embraces clean code, architectures, and high-quality patterns. ⚡ Final Thoughts: GUI Development Isn't Dying—It's Evolving! ❌ The claim that GUI-based development is disappearing is an oversimplification. ✅ In reality, tools like Delphi are thriving because they adapt to modern development needs. ✅ Delphi is no longer just about drag-and-drop—it supports advanced architectures, OOP, and scalable patterns. ✅ The competition with C#, Java, and C++ does not mean Delphi is obsolete—on the contrary, it's gaining new strengths. 💡 However, if there’s one thing I can guarantee will go extinct, it’s not Delphi itself, but the era of classic, messy "spaghetti code" development. 🚀 Most modern Delphi developers no longer even have the patience or willingness to open old, disorganized projects because of their lack of structure, logic, and maintainability. 🔥 Clean, well-architected code is the new standard—and that’s where Delphi is heading! 🔥 Delphi will remain a powerhouse as long as it continues to adapt and evolve! 🚀

Mine https://github.com/vhanla/MineSweeper it is so basic 🙈

Of course. If someone wants to pay me my going rate, I'd stop everything and create one. As it stands, I hope to find time to work on creating one. The million+ lines of code that don't belong to me can't just be posted in attlasian's system.

For years LSP has been broken on our very large code base. The main problem being "Find Declaration" is non-functional. We also experience problems when switching between Win64 and MacOS build targets; usually doing so without cleaning the project results in the IDE crashing or the compiler crashing or both. I complained about this earlier today in this post: Today, I was stepping through code in our MacOS build when I noticed that the IDE was taking me to the wrong source file. That clued me into what was going on. This project has about 40 local copies of Delphi source files to fix various bugs and add some needed access to private fields, etc. (Trust me, we hate to do this, we don't want to do this, but when the FMX code base assumes only one thread will ever want to use bitmaps and stuff like that, we have no choice). Of course these local copies appear first in the search path. This naturally necessitates that the other source files are rebuilt, and they are listed in the search path, lower down. The compiler works perfectly fine; our modifications are built without issue. But the IDE and LSP hate this. While stepping through code, it took me to the original FMX.COntrols.pas file, not the local copy that is being compiled into the build. No amount of tweaking the search path or browsing path helped. This got me thinking that this could be related to code navigation issues. So I went into the Rad Studio installation folder and renamed all of the source files for which we have a local copy, so that it would be impossible for the IDE or LSP Server to reach them. And like magic, every single problem I have been having with code navigation suddenly went away. Even switching between MacOS and Win64 build targets and compiling became a seamless operation. So, it appears clear that the LSP Server and IDE do not take the same clues as the compiler or linker or whatever when it comes to search paths. And chaos ensues, due probably to incompatible interfaces that exist between unmodified fmx classes and our local forks. Now I could be overstating the effectiveness of this fix, but I spent an hour doing things I know break the IDE and they all worked. The problem is now I have gone nuclear on the Delphi source folders and no other projects can use them. What I would like to do is have a different copy of the BDS /source/ folder that is used for this project. But we already know a wholesale copy into the search path won't fix it, because those files are already there. We need the IDE to treat a different folder as canonical for $BDS/source. I already use the -r command line switch for the IDE to isolate this project into its own registry hive, but I could not find a way to override the BDS variable (nor do I think that is the right solution). This brings me to my question -- going to Tools/Options and trying to override the BDS environment variable creates an error since it is "built-in." My current solution is clunky -- maintain two source copies of the BDS source folder, one with all the files and one with files removed that we have local copies of -- and switch between the two depending on what project I am working on. But is there a way to tell the IDE and LSP Server to use a different source folder? (Probably not, because if so, it would already be working based on the project settings, LOL!) If I can get time I may try to make a small project that reproduces one of these problems, but this is a million+ line project and it could have to do with a combination of factors, not just the fact that we have local copies of stuff like FMX.Controls with incompatible interfaces.

Personally, I create .pkg files - using the create installer function of Mosco.

SQL Server Express is ano brainer, even InnoSetup can handle its installation automatically without user interaction. When you outgrow SQL Server Express, you can upgrade to a more powerful SQL Server edition such as Standard or Enterprise, or migrate your data to a scalable cloud-based database solution like Azure SQL Database. Avoid exotic DBMSs that introduce you to a labyrinth of their own dialects, from which there is no turning back.

Yet another Microsoft frontend technology? Microsoft do have a capability to provide the technology, the tool chain, the tools and the IDE or their 'Community' does. The Delphi approach matters for mid-sized applications as result of Microsoft or Apple denying the necessity for dialog based applications in the 1990s, which have been covered by various web technologies later on. I doubt that it makes lots of sense to integrate another GUI technology in anything else but a development environment pretty similar to PyScripter. For different reasons the have always been small applications in a Win 3.x tradition (utilities with GUI) and the real big/complex ones. For the latter C/C++ setting up bigger teams paid. In both cases no one ever needed a GUI designer and for the first the shortcomings of MS GUI technologies concerning GUI in case of Visual C/C++ didn't hurt. VW was the solution for the dialog based applications and those were mid-sized. VB suffered from the OLE and/or early COM approach to let the business developers design the GUI and the business logic and the controls and such stuff should have been implemented in C/C++. Remember Microsoft touting the return to one development language and that was the C language and C++ later on. The golden opportunity these days arose wtih so called Y2k Bug and companies investing in replacing the IBM Mainframe/Host and the growing of the finance industry in the 1990s. The VCL approach is lean enough and still does it's job pretty well, but for most of us. For the last decade or longer developer face/experience a certain kind of meta programming, in a different sense but the original one, by JetBrains or special development environment aiming at a certain technology. PyCharm vs. Wing and 20 other alternatives. PyScripter shows in lists of the 10 top Python development environments, while the Wing IDE requires a top 20 list in order to show up. A few years ago, Wing was ranked number 2 or 3 and fell back year by year. If people want a Thonny on steroids there is nothing EMB could do against. Have a look at VS Code or the new JetBrains IDEs. Since the shift to this century we see strong trend into direction of 'terminal style' development combined with more sophisticated and specialized technological underlying. So we can just say, GUI driven development found it's place, but has been a tiny rabbit-shit on the long time-line in which GUI focused programming in addition had it's decade in the 1990s. Third-party does not mean, not being in the position to implement your own widget-set, it means that writing ones own widget set is simply to expensive in a sense of time consuming. Even in case of WPF the controls shipped can be regarded as a sound proof of concept of the underlying technology. The idea of 'the GUI technology' is a very Microsoftish thing. To mimic the GUI is by far an/the approach enjoying broader acceptance on even on a mid-term already. ... Heavy rings on fingers wave Another star denies the grave See the nowhere crowd, cry the nowhere cheers of honor Like twisted vines that grow Hide and swallow mansions whole Dim the light of an already faded primadonna (Metallica, The Memory Remains) Love the title of the song :) Beside all your valid thoughts and arguments from a technical perspective, let's say it that way, 'If you are still developing VB-style at the age of 30, you must have done something wrong and using RAD Studio for that changes nothing concerning this remark' - not talking about you.

FYI Signotaur can sign MSIX files - https://www.finalbuilder.com/signotaur And it works with Certum tokens and works around the password prompts.

When you publish a game in this challenge or in general, don't forget to add "delphi-game" topic to be listed in https://github.com/topics/delphi-game "delphi", "gamedev", "game-development" and "game-source" are welcome too for showing to the other game developers that Pascal and Delphi are available for game programming.

I have, and that uses an older version of signtool: "C:\Program Files (x86)\Windows Kits\10\App Certification Kit\signtool.exe" sign /v /a /fd SHA256 C:\Win\SignTest\Win64\Release\SignTest\bin\SignTest.msix The following certificate was selected: Issued to: My Company Issued by: Certum Extended Validation Code Signing 2021 CA Expires: Sat Jan 08 12:11:18 2028 SHA1 hash: E7C16794EA23F573DE3EA32B5B564717CE84CC75 Done Adding Additional Store SignTool Error: An unexpected internal error has occurred. Error information: "Error: SignerSign() failed." (-2147024885/0x8007000b) File version is 10.0.19041.685. I'm using 10.0.26100.0 which at least gives a slightly better error message.

Actually, no. Creating and destroying windows is highly discouraged in DllEntryPoint(), see: Dynamic-Link Library Best Practices: Guess where the CreateWindow/Ex() and DestroyWindow() functions reside - in user32.dll ! 0x0EEDFADE is the exception code when a Delphi exception escapes into the C++ runtime. So, what exception type exactly is the TForm destructor actually throwing? My guess is EOSError if DestroyWindow() fails. But a TForm destruction does a lot of things, so there could be any number of reasons why it would fail while the DLL is in the process of being unloaded from memory. Perhaps, if your DLL's TApplication object were already destroyed (or in the process of being destroyed). You should run your code in the debugger and verify that. Your global Form1 variable would not be updated in that situation, so you would have a dangling pointer. One way to handle that would be to assign NULL to your variable in your Form's destructor. But really, this is not the kind of stuff that you should be doing in your DllEntryPoint() to begin with. It would be better to export a couple of functions from your DLL that the loading app can then call after loading the DLL and before unloading it.

For Delphi / RAD Studio version 12.3, the original solution provided by Jim:  C:\> getitcmd -i=fmxlinux-12-1.78 works "out of the box" with no issues !! ( --> no "patch" needed as in 12.2 ) You can use this solution to get "FMX Linux" until they reach a final agreement with Kryukov's state ...