Access ELF Documentation Access ELF Tutorials Access ELF On-Line Help Access ELF Downloadable Help File Access ELF FAQ VB ELF Documentation VB ELF Tutorials VB ELF On-Line Help VB ELF Downloadable Help File VB ELF FAQ
Configuration & Licensing Options
Critical Opinions
Our Users Talk Back


Please sign our guestbook!





VB ELF Developer's Document, Version 2.1


This is the Version 2.1 release of VB ELF (November 1999)

[ v2.1 is a minor upgrade to the September 1999 v2.0 release.
Much of the documentation will refer to v2.0 as the current version. ]

Welcome to the world of ELF Natural Language Querying! Before we dive into the technical considerations, just a few words to suggest why you should spend the time to familiarize yourself with the ELF (English Language Frontend) system. Have you ever seen a computer system that lets you type: "Graph the low, high and close for Microsoft's stock on December 25th of each year." -- then goes ahead and does it? ELF can. It can also generate the highly complex SQL needed to answer such queries as "Which of our customers have ordered more than the average number of products?" or "Which albums are available in both cassette and CD formats?" In other words, no matter what your data looks like, there's a good chance that ELF will handle the kinds of queries that you -- and your end users -- need answered every day.

VB ELF Installation, Compilation and Integration

Note: VB ELF is a 32-bit program. It will not run on any Windows system earlier than Windows 95.

Legal Requirements of Use

You may NOT reverse-engineer or in any other way gain access to, or modify the source or executable code of the file ACCELF.DLL. You may not directly call the functions supported by ACCELF.DLL except from VBELF32.EXE and/or VBELFOLE.EXE.

VB ELF is a royalty-free product as long as it is being incorporated into distributable executable files. ELF Software reserves the right to license VB ELF independently as an Internet/Intranet server-based program. For the use of VB ELF on ASP-enabled servers, we require an additional one-time per-server-machine license charge.

VB ELF (Version 2.0) Stand-alone Program

VB ELF is targeted at developers, so we're not going to waste your time explaining how to launch a self-installing program or how to find our Program Group from the Explorer. To get a thorough understanding of our product and how it can be used, integrated and distributed with your own database projects, you're going to have to cover a lot of ground. So let's get started.

Overview

There are 4 components that make up the VB ELF stand-alone program. They are VBELF32.EXE, VBELF.MDA, ACCELF.DLL and ELFCLIB.DLL Normally, a new directory is created for use by VB ELF, for instance, a C:\Program Files\VBELF directory. VBELF32.EXE and VBELF.MDA should be placed in this directory, and both ACCELF.DLL and ELFCLIB.DLL should be placed in the Windows\System directory. The Windows system directory is usually C:\WINDOWS\SYSTEM, or on NT machines, C:\WINDOWS\SYSTEM32.

Like all other Windows programs, VB ELF relies on system components; and like most others, it relies on some third-party components. Because you can’t in general be sure what components are already installed on a computer, automated installation procedures like the one we use (from Wise) are recommended. For instance, we use the Dbgrid32.ocx from Pinnacle, and Microsoft’s Mschart.ocx control. We also rely on Microsoft Jet. If you are integrating VB ELF into a project which you distribute, you’ll need to make sure that all the pieces are in place. This section reviews the components which are required by our system.

Required Components

VB ELF 2.0 is being released as Visual Basic 6 source code only. Because Version 2.0 takes advantage of many of the new features of Visual Basic 6, it can only be recompiled and modified by developers with access to VB6. However, it can of course be used, as shipped, without recompilation or modification.

VB ELF also utilizes a number of controls supplied both by Microsoft and third-party providers. Each one of these tools is bundled with VB6 and available on the VB6 (or Visual Studio) CD. In some cases, because Microsoft is trying to promote the use of its own controls rather than these third-party controls, it has "hidden" them in directories where they must be manually installed. The following section describes the location of all the controls in use by VB ELF 2.0. Note that some of these controls have "Design-Time Licenses" and you must install by incorporating the .REG information accompanying the controls into your system using REGEDIT (Merge).

The controls in use are:

