next »

[Stefan S.]

Hello List,

Is there a possibility to have an autocomplete during the input of an field.

f.e.:
I enter the Name of a customer "Sch"
and in a Clipbox  I can see all Names beginning with Sch (Schmitz, Schulz, Schmidt, ...) saved in the Database.

Any Idea ?

Stefan Serwe

[Reuben B.]

My understanding it is more of a GDC/GWC issue defining an appropriate widget.

With what we have currently you can do something like ...

Code

DIALOG ATTRIBUTES(UNBUFFERED)
   INPUT BY NAME field
 
   DISPLAY ARRAY list TO list.*
 
   ON ACTION dialogtouched
      -- whenever the value of field changes, alter the items displayed in the array
      IF FGL_DIALOG_GETFIELDNAME() = "field" THEN
         CALL populate_array_based_on_what_is_entered(FGL_DIALOG_GETBUFFER())
      END IF

however I suspect you want the items to appear below the current field in a drop-down list, rather than in an array off to the side.

[Reuben B.]

I should also point out that there is an entry in our system to add a widget to do this...

Bz15839 - Provide a new EDIT widget with dynamic selection list

... I'll add Stefan to the list.  If there is anyone else looking for the same functionality the more requesters the more chance it gets looked at.

I have attached two sample programs where in the past I had attempted to get the same functionality.  One using the technique I mentioned previously, the second attempt using a QUERYEDITABLE COMBOBOX in a CONSTRUCT to populate a variable.  You maybe able to improve them to get something close to what you want. 

[Snorri B.]

I'm all in for a widget like that!
Regards,
-Snorri

[Reuben B.]

My understanding it is more of a GDC/GWC issue defining an appropriate widget.

...

Before I alienate the GDC/GWC teams and never have them implement anything for me ever again, to do this properly there is probably some changes needed in the communication protocols.

The 4gl examples I posted had approx 200 rows so inbetween keystrokes the round-trip time to send the keystroke via ON ACTION dialogtouched, determine, and send back the list of entries to populate the list is neglible.

Now imagine if the number of potential rows in the drop-down list was measured in ten and hundreds of thousands, say all the customer names from the database.

Typing in S may return 10,000 rows, typing in SC may return 1000 rows,  typing in returns SCH 100 rows.  So in the time between typing S and C, is the system able to go back, determine the 1000 rows and return them to the front-end, and do you really want to return 1000 rows.   We probably want to have the equivalent of ON FILL BUFFER for the drop-down.  Any other thoughts on how that process could be implemented welcome.

So it is not necessarily as simple as implementing a widget or variation of an existing widget.

Reuben

[Paul S.]

Add me to the list.

Question, should we use this forum for feature requests?

Paul

[Tim S.]

Count me in for widget like that also.

Tim S

[Reuben B.]

Add me to the list.

Question, should we use this forum for feature requests?

Paul

From https://4js.com/fjs_forum/index.php?topic=7.0

The Four J's Technical Forum is for:


Product Announcements.
A discussion with BDL (Genero or BDS)  programmers about :

 Features, tips and tricks in BDL programming.
  Hints on how to implement specific application features.
  Guides on deployment methods.
  Web, SSH & SSL questions and tips etc.

But NOT For:

Post requests for support.
Chasing product problem fixes.

If you do have a feature request, I'd suggest the following...

Describe the business problem first - someone may have had a similar problem and found a solution using an approach you haven't thought of.   

Offer suggested syntax -

Remember our targets - we have to make sure that whatever we implement works on all the platforms we support.  With the back-ends and databases this isn't normally an issue, but with the front-end remember that ideally it has to work in both GDC and GWC.

Vote - There is a saying I'm fond of, "The barking dog gets the biscuit".  The more people we know are after a certain feature, the more closely it will be looked at.

Timing - Note the timings of our release cycle.  It is extremely unlikely that any new request today will make it into 2.30.  Also participate in the EAP, it maybe that a slight tweak in a new feature gives you the functionality you are after.

Bz number - Like bugs make sure you get a Bz number.  That tells you it is in the system.  Doesn't necessarily mean it will get implemented but it will get relooked at from time to time.

[Leo S.]

My understanding it is more of a GDC/GWC issue defining an appropriate widget.

...

Before I alienate the GDC/GWC teams and never have them implement anything for me ever again, to do this properly there is probably some changes needed in the communication protocols.

The 4gl examples I posted had approx 200 rows so inbetween keystrokes the round-trip time to send the keystroke via ON ACTION dialogtouched, determine, and send back the list of entries to populate the list is neglible.

Now imagine if the number of potential rows in the drop-down list was measured in ten and hundreds of thousands, say all the customer names from the database.

Typing in S may return 10,000 rows, typing in SC may return 1000 rows,  typing in returns SCH 100 rows.  So in the time between typing S and C, is the system able to go back, determine the 1000 rows and return them to the front-end, and do you really want to return 1000 rows.   We probably want to have the equivalent of ON FILL BUFFER for the drop-down.  Any other thoughts on how that process could be implemented welcome.

