New topic: ImplicitInstance Off and Inter Window Communication
<http://forums.realsoftware.com/viewtopic.php?t=47782> Page 1 of 1 [ 11 posts ] Previous topic | Next topic Author Message symbiount Post subject: ImplicitInstance Off and Inter Window CommunicationPosted: Fri May 03, 2013 6:38 pm Joined: Thu Oct 12, 2006 2:32 pm Posts: 31 Just wanted to check if it's correct that if you're instantiating windows in code and have ImplicitInstance turned off there's really no way to refer to a control in one window from another window? If I'm wrong I'd appreciate knowing how it can be accomplished. Top timhare Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Fri May 03, 2013 6:49 pm Joined: Fri Jan 06, 2006 3:21 pm Posts: 12295 Location: Portland, OR USA It certainly is possible. It really depends on how you are accessing the window and how OOP you want the solution to be. Can you give more details? Top symbiount Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Fri May 03, 2013 7:13 pm Joined: Thu Oct 12, 2006 2:32 pm Posts: 31 Sure, details I have plenty of, it's the solutions I seem to be running a little short on! A typical db front-end with a boatload of windows is where it starts. The windows get built in code using different container controls based on it's function AND where it's being called from AND the security level of the user. It's also not unusual to have multiple instances of the same window. So say I want to do something simple like this: Window1 creates sub-window2 sub-window2 needs to read Window1.textfield1.text sub-window2 then needs to write to a cell in Window1.listbox1 I've tried numerous ways of instantiating the sub-window and they work...until I try to access the control at which point I get a compiler error "This item does not exist" which I guess makes sense since from the compiler's perspective it doesn't. Except that I've used others where it works and I can just keep a table of window handles and who called what, etc, so the structure can easily be determined. I just can't seem to accomplish the same thing in RB unless I have ImplicitInstance on and the windows aren't aliased, which causes other problems that are worse. Top timhare Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Fri May 03, 2013 7:36 pm Joined: Fri Jan 06, 2006 3:21 pm Posts: 12295 Location: Portland, OR USA One simple approach is to give sub-window2 a pointer to the window1 that created it. Add a property to sub-window2 parentwindow as window1 When window1 creates sub-window2, it sets the parentwindow to itself. dim sw as sub-window2 sw = new sub-window2 sw.parentwindow = self Better, give sub-window2 a constructor that takes a window1 parameter and sets parentwindow dim sw as sub-window2 sw = new sub-window2(self) sub-window2 can now refer to the control on its parent window dim s as string = parentwindow.textfield1.text To be a little more OOP, give window1 a method that returns the value from textfield1. That way, sub-window2 doesn't need to know the details of where the value came from, so its code won't break if you decide to change the field's name, or even display it in a totally different way. HTH, Tim Top symbiount Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Fri May 03, 2013 9:13 pm Joined: Thu Oct 12, 2006 2:32 pm Posts: 31 Thanks Tim, unfortunately this doesn't solve the problem. I can refer to controls on a window that's instantiated without an alias, it's one that is aliased that presents the problem. As in: w.show [from w] dim sw1 as subwindow2 [from sw1] dim sw2 as subwindow5 There's no way for sw1 to reference a control on sw5 or vice-versa, or, for that matter, for w to reference a control on either sw1 or sw2. The compiler chokes every time because, presumably, the references don't exist during compilation. I'd love to be wrong on this but I can't find a way to resolve it. Top timhare Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Sat May 04, 2013 1:08 am Joined: Fri Jan 06, 2006 3:21 pm Posts: 12295 Location: Portland, OR USA I just showed you one way to do it. You have to give one of them a reference to the other one. And if it has to go both ways, make one of the references a weak reference so you don't create a circular link. Top kermit Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Sat May 04, 2013 10:24 am Joined: Mon May 30, 2011 12:56 am Posts: 679 tim is right In case you are struggling with that, if there is only ever going to be one sw1 , sw2, sw5 etc, then implicit will do it. Another way is to assume there is only ever 1 sw1, sw2 ACTIVE at any time. If that can be true, add properties to app app.sw1 as Window1 app.sw2 as Window2 and so on When an instance of Window2 opens or gets focus, it could do this: app.sw2 = self Then anywhere in your code you could do this: is app.sw2 is not nil then app.sw2.listbox1.add "Hello!" end if But all that is just a suggestion based on you not taking Tim's code examples on board yet... Top Thom McGrath Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Sat May 04, 2013 11:23 am Site Admin Joined: Tue May 06, 2008 1:07 pm Posts: 1436 Location: NotEvenOnTheMap, CT Turn off implicit instance on both sw1 and sw2. It's evil and should be avoided, which is always possible. I'm assuming in this scenario that sw2 will always be created from sw1. In this design, I'm assuming Window2 will always be created by and paired with a parent Window1. Here's a project that should give you an idea how to approach this. https://www.dropbox.com/s/uzw6fhyel4yxy0i/Comm%20Between%20Windows.rbp _________________ Thom McGrath - @tekcor Web Framework Architect, Real Software, Inc. Top symbiount Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Sat May 04, 2013 5:54 pm Joined: Thu Oct 12, 2006 2:32 pm Posts: 31 I understand what Tim was suggesting as well as Kermit and Thom, however, it doesn't work for the scenario presented. The assumptions being made are not in alignment with the reality of what Iâm working with. Although I appreciate and thank you all for the help offered. Ultimately, this has nothing to do with ImplicitInstance. As I mentioned earlier in describing the usage, the windows are all created in code using a single base window and many container controls. In most cases a single window will be utilizing multiple containers. Multiple instances of any given window are assumed and expected. There are certain windows which would have little value if they werenât allowed multiple instances. In some cases there will be multiple instances from a single parent and in others there will be multiple instances from multiple parents and in yet others there will be a single child needing to be accessed by multiple parents or needing to access those parents itself, or both. There is no certainty whatsoever as to who the parent might be nor should that matter. Nearly all of the windows can be created in multiple places and for varying purposes. There is absolutely no way to use any kind of pairing structure nor can any specific window hierarchy be assumed. In fact, there really is no hierarchal structure to the windows nor can there be. There are cases where a window that would be considered the parent is closed but itâs necessary to keep some, but not all, of the windows it created open. The goal is to be able to read and write to EVERY window from ANY window. There is also the additional requirement that a session state must be able to be saved and re-started at a later time precisely as it was when it was closed. This is why none of the solutions offered are workable. Once again, many thanks for the suggestions! Top timhare Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Sat May 04, 2013 11:51 pm Joined: Fri Jan 06, 2006 3:21 pm Posts: 12295 Location: Portland, OR USA Then you need some way of identifying any given window, so you know who you're talking to. Then it's a matter of iterating through all the open windows, finding the one you want, and casting it as appropriate so you can access its methods and properties. This is all very doable, and can even be rather easy/elegant. Define methods and functions to do all the interaction. Try to name them as descriptively as possible - that will help you organize your thoughts. Then you can group the interactions into logical groups and create a Class Interface for each grouping. You can use the interface name as a variable type instead of each window name. One interface can suffice for many windows. For example, if window1, window2 and window3 all implement an "UpdateProgress" interaction - ie., any other window can tell any of those windows to update some progress indicator - then you can add an interface, ProgressUpdator, with a method UpdateProgress. Add that method to each of window1, window2 and window3. Then instead of saying if window(n) IsA window1 then window1(window(n)).UpdateProgress(x) elseif window(n) IsA window2 then window2(window(n)).UpdateProgress(x) elseif window(n) IsA window3 then window3(window(n)).UpdateProgress(x) end You can just say if window(n) IsA ProgressUpdator then ProgressUpdator(window(n)).UpdateProgress(x) end It can save a lot of code, as well as keeping things grouped logically. HTH, Tim Top symbiount Post subject: Re: ImplicitInstance Off and Inter Window CommunicationPosted: Sun May 05, 2013 1:59 pm Joined: Thu Oct 12, 2006 2:32 pm Posts: 31 The solution, in this particular case, is to simply ignore the windows altogether. Since they have no controls tracking them wouldnât accomplish much anyway. Also, accessing the controls within the containers that are embedded in the windows is cumbersome, at best. Iterating and then casting would just add unnecessary overhead from my perspective, as well as not really supplying all the information the new window needs. Much easier to ignore the windows and just deal with the containers (and the occasional, individual, on-the-fly controls). As soon as I did that it became quite simple and fully functional. Everything now knows who it is and where it came from as well as what itâs being asked to do. Thatâs all I was really looking for since saner clients would be a less reasonable expectation! Thanks again, Tim. Top Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending Page 1 of 1 [ 11 posts ]
-- Over 1500 classes with 29000 functions in one REALbasic plug-in collection. The Monkeybread Software Realbasic Plugin v9.3. http://www.monkeybreadsoftware.de/realbasic/plugins.shtml [email protected]
