'Events' Quiry

[J-G]

Nothing for months and now I find I need help two days running 

It's more a question of how to stop and event that I didn't expect to be triggered rather than a failing process.

In this Auto DB program, I need to provide a 'search' as well as a [Next] / [Prev] option. Both (all three) are working but I was surprised to find that the 'Search' code is triggered when [Next] or [Prev] are requested.

For [Next] & [Prev] I'm using the 'On Click' event of TArrow and they work exactly as anticipated but now I've added the 'Search' by utilising the 'On Exit' event of a TEdit when debugging I see that the TArrow event calls the TEdit event procedure.

The end result is that the next (or prev) records are shown correctly but naturally I suspect that the time taken to 'search' will ultimately be significant. On my system its indecernable but the target system will be very much slower so this may be significant.

Is this behavour 'normal' - and therefore unavoidable - or should I be doing something different?

[Martin_fr]

Technically it should probably be OnEditDone, rather than OnExit. Since a user can press enter in the search edit, which probably would not call OnExit. But not tested.

OnEditDone might be triggered earlier. So it could worsen your issue.

Only idea I have is, that when the search is triggered (OnEditDone/OnExit) call QueueAsyncCall. If then the Next/Prev or similar button receive a click, they can cancel the async call, and no search will be done.

[J-G]

Thanks Martin  -  Of course you are correct I AM using OnEditingDone - not OnExit -  I have to blame the aging grey-matter !

I assume that I'd call QueueAsyncCall at the start of the 'Search' Proc. and if the next item in the queue is a  [Next] or [Prev] I'd simply [Exit] the search?

Since I've not come across QueueAsyncCall previously, I'm not at all sure quite how to proceed - even as a test 

[Martin_fr]

The OnEditDone would do 2 things.
1) check if there already is next or prev in process (set a flag in those events). This is in case the next event is triggered first.

2) Application.QueueAsyncCall(@self.DoPerformSEarch, 0); // 0 does not matter

---
The OnNext/Prev would
- set the flag
- Application.RemoveAsyncCalls(self) // all for that object / you may create a separate object for that

----
The DoPerformSearch would call the actual search for the database.

------------
async call is similar to OnIdle. But it is called even if not idle. It is called as soon as the current events are processed.

[J-G]

Again, I am indebted to you Martin, thanks.

I've now tested the program on the target PC and although it is 'S l o o o o w'  starting up; the program runs at an acceptable speed - certainly finding the [Next] or [Prev] Record in less than the blink of an eye     

I will however now investigate the QueueAsyncCall using your very detailed and succinct instructions  -  I THINK I understand them !

The only thing that I notice currently is that I can't ask for [Prev] when at the first record - my 'normal' method here is to simply select the 'Last' but it seems that the 'search' gets in the way  -  so it would be a benefit to circumvent it.

[Martin_fr]

The only thing that I notice currently is that I can't ask for [Prev] when at the first record - my 'normal' method here is to simply select the 'Last' but it seems that the 'search' gets in the way  -  so it would be a benefit to circumvent it.

That is something you should be able to do in your various OnButtonPress / OnEditDone.  Unless you have some db aware controls that directly trigger, and don't give you events.

In the Next/Prev you can
- cancel any async pending search
- decide where to go
- set a flag to prevent any search (if the event comes later / depends on order / may depend on WS)

The flag should be cleared when the data arrives.

But that means that while you wait for the result of next/prev then you can't start a search aborting next/prev.
That would only be important if next/prev could also be so slow, that a user has time to change their mind, abandon them and start a search.

For that you could schedule another async event to clear the flag.
You would then have (only some of, but in this order)
- EditDone => go async
- NextPressed => flag && exec-next && clear async && go async to clear flag
- [maybe late EditDone] => stopped by flag
- async from EditDone:  do search
- async from Next: clear flag
- app goes idle (user could start a search now / if that is actually wanted?)
- data is received (alternative place to clear flag / but if something goes wrong and data is not received....)

Then again: once a db query was started  (e.g. next is running), you don't want user input, until this is finished.

Because, once it has been sent to the db, the db will run it and finish it. If the user starts a 2nd action, the db will have 2 actions running (and the app only uses the last result / hopefully).

On a fast PC, the db can still finish faster running them in parallel. But on a slow PC, that may just stack up, and give the user time to schedule more and more queries.

So ideally, when you have any of the EditDone/ButtonPress you would disable all buttons, and only enable them when the result comes in.
Of course if EditDone disables the buttons, then NextPressed is encountered and cancels it, and NextPressed decides that the end is reached and no action should happen, then it must also re-enable the buttons.

Other designs would be to leave the buttons enabled, but don't send further next, while already running, collect them, and then (if avail) go forward by the total count. But that is complicated. Probably not worth it.

[J-G]

Again a very fullsome responce Martin  -  and I'm sure someone will find it useful 

Though not afraid to test new ideas, I am on a strict "don't spend too much time (money) on this"  the 'Customer' / Friend is pretty much retired so is not reliant upon getting this historic data to provide an income.

With this in mind I have found a quick (maybe 'dirty') method of getting the [Prev] button to select the final record when going backwards at the start - - - - -  I've jumped over record 0   

I did look at making the search 'Target' [Nul]   ie. '',  but that wasn't effective. I just so happens that Record Zero is blank anyway - this is historic and was initially intended to be used for another purpose but it has proved to be useful in this respect.

Your idea of setting a 'Flag' in [Next]/[Prev] was interesting and I did create a [NoSearch] boolean which I set to false in N/P and then checked at the start of the search Proc. but the N/P events obviously hadn't been triggered prior to the Search.

Although I no longer read the Lazarus Forums on a regular daily basis, I'm immensely grateful that it exists and I see many 'old friends' (Lainz, Jamie, Mark, yourself . . . ) still posting and providing assistance.