I am having problems with terminology (new to Servoy) and suspect what I want to do is very simple. I have a button that does a servoy find + search that reduces the current set of records to those that are ‘active’. This works perfectly. The user can then scroll fowards and backwards through that set of records. I then want to ‘find’ the first record (within the set) that matches a criteria…eg in human language terms 'go to first record where surname = ‘jones’.
The point is I only want to MOVE the recordindex to that record.
I dont want to reduce the recordset down to records that have ‘surname=jones’.
I have tried doing this with variations on the find+search paradigm but it either doesn’t do anything at all…or it reduces the set of records down to just those that comply. eg:
function searchSurname()
{
controller.find()
surname = “#%”+globals.surname+“%”
controller.search(false,true)
}
…how do I move to the first record that matches the criteria? (In human terms I would call this a ‘find’ - but it doesnt seem to be that in servoy).
I am assuming this must be really simple but I just cant grasp it:)
Maybe you could create a second foundset, do the find / search in that foundset and then use the
primary keys from that foundset to do a selectRecord in the original foundset.
Hmm
Seems a bit complex for a simple function
In most other environments there is a Control-F function that will do a find in specific column and take you to the first occurrance without reducing the set of records.
Also,
As far as I can tell the setSelectedIndex function moves to a record by its sequence (index) in the foundset. That presumes you know at which position in the foundset is the data value you are looking for…which is sort of s circular argument…
What I really need is:
setSelectedIndex(surname=‘jones’)…which as far as I can tell doesnt exist? Has anyone managed to duplicate this ?
Jan Aleman:
Out of curiosity: what would the practical use of such a search be?
I think, to move to a record matching certain criteria in the current foundset without reducing the foundset, e.g. in a list view
Is there any easy way to do this? It’s a common enough operation.
As an example, quickly move the pointer to a given place in a list of surnames by alphabetically character, and still be able to scroll backwards and forwards through adjacent records.
Jan Aleman:
Out of curiosity: what would the practical use of such a search be?
I think, to move to a record matching certain criteria in the current foundset without reducing the foundset, e.g. in a list view
Is there any easy way to do this? It’s a common enough operation.
As an example, quickly move the pointer to a given place in a list of surnames by alphabetically character, and still be able to scroll backwards and forwards through adjacent records.
For rolodex users? I still don’t see any practical use in the example above. Why do you want to scroll back? If you are on ‘f’ and want to search for ‘e’ why not search?
Well, let’s say you have invoice numbers and you want to jump to a numbered invoice, then continue to flick through records from there. Similar with dated records.
My aim is to make software that perform how users like and expect to function, not to mould the users to the shape of the software. The Rolodex is a great example that less computer savvy people can understand!
antonio:
Well, let’s say you have invoice numbers and you want to jump to a numbered invoice, then continue to flick through records from there. Similar with dated records.
My aim is to make software that perform how users like and expect to function, not to mould the users to the shape of the software. The Rolodex is a great example that less computer savvy people can understand!
simulating a rolodex would take very few lines of code. But again I assume that’s not what you want? You’re all giving me a hard time trying to understand what you are really trying to achieve and why you want it and how users would actually benefit from it.
Jan
I think the simpleast explanation is one of ‘context’ - in most windows applications (eg Access/Word/Excel) there is a ctrl-F function that takes the use to the next occurance of the search string…but doesnt remove the rest of the information…so you jump to that record/string…but still withint he rest of the information.
Many users are confused by the behaviour of all the non-matching information ‘disappearing’.
Jan, the Rolodex is a great analogy. While it may not be the most efficient from a programmer’s perspective, it’s a real world equivalent that end users can relate to (especially those not entirely comfortable with computers). For example, most people love the iPhone GUI. Apple has gone to huge efforts to make it intuitive - and in the Contacts app they have gone for a Rolodex!
Put simply, I’d like to know a quick way to change the record pointer (in list or record view) with out reducing the current foundset. I thought setting the [reduce search] parameter to false in the controller.search() would do that.
antonio:
Jan, the Rolodex is a great analogy. While it may not be the most efficient from a programmer’s perspective, it’s a real world equivalent that end users can relate to (especially those not entirely comfortable with computers). For example, most people love the iPhone GUI. Apple has gone to huge efforts to make it intuitive - and in the Contacts app they have gone for a Rolodex!
Put simply, I’d like to know a quick way to change the record pointer (in list or record view) with out reducing the current foundset. I thought setting the [reduce search] parameter to false in the controller.search() would do that.
You can do exactly the same in Servoy and it will require a lot less coding (I guarantee at least 95% less coding) than they spent on iphone. Oh and it will be a lot faster than an iphone too, and last but not least it will work on more than just an iphone! And have more functionality. And…
A rolodex is only handy when the dataset is only like a 200 records or so. When you have thousands or more records then you shouldn’t be browsing like that through your resultset. It doesn’t scale and it will also be a bad UI experience. Searching (limiting the resultset) is then the way to go and a place where SQL excels in.
So think about this, what if you make a solution that uses the rolodex approach and your customer decides it wants to store a couple of thousand contacts in there?
Same issue with valuelists that people try to populate with thousands of records (BTW Servoy only allows 500 records in a valuelist). It’s bad UI to put so many records in a valuelist (like for use in a combobox). Create a listview with a search/filter field that can act as a listpicker for that field. It’s a much better UI for large amounts of records. Search instead of browse.
ROCLASI:
A rolodex is only handy when the dataset is only like a 200 records or so. When you have thousands or more records then you shouldn’t be browsing like that through your resultset. It doesn’t scale and it will also be a bad UI experience. Searching (limiting the resultset) is then the way to go and a place where SQL excels in.
So think about this, what if you make a solution that uses the rolodex approach and your customer decides it wants to store a couple of thousand contacts in there?
Same issue with valuelists that people try to populate with thousands of records (BTW Servoy only allows 500 records in a valuelist). It’s bad UI to put so many records in a valuelist (like for use in a combobox). Create a listview with a search/filter field for such amount of records that can act as a listpicker for that field. It’s a much better UI for large amounts of records. Search instead of browse.
i also wonder about the durability of the rolodex image as a meaningful icon.
when i taught my daughter claire a little bit of FMP (born 1988) and i explained that one pages through records using that widget in the status area “that looks like a rolodex” she asked me “that looks like a WHAT?” it’s a very long time since i’ve seen a physical rolodex on a real desk. therefore the little “rolodex card” icon with the two square rolodex rail (or wheel) holes is becoming, IMO, obsolete. Why use an icon that represents a physical object nobody uses?
All good points, thanks. Let’s not call it a rolodex or use an icon that looks like one. My main consideration is that not everyone thinks like computers/programmers. Can we make software that can work for those who think differently? If you’ve got less than 200 records from a Find/Search which you want to preserve, what efficient code can we use to move the selected index pointer with out reducing the current foundset?
An example - a user wants to find a record for Acme Widget Co. created some time ago but only has a vague idea of the date. They first do a Find for Company = Acme Widgets and see there are several pages of records in list view. From here the options are
Reduce the search for a specific date. If that’s not the right date, they will have to repeat the search for Company, for each date.
Reduce the search for a date range, entering “01-06-2008…01-07-2008|dd-MM-yyyy”. IMHO This really isn’t intuitive to your average user who doesn’t work in Java. Sure it’s possible for users to learn, but that’s adapting the user to the software.
Provide a way to jump to a selected date then look at records around that date.
The iPhone analogy was just there to make the point that a lot of people in the world love to flick through records to find things, even if they’ve never owned a rolodex. Observe how many people use things like Cover Flow, or flick through records in their Contacts. Agreed that it’s not efficient for 20000 records, but it’s great for 50-200. Apple put those things there for a reason - they spent vast amounts on focus groups, audience research and other qualitative studies and found that this is how most brains work. It’s the difference between good and GREAT!
Hans suggested this - what’s the most efficient to do this? (and given these discussions, could “Goto without reducing foundset” ever be considered as a parameter on the Search command.?)
Hans Nieuwenhuis:
Maybe you could create a second foundset, do the find / search in that foundset and then use the
primary keys from that foundset to do a selectRecord in the original foundset.
I totally agree with Antonio. We are migrating away from Visual Foxpro and with Foxpro we have the command ‘seek exprChar’ (on an index) that moves the recordpointer to the first (exact) matching record. With the command ‘set near on’ we can even move to the nearest matching record.
We see at our customers site that users often don’t have the exact search-input-criteria. Nice example in the Netherlands is searching on postal code, where postal code is area based and often used in marketing and expedition.
Point is that we can’t tell our customers how to search…
I’m very happy with the Servoy-objecttype ‘foundset’ and would like to see the recordpointer-movement-search enhancement to it !
and the select the record in the main foundset using that PK.
If the select Record() function returns false, the PK value is not (yet) part of the loaded records in the main foundset.
Up to you what to do then:
1: trigger the load of the next 200 records in the foundset and try to select the record again, in a loop, untill selectRecord returns true (be carefull: this might load thousands or crecords into memory!)
2: show the user a message of some sort.
ROCLASI:
Same issue with valuelists that people try to populate with thousands of records (BTW Servoy only allows 500 records in a valuelist). It’s bad UI to put so many records in a valuelist (like for use in a combobox). Create a listview with a search/filter field that can act as a listpicker for that field. It’s a much better UI for large amounts of records. Search instead of browse.
I created a (dynamic) listpicker module. You can find it on ServoyForge.