Should images returned from NSTableView's dragImageForRowsWithIndexes be autoreleased?

  • Greetings,

    I have a table subclass that implements
    dragImageForRowsWithIndexes:::: and have random
    reports of a crash while in the drag loop code (not my
    own) that makes me wonder about the images that are
    created in the implementation: should images alloc'd
    in this call be "leaked" i.e. not released, not
    autoreleased, or should they be autoreleased? Right
    now I autorelease them, and I can't really find
    anything in the documentation or the list that
    specifies the actual image retention explicitly.

    Thanks,

    Michael


    ____________________________________________________________________________________
    Need a vacation? Get great deals
    to amazing places on Yahoo! Travel.
    http://travel.yahoo.com/
  • On Sep 24, 2007, at 2:20 PM, Michael Dupuis wrote:

    > I have a table subclass that implements
    > dragImageForRowsWithIndexes:::: and have random
    > reports of a crash while in the drag loop code (not my
    > own) that makes me wonder about the images that are
    > created in the implementation: should images alloc'd
    > in this call be "leaked" i.e. not released, not
    > autoreleased, or should they be autoreleased? Right
    > now I autorelease them, and I can't really find
    > anything in the documentation or the list that
    > specifies the actual image retention explicitly.

    You should assume that, unless an exception is specifically called
    out, that the standard object ownership rules apply.

    Jim
  • Of course they should be autoreleased. It follows the general rules
    for retaining objects: unless a method name starts with "copy" or
    "init", the returned object should not be explicitly retained (unless
    the object is kept around in an ivar or a global instance of course,
    which here is probably not the case).

    Christiaan

    On 24 Sep 2007, at 8:20 PM, Michael Dupuis wrote:

    > Greetings,
    >
    > I have a table subclass that implements
    > dragImageForRowsWithIndexes:::: and have random
    > reports of a crash while in the drag loop code (not my
    > own) that makes me wonder about the images that are
    > created in the implementation: should images alloc'd
    > in this call be "leaked" i.e. not released, not
    > autoreleased, or should they be autoreleased? Right
    > now I autorelease them, and I can't really find
    > anything in the documentation or the list that
    > specifies the actual image retention explicitly.
    >
    > Thanks,
    >
    > Michael
    >
  • On 24 Sep 2007, at 1:20 PM, Michael Dupuis wrote:

    > I have a table subclass that implements
    > dragImageForRowsWithIndexes:::: and have random
    > reports of a crash while in the drag loop code (not my
    > own) that makes me wonder about the images that are
    > created in the implementation: should images alloc'd
    > in this call be "leaked" i.e. not released, not
    > autoreleased, or should they be autoreleased? Right
    > now I autorelease them, and I can't really find
    > anything in the documentation or the list that
    > specifies the actual image retention explicitly.

    By the rules of object ownership for memory management (which I won't
    fully summarize here), you must not release or autorelease any object
    returned from a method not containing "alloc", "new", or "copy" in its
    name.

    -- F
  • Thanks for the replies. They were what I expected, I
    was just checking, since I can't see to put my finger
    on what else could be causing my crash. Thanks all for
    ruling this out at least.

    Michael


    ____________________________________________________________________________________
    Got a little couch potato?
    Check out fun summer activities for kids.
    http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+k
    ids&cs=bz
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today