A sincere thanks goes out to Bill for the effort that went into compiling these results.

Note, the ArcView discussion list is a place to post or share your ArcView related problems, questions, discussion. The list has a very good following and is meant for ArcView related disussion only. You can subscribe by emailing to ArcView-subscribe@listbot.com.

Introduction

The original inquiry posted to ArcView@listbot.com contained four specific questions:

• Most of us are self-trained or minimally trained in Avenue itself and are probably proud of that. (Am I correct? Or has everyone taken one of the ESRI courses?) So, of what interest could such a course possibly be? Who would take it? Is it better instead to learn by doing?
• Would it make sense to teach such a course in one block (a five-day segment), over several weekends (one or two days each?), or as a series of three-hour evenings (over seven to 14 weeks)? In other words, what is the best way to learn this stuff--by immersion or in bits and pieces? What is least inconvenient for people who are already working full-time in this profession?
• What topics definitely should form part of such a course? I am fishing for the sore points--the most difficult parts of Avenue, the most treacherous, those most likely to cause bugs, your favorite workarounds, what you use most, etc.
• Periodically people post SUMs of recommended Avenue self-instruction books. Which books, if any, do you think would be suitable for this course?

This document summarizes the contributions of 44 respondents and then concludes with my own reactions. Several interesting ideas spring up along the way:

• If you are teaching an ArcView-related class or are teaching yourself Avenue, the lists of important and problematic topics in the "Topics" section can help keep you focused.
• People are concerned about Avenue’s future. Read their comments in the "Future" section below, then read my optimistic take on the situation in the last section.
• Several people would like to share general-purpose scripts rather than full-blown applications. Their proposals appear in the "Challenges" section. E-mail me if you would like to contribute to this effort.
• Many respondents commented on the ESRI Avenue courses. This document begins with an analysis of those comments because they establish a need for a different course.

Many respondents commented on the ESRI Avenue courses. The consensus is that these courses are "targeted at a wide range of topics," "show the concepts of the language," and teach people just enough "to learn to be comfortable with programming in Avenue." According to one, "the class was really an introduction to the semantics of the Avenue language."

There were complaints. Some concern the course itself. Of those, many are simply darker reflections of the course’s strengths: because it is broad and general rather than deep and specific, it does not teach how to solve problems in Avenue, it does not show "how to make the most effective use of Avenue’s data structures," and it does not provide training specific to people’s work. It is "useful only for minor undertakings such as drawing graphics, changing a line color, etc." and not successful in preparing students "to program for a whole project."

Other complaints concern how the course was taught. At least some of these courses have been taught by non-programmers: "apparently ESRI thought one can teach without doing"; "ESRI employees simply teach a ‘canned’ course."

The remaining complaints concern the students. "The students … fell into two broad categories: those who had already taught themselves most of the material and those who were lost because they had no GIS background. In both cases, the classes were definitely not as useful as everyone involved probably had hoped."

In summary, the existing courses appear to focus on "speaking" the language (the grammar and the object model). Evidently, there is a need for information about creating effective, practical, efficient—even elegant—software projects in Avenue.

The vast majority of respondents agree that "learning by doing is best" and that an Avenue course should be conducted in small discrete segments spread over weeks or months. Almost everyone objected to the immersion approach: it is just too much to learn at once and very little information is retained.

Several people spoke highly of a collaborative approach: one found that "we, the students, could come up with better answers to the professor’s posers than the professor by himself." Many emphasized the need for homework or its equivalent—some form of student-directed hands-on problem solving. "Learning by Fooling Around is far better than being told what to do and what button to press in the given situation."

A few respondents recognized that beginners (in GIS or programming) will have different learning needs than experienced programmers, suggesting that a one- or two-day seminar could meet the needs of the latter.

There were many strong requests to make this a web-based course. This solves the logistical problems and allows people to work the course within their schedules.

The division into basic topics and problem issues is my own.

• Basic programming knowledge: using flow of control constructs (if..then, while, for..each), passing and verifying script arguments.
• Building scripts and simple applications. Approaches to programming in Avenue: "typical workflow," common script elements.
• Objects—"understanding the object model and how to use it in relation to Avenue" (traversing the object hierarchy to get an object, for example)
• Using help. Finding and using example scripts and extensions
• How to handle errors
• "Navigation and management of lists, dictionaries, stacks, and bitmaps"
• Strings: string manipulation, quoted strings, case-insensitive string searches
• Ftabs, Vtabs, and bitmaps [this was specified by many respondents]
• Using table and spatial indexes effectively
• Manipulating graphics within a display
• Creating dialogs
• Using Avenue to build queries
• Using Avenue in the field calculator
• Processing external data
• Creating efficient and "elegant" scripts

