Dalija Prasnikar

You can fix that to show old menu options. Works fine. See https://superuser.com/q/1674122/464320

I would go back to Vista or Win 7 in blink of an eye. I would be thrilled if I could have stayed on Win 10, too. Windows 11 is by far the worst Windows version ever (and I could not believe this was possible after Windows 8). There are zero new features I want to have and they messed up everything else. For start half of the things no longer cannot be configured. Taskbar height is too big, colors and icons are awful, Windows theme even worse (selection colors, checkboxes, and similar), you need ten clicks more to do things, fonts are total nightmare and cannot be uninstalled. Whoever designed that Cascadia Mono font needs to be tarred and feathered. It is absolutely illegible and half of the websites are using is as the default monospace font. And this is just scratching the surface...

Thread safety has nothing to to with speed. Strings are reference-counted and string assignment is not atomic operation. Assigning string variable from multiple threads can mess up the reference count and cause memory leaks and crashes. Yes. Access to the string needs to be protected (that includes other code that accesses that string even if it is just being read from). But, if the leaks are still there, then there are most likely some problems in other code you haven't posted. Which Delphi version are you using?

Thank you! I would never do that. Disagreement does not imply lack of respect. It was not meant to bother you. This is why I also put a smiley at the end of my sentence. The point was to bring attention to your posts which are hard to read because of your AI usage. AI can be helpful, especially for communication and I know people who are able to communicate their thoughts better with the help of AI. However, that involves using AI very lightly and mostly for translating and fixing text they actually wrote. When you give AI more freedom to write things for you, the effects will commonly be the opposite. I am finding your posts where you used AI extremely hard to read. They are long and unnecessarily wordy. Another problem (not that relevant here and now) is that when one can clearly recognize something being AI generated more than having some light AI touches, one cannot be sure whether you are actually discussing something with a person or merely an AI. Are the points and arguments used really the ones that the person has tried to make or it is just something AI put there? It is hard to have a conversation in such situations. Nobody is trying to prevent anyone from using AI. You are free to use it all you like. I am not sure what you mean by spying or using third party tools. I am neither spying on you, nor I am using any tools for AI detection. As a Stack Overflow moderator, I have seen first hand the huge amount of damage AI can cause. The amount of posted AI answers there (where vast majority of them are completely incorrect AI slop) is not measured in thousands. It is measured in tens and hundreds of thousands. There are users who posted hundreds and even thousands AI answers. Imagine how much more of such posts would be there if AI would be allowed there. The site would be overflowed with AI. The only reason why AI is forbidden there is to preserve the site as repository of knowledge and a place where you can go and get help from actual experts in their field. Unfortunately, the only means moderators have to fight such influx of AI answers is to remove all and every one where some AI usage is detected (even when it is used merely for translating). We cannot easily distinguish between post which were fully AI generated and ones that were merely improved by AI. On the scale of Stack Overflow, with only handful of moderators removing AI, we cannot judge the correctness of each and every answer. Unfortunately, it would. You cannot add feature without removing the time needed to do implement said feature, from something else. That means less improvements in already used frameworks (VCL and FMX), less bug fixes, less IDE improvements. Embarcadero is not Microsoft, nor Apple, nor Google. They need to pick what they will do carefully to maximize benefits to all customers, which means focusing on the things that cannot be easily provided by 3rd party.

Actually it is not nonsense at all. This is the source of your memory leaks. String assignments are not thread-safe.

@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....

Yes, but the new 64-bit compiler is about compiler bitness, not platform. That means that compiler is no longer 32-bit process and can use all available memory on the system.

Of course, but plenty of code doesn't have that.

For me it is about code intent. FreeAndNil implies reusable variables and more complex instance lifetime. Free implies the opposite.

No. I remember seeing such code, but I cannot tell you the exact place. It is hard to find them because in most places RTL, VCL, and FMX use FreeAndNil when it is not needed at all or for lazy initialized/reusable variables.

