Dalija Prasnikar

5 hours ago, David Heffernan said:

I think start should pair with finish, begin pairs with end, from pairs with to, etc. Don't really like start paired with end. 

Interesting...  as non native English speaker, I guess I don't immediately see the difference. Above pairing generally makes sense.

In this case, from my perspective TrimBeginning is extremely awkward to write.

1 minute ago, David Heffernan said:

ofc, the naming of TrimRight is a bit of a slap in the face for Arabic speakers and other RTL languages!!! 

 

Should really be TrimEnd and TrimBeginning or something like that... 

Android API moved from such ambiguous methods and properties named left/right to start/end so following that rule it would be TrimEnd and TrimStart 

29 minutes ago, dummzeuch said:

These don't, but the girls do. "Frauenpower" as we say in Denglish.

 

(Hm, not sure whether this is sexist. If it is: Sorry ladies this is meant to be a joke.)

As long as we have power, all is good  

43 minutes ago, malobo said:

On average, it takes 10 to 12 seconds to open a form. My computer is an I7, 32Gb., 1TB SSD. 

You can also try disabling package cache, it helped in my case. 

You need to edit registry key HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Package Cache and then set the DisableAll value to 1. If it does not exist add new DWORD value with that name.

But 10-12 seconds is really long time. Maybe something else is in play. If disabling Live Bindings and package cache does not help I would recommend filing bug report at https://quality.embarcadero.com/

Locks of any kind used as field in a class are meant to protect integrity of the data inside object instance, not to protect that instance from being destroyed.

If you need to protect particular TMyClass instance itself, you will need to use some outer locking mechanism.

7 minutes ago, malobo said:

You are right. But I've wasted a lot of time trying to use this version and I can't waste much more. Which release can be the most similar to D2010?

The most similar would be Delphi XE, but that is not a long jump 🙂

Every new version has some features and some differences, and you will need to tweak some code to adjust in order to benefit from those features. The more recent version you use, the less future tweaking will be required.

From that perspective, probably the most stable recent version is Tokyo - 10.2.3. Rio - 10.3.3 is also quite usable, but it does have less stable debugger, and new IDE styling can cause performance issues on low end machines. All those versions have better support for using high DPI in your applications. If high DPI is not imperative for you, and you are less inclined to make huge jump, then XE7 is probably the most stable version in between. XE7 is also good option if your code uses class helper for gaining access to private class members, since that was removed in Berlin 10.1.

41 minutes ago, malobo said:

Absolutely agree. I just bought the license to continue some projects and getting paid was very easy. Now I am considering going down to D2010 to be able to work normally. It is a pity. I think the product is being loaded. And to top it all you have to swallow with everyone who is saying that it is very good and that it is very fast. I would like to know what they get ...

While 10.4.2 is a bit unstable (fortunately, my code does not choke it too often), going down to D2010 seems like overkill. There are many stable releases in between you can productively work with, and then move to 10.4.2 when patched. 

3 hours ago, Renate Schaaf said:

It isn't, the creation of the threads takes too long, in the end the procedure takes about twice the time of the unthreaded one. I would really hate to have to use the approach with waking up existing threads to do the resampling ...

 

I introduced the timeout, because the first time this happened, I had to kill the application.

OK, long timeout was a bit confusing and I could not determine how long each operation should last. 

Quote

I am right to assume then, that there isn't anything obviously wrong in my approach which would cause the timeout?

As far as I can see there are no obvious reasons why your approach fails with timeout. It is a bit longish code, so I am not excluding possibility of not catching error in code and possibility of some memory corruption, but that would commonly show much sooner. 

Using TTask and reusing threads through its thread pool is definitely faster and more correct approach comparing to creating anonymous threads. Anonymous threads was "fallback" suggestion in case your overall time spent in calculation is long enough so that creating thread overhead pays off.

If the TTask is really the issue here (which is also hard to say) another option would be trying some other library. One thing you probably can confirm, by using anonymous threads is that TTask is the culprit here (even though you can never say that with 100% certainty). 

22 minutes ago, Renate Schaaf said:

Good idea, but I'm doing zoom-pans, the fixed resizing I leave to the video-encoder to do.

I want to be reasonably sure that this runs on any system, not just mine .. Time to do some more stress tests 🙂

Since, your timeout is quite large, I suppose your requirement is not real-time resizing. In that case AnonymousThread approach can be good enough. I would also suggest using TTask wait without timeout, but 10 seconds is quite long time period, so it is quite possible there are other problems with TTask, and that using no timeout would just hang indefinitely (it might be worth trying, though). If the AnonymousThread approach is not good enough (creating and starting thread takes time - not much, but still) then creating reusable dedicated threads that would take care of resampling could be an option. But that is the most complicated approach, because you would need to communicate back and forth with such long running threads and pass data in and out as it finishes processing pieces of data. It is possible that there are libraries that have something you can reuse - the first place I would look for is OmniThreadLibrary https://github.com/gabr42/OmniThreadLibrary