• Working with projections
• "The basic GIS operations on points, lines, and polygons," including extracting coordinates, using vectors, and handling graphics within a projected view. Understanding topology.

• "Solving spatial problems, like how do I know if a point lies on the right hand side or the left hand side of a polyline, how do I calculate a median line, how to draw a point at distance x in a direction perpendicular to a given line, just to name a few recent ones."

• Customizing the interface
• Understanding the various document objects: Views, Tables, etc.
• Layouts, especially controlling printing and scale
• Building extensions and ODB objects. Extension preferences.
• Manipulating the Table of Contents
• Object tags (with good examples)
• Using dates and date fields

• Program control—work-arounds for pausing Avenue, for instance
• Effective autolabeling ("ineffective autolabeling is a snap")
• Grids and Spatial Analyst
• SDE
• Getting data from MS Access or Oracle. Using embedded SQL statements. [This is really a Windows issue.]
• Interacting with external programs: DLL, DDE, and ODBC connections.
• Text creation and placement
• Installing and uninstalling extensions effectively
• Understanding and coping with "segmentation violations."
• Sizing and placing dialogs using Avenue (instead of the Dialog Editor)
• Using Avenue in a multi-programmer environment
• "Accessing and selecting symbol lists, palettes, fill types, etc."
• Integrating multi media

Respondents were lukewarm at best about recommending books. Many have not read any Avenue books. Others agree that "none of the books on Avenue I have seen so far qualifies as recommendable." Several suggested compiling a list of appropriate web sites instead.

Nobody strongly recommended a particular book, but two books were mentioned several times. These are

1. Using Avenue by ESRI (the manual that ships with ArcView).
2. Amir Razavi's ArcView/Avenue Developer's Guide (2nd or 3rd Edition)

Other books and websites mentioned include

• Extending ArcView GIS by Ormsby & Alvi
• Avenue Programmer's Reference
• http://www.gator.net/~garyg/aveclass.htm
• ArcView GIS/Avenue Developer's Guide
• 101 ArcView/Avenue Scripts: The Disk (Version 3)
• ArcView GIS Exercise Book
• Inside ArcView GIS

Finally, one commenter suggested "someone ought to write a book like the one called "Effective C++ - 50 Specific Ways to Improve Your Programs and Designs" by Scott Meyers, Addison-Wesley."

Some respondents made comments challenging the premise that an Avenue course is needed or that it could succeed. A few issued some general thought-provoking statements that did not properly belong in the list of topics above. You will find that some of these are contradictory. Here they are.

"What is most frustrating to me is not being sure if the coding techniques being followed make for efficient programs. This doesn't refer to naming conventions; rather the best way to get a fast running program."

"Teaching computer science and software engineering concepts might be a drain on the precious time needed explain the intricacies of Avenue (save maybe bitmaps or stack operations)."

"There is a big lack concerning the work-arounds and unofficial hints how to solve a problem, what problems cannot be solved, etc."

"The question really is, what do you have to offer that is different than ESRI - a tested course? Real-world info, workarounds are good, but what about format? Price? Availability? If you can fill a niche, I say go for it. But make sure the niche is clear."

"I think I might try to teach a general survey with the overarching goal of teaching ‘how to think in this environment.’ "

"The ideal solution would be for ESRI to make an experienced developer available to respond to all questions submitted to ArcView-L." [See my response below.]

"What would be useful is a series of heavily annotated scripts explaining what each line does and why and what each group of lines does and why. Perhaps a collection of scripts (functions) could be made available on the list [periodically]? Users could submit their scripts for use, highlighting any novel approach that is employed."

Along the same lines:

"Maybe it’s a good idea to compile a library of tips and tricks, general programming principles, etc. Many valuable solutions are posted to ArcScripts but I frequently find myself copying and pasting only parts of scripts into my own scripts. The problem with ArcScripts is that most of the scripts posted are problem focused. Not many scripts get posted that can be used [within other scripts using av.Run or aScript.DoIt requests].’ As people tend to use a wide range of coding conventions all the code snippets lack consistency [and are therefore difficult to adapt for general use].

