Re: Cocoa-dev Digest, Vol 4, Issue 1333

  • Hello Rick,

    Yes, this is definitely possible, and probably a lot easier than you
    might imagine.  (I did this exact thing in a major commercial
    application several years ago with great success--and it literally
    took only a couple of days to get the basics up and running.)  Here's
    what I recommend (from memory, since I do not have the code mentioned
    any more--so you will have to work the details):

    First, write an Obj-C proxy class for your C++ Satellite class.  Fill
    it in with a pointer to your C++ satellite object and add KVC/KVO
    compliant accessors and mutators (which are usually just a line or two
    long because they just forward to the C++ object).

    Second, write a simple shim/wrapper class for your collection of
    satellites (You _are_ using a Standard Library collection class,
    aren't you?) using NSMutableArray and implementing the basic accessor
    and mutator functions (insertObject:atIndex:, removeObjectAtIndex:,
    replaceObject... etc.).  This collection holds the proxies from the
    first step above.  When a request for a satellite comes in you check
    to see if your proxy list has a proxy for it, if not fetch the C++
    object, make up a proxy to it, and drop the proxy into the proxy array
    (lazy instantiation).

    There are a number of different approaches you can take working from
    this basic concept.  Instead of lazy instantiation, you could create
    all the satellite proxies when the proxy array is created.  )This
    approach may actually be easier to get running properly at first and
    then optimize it to do the lazy approach.)

    In my final implementation, I actually had two NSMutableArrays: the
    'fake' one which I used for bindings and which provided all of the
    bindings-required accessors and mutators but did not actually contain
    anything, and a second one, which was a member of the first one, and
    which actually contained the object proxies and to which all the
    accessor/mutator functions from the first were directed.  IIRC, this
    was required because there was some issue with bindings which
    complicated the implementation of the first array--but I don't have
    access to my notes and cannot recall the underlying reason--just keep
    this two-array approach in mind if you start to run into trouble.

    HTH and Merry Christmas to you,
    Mike

    On Dec 22, 2007, at 14:53:55 -0800 PM,  Mann <rmann...>
    wrote:
    > Subject: Using Bindings with C++ objects
    >
    > I have an existing Carbon app that I'm trying to port to Cocoa. I
    > don't want to rewrite everything as an Obj-C object, so I'm looking
    > for ways to wrap Cocoa around my C++.
    >
    > In one situation, I have a C++ object that represents a Satellite,
    > and another that is a SatelliteProxy. In the app, there is a master
    > list of Satellite objects, and a SatelliteProxy for each satellite
    > in each view that's displaying satellites. The proxy object
    > overrides some of the attributes of the graphical representation of
    > a Satellite. For example, in one view, the International Space
    > Station (ISS) may have a red ground track, and in another view, a
    > green ground track. In this instance, there are two ISS
    > SatelliteProxy objects that each refer to the single, global (app-
    > wide) ISS Satellite object.
    >
    > The user can select SatelliteProxy objects (one or many) in a view,
    > then use an inspector to adjust their attributes. For example, if an
    > attribute is "Show footprint" (the footprint is the area of the
    > Earth that has line-of-site to the satellite at a given instant),
    > and two satellites are selected, one with the footprint enabled, the
    > other not, the checkbox in the inspector would show a dash.
    > Similarly, if both satellites had the footprint enabled, the box
    > would show as checked (standard multi-object inspector behavior).
    >
    > I'd like to use bindings to facilitate this (as I understand it,
    > this is something they're good for). However, they won't work
    > directly on C++ objects. I was thinking I could subclass
    > NSArrayController and override the valueForKey: methods to manually
    > inspect the key path and hard-code queries to the SatelliteProxy
    > objects. One of my concerns with this approach is that the
    > NSArrayController's container for the collection of SatelliteProxy
    > objects may not be able to contain C++ objects.
    >
    > I'd like to get feedback on this approach. Is it viable? It's okay
    > if there's extra effort coding up the key-to-C++ mapping. That's
    > still less work than rewriting my classes as Obj-C.
    >
    > An alternative is to create a wrapper Obj-C object, one for each
    > SatelliteProxy object. I do something similar for the view code I
    > wrote in the Carbon app.
    >
    > Suggestions?
    >
    > TIA,
    > Rick
  • On Dec 24, 2007, at 8:38 AM, Mike Rossetti wrote:

    > Yes, this is definitely possible, and probably a lot easier than you
    > might imagine.  (I did this exact thing in a major commercial
    > application several years ago with great success--and it literally
    > took only a couple of days to get the basics up and running.)
    > Here's what I recommend (from memory, since I do not have the code
    > mentioned any more--so you will have to work the details):
    >
    > First, write an Obj-C proxy class for your C++ Satellite class.
    > Fill it in with a pointer to your C++ satellite object and add KVC/
    > KVO compliant accessors and mutators (which are usually just a line
    > or two long because they just forward to the C++ object).

    Okay, that's what I thought would work well.

    Thanks for giving me some evidence that the approach is reasonable.
    Someone else on the list agrees.

    --
    Rick
previous month december 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
31            
Go to today