OCX Technology : Field & Mapping Applications
OCX Technology
What is an OCX?
ActiveX controls are part of the componentware OCX family, designed to run in any
Windows application that is OLE-enabled. There are 3 basic types of controls - Built-in, User
Controls, and ActiveX. ActiveX Controls are independent software components that can be
quickly and easily added to development projects using tools like Visual Basic, C++, Java,
PowerBuilder, etc.. OCX controls can execute events, and give the developer the ability to
code methods, properties and behaviors. Just like built-in Visual Basic controls implement
simple user interfaces and logic, ActiveX controls feature more complex interfaces and
behaviors. They range from the simple, such as the ability to display text, to complex, such as
displaying a mapping file or graphics file and navigating through those maps.
If you have features and behaviors you need to add to your application, look at OCX
technology, it might be just what you’re looking for. All you have to do is install a control
and use it. Close integration of OCX support with popular drag-and-drop design interface
GUI client fronts (like VB5) enables developers to build applications using OCX components
as if they were native controls.
Who should consider using an OCX?
For utilities deploying field crews to maintain facilities and or respond to outages for
restorations, technologies exist today to eliminate the use of paper maps and documents in
the field, thereby providing more efficient field-to-office operations. Deregulation experience
is causing utilities to compete for customers; compete on the basis of cost, quality and
service. In such competitive environments, customers naturally look to the lowest-cost
provider. This means utilities must streamline workflow with technology and heavily weigh
the managed costs (maintenance) for continued development and support
When migrating mission-critical systems from mainframes to client/server 3-tiered
architectures, the use of OCX controls should be considered seriously. Supporters of 3-tiered
architectures want to build and maintain their core business logic functions in only one
standardized set of code within the application server tier. The application server component
can then be used with any one of the client side front end tools. Interfaces become generic,
flexible and scalable to the multiple front-end tools (Tier-1) as well as to Client tier or back
end data stores (Tier-3). This allows the core business logic functions to maintain platform
independence from front-end tools and separates itself from the inherent problems of those
front-end or data store tools.
|