DBGrid32.ocx
Source: CD #1 of Visual Studio 6.0 OS\SYSTEM
Datetime stamp: 6/26/98 10:30 PM
Maker: Apex Software Corporation
Version 5.01.8104
============================================================
Mschart.ocx
Source: VB5 Professional CD OS\SYSTEM
Datetime stamp: 1/16/97 9:11 AM
Maker: Microsoft

We have not updated to the newer version of MSChart available from CD #1 of Visual Studio 6.0 OS\SYSTEM (Datetime stamp: 6/26/98 2:16 PM), however this should not cause any conflicts with existing systems because the newer version has been renamed to Mschrt20.ocx. ============================================================
Grid32.ocx
Source: CD #2 of Visual Studio 6.0 COMMON\TOOLS\VB\CONTROLS
Datetime stamp: 6/26/98 8:22 PM
Maker: Microsoft
============================================================
Msadodc.ocx
Source: CD #1 of Visual Studio 6.0 OS\SYSTEM
Datetime stamp: 6/24/98 10:55 AM
Maker: Microsoft
============================================================
Msdatgrd.ocx
Source: CD #1 of Visual Studio 6.0 OS\SYSTEM
Datetime stamp: 6/24/98 10:56 AM
Maker: Microsoft
============================================================
Comdlg32.ocx
Source: CD #1 of Visual Studio 6.0 OS\SYSTEM
Datetime stamp: 6/24/98 10:55 AM
Maker: Microsoft
============================================================
Comctl32.ocx
Source: CD #1 of Visual Studio 6.0 OS\SYSTEM
Datetime stamp: 6/24/98 10:55 AM
Maker: Microsoft
============================================================
Finally, the complicated case:

Graph32.ocx
Source: CD #2 of Visual Studio 6.0 COMMON\TOOLS\VB\CONTROLS
Datetime stamp: 6/26/98 8:22 PM
Maker: Pinnacle-BPS (now known as Pinnacle Webworkz)

Support Files: Gsw32.exe, Gswdll32.dll, Gswag32.dll
All Datetime stamped: 10/22/97 5:10 AM
Source: Acquired from Pinnacle

We do not use the Gswdll32.dll support file distributed along with graph32.ocx on VB6 CD #2, because it locks our systems!

The Graphics Server documentation states that Gswag32.dll (as well as the other two files) are required by any app using the Graph control; however, it was not even distributed on the VB5 CD or anywhere in the Visual Studio distribution. We know of only one case (under Win NT) when this file appeared necessary; we're including it for thoroughness. ============================================================
VB ELF depends on the Microsoft Data Access Components. You must ensure that MDAC 2.1 or later is pre-installed on any machine that will be running VB ELF. MDAC 2.1 will be available from the same location as the VB ELF download, and is always available from Microsoft. ============================================================

VB ELF also requires the Visual Basic runtime files and the Microsoft Jet redistributable files. It is assumed that if you have the tools to compile these projects under Visual Basic 5.0 (or 6.0) that you have the legal right to redistribute these files from Microsoft.

You should also be sure when distributing such system files that your installer does not overwrite any newer versions of the components.

These are the system files required: Asycfilt.dll, Comcat.dll, COMDLG32.DLL, ComDlg32.ocx, Ctl3d95.dll, Ctl3dnt.dll, DAO360.DLL, MSBIND.DLL, Msjet35.dll, Msjint35.dll, Msjter35.dll, Msrd2x35.dll, Msrepl35.dll, msvbvm60.dll, Msvcrt40.dll, OLEAUT32.DLL, Olepro32.dll, Stdole2.tlb, Vb5db.dll, Vbajet32.dll

Note that we've continued to include many of the Jet 3.5 system files, despite the fact that VB ELF uses the newer Jet 4.0 technology. This is simply because Microsoft often changes version numbers on only some of the required files (eg, VB5DB.DLL, which is still required under VB6) so we'd rather be safe than sorry. It appears that Jet3.5 object declarations are also required, so you should also include these files in any distribution.

============================================================

The VBELF.HLP file should also be placed in the VB ELF application directory, although it is not strictly required. Note that version 2.0 continues the system we introduced earlier, in which Help is available both as a local .HLP file and via context-sensitive direction to our Web site. At the time of shipping, the local help file will be the more up-to-date. As we continue to receive feedback and make changes, the Web version will contain the latest information.

