ftp.nice.ch/peanuts/GeneralData/Usenet/news/1989/CSN-89.tar.gz#/comp-sys-next/1989/Jan-Apr/Interface-Builder-question

This is Interface-Builder-question in view mode; [Up]


Date: Sun 23-Feb-1989 01:39:47 From: Unknown Subject: Interface Builder question I'm building a distributed mail application for the NeXT. It has a bunch of windows, only one of which is visible at startup. The other windows (a "mailbox", "read", and "send" window) all have been defined via IB and set as not visible at application launch through the inspector. I can -- and will -- have many instances of these windows on the screen at the same time. Every time I read a message I'll get a new read window, etc. So, really the windows I defined via IB (which have a scrolling text view and some buttons) are prototypes for the windows I will create. However, I am at a total loss for how I should instantiate these windows. If I call the "new" factory method for the class associated with each of these windows, then what I get is the tiny default window made by [Window new]. I'm almost at the point where I am going to have Interface Builder decompile the interface, in which case I can get what I need I need from the buildInterface() function. However, this would mean punting Interface Builder for any future changes in the interface. It also means having to write the code for all those connections. Any ideas? Oh, does anyone know if it is possible to have a menu which is attached to (and associated with) a window instead of the main menu? In other words, I want something that looks like a menu (including having submenus), attaches as a separate square to one of my windows, but otherwise is like a button. Interface Builder makes all menus come under the main menu, which is not what I want. -- Mark -- >From: ali@polya.Stanford.EDU (Ali T. Ozer)
Date: Sun 23-Feb-1989 15:30:06 From: Unknown Subject: Re: Interface Builder question In article <944@blake.acs.washington.edu> Mark Crispin writes: > I can -- and will -- have many instances of these windows on the >screen at the same time. Every time I read a message I'll get a new >read window, etc. So, really the windows I defined via IB (which have >a scrolling text view and some buttons) are prototypes for the windows >I will create. > > However, I am at a total loss for how I should instantiate these >windows. If I call the "new" factory method for the class associated >with each of these windows, then what I get is the tiny default window >made by [Window new]. To create a new window without using IB, use the newContent:style:backing:buttonMask:defer: method in Window. It creates an offscreen window which can be brought on screen with orderFront:. You can use setContentView: and addSubview: to add your own buttons/sliders/views/etc to such a window. Please don't decompile interfaces in IB; the resulting code isn't complete or reliable. There's actually a nice way to generate the prototype window in IB. From the "New..." window, choose "New Object." (This lets you create a new object class independent of any application.) Create your window within the context of this "New Object" project, and save and decompile it. You will get a .nib file which contains the definition of your window and a .m file that contains the method to instantiate such a window, including all the views inside it... All your application has to do is call this object's "new" method to instantiate a window. Hope this helps. Ali Ozer, aozer@NeXT.com NeXT Developer Support >From: abe@mace.cc.purdue.edu (Vic Abell)
Date: Sun 24-Feb-1989 03:12:09 From: Unknown Subject: Re: Interface Builder question Yes, the "Custom Object" facility of "New..." does exactly what I wanted; to prototype a window which I can create arbitrarily many of from my application. Of course, what you get back from the "new" method is the object, not the window, so you need to have a socket from the window to the object so you can store it away in an instance variable. Now, about those menus... I see no way in IB to create a menu. You can add to the existing MainMenu tree, but that isn't always what you want. I want to have, attached to (as opposed to contained within) my window, a menu of operations that are only appropriate to that window. I know about buttons, and in fact I have a row of buttons on the bottom of my window for certain operations. But, what I need for this is too hairy for buttons. I spent several frustrating hours with IB trying to do what I wanted with Cut/Paste, and ended up throwing in the towel. I admit to not understanding very well how IB Cut/Paste work, due in part to the incomplete feedback IB gives and the existance of too many states in IB that "don't do anything." Anyway, this is the sort of window I would like to put up: _________________________________________________ | |Menu1 >| | |Menu2 | | |_______| | | | | | | | | |_______________________________________| |Button | Button | Button | Button| ----------------------------------------- Certain very basic operations are on the bottom of the window as buttons, and the more complex items are on the side as a menu. If I made the side items into buttons it'd make the window unpleasantly fat (not to mention that there are several levels of submenus from that side menu). I don't think this can be done with IB. Can it be done with the present version of the Appkit at all? -- Mark -- >From: leach@neptune.uucp (Tom Leach)

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.