Faq and documentation                                
Customer Information
    Licensing
     
Partners
    PaxScript
     
Product Information
    Downloads
    Features
    Screenshots
    Documents
     
Product Tutorials
    Overview
    How to Install
    How to embed
    Code Repository
   
   
   
   
   
   
   

How to embed PaxDebugger into applications.

PaxDebugger can easy be embedded into existing application.
It's just a matter of few mouse click:

  • Put PaxDebugger component into the application main form (or in the main datamodule that contains application logics).
  • Put language components (TPaxLanguage) in the same form (or datamodule) used in the previous step.
  • Select PaxDebugger component and from Delphi object inspector set DebugMode=TRUE, ShowToolbar=TRUE, ShowMouseEvaluationHint=TRUE, ShowToolBar=TRUE, VISIBLE=TRUE. Then choose a default language.

Now application is scriptable through PaxScripter/PaxDebugger, so run it.
Take a look into visual settings; form 'File' menu click on 'Debugger settings' and lets have fun with settings.
As pointed in the Overview tutorial, PaxDebugger works on projects. Projects can reside on file or on database, lets talk about these two options.

Project on file
A file-based project can be inserted in two ways:
  • Using the IDE: from 'File' menu you can choose to create a new file-based project ('New project' item) or load one from file ('Open project' item). In the first case a project name will be requested to the user.
  • Not using the IDE: PaxDebugger component has two public methods, NewProject and OpenProject. OpenProject needs a filename parameter, that specifies the filename of the project being loaded. NewProject method need a project name, and a flag that tells to PaxDebugger if project will reside on file (TRUE value) or on database (FALSE value). We're working on file-based project, so we have to set a TRUE value for this flag.

Every module will be saved on a single file, that will contain the code text. Filename is given by <ModuleName>.<LangExt>, where LangExt is a file extension that depends on (pax)language used for the module. The project file, that will have a .pax extension, is in XML format, and contains groups and their modules relations. Here's two examples on how file-based project can be inserted without using IDE (so using PaxDebugger methods):

procedure LoadProjectFromFile1;
begin
  PaxDebugger.OpenProject('c:\Projects\TestProject.pax');
end;



procedure LoadProjectFromFile2;
begin
  PaxDebugger.NewProject('TestProject', TRUE);
  // now modules can be added using AddModule method
end;
      

Project on database
A db-based project can be inserted only via PaxDebugger component. This means that IDE is unusefull for this type of task. Lets have a see of a typical application that uses PaxDebugger with a db-based project:
procedure OpenDBProject;
var
i, recsCount: integer;
record: <RecordClass>;
module: TPaxDebuggerModule;
begin
<Open database>
recsCount := <GetRecordsCount>;
PaxDebugger.NewProject('TestProject', FALSE);
for i := 1 to recsCount do begin
record := <ReadRecord_FromDataBase>;
PaxDebugger.AddModule(record.ModuleName, nil, module);
if (Assigned(module)) then
module.SourceCodeText := record.CodeText
else
ShowMessage('PaxDebugger cannot add module');
end;
<Close database> PaxDebugger.ImposeProjectLoaded;
end;
Specific database stuff (open db, read records and close db) is left to the application; it may be, for example, an ADO connection or a ODBC one. PaxDebugger is used to create project, add modules and assign code for each inserted module. The second parameter of AddModule is a TPaxLanguage class; if nil is specified (like in the above example), the default language will be used.
The call to ImposeProjectLoaded is necessary to inform PaxDebugger that the project is completely loaded. In the case of file-based projects, this call is not needed.

Once a project has been created or loaded, IDE can be used to debug procedures, move modules, create new groups and modules, edit code and so on.
A project can be saved using the 'Save project' item from 'File' menu, or through the PaxDebugger SaveProject method. The result is exactly the same. If the project was on file, everything goes ok, but if it was on database, how can application know that project and modules are being to saved? Events are the answer.

Use of events

PaxDebugger component is rich of events. For a complete list, click here.

For a basic embedding, save events are the ones important.

  • OnBeforeSaveProject: this event is triggered when a project is being to be saved. Using the second parameter, the host application can do some pre-checks, and if they fail, can stop the save process.
  • OnAfterSaveProject: this event is triggered when a project has been saved, so the application can do some post-processes.
  • OnSaveModule: this event is triggered when a module is being to be saved.

When a project is saved, the event chain is as follow:

  • OnBeforeSaveProject: if this event stops the saving process no other events are triggered, else
    • For every modules in the current project, an OnSaveModule event is triggered
    • OnAfterSaveProject

Here's a typical OnSaveModule event implementation (usefull for db-based projects):

Procedure PaxDebugger1OnSaveModule(Sender: TObject; const Module: TPaxDebuggerModule);
begin
  if (Module.NeedSave) then begin
    <Save module informations to a database record>

  end;
end;
      

The NeedSave property of TPaxDebuggerModule class, can be used to check if the module has been changed. A module is considered changed if:

  • Its code has been changed, or
  • Its group has been changed, or
  • Its group has been renamed

This information can save several db update operations.

 

 

 
  24 Nov 2004: PaxDebugger 1.3 is out ...
  8 Apr 2004: PaxDebugger 1.0 is out