You can always download the latest version of our help files from the Downloadable Help section of our Web site (http://www.elfsoft.com/Help/Vbelf/Overview.htm).

DEVELOPER'S VERSION:

Compiling VB ELF under Visual Basic 6.0
If you have the Developer's version, you may have received the source only as part of a download package. You can create VB ELF, the stand-alone as well as the OLE server and OCX versions, by compiling our code.

Naturally you like to compile the source, to verify that you have complete control over customization of the project in the future. It is important to understand before you begin compilation though that our distributed executables are all synchronized with the No Compatibility setting. This means that the VBELF OLE demos and OCX controls all depend on the specific compilation of VBELFOLE distributed with the .OCX and sample .EXE files. You can recompile VBELF32 all day long with no consequences. But if you recompile VBELFOLE on a machine, it will re-register that compilation of VBELFOLE as the "authorized" ActiveX server. The OLE_DEMO will no longer run until you recompile it as outlined below, fixing up its reference to VBELFOLE. The OCXs will similarly be out-of-sync, until recompiled, and of course the demos that use the OCXs will also be temporarily out of order.

This is a matter of personal preference, but we've found that setting Binary or Project Compatibility on ActiveX components can mask problems until long past the last minute -- like when your software has already been installed on a client's machine.

If you want to avoid all these compilation worries, just use the synchronized versions of the components and OLE Server which come on the VB ELF CD-ROM, and skip recompiling our code entirely.

Stand-alone version:
To create VB ELF (stand-alone), open the project Vbelf32.vbp using Visual Basic 6.0. You should be able to compile the project, creating VBELF32.EXE, by selecting Make EXE file… from the File pull-down menu. This project compiles in under 5 minutes on a 200 MHz NT Server machine and produces a file about 5096 KB.

Troubleshooting checklist.
In case the compilation does not go smoothly, here are some things to check. Project/Components/Tools tab. You should have the following eight (8) Custom Controls installed:
1) Microsoft ADO Data Control 6.0 (OLEDB) (MSADODC.OCX)
2) Microsoft Chart Control (MSCHART.OCX)
3) Microsoft Common Dialog Control 6.0 (COMDLG32.OCX)
4) Microsoft Data Bound Grid Control (DBGRID32.OCX)
5) Microsoft Data Grid Control 6.0 (OLEDB) (MSDATGRD.OCX)
6) Microsoft Grid Control (GRID32.OCX)
7) Microsoft Windows Common Controls 5.0 (SP2) (COMCTL32.OCX)
8) Pinnacle-BPS Graph Control (GRAPH32.OCX)

If you don’t have these controls, the compilation will not be successful. You will need to install the missing controls. Please see the Components section at the very top for the location of these installable controls on the Visual Basic 6.0 CD (or Visual Studio 6.0 CD set). You will need to follow the installation instructions for adding these controls to your toolkit, for instance by copying the files onto your system and importing the registry information using RegEdit.

You should also have (at least) the following References:
1) Visual Basic for Applications (MSVBVM60.DLL)
2) Visual Basic runtime objects and procedures (MSVBVM60.DLL\3)
3) Visual Basic objects and procedures (VB6.OLB)
4) OLE Automation (STDOLE2.TLB)
5) Microsoft DAO 3.6 Object Library (DAO360.DLL)
6) Microsoft ActiveX Data Objects 2.1 Library (MSADO15.DLL)
7) Microsoft Data Binding Collection (MSBIND.DLL)

Check for these using the References selection from the Project drop-down menu item.

Note that you should NOT try to include references to VBELFOLE.DLL or to the ELF ActiveX Controls. Once these programs are compiled, their references will become available, but should be used only by appropriate client applications, like the VBELF60\SAMPLES\VB\OLE_DEMO\Ole_Demo.vbp (which uses VBELFOLE.DLL) and VBELF60\SAMPLES\VB\ELFOCX\VBOCX_DEMO.vbp applications provided (and of course by any client applications which you create).

(VBELF60 is a reference to the fact that these are VB6 projects.)

