Apple assumes that you “speak” Objective-C fluently 
Actually the Objective-C language guide + the class references + the programming guides contain all information you need
the Objective-C language guide + the class references + the programming guides contain all information you need
Hello Stefan,
Thank you for your post, I know that everything is at hand and more than fully documented, I just regret it’s presented more like law articles as colorful advertising Of course I know they are more written for serious “give me code or give me death, I program to make money” programers as for “it’s not my job, I’m doing this after midnight” free-lance amateurs…
That’s why I like this MacScripters so much 
Regards
I think a lot of programmers here program for money that are just willing to help others to let their own knowledge increase too. Well you have to understand in today’s programming that there are two different things. The programming language and the huge amount of libraries you have to understand. Those two are totally different. To learn Objective-C you don’t need to know anything about cocoa, but it makes life easier to work with. To understand cocoa you need to understand Objective-C as well because cocoa is an Objective-C library.
… that’s what I was afraid to read 
I like ASOC because it doesn’t pre-require accurate knowledge of Objective-C (or represent a softer way (for me) to discover Objective-C). I don’t know at which point the guys at FPC have adapted their compiler to XCode 4, but it seems less difficult to learn Objective-C (I only know C++ by name) that to adapt to the different forms of Object(ive) Pascal… but these considerations are personal and out of the scope of this forum.
Thank you guys to spend your time for helping beginners like me!
Regards
Hello Ric, Stefan, DJ, Shane,
I wanted you to know that I followed your suggestions and combined them, so I finally wrote:
set cardLongText to gTextView's RTFDFromRange_({0, gTextView's textStorage()'s |length|()})
tell theEncoder
encodeObject_forKey_(cardLongText, "cardLongText")
finishEncoding()
end tell
someData's writeToFile_atomically_(theFile,true)
which gives me what I wanted from the beginning: I can store a “TextEdit equivalent” (text with embedded images/sounds) into a single file showing the correct icon (set in IB, with no further code), and the serialization provides backward compatibility. That’s really “the more bang for your buck” solution!
Thank you for your patience and your valuable advice!
Regards,
Bernard,
I haven’t used encoders much, so maybe I don’t know all their advantages, but in your project where you are saving one thing, I don’t see the advantage of encoding. In a project like Shane’s People Docs, where you have a well defined interface that you might want to add to or subtract from in the future, I can see how encoding each object separately gives you both backward and forward compatibility. But in your project where you basically have a free form object, a text view, where the user can put anything they want into it, then the various RTFD methods certainly seem to offer the most efficient way to read from and write to them – since the RTFDFromRange already converts (encodes?) the contents of the text view into a data object, I don’t see what you get by then encoding that data object. If you or anyone else can enlighten me on this topic, I’d be grateful.
Ric
Hello Ric,
I must apologize because I’ve shortened the code that I’ve posted. There is much more to come, and saving a text was only for testing.
I’m writing an educational application, which has to be simple to use but will be inversely complex to program. The users (12-14 years old) will define textually some “locations” (a forest, a castle, and so on), and illustrate them with images and sounds. Special fields in the text allow to “travel” from a location to another. Later, objects will be added into these locations, and the user will interact with them. These objects (say, a key) will in turn operate on other objects (a door, for example).
Encoding was my first choice because the document (one for each location) will contain more than just a text: there will be a header defining properties, a second text for a brief description, some messages, a symbolic icon, an ambient sound (music or noise), and maybe more. Encoding is a rather effective way to store entire objects (in a loose sense) without spending time to define a precise, hard-coded (and restrictive) format. You may even store empty keys for future use. The counterpart is that the file boosts in size: that’s four times the size of a RTFD wrapper for the same information. Apple is storing objects in a much better way, I guess…
I could have said all this sooner, but I thought it’s was not relevant at this state of implementation. I hope it makes things a bit clearer. And makes also clearer that I’ll need the help from MacScripters sooner or later!
Regards,
Bernard