Jim DeMarco
Jdemarco at hshhp.org
Thu Oct 2 18:56:46 CDT 2003
...and all custom properties, methods, and events appeared where they should be? As I recall the issue I had (and the speaker at the event I mentioned) was either custom events not appearing in the custom object's event list (and not appearing in the property window's event list) were therefore inaccessible. Jim D. -----Original Message----- From: Drew Wutka [mailto:DWUTKA at marlow.com] Sent: Thursday, October 02, 2003 4:11 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] CBO Not In List Yes, I have written custom controls that work in Access 97. (Not a combo box though...) Drew -----Original Message----- From: Jim DeMarco [mailto:Jdemarco at hshhp.org] Sent: Thursday, October 02, 2003 3:02 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] CBO Not In List Are you implying that you've successfully done this? Any custom ocx I've written (and others) don't quite work as well in Access as VB (A97 in my experience). I can't remember the shortcomings offhand but as an example, I was at an Advisor.com event a few years back and the topic was creating custom controls in VB6. The speaker got bold after mentioning how this control would work in any development tool that supported ActiveX and decided to show us how he could drop it on an Access form and use it. I had already tried this bright idea and had a strong feeling it would fail and it did. Sorry for no details. I guess if someone wanted I could dig up my results. Jim DeMarco Director of Product Development HealthSource/Hudson Health Plan -----Original Message----- From: Drew Wutka [mailto:DWUTKA at marlow.com] Sent: Thursday, October 02, 2003 3:51 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] CBO Not In List Just build a new combo box John. Grin. Blow the dust off of VB 6.0, and make an .ocx. Drew -----Original Message----- From: John Colby [mailto:jcolby at colbyconsulting.com] Sent: Thursday, October 02, 2003 12:00 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] CBO Not In List That's true for data entry, but I am building a search combo for data that is more than one field, thus a form has to open. And my original solution isn't working for all instances. 8-( 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 12:51 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] CBO Not In List That's generally the way I handle it as well, although I may create the basic new record from code and then pop up a form so they can add any additional data that's needed if the situation warrants it. Charlotte Foust -----Original Message----- From: Developer [mailto:Developer at ultradnt.com] Sent: Thursday, October 02, 2003 8:41 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] CBO Not In List As a terrible typist, I agree with Charlotte. I actually like that it waits until you leave; in some apps I grab that "NewData", pop a msgbox, and if the user responds yes, perform an insert of the NewData (avoiding the input form) , grab the new id, re-query the cbo, and select the newly added item. If they answer No, I clear what they typed and drop down the cbo. Just my .02, Steve -----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 _______________________________________________ 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 _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com **************************************************************************** ******* "This electronic message is intended to be for the use only of the named recipient, and may contain information from Hudson Health Plan (HHP) that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately, either by contacting the sender at the electronic mail address noted above or calling HHP at (914) 631-1611. If you are not the intended recipient, please do not forward this email to anyone, and delete and destroy all copies of this message. Thank You". **************************************************************************** ******* _______________________________________________ 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 *********************************************************************************** "This electronic message is intended to be for the use only of the named recipient, and may contain information from Hudson Health Plan (HHP) that is confidential or privileged. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited. If you have received this message in error or are not the named recipient, please notify us immediately, either by contacting the sender at the electronic mail address noted above or calling HHP at (914) 631-1611. If you are not the intended recipient, please do not forward this email to anyone, and delete and destroy all copies of this message. Thank You". ***********************************************************************************