08:03:52 PM
3J31707MV
You did not really give me a solution. I was not implying FAS was not dojng its job. It is not FAS at all; FAS will happily process any number of records properly in a grid, combbox, etc. FAS is running it perfectly.
But that is not relevant to my issue, a common issue in business apps - large picklists. So if FAS is OK why not just use a grid or combobox, you say?
Let's take grid as an example. The problem is AW grid cannot have a data source of more than X items before slowing down, and eventually coming to almost a standstill. The number of data items varies with the memory, etc.
Alex himself on the AW forum says their grid cannot be used for large lists of data as it has no server side paging and probably never will. It does have a virtual mode, which helps a little on the client side. But robist grid productsm all have server side paging, which dishes out records a page at a time seamlessly. Look at the example here of how smooth a grid with 500,000 records can move with server side paging: http://mleibman.github.com/SlickGrid/examples/example-optimizing-dataview.html . You can look at their other examples as well, they have an async column fill, and more. Those are features that allow a grid to be used for anything. AW grid is an excellent GRID, but not good at DATA management.
There are no other options within VFP that will translate into a proper pickup list via FAS.
So FAS is working fine, but it is lacking this essential tool. Since I doubt you are switching grids soon, I was hoping you would have a solution.
I take it you do not have a solution.
1- FAS has no grid limitation, only high Reccount() take longer to process on the server
2- I would populate the grid by SELECT-SQL, or preferably a parameterized view, and show it after user has typed something
3- Please note that DOM event change() does not behave like InteractiveChange() - user needs to hit enter to submit textbox's value
Normally when we need a lookup for a name, etc. we use a grid. But since a grid cannot handle more than a couple hundred records, what do you think is the best way to do a lookup that meets the following basic criteria:
1. Displays mutliple fields across (i.e. a name lookup would display name, address, city, state, occupation, phone)
2. Incremental searching (press KO takes you to first KO entry
3. A ctlr+f type find within the lookup, to jump to the first occurence of say "west 43nd street", even though the address field is not the ordered field
4. Record count could be up to 100,000 records.
5. Must be able to search thru all the records, not do some sort of halfway web type search where you have to type in a name and it tries to find a half dozen similar names.
6. the user may have entered a initial search criteria, and if so, we use it not to limit the records shown, but as a point of where to start (IOW we SEEK what he enterd, but we do not filter).
What I am calling a lookup is often called a picklist.
Pretty basic stuff for VFP. Seen similar in serious business web apps. Not sure best way to do it given the grid limitations.