The other three components of VB ELF, VBELF.MDA, ACCELF.DLL and ELFCLIB.DLL, are supplied in the Source Code directory. There is no security on the .MDA file, and its contents can be examined. In fact, you can use VB ELF itself to open and view the tables within VBELF.MDA (use the DB Design/Open Jet MDB option). You're free to modify any of the source code in the VB ELF project, or any of the rules in the VBELF.MDA tables, but you must not distribute the source code to any third party.

Once again, you may NOT reverse-engineer or in any other way gain access to, or modify the source or executable code of the file ACCELF.DLL. You may not directly call the functions supported by ACCELF.DLL except from VBELF32.EXE and/or VBELFOLE.DLL.

Redistributable Files:
Note that VBELF32.EXE is a stand-alone program sold separately by ELF Software to end-users. You do not have the right to redistribute VBELF32.EXE to your clients. You may distribute ONLY the server portions of VBELF, which comprise the five files: VBELFOLE.DLL, VBELF.MDA, VBELF.HLP, ACCELF.DLL and ELFCLIB.DLL.

VBELFOLE will be referenced by the projects you create. When it is compiled on your machine, it is automatically registered in the Windows Registry as an available Reference. There are several ways to ensure that it is also available to your end users. Of course, you must distribute the component files, VBELFOLE.DLL, VBELF.MDA, ACCELF.DLL and ELFCLIB.DLL (and the optional VBELF.HLP file) . Normally, this is done by using the Visual Basic Setup Wizard, or a third-party installation wizard, to build a distribution kit for your application. You are probably already familiar with this technique.

You should specify that ACCELF.DLL and ELFCLIB.DLL will be transferred into the Windows system directory.

VBELFOLE.DLL and VBELF.MDA (and optionally VBELF.HLP) can go in their own directory, or in your application's directory. You may wish to create a separate subdirectory for VB ELF, since this is usually where the interface grammars are created, once the application is in use. You might prefer to have these grammar subdirectories kept separated from your other application subdirectories.

If VBELFOLE.DLL is distributed using the Setup Wizard, it will automatically be registered in the Windows registry of the target machine. You can also manually register this program as a reference by using the REGSVR32 utility. For instance, you can type REGSVR32 VBELFOLE from a DOS box command-line, or run REGSVR32 VBELFOLE from the Start / Run window of Windows 95 or Windows NT.

To delete the Reference to VBELFOLE.DLL, you can run the reverse process, using REGSVR32 /u VBELFOLE.

The two project files in the Source Code (VBELF\VBELF60\SOURCEV6) directory are:
Vbelf32.vbp -- VB ELF stand-alone
Vbelfole.vbp -- VB ELF in-process OLE server

(In previous versions of the software, VBELFOLE was an out-of-process server (.EXE) which executed in its own memory space. In the current release, it is an ActiveX DLL which runs within the memory space of the application program. According to Microsoft, this promotes security and reliability; but we probably wouldn’t have made the change except that VB6 won’t allow us to create (working) out-of-process servers anymore. So much for backward compatability!)

In addition, there are several sample programs
VBELF\ VBELF60\ SAMPLES\VB\OCX_DEMO\VBOCX_DEMO.vbp -- Sample client program using the ELF4VB ActiveX (OCX) control.
VBELF\VBELF60\SAMPLES\VB\OLE_DEMO\OLE_DEMO.vbp -- Sample client program using the OLE server directly.
VBELF\VBELF60\ SAMPLES\ Delphi\ OCX_DEMO\dELFi_DEMO.dpr -- Sample client program using the ELF4Delphi ActiveX (OCX) control.

(Note that these "4"s don’t refer to VB4; we were just being cutesy -- ELF for VB, ELF for Delphi -- and now it’s too late to change.)

Compiling VBELFOLE.EXE under Visual Basic 5.0
To create the OLE in-process server version of VB ELF (VBELFOLE.EXE), open the project Vbelfole.vbp using Visual Basic 6.0.

Build VBELFOLE.EXE by selecting Make DLL file… from the File pull-down menu. This project takes about 5 minutes to compile under Visual Basic 6 and produces a file around 5556 KB, slightly larger than VBELF32.EXE.

