This is communication-between-objects in view mode; [Up]
Date: Sun 31-Aug-1989 15:23:28 From: Unknown Subject: communication between objects Thanks to the advice of Bill Parod, I now have a custom subclass of ScrollView displaying a matrix of buttons (Hooray!). Now, all I have to do is figure out how to let the outside world know how that one of the buttons has been pushed. What I think I need to do is to set the target of the Matrix to the ScrollButtons object (my custom object), and set the target method to some method of ScrollButtons that will report to the outside world. Beyond that, I'm not sure what needs to be done. I want my different objects to be fairly independent of each other, in order that it will be simple to modify one without messing up the other.... Going on what meager knowledge I have now, what I would like to do is have some central controlling object that will coordinate how the other objects interact with each other. Call this object "mediator". The other objects will be (probably) an OpenPanel to select a directory to work in, the ButtonScroll, and a Displayer/ Searcher object which will search for references and take requests to display them. The idea is that whenever the user diddles some control or another, the interface will message the mediator in its own particular way. The mediator, once messaged, will get the needed information out of the messaging object, then call the appropriate messages and functions to get the job done. For example, there is a text field in which the user may type keywords. When the user hits a "search" button, the button will message the mediator (just like the one-button calculator in the IB tutorial). The mediator will then message the Displayer/ Searcher, and ask it to search for the proper keywords. After that is done, the mediator can ask the Displayer/Searcher for all the file names of everything it found (perhaps one at a time). The mediator can then message the ButtonScroll to clear itself and display the individual file names. The advantage I see to the "mediator" approach is that the different object that do the work don't have to know anything about each other. The mediator can coordinate them all. One problem I saw with the way the one-button calculator is implemented in the tutorial is that the Calculator object had to take its input from a text form--nothing else would do, what with the selectTextAt: method. My way, you can easily set up different objects to interact with each other. I think I have a good idea of what I want to do. The only problem is that I have no idea how to do it. I want to be able to connect everything together with the interface builder, but I have no idea how to write an object so that is possible. The different objects need to be bound together at runtime, and I'm pretty sure I need to use outlets to do it, but how? For the tutorial, I just used the Classes window in IB to set up a couple of outlets, but I don't know what that actually did. There was a bunch of business about setInputForm & such that was automatically written for me. If I tried to use the Classes window and selected UNPARSE, wouldn't that destroy all the stuff I've already done? Would I be ok if I did a PARSE first? Basically, I want there to be no code in by ButtonScroll class about the mediator. I don't want it to instantiate the object; that should happen on startup. I want the ButtonScroll, when a button has been hit, to send out some message to it doesn't know where that just says, "I've been hit. Do what you will." This message should have the effect of messaging some method (specified in IB) in the mediator object that can ask the ScrollView "where were you hit?" (which button). The mediator method, now that it knows which button was hit, can message some object to tell it to display a file. While the mediator should know the the name of the methods of this object, it shouldn't know the actual kind of object there (polymorphism--different object, same method names), and shouldn't have to instantiate it. There should be some way that IB can create the object and let the mediator know what the id is (outlet?) before the application actually starts running. Does anyone have any ideas on all of this stuff? I know I'm beating this into the ground, and I'm actually not quite as ignorant as I'm acting, but I figure too much information is better than not enough. In a nutshell, my question is: "How do get my brand-spanking-new object to do something when someone hits a button on it?" | Dan Zerkle home:(805) 968-4683 morning:961-2434 afternoon:687-0110 | | dz@cornu.ucsb.edu dz%cornu@ucsbuxa.bitnet ...ucbvax!hub!cornu!dz | | Snailmail: 6681 Berkshire Terrace #5, Isla Vista, CA 93117 | | Disclaimer: If it's wrong or stupid, pretend I didn't do it. | >From: carlson@mrcnext.cso.uiuc.edu
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.