jwcolby
jwcolby at colbyconsulting.com
Thu Feb 12 16:21:21 CST 2009
I would suggest that kind of behavior is much easier to implement by using the message class that I floated past a few weeks ago. Given that many of you were not using classes, that email might have gone right over your head. The basics are that we have a class that raises events which I call "messages". The clsMsg is a global class that any class can grab a pointer to. The clsMsg has a method to call which sends a message, and raises the Message event whenever anyone calls that message. That class has an "email" like syntax, with a From, To, Subject and Body variables. So... Customer form grabs a pointer to clsMsg. Orders form grabs a pointer to clsMsg. Customer form calls the Message event of clsMsg, passing off it's form name (frmCustomer) in the from field, the name of the form that the message is intended for (frmOrders) in the To field, and perhaps the CustomerID in the Subject field. The order form is sinking the Message event. Its message sink gets every message going by, but it filters on the To field looking for its own name in the To field. If it sees a message with its name in the To field, it then grabs the CustomerID out of the subject field and uses that to look up the correct customer's orders. Notice that this message class (which I actually have in my framework and use in my applications) is a "generic" communication channel between parts of your program. I will send it along in the next email. John W. Colby www.ColbyConsulting.com Arthur Fuller wrote: > I've done that with the NotInList event too. I did it with a function that > accepts the name of a form, but a class is a cleaner way to go. > > What I was thinking here is that I could have a customer form open and and > orders+details form open at the same time, and that navigating on the > customer form would automatically refresh the orders form, even though they > are separate forms. The same thing could be done with the order details > subform and the products form. > > Arthur > > On Thu, Feb 12, 2009 at 4:43 PM, jwcolby <jwcolby at colbyconsulting.com>wrote: > >> Yep, that will work just fine. What is the implementation idea? >> >> I have a behavior that I actually have embedded in my framework where the >> dbl-Click event of the >> combo can cause a list form to open, navigate to the record in the combo, >> or if the combo item is >> "not in list" opens the list form in Add mode. >> >> Suppose that you have something being displayed in a combo box. Perhaps a >> name / SSN for a person. >> A user is trying to add people in a form using that combo, but notices that >> the name / ssn in the >> combo box appears to be correct but the SSN is off by a digit (just an >> example scenario). The user >> can select that person, then dbl click in the combo. The combo class has >> to have been fed a form to >> open in case of the dbl click. If it has, then the combo opens the form. >> Since the PKID is in >> column 0 of the combo, the combo class "passes in" the PKID of the person >> selected in the combo. >> >> The form as it opens, grabs the PKID and moves to that PKID and places the >> form into Edit mode. >> Voila, instant edit of exactly the correct record in another form. >> >> John W. Colby >> www.ColbyConsulting.com <http://www.colbyconsulting.com/> >> >> >> Arthur Fuller wrote: >>> I've gone all the way with you, JC, and this weekend I plan to try an >>> experiment bearing on the "Sinking Events in Multiple Places" concept -- >>> specifically, two related forms open and navigation on one causes >> parallel >>> navigation on the other, so they stay in synch. Seems like a perfect >>> application of this concept. >>> >>> Arthur >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >>