Simon, First of, thank you for all those links and explanation. Very much appreciated. Now, more below.
On Tue, Oct 22, 2013 at 3:48 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > On 22 Oct 2013, at 7:37pm, Igor Korot <ikoro...@gmail.com> wrote: > > > On Tue, Oct 22, 2013 at 2:29 AM, Simon Slavin <slav...@bigfraud.org> > wrote: > > > >> On 22 Oct 2013, at 9:17am, Igor Korot <ikoro...@gmail.com> wrote: > >> > >>> Now I am trying to add the "sqlite3.c" but I couldn't. > >>> Going to "File"->"Add Files to,,," I see only my .cpp, .h and sqlite3.h > >>> files. I don't see sqlite3.c file in the "Add File" dialog. > >>> > >>> Is there any setting I need to turn in order to be able to do so? > >> > >> Drag your .c and .h files directly from the Finder into some part of the > >> project structure window on the left of the Xcode layout. There's > usually > >> a section called something like 'Other source' or something like that, > >> though theoretically they can go anywhere. > > > > OK. That's easy. > > > >> Once you've done that, look at the properties for those files and make > >> sure that Xcode knows that the .c file is C, not C++. > > > > And this is not. ;-) > > How do I check the properties of this file? Right click on it? > > Did you try right-clicking on it ? Or left-clicking on it ? > > > And what do > > I check? > > I am very new to XCode, so I need to get this from very basic. > > Click on it to select it, then look at the right-most pane on the window > (you should have three: left, middle and right) and try to understand > everything you see there. Click on the popups, see what the alternatives > are and try to pick the right one. For these files you're actually looking > for a popup that says 'Type' and you want it to mention C, not C++. > OK, that was easy. I checked and it looks like XCode successfully deduced that the file is C. > > Xcode is extremely complicated. Possibly too complicated. It's far too > big for me to explain it here. But you are definitely going to have to > learn how to do these things in order to do any good at all. Take a look > at the documentation for 'Navigation area' in > Yes, it is complicated. I think it even more complicated than KDevelop/Anjuta/MSVS. But that is OK. I now have a lot of links to documentation so that I will have an armor in the very near future. ;-) > > < > https://developer.apple.com/library/mac/recipes/xcode_help-general/_index.html > > > > If you are new to Xcode t may be worth going through an Xcode tutorial like > > < > https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMapOSX/books/RM_YourFirstApp_Mac/Articles/GettingStarted.html > > > > which will at least teach you what the various parts of the GUI are for > and give you a hint where to look for things. > > > Well, I did it this way to put the icon file in and though assumed that > the > > process will work for SQLite DB file. Guess I was wrong. > > And here again - how do I check that this file is marked? Where to go and > > what to look for? > > Again, find the database in the navigation area and see what its > properties are. You need to check that 'Target Membership' is ticked for > the application you're building. > I dropped the .db file in the leftmost panel where the source code is, selected it and then looked at the right panel. There is a pane called "Target Membership" and my application is checked. > > >> From the way you asked the question I assume that your application will > >> only need to read from that database, not change it. That's fine. OS X > >> may be a little alarmed at an application which tries to change the > >> contents of its own bundle. > > > > If you mean "change the structure of the tables" - yes. The DB is created > > and the tables will not be changed. > > No, I include changing the contents of the tables too. Anything that > edits the file. And you would seem to have a problem: if your application > is stored in the normal place, and a non-administration user runs it, it > cannot edit itself. You'll get an error message of some kind. > > Including a file in your application and allowing users to change the > contents of that file will not work for most Mac users in most situations. > First, only Administration account users have enough privileges to change > applications in /Applications, and most users should only be using > Administration privileges for doing Administration tasks. Second, having > an application edit applications (even itself !) is the typical behaviour > of a virus and parts of the operating system will conspire to prevent it > and alarm the user. It is because of precautions like this that viruses > are not a problem for Mac users. > > So how do you do what you want to do ? Well, you store a 'starter' copy > of the database in your application. Which is exactly what you're doing > already. But instead of having your application try to edit that one it > should being trying to find a copy of it in the folder > > ~/Library/Application Support/Appname > Well, this is what it will do. Presumably for clarification I would call it "Application Data" directory/folder. Now one last question hopefully. Where XCode will store the db file inside the bundle? Is there a specific place or it will go where the executable will be put? > > If one doesn't exist, it should make one but copying the 'starter' one out > of its own bundle. Then it should open that copy. That way, each of your > users will have their own copy of the data and you can have many users on > one Mac without worrying that they will interfere with one-another. > > Read this, about what I wrote above: > > < > https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40010672-CH1-SW1 > > > > You want the section > > Accessing Files and Directories > Locating Items in the File System > Locating Items in the Standard Directories > > and you should probably end up using the 'URLsForDirectory:inDomains:' > function, like listing 2-1 on that page. > > And lastly: All this is very complicated. Sorry. But doing things this > way makes sure your app behaves in the standard OS X way, isn't subject to > viruses, and acts exactly the way Mac users expect apps to behavie. > Yes, this is my ultimate goal. And sorry for such trouble. I am very-very new on the Mac side and all this Carbon/Cocoa/Xcode stuff is very new to me. So thank you for taking such a huge amount of time for explaining all this and putting it all together for me here. > Simon. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
