WinWrap® Basic is an embedded macro language component available for .NET and COM 32/64 bit Windows applications. The WinWrap® Basic Component is an alternative to Visual Basic for Applications VBA, ActiveX (e.g. VBScript, JScript, PerlScript, Rexx-based WSH engines and others), and VSTA for this purpose. The WinWrap® Basic Component is compatible with VBA, Sax Basic, VB.NET and Visual Basic 6.0 style scripts.
Control and Debug a server or remote application's scripts. The Synchronized Property, Synchronize Method and Synchronizing Event (OnBasicSynchronizing Callback) work together to add remote control to WinWrap® Basic.
Adding WinWrap® Basic Scripting to your .NET and COM 32/64 bit Windows application adds powerful end-user and field scripting capability. Whether configuring a deployed application, or providing end-user scripting for application specialization, WinWrap® Basic will add powerful capabilities to your application.
Assume that you have a BasicNoUIObj object that runs script code in a service. Let's call that the "engine". To remotely control the engine you'll need a BasicIdeCtl in the GUI of a Windows Application. Let's call that the "debugger". Remote control allows the debugger to view engine code, set engine break points, single step and run the engine from the GUI.
Both the engine and the debugger must have their Synchronized property set to True. The script execution in the engine is unchanged by the Synchronized property. However, the engine will fire a Synchronizing event whenever the engine needs to inform the debugger of a state change. The description of the state change is encoded in the Params parameter of the Synchonizing event. That data must be passed to the debugger's Synchronize method. This is what causes the debugger's state to track the engine's state.
Likewise, the debugger will fire a Synchronizing event whenever it wants to control or query the engine. Similarly the Synchronizing event's Params data must be passed to the engine's Synchronize method.
By exchanging information using the Synchronizing event and the Synchronize method, the debugger can control engine and track engine's state changes in the debugger.
Getting the Synchronizing data to the other's Synchronize method requires some form of remote procedure call. COM, COM+ or a TCP/IP connection are some possibilities. If you already have a connection between your the debugger's host application and the engine's service, just use that. Be sure to pass the Params and Id parameters unchanged between the Synchronizing event and the other's Synchronize method call.
WinWrap® Basic uses a lazy form of synchronization. When the Synchronize method is called, the action is posted to the thread's windows message queue. The action will take place after the Synchronize method returns. So, don't expect the debugger and the engine to be in complete lockstep. This is a good thing, because the connection between the two might be slow.
Multiple debuggers can control the same engine. As long as every debugger receives the same engine Synchronizing data everything will work fine. (The debuggers are not aware of each other directly, but because they all receive the same state information from the engine they all display the same state.)
The reverse is not true. A debugger can not control more than one engine. However, a debugger can switch from one engine to another different engine. Just set the debugger's Synchonized property to False change the connection and then set it back to True.
Debuggers and engines can be in the same process. They can even be in the same thread, however, more than one engine per thread can lead to execution dependencies (try to avoid that).
Debuggers and engines can be in different types of applications. For example, a .NET debugger can control a COM engine.
Copyright Polar Engineering, Inc.
© PolarEngineering®, Inc.