Path: utzoo!attcan!utgpu!watmath!att!rutgers!ucsd!usc!apple!mips!prls!pyramid!leadsv!esl!esl.ESL.COM!dml From: dml@esl.com (Denis Lynch) Newsgroups: comp.sys.next Subject: Re: Interface Builder Message-ID: Date: 15 Nov 89 22:23:46 GMT References: <770001@hpvcfs1.HP.COM> <680016@hpcuhc.HP.COM> Sender: news@esl.ESL.COM Organization: ESL Inc., Sunnyvale, CA Lines: 78 In-reply-to: edwardm@hpcuhc.HP.COM's message of 14 Nov 89 18:32:00 GMT In article <680016@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: Steve Miller writes: > I saw a demonstration of the NeXT yesterday and have a couple of questions > on the Interface Builder (IB), especially from people who are familiar with > Prototyper on the Mac. > However, one concern that I have is when you finally build you interface and > then you add all of you custom code to do the special things you program is > ment to do, can you go back to IB and change things without any grief. Although I'm not familiar with Prototype, I echo your concern. But the worst thing is that you're not familiar with the NeXT either! I have seen a similar tool here at HP that DOES allow one to modify the interface. The basic idea with this tool is that you define "callbacks" (functions) for events. These functions are defined in #include files which are not modified by the interface builder. Unfortunately, the NeXT IB requires you to modify the files it generates. I presume you are speaking of UIMX. The facilities of the two are not all that different. IB maintains its own files of what UI objects connect to what program objects, and what messages the UI objects send. UIMX does too. But UIMX eventually writes out UIL, which you are free to modify at your peril. The NeXT files you may be alluding to are the Objective C class definition files that IB will generate for you *as a convenience*. So consider a scenario where you are building a program and its interface. You connect a UI widget (say a button) to some object in the program (a valueController). You say that this button should send the reset message to the valueController. So what really happened here? You gave IB a spec for the valueController class, so it would know which messages can be sent to one of its instances. You can do this in two ways: you can tell IB to read in a class definition, or you can manually enter the class description and tell IB to generate the Objective C code. Now you want to change the class specification. You can do that either by editing the Objective C code, or by modifying the class description within IB. If you edit the source code, you can then ask IB to read it in and update its version of the specification. If you modify the class description within IB, then you have two choices again: ask IB to generate the Objective C code again, or modify the code by hand. If you choose the first path, then any changes you put in (like putting real code in those methods!) will be lost. Whoops. The second isn't real cute either, since there are no guarantees you make the same modes. So the moral is, if you're going to modify a class definition then modify the Objective C code and tell IB to go find out what you did. But the real question seems to be about something else entirely: what happens if you want to change the appearance of the UI object, or what it connects to, or what message it sends? In this case, IB does precisely the right thing: it keeps all this in data structures, it *never* generates code. You use IB to modify the data structures, even after the program is "delivered." For packaging convenience, NeXT applications are generally shipped with the IB description imbedded in a segment in the applications' Mach-O executable files. But they can still be extracted, edited with IB, and put back. So IB provides exactly the most important capability: you can modify the interface appearance and behavior well beyond the last minute, and without ever touching any code! Sorry to go on for so long, but all this discussion about how the software *might* work inspire me to "set the record straight." Denis Lynch ESL, Inc.