"It would be extremely helpful if a sort of template for function/request-like code fragments would be available. Such a template should define how to pass and verify arguments and how to return appropriate error/return codes.

"I think such a library of functions will be very useful and as many scripts are already available, I think it’s [just] a question of organizing, checking, and transforming them according to the still to be defined coding template."

There is a lot of concern about where Avenue is headed. "Is this all going to be moot anyway? ArcView 4 will not have Avenue. … How is all the legacy work we have going to be ported?" "Is it worth it to expend more time (=money) getting better at Avenue when the language is on the way to becoming obsolete? … What will the new object model (classes, properties, methods, and requests) look like?" "Is it worth it to invest more time/money on that strange Avenue syntax which has several constraints?" "Learning a dead language might be a hard sell."

The comments about the ESRI courses (classroom and web based) establish a need for both a classroom offering and a web offering that are practical, hands-on, and appropriately paced. The class should be spread over time, provide for a great amount of student involvement, collaboration, and homework. If possible it should involve creating real programs in each student’s area of expertise or interest.

I would like to offer a web course, but it could not match my vision of an environment where people learn problem-solving techniques by watching and doing. Furthermore, developing a good web course takes a huge amount of time and effort. At best, maybe some useful supplemental materials will fall out of the planned classroom offering. I will keep you posted.

It is truly amazing that ESRI does not have a person dedicated to responding to questions on ArcView-L. What an opportunity for great customer service—and for generating customer loyalty. Can you hear me banging my head on the table in disbelief that they could blow this chance so badly?

I have described a near-consensus of opinion about course format. However, there is controversy regarding what and how to teach. Some respondents insist that the focus be on learning the details of Avenue—no teaching that awful theory stuff. Others take almost an opposite view.

Take another look at the list of important topics. Fully half of them—probably the most fundamental and most important—have nothing to do with Avenue itself. This is basic material to any programmer, regardless of the language: creating programs. Data structures. Error handling. Several more topics are purely geographical: projections. Manipulating two-dimensional graphical objects. Geometric and topological calculations. (There are other topics, mentioned by no one, whose importance for Avenue programmers is paramount: using operating system resources. The difference between references by name and value. Memory allocation. Algorithmic complexity. How a script interpreter works. How lists are implemented in a pointer-based language. … Avenue can be truly dismaying if you do not understand how these things influence its behavior.)

Lacking a firm foundation in these basics will cause anybody, no matter how clever, to struggle with Avenue. Conversely, having that foundation provides the intellectual wherewithal to identify, understand, and solve the many problems that Avenue poses for the programmer.

This, then, is the gap to be filled, the need that goes unmet: to offer an Avenue-based course that also provides the computer science and geographic analysis foundation on which all GIS scripting (regardless of the language) is built. A course that teaches how to overcome the inevitable limitations in documentation and performance by applying basic software engineering principles to developing GIS scripts.

The value of such an approach lies in its preparation for the future. So what if ArcView’s scripting language changes? If it is merely a change in syntax, then (a) in an afternoon you will teach yourself to write "for i from 0 to n" instead of "for each i in 0..n" and (b) there will be programs that do this rewriting for all your legacy code. If the change includes a change in object model, then life is tougher, but you still will not have to relearn the first half of the topics above. Furthermore, if your legacy code was written by current software engineering standards (very little Avenue code has been so written, I am afraid) then porting it to the new environment will be much less work than a full rewrite. Finally, if the change is truly wholesale—different syntax, different object model, different interface entirely—then we are looking at something that is no longer ArcView. In such a case, I heartily recommend a careful evaluation of the competing software products. Some are full-featured, perform well, and read your data sets. Their only disadvantage in the marketplace arises from your commitment to ArcView. If ArcView were to change a lot, then that disadvantage disappears.

We might not now be able to say what ArcView’s scripting language will look like in the future, but whatever it is, it will always be a medium for manipulating and analyzing geographic and database objects. Thus, to the extent you learn the underlying ideas and learn to abstract your thinking from the limitations of Avenue syntax, you will discover that what you code is long lasting and independent of what ESRI marketing or technical decisions impose on you. Avenue is not dead and the rumors of its impending demise are greatly exaggerated.

—Bill Huber, Quantitative Decisions, Merion Station, PA, 22 November 1999.

mailto:whuber@quantdec.com