I divided the Main View of my VC++6 MFC application using Static Splitting with rows and columns like (1x2) or (3x3) and so on.
One of these parts, when clicked on, is the Active View.
When I draw a shape say, a circle/rectangle on the Active View, all the other Views ape the shapes I drew on the Active View. How do I avoid that?
I tried UpdateAllViews() with the Active View as first argument. It still does the same.
Any ideas?
If you are using the same class for all views this is expected behavior, since splitter wires all views to the same document object. I presume that you are use document object for drawing data storage.
UpdateAllViews is used for to update views if data in the document change. Each view then uses document’s data to render different visual interpretation of this data. Hence each view would be a different type (represented by different classes) knowing how to visualize data.
For example: document is used to store number array. Three views are showing those numbers as decimal, hex and binary representation.
If one number is changed, all views are notify to update own representation.
In your case working solution would be to move drawing data to the view rather than the document. Most likely your application does not need a document at all.
UpdateAllViews() calls the OnUpdate() function for each view. The default implementation of OnUpdate() invalidates the client area (talking about simple "graphics" views like CView() or CScrollView()). You can override the OnUpdate() member and encode the desired behaviour (as far as invalidating/updating is concerned) in the lHint and/or pHint parameters.
Related
I am building an app, which will draw a representation of column-based data. I need both interactable cells and headers, so instead of adding suppplementary views for each column, I made another NSCollectionView that contains headers only.
The issue is that I would like to share selection rectangle state between these collection views, but I am not sure if there's some good way to achieve that or I have to hack whole controller.
Initially I was thinking about making an overlay on whole window, that would register in first responder chain, but it would use methods like draggedMouse only in my own methods and I would override built-in to pass the events to views behind, then if the view detected that user would like to draw a selection rectangle (select multiple items), that event would be moved to overlay view.
I thought also about making first row of items as sections (I am using compositional collection view layout, so it isn't that hard), but I think it would make features like drag and drop a huge pain in the bottom.
On the image you can see part of these collection views and how it looks now.
I created a custom NSView that displays some data exactly the way I want it to (a line chart of sorts). I now want to add a couple of sliders to have the ability to zoom the displayed data in and out. I would also like to add a couple of checkboxes so that the incoming data can be interpreted and graphed in different ways, and maybe some scrollbars to be able to see past data. I need to have at least 5 copies of this view (with all its controls) on screen at the same time, each showing a different data feed.
This way of thinking a user interface falls nicely into the WebComponents paradigm where you can design a component that encapsulates many different ones. As I understand it, there is no way of nesting controls like this into a master control in Xcode.
Of course I could layout all the views and all the controls separately inside a view controller and achieve exactly what I want but it would not be as maintainable as having ONE object that I can duplicate either in interface builder or in code.
My question is: what is the proper way to achieve this in Xcode (if any)? I don't need code examples but rather a conceptual answer and I'm only interested in answers related to Cocoa rather than CocoaTouch.
I just learned that you can have multiple view controllers as child controllers. This is exactly what I was looking for as it maximizes reusability and reduces maintenance.
In order to explain what problem I am having I will quickly explain the scenario. I have a synthesizer I am building that has several "control views". One control view may be 4 vertical sliders while another is one big matrix or something.. So, say I have control views 1-4. In addition, I have two main sections (which are just holder views), which can contain one of the 4 control views. At any given moment, sectionA can have controlView4 while sectionB can have controlView2. This works perfectly.
The problem with this is SectionA cannot have ControlView1 while SectionB has ControlView1 simultaneously. This leads to undesirable behavior. For example, if SectionA currently has ControlView1 while SectionB has ControlView4 (which will wrap around to ControlView1 on the next toggle), than the next time I toggle SectionB's active ControlView, SectionA's ControlView will simply disappear. (presumably because UIKit implicitly removes it from SectionA's subviews when I add it as a SectionB's subview.)
So, there is some default behavior of UIView that isn't ideal for this modular scheme I wish to implement. That being said, is there a way to achieve what I want without deviating to far afield from iOS best practices and sane code design?
First, I would want to have a different type of view controller for each type of view. Then, each time I wanted a view in a section, I would create its matching controller and have it take over that container area. If the four sections are then displaying multiple copies of the same view, they each have their own controller to keep them organized.
Assuming you have your data model separate from your views and controllers, there should be no extra complexity.
In the MVC model, where does the view differentiate between the model when the views are sufficiently complex?
My question arises from my attempt to develop a desktop application with a Canvas view. The user has a click mode (e.g. select, add object A, add object B, add object C, etc.). When performing actions, this changes data in the model. The state of the model can later be saved to a file via another view control.
When starting the project, I attempted to encapsulate as much of the Canvas-specific state as possible into the Canvas view. However as I attempt to fit the MVC pattern, it seems as though most of it belongs in the model.
I feel as though the Canvas class is complex enough to contain its own state, which is where my confusion arises. It contains the location of several types of objects on the Canvas. Where does the boundary lie between view data and model data? Or is this a case where there is MVC within an MVC (i.e. M V(MVC) C)?
I have chosen MVVM after looking into some patterns. It seems to be exactly what I needed. The ViewModels hold data specific to the views or controls, that will never be saved but still need to be bound to by the UI.
I am trying to create a Mac OS X Cocoa based application with data displayed in a tabular format, but the data needs be displayed vertically in one column per entity instead of the standard NSTableView one row per entity functionality.
Is there an appropriate Cocoa class for this? Essentially I'm looking for a "horizontal" table of NSControls, but I do not need headers, sorting, etc. I just need a view to bind my core data array of entities to that displays the data in various NSCells depending on the field. (i.e. instead of one column of checkboxes and another column of textfields, I need one row of checkboxes and another row of textfields, etc.)
Thanks!
There is no pre-baked Cocoa control that handles this exactly like a table, just in "vertical" mode.
You might try NSCollectionView set to one row and unlimited columns. Create your NSCollectionViewItem (as the "prototype" or template) in a vertical configuration and you should be good to go for the most basic needs and even throws in some pretty animation.
The problem is, it's only available starting at 10.5 and is a lot less useful unless you're targeting 10.6 as a minimum. Even then NSCollectionView/Item can quickly become too unwieldy if your needs go beyond the basics it provides. At that point, creating your own home-brewed equivalent that targets what you need might be easier.