Toolbook is a perfect development environment for quick creation of applications with functionally rich interface. Bult-in scripting language is as powerful as Visual Basic. Ability to use third parties' ActiveX Controls and DLLs makes the range of the tasks doable in Toolbook almost unlimited. The only drawback I see in Toolbook is its age. The core of Toolbook is still 16 bit and hasn't changed significantly since the times of Windows 3.1. Of course, the situation may change with the release of Toolbook 9.0 which is supposed to be 32 bit. But now the only choice left to us is run 16-bit applications on 32-bit operating systems and using their Virtual DOS machines. In most cases this is quite sufficient and Toolbook applications are quite workable, but everything changes when you are trying to link 32-bit OCXs or DLLs.

Except the very simple libraries or OCXs, Toolbook becomes very unstable. Calling external 32-bit dll or ActiveX control within Toolbook very often crashes system producing internal GPF errors. So the actual list of 32-bit libraries and controls fully compatible with Toolbook is very short.

The internal cause which leads to these errors is the following: many of the 32-bit libraries can't work in the same memory "thread" as ToolBook. The possible solution to avoid the conflict between 32-bit library and VDM is to run VDM and Toolbook and 32-bit library code in DIFFERENT threads. This will lead to extra efforts in programming both in OpenScript and in some of the languages supporting the development of 32-bit applications, for example VB, C/C++, Pascal, etc, but make the configuration stable. In other words you shouldn't link DLL with linkDLL32 statement or link OCX within Toolbook. You run all 32-bit code as a separate application-wrapper.

Shortly the workaround is the following

1. You write in VB or C/C++ 32-bit application, that links DLLs or OCX..
2. Having in mind DLL/OCX functionaly you develop a special bidirectional interface between wrapper and host Toolbook application. The most convinient way of doing that is Windows Messaging system, i.e. SendMessage() function. In both cases messages are sent to the windows, so to make messages deliverable applications need to exchange HWND values.
3. To hide wrapper from the Windows Task Bar you can use a very simple trick. Make the wrapper main window the child window of ToolBook. To find API functions for doing that refer to API help.

I used this scheme several times and it proved to be quite reliable when any other method or endless experimenting with 32 bit libraries failed.

The only problem encountered on this way were system crashes on attempts to send pointer as a parameter . Very often this happened when you needed to pass a string as a parameter of SendMessage() function besides sending a simple DWORD value from one thread to another thread was safe. Thus if your library implies using STRINGs or STRUCTUREs as a parameters or return values you need another methods of exchanging information between applications. These methods are:

1. Using data or ini files stored on a hard disk.
2. Implementation of special sequential protocols for sending information.

If you have questions about the details of developing such hybrid applications feel frre to email me.