Hi Ken,
Thanks for the reply and some interesting approaches for me to
consider. More comments below.
Ken Dibble wrote:
I put these controls directly onto any form where I need a search, and
add a Search() method to the form. Pressing the "GO" button calls the
Search() method. The form's Search() method validates the user input
and if it's okay, passes it to a nonvisual Search object. (I should
make all this into a class at some point--but I've been following the
XP technique of getting a few permutations of the input/search/return
results pattern working so I can find the common threads, and so far
it still looks like refactoring a class out of it will take longer
than it does to copy/paste the elements where I need them, and I'm on
a deadline to get this thing out the door.)
On forms where adding/editing of records is allowed I put a standard
toolbar class at the bottom of the form and the find button calls
thisform.findrec() This pulls up a modal form that allows the user to
type in an order number or style number and it will show the results
below (updated for each keystoke). They can either select a record (and
stay on this record) or cancel. The calling form then takes care of
refreshing.
On other forms that have no toolbar I just allow the user to enter some
sort of code or part code in the search box and call a standard modal
search screen with the results (or not found messagebox).
Depending on the situation, when there are no matches the user may be
given the option of starting a new record. When there are matches, the
user may get an option to press a "New" button on the modal results
form to signal that none of the search results is what s/he wanted and
that a new record should be created instead. Either way, when the
modal form closes, the Search() method will then call the normal form
method that sets up the display for a new record.
For things like lookup tables I have been bitten by allowing anyone to
enter a new code/description. If we take a supplier table for example,
people seem to know them by slightly different names and would therefore
add the same supplier under a different name leaving me a mess to clear
up. I now only allow 1 (plus 1 or 2 backup) people to add to these
tables who know all the suppliers and what is already on the system.
I don't like to make users open a new window to start a search because
in my systems searching is an extremely common task. In many cases, in
order to prevent duplications users must search the existing data
before they are allowed to create a new record. So having the controls
on the same form where the data will be entered speeds things up
considerably.
On my forms where I allow adding I don't really need to force them to
search as adding a duplicate style is okay (the system is an garment
ordering system and each garment is given a style code so more than one
order for the same style is allowed, but each order will always have a
unique order number). When the user adds a style they will be informed
if it is a repeat order (they should know this) and can therefore cancel
adding to check things. I think some of the these choices are data
driven depending on what you are allowed to do.
In the past I've also used a system wherein searching for a term
immediately displays the first found instance on the form, and the
user can keep pressing the search button to display subsequent
matches, but most people don't find that as convenient as getting an
entire list of matches at once and being able to choose the one they
want to view.
Yes, I usually display all the results that match the search ref they
put in. The exception now is when I update the results below for each
keypress. I now only show the first 80 matches as it gets too slow at
the start of the search ref.
E.g. They enter MK-546743 so I start searching after the third
character and search for MK-5 which will have quite a lot of matches and
unlikely that they will pick from this list. Usually they just keep
typing till their style appears in the visible list, which is a list box
of about 25 items.
Cheers
Peter
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
