We are pleased to release a hotfix for RAD Studio 10.2. This hotfix addresses:

  • debugger issues for Android, iOS, and Linux;
  • Delphi Win64 compiler issues;
  • a C++ RTL issue addressing a crash on exit;
  • a security issue in the C/C++ RTL. Our thanks to Ɓukasz Wyporek for notifying us of this issue.

You can find full details about each issue in the readme and download page on CodeCentral.

We also have an Android compatibility patch in the works to address Android issues around text input, control rendering and performance.

Anonymous
  • Hi Almost all of my android programs are suddenly closing after a while after being compiled with Tokyo. So ultimately I resorted to a very minimal test: start a new Multi-Device application... Create an empty form. Put a button and a text or a label on it. Compile and deploy to android 5.01 or 6.1... The application would run for one hour then suddenly closes without any message. This happened on 3 devices with no apparent reason. There seems to be a bug somewhere. Memory consumption stays normal. Cpu usage normally. But applications compiled with tokyo always crash after 1 hour or so, even simple apps on brand new devices Has anyone experienced a similar problem? Thanks
  • Fresh install of Tokyo then apply this Hotfix try to compile existing Android app and get "FMX.Forms not found" errors (it seems like heaps of other FMX units are missing as they are red-underlined as well) complies fine with fresh Tokyo or Seattle installs. I have turned off the Windows Defender anti-virus - the only AV on the machine.
  • Reply to comment posted today (Reply buttons available "randomly" in both Firefox and ie?) The quantity of updates to a degree is not important as long as issues identified in the release are always resolved rather than fixed "in the next version"...where new problems are added. Working this way means you never have a stable build, which in turn means those that do upgrade are stuck with broken tools (if they cannot upgrade for a while after). Feedback re Kaspersky. I have not uninstalled it yet...because after messing about with the cbproj files the errors stopped...after making more changes the errors started again. So it does not seem to be an av issue. FYI. in 10.0 everything still compiles just fine at the mo initial changes were because 10.0 had issues compiling some, but not all, apps. This turned out to be related to 1) source folders being moved between versions (so win32 iLink settings became corrupted) 2) The somewhat random way in which the cbproj files are upgraded (xml entries are in different area's for different project files) were the cause of some but not all apps either compiling or not. It's the cleanup / standardisation that seems to have RAD 10.2 working then not working. I have deemed it an avoid release, like many before it, because I've experienced issues and have no guarantee it will ever get fixed. One thing I would really love to see is proper documentation on these xml (proj) files as I've read enough "how to fix this issue" webpages to know that editing these files fixes a whole host of ills that you simply can't fix through the RAD studio interface ...and yet I am currently guessing as to how the structures work...and what each element does because the help files cover them at a really minimal level. Put it this way, it seems on the face of it that I might be able to get 10.2 working if I could understand what's going wrong in the project configuration files, but I've no means to accurately translate much of the contents
  • Hi James, Thanks for the feedback. It will be taken on board. FWIW, we're aiming for several releases to 10.2. Not sure about five, but should be two or three at least. The thing about the number of releases is, effort put into a point release is effort not in a major release. These days, with update subscription, you get everything steadily every few months anyway, so we're planning more releases with more content.
  • Try not to get confused, this is re your next comment to me (there's no reply button??) Most large companies don't like to touch new os's till there's a patch or two...because nobody's perfect so there will be issues that need resolving. This is why there's large jumps between me actually upgrading RAD Studio. Something always coming up. I don't so much mind paying the maintenance subscription costs when I can't upgrade as I try to look at it as supporting a company that I need to maintain the tools I use. But as mentioned patching a running system is not the same as going through a massive project making changes to suit things like AnsiString support removed (This one was a doozie!), Removal of Rave Reports (Another very major bind), TSockets.hpp seems to give 10.2 the right hump...which means work going through looking for any any all references and seeing what that affects...and what the consequences of removal might be. Then there's the third party integration stuff like Axis Cams, Fingerprint reader API's etc.. sometime these don't play ball till I see updates More patches please as there's little point having a development platform that will never be fully stable. I'm certain most programmers like myself and Lazlo prefer completely stable to totally up to date, but with showstopping issues. Take ilink32 (yes I did exclude the project folder from my AV scans). This has been causing devs a pain in the butt for donkeys years, forcing them to reboot computers once it messes up...and it's just been updated now...because focus has been on pushing a new releases. x64 also took an age to turn up when people had been screaming for it for years, because integrating third partys was all the rage at the time. Here's my thoughs on that QReports, Rave Reports...I'm waiting on having to redo everything again once Fast reports is booted out. All's I'm saying is there's a middle ground and it needs to be considered beacuse basic features and stability are crucial to most. Yes I will do a QC for the issue with captions etc.. losing transparency (once I get that far in the project update process)
  • Did you try turning it off from your source and build folders? Compiling and linking opens and uses a lot of files, and they're executables, and they're exactly what AVs are interested in. An AV can interrupt and cause errors that are completely out of our control.
  • We are trying not to have too many updates, but we have a couple planned for 10.2, and two hotfixes / patches out already. The transparency and parent color bug you mention - could you link to the QP please?
  • Hi Andrew - you're right, and my apologies it's taking so long. You may be able to rebuild Boost yourself, though that is a lengthy process. We're looking into it and I've just escalated it.
  • Understood. iOS and Xcode, should be coming soon. Until then please use 8.2; you can install that version by downloading it from Apple. NexusDB: I'm not aware of that, will follow it up.
  • My apologies - I missed this was a FireMonkey bug, not VCL. We're tracking it and hope to have a fix.
  • I'd like to add my name to the disappointed list. Most releases these days get just one update, rarely 2, possibly none. From what I remember XE2 had 4 updates, 2010 had 5. Gone are the days when much effort is put in to fixing anything "before the next release" where new tooling adds new problems. For me this creates a huge problem because upgrading is never that easy. Sometimes, like 10.2 I simply cannot use the current build as it fails to compile anything, sometimes I have to change code, sometimes (like with Rave reports) support for stuff just disappears which means delays due to huge re-writes. Sometimes I just don't have time (as I always seem to have to go through a million and one screens and disable, then re-enable transparency & Parent Color checkboxes before caption objects use the container/parent colour again?) For one reason or another I have been forced to ignore most releases which leaves me stuck with an environment that's best described as "not as broken as the alternatives". Put another way. I can no longer be confident that issues will be fixed in short order so I cannot risk upgrading when there's a failure during testing...and I truly wish this was not the case. Please go back to old way of thinking and continue fixing versions after they have been superseded.
  • David, yes, we make it, since 1 month: We are looking every day for a hotfix, or for 10.2.1. We need a deadline. We don't need any new features, EMB should fix major bugs first, look at the last 5 replies... We are disappointed.
  • David When will the toolchain be fixe to allow Boost to be used with Tokyo? This is a MAJOR bug, making it impossible for us to upgrade to Tokyo since we rely on boost. Please see RSP-18123 (which remains unresolved). The proble is that the pre-packaged Boost DLLs that ship with Tokyo have been compiler with the memory Manager from Berlin (!!) - hence at run-time Windows comlains that it cannot find the right emory manager and forces your app to shut down. It is not a workaround to ship the old memory manager, since that causes untold confusion where data is held. This bug warrants a re-issue of ALL the Boost libraries. It does not require a hotif for Tokyo as such.