Currently, my Xcode4 does not stop at NSAssert failure. How can I make it stop at NSAssert failure again?
Go to the XCode 4 breakpoint navigator.
Click the + button and choose "Add Symbolic Breakpoint"
Set Symbol: to "-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]"
Click "Done"
Now you will stop in the debugger as soon as NSAssert fires. In my testing, it goes to the nearest source code and doesn't just show you the assembly where you set the breakpoint.
More Generically, you could do this:
Go to the breakpoint navigator.
Click the + button and choose "Add Exception Breakpoint"
Set Exception: to "Objective-C"
Set Break: to "On Throw"
Click "Done"
This may be more or less useful depending on your code.
See also the XCode 4 documentation result for "Adding an Exception Breakpoint"
Assertions are automatically disabled, by default, in a Release build. If you want assertions to work, do a Debug build, or turn off the Other C Flags build setting where assertions are turned off in the Release build.
Related
I have a window, a label, a button, and an NSObject.
The first thing I want to do is change the NSObject's class to that of my custom controller.
The thing is, I can't seem to select it. Whatever object I select, the inspector panel says "No Selection". Why? I'm baffled.
accepted answer did not work for me, but answer by 'NSExplorer' did (In Xcode4, the new interface builder says "no selection"). i slightly modified answer from 'NSExplorer'
.. switch to another (non IB) file in the current tab
.. switch back to the IB file (eg. Main.storyboard)
the Attributes Inspector will magically show in the new tab.
I just had to close the assistant editor and the debug area and then it magically showed up. If you don't have the assistant editor open then all you need to do is open it, then close it again. That should fix it too.
If you don't know what the assistant editor is I have highlighted it in red:
Xcode 7.2
The interface builder in XCode 4 is incredibly buggy. I'm also having frequent issues like this. Have you tried closing XCode and re-opening your project? Sometimes, resizing the entire XCode window also seems to reset the interface builder layout.
Make sure you're selecting the objects from the XIB document panel (Where it says "Objects") on the left. Sometimes clicking the actual UI controls doesn't catch in the inspector panel, for whatever reason.
For me, I had the bottom, debugger stretched all away to the top. It said "no selection." By Taping on hide/open bottom debugger twice, you can get the main component back again.
If you have multiple windows, close the storyboard file and open it again, it worked for me
I need help with Xcode 4. I started something very simple, created a cocoa project and added a Window object and called it preferences.
Then in order to access this new window I linked it with the menu item "Preferences" action makeKeyAndOrderFront.
Just that, then when I run the application, the first time I click on the Preferences menu item, the preferences window open just fine ... after I close it and click again on the preferences menu item, then application crashes with EXC_BAD_ACCESS on the main.m
Does anyone knows what is the problem?
I had exactly the same problem, and I suspect we were both following the same trail of sparse tutorial information out there to make a Preferences window like Apple's.
I solved this issue just now by just setting window = nil, and not trying to get fancy with [window autorelease]. As I tested, using [window release] would cause the issue instantly, while [window autorelease] would create that second-time crash.
I Had the same behaviour. After some tests I understood that the problem is that the second time you click the preferences menu you send a message to the window that has been released (the object does not exist anymore). You can verify it by adding the 'NSZombieEnabled' environment variable set to 'YES' on the 'Arguments' Tab of your executables from XCode.
I solved this issue deselecting the 'release when closed' check in the interface builder for the window used as the preferences window.
Bye. Peter.
I've created a new dialog using Qt Creator (version 4.7.0) - one of the templated forms (with an OK and a Cancel button).
I want the user to enter some data on the form and then when they click OK, it saves that information. So I had a look, and saw that when the OK button is clicked, it sends and signal to the dialog's accept slot.
So I right clicked on the dialog in the design view, and selected "Go to slot...". I clicked on the "accepted" option, which dropped an on_Dialog_accepted() method into the dialogs class. However, when I run the program and open the dialog, I get an error in my console saying QMetaObject::connectSlotsByName: No matching signal for on_Dialog_accepted()
So what did I do wrong?
I've found documentation on the connectSlotsByName - but nothing about any obvious pratfalls that an inexperienced Qt-developer can get themselves into.
Right-clicking on the dialog in the design view prior to selecting "Go to slot..." made a connection from the dialog's signals to the dialog's slot, which doesn't work with QMetaObject::connectSlotsByName(), since that method searches for all child objects, but not for the object itself.
What you wanted to do actually is right-clicking on the OK button, then selecting "Go to slot..." from there. It will then create a slot with the name of your button widget, and the connection will be made correctly at run-time.
It makes no sense that QtDesigner lets you select "Go to slot..." from the Dialog. You might want to file a bug to Qt's devs for that.
It is basically just as Fred explained: you did not do anything wrong. This is a QtCreator bug. And a pretty old one for that matter. Unfortunately, even two years later nothing in that regard has changed.
The assignee of the aforementioned bug decided to sort of redirect it to this QtCore bug, which simply asks for QMetaObject::connectSlotsByName() to be changed in a way that it also processes the passed object and not only its children (thereby fixing the QtCreator issue).
I had a look at the source and submitted a trivial patch.
Update: The patch got accepted, meaning this bug is going to be fixed in Qt 5.1. Note: it is not relevant which version of QtCreator your are using but which version of Qt you link your code to.
In Visual Studio 2008 while debugging an ASP.Net website I set a breakpoint in the codebehind page. I refresh the page or submit to call the method, the breakpoint is hit. Then I delete the breakpoint and continue execution. I make a change to the codebehind page and save it. I submit or refresh again and the deleted breakpoint is back! It is hit again, and I delete it again. I have tried delete, disable, nothing works it keeps coming back if I make a change to the page. It is extremely annoying and unproductive. The only way I have found to make the breakpoint permanently go away is to use the Debug menu Delete all breakpoints item, which is obviously less than ideal. I have been able to reproduce this on other developers machines also. What is going on here? Is this by design? Is it a bug in VS? How do I keep these zombie breakpoints from resurrecting?
It's probably a bug. Either use Delete All Breakpoints (Shift+F9) or try deleting the breakpoint in stopped (not Run) mode.
It's because its child breakpoints persist: MSDN article.
Your options are:
- Stop your debug session, then remove the breakpoint by clicking its red glyph.
- Find the breakpoint in the Breakpoint Window list and delete it from there.
- Use a macro to clean up child breakpoints between debug sessions, then remove by clicking the glyph.[1] (Quirky, but feels good when it works.)
- Use a macro to delete a breakpoint on the currently selected line.[2]
It's as #sgiffinusa's link describes: it's the difference between a pending and a bound breakpoint. Before the debugger is attached, it's a pending breakpoing, once the debugger is attached, it may have more than one piece of generated code accessing it, and the debugger binds a breakpoint to each path into that code. I don't get it...but that's what seems to happen. :)
One work around that seems to work for me is to, instead of toggling the breakpoint with the mouse by clicking the margin, use the F9 key (or whatever you have it mapped to,) to toggle the breakpoint off, and then press F9 again to toggle it back on, and then F9 once more to be rid of the dang thing forever.
I've no idea why that works, but it does in this office.
I've had this problem too. If you stop debugging (click stop) before you delete the breakpoint, it should go away permanently.
I think this is by design.
Remove a breakpoint in debug mode and it's temporary.
Remove a breakpoint in design mode and its permanent.
I'm using VS 2010. And in VS 2010 it's even more painful now to attach to the worker process when you want to test your local IIS site via IIS, not the VS built-in web server.
It's more painful because now when you select the worker process () via the Debug Menu | Attach to Process | w3wp.exe it brings up an additional prompt asking if you're sure you want to do this.
Even before this, attaching to the process in previous versions of VS was just outright painful. I must do this 200 times a day which wastes a lot of my time when it takes 5-10 seconds to click through and do this.
Now if you've got 2 different worker processes going, then I can see a need to choose. But before that, just getting to that attach screen is simply painful.
Anyone know a shortcut or just a quicker way other than the attach to process dialog in order to attach to the worker process in VS?
I don't understand why Microsoft doesn't add a nice toolbar icon or something that jumps you right to that Attach to Dialog screen and even better you could be able to specify only to show worker processes as an option which would save me a hell of a log of time sifting through that list even though it's already alphabetized. I still have to scroll to get to it.
Anyway, it's becoming a huge annoyance now..I'm really tired of the long way to get the attachment going to that process every single time.
Hm, not a great leap over and above what you are doing, but it may ease your workflow. have you taken a look at command customization?
Click Tools -> Customize ... (or Right-click tool bar and select Customize ...)
From Customize dialog, click Commands
Select your target, (I suggest Context menu)
Select your sub target (if Context menu, select Editor Context Menus | Code Window)
Click Add Command
From Add Command dialog, select Debug category
Select Attach to Process... from command list (near top)
Click OK
Click Close
Use your new shortcut!
Hope this helps! :)
ps: if you added Attach to Process... command to Code Window context menu, you should be able to launch the Attach to Process dialog from right clicking anywhere in a code window.
Record a macro while attaching and assign a shortcut for that macro and/or assign a menu item for it.
Steps:
Tools -> Macros ->Record Temporary macro
Attach to w3wp, Click on Ignore, etc
Stop recording the macro
Save it
To add a menu item (say under Debug) Right click on VS's Menu strip -> Customize... ->Commands -> ... Add Command -> Macros.YourMacroNAme(DebugIIS for eg)