I recently ran into an issue where I would go to check the callers of a method using the Assistant Editor, but it would display as if there were no callers of the method in question.
I narrowed it down to that method being inside a conditional preprocessor directive. When I removed that, I was able to find the callers of the method.
Is there a way I can get Xcode to recognize the callers without removing the conditional preprocessor directives? Or do I need to continue with the work around every time?
I was experiencing this issue but with a different cause. In my case, callers was greyed out because I had a device connected that was somehow preventing it working. Disconnecting the device caused the code coloring to work and populated the callers list
Edit: deleting device data under Window/Projects (Xcode 6.3.1) permitted code coloring to work again while the device was connected and callers list was again populated
Related
iOS 10 / Xcode 8 GM build getting the below, never had it before on Xcode 7. Any ideas?
objc[25161]: Class PLBuildVersion is implemented in both
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/AssetsLibraryServices.framework/AssetsLibraryServices
(0x12049a910) and
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/PrivateFrameworks/PhotoLibraryServices.framework/PhotoLibraryServices
(0x1202c4210). One of the two will be used. Which one is undefined.
(NOTE: Only seems to happen in simulator, does not appear on real device).
Main Idea
Main idea is simple:
If your app (or dependencies, such as Pods) uses framework, that uses explicit (or implicit) PhotoLibraryServices.framework or AssetsLibraryServices.framework as dependency, Xcode warns you (even if you are using only one of them). It might be Photos/PhotosUI.framework or AssetsLibrary.framework, or another (I don't have full list of dependencies, but it is possible).
What is the problem?
Class with name PLBuildVersion is defined in both PhotoLibraryServices.framework and AssetsLibraryServices.framework. Class name is unique in Objective-C (you can't define 2 classes with same name), so it is undefined which one will be used in runtime.
However, I think that it will not be a problem, because both classes have same methods and fields (checked this with disassembler) and I guess that both were compiled from the same source.
Radar is already sent.
As per answer from Apple employee on Apple's Developer Forum:
You don't control either of the class sources listed, so there isn't anything you can or should do – aside from Reporting a Bug.
I was unable to find a way to get rid of the warning, but if you want to prevent the app from crashing, you need to provide a description for why you are accessing the camera, photo library, etc. This is new in iOS10.
Input the following into your Info.plist file.
Photo
Key: Privacy - Photo Library Usage Description
Value: $(PRODUCT_NAME) photo use
Camera
Key: Privacy - Camera Usage Description
Value: $(PRODUCT_NAME) camera use
More info can be found here: https://iosdevcenters.blogspot.com/2016/09/infoplist-privacy-settings-in-ios-10.html
I find you can get this error merely by using a UIWebView. My solution was to replace my use of UIWebView with WKWebView.
I had this after adding Answers on Fabric to my project.
Deleting derived data did the trick for me. (shift alt command k in XCode)
Edit a year later:
After deleting derived data, always exit XCode and start it again.
In unrelated cases I have the impression that deleting derived data does not clear XCode’s in memory caches of the derived data.
Resetting the iOS simulator fixed this for me. Simulator -> Reset Content And Settings.
In my case this warning started to appear after opening a second xcode project and running the second app on the simulator. After changing back to the first app, the warning started to appear. I just quit the Simulator and Xcode and reopened my project. The warning disappeared after that. If that doesn't solve it, proceed with the other answers. Xcode can be really picky sometimes.
I am trying to compile a VB6 application, but it fails with the error, "Run-time error '91': Object variable or With block variable not set". It turns out the Resize event of a user control is firing during compilation and calling code that attempts to access an object that has not been instantiated yet.
Why is an event firing during compilation and is there any way to stop it?
Edit: I had some code here, but it's not relevant. The problem results from the fact that UserControl code (namely the Initialize, ReadProperties, Resize, and WriteProperties events) can execute at unexpected times. If the code in these events relies on other code to initialize any of its data structures, there's a good chance it's going to fail because that initialization code may not have executed. Especially during compilation when nothing is supposed to be executing! I'd call this a bug, but I'm sure Microsoft can rationalize it somehow.
Here's is a good article on the lifecyle of user control events
Understanding Control Lifetime and Key Events
Here is one snippet
Compiling the Project
When the project is compiled into an
application or component, Visual Basic
loads all the form files invisibly,
one after another, in order to write
the information they contain into the
compiled file. A control instance gets
the Initialize, ReadProperties, and
WriteProperties events. The control's
property settings are compiled into
the finished executable.
It doesn't mention resize (which happens during run-time or when you physically resize the usercontrol on a container in design-time). Maybe your Initialize event is resizing the user control?
To avoid the error you can check if the offending object has been created before doing anything:
If Not Object Is Nothing then
do something
I think some events for user controls get executed during design time, at least for the purpose of rendering them in a consistent way.
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
When trying to restore a version of a document in my document based application, I get an error:
kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList(). Compensating...
kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged.
and the document remains unchanged. Also, when this happens, I get a message as soon as I start editing the document telling me:
The document [...] could not be autosaved. The file has been changed by another application.
I think these two problems may be related.
I don't know what to do or "check" because versions just works without any implementation needed; I'm actually confused, because Apple says that I just need to enable autosave in order to restore/revert using versions. Does anyone know what can be causing that error?
Thanks.
I've ran into all of your issues, causing me much pain.
I've gotten that error message regarding kCGErrorFailure... before as well when browsing versions. I've just ignored it mostly as it seems harmless to me. TextEdit seems to spit out this message as well. (Looks like an Apple bug)
For the "document remains unchanged", check here: Restoring from versions browser on OSX lion not working... ideas? (in short, your code for updating your document's UI is probably not being called for the document that is being reverted) (Looks undocumented to me)
For autosaving issues, check here: http://www.cocoabuilder.com/archive/cocoa/306217-how-to-implement-autosaving-browsing-versions-reverting-to-last-saved-in-lion.html (in short, use the file wrapper methods instead for reading and writing). (Looks like an Apple bug)
As well as returning YES to autosavesInPlace: your document needs to at least call updateChangeCount: passing NSChangeDone whenever it changes, so that it "knows" that there are changes to be autosaved.
I am trying to compile a VB6 application, but it fails with the error, "Run-time error '91': Object variable or With block variable not set". It turns out the Resize event of a user control is firing during compilation and calling code that attempts to access an object that has not been instantiated yet.
Why is an event firing during compilation and is there any way to stop it?
Edit: I had some code here, but it's not relevant. The problem results from the fact that UserControl code (namely the Initialize, ReadProperties, Resize, and WriteProperties events) can execute at unexpected times. If the code in these events relies on other code to initialize any of its data structures, there's a good chance it's going to fail because that initialization code may not have executed. Especially during compilation when nothing is supposed to be executing! I'd call this a bug, but I'm sure Microsoft can rationalize it somehow.
Here's is a good article on the lifecyle of user control events
Understanding Control Lifetime and Key Events
Here is one snippet
Compiling the Project
When the project is compiled into an
application or component, Visual Basic
loads all the form files invisibly,
one after another, in order to write
the information they contain into the
compiled file. A control instance gets
the Initialize, ReadProperties, and
WriteProperties events. The control's
property settings are compiled into
the finished executable.
It doesn't mention resize (which happens during run-time or when you physically resize the usercontrol on a container in design-time). Maybe your Initialize event is resizing the user control?
To avoid the error you can check if the offending object has been created before doing anything:
If Not Object Is Nothing then
do something
I think some events for user controls get executed during design time, at least for the purpose of rendering them in a consistent way.