François Ghoche, ATON Consulting + V.I.P. Group (France)
Warning : This paper has been written while the product build available was not final. Some innacuracies may be found. This paper must not be considered as an accurate and complete description of the final version of the product.
Introduction - Development and deployment platforms vs. Visual dBASE versions
The New features in Visual dBASE 7
32-bit virtual machine and API bindings - 32-bit BDE & SQL Links - New Deployer (customized InstallShield) - New Editor with Tree-like live outline - OCX - Grid class - Container class - Notebook class - Toolbar class - List and Outline classes - Report classes and Visual two-way Designer - Data-related classes - New header for DBF tables with Data Dictionary - Native support of CDX indexes (FoxPro) and Access databases - Language enhancements - New error/exception handling - New Navigator - Project Manager - Additional Images types - Web Tools - Form Designer enhancements - New Debugger
Obsolete features in the 32-bit version
No support for VBXs - No more Crystal Report - No dBASE DML QBE Designer - No more @ SAY/GET
Building a strategy
Develop under Visual dBASE 5.x - Develop under Visual dBASE 5.x, but use the 32-bit Deployer - Move all development to Visual dBASE 7 - Move to Visual dBASE 7 and keep code at Visual dBASE 5.x level - Set up for cross-platform development under Visual dBASE 7
Preprocessor directives - Build wrapper classes for missing functionality - Use Function libraries - Deployment files and scripts - Stay in touch
Reports - Browse vs. Grid - OCX vs. VBX - Data-related classes vs. QBE files - New controls - New DBF tables and data dictionary - Exception handling - Other language enhancements - New image formats - Porting DOS applications - Porting Visual dBASE 5.x applications
The final Word
Visual dBASE 5.x is compatible with Windows 3.x, Windows 95 and Windows NT. So, why do we need to care about the deployment platform ?
Of course, there is always the option of keeping on using Visual dBASE 5.x to develop for all platforms. Then the whole question can be overruled.
However, there are some drawbacks.
First, the new version produces 32-bit code and runs with both a 32-bit virtual machine and a 32-bit BDE. In theory, this should give faster and more secure code, which builds on the native features of 32 bit operating systems. However, this kind of argument has to be checked against the effective implementation of the product, which is not possible at the time of writing this paper.
More importantly, the 32-bit version comes with new features, which make the migration to the new development environment worthwhile.
All right, then why not just move to the new environment and forget about Visual dBASE 5.x altogether ? Well, the 32-bit compiler produces 32-bit code, which cannot be deployed on Windows 3.x computers. So unless you are sure all your users/customers have moved away from 16-bit operating systems, you still have to provide executables for both 16-bit and 32-bit platforms.
So what are the options ?
In this paper, we shall first cover the new and obsolescent features in Visual dBASE 7. Then we shall examine possible strategies and tactics to face the challenge.
Running in the 32-bit protected environment with a new 32-bit virtual machine (runtime engine) provides for better code and memory protection. Visual dBASE 7 will use the new Win 32 API calls and features.
The Borland Database Engine (BDE) which comes with Visual dBASE 7 (the same one as in other 32-bit Borland products such as Delphi 3 and IntraBuilder) is also tailored for the 32-bit operating system environment.
It comes with enhanced native drivers for DBF (dBASE and FoxPro, including CDX indexes), DB and MDB (Access) data, as well as driver support for new SQL formats, such as DB2.
There is also a new configuration/administration utility, with tree-like cascadable views.
Remember the pain when you had to work concurrently on two different projects with the Visual dBASE 5.x Deployer ?
Well, Visual dBASE 7 comes with a customized version of InstallShield, the world famous deployment software. You will have the possibility to save your parameters for each project and call them back when needed.
It will also provide for more and better customization. In addition, it complies with the Windows 95/NT specifications and can update the registry and also provide for an uninstall feature.
The new Brief-like editor is worth the migration by itself !
You will have more options for customization in the properties dialog. Among these are two options for selecting the character set used : Windows Latin-1 or the DOS active code page.
But the most important feature is the permanently updated left-margin live outline. By dragging the adjustable left pane border, it displays a tree-like outline of your program. The various objects and methods are organized in logical order, and alphabetical order within each category. When you click on an item in the outline, the cursor is moved in the right pane and the corresponding piece of code is highlighted.
The outline is live. It is updated while you modify the code.
The OCX specification will bring all the advantages of the DLL and the VBX plus OLE. This will make your application even more open to external tools and features.
OCX is also the basis for ActiveX support. Visual dBASE 7 will support ActiveX in forms and reports. To create ActiveX, you will need 3rd party tools.
For all those who complained about the limitations of the current Browse class, the new Grid class will be programmable down to the individual cell. It means you will be able to control the cell color or other properties, for instance. You should also be able to define different controls, such as combo boxes in various cells and images in others.
It does mean : bye, bye Browse... at last. However, the old Browse will still be emulated, for compatibility when porting existing Visual dBASE 5.x applications.
This class will bring a new level of power to the object oriented design of your applications and tools.
You can group several controls into a container. Then you can turn the container and all contained objects into a custom control, which you can drop from the control palette into forms and reports.
The Notebook class could be described as a combination of a TabBox class and a container class.
First difference : the tabs are on the upper edge of the notebook. Also, you do not need to synchronize the notebook with form pages, as you do with the tabbox. That's because the Notebook class handles its own pages : one page per notebook tab.
Each page is a container. You can put any controls in there, and move them from one form to another. You can also put Containers objects into Notebook pages, etc.
Now you can have it too... A customizable, dockable Toolbar class comes with Visual dBASE 7..
You will now have Windows'95 like cascadable tree views.
The Report Designer is a visual two-way tool, similar to the Form Designer. It comes with an equivalent set of tools and features.
The Report classes are fully sub-classable. This means that you can have report classes used as models for other reports. Custom report classes are used in the visual designer, in the same way as custom forms from CFM files in the Form Designer.
The new classes include the Query/Rowset/Field group of classes, as well as DataModule, Session, StoredProc and Database. The new set of data-related classes provide for encapsulation for database and table data. They come with a new Query Builder, which reads and writes SQL.
The Data Module Designer and Wizard enable you to build Data Modules custom controls, which are reusable.
For more information on data-related components and features, please refer to the paper entitled Moving to the New Data-Related Classes in Visual dBASE 7 (DB070.html).
Attributes are created in the Table Designer and include : constraints, table/field-level properties, primary keys, referential integrity, ... Here is some of the new features :
Custom field attributes comprise an active data dictionary that works at runtime, not just design time. These attributes are named properties with string values.
As previously mentioned for the BDE additions, you can now share data with more existing applications using FoxPro tables and indexes, as well as Access MDB databases.
This is done through native support, not with an additional driver. It will provide better performance than when using ODBC drivers with Visual dBASE 5.x.
WITH <oRef> <code> ENDWITH
f = new form() with f text = "whatever" ... more properties height = 3 endwith f.open()
Instead of :
f = new form() f.text = "whatever" ... more properties f.height = 3 f.open()
Try / Catch / ? provide for structured exception handling with TRY block, THROW statement, and Exception class :
TRY <code to execute> [ CATCH ( <exception type1> <exception oRef1> ) <code in case of error> [ CATCH ... ] ] <code in case of error> [ FINALLY ] <code to always execute at the end> ENDTRY
The following code creates a text file and runs a process. If an error occurs, a message is displayed. No matter what, the file is always closed at the end.
try h = fcreate( "somefile" ) do stuff catch ( Exception e ) msgbox( "Error occurred during stuff" ) finally fclose( h ) endtry
The new Navigator comes with upper edge tabs, as well as additional tabs for Reports, DataModules and Projects. The current build includes an IntraBuilder-like navigator. The shipping version should include a revised tool.
It will help you keep track of your whole projects.
Here are some features of the Project Explorer :
Support is now provided for more image formats : PNG, JPG, GIF (including animated GIF), XBM, EMF.
The shipping version should come with more Web tools and Internet enablement features.
The improved Form Designer, features include :
In both the Form and Report Designer, an improved Inspector, with :
It features :
The VBX specification describes a 16-bit DLL with standard interfaces.
In the 32-bit world, this role is taken over by the OCX specification. To make a long description as short as possible, an OCX combines the VBX and the OLE specifications.
In other words, you will not lose any functionality when changing from the former to the latter. However, you will possibly have to look for a replacement OCX to your existing VBX.
Another possibility is to replace a VBX with a Visual dBASE class or function, in case some of the new features in Visual dBASE 7 meet the need.
Crystal Report is not bundled in Visual dBASE 7.
Borland plans to provide a migration utility of some sort, to convert existing "rpt" files to Visual dBASE 7 code. This should solve the question of the migration from Visual dBASE 5.x to Visual dBASE 7.
What about cross-platform development ?
The goal is then to avoid having to design two different sets of reports, one for each platform.
One possibility is to buy the 32-bit version of Crystal Report, and keep on using Crystal in both Visual dBASE 5.x and Visual dBASE 7.
If you do not like this idea, another possibility would be to use a replacement for Crystal Report in Visual dBASE 5.x. This set of tools would emulate to a certain extent the report classes in Visual dBASE 7. You can then build programs with reporting code suited for both 16-bit and 32-bit Visual dBASE versions.
What we mean here is that you cannot visually design a QBE in Visual dBASE 7 and have the resulting generated code be the traditional old DOS syntax : USE, SET RELATION, GO TOP...
This is because the visual designer in Visual dBASE 7 will generate code for the new data-related classes : SQL DML (Data Manipulation Language).
I don't personally consider this an inconvenient. Of course, it may push you a little bit too fast than you would like to switch to the new syntax... If you do not like the idea, you can stick with dBASE DML.
In this case, you will have to code your QBE files by hand.
Of course, another possibility is to keep on using the Visual dBASE 5.x query designer to generate your QBE files. Anyway, Visual dBASE 7 will use both DMLs fine in programs and forms.
Support for some DOS commands addressing the screen directly will be discontinued.
What this means is that you will not be able to run a DOS program unmodified in Visual dBASE 7. You will have to do some re-engineering work first.
However, it also means that Visual dBASE 7 will not carry all that extra weight just for the sake of running old DOS programs in the result pane of the command window.
All right, so you have to make a decision and build a strategy. What are the choices ?
This is the "don't get wet" strategy. You stay under the environment you have learned to know and master.
If 90% or more of your users are still running Windows 3.x, this choice may be worth some consideration.
However, you will not benefit from the new features in Visual dBASE 7. You will also not have access to 32-bit operating system features, such as long file names and naming conventions. Internet enablement of your applications will be limited to what is available in Visual dBASE 5.x : the WebTools - no OCX/ActiveX support, for instance.
Visual dBASE 7 comes with a customized version of InstallShield, which gives the developer much more control on the deployment process. It also provides for an "Unisntall" feature, as expected under the 32-bit operating systems environments.
This possibility has not been tested at the time of writing of this paper. However, one can expect that the code must still be compiled under Visual dBASE 7 (i.e. provide a 32-bit executable) in order to be used with the 32-bit Deployer.
All the fantastic new features are then available for you. You can use the new tools to enhance your productivity. Your users can benefit from a truly full 32-bit environment.
One question remains : what about Windows 3.x users ?
Two possibilities :
Outside those two cases, you may have to think about it twice before choosing this path.
Moving to Visual dBASE 7 brings several tools and enhancements to the developer.
You may decide to benefit from the added productivity, while keeping the code at Visual dBASE 5.x level.
In this case, you just refrain from using the features that cannot be compiled under Visual dBASE 5.x : Report Designer, data-related components, new language additions, etc.
The goal is to produce source code that can then be compiled and deployed from within Visual dBASE 5.x.
This strategy will require some trial and error to be implemented. It also requires a lot of self discipline to stay within the narrow track, while working on the large boulevard.
Setting up an environment for cross-Platform development using Visual dBASE 7 will bring many advantages :
However, this is not a "one day" switch.
You have to invest some time to learn the new functionality and features. The Borland newsgroups and the Compuserve forum will help you in that respect. But you still need some time to get up to speed and comfort.
There are also some differences in existing features that you will need to become accustomed with.
Most of all, as you have now realized, you will need to build some tools to ensure compatible functions for cross-platform development.
Deciding for a strategy is the first step. Then, you need to work on the tactical part and set up your toolbox.
Preprocessor directives are the first and most important feature to help cope with platform incompatibilities.
Whatever your choice for cross-platform development, you will have to face this question : will you maintain two different sources, one for each platform ?
The most efficient way to handle the task would be to maintain only one source for both platforms. But then, you need a way to make sure the source code for features specific to Visual dBASE 7 is not fed to the Visual dBASE 5.x compiler. Also, the Visual dBASE 7 compiler mustn't see the source code you have included only for the Visual dBASE 5.x platform.
Preprocessor directives are the way to handle that task.
The preprocessor reads the source code before it is fed to the compiler. In the meantime, it executes whatever "directives" are included in the text stream.
The directives will enable manipulating the source code to a certain extent. One important thing to understand is that the source code is not code for the preprocessor. It is just : text. The preprocessor does not understand anything about the syntax or logic of the program.
Let's summarize the most important directives as needed in this particular task :
The Define directive as described will declare a meta (or pseudo) variable. Once "defined" we can test for the existence of this meta-variable anywhere within the source code for the current program file.
Important : Please note that the scope is limited to the current program file only.
If you need to use the same meta-variable in more than one program file, you have to :
We shall cover Include files later in this section.
Once the meta-variable is declared, we can use it within control structures :
#IFDEF MetaVariableName * some source code #ELSE * some other code #ENDIF
In the following example, if the meta-variable VDB7 is defined, the report definition ReportFile.rep is used. Otherwise, the Crystal Report file ReportFile.rpt is used. In the latter case, the Grid class declarations will be replaced by that of a custom class : MyBrowse.
The control structure can also be used to isolate some platform dependent code, as needed.
#DEFINE VDB7 #IFNDEF VDB7 #DEFINE ReportFile ReportFile.rpt #DEFINE Grid MyBrowse * some Visual dBASE 5.x specific code #ELSE #DEFINE ReportFile ReportFile.rep * some more Visual dBASE 7 specific code #ENDIF
Of course, while IFDEF means "if the meta-variable is defined", IFNDEF checks if it is not defined.
Preprocessor directives are also used to declare pseudo-functions :
#DEFINE NewFunction(x,y) OneFunction( OneOtherFunction(x,y),x )
In this case NewFunction would be a Visual dBASE 7 specific function. It will be replaced before compilation with the alternative structure using OneFunction and OneOtherFunction, which are supposedly Visual dBASE 5.x compliant syntax.
Of course, this pseudo-function declaration should be included in a platform control structure similar to the previous one :
#IFNDEF VDB7 #DEFINE NewFunction(x,y) OneFunction( OneOtherFunction(x,y),x ) #ENDIF
You will most probably need to use some or all of these directives in more than one program of your application. Instead of typing them again and again (or even using cut and paste) in the beginning of some of your program files, it is much more efficient to group all these directives in one common text file. You can then include the text file in the beginning of all your programs.
The "h" extension is just a conventional way of identifying include header files.
I usually have one header file for each application, named with the same name as the main program (or the EXE) and included in the first line of every program.
These are only some examples of the most important usage of preprocessor directives. For a more extensive description and examples, please check the Visual dBASE Programmer's Manual.
You can design classes specifically to emulate some of the new Visual dBASE 7 classes under Visual dBASE 5.x,, or else to occupy the place of non supported functionality.
For instance, take the issue of the Browse and the Grid classes.
I doubt you can easily emulate all the features of the new Grid class in Visual dBASE 5.x code. However you can still design a custom class extending the properties and methods of the Browse class. You can then use preprocessor directives to include the code to use either the Grid class or your replacement custom class, depending on the target platform :
Class MyBrowse of Browse * class constructor * methods' override * additional methods EndClass
One alternative possibility would be to use a grid VBX for the Visual dBASE 5.x side of your applications. You can then use a class as a wrapper, as well as preprocessor directives for cross-platform compiling.
* Begin file MyApp.h * Comment out the following line before compiling under Visual dBASE 5.x: #DEFINE VDB7 #IFNDEF VDB7 CLASS Grid Of Text CUSTOM this.Text = "Grid class emulation" LOAD DLL GridVbx.vbx DEFINE GridVbx GridVbx1 OF THIS; PROPERTY; Top 1.4111,; VBStream " GridVbx.BFM 56",; Left 15,; Height 1.3535,; Width 23.166 * some Visual dBASE 5.x specific code ENDCLASS #ENDIF *End file MyApp.h
The goal would be to build twin functions to suit both platforms. For instance, you could optimize the code for better performance or for different behavior under Visual dBASE 7. In this case, you may not need preprocessor directives, because the part of the function written for Visual dBASE 5.x and it's Visual dBASE 7 counterpart are both valid code in both environments.
Function MyFunction( SomeParameters ) * some common code IF "7." Version() * code you want to run under Visual dBASE 7 ELSE * code you want to run under Visual dBASE 5.x ENDIF * NB: the code must not contain version-specific syntax * or else, enclose it in preprocessor directives RETURN SomeValue
Function libraries may be used to provide for compatibility within your applications, so that you can use the same functions in your source code, regardless of the target platform.
The last step in application development, but not the most straightforward in Visual dBASE 5.x.
The Visual dBASE 5.x Deployer relies on :
The Visual dBASE 7 Deployer should bring more flexibility and customization.
Also, the Project manager will enable better centralized control on all the files of an application.
After you have mastered the new environment, you will be able to build script files or programs, to prepare or update deployment setup for both platforms automatically after each new version is complete.
To ask questions and gather examples and updates on these and other tools and hints, the most efficient way is to stay in touch with the Visual dBASE community on-line.
The official way is through the private newsgroups sponsored by Borland and managed by the TeamB volunteers (forums.borland.com).
A propagated Usenet newsgroup is also available with free volunteer support (nntp://comp.databases.visual-dbase).
If you are using a Web browser, you can check the following page (in French) : http://www.fghoche.com/vdblinks.htm
You will find there all the links for the Borland newsgroups. When you click on one of those links, the browser should load your newsgroup reader (providing you have installed one on your computer of course) and connect you directly to the newsgroup.
You will also find on this page some links to other interesting Visual dBASE resources and sites.
Of course, you can also visit and participate in the VISUALDB forum on CompuServe. Although not the "official" place anymore, since Borland has moved support to the private newsgroups, it was and remains on of the best places for exchanging with other developers, getting responses to your questions and accessing the best library of resources on-line.
Another important place to get the latest information and tools is the Visual dBASE Web Magazine on the Alan Katz Web site ( http://www.ksoftinc.com/vdb/ ). The French version of the magazine is hosted in my own Web site ( http://www.fghoche.com/vdbmag/ ).
There is also an e-mail newsletter distributed by Borland International. It will keep you informed of news releases and events. You can subscribe by filling in a form on-line at the following URL : http://www.borland.com/feedback/listserv.html
At the time of writing this paper, the field test version of Visual dBASE 7 is still in its alpha status. While giving crash-proof code and old-timer hints is still a difficult task, I can nevertheless warn you against some hard-to-pass situations.
As previously explained, Crystal Reports and the Visual dBASE 7 Report classes are very different animals.
If you want to use your existing report definitions on both platforms, one solution would be to buy the latest 32-bit version of Crystal Report and use it for your Visual dBASE 7 applications.
If you are among those developers who cannot wait for the opportunity to get rid of your toolbox of CrystalWeirdnessWorkArounds, you will want to switch to the Visual dBASE 7 Report classes immediately.
Then remains the task of emulating equivalent features under Visual dBASE 5.x.
Just to convince you - if needed - that you are not alone in this situation, I have included on the Conference CD-ROM three candidate Report tools for Visual dBASE 5.x. They are all written in Visual dBASE code (plus Windows API calls when applicable). While they may not be exactly suited for the task in their current status, you may be interested in adapting/learning for your cross-platform reporting needs. The files are :
No doubt many developers will tackle this subject when Visual dBASE 7 ships. Stay tuned to the news for future updates.
Browse emulation will be provided in the shipping version of Visual dBASE 7. This will enable porting your Visual dBASE 5.x applications to the 32-bit version and running the current forms.
When adding new functionality, or developing new applications, you will most probably want to use the new Grid class instead of the Browse. Remember however that Grid functionality will be difficult to provide/emulate under Visual dBASE 5.x.
I have included an example in the code file for this session. The file BrPlus55.zip contains a custom Browse control. The 'cc' file proposed by Jim Sare extends the Visual dBASE Browse class. You can determine CurrentColumn/CurrentRow/TopIndex/ColumnCount of the custom Browse control.
You may also choose to use a Grid VBX to provide for equivalent functionality under Visual dBASE 5.x to the Grid class used in Visual dBASE 7.
If you are currently using some VBXs in your Visual dBASE 5.x applications, you will have to :
One thing is sure : you will not lose when changing from VBX to OCX. The latter adds OLE functionality to the open specification already provided by VBXs.
With the support of a third-party add-in such as JazzAge ActiveX, you will also be able to create ActiveX from your applications. However, bear in mind that same will hardly ever be available for the Visual dBASE 5.x version of your compiled applications.
You can keep on using dBASE DML syntax for your data sources in forms.
However, you most probably will want to benefit from the data encapsulation and better portability brought to you by the new data-related classes.
In this case, you will have to handle both versions' syntax in your source code, as previously explained.
Bear in mind however, that the navigational logic may sometime differ between the two DMLs.
The most obvious example is the behavior when reaching the boundaries of a table/data set.
When using the dBASE DML, if the record pointer is at the last record of the table/set and you use the Skip command, the EOF() condition will be met. The record pointer will then be pointing to this strange place somewhere between heaven and hell called the phantom record.
When doing a similar move in a Rowset, the EndOfSet property will be triggered as well and set to True. However, the current record will still be the last record in the Rowset. There is no such thing as a phantom record in the Rowset.
Another difference is that while you have to test for EOF() and/or BOF() with dBASE DML, depending on the direction of your navigation, the EndOfSet property is used in both cases in a Visual dBASE 7 Rowset.
Of course, one major advantage is that the expected behavior is then the same whatever the data source, whether DBF, DB or SQL engines.
Visual dBASE 7 comes with many new controls. Most of them are UIControls somehow related to the new GUI environment as available in Windows 95/NT.
Of course, you will have to design your applications in such a way that you do not rely exclusively on the new controls. Or else provide for similar functionality via VBXs or DLLs in the Visual dBASE 5.x version of your application.
If you intend to use the new data dictionary features as provided in the version 7 DBF tables, you will have to beware : these tables and features will not be usable in a Visual dBASE 5.x program.
The major inconvenient is then that you may have to provide for additional code to reach similar end results in the Visual dBASE 5.x version of your application. The basic goal for using a data dictionary could then be defeated.
Also, remember to use Visual dBASE 5.x when creating the data tables for that environment. Visual dBASE tables using the new header cannot be used in Visual dBASE 5.x. Note that you can also use Visual dBASE 7 to create the tables for the 16--bit part of your application if you set the level to '5' in the BDE configuration for the DBF driver.
Exception handling syntax is a major addition in Visual dBASE 7.
However, it provides for a different source code structure from the traditional ON ERROR syntax.
If you want to have more control and use the new syntax, you will have to be careful in the design of your cross-platform programs.
If you want to produce cross-platform code, it may be advisable to dump some of the new syntax altogether. After all, you have survived without the increment/decrement operators until today...
You can also emulate some other features, again, either with functions, or else with preprocessor directives to Define meta-variables and pseudo-functions
You will probably want to use one of the new formats - such as the JPG or GIF format - in your applications (or you may just have to).
The Visual dBASE 5.x version of such an application will require an external viewer. You can look for an adequate VBX or a DLL.
Such a component may already be available in your computer, as many software packages install such viewers automatically. However, you should inquire about copyright and distribution conditions if you intend to provide one of them with your executable.
If you intend to move a DOS application for execution in Visual dBASE 7 as is - same as could be done in the Visual dBASE 5.x result pane of the Command window - then the warning spells in two words : forget it !
Re-engineering is a necessity, at least as far as the user interface is concerned. @ SAY/GET are not supported anymore.
Of course, it is always better to start from the basic specs and build the Visual dBASE 7 version of your application from the ground up, all over again.
For some/all of your existing Visual dBASE 5.x applications, you may intend to proceed with a simple port to Visual dBASE 7. You may then erroneously think that all this discussion is of no interest to you.
You are wrong !
In many cases recompiling the source code under Visual dBASE 7 simply may not work. Or at least, it will not suffice.
In other words, you may be concerned by some, or all, of these pitfalls.
Of course, recompiling the entire Visual dBASE 5.x application is the first step to achieve, just to know about possible problems.
However, it is usually a safe bet not to start by moving large applications to begin with. Instead, you may build your experience, tactics and toolbox step by step. You will save time in the long run.
This paper does not provide an extensive set of tools and utilities because they are simply not available yet. Nevertheless, I hope it will have given you a better overview of the task, as well as some pointers to build your own strategy and tactics for cross-platform development with Visual dBASE.
François Ghoche - July 97
Ghoche can be reached at :
CompuServe 100023,24 ;
mail : ATON - BP 49 - 78042 Guyancourt (France);
voice : +33 (0) 139 440 301;
fax : +33 (0) 139 440 331;
World Wide Web : http://www.fghoche.com.