Recent

Author Topic: Application.QueueAsyncCall with variant parameter  (Read 2495 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Application.QueueAsyncCall with variant parameter
« on: April 05, 2015, 07:41:56 pm »
http://bugs.freepascal.org/view.php?id=27788

First of all, I am not suggesting pro or contra an the request. Just got curious...

@Denis:

Why do you not store the data on a field in the current object?

Code: [Select]
  TMyObject = class
  private
    FDoAsyncData: String;
    procedure DoAsync(Data: PtrInt);
  public
    procedure Foo;
  end;


procedure TMyObject.DoAsync(Data: PtrInt);
begin
  if FDoAsyncData = '' then ;
end;

procedure TMyObject.Foo(: TObject);
begin
  FDoAsyncData := 'SomeThing'
  Application.QueueAsyncCall(@DoAsync, 0);
end;

If DoAsync is on  another object then store the data there.

MageSlayer

  • New Member
  • *
  • Posts: 10
Re: Application.QueueAsyncCall with variant parameter
« Reply #1 on: April 05, 2015, 09:42:31 pm »
I am sending a bunch of async calls (specifically dynamically inserting/removing several GUI controls), so it will be necessary to keep something like a list of things to do.

So why invent another list if async already contains a queue quite suitable for that?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9791
  • Debugger - SynEdit - and more
    • wiki
Re: Application.QueueAsyncCall with variant parameter
« Reply #2 on: April 05, 2015, 11:09:06 pm »
Well as for me: Just curiosity. I used QueueAsynCall before, and never came across such need.

But then that is because in a case like this, I would queue only one call, and have a list for that call, to which I can add at any time. Once the call was done, I queue the next.

Of course that would simply be my approach. That does not say it is better or worse, than having many async calls.

Actually it may have one advantage. If you queue 1000 async calls, afaik they will run all in one single block. There is no other processing in between. Your app, may become none reactive for a moment.
If I have just one call, then I can specify to process only the first x (e.g. 50) items, or process until 100 milliseconds have passed, and schedule a new async call for the next round (after events were processed again)

If your code is not time critical, or not going to reach such extends, then it does not matter.


-----------------------
As for the feature request, the code in question is not maintained by me, so I am not going to make the decision on it.

But in cases like his, the question (IMHO) always is, if the problem that is being solved is generic enough to justify the added maintenance.

That is, I do NOT say, that your code burdens a lot of maintenance on the current implementation of AsyncCalls. But if, or if not is something I will not be deciding.

 

TinyPortal © 2005-2018