Without going into the why you are getting timeout, could be the issue @Vandrovnik mentioned, could be something else. Depends on your machine, number of cores, system activity too. 

But, if you are resampling video frames, that suggests that you are resizing same sized frames to same output size. In that case, calculating contributor weights for each frame again is huge waste. Calculate that once, and then just reuse it.

1 hour ago, Lars Fosdal said:

To add insult to injury, I also caught the SARS-Cov-2 English mutation around March 16th, but I was lucky and got a very light progression, almost like a mild flu - but with an unusual amount of fatigue.

Ouch.... I wish you full recovery.... I would also say speedy, but you don't recover fast from that thingy.... I also had mild symptoms (I had way worse flu infections), but fatigue is beyond extreme... I literally slept for a month.

1 hour ago, Lars Fosdal said:

I highly recommend NOT contracting this shit!
Keep your distance, wear that mask, wash those hands - and get vaccinated.

Absolutely. It is quite bad experience even with mild symptoms.

9 hours ago, emailx45 said:

@Remy Lebeau

read help about 

xxxx.HandleAllocated

read the post ... 

I suggest that you read once again what @Remy Lebeau posted. You example is horrible and no amount of dancing around it will ever make it work properly. 

When you run it, and it works... that will only be an illusion caused by undefined behavior and a touch of luck.

8 minutes ago, Remy Lebeau said:

This is only dangerous if the code is using BOTH Action=caFree with Free() together, which makes no sense to do.  Use only one or the other, not both.

 

And that is exactly the situation OP has encountered here. I guess you missed that part.

On 2/16/2021 at 4:20 AM, Ian Branch said:

MyForm := TMyForm.Create(self);

try

with MyForm do

begin

...

....

....

end;

finally

MyForm.Free;

end;

 

in MyForm I have..

 

...

...

procedure TMyForm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action := caFree;
end;

 

 

Is this construct OK?

No. It is not OK. You are trying to release the form twice.  Once explicitly by calling Free and once by setting on close Action to caFree.

This may work under some circumstances, like @balabuev mentioned caFree triggers posting CM_RELEASE message to the form window handle. If there is no code that will pump the message queue (like Application.ProcessMessages) between the time OnFormClose is called and your explicit call to Free, then calling Free will actually destroy the form and along with it its window handle and message posted to that handle will be discarded because window no longer exists.

However, if CM_RELEASE message is processed and handled before your explicit Free call, form will already be destroyed at the point you call Free and hence the error you are seeing (presumably from EurekaLog)

On 2/16/2021 at 4:20 AM, Ian Branch said:

Suddenly, I am starting to get 'EUseAfterFreeError's indicating the MyForm.Free;

My immediate thought is that the .free from the calling form is not finding something to Free because the called form has already done a caFree.

If this is the case, why has it just started?

Because you have added some other code in between that is calling Application.ProcessMessages.

You have to choose one option. Either you will use caFree or you will use Free. Using both and hoping for the best is not good option even if it works, because it can be easily broken, which you now have first hand experience.

If you need to retrieve some value from the form after it is closed, then you shouldn't use caFree anyway because you may access dead form - again depending on the other surrounding code. Another reason to explicitly Free form is that this makes memory management more obvious. You create form, do something with it, and then you release it.

1 hour ago, TrevorS said:

I have a project that runs in OSX only,  Just moving it to Delphi 10.4.1 (I've seen the occasional memory exception when I close [Order Detail] - but I can't recreate it)

ShowModal is not supported on Android and it is not recommended on iOS, and if you trust documentations it should be safe to use on macOS. Issue is most likely caused by some other code, not your general form handling code that you have here. 

http://docwiki.embarcadero.com/Libraries/Sydney/en/FMX.Forms.TCommonCustomForm.ShowModal

1 hour ago, TrevorS said:

Is the nil/freeandnil the best way to deal with nested modal forms in a Firemonkey/OSX? All of the [forms] are modal and are created / freed in the same way.

Your form handling is mostly correct. I would remove SaveFormPos from finally block because if something goes wrong you most likely don't want to save your form position. Also, if SaveFormPos can raise an exception, you will leak the form because FreeAndNil will not be called in that case. Also I would put f.var assignment inside try... block, because if that assignment raises and exception you will also leak form. And since form variable f is local variable and it is going out of scope right after you are releasing it, there is very little point in calling FreeAndNil, simple f.Free is enough.

Generally, books are the best resource for learning any language. More experienced developers can usually get they way around new language faster, so official documentation might suffice.