In case the compilation does not go smoothly, see the trouble-shooting checklist in the section on compiling VBELF32.EXE. The same Custom Controls and References are required to build both projects. In fact, they use the same source, with the difference that the Startup Form is [Sub Main] for the OLE Server, rather than [Toolbar],and it has a conditional compilation argument of IS_OLE_SERVER = -1 (set in the Project Properties Make tab). VBELFOLE also includes the ELF.CLS module containing the ELF interface class.

Visual Basic 4.0 produced wonderfully compact code and compiled extremely quickly. However, the fact is you can’t always use the most suitable tools because of the difficulty of supporting too many standards. It was necessary to move up to VB5 in order to product the ActiveX component wrappers for our OLE Server, and although these are used pretty infrequently by VB programmers (since VB has the ability to reference the OLE Server directly), we moved everything to VB5. And now that OLE DB and ADO have arrived with VB6, we’ve eagerly adopted the new standards -- this has allowed us to extend VB ELF’s reach, using OLE DB, to SQL Server 7.0, Oracle and other enterprise database solutions. (But the speed of VB4 is still a nice memory.)

To emphasize this: If the applications you plan to distribute are written in VB, you do not need to use .OCX controls, since your programs can directly reference the Properties and Methods of the ELF class, which are exported by VBELFOLE.DLL. To do this, you simply declare an interface object in your application: For example,
Private ELF_Interface As New ELF
Then, using the functions of ELF can be this simple:

' set the source MDB
result = ELF_Interface.elfSelectJetMDB("c:\mdbs\Northwind.mdb")

' open the interface grammar
result = ELF_Interface.elfOpenGrammar("VB ELF Directory","Northwind.ELF")

' perform a query
MyQuery = "Show me the customers who bought seafood products."
ELF_Interface.ExecuteSQL = 5 ' return resultant SQL query name
QueryName = ELF_Interface.elfTranslate(Q, ResponseQueryName) ' return name of the answer query

' display the answer in a DBGrid control
Data1.DatabaseName = "c:\mdbs\Northwind.mdb"
Data1.RecordSource = QueryName : Data1.Refresh : DBGrid1.ReBind

Note that ELF_Interface is an arbitrary name, you might want to use something shorter!

Users of earlier versions of our software may notice that we now support the more standard method of passing parameters to our object’s methods. All parameters have been declared as Optional so that ASP pages and any applications written using the earlier method (of setting global properties and calling parameterless methods) will still work, with no changes. However, we can’t guarantee this backward compatability through the next major release, so we encourage you to rewrite your applications using the parameter method. Of course, one of the advantages of this new method is that it supports Microsoft’s Intellisense technology, which provides views of any parameters (along with their types) in the VB IDE (Integrated Development Environment).

Compiling the sample client for VBELFOLE.DLL (OLE_DEMO)
1) Open the project vbelf\vbelf60\samples\vb\OLE_Demo\Ole_demo.vbp
2) Click Project/References. In the Available References list there will be an entry, Natural language query interface for Jet/ODBC/OLEDB, preceded by MISSING: The reason for this is that your newly-compiled VBELFOLE.DLL does not match the version used when creating the project. Uncheck the reference and close the References window.
3) Re-open the References window, and click browse. Use the file finder to locate VBELF\ VBELF60\SOURCEV6\VBELFOLE.DLL (which you should have created in this directory during the compilation of the VBELFOLE project).
4) Click OK to add the reference to your project.
5) Select Make EXE File. . . from the File pull-down menu

The OLE_DEMO sample program is a very complete example of how to call every available service exported by VBELFOLE. Whether you are writing client programs in Visual Basic 6.0 or Visual Basic 5.0 (or even VB4.0 32-bit), you can use these same techniques to directly access the language services provided by VB ELF via its ActiveX server.

However, if you plan to use ELF with projects written in Delphi or Visual C, you will need to create an OCX version. (You can also use the simple OCX version we supply.) Delphi and other programming language projects cannot reference VB OLE servers directly, so they must pass information through an OCX control. In order to simplify your projects, and ease compatibility with future projects, you may choose to do all your interfacing to the VBELFOLE server through OCX controls, even though this adds an additional layer.

