Converting classic Superbase programs to SIMPOL, depending upon complexity of the Superbase code, can be easy or complicated. Even if it is complicated it will be easier to convert to SIMPOL than to any other target, simply because the necessary components, such as detail blocks, are provided by SIMPOL and these are not found in other products (grids yes, but not nestable detail blocks). Also, numerous utilities are provided to convert data, forms, dialogs, menu programs and more. It is probably easier to clean up your code in SBL first than it is to try and convert it into SIMPOL and clean up the resulting mess.

It is a very good idea to be on a very recent version of Superbase when you convert. Nothing older than Superbase 2001 is recommended, since that version contains a solid implementation of the Win32 DLL support and also includes the Project Manager, which will greatly help in reworking projects. Also, a number of the conversion utilities that are shipped with SIMPOL are written in SBL and may or may not work as expected on older releases. The tools will not work if run from version 2, and may not work on a release older than 3.6!

Guidelines for Preparing Code in Superbase Classic for Conversion

The following are a set of general guidelines that will make converting any project to SIMPOL easier:

1. Modular design: Try and make sure that you do a good job of reusing code, keep common code in a set of specific modules.
2. Event driven: Take the approach of:
   1. Initialize the app.
   2. Run the app (a small loop just waiting for events preferably using process().
   3. Close the app (clean up properly, though SIMPOL does most of it for you).
3. Limit global variable usage. Use globals as if they were either constants or to transmit essential information. Document any use of them.
4. No GOTOs except for ON ERROR GOTO. No GOSUBs and RETURNs (use SUBs or FUNCTIONs). Try to use local error handling as much as possible (turn off the expected error(s), do a CLEAR ERRNO, then try the operation and check for success). Make use of Superbase.ErrorHandlingPush()and Superbase.ErrorHandlingPop(). Use the global error handler for syntax error trapping only.
5. Don't use field-level calculations, constants or validations. Put these into a single routine that is called when you save a record. Put form-level validations and calculations into functions and assign them to onlostfocus events, rather than using the calculation and validation features of the textbox objects.
6. Don't use v2-style BEFORE and AFTER triggers (convert them to ongotfocus and onlostfocus events). If you have to use the ENTER statement, only use it to initiate data-entry, don't use it for ranges.
7. Use the Superbase report engine, but avoid using the alignment and sizing codes from text-based reporting (? @33;&27]foo.FOOBAR).
8. Always use the full syntax if possible when using the SELECT, etc. statements like: SELECT FORM KEY s$ FILE "FOO" INDEX Foobar.FOO, don't use the shorthand versions like: SELECT FORM KEY s$. Also, don't use things like WHILE NOT EOF(""), instead name the file: EOF("FOO").
9. Avoid using SuperBoxes in any new project if you can, conversion will be a be a lot of work otherwise. If you have capabilities in SuperBoxes that you are using that are not yet part of SIMPOL, please contact us and let us know, since there is a huge array of functionality we will yet be adding and this can help us to prioritize the order in which we add things.
10. If you are making DLL calls (to the OS or otherwise), try and use the Win32 versions if you can, since there will be less work to convert them later (often the calls are not exactly the same).
11. If you decide to use something that is incredibly clever in SBL, realize that it may not work (or even be necessary) in SIMPOL. Always document clever bits since later you may not remember why they were clever or which problem they were meant to solve.

Things that SIMPOL Can or Cannot Do

This is a list of things to be aware of that will be either possible or not in SIMPOL:

1. No GLOBAL variables (but you can create a user-defined type that has a property for everything you want to keep track of and pass that object around).
2. SIMPOL has a constant statement, but it is handled at compile time. It is handy for things that never change in a program. Don't use it for strings if you intend to localize the program into another language. Create a special object for those, such as an array and use a constant integer as the index into the array. Then make the array part of your application object (the one you hooked all the global bits into). This will make it possible to eventually load the strings at runtime.
3. In SIMPOL you can have as many copies of the same record available concurrently as you require, but only one can be locked.
4. In SIMPOL there is no MDI (yet), but you can have as many top level windows, each with a menu bar, status bar and tool bar, as you need.
5. There is no difference between forms and dialogs in SIMPOL, forms can be hosted in windows or in dialog windows. Dialog windows can be either modal or non-modal, but don't have scroll bars, menus, status bars or tool bars. Forms can even be hosted in tool bars.
6. SIMPOL applications can be multithreaded, so that you may have two or more threads of program execution happening concurrently. This is not required for using multiple windows, however, it can be useful under certain circumstances.
7. There are utilities for moving dialogs, forms, menu bars, and database tables to SIMPOL from SBL. There is a community project to write a code converter, though it may not be able to move all code. It will probably manage non-object code slightly better than it does object code. The converter is plug-in based and can be extended by our user community.