Debug Custom Module

To debug an custom Module, you basically set up the command line and current directory of your debug
target the same way as if it would have been started by the Communication module itself.
You then run the Debug target and it will react the same way as if it would be started during runtime.

Prepare VisXpert

  • Register your Custom module to VisXpert using any of the methods of registering an module.
    You must register your module type once before running VisXpert.
  • Start or Restart VisXpert. VisXpert will check the registered modules only during startup.
  • Add your newly registered Module to an VisXpert Project where you will do the Debugging.
    You will need your Module to be present in the current VisXpert project, otherwise VisXpert
    will reject all communication requests.

Prepare Visual Studio

  • Set the current directory of your debug Target to the “bin” directory inside the directory
  • where you have installed “VisXpert”.
    this is usually “C:\Program files (x86)\VisXpert\Bin”. You can adjust this in your Visual studio
    Project settings.
  • Set the Commandline to an valid commandline that it would get as if it where started from the
    VisXpert Communication module. For more information on how to do that, please check the appropriate section.
  • Run Application in Debug mode. Set Breakpoints debug your module as needed.

Command line

When VisXpert starts an Configured module, it passes Command line to the module, that contains multiple
pieces of information that the Module will need to make an connection to the Communication module.
The Command line arguments are:

  • /N=”Module Name” : Each module is identified by its Modules name.
  • /T=”Module Type” : Each module also has an module type
  • /A : if the Module is an “Runtime” module
  • /E : If the Module is an “Editor” module
  • /P=”Module Config Directory” : This is the directory where the module can store and read its configuration from

For example you an Commandline would look something like the following.
/N=”MessageView 1″ /T=”MessageView” /A /P=”D:\Temp\Austral\Visu\Austral\Message1\Message2\”

The Module name is the name that the your module has in your test VisXpert Project.
The Module type is the Type under which you have registered you Module in VisXpert
The directory is an subdirectory inside the project directory, that is assigned by the VisXpert Communication Module

What to be aware of

when you are communicating with VisXpert, you are using resources of VisXpert.
When you “Stop” debugging from visual studio, the Debugged process gets “killed” immediately, without being
given an chance of freeing any resources.
No Finalizes, disposed event handlers or other Handlers will run if you just “Stop” debugging.
You should properly close your Module to stop debugging. Repeatedly starting and stopping debugging from
Visual studio, can cause instabilities in the VisXpert communication module.

Another thing to be aware of are Tim outs. If you have set an Breakpoint in certain functions, the whole
process will be “frozen” while you are examining the
breakpoint. This also means, that nothing will send “Life Messages” or “Acknowledges” to the Communication module,
possibly causing Timeouts. Keep that in Mind
when setting Breakpoints.

Print Friendly, PDF & Email