With the growing prevalence of 64-bit Windows being pre-installed on many new computers, although it is becoming difficault for existing Superbase systems. It is possible to still run Superbase Classic using Windows 10 32bit OS either as a fresh instal to a bare bones type PC or by installing Microsoft Windows 10 32bit ISO into VM Ware workstation on any 64bit pc, VM ware is superb easy to use with no driver issues and Superbase Classic runs better than ever before on it.
it is important to start planning a forward direction or migration path for your existing Superbase systems.
We at Superbase Software Limited are happy to provide as much assistance as we can with Superbase Classic systems on to VM Ware, or migrate onto Superbase Next Generation (SB-NG) SB-NG was designed and produced by the same team that released the final five major versions of Superbase it was always the next generation.
Converting Superbase Classic programs to SB-NG depending upon complexity of the Superbase code, can be easy or complicated. Even if it is complicated it will be easier to convert to SB-NG than to any other target, simply because the necessary components, such as detail blocks, are provided by SB-NG and these are not found in other products (grids yes, but not detail blocks with normal controls). 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 and clean up the resulting mess.
It is a very important to be on the last version, Superbase Classic when you convert. Nothing older than Superbase 2001 is recommended, Classic 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 SB-NG are written in SBL and may or may not work as expected on older releases.
Guidelines for Preparing Code in Superbase Classic for Conversion
The following are a set of general guidelines that will make converting any project to SB-NG easier:
- Modular design: Try and make sure that you do a good job of reusing code, keep common code in a set of specific modules.
- Event driven: Take the approach of:
- Initialize the app.
- Run the app (a small loop just waiting for events preferably using process().
- Close the app (clean up properly, though SB-NG does most of it for you).
- Limit global variable usage. Use globals as if they were either constants or to transmit essential information. Document any use of them.
GOTOs except for
ON ERROR GOTO. No
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.ErrorHandlingPop(). Use the global error handler for syntax error trapping only.
- 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.
- Don’t use v2-style
AFTERtriggers (convert them to ongotfocus and onlostfocus events). If you have to use the
ENTERstatement, only use it to initiate data-entry, don’t use it for ranges.
- Use the Superbase report engine, but avoid using the alignment and sizing codes from text-based reporting (
- 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:
- 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 SB-NG, 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.
- 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).
- If you decide to use something that is incredibly clever in SBL, realize that it may not work (or even be necessary) in SB-NG. Always document clever bits since later you may not remember why they were clever or which problem they were meant to solve.
Things that SB-NG Can or Cannot Do
This is a list of things to be aware of that will be either possible or not in SB-NG:
- 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).
- SB-NG 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.
- In SB-NG you can have as many copies of the same record available concurrently as you require, but only one can be locked.
- In SB-NG 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.
- There is no difference between forms and dialogs in SB-NG, 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.
- SB-NG 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.
- There are utilities for moving dialogs, forms, menu bars, and database tables to SB-NG 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.