Rocky Smolin - Beach Access Software
bchacc at san.rr.com
Tue Feb 28 22:15:09 CST 2006
Well, thanks to you and your dictatorial methodology I find I am now completely unable to create a new table without defining an autonumber PK as the very first field. With ID as the suffix of the field name. Thanks a lot. And I mean that. Rocky John Colby wrote: > 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 > > -- Rocky Smolin Beach Access Software 858-259-4334 www.e-z-mrp.com