Skip to main content

dITo: do IT ourself: [n/a] C/S auto-search while typing experiences C/S

  • November 19, 2018
  • 10 replies
  • 0 views
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

10 replies

Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Have you tried using the UTIMER in Uniface9. Then you will probably not have to search for every keypress......
Just an idea, probably not the right way to go......

 Regards RogerW.

 


Author: rogerw (roger.wallin@abilita.fi)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Hi Roger,

if you see some implementations in Windows, their only heartbeat is the typing of the user.

As I said: this is the essence from different attempts to implement this features in classic C/S.
And in 1996, I think we had no non-blocking UTIMER implementation available.

I know that in more advanced widgets as we have/had in uniface C/S, you can set a "delay".
Autosearch will only take place if the user stops typing for this amount of time.

Success, Uli

P.S. I do not want to implement this feature, just retweet experiences from the past.


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Hi Uli,

I would like to implement it.
It would be nice to hear about working solutions with Uniface.

Regards RogerW.

 


Author: rogerw (roger.wallin@abilita.fi)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Hi Roger,

here is some code as a start for you:

Success, Uli

 

Hi Kevin,

here is a (7.2.04) *.pro using
the editfield fedit and
the Listbox fListbox populated with the associative list
Albert=Albert<;>Alfons=Alfons<;>Bart=Bart

Success, Uli

Trigger <LPMX> from Form: A_AUTOCOMPLETE

****** entry lp_AutoCopy
1 if (fListbox != "")
2-1 fEdit = fListbox
3-1 message/info "Copy done"
4-1 endif
5 end ; lp_AutoCopy
****** entry lp_AutoPosition
1 variables
2 string v_valrep, v_temp, v_edit, v_positem
3 numeric n_position
4 endvariables
5 message/hint "Autoposition for %%fEdit%%%"
6 getitem/id v_temp,$valrep(fLISTBOX),v_edit
7 if ($status > 0) ; hit
8-1 fListbox = v_temp
9-1 return(0)
10-1 else
11-1 v_positem = ""
12-1 v_valrep = $valrep(fListbox)
13-1 uppercase (v_valrep,v_valrep)
14-1 uppercase (fEdit,v_edit)
15-1 putitem v_valrep,-1,"%%v_edit%%%=%%v_edit%%%"
16-1 sort/list v_valrep
17-1 getitem/id v_temp,v_valrep,v_edit
18-1 getitem v_positem,$valrep(fLISTBOX),$status
19-1 if (v_positem = "")
20-2 getitem v_positem,$valrep(fLISTBOX),-1
21-2 endif
22-1 endif
23 fListbox = IDPART(v_positem)
24 return(0)
25 end ; lp_AutoPosition

Trigger <DTLF> from Field: FEDIT.DUMMY.DUMMY

****** Y40::
1 call LP_AUTOCOPY

Trigger <SMOD> from Field: FEDIT.DUMMY.DUMMY

****** Y45::
1 call do_macro
2 return(99)
****** entry do_macro
1 macro "^next^field^previous^field^last_text"

Trigger <VALC> from Field: FEDIT.DUMMY.DUMMY

****** Y53::
1 call LP_AUTOPOSITION


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

... or go to the uniface listserver at

http://groups.google.com/group/comp.soft-sys.app-builder.uniface

and search for keystroke.

You will learn that the V7 COMBOBOX was recommended for suporting the desired functionality.

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

An old skool C/S exemple: http://www.tonymarston.net/uniface/tip41.html

In my experience database search performance issues are less of an issue when you oblige the user to type in a minimum of two to three characters before starting the search.

Regards, Arjen


Author: Arjen van Vliet (arjen.van.vliet@uniface.com)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Hi Arjen,

Good old Tony Marston,
a real pitty that we lost him to RADICORE.

Thanks for finding this example, I knew it exists but I had forgotten where I saw it.

The beauty of this example is the use of LOOKUP which delivers only hits, but no data.
This boosts the "retrieve" time, but demands the retrieved entity to be the topmost in the component.

Returns only a single record, but with a nice performance.

So we have implementation alternative 3

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Hi Arjen,

Forcing the user to type in at least 3 characters leaves all entries with 1 or 2 characters hidden.
Don't think this should become a fixed limit.

I have not tested it, but assume since we have maxhits, the real volume of matches in the database
should not influence the performance so much as before.

Looks good for some type of benchmark against different database(driver)s.

Success, Uli

Syntax

read{/lock} %\\

{using Index | options "{index= n} }{ ; maxhits= n }{ ; cache= n | ALL }{ ; step= n "} }%\\

{u_where (SelectionCriteria) | where DMLStatement | u_condition (Condition)} %\\

{order by OrderBySpecs}


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Performance is not always an issue.

I have a customer who wants to use this to select a value from a (long) dropdownlist,

so all possible values are already in memory.

My problem now is that I have to use a UNIFIELD in an otherwise modern GUI (combined with a listbox).

I really would like to have widget (dropdown or combobox like thing) that does it, instead of just jumping to the first letter typed.


Author: Theo Neeskens (tneeskens@itblockz.nl)
Jan Cees Boogaard

[n/a] C/S auto-search while typing experiences C/S

Author: ulrichmerkel@web.de (ulrich-merkel)

- The user types something in a textfield
- while typing, he will get a list of matching datasets

For a couple of years (AFAIK from 1996), developers on the uniface C/S front tried to implement:
To monitor the input, one has to "persuade" the SMOD to fire on each keystroke which is not too hard to do.
Each time the user stroke a key (no cursor movements,  are ) a new retrieve was sent to the database.
limiting factor(s): how long takes each retrieve
It was  found in the old days, the usability killer is the performance of retrieving the database.
 

Especially at the beginning of the text, user suffer from "type ahead":
He typed "ABC", but the application displayed only his "A", after a while, "AB" is shown and finally "ABC"
Assuming each retrieve takes a second it takes 3 seconds before he sees what he typed in 0.2 seconds.

 

Alternative to avoid all the retrieves: fetch all data at first and then position:

- create a new record with a PK of the textfield
- retrieve/o - if you are lucky, a record exists with this PK and is activated and you RETURN
+ otherwise we have to position to a "next likely" record
- sort the complete entity in PK order
- create a new record with a PK of the textfield, just to find the new created record
- retrieve/o - now you are positioned in the list
- remocc/e to get rid of this helper and keep position
- (perhaps advance to the next position)
limiting factor(s): bringing all records in memory takes time, how fast is the sort?

In most cases, this functionality had not reached the eye of the end-user.

Success, Uli

Hi Theo,

I cant agree with you: performance is always an issue.

on the other one:

I am sure there is a widget outside with all the functionality we can include via OCX.

As an example, see: http://www.codeproject.com/KB/winsdk/Win32AutoCompleteComboBox.aspx

Success, Uli


Author: ulrich-merkel (ulrichmerkel@web.de)

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement