Other than Chapters 21 and 22, this book has focused on the OpenGL API from the standpoint of a C program. No consideration of Windows programming is complete, however, without a discussion of the many 4GLs and other visual environments popular today. In this chapter we will briefly discuss the requirements of using the OpenGL API from some of these environments. In addition, we will demonstrate an OpenGL OCX (OLE custom control) that is included with this book for two widely used Win32 development environments: Microsoft’s Visual Basic 4.0 and Borland’s Delphi 2.0.
For the purposes of this chapter we will assume you have a working knowledge of your particular environment (Visual Basic or Delphi), and how to use and call OCX methods. Even if you have no experience with OCX controls, you may be surprised by how easy they are to use.
Any Windows development language or environment can make use of OpenGL, provided it supports low-level access to the Win32 API and other libraries contained in DLLs. Most environments and tools allow this in order that applications can be integrated with other libraries, or simply so that the developer can take advantage of new operating systems features introduced after the tool is released.
The entire OpenGL API is contained in two DLLs: opengl32.dll and glu32.dll. Just as most Win32 APIs are accessed directly from DLLs, such as user32.dll, gdi32.dll, and others, you can also get to OpenGL functions and commands from a high-level language environment. Each tool and environment takes a different approach to accessing functions in external DLLs. Usually, you need to specify the function name, its arguments, return type, and in which DLL file the function is contained.
There are two disadvantages to using these methods for using OpenGL from one of the aforementioned environments. First, it is extremely tedious! Every OpenGL function needs to be defined and exported for a given environment. In addition, the argument and return types must be mapped to the native data types of the particular environment. Not only the functions must be defined, but so must all those state variables and flags (GL_ACCUM, GL_LOAD, and on and on) from the header files. This is further compounded by the fact that you must do it for each and every environment that would make use of OpenGL!
The second disadvantage is the requirement of Win32 that OpenGL-enabled windows have the Windows styles WS_CLIPCHILDREN and WS_CLIPSIBLINGS set. Some of these environments make it very difficult to get to any low-level window styles unless they’re on a proprietary check box somewhere. The worst case is that you may even have to export CreateWindow from Windows itself and call it from within your program.
If you’re going through all this trouble to use OpenGL from say, Visual Basic, you might just as well write a DLL in C that does all your OpenGL rendering, and then call into it from your high-level environment. This answer, though it’s probably the most optimal in terms of performance, is something of a cop-out that leaves non-C/C++ programmers out of the picture.
But if you bought this book to learn about OpenGL, and you have been able to follow the samples and function definitions, there is still hope!
The term object oriented is perhaps, along with client/server, one of the most abused and misused buzzwords of the 1990s. We want to avoid a serious debate on this issue, but we think one important new technology holds significant promise for code reuse.
That technology is OLE (Object Linking and Embedding)—or, more importantly for this chapter, the OCX (OLE Custom Control). When Microsoft introduced Visual Basic and made development of custom controls possible through VBXs, a new industry was born almost overnight. New companies and fortunes were made supplying Visual Basic developers with new and interesting widgets. Soon competing environments (PowerBuilder, Delphi, and others) allowed VBXs to be used for their applications. This further fueled the fire of component reuse.
These so-called plug-and-play software components revolutionized application development for 16-bit Windows. The successor to VBXs was the OCX, which makes use of OLE automation to create a framework for highly portable and reusable software modules. Microsoft has of late made OCX development possible for 16-bit Windows, but the original target was the new generation of 32-bit Windows operating systems.
By packaging your code into an OCX, it can be used by any environment that supports OCXs. This includes MFC-based C++ applications, as well as Visual Basic 4.0, Borland’s Delphi 2.0, PowerBuilder, and others. Furthermore, no special consideration is necessary for the host environment. You just register the OCX with the operating system, and all its methods are available. Code that interfaces with the OCX will, naturally, be dependent on the syntax of the environment, but the control itself is merely “installed” into your environment and is ready for use.
By wrapping the OpenGL API with an OCX control, we have effectively solved both disadvantages of using OpenGL from a high-level visual language. Now all the functions are defined for us, and we even have a window readily available to do our drawing! Moreover, now we can use OpenGL from any environment that supports OCX controls!
There is one caveat: The OpenGL functions that require callbacks such as those used for NURBS and polygon tessellation cannot be supported here in a manner that would work with all environments. Many environments are not even compiled but rather are interpreted, and passing a pointer to a function is just not possible. The exception may be environments that produce true compiled code that is compatible with the C calling conventions (such as Delphi).
See the document for your environment for details on accessing external functions, as well as supplying C-callable routines from within the host environment.