Vandrovnik

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

Delphi's "Shifting a 1 63 places to the left in a 32-bit variable" is the same as "Shifting a 1 31 places to the left in a 32-bit variable", so you will get $80000000. In the example above, shifting is done in 64bit variable and the result $8000000000000000 is assigned to 32bit typed constant - lower 32bits are used (0) and a warning is generated.

Also note this in help: The operations x shl y and x shr y shift the value of x to the left or right by y bits, which (if x is an unsigned integer) is equivalent to multiplying or dividing x by 2^y; the result is of the same type as x. For example, if N stores the value 01101 (decimal 13), then N shl 1 returns 11010 (decimal 26). Note that the value of y is interpreted modulo the size of the type of x. Thus for example, if x is an integer, x shl 40 is interpreted as x shl 8 because an integer is 32 bits and 40 mod 32 is 8. So we have: const P: UInt32 = UInt32(1) shl 63; // contains 2147483648

In help, they write: "If constantExpression is a real, its type is Extended." I believe F1 and F2 are both extended. const F1 = 0.2; F2 = Single(0.2); writeln(F1); writeln(F2); 2.00000000000000E-0001 2.00000002980232E-0001 If F1 was comp, it could save only integer values.

But TDirectory.GetFiles (System.IOUtils) internally uses FindFirst/FindNext too...

When I had 10.2 and 10.3 on my PC and uninstalled 10.2 later, help in 10.3 stop working and must be reinstalled.

Have you tried to use lower resolution and turn the light on?

I have seen the same problem and have "solved" it this way: Kamera.Quality := FMX.Media.TVideoCaptureQuality.LowQuality; Kamera.Quality := FMX.Media.TVideoCaptureQuality.MediumQuality;

The declaration must be outside of the form...

Did you read, what Cristian Peța linked? function ShutdownBlockReasonCreate(hWnd: HWND; Reason: LPCWSTR): Bool; stdcall; external user32; function ShutdownBlockReasonDestroy(hWnd: HWND): Bool; stdcall; external user32;

I believe Anders is right. Class reference is just a pointer - its size is known. When you use this class as a member of another class (fChild: tChild, where tChild is a class), you cannot reference its members in properties (property x: integer read fChild.x). If fChild is a record (fChild: tChild, where tChild is a record), you can reference its members in properties, like in Anders' example (property x: integer read fChild.x).

If size was the only problem, I can imagine something like this ("human preprocessor"): type tRecordA = record of size 8; tRecordB = record ... function Test: tRecordA; end; tRecordA = record x, y: integer; end;