search screens are not customizable or personalizable, so unlimited scrolling is always an issue.
In most cases I’m OK with creating some kind of custom search using the built in tools.
However there are a few forms where it’s not possible to build BAQ searches using the built in tools. e.g. where multiple key values must be returned.
I wish the built in tools could handle these cases. It comes up just enough…
In the meantime, an example for returning multiple keys in a search does exist.
Hopefully still available from this site - http://trigemco.com/code-blog/
I’m currently working on a situation that needs this. It’s a BAQ Search against UD19 which requires multi-key returns. Currently the form is being loaded from my search based on key 1 only even though the BAQ is specified to return all 5 keys. I wasn’t able to find the example you were referring to at the link you provided, by any chance you have any info on how to get around this situation?
Use the sysid column to return the right row.
How about just the following for the built-in search:
- The ability for the search window’s size and location to be remembered.
- Remember the column order and widths
- A button to return all results. Like when you know there is less than 500 records, and dont want to have to click the ‘Next 100’ button several times. Or editing the options to return all.
- When using ‘Next 100’ have the list scroll to the first “new” result found (the 101st, 201st, etc…)