Anyway, Delphi Language Guide is always a good place to start http://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_Language_Guide_Index

4 minutes ago, Fr0sT.Brutal said:

Is there a trouble with DUnitX? CB consumes Delphi code AFAIK.

CB can use most of the Delphi code, but not all.

1 hour ago, Stefan Glienke said:

I doubt - google benchmark is a little more than "run this stuff in a loop and time it with a stopwatch" 😉

Yeah... but making a wrapper around C++ lib.... 

18 hours ago, Stefan Glienke said:

I wish someone with some C++ knowledge would write a Delphi wrapper for Google Benchmark

It would probably be easier to write the whole thing from scratch in Delphi.

17 hours ago, Attila Kovacs said:

I need some clarifications here too, as I'm not using timers anywhere, maybe my 3rd parties does, I don't know, but what is "wrong time" for a timer?

I can't remember having seen a property like OnWrongTime or OnRightTime.

Is it possible that you are referring here to "wrong code" instead?

I meant wrong time. Let me explain.

procedure TMainForm.OnTimer(Sender: TObject);
begin
  ChangeFooBarForkState;
end;

procedure TMainForm.BtnClick1(Sender: TObject);
begin
  DoFoo;
  DoBar;
  DoFork;
end;

procedure TMainForm.BtnClick2(Sender: TObject);
begin
  DoFoo;
  Application.ProcessMessages;
  DoBar;
  Application.ProcessMessages;
  DoFork;
end;

Let's say that DoFoo, DoBar and DoFork depend on some state that is changed on timer with ChangeFooBarForkState and if you call DoFoo, DoBar and DoFork in sequence with different state you will get wrong result.

In BtnClick1 without ProcessMessages, those procedures will run serially without interruption and with consistent state, because OnTimer event cannnot run in the middle, but in BtnClick2 timer can be triggered and can mess up that state.

Now, this is a bit contrived example and you can say that you can fix such code to work properly with timer, but the point is that just like thread safety can sometimes be tricky because code may work properly most of the time, ProcessMessages can also be tricky to do right because you have to think about all the potential messages that can be processed and it can be easy to overlook some and you may have random bad behavior that is hard to reproduce. 

Now, this timer example is based on real life scenario someone had somewhere, where Application.ProcessMessages was the problem, I just don't remember where I read about it or what was exact code in question.

21 minutes ago, Alex Texera said:

Tnx for answer, I don't have login credentials for your link.    Are you developing FMX application, what stay in your sdk path in rad studio (Android-28, 29, 30)?  

I currently have API 29, but I am testing Delphi Android applications only on Android 7.0 device.

I am not actively developing on Android with Delphi. When I started Delphi for Android was not suitable for my use case and didn't have support for devices I needed, so I had to use Android Studio.

6 minutes ago, Fr0sT.Brutal said:

What's wrong with timers in this situation?

Modal dialog will prevent user triggering actions, but it will not prevent triggering timers (if you have one) from causing possible unintended actions running at wrong time.

Upgrading the SDK opens possibility for incompatibilities.

Applications with lower SDK version run in compatibility mode on newer versions of the OS. When you increase SDK version you are basically saying this application supports all new OS APIs. If your application (that includes RTL and FXM) does not support all new APIs it can crash or malfunction.

See: https://quality.embarcadero.com/browse/RSP-27218

This issue has been resolved in 10.4 Sydney and Android 11 is now officially supported by Delphi. I am not sure if there are any other issues.

9 minutes ago, Attila Kovacs said:

You can't just pick a piece of code and put it in the background thread. You can do it with some code, but not every time.

When I said put your code in background thread, I didn't mean literally like run exactly the same code in background thread. But for any code that runs long, Application.ProcessMessages is always the wrong solution. It may be quick fix at some point, but it is still a wrong solution.

First step in writing better code is acknowledging that Application.ProcessMessages is wrong solution. Then and only then one can start going in different direction and start learning and applying better solutions. It can be long process, depending on the existing code you (I don't literally mean you) already have. But the sooner you start, the less work you will have in the future when you start removing Application.ProcessMessages. 

If you never start doing that, sooner or later you will encounter code where Application.ProcessMessages will not work as intended and you will not be able to make UI fully responsive when using it. Learning how to use background threads at that point - when you cannot properly take time to experiment and learn will only make it harder.   

9 minutes ago, Attila Kovacs said:

No, you can't do that. You can do it in some cases, but not every time.

It depends, but certainly more often than with Application.ProcessMessages approach.

5 minutes ago, Fr0sT.Brutal said:

Showing a non-closable modal form eliminates such issues

Yes, it does. Until some timer throws you a curved ball.

Yes, it is possible to polish Application.ProcessMessages approach and solve reentrancy issues around it. That still makes it a poor solution because you still have other problems I mentioned before.