On 7/16/07, Bill Witherspoon <[EMAIL PROTECTED]> wrote: > > On Jul 16, 2007, at 9:56 AM, Bill Witherspoon wrote: > > > >> I assumed that I would be able to access one form from another by > >> going > >> through it's application property, something like: > >> > >> self.Application.MyOtherFormName.txtBox.Value = "the value I want > >> to pass" > > > > The attribute you are looking for is self.Appllication.uiForms. > > However, it does not resolve items by name as you are trying to do. > > > > Normally forms are distinct and do not reference each other, but > > there are exceptions. When that behavior is needed, you need to > > supply a reference to the 'target' form so that it can refer to that > > form's methods/properties as needed. > > > >> The dApp docs make mention that it contains a collection of > >> applications > >> forms, but I can't seem to find it in the properties. > >> > >> I did get the behavior I was after by using: > >> self.Parent.txtBox.Value = "the value" > >> > >> but I wasn't sure if this was the best way. > > > > That will only work if the form in question is a child form of the > > one containing the text control. It will not work in most cases. > > > > Also, it is generally considered inadvisable to tightly bind the > > name and position of a control on a form to anything. This is > > considered "tight coupling", and now even minor changes to one form > > can break the other. The better approach would be to add a method to > > the form containing the textbox that will return the desired value, > > and have the other form call that method. This way, the calling form > > doesn't need to 'know' anything about the internal structure of the > > other form. > > > > Yes, I agree on that one. But I think I'm stuck here, because the > sub-form that is spawned is a search form for items to be added to the > parent. > > The user might do a few searches, and then select one item (or more if I > can figure out how to do that) from the resulting grid. This item is the > info I want to pass back into the detail record of the parent form. > We're selecting items for a purchase order in this case. > > Do you mean I should return a value through the sub-form's Close event? > >From the main form: > > self.frmPS = frmPartSearch(self) #this is the sub-form > self.frmPS.Show() > theValueINeed = self.frmPS.theValue #variable set as subform closes > > I guess the part I'm confused about it is when the method is called. In > the above isn't the sub-form going to be shown, and the variable grabbed > immediately (in which case it's wrong)? > > I need to grab the value as the sub-form closes, after the user has done > their searches. The only way I can see to do that is "push" the value > back into the parent form, since the parent will never know when to go > and get the values.
Create the form as a dDialog. Show the form as a modal form. When the user clicks ok or cancel, the form is not destroyed, it merely hides itself. You are then free to call a method from the dialog class you created (call it getData or getValue or whatever) and that function will return your selected value. Then destroy the dialog and you are done. This is simple compared to 2 completely unrelated forms... > > Bill. > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
