VIP-C: A Different Kind of IDE

Program design combining visual and textual programming methods

By Edward Ringel

Why VIP-C?

To answer this question, a little personal history. I have been programming the Macintosh on a part-time and hobbyist basis for about 10 years. I have spent much time and money trying to find the “right tools” so that I could have fun and be productive. I’ve bought and used some great products; I’ve also bought and used some real stinkers. Any programmer who’s been at it for a while will admit to a similar experience. Time and money both wasted and well spent have given me the following perspective:

1. Procedural languages are all the same. Current Macintosh implementations of C, Pascal, FORTRAN, and BASIC are all able to carry out most program-ming tasks.

2. There are good ways of developing libraries of usable, extensible, reusable code that don’t rely on an object-oriented paradigm.

3. Any given object-oriented program-ming system takes a long time to learn. Once learned, that system may be quite productive. However, skills acquired in one system or library are applied only with difficulty to another.

4. Productivity depends upon the complete development environment, rather than only upon the language.

5. A good GUI builder/app framework is worth every penny spent.

6. I want to save time and develop a good product rather than adhere to an ideology of programming technique.

What does this have to do with VIP-C? The death by asphyxiation of my two favorite tools, THINK Pascal for environment and ViewIt for a GUI builder, put me on a several-month expedition to find a replacement. The ground rules for the search: I would be willing to change from Pascal; I would be willing to learn an object-oriented paradigm if it were comprehensible to mortals; I wanted an environment/GUI generator that left me with source code at the completion of development (I was unhappy with the prospect of “shared libs from hell” after the company that made one I was using went out of business and I had several thousand lines of code dependent on unsupported, dated, unalterable products); I would not work with an environment that required me to learn an elaborate series of sub-commands to get simple jobs done.

I chose to work with VIP-C and Metrowerks Gold. Everyone knows about Metrowerks; they do a great job, and nothing else needs to be said. VIP-C, however, was new to me. I have used it for several months and have been impressed with its utility, its ease of use, and the tight integration between the GUI and the actual processing of data. It is not perfect, and it is not for everybody, but it is hard to beat for turning out a finished app without sweating out every last detail. It does this without being object-oriented. It leaves me with source code at the completion of the project. I have ultimately come to view some of the peculiarities in the environment as useful. As of this writing (December 1995) the current release of VIP-C is 1.5.3. I have also used VIP-C 2.0b21 for several weeks as a beta tester. Both releases support 68K and PPC Macs. Version 2.0 of VIP-C (and of its companion product VIP-Basic) are set to debut at MacWorld Expo in San Francisco in January 1996. As such, I have not reviewed features of version 1.5.3 that are not supported in version 2.0, and have not obsessed about problems in version 1.5.3 which have been resolved in version 2.0.

[As this issue went to press, in January, the Mainstay folks were just putting the finish touches on version 2.0, so some facts may be slightly different; but they’ve told us that Ed’s description is substantially correct. - man]

What is it?

VIP-C is not a traditional text-based development environment, nor is it as visually oriented as Prograph. I prefer to think of it as another kind of IDE - an Integrated Design Environment. The product has several cardinal identifying features. It is an interpreted C environment, implementing a robust subset of ANSI C. It has integrated support for an application framework, called “the dispatcher”. It ships with a library of high-level routines that simplify a variety of programming tasks beyond mere GUI management. The environment has a built-in resource editor which performs a variety of tasks similar to ResEdit or Resorcerer, but also has extensions that dramatically simplify GUI management. The text editor has an integrated syntax checker, help system, flow diagram generator, and function palette, which together significantly reduce errors in logic, syntax, and typography. When a project is complete, a stand-alone application can be created around a VIP-C runtime kernel or through source code exported to the compiler of your choice. Commercial-quality applications have been written using this product.

The Project Model

VIP-C uses a project model. When a new project is made, three files are created which contain the resources, code and variables. Resources are stored in a standard format (the file has a ResEdit type); the code and variables are in a proprietary format. This is in sharp distinction to Metrowerks and Symantec, where even a small project can have dozens of associated .c, .h, and other files. Unlike Metrowerks, which offers a variety of project types, VIP-C offers only two options: to use the dispatcher framework or not.

