outlets to multiple views (NSView)

  • I have an application with 4 different views of a 3D scene. The views
    are NSOpenGLViews. They are "connected" to each other using outlets.

    My goal is to be able to update the views whenever something is
    changed in any one of them. So i am keeping track of which view i am
    making the change in and accordingly updating the other 3 views by
    calling this method:

    [view1 setNeedsDisplay:YES];
    [view2 setNeedsDisplay:YES];
      etc

    This seems to be working rather inconsistently for me. one view doesn
    update any of the other 3 views, one updates just one, and one
    updates all of them just fine. Ive checked the connections in IB,
    checked the outlets in IB, and checked the code. I even wrote a test
    method which prints out "hello world" just to see if the connections
    are working, and they do  work. but the views just dont seem to
    update/redisplay as they should.

    So im not sure where/what the problem is here.

    Any help would be appreciated.

    Cheers,
    Aaron
  • Am 21.10.2006 um 12:30 schrieb Aaron Boothello:
    > I have an application with 4 different views of a 3D scene. The
    > views are NSOpenGLViews. They are "connected" to each other using
    > outlets.
    >
    > My goal is to be able to update the views whenever something is
    > changed in any one of them. So i am keeping track of which view i
    > am making the change in and accordingly updating the other 3 views
    > by calling this method:
    >
    > [view1 setNeedsDisplay:YES];
    > [view2 setNeedsDisplay:YES];
    > etc

      Don't do that. Cocoa uses the model-view-controller paradigm, which
    offers a much better solution to this:

      Use NSNotifications instead. Create a model object that takes care
    of managing the data. Each view, when edited, only tells the model
    how to change. When the model is changed, it sends an NSNotification
    that it was changed, and all your views subscribe to that
    notification. That way, whenever the model changes, whether it be
    under code control or through a view, or through a numeric edit field
    in an inspector, all views you have (and even aforementioned numeric
    edit fields) will know and can update as needed.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Definitely, or even make use of Key Value Observing instead of
    NSNotifications.

    Mike.
    On 21 Oct 2006, at 13:17, Uli Kusterer wrote:

    > Am 21.10.2006 um 12:30 schrieb Aaron Boothello:
    >> I have an application with 4 different views of a 3D scene. The
    >> views are NSOpenGLViews. They are "connected" to each other using
    >> outlets.
    >>
    >> My goal is to be able to update the views whenever something is
    >> changed in any one of them. So i am keeping track of which view i
    >> am making the change in and accordingly updating the other 3 views
    >> by calling this method:
    >>
    >> [view1 setNeedsDisplay:YES];
    >> [view2 setNeedsDisplay:YES];
    >> etc
    >
    > Don't do that. Cocoa uses the model-view-controller paradigm,
    > which offers a much better solution to this:
    >
    > Use NSNotifications instead. Create a model object that takes care
    > of managing the data. Each view, when edited, only tells the model
    > how to change. When the model is changed, it sends an
    > NSNotification that it was changed, and all your views subscribe to
    > that notification. That way, whenever the model changes, whether it
    > be under code control or through a view, or through a numeric edit
    > field in an inspector, all views you have (and even aforementioned
    > numeric edit fields) will know and can update as needed.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/mike.abdullah%
    > 40gmail.com
    >
    > This email sent to <mike.abdullah...>
  • Thanks Uli.
    When i started programming in Cocoa, i started using the MVC
    paradigm. My application is mostly openGL based within the Cocoa API.
    When i first started it was recommended that combining the
    view&controller. What do you guys reckon ? i dont have any problem
    splitting them apart....would it be beneficial ? cause the OpenGL
    views do have to interact with the UI.

    Cheers,
    Aaron

    On 21/10/2006, at 8:17 PM, Uli Kusterer wrote:

    > Am 21.10.2006 um 12:30 schrieb Aaron Boothello:
    >> I have an application with 4 different views of a 3D scene. The
    >> views are NSOpenGLViews. They are "connected" to each other using
    >> outlets.
    >>
    >> My goal is to be able to update the views whenever something is
    >> changed in any one of them. So i am keeping track of which view i
    >> am making the change in and accordingly updating the other 3 views
    >> by calling this method:
    >>
    >> [view1 setNeedsDisplay:YES];
    >> [view2 setNeedsDisplay:YES];
    >> etc
    >
    > Don't do that. Cocoa uses the model-view-controller paradigm,
    > which offers a much better solution to this:
    >
    > Use NSNotifications instead. Create a model object that takes care
    > of managing the data. Each view, when edited, only tells the model
    > how to change. When the model is changed, it sends an
    > NSNotification that it was changed, and all your views subscribe to
    > that notification. That way, whenever the model changes, whether it
    > be under code control or through a view, or through a numeric edit
    > field in an inspector, all views you have (and even aforementioned
    > numeric edit fields) will know and can update as needed.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
  • Am 25.10.2006 um 08:23 schrieb Aaron Boothello:
    > When i started programming in Cocoa, i started using the MVC
    > paradigm. My application is mostly openGL based within the Cocoa
    > API. When i first started it was recommended that combining the
    > view&controller. What do you guys reckon ? i dont have any problem
    > splitting them apart....would it be beneficial ? cause the OpenGL
    > views do have to interact with the UI.

      Well, it isn't really MVC if you combine view and controller. There
    are some cases where you may want to split up the controller into a
    view-controller and a model-controller, but marging the controller
    into the view or the model destroys most of the advantages of MVC.

      Now, keep in mind, in general it's OK to call setNeedsDisplay:
    directly on you view, and to have the view tell your controller
    *directly* what it wants, but if you have several views accessing the
    same model, through the same controller, that no longer is a good idea.

      It's just a matter of using the right tool for the right job.

      One thing that helps me often, is to think what parts I would have
    to replace if I wanted to change my file format (e.g. from XML to SQL
    or whatever). Most of those parts would be what belongs in the model.
    OTOH if I wanted to turn this thing into a command-line tool, the
    parts I'd have to replace would be the "View" part of MVC.

      Does that help?

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • ive been implementing notifications into my code.

    after registering different views as 'observers' of my model. if i
    change the model from any of the views, do i need to 'post A
    Notification' in order for the other views to be updated ? or is this
    supposed to happen automatically when the model is changed ? tring to
    get this to work, so was wondering what the chain of events and
    behavior 'should' be.

    Cheers,
    Aaron

    On 25/10/2006, at 4:22 PM, Uli Kusterer wrote:

    > Am 25.10.2006 um 08:23 schrieb Aaron Boothello:
    >> When i started programming in Cocoa, i started using the MVC
    >> paradigm. My application is mostly openGL based within the Cocoa
    >> API. When i first started it was recommended that combining the
    >> view&controller. What do you guys reckon ? i dont have any problem
    >> splitting them apart....would it be beneficial ? cause the OpenGL
    >> views do have to interact with the UI.
    >
    > Well, it isn't really MVC if you combine view and controller.
    > There are some cases where you may want to split up the controller
    > into a view-controller and a model-controller, but marging the
    > controller into the view or the model destroys most of the
    > advantages of MVC.
    >
    > Now, keep in mind, in general it's OK to call setNeedsDisplay:
    > directly on you view, and to have the view tell your controller
    > *directly* what it wants, but if you have several views accessing
    > the same model, through the same controller, that no longer is a
    > good idea.
    >
    > It's just a matter of using the right tool for the right job.
    >
    > One thing that helps me often, is to think what parts I would have
    > to replace if I wanted to change my file format (e.g. from XML to
    > SQL or whatever). Most of those parts would be what belongs in the
    > model. OTOH if I wanted to turn this thing into a command-line
    > tool, the parts I'd have to replace would be the "View" part of MVC.
    >
    > Does that help?
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
  • Am 25.10.2006 um 12:14 schrieb Aaron Boothello:
    > ive been implementing notifications into my code.
    >
    > after registering different views as 'observers' of my model. if i
    > change the model from any of the views, do i need to 'post A
    > Notification' in order for the other views to be updated ? or is
    > this supposed to happen automatically when the model is changed ?
    > tring to get this to work, so was wondering what the chain of
    > events and behavior 'should' be.

      Well, that depends on how you're implementing it. You can e.g use
    bindings, or rather Key-value-observing to observe certain objects'
    values, and when those change any observers will be notified. Or if
    your objects aren't KVO-compliant, you'll have to code it manually
    either by coding your object to be KVO-savvy (thus explicitly calling
    certain methods when a value changed), or by sending NSNotifications
    whenever a change happens.

      Pick whatever you feel works best for you. The docs should help you
    determine the advantages and disadvantages of each approach.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
previous month october 2006 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