Xbase++ provides INIT procedures, a concepts which allows by a simple declaration of INIT before the procedure keyword to ensure that this procedure is executed before your procedure main is executed. An example is shown below.
The order of INIT procedures is implicit, so you can not count on having a module A available in the execution of your INIT PROCEDURE of module B.
Well the idea of INIT procedures is from Clipper and has its roots in a procedural / module oriented world. Since Xbase++ comes with a fixed typed and prototype based Object Oriented programming model we already can package and organize functionality much more better than in the past. Remember a procedural module if designed well compare very good to classes.
Since the Xbase++ OOP Engine also provides the concept of classes - the factory of your objects - it is a good idea to put all your init code into the
- :initClass() method of your class. However in case of an error you need to raise an runtime error since initclass is called implicit. You also need to call :initclass() of your parent classes to ensure proper initialization of them.
- Implement a constructor, instead of using :new() for instance creation. Just add a CLASS METHOD Create(), do the initialization inside the class method, if it fails return NIL no object could be created since the init of your class failed, or simple create the instance with self:new() and return it.
Notes:
Xbase++:
INIT PROCEDURE startupMyModule()
// your code is
RETURNBackgroud
When an Xbase++ process starts up, the runtime as well as other components of an application need to be properly initialized before the execution of procedure main can take place. In Xbase++ the following order documents that application startup sequence:- Xbase++ runtime startup
- Register of Symbols (variables and entities) of all static bound dynamic linked libraries
- Initialization of all static data segment in exe and dll of process
- Installation of default error handler (see errorsys.prg)
- Execution of process I/O sub system (see appsys.prg, console, gui, hybrid, stream)
- Load of default DatabaseEngines (see dbesys.prg)
- Execution of all INIT procedures
- Execution of PROCEDURE MAIN()
The good
- You do not need to maintain an explicit startup/init of your module.
- Add on library vendors can hide Initialization and automate library startup/init. Which makes library usage simpler
The bad
When executing code in your errorsys, appsys or dbesys always keep in mind INIT procedures are not executed until yet so you need to avoid to use "high level" features.The order of INIT procedures is implicit, so you can not count on having a module A available in the execution of your INIT PROCEDURE of module B.
Okay and then
To control ordering of INIT procedures you can use INIT2 and INIT3 to group init procedure executíon, The Xbase++ runtime executes init procedures in 3 levels. INIT1 is reserved for Alaska Software usage only and runs before all other INIT procedures. INIT2 shall be used by add on vendors and INIT3 is where anything can go. This way some sort fo order between init procedures can be established and maintained.Well the idea of INIT procedures is from Clipper and has its roots in a procedural / module oriented world. Since Xbase++ comes with a fixed typed and prototype based Object Oriented programming model we already can package and organize functionality much more better than in the past. Remember a procedural module if designed well compare very good to classes.
Since the Xbase++ OOP Engine also provides the concept of classes - the factory of your objects - it is a good idea to put all your init code into the
- :initClass() method of your class. However in case of an error you need to raise an runtime error since initclass is called implicit. You also need to call :initclass() of your parent classes to ensure proper initialization of them.
- Implement a constructor, instead of using :new() for instance creation. Just add a CLASS METHOD Create(), do the initialization inside the class method, if it fails return NIL no object could be created since the init of your class failed, or simple create the instance with self:new() and return it.
Notes:
- In theory you could use :init() to perform the initalizaiton of your module/subsystem but that would be practically wrong for two reasons. #1, :init() is the called for each instance creation so your are at the wrong place and #2 to avoid repeated initialization you need to add logic code to avoid repeated execution.
