Abnormal behaviour in Xcode? - xcode

I was developing an application based on navigation controllers and tableviews. After working for two days, I experienced abnormal behaviour in xcode. For debugging errors, I used 'NSLog()' and alert view. But it was not executed while debugging. Some codes which i changed was not shown in the execution. Then it got worse, even it didn't recognize break points inside the code. Even I closed the application and restarted it. Still it was giving the same problem. Then I deleted the build folder. And then it became normal. Why this happened? Whats the reason behind it?

As a general strategy, when I see weirdness like that during development, I do a 'clean all' (equivalent to deleting the build directory) and rebuild. It's not a guaranteed fix, but sometimes it helps.

Related

Xcode4 breakpoints adapt to code changes?

I have a series of logging breakpoints in Xcode4 that I'm using to selectively log things as I need them. However, whenever I make changes to the code involving adding or deleting lines, these breakpoints get out of sync with where they are supposed to be, sometimes even going to a completely different function.
Is there a way to keep the breakpoint in sync with the code, rather than just rely on the line number?
I believe it should, at least it's the IDE's usual behaviour.
Just a thought. Have you tried to reinstall XCode? I have experienced all sorts of weird bugs since the upgrade to XCode 4. For example, being unable to select a XIB file for a popup window in a project---and when creating a project from scratch, I was able to select that XIB and create the popup. At the time I posted a question on StackOverflow about this and it is still unanswered ever since.
Since that time, the project was overhauled and now I build my interfaces from scratch using full Obj-C code, dumping the interface builder 99% of the time...

Xcode not predicting

Am new to objective-c and xcode, and i love programming with them. But am facing a problem with xcode this has occurred quite a few times before, i.e the xcode's Auto-Suggestion mode is not working.
By Auto-Suggestion i mean- when i type say two letters 'UI..' xcode predicts the remaining word to be "UIColor, UIButton, .. etc".
Same for the instance methods eg. you type 'init ' and a list is shown as "initWithFrame,
initWithNibName, .." and so on, which makes coding so easy.
But after i performed some operation like undo or delete i don't remember what i did exactly, this auto-prediction is not working and this is happening only on a particular file.
Any idea what i did wrong to make this happen?
Thanks
Xcode sometimes freaks out and exhibits this behavior. Best you can do in this case is clean your project (cmd-shift-K), close Xcode, then re-open it.
I have noticed this behavior especially when using #defined macros extensively.
I know this post is old, but the correct way to resolve this issue is to clear your derived data. After cleaning the derived data and restarting Xcode, your project will say "Indexing" which is the process of setting up everything required to make this feature work. After that, everything should work again.
To clear derived data go to Xcode->Preferences. Then click the little arrow next to the path to the derived data folder. Finder will open with the projects in derived data. Simply select and delete the one specific to your project giving the issue (Don't worry, this will not affect your project).
If there are any compile errors, then also prediction doesn't work properly. try resolving them first.

Why is xcode(4) so slow to dismiss errors I've already fixed?

So I hit Cmd+B and xcode throws all these errors and warnings at me. But after I fix them, xcode is sometimes slow to catch on, often requiring another Cmd+B on my part to nudge it to recheck the file. Is there a setting somewhere I can toggle to make xcode recheck for errors more aggressively?
It seems there's still room for improvement on the things that cause Xcode to retry your code. One thing I've noticed is that if you change something in a header than navigate back to the implementation, it quite often won't detect the fix until you force a build (or run it, which builds first).
The workaround? Save (Cmd-S) the file before navigating away from it or save all files (Cmd-Opt-S) if you've fixed several problems across several files.
The long-term solution? File bug reports at http://bugreporter.apple.com

MSTest stops debugging tests outside test project in 2010

I have no idea how this started so I'm guessing there's a setting somewhere that I've been unable to find. I have a test that calls a method but when I run debug, it simply will NOT step into that dll. At all. Period. Throws an exception just fine, but it's kind of worthless when I can't step into see what's actually going on.
When another team member picks it up, he's able to debug the exact method I was attempting to target. Yes, same breakpoints, yes, same code (I checked in, he got it, ran just fine)
What the hell?
update : checked the test project for stupid entires, deleted the debug/release folders for fun, I've went though and dumped the project completely and got it back out of tfs. I've nuked the appdata/local/ms/vs/10.0 folder and the /appdata/roaming/ms/vs/10.0 folder. Deleted the local test results.
You probably need to investigate your project references. Is the DLL possibly GAC'd? Take a close look at the *.csproj file.
The fact that it can be debugged no problem on someone else's machine indicates to me that you're having an environment issue. Some sort of multiple library reference issue.
Another possibility: Visual Studio (and all its embedded tools) can have many strange caching behaviors. You might want to clear out extraneous MSTest-related temporary cache files/dirs.
Ok, got it. You can't do one of those things and it works. I had to do them all prior to opening up vstudio again. It'll blow your settings away just as a heads up.
Kill the AppData/Local/Microsoft/visualstudio/10.0 folder
Kill the AppData/Roaming/Microsoft/visualstudio/10.0 folder
Kill your entire project ... all of it.
Get latest (force)
And it works again.

Why does 'clean' magically fix mysterious bugs in my app?

If I ever have a problem that is not showing up as a warning, but makes my app crash on runtime, sometimes I'll build->clean and often it this unkown bug disappears. This happens mostly when I import new images into the project(replacing old ones) or when I make major syntax changes with my code.
F'in 'Clean all Targets', how does it work?
Thanks
When you build for the first time, all of your code is turned into object code. That way when you make a tiny change to one file, you don't have to recompile your whole project, just that one file.
Now sometimes things go funny and stuff doesn't align properly, or dependencies aren't updated and boom crash. The build system is supposed to detect this but every project I've worked on has had this problem at one time or another.
Build clean deletes all the intermediate object code and recompile from scratch.
When you clean your project, you force your entire application to recompile itself. Maybe one of your resources was compiled into your application in a way that required you to recompile everything when changing the resources?
What sort of application are you building - do you use threads? I would make sure they aren't race conditions, because their trademark symptoms are sporadic non-reproducible errors.

Resources