Rick's World

Link: https://sourceforge.net/projects/parexplorer

I have officially started my first open source project. It is a program called Par Explorer. What is Par Explorer? The purpose of it is to allow you to open a PAR or PAR2 file and view all the packets stored in it and the contents of each one. All it does is let you view the data. You can't change it or create it.

I wrote this program more as a testbed for learning how to read PAR/PAR2 files. I'm working on a separate application (not open sourced yet), that will do some more processing of PAR files. The purpose of this application is mostly to develop and test the code to read and process PAR files. It also gives me a chance to learn how to write document based Cocoa apps. PAR files make use of some interesting concepts such as MD5 hashes, CRC32 checksums and Reed-Solomon codes. I'd never done any work with these concepts, so this is something else I'm learning during the development of this program. You can freely view the source for the app over in the Subversion repository on the SourceForge project page, so if you are interested in any of these concepts, take a look. MD5, CRC32 and a large amount of PAR2 code is already there, if you need that. Have fun!

I've been learning Cocoa on OS X lately. One of the things I've been experimenting with is document based applications. I've been working on an application that processes Par and Par2 files. So, in the process of developing this application, I needed to write a document based application to view the contents of the files. The problem is, XCode doesn't prompt you for the name of the document class when you tell it to generate a new Document based application. Instead, it generates a document class called 'MyDocument'. This is obviously not a very useful class name. When XCode generates this MyDocument class, it also generates the MyDocument.nib file and connects everything together for you. The problem is, if you try to rename the document, all those connections break and the document and NIB stop working together. Plus, if you want to generate a second document/NIB, you are on your own. I wanted to document how to manually rename a Document class/NIB so that the connections between them continue to work. For this example, I'll use the example of renaming 'MyDocument' to 'ParDocument' (which is what I did in my application). If you want to use a different class name, just substitute your class name for everywhere that I mention 'ParDocument'.

Generate the new Document class

1. In the File menu, select 'New File'.
2. In the Assistant dialog, choose the 'Objective-C NSDocument subclass' item under 'Cocoa'.
3. Give the new class the filename 'ParDocument.m'. Make sure that the 'Also create "ParDocument.h" is checked.
4. If you view the contents of the ParDocument.m file and look at the 'windowNibName' function, you will see that it returns @"ParDocument". This string returned MUST match the filename of the NIB file that goes with this document. In other words, it will try to load 'ParDocument.nib', since you listed 'ParDocument' as the Nib file name. If you rename the class in the future, you also need to change this string to point to the new Nib file. Since we generated the class, this string is already set correctly.

Generate the new NIB file

1. Open Interface Builder by double clicking on the MyDocument.nib file.
2. In Interface Builder's File menu, choose 'New'.
3. In the 'Starting Point' Dialog, choose 'Window' under the 'Cocoa' item.
4. In Interface Builder's File menu, choose Save As.
5. Make sure that you choose the right directory here! Save it to the 'English.lproj' directory underneath your main application directory.
6. If you save it to this directory, it will then prompt you to add the new NIB file to your project. Tell it to add it to your project.
7. From Interface Builder's Classes menu, choose 'Read Files'
8. Select the 'ParDocument.h' file. This is necessary to tell IB about your Document class.
9. In IB, click on the 'File Owner' icon.
10. In the Tools menu, pick Show Inspector.
11. Choose 'Custom Class' from the Inspector's top drop down list. Select ParDocument as the class.
12. In IB, Control-Drag from the 'Files Owner' icon to the 'Window' icon. Set the 'window' connection to this Window.
13. In IB, Control-Drag from the 'Window' icon to the 'File's Owner' icon. Set the 'delegate' connection to ParDocument.
14. Save and exit IB

Set the Document Class for the Document

1. In Xcode, right clock on the Target and select GetInfo
2. Set the 'Class' column of the list on the bottom to ParDocument

