Menu
▾
▴
rubycocoa-talk — talking about RubyCocoa
You can subscribe to this list here.
| 2002 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(1) |
Feb
(11) |
Mar
(9) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(4) |
Aug
(3) |
Sep
(15) |
Oct
(8) |
Nov
(9) |
Dec
(11) |
| 2004 |
Jan
(5) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(6) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
(3) |
| 2005 |
Jan
(1) |
Feb
(7) |
Mar
(6) |
Apr
(36) |
May
(20) |
Jun
(42) |
Jul
(21) |
Aug
(12) |
Sep
(56) |
Oct
(5) |
Nov
(55) |
Dec
(53) |
| 2006 |
Jan
(43) |
Feb
(83) |
Mar
(98) |
Apr
(42) |
May
(68) |
Jun
(55) |
Jul
(50) |
Aug
(104) |
Sep
(13) |
Oct
(70) |
Nov
(37) |
Dec
(42) |
| 2007 |
Jan
(56) |
Feb
(18) |
Mar
(43) |
Apr
(80) |
May
(65) |
Jun
(149) |
Jul
(103) |
Aug
(71) |
Sep
(62) |
Oct
(67) |
Nov
(72) |
Dec
(63) |
| 2008 |
Jan
(64) |
Feb
(63) |
Mar
(31) |
Apr
(42) |
May
(71) |
Jun
(62) |
Jul
(37) |
Aug
(25) |
Sep
(5) |
Oct
(2) |
Nov
(7) |
Dec
(14) |
| 2009 |
Jan
(20) |
Feb
(15) |
Mar
(19) |
Apr
(8) |
May
(7) |
Jun
|
Jul
(37) |
Aug
(12) |
Sep
(19) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
| 2010 |
Jan
(5) |
Feb
(24) |
Mar
(16) |
Apr
(9) |
May
(4) |
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(5) |
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Eloy D. <elo...@gm...> - 2008-05-30 18:32:26
|
I would expect to use view.animator.setFrame(), which doesn't work for me. I had the feeling I might miss some critical step for my view to become usable with CA, like rendering an image or something like that. On 30 mei 2008, at 19:05, Patrick Geiller wrote: >> But I have a custom view which does a lot of drawing and I want to >> animate that together with the other views. Basically the only >> thing I >> want it to do is move the origin, but it just completely moves at >> once >> instead of animating it.... > > > Just tried it … moving with setFrameOrigin moves instantly, moving > with setFrame animates. Which function are you moving your view with ? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Patrick G. <pge...@wa...> - 2008-05-30 18:06:25
|
> But I have a custom view which does a lot of drawing and I want to > animate that together with the other views. Basically the only thing I > want it to do is move the origin, but it just completely moves at once > instead of animating it.... Just tried it … moving with setFrameOrigin moves instantly, moving with setFrame animates. Which function are you moving your view with ? |
|
From: Eloy D. <elo...@gm...> - 2008-05-30 16:31:48
|
Hiya all, I'm playing with CA a bit and can't seem to figure a problem out. I can use the animator proxy on all kinds of views with no problem at all and group them etc. But I have a custom view which does a lot of drawing and I want to animate that together with the other views. Basically the only thing I want it to do is move the origin, but it just completely moves at once instead of animating it.... I must probably do something special with the custom view, but haven't been successful yet. Could someone with more CA knowledge point me to the correct part of the docs? Or better yet, some source? :) Cheers, Eloy |
|
From: Allison N. <dem...@ma...> - 2008-05-30 08:53:02
|
Oh, I'm sure I can find a solution now that I understand what the problem is :-) I think I might just use Cocoa archiving instead of YAML, that should sort things out.
On Friday, May 30, 2008, at 10:16AM, "Eloy Duran" <elo...@gm...> wrote:
>Ah hmm, yeah that would be hard.
>Can't you dump/load the actual data that the Schedule wraps?
>Further than that I wouldn't have a ready solution for you.... :/
>
>Eloy
>
>On 30 mei 2008, at 10:06, Allison Newman wrote:
>
>> Oh, nothing special - classes that I had created myself. I've
>> included an example below. As you can see, there's noting nasty in
>> there. The trick is that apparently objects that are sent to the
>> NSOutlineView need to follow the 'protocol' NSObject, and if that's
>> not the case, there is an error in objc_sendMessage.
>>
>> class Schedule < NSObject
>> attr_accessor :name_str, :days, :dates
>>
>> def initWithName_array(name_str, days_array)
>> init
>> @name_str = name_str
>> @days = days_array
>> self
>> end
>>
>> def self.defaults
>> defaults = []
>> defaults <<
>> Schedule
>> .alloc.initWithName_array(Library.get_localized_string("WEEK_DAYS"),
>> [:monday, :tuesday, :wednesday, :thursday, :friday])
>> defaults <<
>> Schedule
>> .alloc.initWithName_array(Library.get_localized_string("WEEKEND"),
>> [:saturday, :sunday])
>> defaults <<
>> Schedule
>> .alloc.initWithName_array(Library.get_localized_string("EVERY_DAY"),
>> [:monday
>> , :tuesday, :wednesday, :thursday, :friday, :saturday, :sunday])
>> defaults
>> end
>>
>> def isItemExpandable
>> puts "#{self} isItemExpandable"
>> false
>> end
>>
>> def getChild(index)
>> nil
>> end
>>
>> def numberOfChildren
>> 0
>> end
>>
>> end
>>
>> On Friday, May 30, 2008, at 09:24AM, "Eloy Duran" <elo...@gm...
>> > wrote:
>>> What kind of objects that inherit from NSObject are you trying to
>>> save?
>>>
>>> Eloy
>>>
>>> On 30 mei 2008, at 09:13, Allison Newman wrote:
>>>
>>>> OK, I've narrowed down the problem - here's the deal.
>>>>
>>>> When the NSOutlineView calls outlineView_child_ofItem, the
>>>> datasource must return an object that has inherited from NSObject.
>>>> Apparently the object is not treated as an opaque pointer inside the
>>>> NSOutlineView.
>>>>
>>>> However, if you use YAML to serialise an object that inherits from
>>>> NSObject, when you reload the object, the NSObject part is not
>>>> correctly initialised. Conclusion, you can not use objects that are
>>>> saved using YAML in an NSOutlineView.
>>>>
>>>> Phew! That's nasty! The Ruby parts of the reloaded object work
>>>> just fine, it's only when you try to do something Cocoa-ish with it
>>>> that the problems start.
>>>>
>>>> Thanks to everyone that helped me work through this. Is this sort
>>>> of problem already documented somewhere? If not, maybe I could
>>>> write up a quick doc describing the problem, but where should I put
>>>> it so that others can find it?
>>>>
>>>> Alli
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Rubycocoa-talk mailing list
>>>> Rub...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Rubycocoa-talk mailing list
>>> Rub...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Rubycocoa-talk mailing list
>Rub...@li...
>https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
|
|
From: Eloy D. <elo...@gm...> - 2008-05-30 08:16:19
|
Ah hmm, yeah that would be hard.
Can't you dump/load the actual data that the Schedule wraps?
Further than that I wouldn't have a ready solution for you.... :/
Eloy
On 30 mei 2008, at 10:06, Allison Newman wrote:
> Oh, nothing special - classes that I had created myself. I've
> included an example below. As you can see, there's noting nasty in
> there. The trick is that apparently objects that are sent to the
> NSOutlineView need to follow the 'protocol' NSObject, and if that's
> not the case, there is an error in objc_sendMessage.
>
> class Schedule < NSObject
> attr_accessor :name_str, :days, :dates
>
> def initWithName_array(name_str, days_array)
> init
> @name_str = name_str
> @days = days_array
> self
> end
>
> def self.defaults
> defaults = []
> defaults <<
> Schedule
> .alloc.initWithName_array(Library.get_localized_string("WEEK_DAYS"),
> [:monday, :tuesday, :wednesday, :thursday, :friday])
> defaults <<
> Schedule
> .alloc.initWithName_array(Library.get_localized_string("WEEKEND"),
> [:saturday, :sunday])
> defaults <<
> Schedule
> .alloc.initWithName_array(Library.get_localized_string("EVERY_DAY"),
> [:monday
> , :tuesday, :wednesday, :thursday, :friday, :saturday, :sunday])
> defaults
> end
>
> def isItemExpandable
> puts "#{self} isItemExpandable"
> false
> end
>
> def getChild(index)
> nil
> end
>
> def numberOfChildren
> 0
> end
>
> end
>
> On Friday, May 30, 2008, at 09:24AM, "Eloy Duran" <elo...@gm...
> > wrote:
>> What kind of objects that inherit from NSObject are you trying to
>> save?
>>
>> Eloy
>>
>> On 30 mei 2008, at 09:13, Allison Newman wrote:
>>
>>> OK, I've narrowed down the problem - here's the deal.
>>>
>>> When the NSOutlineView calls outlineView_child_ofItem, the
>>> datasource must return an object that has inherited from NSObject.
>>> Apparently the object is not treated as an opaque pointer inside the
>>> NSOutlineView.
>>>
>>> However, if you use YAML to serialise an object that inherits from
>>> NSObject, when you reload the object, the NSObject part is not
>>> correctly initialised. Conclusion, you can not use objects that are
>>> saved using YAML in an NSOutlineView.
>>>
>>> Phew! That's nasty! The Ruby parts of the reloaded object work
>>> just fine, it's only when you try to do something Cocoa-ish with it
>>> that the problems start.
>>>
>>> Thanks to everyone that helped me work through this. Is this sort
>>> of problem already documented somewhere? If not, maybe I could
>>> write up a quick doc describing the problem, but where should I put
>>> it so that others can find it?
>>>
>>> Alli
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Rubycocoa-talk mailing list
>>> Rub...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>>
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
|
|
From: Allison N. <dem...@ma...> - 2008-05-30 08:07:06
|
Oh, nothing special - classes that I had created myself. I've included an example below. As you can see, there's noting nasty in there. The trick is that apparently objects that are sent to the NSOutlineView need to follow the 'protocol' NSObject, and if that's not the case, there is an error in objc_sendMessage.
class Schedule < NSObject
attr_accessor :name_str, :days, :dates
def initWithName_array(name_str, days_array)
init
@name_str = name_str
@days = days_array
self
end
def self.defaults
defaults = []
defaults << Schedule.alloc.initWithName_array(Library.get_localized_string("WEEK_DAYS"), [:monday, :tuesday, :wednesday, :thursday, :friday])
defaults << Schedule.alloc.initWithName_array(Library.get_localized_string("WEEKEND"), [:saturday, :sunday])
defaults << Schedule.alloc.initWithName_array(Library.get_localized_string("EVERY_DAY"), [:monday, :tuesday, :wednesday, :thursday, :friday, :saturday, :sunday])
defaults
end
def isItemExpandable
puts "#{self} isItemExpandable"
false
end
def getChild(index)
nil
end
def numberOfChildren
0
end
end
On Friday, May 30, 2008, at 09:24AM, "Eloy Duran" <elo...@gm...> wrote:
>What kind of objects that inherit from NSObject are you trying to save?
>
>Eloy
>
>On 30 mei 2008, at 09:13, Allison Newman wrote:
>
>> OK, I've narrowed down the problem - here's the deal.
>>
>> When the NSOutlineView calls outlineView_child_ofItem, the
>> datasource must return an object that has inherited from NSObject.
>> Apparently the object is not treated as an opaque pointer inside the
>> NSOutlineView.
>>
>> However, if you use YAML to serialise an object that inherits from
>> NSObject, when you reload the object, the NSObject part is not
>> correctly initialised. Conclusion, you can not use objects that are
>> saved using YAML in an NSOutlineView.
>>
>> Phew! That's nasty! The Ruby parts of the reloaded object work
>> just fine, it's only when you try to do something Cocoa-ish with it
>> that the problems start.
>>
>> Thanks to everyone that helped me work through this. Is this sort
>> of problem already documented somewhere? If not, maybe I could
>> write up a quick doc describing the problem, but where should I put
>> it so that others can find it?
>>
>> Alli
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Rubycocoa-talk mailing list
>> Rub...@li...
>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Rubycocoa-talk mailing list
>Rub...@li...
>https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
>
>
|
|
From: Eloy D. <elo...@gm...> - 2008-05-30 07:24:38
|
Happens to the best of us :) Cheers, Eloy On 30 mei 2008, at 06:32, Allison Newman wrote: > Hi Eloy, > > Thanks for the tips included here for managing frameworks - I know > it's not really RubyCocoa, but then, the whole point of RubyCocoa is > to bring non-Mac ruby programmers into the mac development community, > so I guess I won't be the only person coming here that doesn't know > that :-) > > On a more general note, I update my RC to 0.13.2, but it didn't fix > the problem. So, I back-tracked a little further and discovered that > the problem was occurring before the OutlineView was ever called - > specifically, the problem is in YAML - when I read an array back in > from file, the array is initialised, and has the right size, but any > attempt to access a member of the array fails. I got fooled, because > the one time I tested the initialisation of the array, I had deleted > the file, so I created the array from defaults, not from a YAML > serialisation. Sorry to have wasted everyone's time :-/ I guess I > might end up using Cocoa archiving in the end after all... > > Alli > > > Le 29 mai 08 à 17:28, Eloy Duran a écrit : > >> Simply change the location of the RubyCocoa.framework that your >> project links against, >> by selecting it cmd+i and change the path. >> >> Also there's no problem at all with including the framework with your >> build, your users will never know! :) >> >> I have no idea what the Apple software updater does... >> >> Eloy >> >> On May 29, 2008, at 5:15 PM, Allison Newman wrote: >> >>> Yup, bizarrely, I'm running Leopard 10.5.2, so in principal at >>> least, I should have 0.13.1 >>> >>> I don't really want to take the latest build - I want to be able to >>> distribute this app as a binary, so I'm trying to always build >>> against the standard Leopard install. That said, apparently >>> something isn't right in my setup, as I haven't picked up the latest >>> version distributed with Leopard. Très bizarre! >>> >>> OK, I'm going to try installing the latest version manually, to see >>> what that gives... >>> >>> Actually, does anyone know what the Apple Software Updater does when >>> it upgrades RubyCocoa? Does it destroy the old installed version? >>> Are the two systems installed together (mine in /usr/local/bin or >>> something like that, and Apple's in /bin)? If I'm using my own >>> version in /usr/local/bin, how do I make sure that XCode picks up >>> the right version? >>> >>> I know these are not really RubyCocoa questions, but people here >>> must already know the answers, so... anyone???(hopeful look)... >>> >>> Alli >>> >>> On Thursday, May 29, 2008, at 04:37PM, "Eloy Duran" <e....@su... >>>> wrote: >>>> Ai... That's old. I was planning on discussing a new release for >>>> the >>>> next update on the dev. list tonight. >>>> But you will need to install a newer version of RC to have all the >>>> ducktyping code on NSCFArray. >>>> >>>> Eloy >>>> >>>> On May 29, 2008, at 4:33 PM, Allison Newman wrote: >>>> >>>>> 0.13.0 >>>>> >>>>> >>>>> On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su... >>>>>> wrote: >>>>>> I know a fair bit about RC and it should do it :) >>>>>> Which version of RC are you using? >>>>>> >>>>>> You can check in the terminal: >>>>>> $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" >>>>>> >>>>>> Eloy >>>>>> >>>>>> On May 29, 2008, at 3:59 PM, Allison Newman wrote: >>>>>> >>>>>>> Hi Eloy, >>>>>>> >>>>>>> Yes, I have seen it :-/ >>>>>>> >>>>>>> My own code uses a standard ruby array as you have suggested, >>>>>>> but >>>>>>> when it comes back out of the view in outlineView_child_ofItem >>>>>>> (where the item is the array in question), when I try to do >>>>>>> item[index], my code blows up in the bridge (rbobj_get_ocid: >>>>>>> see my >>>>>>> original post). Interestingly enough, item.size still works >>>>>>> correctly. >>>>>>> >>>>>>> One things is sure - if I add methods to my array before handing >>>>>>> it >>>>>>> to the NSOutlineView, when I get it back those methods are no >>>>>>> longer >>>>>>> available. From that I gather that the object is modified >>>>>>> whilst >>>>>>> crossing the bridge. Maybe this is a bug, or maybe it's just >>>>>>> simply >>>>>>> that the RubyCocoa bridge was never intended to support this >>>>>>> kind of >>>>>>> use. Who knows the bridge well enough to decide? >>>>>>> >>>>>>> Anyway, as always, thanks for the reply. >>>>>>> >>>>>>> Alli >>>>>>> >>>>>>> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >>>>>>>> wrote: >>>>>>>> Hi Allison, >>>>>>>> >>>>>>>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>>>>>>> It has code for an outline view in MyPDFDocument.rb, >>>>>>>> >>>>>>>> it does use a NSMutableArray afaik, but it should be >>>>>>>> ducktypable by >>>>>>>> now. >>>>>>>> So ary.childAtIndex(index) could be written as arr[index]. >>>>>>>> So I wouldn't worry about that too much. Also if you send a >>>>>>>> plain >>>>>>>> ruby >>>>>>>> array through the bridge >>>>>>>> it will automatiucally be converted to a NSMutableArray. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Eloy >>>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------- >>>>>>> This SF.net email is sponsored by: Microsoft >>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>>> _______________________________________________ >>>>>>> Rubycocoa-talk mailing list >>>>>>> Rub...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by: Microsoft >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>> _______________________________________________ >>>>>> Rubycocoa-talk mailing list >>>>>> Rub...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> Rubycocoa-talk mailing list >>>>> Rub...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Rubycocoa-talk mailing list >>>> Rub...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>> >>>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Eloy D. <elo...@gm...> - 2008-05-30 07:23:54
|
What kind of objects that inherit from NSObject are you trying to save? Eloy On 30 mei 2008, at 09:13, Allison Newman wrote: > OK, I've narrowed down the problem - here's the deal. > > When the NSOutlineView calls outlineView_child_ofItem, the > datasource must return an object that has inherited from NSObject. > Apparently the object is not treated as an opaque pointer inside the > NSOutlineView. > > However, if you use YAML to serialise an object that inherits from > NSObject, when you reload the object, the NSObject part is not > correctly initialised. Conclusion, you can not use objects that are > saved using YAML in an NSOutlineView. > > Phew! That's nasty! The Ruby parts of the reloaded object work > just fine, it's only when you try to do something Cocoa-ish with it > that the problems start. > > Thanks to everyone that helped me work through this. Is this sort > of problem already documented somewhere? If not, maybe I could > write up a quick doc describing the problem, but where should I put > it so that others can find it? > > Alli > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Allison N. <dem...@ma...> - 2008-05-30 07:13:17
|
OK, I've narrowed down the problem - here's the deal. When the NSOutlineView calls outlineView_child_ofItem, the datasource must return an object that has inherited from NSObject. Apparently the object is not treated as an opaque pointer inside the NSOutlineView. However, if you use YAML to serialise an object that inherits from NSObject, when you reload the object, the NSObject part is not correctly initialised. Conclusion, you can not use objects that are saved using YAML in an NSOutlineView. Phew! That's nasty! The Ruby parts of the reloaded object work just fine, it's only when you try to do something Cocoa-ish with it that the problems start. Thanks to everyone that helped me work through this. Is this sort of problem already documented somewhere? If not, maybe I could write up a quick doc describing the problem, but where should I put it so that others can find it? Alli |
|
From: Allison N. <dem...@ma...> - 2008-05-30 04:33:01
|
Hi Eloy, Thanks for the tips included here for managing frameworks - I know it's not really RubyCocoa, but then, the whole point of RubyCocoa is to bring non-Mac ruby programmers into the mac development community, so I guess I won't be the only person coming here that doesn't know that :-) On a more general note, I update my RC to 0.13.2, but it didn't fix the problem. So, I back-tracked a little further and discovered that the problem was occurring before the OutlineView was ever called - specifically, the problem is in YAML - when I read an array back in from file, the array is initialised, and has the right size, but any attempt to access a member of the array fails. I got fooled, because the one time I tested the initialisation of the array, I had deleted the file, so I created the array from defaults, not from a YAML serialisation. Sorry to have wasted everyone's time :-/ I guess I might end up using Cocoa archiving in the end after all... Alli Le 29 mai 08 à 17:28, Eloy Duran a écrit : > Simply change the location of the RubyCocoa.framework that your > project links against, > by selecting it cmd+i and change the path. > > Also there's no problem at all with including the framework with your > build, your users will never know! :) > > I have no idea what the Apple software updater does... > > Eloy > > On May 29, 2008, at 5:15 PM, Allison Newman wrote: > >> Yup, bizarrely, I'm running Leopard 10.5.2, so in principal at >> least, I should have 0.13.1 >> >> I don't really want to take the latest build - I want to be able to >> distribute this app as a binary, so I'm trying to always build >> against the standard Leopard install. That said, apparently >> something isn't right in my setup, as I haven't picked up the latest >> version distributed with Leopard. Très bizarre! >> >> OK, I'm going to try installing the latest version manually, to see >> what that gives... >> >> Actually, does anyone know what the Apple Software Updater does when >> it upgrades RubyCocoa? Does it destroy the old installed version? >> Are the two systems installed together (mine in /usr/local/bin or >> something like that, and Apple's in /bin)? If I'm using my own >> version in /usr/local/bin, how do I make sure that XCode picks up >> the right version? >> >> I know these are not really RubyCocoa questions, but people here >> must already know the answers, so... anyone???(hopeful look)... >> >> Alli >> >> On Thursday, May 29, 2008, at 04:37PM, "Eloy Duran" <e....@su... >>> wrote: >>> Ai... That's old. I was planning on discussing a new release for the >>> next update on the dev. list tonight. >>> But you will need to install a newer version of RC to have all the >>> ducktyping code on NSCFArray. >>> >>> Eloy >>> >>> On May 29, 2008, at 4:33 PM, Allison Newman wrote: >>> >>>> 0.13.0 >>>> >>>> >>>> On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su... >>>>> wrote: >>>>> I know a fair bit about RC and it should do it :) >>>>> Which version of RC are you using? >>>>> >>>>> You can check in the terminal: >>>>> $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" >>>>> >>>>> Eloy >>>>> >>>>> On May 29, 2008, at 3:59 PM, Allison Newman wrote: >>>>> >>>>>> Hi Eloy, >>>>>> >>>>>> Yes, I have seen it :-/ >>>>>> >>>>>> My own code uses a standard ruby array as you have suggested, but >>>>>> when it comes back out of the view in outlineView_child_ofItem >>>>>> (where the item is the array in question), when I try to do >>>>>> item[index], my code blows up in the bridge (rbobj_get_ocid: >>>>>> see my >>>>>> original post). Interestingly enough, item.size still works >>>>>> correctly. >>>>>> >>>>>> One things is sure - if I add methods to my array before handing >>>>>> it >>>>>> to the NSOutlineView, when I get it back those methods are no >>>>>> longer >>>>>> available. From that I gather that the object is modified whilst >>>>>> crossing the bridge. Maybe this is a bug, or maybe it's just >>>>>> simply >>>>>> that the RubyCocoa bridge was never intended to support this >>>>>> kind of >>>>>> use. Who knows the bridge well enough to decide? >>>>>> >>>>>> Anyway, as always, thanks for the reply. >>>>>> >>>>>> Alli >>>>>> >>>>>> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >>>>>>> wrote: >>>>>>> Hi Allison, >>>>>>> >>>>>>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>>>>>> It has code for an outline view in MyPDFDocument.rb, >>>>>>> >>>>>>> it does use a NSMutableArray afaik, but it should be >>>>>>> ducktypable by >>>>>>> now. >>>>>>> So ary.childAtIndex(index) could be written as arr[index]. >>>>>>> So I wouldn't worry about that too much. Also if you send a >>>>>>> plain >>>>>>> ruby >>>>>>> array through the bridge >>>>>>> it will automatiucally be converted to a NSMutableArray. >>>>>>> >>>>>>> Cheers, >>>>>>> Eloy >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by: Microsoft >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>> _______________________________________________ >>>>>> Rubycocoa-talk mailing list >>>>>> Rub...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> Rubycocoa-talk mailing list >>>>> Rub...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Rubycocoa-talk mailing list >>>> Rub...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Allison N. <dem...@ma...> - 2008-05-29 17:13:42
|
Oh, it's that simple? I'm glad I asked then :-) Le 29 mai 08 à 17:28, Eloy Duran a écrit : > Simply change the location of the RubyCocoa.framework that your > project links against, > by selecting it cmd+i and change the path. > > Also there's no problem at all with including the framework with your > build, your users will never know! :) > > I have no idea what the Apple software updater does... > > Eloy > > On May 29, 2008, at 5:15 PM, Allison Newman wrote: > >> Yup, bizarrely, I'm running Leopard 10.5.2, so in principal at >> least, I should have 0.13.1 >> >> I don't really want to take the latest build - I want to be able to >> distribute this app as a binary, so I'm trying to always build >> against the standard Leopard install. That said, apparently >> something isn't right in my setup, as I haven't picked up the latest >> version distributed with Leopard. Très bizarre! >> >> OK, I'm going to try installing the latest version manually, to see >> what that gives... >> >> Actually, does anyone know what the Apple Software Updater does when >> it upgrades RubyCocoa? Does it destroy the old installed version? >> Are the two systems installed together (mine in /usr/local/bin or >> something like that, and Apple's in /bin)? If I'm using my own >> version in /usr/local/bin, how do I make sure that XCode picks up >> the right version? >> >> I know these are not really RubyCocoa questions, but people here >> must already know the answers, so... anyone???(hopeful look)... >> >> Alli >> >> On Thursday, May 29, 2008, at 04:37PM, "Eloy Duran" <e....@su... >>> wrote: >>> Ai... That's old. I was planning on discussing a new release for the >>> next update on the dev. list tonight. >>> But you will need to install a newer version of RC to have all the >>> ducktyping code on NSCFArray. >>> >>> Eloy >>> >>> On May 29, 2008, at 4:33 PM, Allison Newman wrote: >>> >>>> 0.13.0 >>>> >>>> >>>> On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su... >>>>> wrote: >>>>> I know a fair bit about RC and it should do it :) >>>>> Which version of RC are you using? >>>>> >>>>> You can check in the terminal: >>>>> $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" >>>>> >>>>> Eloy >>>>> >>>>> On May 29, 2008, at 3:59 PM, Allison Newman wrote: >>>>> >>>>>> Hi Eloy, >>>>>> >>>>>> Yes, I have seen it :-/ >>>>>> >>>>>> My own code uses a standard ruby array as you have suggested, but >>>>>> when it comes back out of the view in outlineView_child_ofItem >>>>>> (where the item is the array in question), when I try to do >>>>>> item[index], my code blows up in the bridge (rbobj_get_ocid: >>>>>> see my >>>>>> original post). Interestingly enough, item.size still works >>>>>> correctly. >>>>>> >>>>>> One things is sure - if I add methods to my array before handing >>>>>> it >>>>>> to the NSOutlineView, when I get it back those methods are no >>>>>> longer >>>>>> available. From that I gather that the object is modified whilst >>>>>> crossing the bridge. Maybe this is a bug, or maybe it's just >>>>>> simply >>>>>> that the RubyCocoa bridge was never intended to support this >>>>>> kind of >>>>>> use. Who knows the bridge well enough to decide? >>>>>> >>>>>> Anyway, as always, thanks for the reply. >>>>>> >>>>>> Alli >>>>>> >>>>>> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >>>>>>> wrote: >>>>>>> Hi Allison, >>>>>>> >>>>>>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>>>>>> It has code for an outline view in MyPDFDocument.rb, >>>>>>> >>>>>>> it does use a NSMutableArray afaik, but it should be >>>>>>> ducktypable by >>>>>>> now. >>>>>>> So ary.childAtIndex(index) could be written as arr[index]. >>>>>>> So I wouldn't worry about that too much. Also if you send a >>>>>>> plain >>>>>>> ruby >>>>>>> array through the bridge >>>>>>> it will automatiucally be converted to a NSMutableArray. >>>>>>> >>>>>>> Cheers, >>>>>>> Eloy >>>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by: Microsoft >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>> _______________________________________________ >>>>>> Rubycocoa-talk mailing list >>>>>> Rub...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> Rubycocoa-talk mailing list >>>>> Rub...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>>> >>>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Rubycocoa-talk mailing list >>>> Rub...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Eloy D. <elo...@gm...> - 2008-05-29 15:28:50
|
Simply change the location of the RubyCocoa.framework that your project links against, by selecting it cmd+i and change the path. Also there's no problem at all with including the framework with your build, your users will never know! :) I have no idea what the Apple software updater does... Eloy On May 29, 2008, at 5:15 PM, Allison Newman wrote: > Yup, bizarrely, I'm running Leopard 10.5.2, so in principal at > least, I should have 0.13.1 > > I don't really want to take the latest build - I want to be able to > distribute this app as a binary, so I'm trying to always build > against the standard Leopard install. That said, apparently > something isn't right in my setup, as I haven't picked up the latest > version distributed with Leopard. Très bizarre! > > OK, I'm going to try installing the latest version manually, to see > what that gives... > > Actually, does anyone know what the Apple Software Updater does when > it upgrades RubyCocoa? Does it destroy the old installed version? > Are the two systems installed together (mine in /usr/local/bin or > something like that, and Apple's in /bin)? If I'm using my own > version in /usr/local/bin, how do I make sure that XCode picks up > the right version? > > I know these are not really RubyCocoa questions, but people here > must already know the answers, so... anyone???(hopeful look)... > > Alli > > On Thursday, May 29, 2008, at 04:37PM, "Eloy Duran" <e....@su... > > wrote: >> Ai... That's old. I was planning on discussing a new release for the >> next update on the dev. list tonight. >> But you will need to install a newer version of RC to have all the >> ducktyping code on NSCFArray. >> >> Eloy >> >> On May 29, 2008, at 4:33 PM, Allison Newman wrote: >> >>> 0.13.0 >>> >>> >>> On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su... >>>> wrote: >>>> I know a fair bit about RC and it should do it :) >>>> Which version of RC are you using? >>>> >>>> You can check in the terminal: >>>> $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" >>>> >>>> Eloy >>>> >>>> On May 29, 2008, at 3:59 PM, Allison Newman wrote: >>>> >>>>> Hi Eloy, >>>>> >>>>> Yes, I have seen it :-/ >>>>> >>>>> My own code uses a standard ruby array as you have suggested, but >>>>> when it comes back out of the view in outlineView_child_ofItem >>>>> (where the item is the array in question), when I try to do >>>>> item[index], my code blows up in the bridge (rbobj_get_ocid: >>>>> see my >>>>> original post). Interestingly enough, item.size still works >>>>> correctly. >>>>> >>>>> One things is sure - if I add methods to my array before handing >>>>> it >>>>> to the NSOutlineView, when I get it back those methods are no >>>>> longer >>>>> available. From that I gather that the object is modified whilst >>>>> crossing the bridge. Maybe this is a bug, or maybe it's just >>>>> simply >>>>> that the RubyCocoa bridge was never intended to support this >>>>> kind of >>>>> use. Who knows the bridge well enough to decide? >>>>> >>>>> Anyway, as always, thanks for the reply. >>>>> >>>>> Alli >>>>> >>>>> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >>>>>> wrote: >>>>>> Hi Allison, >>>>>> >>>>>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>>>>> It has code for an outline view in MyPDFDocument.rb, >>>>>> >>>>>> it does use a NSMutableArray afaik, but it should be >>>>>> ducktypable by >>>>>> now. >>>>>> So ary.childAtIndex(index) could be written as arr[index]. >>>>>> So I wouldn't worry about that too much. Also if you send a plain >>>>>> ruby >>>>>> array through the bridge >>>>>> it will automatiucally be converted to a NSMutableArray. >>>>>> >>>>>> Cheers, >>>>>> Eloy >>>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> Rubycocoa-talk mailing list >>>>> Rub...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Rubycocoa-talk mailing list >>>> Rub...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>>> >>>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Allison N. <dem...@ma...> - 2008-05-29 15:16:04
|
Yup, bizarrely, I'm running Leopard 10.5.2, so in principal at least, I should have 0.13.1 I don't really want to take the latest build - I want to be able to distribute this app as a binary, so I'm trying to always build against the standard Leopard install. That said, apparently something isn't right in my setup, as I haven't picked up the latest version distributed with Leopard. Très bizarre! OK, I'm going to try installing the latest version manually, to see what that gives... Actually, does anyone know what the Apple Software Updater does when it upgrades RubyCocoa? Does it destroy the old installed version? Are the two systems installed together (mine in /usr/local/bin or something like that, and Apple's in /bin)? If I'm using my own version in /usr/local/bin, how do I make sure that XCode picks up the right version? I know these are not really RubyCocoa questions, but people here must already know the answers, so... anyone???(hopeful look)... Alli On Thursday, May 29, 2008, at 04:37PM, "Eloy Duran" <e....@su...> wrote: >Ai... That's old. I was planning on discussing a new release for the >next update on the dev. list tonight. >But you will need to install a newer version of RC to have all the >ducktyping code on NSCFArray. > >Eloy > >On May 29, 2008, at 4:33 PM, Allison Newman wrote: > >> 0.13.0 >> >> >> On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su... >> > wrote: >>> I know a fair bit about RC and it should do it :) >>> Which version of RC are you using? >>> >>> You can check in the terminal: >>> $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" >>> >>> Eloy >>> >>> On May 29, 2008, at 3:59 PM, Allison Newman wrote: >>> >>>> Hi Eloy, >>>> >>>> Yes, I have seen it :-/ >>>> >>>> My own code uses a standard ruby array as you have suggested, but >>>> when it comes back out of the view in outlineView_child_ofItem >>>> (where the item is the array in question), when I try to do >>>> item[index], my code blows up in the bridge (rbobj_get_ocid: see my >>>> original post). Interestingly enough, item.size still works >>>> correctly. >>>> >>>> One things is sure - if I add methods to my array before handing it >>>> to the NSOutlineView, when I get it back those methods are no longer >>>> available. From that I gather that the object is modified whilst >>>> crossing the bridge. Maybe this is a bug, or maybe it's just simply >>>> that the RubyCocoa bridge was never intended to support this kind of >>>> use. Who knows the bridge well enough to decide? >>>> >>>> Anyway, as always, thanks for the reply. >>>> >>>> Alli >>>> >>>> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >>>>> wrote: >>>>> Hi Allison, >>>>> >>>>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>>>> It has code for an outline view in MyPDFDocument.rb, >>>>> >>>>> it does use a NSMutableArray afaik, but it should be ducktypable by >>>>> now. >>>>> So ary.childAtIndex(index) could be written as arr[index]. >>>>> So I wouldn't worry about that too much. Also if you send a plain >>>>> ruby >>>>> array through the bridge >>>>> it will automatiucally be converted to a NSMutableArray. >>>>> >>>>> Cheers, >>>>> Eloy >>>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> Rubycocoa-talk mailing list >>>> Rub...@li... >>>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >>> >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Rubycocoa-talk mailing list >Rub...@li... >https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > |
|
From: Eloy D. <e....@su...> - 2008-05-29 14:37:48
|
Ai... That's old. I was planning on discussing a new release for the next update on the dev. list tonight. But you will need to install a newer version of RC to have all the ducktyping code on NSCFArray. Eloy On May 29, 2008, at 4:33 PM, Allison Newman wrote: > 0.13.0 > > > On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su... > > wrote: >> I know a fair bit about RC and it should do it :) >> Which version of RC are you using? >> >> You can check in the terminal: >> $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" >> >> Eloy >> >> On May 29, 2008, at 3:59 PM, Allison Newman wrote: >> >>> Hi Eloy, >>> >>> Yes, I have seen it :-/ >>> >>> My own code uses a standard ruby array as you have suggested, but >>> when it comes back out of the view in outlineView_child_ofItem >>> (where the item is the array in question), when I try to do >>> item[index], my code blows up in the bridge (rbobj_get_ocid: see my >>> original post). Interestingly enough, item.size still works >>> correctly. >>> >>> One things is sure - if I add methods to my array before handing it >>> to the NSOutlineView, when I get it back those methods are no longer >>> available. From that I gather that the object is modified whilst >>> crossing the bridge. Maybe this is a bug, or maybe it's just simply >>> that the RubyCocoa bridge was never intended to support this kind of >>> use. Who knows the bridge well enough to decide? >>> >>> Anyway, as always, thanks for the reply. >>> >>> Alli >>> >>> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >>>> wrote: >>>> Hi Allison, >>>> >>>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>>> It has code for an outline view in MyPDFDocument.rb, >>>> >>>> it does use a NSMutableArray afaik, but it should be ducktypable by >>>> now. >>>> So ary.childAtIndex(index) could be written as arr[index]. >>>> So I wouldn't worry about that too much. Also if you send a plain >>>> ruby >>>> array through the bridge >>>> it will automatiucally be converted to a NSMutableArray. >>>> >>>> Cheers, >>>> Eloy >>>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2008. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Rubycocoa-talk mailing list >>> Rub...@li... >>> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: Allison N. <dem...@ma...> - 2008-05-29 14:33:13
|
0.13.0 On Thursday, May 29, 2008, at 04:15PM, "Eloy Duran" <e....@su...> wrote: >I know a fair bit about RC and it should do it :) >Which version of RC are you using? > >You can check in the terminal: >$ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" > >Eloy > >On May 29, 2008, at 3:59 PM, Allison Newman wrote: > >> Hi Eloy, >> >> Yes, I have seen it :-/ >> >> My own code uses a standard ruby array as you have suggested, but >> when it comes back out of the view in outlineView_child_ofItem >> (where the item is the array in question), when I try to do >> item[index], my code blows up in the bridge (rbobj_get_ocid: see my >> original post). Interestingly enough, item.size still works >> correctly. >> >> One things is sure - if I add methods to my array before handing it >> to the NSOutlineView, when I get it back those methods are no longer >> available. From that I gather that the object is modified whilst >> crossing the bridge. Maybe this is a bug, or maybe it's just simply >> that the RubyCocoa bridge was never intended to support this kind of >> use. Who knows the bridge well enough to decide? >> >> Anyway, as always, thanks for the reply. >> >> Alli >> >> On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... >> > wrote: >>> Hi Allison, >>> >>> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >>> It has code for an outline view in MyPDFDocument.rb, >>> >>> it does use a NSMutableArray afaik, but it should be ducktypable by >>> now. >>> So ary.childAtIndex(index) could be written as arr[index]. >>> So I wouldn't worry about that too much. Also if you send a plain >>> ruby >>> array through the bridge >>> it will automatiucally be converted to a NSMutableArray. >>> >>> Cheers, >>> Eloy >>> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Rubycocoa-talk mailing list >> Rub...@li... >> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > >------------------------------------------------------------------------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Rubycocoa-talk mailing list >Rub...@li... >https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk > > |
|
From: Eloy D. <e....@su...> - 2008-05-29 14:15:40
|
I know a fair bit about RC and it should do it :) Which version of RC are you using? You can check in the terminal: $ ruby -rosx/cocoa -e "p OSX::RUBYCOCOA_VERSION" Eloy On May 29, 2008, at 3:59 PM, Allison Newman wrote: > Hi Eloy, > > Yes, I have seen it :-/ > > My own code uses a standard ruby array as you have suggested, but > when it comes back out of the view in outlineView_child_ofItem > (where the item is the array in question), when I try to do > item[index], my code blows up in the bridge (rbobj_get_ocid: see my > original post). Interestingly enough, item.size still works > correctly. > > One things is sure - if I add methods to my array before handing it > to the NSOutlineView, when I get it back those methods are no longer > available. From that I gather that the object is modified whilst > crossing the bridge. Maybe this is a bug, or maybe it's just simply > that the RubyCocoa bridge was never intended to support this kind of > use. Who knows the bridge well enough to decide? > > Anyway, as always, thanks for the reply. > > Alli > > On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm... > > wrote: >> Hi Allison, >> >> Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >> It has code for an outline view in MyPDFDocument.rb, >> >> it does use a NSMutableArray afaik, but it should be ducktypable by >> now. >> So ary.childAtIndex(index) could be written as arr[index]. >> So I wouldn't worry about that too much. Also if you send a plain >> ruby >> array through the bridge >> it will automatiucally be converted to a NSMutableArray. >> >> Cheers, >> Eloy >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk |
|
From: kimura w. <ki...@us...> - 2008-05-29 14:14:21
|
Hi Brian, On Wed, 28 May 2008 11:44:37 -0500, Brian Marick wrote: > Thanks. I submitted a bug report+workaround at > <http://sourceforge.net/tracker/index.php?func=detail&aid=1970883&group_id=44114&atid=438476 > > > > Did you fix it by having kvc_writer define > automaticallyNotifiesObserversForKey to be false? Doing that manually > passes my tests. Yes. I fixed the bug, you reported in bug#1970883, of kvc_writer at r2023. Just now, I fixed the same bug of kvc_array_accessor at r2025. Thanks again, -- kimura wataru |
|
From: Allison N. <dem...@ma...> - 2008-05-29 13:59:46
|
Hi Eloy, Yes, I have seen it :-/ My own code uses a standard ruby array as you have suggested, but when it comes back out of the view in outlineView_child_ofItem (where the item is the array in question), when I try to do item[index], my code blows up in the bridge (rbobj_get_ocid: see my original post). Interestingly enough, item.size still works correctly. One things is sure - if I add methods to my array before handing it to the NSOutlineView, when I get it back those methods are no longer available. From that I gather that the object is modified whilst crossing the bridge. Maybe this is a bug, or maybe it's just simply that the RubyCocoa bridge was never intended to support this kind of use. Who knows the bridge well enough to decide? Anyway, as always, thanks for the reply. Alli On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm...> wrote: >Hi Allison, > >Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >It has code for an outline view in MyPDFDocument.rb, > >it does use a NSMutableArray afaik, but it should be ducktypable by now. >So ary.childAtIndex(index) could be written as arr[index]. >So I wouldn't worry about that too much. Also if you send a plain ruby >array through the bridge >it will automatiucally be converted to a NSMutableArray. > >Cheers, >Eloy > |
|
From: Allison N. <dem...@ma...> - 2008-05-29 13:59:39
|
Hi Eloy, Yes, I have seen it :-/ My own code uses a standard ruby array as you have suggested, but when it comes back out of the view in outlineView_child_ofItem (where the item is the array in question), when I try to do item[index], my code blows up in the bridge (rbobj_get_ocid: see my original post). Interestingly enough, item.size still works correctly. One things is sure - if I add methods to my array before handing it to the NSOutlineView, when I get it back those methods are no longer available. From that I gather that the object is modified whilst crossing the bridge. Maybe this is a bug, or maybe it's just simply that the RubyCocoa bridge was never intended to support this kind of use. Who knows the bridge well enough to decide? Anyway, as always, thanks for the reply. Alli On Thursday, May 29, 2008, at 02:51PM, "Eloy Duran" <elo...@gm...> wrote: >Hi Allison, > >Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ? >It has code for an outline view in MyPDFDocument.rb, > >it does use a NSMutableArray afaik, but it should be ducktypable by now. >So ary.childAtIndex(index) could be written as arr[index]. >So I wouldn't worry about that too much. Also if you send a plain ruby >array through the bridge >it will automatiucally be converted to a NSMutableArray. > >Cheers, >Eloy > |
|
From: Eloy D. <elo...@gm...> - 2008-05-29 12:51:52
|
Hi Allison,
Have you looked at /Developer/Examples/RubyCocoa/PDFKitViewer ?
It has code for an outline view in MyPDFDocument.rb,
it does use a NSMutableArray afaik, but it should be ducktypable by now.
So ary.childAtIndex(index) could be written as arr[index].
So I wouldn't worry about that too much. Also if you send a plain ruby
array through the bridge
it will automatiucally be converted to a NSMutableArray.
Cheers,
Eloy
On May 29, 2008, at 1:43 PM, Allison Newman wrote:
> Hi Pim,
>
> Actually, I had already downloaded your project :-) You've done it
> with bindings, I'm trying to do it as a plain-old data source. It's
> my first Cocoa app, and others on the Cocoa dev list have suggested
> that I should learn how to do this as a datasource first, to better
> understand what bindings are doing.
>
> I have looked at the example OutlineView.rb that Tim Burks did that
> shows a file system outline view done in RubyCocoa, but the only
> difference that I can see between my code and his is that he only
> uses Cocoa objects - indeed, I can see where he retrieves the list
> of items in a directory ruby style, and then deliberately copies
> the items out of the ruby array into an NSMutableArray, like this:
> array = fileManager.directoryContentsAtPath(fp)
> numChildren = array ? array.count : 0
> @children =
> OSX::NSMutableArray.alloc.initWithCapacity(numChildren)
> numChildren.times {|cnt|
> item =
> FileSystemItem.alloc.initWithPath_parent(array.objectAtIndex(cnt),
> self)
> @children.addObject(item)
> }
> That immediately made me suspect that something bad happens to ruby
> arrays as they cross the bridge, to be returned by a Cocoa
> callback. I guess I just wanted to confirm that this was indeed the
> case. It basically forces me to remove ruby arrays from my models
> and replace them with NSMutable arrays, which then implies that I
> need to get rid of my YAML serialisation of data, and replace it
> with Cocoa archiving code. It's a fair amout of work, and I just
> wanted someone to confirm for me that this really is the problem,
> before wasting a lot of time on something that wasn't necessary. I
> guess this is what Tim was talking about when he said that you
> can't really mix ruby libraries and Cocoa libraries (he used this as
> his explanation for why he created nu in a talk at C4).
>
> Of course, if I'm right, this removes a lot of the joy from program
> in ruby for the Mac. I'm starting to understand why Laurent felt it
> necessary to start the MacRuby project.
>
> Thanks for the help anyway.
>
> Alli
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Rubycocoa-talk mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk
|
|
From: Allison N. <dem...@ma...> - 2008-05-29 11:43:44
|
Hi Pim,
Actually, I had already downloaded your project :-) You've done it with bindings, I'm trying to do it as a plain-old data source. It's my first Cocoa app, and others on the Cocoa dev list have suggested that I should learn how to do this as a datasource first, to better understand what bindings are doing.
I have looked at the example OutlineView.rb that Tim Burks did that shows a file system outline view done in RubyCocoa, but the only difference that I can see between my code and his is that he only uses Cocoa objects - indeed, I can see where he retrieves the list of items in a directory ruby style, and then deliberately copies the items out of the ruby array into an NSMutableArray, like this:
array = fileManager.directoryContentsAtPath(fp)
numChildren = array ? array.count : 0
@children = OSX::NSMutableArray.alloc.initWithCapacity(numChildren)
numChildren.times {|cnt|
item = FileSystemItem.alloc.initWithPath_parent(array.objectAtIndex(cnt), self)
@children.addObject(item)
}
That immediately made me suspect that something bad happens to ruby arrays as they cross the bridge, to be returned by a Cocoa callback. I guess I just wanted to confirm that this was indeed the case. It basically forces me to remove ruby arrays from my models and replace them with NSMutable arrays, which then implies that I need to get rid of my YAML serialisation of data, and replace it with Cocoa archiving code. It's a fair amout of work, and I just wanted someone to confirm for me that this really is the problem, before wasting a lot of time on something that wasn't necessary. I guess this is what Tim was talking about when he said that you can't really mix ruby libraries and Cocoa libraries (he used this as his explanation for why he created nu in a talk at C4).
Of course, if I'm right, this removes a lot of the joy from program in ruby for the Mac. I'm starting to understand why Laurent felt it necessary to start the MacRuby project.
Thanks for the help anyway.
Alli
|
|
From: Pim S. <pi...@li...> - 2008-05-29 10:17:16
|
> I get the impression that my OutlineViewItem instance is getting > corrupted as it moves back and forth across the bridge. Does anyone > have any hints for correctly implementing an NSOutlineView > datasource, or better, can explain why my app is dying? > > Thanks for any help. > > Alli Hi Alli, After a lot of struggeling I have managed to get the outlineview working together with the activerecord bindings. If you download the sourcecode of the timetoticket project you can see how. You must check the treecontroller class. http://www.pimsnel.com/timetoticket/ You need a redmine database for the actual data in timetoticket. I'll attach an empty mysql schema. I wanted to create a tutorial, but I still don't have enought time for doing it. Regards, Pim |
|
From: Brian M. <ma...@ex...> - 2008-05-28 16:44:52
|
Thanks. I submitted a bug report+workaround at <http://sourceforge.net/tracker/index.php?func=detail&aid=1970883&group_id=44114&atid=438476 > Did you fix it by having kvc_writer define automaticallyNotifiesObserversForKey to be false? Doing that manually passes my tests. On May 28, 2008, at 9:58 AM, kimura wataru wrote: > Thanks for your reporting, > > This is a bug of RubyCocoa. > I fixed this bug at svn trunk r2202-2203. > > On Sat, 17 May 2008 14:08:28 -0500, Brian Marick wrote: >> It seems as if RubyCocoa's key-value observing works differently in >> some ways than Objective-C's would. Is this intentional? An >> incomplete >> implementation? The real question: is it stable behavior an app can >> depend upon? >> > -- > kimura wataru > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Rubycocoa-talk mailing list > Rub...@li... > https://lists.sourceforge.net/lists/listinfo/rubycocoa-talk ----- Brian Marick, independent consultant Mostly on agile methods with a testing slant www.exampler.com, www.exampler.com/blog, www.twitter.com/marick |
|
From: kimura w. <ki...@us...> - 2008-05-28 14:58:52
|
Thanks for your reporting, This is a bug of RubyCocoa. I fixed this bug at svn trunk r2202-2203. On Sat, 17 May 2008 14:08:28 -0500, Brian Marick wrote: > It seems as if RubyCocoa's key-value observing works differently in > some ways than Objective-C's would. Is this intentional? An incomplete > implementation? The real question: is it stable behavior an app can > depend upon? > -- kimura wataru |
|
From: Allison N. <dem...@ma...> - 2008-05-28 13:19:19
|
Hi everyone,
I'm having some trouble with implementing an NSOutlineView data source.
Currently, I have created a class called OutlineViewItem, which is defined as follows:
class OutlineViewItem < NSObject
attr_accessor :name, :ary
def numberOfChildren
@ary.size
end
def isItemExpandable
@ary != nil
end
def getChild(index)
@ary[index]
end
def to_s
"OutlineViewItem:#{@name} #{@ary.size}"
end
end
where @name is a ruby String, and @ary is a ruby Array.
I have three of these objects that are added to the root of the NSOutlineView, and they are correctly displayed in the outline view, with the triangle next to them indicating that each is expandable (as each is initialised with several items in it's @ary).
However, when I try to call getChild in the outlineView_child_ofItem method of the NSOutlineView DataSource (where the item given by the NSOutlineView is an object of class OutlineViewItem), my app dies when the OutlineViewItem tries to recover one of it's children from it's @ary. Specifically, the backtrace looks like this:
#0 0x000356e9 in rbobj_get_ocid ()
#1 0x0002d0db in rbobj_to_nsobj ()
#2 0x0002d776 in rbobj_to_ocdata ()
#3 0x0002ef43 in sel_to_rbobj ()
#4 0x0004130c in ffi_prep_cif_machdep ()
#5 0x9164b4e6 in -[NSOutlineView _dataSourceChild:ofItem:] ()
#6 0x9164b3a5 in loadItemEntryLazyInfoIfNecessary ()
#7 0x9164cb5a in -[NSOutlineView _rowEntryForChild:ofParent:requiredRowEntryLoadMask:] ()
#8 0x9164bf5a in -[NSOutlineView _expandItemEntryChildren:atStartLevel:expandChildren:andInvalidate:] ()
#9 0x917a1b4f in -[NSOutlineView _expandItemEntry:expandChildren:startLevel:] ()
#10 0x917a15aa in -[NSOutlineView _expandItemEntry:expandChildren:] ()
#11 0x9164b96e in -[NSOutlineView _batchExpandItemsWithItemEntries:expandChildren:] ()
#12 0x9164b6d1 in -[NSOutlineView expandItem:expandChildren:] ()
#13 0x9182af1a in -[NSOutlineView _doUserExpandOrCollapseOfItem:isExpand:optionKeyWasDown:] ()
#14 0x9182aa1e in -[NSOutlineView mouseTracker:didStopTrackingWithEvent:] ()
#15 0x9182a84e in -[NSMouseTracker stopTrackingWithEvent:] ()
#16 0x9179ceb7 in -[NSMouseTracker trackWithEvent:inView:withDelegate:] ()
#17 0x916e1dde in -[NSOutlineView mouseDown:] ()
#18 0x91688ac3 in -[NSWindow sendEvent:] ()
#19 0x91655714 in -[NSApplication sendEvent:] ()
#20 0x915b30f9 in -[NSApplication run] ()
#21 0x9158030a in NSApplicationMain ()
#22 0x0004163d in ffi_call_SYSV ()
#23 0x000415e2 in ffi_call ()
#24 0x0003e9b3 in rb_ffi_dispatch ()
#25 0x000374a9 in find_bs_boxed_by_encoding ()
#26 0x000d1057 in rb_with_disable_interrupt ()
#27 0x000da18c in rb_eval_string_wrap ()
#28 0x000dad6a in rb_eval_string_wrap ()
#29 0x000d80da in rb_eval_string_wrap ()
#30 0x000e706e in rb_load_protect ()
#31 0x000e709f in ruby_exec ()
#32 0x000e70cb in ruby_run ()
#33 0x00034ae3 in RBApplicationMain ()
#34 0x00001fed in main (argc=1, argv=0xbffff750) at /Users/demallien/Code/Exerciser/main.m:14
I get the impression that my OutlineViewItem instance is getting corrupted as it moves back and forth across the bridge. Does anyone have any hints for correctly implementing an NSOutlineView datasource, or better, can explain why my app is dying?
Thanks for any help.
Alli
|
16 messages has been excluded from this view by a project administrator.