So it is not necessarily as simple as implementing a widget or variation of an existing widget.

Reuben

Hi Reuben, we have 1 kinda autocompleting widget:combobox.
The current behavior is that you can type ahead blindly and land hopefully on the right item
(it works as in Explorer or Mac Finder)
We could add a new mode/attribute/style which shows you what is typed and reduce the list to choose from.
So everything needed for a smaller list (<=50-100 items) without asking back the server is at the client side.
To crawl thru large data sets while typing for sure we need a more intelligent mechanism.
Something like ON FILL BUFFER as you said.
Kind Regards , Leo

[Bryce S.]

We would really like this feature. We currently have the New Zealand postal address database loaded - as a user types in an address it would be great if they see their valid address displayed and pick it.

As for speed, if on Informix database at least, one can set the optimization.
I just created a test program and tried it out.  On the first letter entered database wants to bring back tens of thousands of rows, but optimization gets around that like:

on action dialogtouched
  IF FGL_DIALOG_GETFIELDNAME() = 'text1' THEN
     execute immediate "set optimization first_rows"
     let str = FGL_DIALOG_GETBUFFER()
     # etc load cursor array - display....   then set optimization back to default
     execute immediate "set optimization all_rows"


Regards, Bryce Stenberg.

[Reuben B.]

My understanding it is more of a GDC/GWC issue defining an appropriate widget.

...

Before I alienate the GDC/GWC teams and never have them implement anything for me ever again, to do this properly there is probably some changes needed in the communication protocols.

The 4gl examples I posted had approx 200 rows so inbetween keystrokes the round-trip time to send the keystroke via ON ACTION dialogtouched, determine, and send back the list of entries to populate the list is neglible.

Now imagine if the number of potential rows in the drop-down list was measured in ten and hundreds of thousands, say all the customer names from the database.

Typing in S may return 10,000 rows, typing in SC may return 1000 rows,  typing in returns SCH 100 rows.  So in the time between typing S and C, is the system able to go back, determine the 1000 rows and return them to the front-end, and do you really want to return 1000 rows.   We probably want to have the equivalent of ON FILL BUFFER for the drop-down.  Any other thoughts on how that process could be implemented welcome.

So it is not necessarily as simple as implementing a widget or variation of an existing widget.

Reuben

Hi Reuben, we have 1 kinda autocompleting widget:combobox.
The current behavior is that you can type ahead blindly and land hopefully on the right item
(it works as in Explorer or Mac Finder)
We could add a new mode/attribute/style which shows you what is typed and reduce the list to choose from.
So everything needed for a smaller list (<=50-100 items) without asking back the server is at the client side.
To crawl thru large data sets while typing for sure we need a more intelligent mechanism.
Something like ON FILL BUFFER as you said.
Kind Regards , Leo

Hi Leo,

A COMBOBOX only allows you to enter known values (unless you fudge it by doing a CONSTRUCT using QUERYEDITABLE as in my examples), I suspect the solution will be an EDIT with an attribute or style to offer a list of values as this will also allow you to enter new values.

This list of values could come from the back-end with something similar to ON FILL BUFFER as discussed, or maybe some form of callback function.  However if you didn't need to get the values from a database but were only interested in getting values that had been previously entered into that field/form/window then the values could be stored in the registry similar to other form/window settings.  As I understand it that is what the browsers do with the autocomplete attribute http://www.w3schools.com/html5/html5_form_attributes.asp.

I wonder if GWC users could do this now by editing the Edit.xhtml snippet to set autocomplete="on"?   There is probably even a 2.30 webcomponent solution to this as well.

Reuben

[.]

Quick remark:
Autocomplete will only propose the values already filled by the user for this field ... So the feature will not be fullfilled as, I guess, 4GL developper would like to propose values from the database (as the example from Bryce).

[.]

Just made a small prototype, based on a style on combobox.

Auto-completion list is using the name attribute of each items. I made a few tests and it is pretty usable. My sample reads for each keystroke a text file containing 10 000 entries and updates the list, but as I recently upgraded my laptop I don't know how it behaves on a slow machine.

A more simple example (a combo to select the county, then the completer to select the city in a ~600 items list) works very smoothly.

I'll try to polish the prototype and add this as an "experimental" feature of 2.30. Depending on the feedback we'll see how this can be added as a supported feature.

[.]

Just keep also in mind that the prototype is far from being perfect: if the communication / database / program is pretty slow, GDC's type ahead will buffer each keystroke and you may end with a 100% CPU time on the desktop and on the server too, as GDC has today no way to cancel the type ahead and the request.

So if this goes in 2.30, this will really be only "experimental feature" as we will have to work on a more robust (and working on all front ends) solution.

[.]

Would I be right to say this didn't make 2.30?

Or is it merely undocumented?

I'm in the process of migrating to 2.30 and would love to try this feature. Please!

Thanks

Jeff