From what you write, that’s already what I do. > Just as I thought. You're overloading the system by tightly coupling your > model and your view. Let your instruments (models) do their work, and let > your controller consult them when ready and update the view; don't use your > controller to tell the models to update the views.
That’s the job of the data collecting threads. I have one timer dispatch source per communication interface that tells the instruments objects to gather data from the physical instruments. This runs every second or so. It’s hard to tell because communication can be over wired lines or wireless. Then I have one timer dispatch source that collects data gathered from the instrument objects, process them and put them in their respective data files. This timer fires exactly once every second. One one timer dispatch source deals with synchronization issue. It fires exactly once every second, returns ASAP. On UI update dispatch source that should ideally collects data gathered from the instrument objects and display them. And there is a slight shade of gray. Instead of having an other object owning the properties bound to the UI and doing displayObject.boundProperty = instrument.valueProperty, the properties bound to the UI are members of the instrument object. So what happens is I do instrument.boundProperty = instrument.valueProperty. Finalizing the decoupling would not solve the memory display issue, since it’s a bug in appkit itself. It would just make things a little bit cleaner. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
