Lajos Juhász

Maybe it is commented out to fix some strange issue/bug. In that case the developer that has commented out the code should include the report number in the comment to document the change in behavior.

You can try the test 64 bit Delphi IDE.

Same on my system 2 different exe files.

It could be that when the library detects the debugger it slows down. You can try using Lazarus at Windows to see if it behaves the same.

The question was whether it is possible to check if the future is completed or not. Method Wait can be used to achieve that. (The design of wait could be improved to support non-blocking call, but we can argue if a couple of ms delay is significant or not.) Nobody mentioned that the future is going to be used in the main thread. Whenever ProcessMessages should be used or process paint messages depends on how long the calculation should take. If it is under a minute or the application should be blocked during the life of the method, it should not be used.

Read the documentation: function Wait(Timeout: Cardinal = INFINITE): Boolean; overload; You do not have to wait for infinite.

That is the idea behind future to do something until you definitely need the result of the future. If you want to check if the future is finished you can use the wait method.

The answer is the same as for the previous question you have to change the StyledSettings. In this case you are changing the Family and Style thus you have to remove those elements from the set, you do not change the Style of the font. You can replace: L1.StyledSettings:=L1.StyledSettings-[TStyledSetting.Style]; L2.StyledSettings:=L2.StyledSettings-[TStyledSetting.Style]; with: L1.StyledSettings:=[]; L2.StyledSettings:=[];

Calling a method of the target form?

First of all, DBGrid is not a dataset, it is a component that displays data. How should a component know if and when the field value must be calculated again and cannot use the cached value? On the other hand you can use fkInternalCalc (caches) stores the calculated values https://docwiki.embarcadero.com/Libraries/Athens/en/Data.DB.TFieldKind.

CaretPositionProp is not nil, however when invoking the GetValyue in CaretPositionProp.GetValue self is an Inaccessible value: FMX.Memo.TCustomMemo.GetCaretPosition :00cfcac8 RawInvoke + $40 System.Rtti.RawInvoke(???,???) :00cfcead Invoke + $249 System.Rtti.Invoke(nil,(),???,???,True,True) :00cf5689 TRttiInstanceProperty.DoGetValue + $DD System.Rtti.TRttiInstanceProperty.DoGetValue(???) :00cf54ae TRttiProperty.GetValue + $26 Since it is pointing to an invalid address the Access Violation is when the code tries to execute Model.CaretPosition.

Using Chrome there is still no warning. I got the warning using FireFox.

Use Google Chrome, no error messages.

If you are using a standard windows user then you must start the IDE elevated in order to have a chance to verify which patches are installed.

You see he images because the IDE will copy paste the reference to the imagelist on the DM. The compiler will find the DM containing the pictures and will show them. You can save the form, close all the projects and open the form the IDE will remove the reference to the datamodule and you will not see the pictures anymore.

This also fails in XE5 and 11.2.

FireDAC is using the meta information from the connection library to determine the data types. You can try to use cast to change the data type for the field in your test application.

The version also matters since it was changed for version 12. https://dalijap.blogspot.com/2023/09/coming-in-delphi-12-disabled-floating.html

It was not humorous, that what Embarcadero did communicate about the platforms and the way they do releases. The same was with the 64-bit IDE. For years it was a side project that they were testing. Then when some databases stopped shipping 32-bit client libraries they have decided it is time to ship a half-baked solution....

Yes, they will support it ASAP when they think it is good idea.

There is no TUnicodeStringField this is from the Delphi Unicode Migration (https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf😞 While this update makes the reading and writing of Unicode data in the TField classes consistent with the UnicodeString data type, and eliminates some potential data conversion issues, some of the class and member names in the TDataSet arena remain confusing. For example, there is no TUnicodeStringField type, and the TStringField class still stores its value as an AnsiString value. If you want a Unicode TField, you use TWideStringField (which, as mentioned in the preceding paragraph, is stored as a UnicodeString in Delphi 2009 and later).

Even if anyone from Embarcadero will ever read this there is a low chance that they will do anything based on a forum post. They have an official channel for bug reports.

Yes you can, but can not use the 32 bit IDE if the database has only 64 bit client library to test SQL statements, create fields in the designer.

The only exception if you are working with databases that now ship only 64 bit client libraries. Most, if not all, of the modern databases has discontinued the 32 bit client libraries.

Nope. According to the release webinar they are working on to make a deal to continue to provide it.