Because it is a plague Reusing is the one scenario. Another scenario which you can see in very complex destructors which are part of some deep class hierarchy. It is not to prevent concurrency issues (because it can't prevent those), but it is used to prevent accessing already released fields during more complex cleanup. In such cases it must be paired with is Assigned checks. But this is rarely needed outside frameworks like VCL and FMX (and even there it is used in many places where it is not needed at all).

procedure TMyClass.StartAsyncTask; var LCancellationToken: ... begin // capture this local variable instead of field in anoanymous methods LCancellationToken := FCancelaltionToken; ... TThread.Synchronize(nil, procedure begin if LCancellationToken.Cancelled then Exit; // Callback-Code Writeln('Task finished gracefully.'); end); @Rollo62 Use the above approach to avoid capturing Self. You also need to check once again whether task was canceled when you synchronize, before you touch anything from TMyClass. also this will only work if the code that runs within the task does not touch anything from the class. If you can't avoid that you need to store task in field and wait for its completion before you destroy object.

If the callback runs in the background thread then FreeAndNil will not make the difference. In other words, your guard is not guarding anything. The FMyVar could be released after callback passes the Assigned check. You would need a different mechanism to protect your variable and make sure it is still alive while callback runs. The whole idea that your object which is still used while there may be pending async code running is a serious design flaw. I am not sure how easy would be to fix that code (I expect it is more complex in real life scenario), but you have a problem here. There are different mechanisms that can protect your instance, but which one is the most suitable will depend on other code and context that you haven't mentioned here. You can find some ideas at https://github.com/dalijap/nx-horizon look at how TCountdownEvent is used. another one is in https://github.com/dalijap/code-delphi-async/tree/master/Part6/35.2 GUI Cleanup but that one will work only if the TMyClass instance belongs to main thread. Of course, those are not the only solutions, just something to get you started. I haven't mentioned the most obvious one (waiting for the background thread to finish, before you release TMyClass instance, but I guess that this is not an option here or you would probably use it already.

FreeAndNil is something that you will need to use rarely (it might depend on the kind of code you are writing). In places where your code needs it logically it will be obvious that you need it and everywhere else you can use Free. The point that FreeAndNil can help you avoid errors and mistakes is full of holes. First, simple access after Free is usually easy to catch either by looking at the code (local variables) or by using memory manager in debug mode or other specialized tools. Next, FreeAndNil nils only single reference to the object instance. If you have multiple ones you will still have to deal with dangling pointers and you will need to learn how to use previously mentioned tools. Most of the problems with memory management in Delphi are caused by having multiple references to single manually managed object instance as such code is more complex. This is exactly the place where FreeAndNil cannot help you, but where using it will give you false sense of security. Another reason against using it everywhere, is that it obscures the code intent. Logically, FreeAndNil means that variable will be reused and this is important information. If you use it everywhere, you will have mush harder time reading the code and understanding its intent. And code which is harder to understand is also harder to maintain in the long run. Of course, that can be solved with comments, but then you will have to use them everywhere or you will never know whether some comment is missing somewhere. Manual memory management requires some discipline. thinking about the code you are writing enforces the discipline and makes you a better programmer. Taking the "easy" path where you will slap FreeAndNill everywhere just so you can avoid accidental mistakes and thinking is going to cost you at some point. Many existing codebases where it is used everywhere cannot be easily migrated to not using it as it can be hard to determine where it is needed and where it is not (except for local variables) and they need to continue using it indefinitely in all places, as the only thing worse than using FreeAndNil everywhere is using it randomly. Consistence in code is the king. In my codebase I have less than 50 places where I am using FreeAndNil (I cannot tell the exact amount as I have many smaller projects and it is not easy searching through them as some contain fixed VCL code which uses FreeAndAil a lot, so I cannot easily count usage in my files only) One of the advantages of being a new Delphi developer is that you don't have a lot of existing code where FreeAndNil was used in places where it is not needed and now is the right time for you to decide whether you want to pollute your code with FreeAndNil and stick with it forever or not.

This year, on February 14th, Delphi celebrates its 30th birthday. Over the past three decades, Delphi has proven to be a robust and versatile development environment, empowering developers to build high-performance applications with ease across multiple platforms: Windows, Linux, Android, iOS, and macOS. As we commemorate this milestone, I am also introducing a new book to help guide you into Delphi's fourth decade: Delphi Quality-Driven Development - A practical guide to testing and writing testable code. Useful to lone developers and vast teams alike, this book aims to demonstrate a variety of essential practices and techniques for making high-quality, testable code. There is a 25% sale going on until the end of February for the Delphi Quality-Driven Development ebook, and there you can also get an additional discount on other books if you add them to your order. https://dalija.prasnikar.info/delphiqdd/index.html To all my fellow Delphi developers: May your code compile quickly, your memory be manageable, and your code testable.

Maybe it was some glitch. There were other people from Italy who successfully purchased. If there is some problem with the method of payment, you would have to contact PayHip directly as they are handling that part and I cannot help with this. https://payhip.com/ I was just told that they occasionally have some glitches (where it gives you error on purchase, but there should be button try again and usually that is enough to go through)

Please show the code that actually exhibits the problem. The code you posted (if we ignore the fact that you are missing procedure keyword in your method declarations) works the way you want it to work.

Another more elaborate example that will show why is compiler strictness for var parameter necessary, and why without it we could easily and unintentionally write the code that can corrupt memory otherwise Pass the Dog, Get the Cat

When it comes to mobile development you cannot count on that kind of stability. Not because of Delphi, but because of platforms. android and iOS get new OS version every year, often with drastic changes in some workflows and features. They also expect that you frequently update your application and make it compatible with new OS versions (old applications still run, but if you don't make an update in two years period applications will not be available to users with new OS versions - this is just example, there are variants of what exactly happens in each particular case). Those OS changes also require changes in Delphi toolset and sometimes additions in code. How drastic depends on the each particular change. This is valid for all mobile development toolsets, and is nothing Delphi specific. But, this also means that you will have to keep current with new Delphi releases and you cannot stick using some old Delphi version for too long after new one gets out.

Yes, things have changed significantly for the better. However, there are still some pain points (more specifically debugging, especially on iOS as Apple keeps throwing curved balls) Main difference is that ARC was being source of significant performance issues on mobile platforms. I have done extensive investigations at the time, and by doing slight modifications in FMX code I was able to significantly improve performance. Used optimizations were covered in my blog posts: https://dalijap.blogspot.com/2018/01/optimizing-arc-with-unsafe-references.html https://dalijap.blogspot.com/2018/01/optimizing-arc-hard-way.html https://dalijap.blogspot.com/2018/03/optimizing-arc-weakness-of-weak.html Even though there is no ARC compiler, above articles are still valid when dealing with interfaces in Delphi. Removing ARC compiler was not the only performance improvement. Next one was introduction of Skia library in Delphi 12, which gives better performance on mobile platforms. It is not perfect and depending on the project it is not necessarily working better on the desktop FMX applications, but it is easily configurable, so different rendering methods can be used depending on the platform. Another pain point was using 3rd party frameworks on both Android and iOS, and this has also been significantly improved in the meantime. Overall, plenty of bugs have been fixed in the meantime (of course, that does not mean there are no new bugs), but things are way better than they were at the early beginnings. Most importantly people are successfully using Delphi for writing Android and iOS applications. You can find one such example here: Whether Delphi is the best option for some project that is another question and it can really depend on the project. The best option would be putting down all the tech your app needs to interact with and what are basic features you need to support. After you have tall that listed you can make a demo app to see whether you can easily incorporate all that you need across various tools and platforms. Only after doing that you will be able to tell which one will be the best for the project. And at the end, the grass is not greener on the other side. For development Delphi is much more stable platform than some others. It does not have some fancy features language wise, but its UI frameworks are very stable. Over the years, both Google and Apple made significant shifts in their native frameworks that required extensive code refactoring (yes, you can still use the old ways, but it still requires a lot of work to keep up with changes). If you are looking for cross-platform tool, then situation is not too much different.

If you are using App Bundles and Play Store Signing, then you need to add SHA-1 fingerprint from the Google Play Console as Google will use different certificate for signing from the ones in your keystores. See: https://developers.google.com/android/guides/client-auth

It compiles for me... but after adding missing quotes in interface GUID declaration. TParallelArray is not the problem here.

Just the fact that the code has been working for over 25 years means that it will have very little issues when it comes to exception handling. Only hardware exceptions are the problem, which for VCL means mostly dereferencing nil and dangling pointers and floating point exceptions (which are now masked by default). I doubt that there are many places in VCL that would need code changes for exception handling.

Since there is already plenty of low level RTL code that runs with LLVM based compilers, the only part where those exceptions could cause issues is VCL. I would say that this is probably less of a problem than it may look like on the first sight. Developing Windows ARM compiler is much simpler than 64-bit IDE

AI can't even count properly. Why would it be able to know whether number is prime or not?