combs@sumex-aim.stanford.edu (Dave Combs) (07/21/89)
Gang, Any comments on the following? I've consistently run into a problem when I copy something like a Button object, which contains a cell of another class (Controls do this a lot). The problem is that when the Button is copied, the ButtonCell that it contains is not. If I subsequently free the copied Button, I lose the ButtonCell, and my initial Button dies if I try to use it. Are ButtonCells supposed to be shared between buttons? (I doubt it, since their "contents" field is really in the cell, not the Control). If not, I presume this is a bug that should be fixed. Thanks, Dave (combs@sumex-aim.stanford.edu)
jpd00964@uxa.cso.uiuc.edu (07/24/89)
> The problem is that when the Button is copied, the ButtonCell that it > contains is not. What do you mean "copy" the Button. You should be just calling [Button new] which will make a copy for you. This will also initialize a field that tells the control what kind of cells your entire Button matrix uses. Each button you create this way should have a unique cell. Michael Rutman Softmed
combs@sumex-aim.stanford.edu (Dave Combs) (07/25/89)
Michael, If I want to make a direct copy of a Button, INCLUDING all its various properties (action, key, enabled, etc.), the copy method (either in Button itself or through the global Object method) should be either explicitly allowed, or explicitly disallowed (by overriding with a null-action method, for example). I don't believe it is reasonable to expect that to duplicate a button I have to make a new button, then go through each of the properties in the new button and set each one to the result of fetching the same property from the original button. That's what "copy" is supposed to do for me. Otherwise, why have it? Also, I'm not assuming these two Buttons are in a matrix. (I've had similar problems trying to free unused cells in a matrix and having one free corrupt the prototype cell from which the matrix elements were created). Once again, is it an error to send "copy" to a Button and expect it to generate a copy of the ButtonCell, too? As is, if I free the second Button, the first is subsequently corrupted because its ButtonCell is released. (At the very least, this is inconsistent--if you create a copy without copying the ButtonCell, you should free the copy without freeing the ButtonCell. Correct?) Comments? Dave
ali@polya.Stanford.EDU (Ali T. Ozer) (07/26/89)
In article <23996@labrea.Stanford.EDU> Dave Combs writes: >I've consistently run into a problem when I copy something like a Button >object, which contains a cell of another class (Controls do this a lot). >The problem is that when the Button is copied, the ButtonCell that it >contains is not. If I subsequently free the copied Button, I lose the >ButtonCell, and my initial Button dies if I try to use it. "copy" is supposed to make a copy of only the top level object; all referenced objects are shared. There's another method, "deepCopy," I believe, that duplicates the whole tree of objects. Problem with copy is that it's not always enough, as in the case of Button. Problem with deepCopy is that you might end up with more than you need --- on deepCopy of a view, for instance, you might find yourself with two windows. You want a "functionalCopy," which is not provided. Most AppKit objects are too complex for a simple "copy" or "deepCopy" to suffice. Ali Ozer, NeXT Developer Support aozer@NeXT.com
ali@polya.Stanford.EDU (Ali T. Ozer) (07/27/89)
In article <10884@polya.Stanford.EDU> aozer@NeXT.com (Ali T. Ozer) writes: >"copy" is supposed to make a copy of only the top level object; all >referenced objects are shared. There's another method, "deepCopy," I believe, >that duplicates the whole tree of objects. Yet another example of Why One Shouldn't Read News Unless One Has Had At Least One Coffee That Morning. I'm wrong above; I just got a chance to look through the ObjC docs in the Appendices volume of the Tech Docs, and it says that the copy method is supposed to make a duplicate of the object, duplicating as much of the referenced stuff as reasonable. I was confusing "copy" with "shallowCopy." Given this, it does indeed seem like Button (and various other AppKit objects) do not respond properly to the "copy" method. I'll make a suggestion concerning this... Ali Ozer, NeXT Developer Support aozer@NeXT.com
ali@polya.Stanford.EDU (Ali T. Ozer) (08/05/89)
In article <10906@polya.Stanford.EDU> aozer@NeXT.com (Ali Ozer) writes: >Given this, it does indeed seem like Button (and various other AppKit >objects) do not respond properly to the "copy" method. I'll make a >suggestion concerning this... I did get back one valuable piece of information concerning making copies of objects: Provided the object is able to read or write itself (and all AppKit objects do), use the typedstream package to copy objects: // We want to make a copy of object obj. int length; char *buf = NXWriteRootObjectToBuffer (obj, &length); copyOne = NXReadObjectFromBuffer (buf, length); copyTwo = NXReadObjectFromBuffer (buf, length); // Make as many copies as you wish... ... // Then free the buffer NXFreeObjectBuffer (buf, length); Ali Ozer, NeXT Developer Support aozer@NeXT.com