Leaderboard

https://community.idera.com/developer-tools/b/blog/posts/rad-studio-10-4-patch-3-is-out-vcl-grids-c-win64-debugging-and-c-android-exception-handling-and-resources

When you find a problem with RAD Studio, make sure to create a report in https://qp.embarcadero.com/ which has replaced the former https://quality.embarcadero.com See https://blogs.embarcadero.com/the-new-quality-portal-is-live-here-are-the-details/ for clues on how to use the new reporting platform. And - please describe the problem properly! What you are trying to do The actual result you got The result you expected Most important: How to reproduce the problem - either as a detailed step by step description - or as a small, self-contained, compilable example project - or both of the above Better reports = better chance of getting stuff fixed.

My main problem with .net and D2007 is that every time I install a new version of Windows (twice a year with 10), Microsoft deletes the four Borland.x.Targets files it installs under \Microsoft.Net\, but learnt my lesson a long time ago and keep copies to restore. Angus

Thanks. My guess is that the DRC-file was out of sync with the EXE file at the time you created the project. You should compile the application again and make sure you generate the drc file (see below). Then you can Update the translation project and the resourcestring names and values should now match. Unfortunately the existing resourcestring translations will be marked obsolete since the source name/value pairs have all changed. The only way to recover the resourcestrings you have already translated is to add the translated resourcestring values to the Translation Memory before the update and then use the Translation Memory to apply the translations again after the update. The DRC-file contains the mapping between resourcestring names and string resource IDs. It is created by the Delphi compiler if the "Output resourcestring .drc file" linker option is enabled. Since this isn't obvious I have just updated the DRC-file prompt to state this fact: I have also added a check to display a warning if the timestamp of the EXE and DRC-files are too far apart (>10 seconds), indicating that they are probably out of sync:

I have that same setup. My Delphi 10.4 enterprise IDE was very sluggish until I changed some Windows 10 settings inside the VM as well as on the host machine. After those changes it behaves much faster. -> start - control panel -> in the control panel, double-click the "System" applet -> click "Advanced system settings" -> in the field "Performance", click the button "Settings" Then select the settings as in the image below. Re-start windows.

If it is owned, it is destroyed when its Owner is destroyed. Otherwise, it is leaked and not destroyed at all. When the process exits, the OS will reclaim the leaked memory. Using Action=caFree in the OnClose event is the correct way to do that. Whether or not the Form has an Owner is irrelevant. An owned object can be destroyed at any time, even before its Owner is destroyed. If the object is destroyed first, it will simply remove itself from its Owner so that that Owner does not try to destroy it again.

In the C++ community people usually tell you the compilers are incredibly smart (mostly referring to gcc, clang, msvc or icc) and you should not bother but just know some C++ tricks (constexpr wherever possible and alike). When talking about Delphi it would be an insult to most developers calling the compiler smarter when it comes to detecting patterns and optimization. However - unless you write core libraries like Arnaud or me you usually don't care.

...and you can juggle chainsaws.

I would approach this from the point of view that all data provided by the client is bad until proven otherwise - seriously, expect bad data, when it' encountered report that and exit/stop gracefully (with an error message that enables the client to fix the data).