John Colby
jcolby at colbyconsulting.com
Thu Oct 2 11:12:11 CDT 2003
Hmmm... I suppose so. OTOH many people (touch typists) don't watch the screen as they are typing so they don't know they have entered a mistake - or found data not in the list - until they finally look at the combo some time later. If something happened IMMEDIATELY... I could beep the user, prevent the excess characters from being entered in the combo (so they don't have to visually find the error point) etc. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte Foust Sent: Thursday, October 02, 2003 11:46 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] CBO Not In List Wouldn't that get annoying if someone was simply not a very good typist? Waiting for the afterupdate event at least allows the user to correct their typing errors. Charlotte Foust -----Original Message----- From: John Colby [mailto:jcolby at colbyconsulting.com] Sent: Thursday, October 02, 2003 7:22 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] CBO Not In List >The behavior you propose would be more beneficial for combos that are limited to list, enabling users to get early warning that their entry is invalid or miskeyed. Precisely, and that is what I was trying to say. If the properties for LimitToList and AutoExpand are set true, then some event (LimitToList?) should IMMEDIATELY fire if the user is no longer matching data in the combo. In fact it only seems to fire if the user attempts to LEAVE the combo and the data doesn't match something in the list. Seems silly to me to not fire immediately. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Henry Simpson Sent: Thursday, October 02, 2003 11:05 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] CBO Not In List I have implemented a similar scheme based on a callback combo source. When the form initially loads, it opens with a narrow set of values and as items are not found in the list, the combo is repopulated with a progressively wider range of possible values. The logic behind the method was that users spent over 95% of their time working on active records but occasionally needed to look up records that might become active, records that have been closed and records that have been archived all from a single lookup. It the item ulimately was 'not in list', the procedure allowed for adding the item. The approach allowed for checking a single record 'current' flag for each globally available list source meaning that the data was all cached locally and only refreshed when a single record time stamp indicated the necessity resulting in a drastic reduction in overall LAN congestion. I disagree with your statement that the combo should beep when a not in list is discovered. One of the parameters for the not in list is the contents of the combo when the list fires and I always use this parameter to populate fields in the new record. It would be very annoying to users accustomed to entering new records in a combo to have it beep 30 or 50 times at them as they add new records. I believe that the purpose of the implementation of the event is to allow users to enter new records directly into the combo rather than notify them to get out, yet still use the combo as a record locator. The counter argument to allowing such easy entry of new items is that miskeyed or misspelled text strings are easily accidentally entered as duplicate records but it is possible to use the same, 'as you type' record checking routine to search for likely matches and for the ultimate not in list event to first pop a list of soundex matches from which to choose before permitting the addition of the record. None of my data entry forms have a 'new record' button as I make them search/add new records via combo boxes exclusively. I also find it peculiar that those who argue that misspellings and the ease of adding new records in this fashion makes for the liklihood of accidental duplicate records, it is just as easy for a person to punch the new record button on a data entry form and never see whether the record had been previously entered. Also, the use of a single record table flag to indicate that records have been edited or added ensures that if the possiblity exists of multiple users getting the same data concurrently and each adding the same record since there combo was last filled is greatly reduced. The behaviour you propose would be more beneficial for combos that are limited to list, enabling users to get early warning that their entry is invalid or miskeyed. Hen >From: "John Colby" <jcolby at colbyconsulting.com> >Reply-To: Access Developers discussion and problem >solving<accessd at databaseadvisors.com> >To: "AccessD" <AccessD at databaseadvisors.com> >Subject: [AccessD] CBO Not In List >Date: Thu, 2 Oct 2003 09:29:40 -0400 > >I want to use the NotInList to open an initial data entry form if the >person searched for isn't in the database, else open a tabbed form if >they are. I have this working using NotInList to open the IDE form and >the after update to open the tabbed form to the record of the person >found in the combo. > >However, what I want to do now is to have the combo start beeping as >the person types if the item is not in the list. IOW, NotInList only >fires as the user EXITS the combo and the item is not in the list. >However if the user is typing in a person's name - JOHN COLBY, and by >the time she types the O in COLBY the combo is not finding the name, >the combo should start beeping so that the user is notified to stop >typing and tab out to trigger NotInList and open the data entry form - >or even programatically tab out and trigger the NotInList. > >It seems like it could be accomplished by checking the insertion point >and the length of the data in the combo. If the data exists, the >insertion point is in the middle of the data that the combo is >following, whereas as soon as the data is not found, the insertion >point is at the end of the data. IOW, if the insertion point is at the >end of the data TWICE, then we are at a true "not found" and trigger >NotInList. In fact it seems like the combo should have been built this >way to begin with. > >Has anyone ever done this? > >John W. Colby >www.colbyconsulting.com _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com