Phil's suggestion is a good one and you can do more with that approach: - You can for example create a different class for each window (2 and 3) if you have different properties on each window. - You can create methods on the classes to execute code on Window 2 and 3, from Window 1. - You can even create new events for each window and fire them from window 1.
If you have common code for both windows 2 and 3 you can create a main class with the common code and then create subclasses of the main class for each window to implement specific code for each one. If Window 2 and 3 have some methods that are specific for an app and that you don't want to include on the classes but you need to execute them via Window 1, you can implement a class interface for each Window (2 and 3). Carlos On Dec 30, 2006 1:26 PM, Phil Heycock wrote: > Create a subclass of Window: flexibleWindow, or some such. > > Give flexibleWindow the properties that you will want to be addressing via > the 'relatedWindow' reference in Window1. > > Give Window1 a property: relatedWindow As flexibleWindow > > Make flexibleWindow the SUPER for Window2 and Window3. > > HTH > > P. > **************** > > on 12/29/06 4:42 PM, Chuck Pelto at [EMAIL PROTECTED] wrote: > > > Hi Fargo, > > > > On Dec 29, 2006, at 1:38 PM, Fargo Holiday wrote: > > > >> Honestly, I'm not tracking what the heck you're trying to do, but > >> why not just subclass Window and add whatever variables and methods > >> you'll need to your class? > >> I may, as stated, not be following this well enough to grasp why > >> this won't work, but it certainly seems like it would. > > > > What I'm trying to do is come up with a more reusable set of Windows > > in which I can readily shift emphasis from one to another. > > > > The windows are to be part of a relational DB, each window holding > > data for a particular Table (V4RB). > > > > Window1 holds data from the Parent table. > > Window2 and Window3 hold data from the child tables. > > > > Window1 has a TabPanel in it. A number of different tabs do different > > views. > > > > Tab1 - form view of Window1 record > > Tab2 - list view (using ListBox) of Window1 records > > Tab3 - part of form view info with list view (using ListBox) of some > > of related records in Window2; click on a row in the LB and Window2 > > comes up in a form view showing that related record. > > Tab4 - part of form view info with list view (using ListBox) of some > > of related records in Window3; click on a row in the LB and Window3 > > comes up in a form view showing that related record. > > > > [Note: The click on an empty/non-existant record in the ListBox from > > earlier was a way to generate a new related record. Click on a blank/ > > non-existant record row in the LB and it would generate a new record > > in the related table. Still working on what to do about that.] > > > > My idea is to develop a proto-type or 'shell' system that can be > > readily made into a completely different database system, cutting > > down on development time by eliminating as much hard-wiring of > > information as possible. > > > > My thought was that if RB had a way to recognize Windows as I am > > pushing for, it would eliminate the need to write: > > > > Window2.fooProperty > > > > by putting in > > > > fooWindow.fooProperty // where fooWindow is a Window Property of > > Window1 that I can set on the fly to either Window2 or Window3. > > > > Then, when the user clicks on Tab3 or Tab4 the system would > > immediately recognize which is the Window/Table it should be > > targeting based on something in the tab. > > > > Hope that alleviates your confusion. Better still, hope that gives > > someone an idea on how to achieve what I'm trying to accomplish. Even > > better, if they share that with me; neo-phyte that I am.... _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
