Is the method removeAndReturnError: not necessary? - cocoa-touch

I've just read the documentation about conflict resolution with UIDocuments in the iCloud:
Resolving Document Version Conflicts
In the last point of the chapter "How to Tell iOS That a Document Version Conflict Is Resolved" is written:
Remove the resolved versions of the document.
For any versions you no longer need, call the removeAndReturnError: method of NSFileVersion to reclaim the storage for the file. Document revisions remain on the server until you delete them.
But in the code sample "Listing 6-3" there is no removeAndReturnError: method called.
Is this method not necessary or where should I call it?
Thanks for any help
Linard

Related

How to fix the auto code formatting in Pharo?

When I save a method and get back to it later, all of my variable names become temp and all of my parameters becomes arg and the code indentation get changed.
Any thoughts on how I can fix this?
The behaviour that you are experiencing is not code formatting at all. You immage is experiencing an issue where it can't access original source code. Thus it uses a backup solution and decomples method bytecode. During the compilation process the variable names are erased, so they can't be re-created during the decompilation, and generic substitudes are used instead.
Now, why you are missing sources is another question. First of all it's important to check if you get some exceptions. Often these happen when you open or save your image, but also thaty may occur when you save methods.
Depending on the Pharo version you may be missing .changes or .sources files. This often happens when you more an image without moving other supporting files.

Check if method is deprecated

Is there any possibility to programmatically detect if a particular method is deprecated in the current version of system? Thanks
No, there is no any way to programmatically detect if a particular method is deprecated in the current version of system. The only thing you can get to know through warning message that your method is deprecated.
warnings are based on your deployment target.
set the Deployment Target to the latest version.
Do a build from the Product menu, see all the warnings.
You (and others getting here) may be trying to ask a slightly different question - how can you check to see if a deprecated method (aMethod:) of a non deprecated class (aClass) is still available at runtime? You can do that with:
if([aClass instancesRespondToSelector:#selector(aMethod:)]){
// it's still available for use
}

GData causing an error message when running the profiler

So, my dilemma here is pretty much the fact that I have GData included with static headers in my file per the instructions found here: http://hoishing.wordpress.com/2011/08/23/gdata-objective-c-client-setup-in-xcode-4/. Everything compiles correctly and such and I can run the Analyzer just fine. The minute I try to run the profiler to check for leaks, it hits the attached error The service placeholder compiler flag should be replaced by actual service specifications as seen below:
I'm not %100 sure on what I need to do to make this an acceptable service.. or why it triggers this error. Implementing GData was already a not-so-fun walk in the park. (Thank you the guy who added his static tutorial in google's documentation.. lack of documentation). Does anyone know specifically what needs to be done and/or how?
From the docs...
There is a conditional set in the static library target as a reminder
to developers to define the needed services. For your project, replace
or delete the definition
-DGDATA_INCLUDE_nameServiceHere_SERVICE=1
in the Other C Flags section of the static library target's Release
configuration.

How do I find solutions for deprecated code?

I'm new to Mac programming. When I open sample projects, I often get 'deprecated' code warnings during a build. I'd like to fix these and get a clean build using XCode 4.
When Apple deprecates something, how do I find out why it was deprecated?
More importantly, how do I find out what is the 'new' correct way to implement the deprecated task?
For example, I'm seeing deprecation warnings for: QTMovieSizeDidChangeNotification, writeWithBackupToFile, documentForFileName, shouldCreateUI, setShowPanels, QTMovieCurrentSizeAttribute, and many others.
Look up the method in the documentation - they show the deprecated methods and tell you what the preferred methods are.
For example writeWithBackupToFile is clearly marked as deprecated and shows that writeSafelyToURL:ofType:forSaveOperation:error: should be used instead.
Same with shouldCreateUI which shows that either openUntitledDocumentAndDisplay:error: or openDocumentWithContentsOfURL:display:error: should be used instead.
Also, read the other methods in the documentation - you'll find things that do what you need. For example you list QTMovieSizeDidChangeNotification as being deprecated (in QuickTime 7.6.3). Right above it in the documentation you can see QTMovieNaturalSizeDidChangeNotification which has been available since QuickTime 7.6.3). Use that instead.
Look for the deprecated things in the documentation. Usually, there's a note that suggests what to use instead.
For example, the documentation for writeWithBackupToFile:ofType:saveOperation: says:
This method is called by action methods to save document contents to a file. (Deprecated in Mac OS X v10.4. Use writeSafelyToURL:ofType:forSaveOperation:error: instead.)
Search the documentation for that method/function/constant. It should list there what to use instead, or at least bring up a class that obviously has other methods that do something similar.

Bizarre VB6 Make Problem - Previously working identical code won't recompile

I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).