That's it! Now that everything is connected for your new ParDocument class, you can go ahead and delete MyDocument.h, MyDocument.m and MyDocument.nib from the project.

It's a long, involved, and very confusing process to do this.  Hopefully this has helped you.

Ok, this truly sucks.

Last night, I was playing with Objective C. I had written an O-C class and tried to include a C++ class as a member variable of the O-C class. Now, you would think this would be possible, since you can create Objective-C++ classes that take advantage of certain C++ features. Apparently, this support of C++ in Objective-C is incomplete at best. I discovered that when I added that C++ class as a member variable, it compiled, but it gave me a warning telling me that the constructor and destructor of that member class would not be called! If the constructor and destructor don't get called, C++ classes are basically useless! What else won't get called on the C++ class in this case? This really sucks. This means that I had to basically rewrite that C++ class as a full Objective-C class in order to use it properly.

This, in my opinion is a glaring hole in the current implementation of Objective-C. It seems inconceivable to me that you can easily include any C code you want, but only certain parts of C++ work in Objective-C. I really hope they fix this in Objective-C 2.0, that is coming Real Soon Now, in Leopard!

Link: https://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_4.html#//apple_ref/doc/uid/TP40002974-CH7-DontLinkElementID_104

A delegate is a kind of 'helper class' in Cocoa. Very often in Cocoa, you won't subclass a class, instead you'll just use the base class and register yourself as a delegate. This means that whenever interesting events happen in the base class, it calls a method on the delegate. The return value of this delegate function allows you to notify the calling class to stop or continue various operations.

Of course, you can create your own classes in Cocoa. This means that there needs to be a way to add support for delegate processing in your custom class. Here are the steps necessary to make this work.

1. Declare the delegate variable and accessor methods in your class' header file. Note that these accessor methods should follow the standard Cocoa Key Value Coding scheme.

   @interface ClassName : NSObject 
   {
       id delegate;
   }
   
   - (void)setDelegate:(id)val;
   - (id)delegate;
   
   @end
   

2. Define the accessor functions in your implementation file.

   @implementation ClassName
   
   - (void)setDelegate:(id)val
   {
       delegate = val;
   }
   
   - (id)delegate
   {
       return delegate;
   }
   
   @end
   

3. Create an informal protocol that contains all the delegate functions that your class will call in the delegate object. This informal protocol is implemented as a Category on the NSObject class. Note that the delegate will work without this step, but if you leave this out, XCode will generate a lot of "warning: no '-XXX' method found" warning messages. Also, your class that acts as the delegate of this class does not have to implement all these delegate functions. It only has to implement the methods that it is interested in. The rest will simply be ignored.

   @interface NSObject (ClassName)
   
   - (void)delegateFunction1;
   - (void)delegateFunction2;
   // etc...
   
   @end
   

4. Before calling a delegate method, make sure the delegate supports that method by using the respondsToSelector: message.

   - (void)someMethod 
   {
       if ( [delegate respondsToSelector:@selector(delegateFunction1:)] ) 
       {
           [delegate delegateFunction1];
       }
   }

Link: https://www.cocoadev.com/index.pl?ExceptionHandling

Here's how to do exceptions in Cocoa... It's nearly identical to C++ exceptions:

@try
{
    // Do some code here that might throw an exception.
}
@catch( NSException* e )
{
    // Log the exception. 
    NSLog( @"Exception: %@, %@", [e name], [e reason] );
}

One important thing to remember when doing these types of exceptions is that it will only work for apps written for OS X 10.3 (Panther) or later. This shouldn't be a problem, though.

Also, in order to get these to work, you need to turn on Objective-C exceptions in the XCode Build settings. The easiest way to do this is to bring up the Project Info dialog box, click on the 'Build' tab, then use the search box in the upper right to search for 'exception'. The last one should say 'Enable Objective-C Exceptions'. Click that item to put a check box in the box, rebuild and you are done.