CompuServe Messages

Charles, I would like to create a compiler for Helm applications that would include only the necessary functions in the executable. Someday I will certainly create such a compiler. However, I'm busy at the moment creating a cross platform version of Helm and I expect it to take most of my time for the next year. I do plan to move a lot of Helm into runtime libraries and this will accomplish a lot of what you have in mind. You shouldn't get the idea that I'm embarrassed by the sizes of Helm and the browsers. There is a lot of stuff in Helm and it is more than just a program that creates applications. It is like HyperCard and Toolbook because it is also a flat file database manager where the the data is stored inside of the application itself. If the user types into a textfield, Helm will update the book/application file as necessary. There is also a music player, sound player, PostScript printing, reports, hypertext, and visual effects. It has the largest variety of built-in objects of any authoring system that I've seen. And the integrated paint program is a lot more than a few touch-up tools. Helm 2 will even have communcications features with support for the XPR libraries. If you compare Helm to other applications of this scale, I think you will discover that it is quite small. There are better tools for creating small utilities but for more ambitious projects with lots of data and interactivity, Helm is a good choice. A Helm book consists of one or more pages. Helm automatically loads and unloads each page (and its objects, scripts, actions, and images) from disk into memory as the user moves from page to page. This means you don't have to worry about loading and unloading resources into memory because Helm takes care of it automatically. For a book with a lot of pages, most of the application remains on disk until needed. Also, Helm now shuffles images in and out of fast memory to help lighten the burden on chip memory. I think the the execution speed is pretty good. I have done a lot of things to make page rendering more efficient. For instance, each page is associated with a form. A form can include any of Helm's objects and is used to create a background for multiple pages. If the user moves to another page that uses the same form, Helm analyzes the display and only renders the pieces of the screen that need rendering. You can have Helm do the same thing if you change the properties of one or more objects from the script language. By locking and subsequently unlocking the output, Helm will update only the necessary parts of the page. I'll start uploading some examples soon so you can get a better idea of Helm's capabilities. Jerrell Nickerson Eagle Tree Software