I found a view is somehow added under the control of a view controller, how can I track this process while debugging? My goal is to find where and how this view is created and added so that I could remove it since I don't need this view. Thanks.
You can use the Debug View Hierarchy:
Here you can see al the views, find the one you' re looking for, select it and select Show the Object Inspector:
There you will see the memory address of the object, in my case I've selected a UILabel, then you can add a watch expression on the debug area by right clicking:
Write the address casted to your view element (again, in my case a UILabel):
((UILabel*) 0x14ff9c80)
Finally, you will see something like this:
With this you will be able to get some information of the view you're looking for.
You can create a custom subclass for your self.view in UIViewController and override addSubview and insertSubview:atIndex and put breakpoints there.
All added views then should trigger a breakpoint.
I want to design and generate view elements in code, without using storyboard. But I haven't figure out a simple way to locate where should I put my view elements by describing its CGRect. For example, I can drag a button direct into the storyboard and put it where i want, however, in code, I have to write something like
[button setFrame:CGRectMake(24.0f, 113.0f, 271.0f, 140.0f)];
Is there any way or any software can help me?
Your question is a bit broad. You can create your view in code by including in your subclass of UIViewController properties for each subview (control) element and then make all the initialisation in designated initialiser and setting frames and other customisation in viewDidLoad method most likely. But for details where to what set you should go to references for UIViewController lifecycle as it may depend on what you want to achieve. in some cases setting frames in viewDidLoad will be fine whereas sometimes you will need to make some changes in viewDidLayoutSubviews for example.
I have googled a lot, but some where I am doing a mistake regarding the xib file. I have four buttons in view controller.xib file. Then when I tap the button one two three, alertinputtypetext has to be dislayed. Its done successfully.
But when i tap the fourth button, I need to display pickerView.xib. But when I am debugging the application, the application sequence is missing and showing the main.m class.
Please help me somebody. Give me hint to proceed further.
"I need to display the another file pickerView.xib" ?.. if pickerView is UIViewController subclass you could show it simply .. if its just a nib file contains a pickerView , you could use loadNibNamed:(NSString *)name owner:(id)owner options:(NSDictionary *)options , but actually you don't need to put it in separate nib file .. xib can hold more than one view inside it , so you could use you original viewController.xib , or what I prefer is to it programmatically without loading it from xib.
I've got an app that I've developed for the iPhone, but now want to port to the iPad. The iPhone app is navigation style and based on discrete table view controllers managed by a nav controller. The larger screen real estate of the iPad means that I can comfortably fit a couple of these table view controllers on to the screen at the same time.
The question is how? Should I
a) have the main view load two table view controllers from separate NIBs and then position them on screen (I'm not sure how I set they x and y of subviews loaded from nibs).
b) create sub-views in my main nib and populate these with data from my existing classes (if so how do I hook up the IBOutlets)?
c) do something completely different
One thing I should point out is that I don't want to use the split screen option.
Alert! This QA is now of historic value only.
It is now trivial to do this sort of thing with container views in iOS, which is why Apple edited them:
https://stackoverflow.com/a/25910881/294884
How to add a subview that has its own UIViewController in Objective-C?
Historic answer...
".. how I set they x and y of subviews loaded from nibs?"
I'm not sure if I fully understand your question Phil, but here's an easy and clear way:
Fire up interface builder and in the new larger iPad view, simply add new smaller views (UIViews)... Put them exactly where and how you want them. We are going to call these "basket" views.
Let's say one of your complicated views from the other app is your fatDogs view. Call the new basket view fatDogsBasket. Then in the code, in viewDidLoad, just do the following with all these "baskets"...
[fatDogsBasket addSubview:fatDogs.view];
[clientsBasket addSubview:clients.view];
[namesBasket addSubview:names.view];
[flashingLightsBasket addSubview:flashingLights.view];
// etc
You're done! (Obviously, make sure that the relevant view controllers, fatDogs, flashingLights and so on, are all ready to go and instantiated.)
The "basket" system is handy since each one will hold your previous work in one place; usefully you can (say) set overall invisibility or whatever just by touching the baskets. Obviously, if you want to set, or maybe move, the position of a basket in the code, just go
happyBasket.frame = CGRectMake(509,413,
happyBasket.frame.size.width,
happyBasket.frame.size.height);
UIViews in iOS are very lightweight, so it's no problem at all adding another layer of UIViews.
I hope this is what you were getting at!
------Later...
You went on to ask: "Just to make sure I'm clear on the right way to implement this. The main view controller has IBOutlets for each of the 'baskets' and its this IBOutlet connection to the subview that I'm calling. Each of the view controllers that I'm going to show in each basket has it's own nib and associated IBOutlets. Right? –"
So, "The main view controller has IBOutlets for each of the 'baskets'"...
Right, the main view in the new app, would have lines like this in the .h file:
IBOutlet UIView *fatDogsBasket;
Note that you are simply declaring "fastDogsBasket" to be a UIView. You shouldn't worry too much about the "IBOutlet" word. All that means is "I need to be able to look this item up, over in the interface controller." It's important to realise IT DOES NOTHING.
So yes all the "baskets" will be UIViews and hence of course you must delare them as such in the .h file of your main view controller. Personally is would not use the phrase "a view controller has IBOutlets." It sort of confuses things and gives the wrong idea. Just say "don't forget to mark the UIViews as iboutlets in the header file."
So anyway yes that's exactly what you do, declare all the "basket" UIViews in the .h file of the main controller, and indeed mark them all as IBOutlets so that interface builder will work more easily. Next ..
"its this IBOutlet connection to the subview that I'm calling" -- that's wrong.
The basket such as fatDogsBasket IS SIMPLY A UIVIEW and that's that. It's just a UIView.
Now, as you know you can put UIViews inside other UIViews. (Obviously, this is commonplace, every UIView has scores of UIViews inside it and so on and on - it's the most basic part of building up an interface.)
So, what are you going to put inside your fatDogsBasket uiview? You're going to put in ALL YOUR PREVIOUS WORK on fatDogs! Previously (for the iFone) you wrote a wonderful class - a view controller - called fatDogs. (It may well have even had many subclasses and so on.)
We're now going to take the view from fatDogs (of course, that is fatDogs.view) and literally put it inside fatDogsBasket. (Recall that fatDogsBasket is a UIView.)
So firstly you would have to completely include your amazing class fatDogs (from the old project) in your new project. Click "add existing flies/classes" or something like that...you'll figure it out. Yes, add all the class files, xibs, any subclasses and so on.
Then, simply do this .. in your new super-powerful uber-controller, in viewDidLoad, just do the following with all the "baskets"...
[fatDogsBasket addSubview:fatDogs.view];
[clientsBasket addSubview:clients.view];
[namesBasket addSubview:names.view];
[flashingLightsBasket addSubview:flashingLights.view];
// etc
You're done! Note that the view from fatDogs (ie, fatDogs.view) is now displaying inside of the UIView fatDogsBasket. The class fatDogs will now work completely normally, just as it did in the old days! And incredibly, you can easily (here in your new controller) do things like simply move fatDogsBasket, and it will move the fatDogs view easily all at once, without worrying about the details of fatDogs and it's views.
Finally you ask..
"Each of the view controllers that I'm going to show in each basket has it's own nib and associated IBOutlets."
Exactly correct. When you add your old system "fatDogs" to the new project, you will be adding all of it's xib files and so on. Anyting that happens or doesn't happen inside those classes, to do with perhaps buttons or anything else marked as iboutlets, or anything else, will just still be the same within those classes. I'm pretty sure absolutely NOTHING will change when you use those old classes in your new project.
Just for the record .. "Each of the view controllers that I'm going to show in each basket.." Just to be accurate, you don't really show as such a viewcontroller, you show the view of the viewcontroller (!!). In other words, for fatDogs (a view controller) you will be showing it's view, which is, simply enough, referred to as fatDogs.view. ("view" is, of course, a property of any UIViewController, so you can just say vcName.view and you're done.)
Hope it helps!
And finally you ask .................................
"I've got it compiling OK, but my baskets are showing up empty, i.e. they're not showing the views of the view controllers that I've imported."
Tell is the name of one of your UIViewController classes from the old project, so we can be specific
Let's say you have an old UIViewController called HappyThing. So you will very likely have a file HappyThing.h and a file HappyThing.m and a file HappyThing.xib.
put all those in the new project, you must do so using Add->Existing Files. (Control on one of your current filenames in the list on the left in XCode.)
You will have to do this #import "HappyThing.h" somewhere or other in your new project - either in your Prefix.pch file or at the top of your new UIControllerView
To be clear in HappyThing.h you will have a line of code
#interface HappyThing : UIViewController
In your new UIViewController.h file, you will have to add a new variable, we'll call it xxx,
HappyThing *xxx;
Note that the type of xxx is HappyThing. (Note that as a rule, you would use the naming convention "happyThing" (note the lowercase "h") rather than "xxx", but it's just a variable and I want it to be clear to you that it's just a variable.)
Next! At the moment it's just a variable that is not pointing to anything, it's nothing. (Just as if you said "int x", but then did not actually say "x = 3" or whatever.) So! In your code you have to actually instantiate xxx.
xxx = [[HappyThing alloc] init];
[xxxBasket addSubview:xxx.view];
Note that the first line is what makes an instance of HappyThing come in to existence. And of course, you want to use "xxx" to point to that instance.
The second line puts the view in to the relevant basket! Note that of course what you want is the view associated with xxx (ie, xxx.view) ... remember that xxx is a UIViewController, it is not itself a UIView. The associated UIView is "xxx.view". (The view is literally just a property of xxx.)
Memory management! Note that you used "alloc" to bring xxx in to existence. This means you DO own it, and of course that means YOU DO NOT need to send a retain there. Furthermore, since you do own it, that means You eventually have to RELEASE it. (easy ... [xxx release];)
So simply add the line [xxx release]; to the dealloc routine in your new UIViewController. (Really it won't cause any harm if you forget to do this, but do it anyway.) Conceivably you may want to release it earlier for some reason once you are more comfortable with the process.
(I was just working on a project with a huge number of huge tables, popovers and the like, so I only made them on the fly and got rid of them as soon as possible, to use less memory. But all of that is irrelevant to you at this stage.)
So now you should SEE IT ON THE SCREEN!
Don't forget if you previously had some routine in HappyThing, which you had to call to start it working (perhaps "beginProcessing" or something), you'll have to call that yourself from the new UIViewController. Hence perhaps something like:
xxx = [[HappyThing alloc] init];
[xxxBasket addSubview:xxx.view];
[xxx beginProcessing];
[xxx showAmazingRedFlashingLights]; // or whatever
Finally you asked ...
"When you've use this technique, do you simply include the headers of the imported files in your main view controller, or do you forward class them in some way?"
That was not your problem, your problem was that you were not instantiating it with the line xxx = [[HappyThing alloc] init];. So, good luck!
Regarding the line of code "#class HapyyThing", if you want to simply put it just above the start of the definition of your new UIControllerView. Generally you don't have to if you have your include line in the best place. Anyway it is an unrelated issue. It simply won't compile if your new UIViewController, can't find HappyThing. Enjoy!
I have a nib file where I have a view that contains a background image, a button and another image that covers the full screen (a shadow) that needs to be moved to the front.
On the view, I'm creating child views, and after creating those and adding them using [self addView] I need to move to the front the shadow image.
I'm currently using the tag attribute to find that view, but I'm thinking there's probably a better way, by means of identifying the subviews I add in Interface Builder by some name.
I tries adding a IBOutlet to connect the subview with its parent, but it didn't work (and made no sense, since the subview is already connected to its parent in some way).
The IBOutlets way should work, and is probably the best way to do it. Make sure you made the proper connection in Interface Builder after you declared them in the .h file.
The iPhone does a lazy loading of view controllers. The nib might not have been loaded in initWithCoder or any init method for that matter as Kendall specified.
viewDidLoad is the preferred place to access anything from the nib if you want to access them before the view is displayed.
Hope that helps.
At what point are you trying to access the subviews? If you try within init of a ViewController, the IBOutlets will be nil. The first method you can get at them is probably viewDidLoad.
The reason it does make sense to do things this way is that IBOutlets are just direct pointers to some component, even if they are already subviews of something else. Just saves a lot of hunting.
Using the Tag is a perfectly valid way to locate specific views, so long as you're using the viewWithTag: method. If you're already using tags, there's no need to change to IBOutlets unless you just don't like calling viewWithTag:.