Leaderboard

We probably do not write the same kind of code, because it never took much time to me to move a project, even a big one, to the next Delphi version. The only case when it took significant time was when Unicode was introduced. Most of the time, it was just a matter of recompile. I must say that I always manage to have FULL source code for every component I use and have that source code included in all projects making use of the component. When a new Delphi release comes, most of the time a simple recompile is enough. This include the component package projects. The most common change to the source code is to add a simple conditional compilation related to compiler or runtime version. When you have full source code, you don't depend on component vendor when a new Delphi is released.

Hi, this morning, digging deep in the source I found the solution. My fault was in the use of Data.Bind.Components.RegisterObservableMember to have a LinkPropertyToFieldText link you have to use Data.Bind.Components.RegisterValuePropertyName initialization Data.Bind.Components.RegisterValuePropertyName (TArray<TClass>.create(TLThermo), 'Progress', 'FMX'); finalization Data.Bind.Components.UnRegisterValuePropertyName (TArray<TClass>.create(TLThermo)); So, it's solved

If you are posting this in the hope someone will eventually fix it... *post the link* to the issue so others can vote!

If I was starting a new application targeting multiple platforms, I would develop for all platforms simultaneously while building the app. The reason is that different platforms will have slightly different ways of doing things and if you build the app to work well on one platform then address needs of others, it may affect some screen design decisions you would've made differently earlier. For example, iPhones and iPads don't have a back button but Android devices usually do so if you write the app with the assumption of an Android device first and assume everyone will have a back button, your screen may be too cluttered to add a back button later when you add the iOS platform. That's just one simple example and of course you should be aware of platform differences up front (and never make assumptions, etc.). There are many other considerations such as screen size and orientation, which style will you apply for the different platforms and how do all the different edit controls look and feel. All these things have subtle influences on your screen design. It's much easier to make those decisions in the early stages than to then try to morph a feature-complete app for another platform.

Lars, thank you for your post. It is indeed sad that Markus died. I want to correct one thing in your post. I founded Sisulizer with my brother, Markus and Renate. I wrote the application with my brother (in Delphi, of course). Markus and Renate handled the sales. We shared the support. About a ten years ago I left Sisulizer. I wanted to create a new and better localization tool that would be better suited for IT world heading to the cloud. I did not want to make a cloud only solution like MemSource and Crowdin. Instead wanted to make a hybrid solution that combines the best part of desktop tool and a cloud tool. So I wrote Soluling. The desktop part of that works like Sisulizer. It means you select a file, Soluling scans it, you translate or you let somebody else to translate, and finally Soluling build the localized files. Compared to Sisulizer, Soluling has the following improvements: The app itself is also provided as 64-bit Modern Office style ribbon UI The visual editors use real components. In Sisulizer they were emulated. This means that the translator will see the forms just as they appear in Delphi IDE. In .NET they use the real .NET components. Interactive translation memory with fuzzy matching and an interactive termbase. Sisulizer was loved by developers but not that much liked by translators because TM and TB were missing Support for 6 machine translation engines: Google, Microsoft. Amazon, IBM, DeepL and ModernMT More that 100 supported file formats including Delphi 11 Alexandria, .NET 6.0, Angular, React, Vue, DITA, Android, iOS and databases Command line version, SoluMake.exe , that can be used in build servers and even cloud based DevOps build processes Automatic conversion from Sisulizer's .slp to Soluling's .ntp. It generally takes a less than a day to switch from Sisulizer to Soluling. Soluling comes with open source I18N library that brings a nice grammatical number (plural) and grammatical gender (male/female) support for Delphi and .NET. Sisulizer customers get a discount. Soluling's desktop and command line apps are written in Delphi. Next year we start rolling out the cloud parts that let you push your projects to the cloud where the translators can get them and use either Soluling's desktop app or a browser app.