The project window maintains a list of all functions, not files, further emphasizing the differences between a traditional environment and VIP-C. All functions are at “top level” with no equivalent to a function local to a .c file. Functions can be viewed alphabetically or as a diagram showing relationships among dependent functions. [Mainstay are working on a revision where these relationships will be portrayed in a Finder-like manner. - man.] All Macros and Type definitions are also at top level and are global to the project. This is occasionally inconvenient as it can make for long scrolling lists. A list of global variables is also available at this level. A final list available is that of the Resource constants, which is a means of generating and editing resources. These different lists are maintained in “mini-windows”.

Activating a mini-window permits definition of an object or editing of an existing object. Each type of object has its own editor, but there is a uniform editor interface. Both typing and menu-based pickers can be used for creating the definitions. A dyed-in-the-wool C programmer will shudder at the absence of a long list of #defines and declarations at the beginning of the program, but the definition system is easy to learn and very addictive.

Figure 1. The project window contains a list of functions, modification and creation dates, and other information. The small window-like creatures contained within the project window are the mini-windows mentioned in the text.

Functions are defined in a similar fashion. Indirection, parameters and return values are all established in a definition window and added to the main project window. The combination of typing and pickers reduces typographical errors significantly.

Figure 2. The function definition window is representative of the various object definition windows supported by VIP-C.

A Rich, Helpful Editing Environment

Function code is developed in an editor window, and here VIP-C really shines. In addition to the previously mentioned mini-windows, local variables can be defined in their own mini-window. (It is not possible to create local variables with scope limited to a block.) Typing <semi-colon> <return> triggers a syntax check; errors are reported in an error panel and auto-formatting is inhibited if an error is detected. The same key sequence triggers an update of a flow diagram that models the textual data. At first I thought the flow diagram was gimmickry, but selecting a line of code in the text area selects the same “place” in the diagram and vice versa. This feature is very useful in debugging errors of logic.

Figure 3. The text editor shows a function which consists of a switch statement. Mini-windows are at left, and at bottom left are the parameter and local variable mini-windows. The flow diagram and text areas are self-evident. The arrow in the flow diagram corresponds with the downward triangle in the text area. Clicking on the downward triangle brings up the function palette. The “?” at the top of the window activates the help apparatus, and the surrounding panel returns the requested definition.

Typing is reduced by the use of an icon-based palette of functions. Each icon represents a group of functions, which can be organized and edited by the user. Typical C constructs such as if then, switch, etc., can easily be dropped into place. Similarly, variable names can be dropped into statements from the mini-windows by a simple selection process.

VIP-C is aware of the function definitions of the Toolbox, your functions, and several hundred high-level functions supplied with the program that handle a variety of processes: the GUI, string processing, math, complex lists, text editing, networking, to name a few. These functions, if they have been incorporated into the palette, can be chosen from a scrolling list and pasted, without typing, into your code. At the time of this insertion, a small dialog box comes up that allows you to match your variables to the required variable types. This dramatically increases accuracy. If you do need to review a function definition, or any other definition for that matter, there is a help system that can recall information quickly. My only quibble here is that long definitions, such as large structs or functions with many parameters, are not well formatted and are difficult to read when presented in the help panel.

The predefined functions work well alone, in Toolbox-based code, or with the dispatcher routines. The dispatcher is an application framework that takes care of many housekeeping tasks, and includes a number of hooks for your code. For example, a _do_idle() hook is available, so that if you want to do something beyond dispatcher functions during null events (though these are actually quite complete), you simply call your function from this hook. In general, I have found the dispatcher desirable to use, and the documentation has been easy to follow. The tutorial was particularly helpful here.

GUI And Program Are Built Simultaneously

Aside from the editor, the other major advantage of VIP-C derives from the interaction between the dispatcher and the resource editor. Alerts, menus, dialogs and other program elements that interact with the user can be built in the usual fashion. The editors are robust and are better than ResEdit for the universal ('MENU', 'DLOG', etc.) resources supported. This feature does not require great explanation. Extensions to the usual editor functions are the prize feature. If using the dispatcher, you can directly associate routines for update, action, get/set etc., with a menu as a whole, a dialog as a whole, or individual objects within the menu, dialog, alert, etc. If a menu item, for example, is moved within the menu, the routine linkage remains intact. In some respects this is similar to facilities in Visual Architect or MacApp’s view builders, but it is simpler to use, and does not require an intimate knowledge of a class inheritance structure.

