Visual Basic / Paradox Engine Demo Written by Steve Jackson 9152 Brabham Drive Huntington Beach, CA 92646 Source code free to all. Comments, questions are welcome. If you know of any ways I can earn a little extra income to purchase a faster computer (and with more memory of course) that would be welcome too. ====================================================== A Visual Basic application called "Visual Video" that uses Paradox Engine for database access. It is NOT meant to be a viable video tape rental system - just a little sample of calling the Paradox Engine DLL from Windows VB. No exe file is included to keep zip file small. Also, the DLL files are not included. ====================================================== Assumptions: You have a working knowledge of Paradox Engine You have the Paradox Engine DLL - PXENGWIN.DLL You have Visual Basic and its DLL Suggestion: Load this in a separate directory. Put this name in db_dir in GLOBAL.BAS (so the app will know where tables are) Files included: VVDEMO.MAK Project make file PXMODULE.BAS Engine DLL definitions and calls to engine functions VVDBMOD.BAS Customer database routines VVDBMOD2.BAS Item database routines VVGLBL.BAS Global defines - but no engine stuff *.FRM Various forms *.DB and *.PX Customer and Item databases VVDEMO.TXT This file BACKGROUND The Paradox Engine comes with a DLL library with all the engine functions except for PxNetInit() which is handled a little differently in Windows. Visual Basic can use most of these easily (more on this in a moment) by defining them as DLL declarations. The important thing is to define the C argument types in equivalent Visual Basic types, and it is VERY important to use ByVal properly to define variables passed by reference. Also, strings passed to functions for update should be defined as fixed length (see PxGetAlpha). C does not understand VB's variable length strings and will promptly crash your app if you get it wrong. Most of the engine functions return an int as an error code, and this works quite well in VB. I called a generic error routine after most calls that traps show- stopper errors from normal expected errors like not- found, etc. At least one of the functions returns a pointer to a string - PxErrMsg, and I have not yet worked out how to use that in VB so for right now my error routine just shows the error number. Some sharp programmer could probably get some windows memory and grab a pointer to it, but those kind of API calls are beyond the scope of this little tutorial. STRUCTURE OF VVDEMO I tried to put all the Paradox Engine declarations in one BAS file to isolate it from the rest of the app. I also have one BAS file for each database with various functions for Startup, Get, Add, Update, Delete, etc. etc. This results in a two layer approach: The form objects call the generic functions in VVDBMODx.BAS which in turn call the Paradox specific functions in PXMODULE.BAS. The reason for this is to make it easier to change the Paradox specific routines without affecting the application, and to keep your global file from getting cluttered up. You may love it or hate it, but at least I had a reason for it! By the way, if you create module files as plain ASCII before editing them in VB, they will remain ASCII files that you can use with your favorite editor. If you start a new module file in VB, it saves it in a weird tokenized form. (After all, it is basic you know) NETWORK INIT In the dos version, you can initialize to whatever kind of network you want with PxNetInit. In windows, you must always init with PxWinInit, and it picks up the desired network from settings in WIN.INI. I came up with a way to change this at run time in a C program like this: I put up a dialog box with different network choices. When the user clicks OK, I wrote to WIN.INI with the WriteProfileString() API call to change the settings, stopped the engine with PxExit(), and restarted with PxWinInit(). This picked up the network change (or userid or net drive) without stopping the app. I have not tried it yet in VB, but it worked fine in C. FINAL WORDS Thanks to my friend John Jaster who gave me most (but not all) of the Paradox DLL declarations. I added some, and corrected a few. They are still not complete, but I leave that to the next person in this chain. Or if anyone reading this wants me to finish it up, let me know, and I'll find the time!