We have supplied a sample OCX client project, VBELF\VBELF60\SAMPLES\VB\OCX_Demo\VBOCX_DEMO.vbp, which demonstrates the use of the ELF OCX. All the controls displayed on the forms in that project are client controls, just like the controls you add to your own forms. However, on each form there is also an ELF4VB control (named ELF4VB1). This control has been hidden behind the frame control, but you could also set its Visible property to False. In the absolutely simplest case, you could even make the control visible, and give your users access to all the ELF functions directly. Most likely, you will want to split the functions up (as we've done with the Analysis and Query functions). You may not want to provide Analysis functionality to your clients; this allows you, the developer, to completely control this process. Unlike on our sample query form, you may prefer to NOT provide a Browse facility for selecting databases, hard-coding the selection of databases into each specific application instead.

Creating an OCX Version of VB ELF

We have included an OCX control which references VBELFOLE to perform natural language analysis and queries. The project is called ELF4VB.vbp and is located in the VBELF\ELFOCX\VB directory.

You might notice how small this OCX control project is. The OCX performs very little function in and of itself. It simply packages information and passes it back and forth to the VBELFOLE server, for the benefit of programs, such as those written in Delphi and C, which cannot reference OLE servers directly.

If you received this package on disk, the OCX references the VBELFOLE.EXE server shipped (compiled). You can run the sample client programs without modification. If you receive this package as a source code only version (for example, as a software download), you must perform the following steps.

1) Compile VBELFOLE.DLL as described above in Compiling VBELFOLE.DLL…
2) Open ELFOCX.vbp under Visual Basic 6.0
3) Click Project / References. In the Available References list there will be an entry, Natural language query interface for Jet/ODBC.OLEDB, preceded by MISSING: The reason for this is that your newly-compiled VBELFOLE.DLL does not match the version used when creating the project. Uncheck the reference and close the References window.
4) Re-open the References window, and click browse. Use the file finder to locate VBELF\VBELF60\ SOURCEV6\VBELFOLE.DLL (which you should have created in this directory during the compilation of the VBELFOLE project).
5) Click OK to add the reference to your project.
6) Select Make vbELF.ocx from the File pull-down menu

Building the sample OCX-client program, "VBOCX_DEMO"

The created file vbELF.ocx is now ready to be used by client applications. To demonstrate the use of an OCX, open the project VBELF\VBELF60\SAMPLES\VB\OCX_Demo\VBOCX_DEMO.vbp.

When you first open this Project, you'll get a message from Visual Basic: "vbELF.ocx could not be loaded -- Continue Loading Project?" Respond Yes to this message. There will be another message during load of the Query Client form: "Errors during load. Refer to [log file] for details." Click OK in response. This message will be repeated during load of the Analysis Client form. Again click OK.

As before, this messages mean that you need to update the reference to vbELF (to the vbELF.ocx file you just created). Please note that this process WILL NOT need to be repeated by your users, because you will be distributing applications in sync with the VBELFOLE and vbELF.ocx files that you create. (Again, this is only for those who want to compile our distributables from scratch, instead of using the standard, synchronized releases.) This is a developer's version, so we figure you can work though these synchronization issues, and they're good experience for any re-synching you need to do if you modify any of our source code.

