Visual Basic: From Visual Forms to Event-Driven Programs

On 20 May 1991, Microsoft announced the Visual Basic programming system, or VB, at Windows World '91 in Atlanta, United States. The press release described it as a graphical application-development system for Windows 3.0, with availability planned for June at a suggested U.S. retail price of $199. Announcement and scheduled availability were separate phases; the May release cannot automatically be treated as evidence that every user already had the product.

The product addressed a practical problem: besides writing business logic, programmers had to create windows, buttons and menus and handle their responses. VB combined interface design with BASIC programming, targeting corporate programmers, software consultants and independent software vendors. Visual tools handled repetitive interface work, while programmers still had to determine what each operation would actually do.

References: [1]

In an oral history archived in 2017, Alan Cooper recalled that accompanying Microsoft sales staff on a visit to Bank of America drew his attention to the need for the same system to serve both experts and ordinary tellers. Rather than designing just one Windows shell, he could supply a building tool with composable parts such as buttons and lists. He called the prototype Ruby, a project codename unrelated to the later programming language of the same name.

Cooper said that after seeing a demonstration in 1988, Gabe Newell arranged for him to show it to Bill Gates; Microsoft subsequently purchased and accepted the technology. Programmers including Michael Geary also participated in Cooper's team. The originally planned shell was not ultimately marketed in that form, and the visual front end was later combined with Microsoft BASIC to create VB. The press release directly confirmed that the forms engine used technology purchased from Cooper Software, providing contemporary corroboration for this recollection.

References: [1] [2]

A form is the working surface on which interface components are placed. Developers drag and drop text boxes, buttons or list boxes, set properties such as position, font and color, and then enter code for events such as clicks or keystrokes. This arrangement connects the interface's appearance with its actions, without requiring developers first to hand-code every part of window creation and the logic linking components.

A hands-on article in the August 1991 issue of BYTE explained that clicking an interface component opened its corresponding code window. Programs could run inside the development environment or be built as Windows executables. The editor also checked syntax, standardized capitalization and provided debugging tools such as single-stepping and breakpoints. Design, programming and observation of results thus became a continuous workflow.

References: [5]

Microsoft technical document Q76559 gives an example applicable to version 1.0: create a new project, place a button and label on Form1, open the code window, and insert Print statements into event procedures such as Form_Click, Command1_Click or Form_Load. This illustrates a minimal program: clicking the button executes the output statement in Command1_Click, while Form_Load handles initialization when the form loads.

Event procedures do not run sequentially merely because they appear earlier in a file; their corresponding actions trigger them. Developers can run the program with F5, step through it with F8 and toggle breakpoints with F9 to see whether the expected behavior occurs. This example illustrates the method without purporting to reproduce a particular launch demonstration: dragging and dropping arranges components, code gives them actions, and debugging checks whether the two connect correctly.

References: [3]

Microsoft technical document Q113329 demonstrates another side through automatic scrolling in a list box. Its example begins by placing labels, a button and a list box on a form and setting properties such as Caption and Visible, then calls the Windows SendMessage interface from an event procedure. By combining graphical settings and system calls in one program, it shows that specialized interactions cannot always be completed by dragging and dropping.

The document also explains the side effects of two implementations. One directs a wider range of mouse actions to the list box, interfering with other operations; the other handles movement only within the box, limiting the scrolling effect. The tool lowered the starting barrier to programming without eliminating design trade-offs. The 1991 announcement also explained that developers could create custom controls in C using the Windows Software Development Kit and extend the VB toolbox through a separately supplied Control Development Kit.

References: [1] [4]

The contemporary BYTE review praised the ease of building Windows interfaces while rejecting the promotional notion that any ordinary user could readily program. BASIC code still had to be written beneath the interface, and users without programming knowledge would struggle to go far. It also noted that generated programs required the appropriate runtime dynamic-link library on the target computer; producing an EXE did not remove dependence on a runtime environment.

These early materials show classic VB's value in organizing visual layout, event procedures, debugging and extensible components into a repeatable development method. It illustrates how programmers could reduce interface chores while retaining responsibility for business logic and unexpected behavior. The mechanisms and examples discussed here are confined to the initial version and technical documents explicitly applicable to it, without projecting later Visual Basic .NET class libraries back into 1991.

References: [5] [3] [4]