At build time, the dispatcher automatically detects these linkages and generates code that assures that when a button is pressed, for example, the action proc routine for that button is called; you are responsible only for writing the action proc, not for creating the code for the linkage. The code for this is quite interesting and depends heavily on C’s facility for working with function pointers.

Resource editors are handled as plug-in libraries, which simplify upgrades, and permit the addition of new editors created either by the user or by Mainstay or a third party. Sample code and instructions for writing the editors are part of the package.

A new resource type and companion editor and set of functions, 'FORM', makes its debut in version 2.0. This feature permits graphic construction of a complex window with “pretty” controls, pictures, color, lists, grids (VIP’s answer to the Table class in object environments), styled text, etc. The interface to the editor is excellent, and there is a full-featured function set for get/set of all types of data, update routines, etc. The functionality is massive, and therefore the learning curve is a bit steeper than the rest of VIP, but the end result is well worth the investment. The FORM type and editor integrate particularly well with VIP’s database manager, and I could see a real value to the simultaneous acquisition of both products if you were planning any kind of database work. Tutorial and reference materials are to be updated to provide complete support for this interface constructor. The database manager itself comes with a construction kit for laying out record types, and this integrates fully with the FORM manager.

Figure 4. The FORM editor shows just a few of the graphic and programming elements that can be placed in a window. The tool palette is at left. Radio 2 radio button is selected, and the window in which this control is defined is at right. The visible layer controls the appearance of the control. The “Events” layer, which is not visible, controls the interaction with the functionality of the program.

Runtime Environment and Debugging

When you are ready to run the project, VIP-C has multiple built-in facilities for runtime and debugging support. Code can be checked function by function or for the whole project. The syntax checker will identify syntax errors and will find any undeclared identifiers. The latter are presented in list form, and you can either find the text used (and fix a typo) or declare the identifier through the appropriate editor. The code is then run via interpreter. Because of the nature of programming the Macintosh and the structure of VIP-C, much of the actual work in a program is not done in the interpreter itself, but in the Toolbox or in VIP-C-specific shared libs or code resources (PPC or 68K respectively) to which the interpreter has passed control. Thus, I have not found the interpreter to be horribly slow, either on a Power Mac (6200CD) or a IIsi. I suspect that complex iterative loops with large n’s might degrade performance, but I have not tested this.

Debugging is similar to other environments. Step and trace commands, breakpoints, and a variable observer window are all supported. There is type-casting support for viewing variables. Complex structures (and their pointers and handles) can be viewed fairly easily.

I have found the debugger to be somewhat fragile. Unstable buggy programs make their neighbors unstable, and I don’t expect the stability of a MacsBug, but TPM and Metrowerks debuggers have held up better to equivalent abuse. The debugger and VIP function and run their programs within a “pseudo-Finder environment” similar to the THINK Pascal environment. Thus, context switches have at times corrupted the appearance of the screen, which is not the case when the debugger, the project manager, and the application are true separate processes. This runtime environment also precludes receiving Apple Events, so if you are planning strong support for Apple Events, this aspect of development must wait for a port to a traditional compiled environment. For large, complex commercial applications, the Apple Events issue may well be the greatest obstacle to using VIP-C, unless you are prepared to do a second round of debugging and testing in the final make environment. Another complaint: VIP-C does not permit setting a breakpoint on a token such as a closing brace, for example, so I have had to add dummy assignment statements at the end of a function if I want to check variables “at exit.”

Despite all this, the dispatcher, the built-in functions, and the up-front syntax checking reduce errors greatly. The flow diagram has been a lifesaver more than once. I have had most of my problems with the usual carelessness and early dementia stuff - allocating and deallocating memory, invalid pointers and handles, etc.; this, of course, will clobber any debugger. I have found myself doing the old tricks of using beeps, Alert() and ParamText() calls, etc., more than I used to; but I do get by adequately.

There are a number of other features in the environment that I have not covered. There are a fair number of user preferences that can be set. Function palettes are easily customized. Flowcharting can be suspended. There are many keyboard shortcuts for common activities. Find/replace text searching is on a par with other development environments.

Putting It All Together
(And Taking It All Apart)

When a project is complete and fully debugged, it can be made into an application in two ways: it can be attached to a runtime kernel, or it can be compiled in a traditional C environment. VIP-C can communicate with the Metrowerks IDE by Apple Events, and can export source code and create a MW project, automatically. Independent C source code can also be generated. It’s worth spending some time with this aspect of the product. Before we do this, however, we need some knowledge of how VIP-C actually runs your program.