To update the OCX control, select Project / Components. ELF ActiveX VB Control 1.2 should appear in the Available Controls list (since it was registered when you compiled vbELF.ocx). Check its box and click OK. The VB ELF tool should immediately appear in the Visual Basic toolbox. It's now available to add to your forms. Open the form AnalyzeClient (AClient.frm), and maximize the form. Grab the 3-D frame and drag it to the center of the form. In the upper left corner there's a control named ELF4VB1, which is now a PictureBox control (for some reason VB uses this type for controls it can't identify). Delete this control and add an ELF4VB control to the form. It will be named ELF4VB1 by default. It doesn't matter where this control is positioned, since it's not supposed to be visible to the user. Set its Visible property off, or hide it behind the frame control. Then Restore and Close the AnalyzeClient form.

Repeat this same exact process with the QueryClient form. Now save the Project and run it. Most of the functionality of the OLE Server Demo is also supplied by the OCX demo. By the time you get to the stage of creating an OCX version of ELF, you'll have probably run the standalone version on some of your own databases, and should have some sample interfaces handy to test.

To build the Delphi OCX, follow the same steps as with building the VB OCX, using the project VBELF\VBELF60\ELFOCX\DELPHI\ELF4DELF.vbp. (The Delphi OCX is to be used with Delphi; it is written in VB, not Delphi.) However, if you plan to use the interface features of VB ELF via the OLE Server accessed through the Delphi OCX, and have downloaded our software, PLEASE NOTE that the VBELFOLE program must be recompiled as an out-of-process server for Delphi, not an in-process server. In other words, from the Project Properties option, you must change the Project Type of VBELFOLE to ActiveX EXE from ActiveX DLL. It will then compile as VBELFOLE.EXE. All the other steps are the same. (We’ve simply chosen not to force everyone to download an additional 5 megabyte file -- VBELFOLE.EXE -- when it can easily be created by Delphi users in a few minutes.) CD ROM distributions of the VBELFPAK installation program will include both in-process and out-of-process versions of VBELFOLE.

Importing the ELF OCX into a Delphi Project
In Delphi 3 or 4, open the sample Delphi client project located in VBELF\VBELF60\SAMPLES\DELPHI\OCX_DEMO\dELFi_demo.dpr. Select Component / Import ActiveX Control. From the list of Registered Controls, select ELF ActiveX Delphi Control v1.2 (Version 1.0). The Class Name assigned will be TELF4Delphi. We recommend adding it to the ActiveX Palette page. Click Install. In the Install window, the default installation will be into dclusr30.dpk, the Delphi User's Components (existing) package. Click OK, and if you have not previously added components to this package, you will get a message box asking you to confirm the creation of this package. You should then see a message box stating that TELF4Delphi has been installed. Scroll the Component toolbar to the ActiveX palette, and verify that ELF now appears in as an available control.

In case you need to repeat this process, we should note the steps for un-installing the control. Unfortunately, there does not seem to be any way of cleanly uninstalling a single control. We have been following this process: Click Component\Install packages. . .Select Delphi User's Components,click Edit. Select ELF_For_Delphi_TLB, click Remove. Again Click Component\Install packages. . . Select Delphi User's Components, now click Remove. Click OK to close Project Options. You should now be back where you started.

The sample client we supply in the SAMPLES\Delphi directory is similar to the version supplied for Visual Basic. It uses a hidden ELF control, ELF4Delphi1, which is behind the frame control on each of the two forms, the Analysis Client form and the Query Client form.

However, there are some differences worth noting. First of all, the OCX is different because Delphi does not seem to be able to trigger Methods in a Visual Basic OCX. Since it has no trouble setting Properties, the obvious workaround is to use Properties to invoke methods, which is what we've done.

Another difference is based on the fact that Delphi uses Microsoft's Access Driver to get at data in Jet (.MDB) databases. This is done by setting up an ODBC data source that uses the MS Access Driver. (In contrast, VB and Access go directly through Jet.) This means that data bound controls in Delphi need to be given the name of an ODBC data source (alias) for a Jet database. So the Delphi OCX uses an extra Property to expose the ODBC DSN to your applications.

This is the way it works: When you perform an analysis on a Jet MDB, you use the Jet option to select it in ELF. (You'll notice that you're not permitted to select an MDB via ODBC.) If you use the Browse function to locate the MDB, you should then add the name of the ODBC alias in the DSN box, and click Select MDB. This makes a record of the association between that MDB and the ODBC DSN. Or you can simply enter the two pieces of information (manually or programmatically) , the MDB name and the DSN name, and click Select MDB (or call vbelfSetJetMDB). From then on, each time you select the MDB, the corresponding DSN will be automatically retrieved.

If you want to add a whole set of ODBC-Jet associations in one go, enter them into the elfDataSources table in VBELF.MDA. (Fields are respectively MDB and DSN.)

This is really important ONLY if you are going to populate your own data-bound controls with the results of English queries translated by ELF (as opposed to letting ELF display the datasheets, forms or graphs). In this case, you need to supply the Jet MDB name to ELF, and the ODBC DSN to the Data Components on your form. See the sample code for the exact mechanism for populating these controls.


Last Updated: November, 1999