Jon,You're right... Formatters are implecitly encoded and decoded if attached to the text field cell. And to duplicate a text field with ibDidAddToDesignableDocument generates an assertion failure, too.
I finally use - [IBPlugin document:didAddDraggedObjects:fromDraggedLibraryView:] and it effectively solves the problem. Here is the code I've added to the object that inherits from IBPlugin :
- (void)document:(IBDocument *)document didAddDraggedObjects:(NSArray *)roots fromDraggedLibraryView:(NSView *)view
{
NSObject *object;
int i;
for (i=0; i<[roots count]; i++)
{
object = [roots objectAtIndex:i];
if ([object isKindOfClass:[testIBView class]])
[document addObject:[(testIBView *)object formatter]
toParent:object];
}[super document:document didAddDraggedObjects:roots fromDraggedLibraryView:view];
}I've tried not to not use an outlet and to parse the dragged objects to look for testIBView ones. This works fine...
Thanks again for the time you spent to help me ! Cyril. Le 8 août 08 à 10:37, Jonathan Hess a écrit :
Hey Cyril -I'm glad my advice helped. There's a couple of things I neglected to mention.If your text field is a subclass of NSControl, you should add the formatter as a child of the NSCell, not the NSTextField. In Cocoa, it's actually the cell that conceptually owns the formatter, and Interface Builder's integration of NSCell expects the formatter to be a child of the NSCell. Another point of interest is that the method ibDidAddToDesignableDocument will be invoked every time an instance is added to a document. This can happen in more ways than dragging an object from the library. For example, you could copy and paste the text field. If you did this, after pasting, the new text field would already have it's formatter as a child, and the call to ibDidAddToDesignableDocument would cause the formatter to be added a second time, which would likely lead to an assertion failure.If you only want to perform this action after the user drags from the library, try this method instead:- [IBPlugin document:didAddDraggedObjects:fromDraggedLibraryView:]You'll need to have an outlet to the view that represents your text view in the library in order to decide that the draggedObjects are the result of dragging your text field instance.A final point. Interface Builder's integration of NSControl and NSCell should provide all the code you need to work with a cell that is attached to a control. Typically, dragging a control with a cell from the library will cause the cell to automatically be added to the document. Did you perhaps override the method -[NSObject ibDefaultChildren] but not incorporate the results of [super ibDefaultChildren] into the array you returned? NSCell's implementation of that method is typically responsible for the initial integration of a formatter into an Interface Builder document after dragging a cell with a formatter from the library.In general, most of the callbacks in IBObjectIntegration.h, and IBViewIntegration.h expect you to call through to super. If you decide to stick with your override of ibDidAddToDesignableDocument, it should include a call to [super ibDidAddToDesignableDocument:document].Good luck - Jon Hess On Aug 8, 2008, at 12:17 AM, Cyril Kardassevitch wrote:Thanks a lot Jon !This perfectly solves the issue ! So, to verify that I do it correctly... I've overloaded the ibAddToDesignableDocument notification message into the testIBView integration category :- (void)ibDidAddToDesignableDocument:(IBDocument *)document { [document addObject:[self formatter] toParent:self]; }This seems to work even if, contrary to your indication, this adds the formatter to the document after it is attached to the text field... Tell me if this is wrong, but this is the only way I've found to allow a resonnable separation between the inherited text field object and its integration to interface builder.Thanks again, Cyril. Le 8 août 08 à 07:05, Jonathan Hess a écrit :Hey Cyril -How are you adding the formatter to the text field? After you add the formatter, does it appear as a child of the text field in the document outline view? If not, that's your problem. Interface Builder maintains a tree of all of the objects in the document. If you do something like call '[textField setFormatter:myFormatter]' where textField is a text field in an Interface Builder document, but formatter hasn't been added to the same document, then you'll run into this sort of issue. Just make sure to invoke -[IBDocument addObject:myFormatter toParent:myTextField] before calling [myTextField setFormatter:myForamtter].Hope that clears up your issue - Jon Hess On Aug 7, 2008, at 2:02 AM, Cyril Kardassevitch wrote:hi,I have designed customs NSTextField and NSFormatter objects that I have tried to pack in an interface builder 3 plugin...This works fine (can drag and drop the field, can access field inspector), except that when I select the formatter, interface builder generates an assertion failure with :Backtrace:1. Interface Builder 0x00006620 [IBApplication handleAssertion:inFile:onLine:] 2. InterfaceBuilderKit 0x0021bed4 [Ithanks a lot BObjectContainer objectIDForObject:] 3. InterfaceBuilderKit 0x0021c0ec [IBObjectContainer metadataForKey:ofObject:] 4. InterfaceBuilderKit 0x00224e84 [IBDocument customClassNameForObject:] 5. InterfaceBuilderKit 0x00224e0c [IBDocument classNameForObject:] 6. InterfaceBuilderKit 0x0023f210 [IBDocument commonCustomClassNameOfObjects:] 7. InterfaceBuilderKit 0x0023f15c [IBInspectorController computeTitle] 8. InterfaceBuilderKit 0x0023f08c [IBInspectorController refresh] 9. InterfaceBuilderKit 0x0023b630 [IBInspectorController rebuildInspectorStack] 10. InterfaceBuilderKit 0x0023b4c0 [IBInspectorController validate:]...The NSTextField and NSFormatter child have their own working plugins, and there is absolutely no problem if I combine the 2 above objects manually in interface builder. The field and its formatter are then fully accessible and designable.I've tried various things without success. Has anyone got a tip on how to expose a programmatically attached formatter ?Thanks. Cyril. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)Please do not post admin requests or moderator comments to the list.Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/jhess%40apple.com This email sent to [EMAIL PROTECTED]
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