VIP-C is designed as a central application that contains the interpreter, the text editing functions, the parser, the resource editor hooks, etc. VIP-C itself ships as two applications, a 68K app and a PPC app. The toolbox interface, the built-in functions, and other extensions to the core product are maintained as fat shared libs (used by both the PPC and 68K). Source code for most of these libraries is provided. When your program executes, VIP-C dispatches a call to a built-in function to the appropriate library, and your code effectively executes that function as a compiled, not interpreted, fragment.

You can add new Apple Managers, third-party function libraries (for example, Mainstay sells a database manager), or your own libraries and attendant definitions. This process is handled differently in 1.5.3 from 2.0. Version 1.5.3’s procedure is quite cumbersome and has happily been changed to a much better system in version 2.0; I will only describe the 2.0 system.

Since the 68K and PPC environments contain their functionality in fat shared libs, to add to the environment you simply drop a new lib into VIP’s folder in the Extensions folder. Each shared lib must have an .h file containing the appropriate prototypes, #defines, enums, and typedefs that define the interface. VIP-C recognizes the presence of a new library and asks for the header file, which is read in once, and that’s it. As for building your own libraries, sample code is provided in the form of the core library source code, and instructions are also available. Existing code that was used as a compiled Metrowerks library, for example, would need to be altered for use in 68K environments because meticulous attention must be paid to maintenance of an A4 world. However, it is fairly easy to see how to do this. (Code resources are easier to convert.) PPC libraries require almost no changes except appropriate recompilation. As an aside, it should be noted that you can import code into a specific project (as opposed to the VIP-C environment) quite easily.

Mainstay recognizes that an application attached to a runtime kernel may be big and clunky, and that most serious development will end in a port to a fully compiled environment. Version 2.0 currently comes with stationery projects for only Metrowerks 6 and 7 (version 1.5.3 supported MPW and Symantec as well). These projects contain libraries which correspond to the core of the VIP shared libraries explained above. Creation of a compiled application requires (1) creating source code files, (2) adding the VIP-C specific libs, (3) adding the resource file(s), and (4) adding the runtime stuff everybody needs.

As might be expected, this can get a little hairy at times. However, VIP-C can communicate with the Metrowerks IDE via Apple Events and do it all for you with really quite minimal intervention. If you wish to use an unsupported environment, or for some reason just want source code, you can generate source code alone. VIP-C-generated source code is simply function after function without organization, generated for direct feed to a compiler, not for a human reader. This is not a big issue if you don’t plan to modify the code any further. However, if you assume that you’ll be tweaking the code in the final make environment, you’ll need to take full advantage of Metrowerks’ function pop-up menus, etc. Project stationery and libraries are available to create applications, code resources, and shared libs. Version 2.0 supports the new Apple API (2.01).

Stand-alone applications can also be created without a compiler. Version 2.0 allows you to choose whether the application-to-be needs the VIP shared libs available or not. This makes sense in that something you give to a friend, or sell, needs to be genuinely stand-alone; programs you write for yourself will by definition have all runtime resources available and can therefore be smaller.

Wish List

A wish list would include an execution environment with the application running as a separate process. This would be much more in keeping with current emphasis on the importance of Apple Events and support of complex debugging environments. I’d like to see better support for Apple Events in the dispatcher, and hooks for preference files in the dispatcher. I’d like to see more robust sample code; many of the samples make the teaching point but no more. Finally, I’d like to see a somewhat more stable debugger, particularly one which could stand up to illegal memory access a bit better. Multiple Observe windows in the debugger would also be nice.

Bottom Line

My concerns and wish list notwithstanding, I think this is a great package for general purpose programming. I don’t think this is the way to write tightly optimized code, games, or VBL tasks; and if you have an uncontrollable urge to micro-manage every aspect of your code, forget it - you won’t do that here. General purpose business applications, scientific applications, graphical applications, and particularly data management applications are VIP’s forte. Networking and serial communications tasks are also nicely supported. This is also a very good environment for the programmer who needs to complete a task rather than create an elaborate application. It’s not that the latter can’t be done, because it can, and well; but VIP most notably offers the opportunity to knock off some quick code and get the job done without reinventing the wheel. Tech support (I’ve used e-mail to their Compuserve address from my internet account) has been prompt, courteous, and has answered my questions satisfactorily. I would purchase this product again without hesitation.