Did some work on making Icon Mangler more stable (got distracted while I was commenting). Until now it was the icnsEditorClass's job to see if it was out of memory, and to deal with it (by calling delete this). However that was not a very good method, since the linked list was not nto maintained properly, and it was not a good separation between the main program and the class. The best solution would have been to use exceptions, but I don't have the time to learn them properly before the program is due. Instead I added another bit to the status field of the class (which was used to communicate with the main program anyway), outOfMemory. When that us set after the constructor has been called, we assume that the construction failed, and dispose of the editor. In places within the program too, we call this, when making temporary GWorlds and so on. Then in the DoIdle of the main program we check through all the editors if they're out of memory. If they are we dispose of their saved undo states (which can free up quite a bit of memory if the user has been working for a while). If we have already done that, and there still isn't enough memory then we must close the editor. We display an alert, and let the user save if they want to. In order to make sure that there is enough memory to display the error message and the save dialog (even though we are supposedly out of memory), I allocate a chunk in the beginning of the program (for emergencies like this) and dispose of it in order to free up memory, then when I'm done I allocate it again for future use.

So far this is working pretty well, except that the save dialog when using the Navigation Services wants about 100K of temporary memory, and making the emergency chunk that big is kind of a waste. This isn't an issue for the IB, but in the final program I think I can pre-load the Navigation Services library at the beginning of the program, and unload it at the end.

Also, I'm still not checking whether I have enough memory to save the drawing state, so I need to do some work there too.

On another note, I've thought about the future of Icon Mangler (post IB). I want to make it into a decent icon editor. One of the things that is lacking right now is the option to make only certain sizes/depths available. Right now if you add a 48 x 48 icon at a single depth, then when saving all the other depths are saved too, even though they are not used (so they are white). Also, when making a new icon, all the sizes/depths are allocated, even though they are not used. My solution for this (actually this would go in the base icnsClass, but it'll affect Icon Mangler too) is to have an array of pointers to the icon depth/sizes combinations. When the user adds a new size/depth then the respective pointer is allocated, and when saving only the ones that are used are actually saved. Deletion of depths/sizes should be easy too, since it's a simple matter of calling DisposePtr.

For the actual editor, I think I might have a separate editorClass, from which I make a derived class called icnsEditorClass (which also has as its parent the icnsClass, so we have multiple inheritance :p). The editor class would do its drawing actions on a pixmap/gworld called drawingPix/drawingGWorld. Then in the icnsEditorClass its simply a matter of setting the pixmaphandle/gworldptr to the current size/depth. I'm not doing this just because it sounds fancy, but because it could be useful in the future. For example I could make an editor for other graphical resource types too, and then I wouldn't have to rip out the editor out of the icnsEditorClass and replace the icns specific parts with something else (this would also be a headache when adding features). Or conceivably I could spin off the editorClass as a program of its own, to edit simple pictures (or complicated ones, if I get to that level :p).

Finally, I think that I could release the icnsClass (the newer version, not the current one) to the public as a library. Then developers interested in using the new 32 bit icons could use it without having to worry about learning the whole Icon Services API. In addition I already have my own functions for dealing with 32 bit icons under 8.1, so my class would provide compatibility there too (I could use a conditional statement to use the system functions on 8.5+ and my own functions for older systems, for maxium forward compatibility). Of course it would be free, perhaps even open source (although I doubt that I'd get much of a following).