John Colby
jwcolby at ColbyConsulting.com
Tue Feb 28 21:46:29 CST 2006
LOL, 99% of my forms are bound. 99% of my forms do some pretty "fancy" stuff via my framework as well. For example, I have a "REC_ID" text box on every form which is bound to the PK of the table the form collects data for. The REC_ID on the opening form is bound to the PK so it has information on the field name for the PK which I can use in building "move to" code. If a combo on another (child) form is displaying a record, the combo has the PK VALUE of a specific record in the parent table. If a user dbl clicks a combo box, my framework can cause a data entry form to open displaying data from the parent table that the combo is displaying. Since I know the PK from the combo that was double clicked, and I know the table and field of that PK from the REC_ID control, I can instruct the form to "find" that PK. I therefore have all the pieces needed to open the form and move to the record that the combo was displaying. If the combo back on the calling form was on the new record, it will NOT be displaying data. That is a signal to the opening form to move to a new record so that the user can enter data. I use the same basic logic for the "not-in-list" event of the combo to allow the user to automatically open the data entry form for a combo, move to the new record, and enter new data in the table. When the form closes, the combo requeries and now contains the newly entered data in the list table. That kind of stuff. My framework provides dozens of "behaviors" that are just there if I want to use them. In the OnOpen of a form, when I set up the form class, I can specify that "this combo is dependent on that combo". When the class for this combo is requeried, it automatically requeries all "dependent" object classes. I can have subforms, combos, list boxes etc. all "dependent on" a given object. As long as each of these dependent objects has a "requery" method, I can just iterate the colDependentObject collection of the class, requerying all dependent objects. The current event of a subform can cause the form class to requery all "dependent objects" dependent on that current record of the subform. Of course all dependent objects have to have feedback in the query that allows it to display different data depending on the current row of a form, or the selected item in a combo etc. But if you set it all up, and "inform" the framework (objects) that other objects are dependent on them, then they all get requeried when the master object is requeried. A combo can have a dependent combo, which can itself have a dependent combo. Change the first combo, it requeries the second combo. The second combo then requeries the third combo etc. The third combo could requery 5 subforms. Your imagination is the limit. This kind of stuff can make the creation of dependent combos and subforms a snap. Just one of dozens of behaviors built in to the framework. Yea, I use bound forms, I use autonumber PKs, I use a framework, and I make good use of all of the above. John W. Colby www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky Smolin - Beach Access Software Sent: Tuesday, February 28, 2006 9:15 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Assistance Bound or unbound forms? Rocky John Colby wrote: > Folks, > > I am looking for a "junior level" person to assist me in getting some > of my back log caught up. I need one person, able to: > > Read and program VBA, guru not required. > Understands and can build Access tables, queries, forms and reports. > Must understand data normalization and be able to correctly sort out > what data goes where given a set of objects / attributes. > Must be able to read, understand and build relationship diagrams in > the relationship window in Access (the center of my universe). > Has a few hours a day available (10-20 hours a week). > Must be self starter, blah, blah, blah. > > If anyone out there thinks they might fit the bill, please respond > OFFLINE - email a resume, and introduction email with required hourly > wage to jwcolby at colbyconsulting.com. The more you know and are > capable of the more work I have. > > Thanks, > > John W. Colby > www.ColbyConsulting.com > > > -- Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com