Vandrovnik

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

20 minutes ago, Mike Torrettinni said:

Perhaps inline directive generates even less performant code in earlier Delphi versions. Not sure when it was released first.

Directive inline existed already in Borland Pascal.

3 hours ago, Javier Tarí said:

When I tried it, many years ago, the implementation was awful: it loaded the whole table in memory

A joke instead of a tool

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).

26 minutes ago, A.M. Hoornweg said:

Which brings us back to the solution I proposed originally. Ensure that the compressed data is valid (with another checksum) before trying to feed it to the decompressor.

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.

38 minutes ago, Anders Melander said:

... the ZLib decompressor can assume that it's being given valid data and only uses its own checksum to verify that it is producing the correct output.

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...

24 minutes ago, Fritzew said:

You have never worked with C++ ?
I don't think we will see it before a CE

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]
                 ^

    

19 minutes ago, Anders Melander said:

That won't work. You need to start at zero.

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

6 hours ago, Anders Melander said:

 

Funny name you say? How about he optimize it with Gnome sort instead:

 

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...

24 minutes ago, aehimself said:

http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/expressions_xml.html

"Note: If either operand involves a Variant, the compiler always performs complete evaluation (even in the {$B} state)."

 

It's a feature.

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.

30 minutes ago, aehimself said:

I pushed Opens to a background thread and the UI froze at the first .RecordCount call. The solution was to add .Fetch after .Open in the worker, and the scrollbar still had only 3 positions.

I manually had to handle the WM_SCROLL message and had a custom UpdateScrollBar which called SetScrollInfo. Some of this code might be obsolete already if DBGrid got an update since 10-10.1... never really checked.

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.

9 hours ago, aehimself said:

P.s.: my favorite "feature" is that the vertical progress bar had 3 positions: first record is active: topmost. Last record is active: downmost. Everything else inbetween - progress bar is at 50%. I seen no other component with this "design" yet.

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

5 minutes ago, Mike Torrettinni said:

With:

function CompleteEval(const aBooleanValues: array of Boolean): Boolean;
var i: Integer;
begin
  Result := false;
  for i := Low(aBooleanValues) to High(aBooleanValues) do
    if aBooleanValues[i] then
      Result := True;
end;

Right?

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;

45 minutes ago, Mike Torrettinni said:

How would that work to retain Result value, if True?

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

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).

14 minutes ago, johnnydp said:

...

When I first heard many years ago about FMX and  mobile, I just knew it that it going just nowhere.

Delphi should stay mainly (and only) Windows desktop development tool (without mobile devices support)

...

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...