Vandrovnik

Do you use IDE Fix Pack? On my PC, it was causing this trouble.

No; problem is, that in the example above there is type "CommandType" and property "CommandType", so CommandType.NA is trying to reference property CommandType, which does not have member called NA.

What about scoped enums? http://docwiki.embarcadero.com/RADStudio/Sydney/en/Scoped_Enums_(Delphi)

This code is a problem when used in 64-bit version...

Could you just allocate some memory (1-2 GB, probably in smaller chunks), so that other allocations have to be from the top part?

Directive inline existed already in Borland Pascal.

I do not use tIBTable at all, so I do not mind. I use mostly tIBDataSet, tIBQuery, tIBSql... tIBDataSet has property UniDirectional, which disables storing visited records in memory.

IBX components also have a tIBTable. I did this migration in one-step (Paradox -> tIBDataSet/tIBQuery).

I still believe that decompressor with wrong input should not enter an endless loop. If you have 2 bytes checksum, you still have a 1 : 65536 probability, that it will not detect wrong input. With 4 bytes checksum, it is 1 : 256^4, much better, but still not 100 % safe.

I think decompressor should somehow handle wrong data too (raise an exception, for example). I have used "ZDecompressStream" and on wrong data, it stays in endless loop (tested on Android 32 bit). I have not tested whether it happens with all wrong data, or if I just was lucky and tested it with something special...

I hope that "CE" is not "civilization end" 🙂

Test is not changed, just at the beginning instead of i:=0 I would use i:=1; When I start with i:=1 with Data 3, 2, 1, it is as in your example, just first iteration is already done: iteration elements 0 3 2 1 swap and dec ^ 1 2 3 1 i=0: inc ^ ... If Data is 1, 2, 3, it is: iteration elements 0 1 2 3 inc, because List[1] >= List[0] ^ 1 1 2 3 inc, because List[2] >= List[1] ^

I cannot see why? In first step, "if (i=0) ..." will execute "inc(i)", so we have i=1 and continue with next iteration... while (i < List.Count-1) do if (i = 0) or (List[i] >= List[i-1]) then Inc(i) else

OK, and when it should work faster, we can always optimize it with starting at i:=1 and using tList<>.Exchange 🙂

CreateMutex(nil, false, 'YourNameOfTheMutex'); Test return value. https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-createmutexa This does not work?

I would start checking your computer, for example with ESET: https://www.eset.com/me/home/online-scanner/

Disabling Welcome Page is on my check list for Delphi installation 🙂

I tried another approach: - manualy set targetSdkVersion to 29, published app in Google Play. - now I have created an update with targetSdkVersion set to 28 and submitted to Google Play - it displayed a warning, but files were accepted. It seems that till November 2nd 2020, updates with targetSdkVersion=28 are accepted: https://developer.android.com/distribute/best-practices/develop/target-sdk - after November 2nd 2020, I hope Delphi 10.4.1 will be mature enough, so that I can start using it.

And what about Embarcadero - they could make a patch for 10.3.3, so that each of us does not have to solve it by himself...

Does anybody know, why is this "feature" present?

The correct name of method is ".FetchAll", sorry for the mistake. I have also edited prior posts with it.

Hmm, I use IBX for data access and it works for me. If .FetchAll is not called and user presses key "End" in the DBGrid, scroll bar also starts working as expected. The same behaviour in DBLookupComboBox.

Only when number of records is not known (so for small datasets you can call FetchAll and scroll bar works as expected).

Yes, I just would change it a little, so that it can work a bit faster: function CompleteEval(const aBooleanValues: array of Boolean): Boolean; var i: Integer; begin for i := Low(aBooleanValues) to High(aBooleanValues) do if aBooleanValues[i] then begin Result := True; exit; end; Result := false; end;

result:=CompleteEval([result, A, B, C]);