ArcView is relatively new to most GIS users and application developers. As users and developers work with ArcView, specifically Avenue, to build single script tools or complex multiple script applications, the need and desire to integrate and leverage existing ArcView tools and applications increases. To maximize the reuse of Avenue script, an application framework should be used during script development. With this framework in place, user and developer will avoid, to a certain extent, problems when integrating tools and applications. The purpose of this paper is to outline an application framework designed to support the integration of applications specifically within the ArcView development environment. the goal of this framework is to enable developers to create a single project file that provides the "hooks" to incorporate additional tools and applications as they are developed. This paper will discuss methods for building an ArcView application and will focus on issues such as the development environment, application infrastructure, and graphical User Interface (GUI) management.
The effectiveness and efficiency of software development can be greatly increased by writing modularized code using informal (styles) and formal (standards) work approaches. Software development is about connecting pieces into a coherent whole. Thus consistent work approaches (while evolving and even arbitrary) provide a structure that allows individuals and teams to minimize the time and thought that they devote to making these connections. These investments in structure return even more benefits in the maintenance phase when old code has to be examined by new programmers (or even the same authors after time has passed). While this philosophy is widely advocated in the software engineering community, what does it mean for the Avenue developer? We present some examples of coding style for Avenue. These include Hungarian notation (notationHungarian, stringCustomerName, etc.), script naming prefixes and suffixes, and several options in script headers. We demonstrate several modular, object-like utility scripts that can be used alone or combined into other utilities. These include developer tools such as a 'System.Echo' substitute for Windows 3.x, a Dictionary inspector, a window packer/tiler, and tools for detecting and dealing with multiple display resolutions. We will also present some ideas on utility maintenance and version control through the Object Data Base (ODB) and mechanisms such as the World Wide Web.
Since ArcView 2 was released, users and developers have required greater functionality and the ability to perform more complex operations. However, this has meant that ArcView and Avenue are pushed closer to their limits, with subsequent problems in reliability and performance. This paper explores, from a practical standpoint, the problems involved in developing large, sophisticated ArcView 2 applications that are designed to work on a variety of hardware platforms with constantly changing data sets, and user requirements. It will specifically address:
Customising ArcView Projects using Rapid Application Development Tools. When integrating GIS in modern information stems, ArcView's built-in user interface tools may prove inadequate. Over the last few years Rapid Application Development (RAD) tools for the MS-Windows platform have matured and become widespread. Hence it seems natural to combine the two. This paper focuses on the development of an advanced user dialogue for an ArcView Project. Techniques for controlling ArcView are described, as well as comprehensive ways of structuring the project. An example using DDE with Visual Basic is presented.