I am using CoreData and the xcdatamodeld editor with great happiness, but when I go to create NSManagedObject subclasses automatically for my entity types, the file placement options seem horribly inflexible.
I have to choose a single folder to place all new files
New files get re-added to the project at the top level (not in any logical groups)
I have my groups & folders set up to mirror each other, additionally I keep separate groups within my "models" folder for each NSManagedObject subclass (because CoreData creates 2 files for each and it just gets cluttered otherwise).
Problem 1 means that in this situation, I have to generate the files 1 at a time, choosing each subfolder manually. Problem 2 is just an added layer of convenience that I feel like should be avoidable.
It seems like it would be sensible for an option to "overwrite any such existing files in place, wherever they are located & whatever groups they may be in" -- so sensible, in fact, I may just be overlooking the command. Any thoughts?
No, you're not overlooking any command. Xcode has a different idea of how to organize things than you do. For problem 1, that's just how it is. Xcode won't attempt to locate existing files in your project when re-generating them. Maybe it should, but that's not how it's designed right now.
Related
I have several lines of code of a written class with Interface written in testclass.h and implementation written in testclass.m in Xcode. I wish when I update an entry in testclass.m, its counterpart in testclass.h can be updated automatically.
For example, I have an interface for following function in both testclass.h and testclass.m:
-(void)testfunction
And I modified its name to a different one due to some reason in testclass.m to:
-(void)another_test_function
If I want this code to run I need to manually change the entry in the header. Although I'm very new to programming but I can imagine it could be really frustrating if you are trying to modify something in a big program with a lot of different files invoking some modified entry name. I wish Xcode can auto-detect this change and modify the entry in the header file to -(void)another_test_function automatically.
Is there any way I can do that? All I know by searching the internet is that you can use a shortcut to "edit all in scope" but this only affect all the occurrence in the same file, not header file.
Right-click the method name you would like to change (in either the header or the implementation file) and then select Refactor > Rename. You can then change the name of the method, and Xcode will show you what it will change.
If that looks good, you can accept the changes and you're done.
I am working on a Cocoa project (first one so I'm still learning) and I need to get a list of all directories at "x" location that also have a directory named "y" within them. I then need to populate a drop down box with the names of the "x" directories that have the "y" folder inside them. I will be using the drop down box selection to create and name a new directory later on.
I have looked into doing this with multiple different scripting languages but I have yet to find anything that works. I have also searched for a way to do this purely with Objective C, but the only thing I can find is ways to work with files, not directories. I am open to any way to do this, but being so new to Objective C and Cocoa in general, a simple way would be preferred.
If anything is unclear, just let me know and I'll do my best to clarify.
On TextMate 2 and opening two files in two different locations such as /path/1/file.txt and /path/2/file.txt, I am no longer seeing a way to perform diffs as before since one cannot select files in the project "drawer." We now have a file browser that seems to have taken its place and thus no way to pick the two opposing files. This also precludes any other command that requires multi file selection that are not within the file structure.
Am I missing something that would allow this to work properly when dealing with files in two different paths?
This isn't a new trick. It's one we learned when grep in project would go insane when you had a project with files whose common ancestor was root or some directory far above the files. Instead of opening your files like:
mate /foo/bar/baz /quix/quacks/quux
You do the following, assuming you're in an empty directory or don't care that its files will be included in the project as well
ln /foo/bar/baz /quix/quacks/quux . && mate .
That can obviously be wrapped up into a function to reduce the syntactical difference. In fact, at one point, I actually wrote a wrapper script around mate to do that transparently when needed AND clean up the hard linked files after I closed the project or quit TextMate. That went away with some bad hard drive though.
Anyhow I HTH
I am working on a module that supplies methods for navigating directories and manipulating files. Basically it will be a combination of the Dir and File classes, with options specific to the needs of a project I'm working on.
Right now I have started writing tests for some of these methods and things are getting messy.
Example
One of the methods I have is a tree function that returns a hash of files and folders where you can pass options like tree(only: 'folders', limit: 3). In order to test that it only goes down 3 levels, I would have to have 4+ subfolders with dummy files in them.
The Problem
Right now I'm testing on folders outside the project since the subfolders are already there, but I want to move away from this, especially considering the implausibility of testing on system files once I start testing methods equivalent to rm -rf (as well as the lack of portability).
I'm starting to think that I need to create a "lab rat" type folder that I do all my "experiments" on, but I have no clue how to approach creating it.
Do I create a function that creates the files?
Do I pull files and folders from another location?
Do I use some sort of "lorem ipsum" generator for file structures?
Do I make all these files and folders manually(ugh)?
Do I just mock and stub the hell out of everything and not actually create/delete the files and folders?(I don't see this happening)
So...
How would someone normally approach testing excessive amounts of file and folder manipulation?
I don't think you want to use mocks/stubs. The file system of your OS should be well tested and fast, so the benefit of mocks/stubs is minimal. Creating a mock/stub system increases the complexity without much benefit.
Here's my answers:
Do I create a function that creates the files?
Yes. You can create tests for these functions to make sure that they are correct. Instead of calling Dir and File, write helper functions that make the code simple and readable. Maybe you can share the helper functions between the source/test code...
Do I pull files and folders from another location?
Not sure what this is for...
Do I use some sort of "lorem ipsum" generator for file structures?
Yes, if you mean create functions that generate file structures.
Do I make all these files and folders manually(ugh)?
No.
Do I just mock and stub the hell out of everything and not actually create/delete the files and folders?(I don't see this happening)
No. One benefit of creating files/directories is that you can manually check what is going on and not be 100% dependent on the tests. This is actually a good approach because without it there could be a bug where both the source code and test code is not doing what you expect, but you wouldn't know because everything seems to be working.
I want to rename about 100 classes in my Xcode project. It would be painful to change every filename, then do a search and replace on the name of each class in question.
Is there a better way?
The change in question involves changing a prefix -- think of what Apple would need to do if they decided to rename all the classes in their "NS" framework to start with "MS". Unfortunately, the two caps in question do start some words in the project which are not among the class names in question.
If your version of Xcode is reasonably up-to-date, you can right-click on the symbol name in the editor and choose "Refactor..." which will take care of both renaming files and renaming symbols (with the appropriate checkbox enabled).
If you don't have C++, Shaggy's answer will probably work for you. But in my case, the answer appears to be that there is no better way.