Search in the "TMS Music Demo"

[Olsen_Leif_Eirik]

Hi,

In the "Music Demo" that comes with TMS Web Core there is this Search field in the upper right corner in all *.List forms. This works just as expected, it searches after every key stroke and displays found records just fine.

But if I, in Delphi, start a new project of type TMS XData Web Application, that I guess produces a similar application as the "Music Demo", I have an issue when using my own xData Rest server.

For one entity (Product), there are just over 2000 records. If I use the Search field and type search criteria ('Felt') slowly everything works fine.

First ex: Type search criteria "Felt" slowly and all is good

On the other hand if I type the same search criteria ('Felt') fast: The grid in the web page displays incorrect records and freezes up:

Second ex: Type search criteria "Felt" fast and grid displays wrong records and freezes up.

On the rest server side I can see 4 GET's, one for each character in the search. Do even fast typing is handled just fine by my server.

On the web client side you might be aware of the "only" code per search is this:

procedure TFViewProductList.edSearchChange(Sender: TObject);
begin
  FGridPlugin.SetFilterText(edSearch.Text, True);
end;

I understand that the "Music Demo" is just that...a demo. But I'd still like to understand why my search freezes the grid like above described.
Any hints and/or tips appreciated.

[wlandgraf (Wagner Landgraf)]

Hi @Olsen_Leif_Eirik,

@Olsen_Leif_Eirik

I understand that the "Music Demo" is just that...a demo. But I'd still like to understand why my search freezes the grid like above described.

For each key pressed, a new request to the server is spawned to retrieve the filtered data, as you have noticed yourself in the browser.

So when you type several keys, several requests are performed. But note such requests are asynchronous.

Thus, my initial guess is that as you type too fast, all the requests are spawned almost together, and then they are not completed in the correct order.

For a production application, I'd do a better handling of the filter edit in a way that it doesn't fire a request each time a key is pressed, but instead, only when the user stops typing for a while - or, when the user explicitly types Enter key or click a "Search" button.