FiveTech Support Forums

Marcelo,

it is easy for the user we can define how we can search the data and we don't need to use mouse,

Please be more specific about how you want to search. The combobox can do incremental searching.

And if you automatically drop down the list the user doesn't have to use the mouse.

So I am wondering what you wish to do that can't already be done with either the combobox or dbcombo?

James

James,

can you post a simple sample?, to see the best approach.

regards

Marcelo

Hello,

here you can download other sample

https://app.box.com/s/48nd61t4sxe5d319c5bm

criteria for search can be defined for the user, the view list size too.

regards

Marcelo

Holas,

this is the code to define the control

Marcelo,

can you post a simple sample?, to see the best approach.

See the info in one of my previous posts in this thread.

here you can download other sample

I don't see that it provides anything that a combobox or dbcombo doesn't do. Also, your example lets the user type in characters that don't match anything in the list which may be confusing to the user.

I do see one problem. I have not been able to find a way to automatically force the list open on the first keystroke with a combobox or dbcombo. I think this will require some changes to the combobox class source code, but this can be easily done.

I have also found that the sound doesn't work since it calls the old Clipper tone() function which doesn't work under windows. The sound was used to provide audible feedback to the user when a keystroke matches data--there was no sound when it doesn't match. This can also be easily fixed.

criteria for search can be defined for the user

With a combobox the search can be defined as either incremental or not (each keystroke finds the first match only). What other criteria do you need to define?

James

James,

please donwload again

https://app.box.com/s/a7lamqj1z427k4a8n34j

I added a combox in the same sample with the same data, please try to find "pico" in GETLIST and in ComboBox

regards

Marcelo

Marcelo,

OK, I see you are doing an incremental CONTAINS search. The combobox control only does searches on the left-most characters and is useful for such seaches as city, item, description, etc. And the database must be indexed.

The combobox control might be able to handle a CONTAINS search using the bChange codeblock.

Your control doesn't seem all that useful searching for Pico, since there are a number of Pico's but they are not sequential so the user only gets the first occurrence and then would have to scroll through the rest of the database looking for other Picos. [I note that it doesn't allow scrolling currently.] I think to be useful you would have to delete all items in the array that don't contain the search characters and this would have to be done after each keystroke. Another complication would be if the user backspaced, then the array would have to be reloaded and then items NOT matching the search characters left after the backspace would have to be deleted. CONTAINS type searches are better done having the user type in the complete search, then pressing a Search button--it is much less complicated and much faster than incremental searching. Still it could be slow since every record in the database has to be processed.

Your incremental CONTAINS search might work on very small lists, but certainly street databases could be tens of thousands or even millions of records long.

I also wonder how you then get the record ID when the user chooses an address. With dbcombo you can display the street and return the record ID.

Searches can be complicated.

Regards,
James

James,

The search is done over all the table until get the number of records you want to display (in the sample 15, oGet:lenDisplay := 15, the common is 5), for that reason there is no scroll

It's an early test, the idea is to work like DBCombo displaying some column reated with another column of the table for result.

I can see there are not interest in this control, if I have some time I will try to finish it, James, sorry for lost your time

regards

Marcelo

Marcelo,

The search is done over all the table until get the number of records you want to display (in the sample 15, oGet:lenDisplay := 15, the common is 5), for that reason there is no scroll

But I wonder, did you intend to only show records containing the search term. For instance, now there are only 4 of the 15 records containing the search term (pico). Also, it seems for large databases this is going to be very slow since every record in the database is going to have to be read and searched for each keystroke. It might be possible to create an index that doesn't contain the first item (address number in this case) which would be much faster. However, users would only be able to search on the second item (street name in this case).

I can see there are not interest in this control, if I have some time I will try to finish it, James, sorry for lost your time

I did not mean to imply that I was not interested. I am just trying to find out what you are hoping to accomplish and pointing out some of the issues with the current design. Users are only interested in getting the result they need as fast as possible.

I don't think time is lost pursuing any of these ideas. Without trying new things we don't learn anything new or develop anything new.

Please let is know of your progress.

James

Eduardo,

I will try to become independent the source code, creating a new class inheritance from TGet class. When I will have some new, I will publish it in the forum

regards

Marcelo