Vandrovnik

In 10.3.3, Classic Undocked and Key mappings set to IDE classic, it is F5.

A conflict with tMonitor declared in Vcl.Forms.pas?

If you put here .pas and .dfm file, I can try it on my PC and let you know (10.3.3 and patched 10.4.0).

I am very glad that Delphi allows me to develop for Android (while being able to test the app on Windows, too). I was just surprised how many problems FMX still has when I started to use it...

I had reported it in version 10.3.1, but problem was closed as "cannot reproduce" https://quality.embarcadero.com/browse/RSP-23904 I think Tools, Manage Platforms was the way.

Looks OK now.

Can you instead of .dpr compile .dproj? Something like this: call "C:\Program Files (x86)\Embarcadero\Studio\20.0\bin\rsvars.bat" set Hlavni=C:\Delphi\Plantis set Pomocna=R:\Plantis "%FrameworkDir%\msbuild.exe" "%Hlavni%\Plantis.dproj" /target:build /p:DCC_BuildAllUnits=true /p:"Config=Release" /p:"Platform=Win32" /p:"DCC_DcuOutput=%Pomocna%\DCU" /l:FileLogger,Microsoft.Build.Engine;logfile="%Pomocna%\Logs.Win32.Release.MSBuildLog.txt"

Just to be sure, have you tried without the picture? Is there 1 picture for the report, or 1 picture for each record?

Classic undocked still unusable... How much time would it need to allow users to manually increase the height of the main window, so that icons are not hidden - 30 second? Or 60 with testing?

They have changed bitmap exports, in my opinion it scales bitmap up when not necessary, which takes time and memory (and sometimes results in Out of memory). I had a discussion and tested export ot bitmap (height = 3508) with following results: - PrintOptimized=true, PictureDPI=300 --- Out of memory, TempBitmap.Height=10528 px - PrintOptimized=false, PictureDPI=300 --- works, TempBitmap.Height=3509 px - OLD_STYLE --- works, TempBitmap.Height=3508 px

I have voted... And I am curious whether it will be fixed before the report is 5 years old 🙂

I have not, because no result list was displayed, just cursor indicating that I should wait... After 3 minutes I killed it.

I have just tried Search for Usages in 10.3.3 --> IDE frozen, Ctrl+Alt+Del 🙂

In 10.3.3, it is better, usually rename finds all places, but sometimes it does not and finds for example just 10 of 30.

If you switch to DeviceCapabilities (which is DeviceCapabilitiesW), take care about memory allocation. 64 bytes is wrong, you will need 64 * SizeOf(Char).

From my point of view, typed constants are just initialized variables, not true constants. (Even when I do not change their values in runtime.) When used in code, regular (untyped) constants may produce faster code: const XTyped : integer = 3; xUntyped = 3; var a: integer; begin a:=5*XTyped; if a>20 then exit; a:=5*XUntyped; if a>20 then exit;

I have asked, what you think is a bug. You have answered and I wrote you, how compiler probably decides the value and that I do not see a bug there. When you want to decide, whether Delphi is wrong with something, first you need a specifiaction saying, what is right. Then you can compare actual result with it. And do testing with current version of Delphi, because even if you find an error in old version, it will probably never be fixed.

When I compile in 10.3.3., I get this (even when optimization disabled):

C : UInt64 = UInt32(-1) shl 63; I suppose it is calculated in unsigned 32 bits (because you used UInt32) as $FFFFFFFF shl 31 (63 is masked by width of the left side operand), which is $80000000. This number is expanded to unsigned 64bit, so $0000000080000000 is expected result. The same for L. Sorry, I do not see a bug here.

I did not understand, which of the values of C, L, M in your example is buggy?

Which of the examples above you think are bugs?

Yes, they are. But David said "And have two literals with different values."

You have: const F1 = 0.2; F2 = Single(0.2); writeln(F1); writeln(F2); 2.00000000000000E-0001 2.00000002980232E-0001

If we use {$R+}, both generate an error.

It is not consistent: Y: UInt32 = $123456789; // just a warning Z: Byte = 1000; // an error