Afternoon, I have a UIImageView that I progmatically add to the window. Infact I have multiple UIImageViews that do so and when I click on any specific UIImageView I want it to become 'top-dog' so to say and be drawn over all other objects on the screen. Basically like the priority drawing for MSWindows operating systems when it comes to their windows. I've scoured all the options built in for UIImageViews when it comes to layering but I cannot seem to find any! I know it exists because in UIBuilder there is a command for sending back/front toBack/toFront. How do I access these progmatically?
Edit*
Also I fear that you might have to access the order in which the subViews are pushed into the 'subView stack' and manually move these around to achieve the result that I want and if so, how would I go about doing this?
Edit2*
Perhapse these are the functions I'm looking for?
bringSubviewToFront
sendSubviewToBack
exchangeSubviewAtIndex
Does this allow for easy Index shuffling?
UIView class has bringSubviewToFront: and sendSubviewToBack: for changing subviews z-order (see "Managing the View Hierarchy" section in class reference for more).
Related
Lets say I have a scene which includes a UIView container on the top half of the screen, and a UIView container on the bottom half of the screen and a few buttons at the very bottom of the screen.
Basically the bottom container will always display static text while the buttons across the bottom will change the content of the top container which may include an image, more buttons, or more text depending on what button is pressed on the bottom. Also each time a bottom button is pressed the top container is transitioned to the new view with a flip from bottom transition.
I have achieved this purely programmatically, but decided to convert my app to a storyboard file since it makes producing the rest of my app much faster and simpler, plus makes the code not look like a crazy mess.
My limited understanding of storyboards seems to deduce that I would need a separate story board scene for every UIView change, and Apple's coding conventions with storyboards seem to imply that we should use a new ViewController every time you create a new scene. All this adds up to an even bigger mess than I currently have.
Is there a better way of doing this? Am I misunderstanding something? If I am not confused, is there some way to make all these scene and view controller duplication cleaner?
The storyboard editor makes it difficult to do what you're describing, because it doesn't let you edit freestanding views associated with a scene.
I suggest you just create a separate nib (not storyboard) for each of the top-half views. These can exist separate from your storyboard. Your view controller (which is instantiated from the storyboard) can then load whichever nib it needs when a button is pressed, and put the view from the nib into its (the view controller's) top-level view.
There must be a way!
I accidentally opened one one day (see attached image). Although I have no idea how I did it and really really want to know, I cannot reproduce it, nor close it. The UIView opened when I was dragging my connection for the table header view from the Connections Inspector to the list of controls on the left side of the screen (not to the actual UIViewController).
I too am reworking a project with storyboards and have a similar problem with multiple views per UIViewController.
In this case it is a table header. I have other UIViewControllers in the project with the same configuration but I cannot get them to pop up either.
I have a NSTableView that holds a name to all of my NSImageView's, and depending on the order that the NSImageViews were added, the last one would be in the front.
But in the case that I want the user to be able to bring a NSImageViews in front of another, how would I do that?
Thanks in advance.
As explained on the NSView reference page, the z-order of a view's subview is given by their oder in the view's subviews array. You can insert a new subview relative to the others using -addSubview:positioned:relativeTo:, and you can reorder the existing subviews by getting the subviews property, reordering the views therein as you like, and then calling -setSubviews: to set the new order.
Specifically, the docs say:
The order of the subviews may be considered as being back-to-front,
but this does not imply invalidation and drawing behavior.
What you are asking about, I think, is how to control the z-order of views.
For historical performance reasons this is not well supported in AppKit (unlike UIKit in iOS), since until somewhat recently you couldn't actually have sibling views that overlap.
A common approach to this (on recent OS X releases) is to use Core Animation (in particular, CALayer) which does support z-ordering natively, but this is probably overkill for what you need (and in any event is going to have a learning curve for you).
What are you actually trying to do? Are these images (image views) precisely on top of one another? If so, the easiest (and much better performing) approach is to have a single NSImageView and to just send -setImage:... to it to change the displayed image.
I have a question about creating custom views. I wanted to implement an interface where I want to have different objects configured in one place, each of them with it's own controls. Kind of like in automator, on the right side view where the workflow is shown with different actions. Are those NSView or NSCell subclasses ?
Any example will be appreciated !
Ken
Here's how you can tell an NSCell and an NSView apart:
NSCells are basically stamps. Given a certain value/object, the NSCell knows how to draw that on the screen how you want it. Like NSTextCells know how to draw NSString's on the screen how you want them. NSCells don't have state, don't remember anything, they're just a one-shot set of drawing instructions that get executed with a given value/object. The idea is to reuse NSCells as much as possible to make drawing things on the screen super simple.
NSViews are sort of logical containers for what goes on on your screen. They can technically do their own drawing, but quite a few of them use NSCells to do their drawing. For example, NSTextField uses an NSTextCell to draw it's text on the screen, it also contains the extra logic necessary to toggle between editing and not-editing by displaying the text box you can type in during editing and using the NSTextCell when you're not editing. NSViews are also part of the responder chain and can respond to mouse-clicks, keyboard events, and the sort.
You're probably going to end up with both, NSViews to hold all the controls you want to use to configure each object and NSCells to draw custom UI elements (like if you use non-standard controls).
The scenario is that I have a UIViewController containing multiple "InteractiveUIImageViews" (inherited from UIImageView) each containing their own UIImage. In InteractiveUIImageView I have iplemented methods for touchesBegan, touchesMoved and touchesEnded to handle their movement and behaviour on screen. Certain objects of this type will be set as 'containers' (think recycle bin) with the objective being that when one image is dragged onto it, it will be removed from the screen and placed inside it to be potentially retrieved later.
My current thinking would be to call a new method in UIViewController from the touchesEnded method of my InteractiveUIImageView but being new to all this I'm not really sure how to go about doing that (e.g. calling a method from the 'parent') or indeed if this is the best way to achieve what I want to do.
Thanks in advance for any advice.
I'm afraid your question is (too me at least) a bit unclear. I get that your are trying drag a UIImage around a scene and drop it in drop-locations.
What is unclear is you class hierarchy. I believe that you are going about it in a wrong way. You shouldn't have to subclass UIImage at all.
Instead I would urge you to let the UIViewController manage the movement of the images. When you touch down on an image, you also touch down on its parent (containing) view.
What you have to to is then reposition the UIImage (all handled by the UIViewController) as you drag the image across the screen. When you let go you check if your finger was inside your drop-zone on touch up.
I'm looking for some kind of a basic, straightforward example of how to work with a pair of NSScrollers in an NSScrollView with a custom NSView.
There are sporadic examples out there, largely consisting of contrived examples using programatically created interfaces, or based on the assumption that the developer is working with a typical ImageView or TextView. Even the Sketch example is based on an NSView that uses the Page Setup in the Print dialog for the bounds, and everything is managed by Cocoa. So there's no real discussion or examples anywhere of how make it all work using a custom Model (though that may be part of the problem, because what does one base the Model on?). Even Apple's own documentation is dodgy here.
Essentially, I have a sub-classed NSView enbedded in an NSScrollView (per the Scoll View Guide), that a user can click in the view to create, edit and delete objects, much like an illustration program. The Model is those objects that are just data wrappers that simply record their position for drawRect: to use. The height and width are based on custom values that are being translated into pixels as needed.
My problem is that all of the examples I have found are based on either a text editor, an image viewer, or uses the standard document sizes in the Page Setup dialog. Because these are common document types, Cocoa basically manages for the developer, so the interaction code is more or less hidden (or I'm just not seeing it for what it is). My project doesn't fit any of those needs, and I have no need for printing. Thrusting my Model into the documentView property wouldn't work.
I'm just looking for a simple example on how to initialize the NSScrollers with a custom, object-oriented Model (the documentView), and handle scrolling and updating based on user action, such as when the user drags a smattering of objects off to the left or down or the window gets resized. I think I'm close to getting it all together, but I'm missing the jumping off point that ties the controls to document.
(Not that it matters in a Cocoa question, but when I did this in REALbasic, I would simply calculate and apply the MaxX, MaxY to a ScrollBar's Maximum value based on user actions, watch the position in the ScrollBar when the user clicks, and draw as needed. NSScrollers in the NSScrollView context aren't nearly as obvious to me, it seems.)
I appreciate the time taken by everyone, but I'm updating with more information in the hopes of getting an answer I can use. I'm sorry, but none of this is making sense, Apple's documents are obtuse, but perhaps I'm missing something painfully obvious here...
I have an array of objects sitting in a subclassed NSDocument which are data holders that tell drawRect what and where to draw. This is straight from the Sketch example. The Sketch example uses the document sizes in the Page Setup dialog for the size, so there's nothing to show here. I'm cool with Cocoa handling the state of the scroll bars, but how do I link up the ScrollView to see the initial editor's state held in the NSDocument and updates to those objects and the editor? Do I calculate my own NSRect and pass that to the NSScrollView? Where and how? Am I doing this in my custom NSView which has been embedded in the NSScrollView or my NSDocument in init? The NSScrollView isn't created programmatically (there's no easy way of doing that), so it's all sitting in Interface Builder waiting to be hooked up. I'm missing the hook up bit.
Perhaps I'm wearing my "I don't get it" cap this week, but this can't be this difficult. Illustration apps, MIDI Editors, and countless other similar custom apps do this all the time.
SOLVED (mostly):
I think I have this sorted out now, though it's probably not the best implementation.
My document class now has a NSRect DocumentRect property that looks at all of its objects and gives back a new NSRect based on their location. I call it in my subclassed NSView's mouse events with
[self setFrame:[[self EditorDocument] DocumentRect]];
This updates the size of the View based on user interaction, and the window now handles the scrolling where it didn't before. At this point I'm figuring out how to get the frame to expand while dragging, but at least I now have the fundamental concept I was missing.
The answer given pointed me in the direction I needed to go here (documentView requiring a view, which translated to looking at the NSView class), so Peter gets the credit. Thanks so much for help.
The document view isn't a model, it's a view. That's why it's called the document view.
The reason there are so few examples on working with NSScrollers directly is because you normally don't. You work with NSScrollView and let it handle the scrollers for you.
All you need to do is make a view big enough to show the entire model, then set that as the document view of the scroll view. From there, it should Just Work. You don't need to manage any of the scrolling-related numbers yourself; Cocoa handles them for you.
For details, see the Scroll View Programming Guide.