by Stephan Grieger - GUI Computing
The problem that a lot of developers have (myself included) is that once we learn a language we tend to stick to that platform - no matter what the application is. In fact, we actually try to go against the limitations of the language to try and make it fit the specification. This invariably leads to problems and elaborate workarounds to workarounds. We become pigeon holed so to speak.
On a recent application, we needed to develop an interface which would allow the user to view a certain form on the page, exactly as it would appear on paper. They then needed to enter information onto the form, be able to print it, save it, etc. Added to that was the need for the user to be able to design their own forms, save and use.
Initially we decided to go with Visual Basic all the way, creating a form's design and control engine with VBX support, etc. The problems associated to this were immense, to the point where they were almost insurmountable. Then we hit upon the idea of using ToolBook, designed specifically it would seem for this exact task - and expected to save us a lot of time and pain. Now the only thing left was how do we get our Explorer (related GUI Explorer article to be included in the next issue of AVDF) to talk to our ToolBook application. DDE?
DDE is one of those things that I try to avoid when possible. Unfortunately, this application required both Visual Basic and ToolBook platforms - which then needed to communicate. The only reliable, if you can call it that, method was DDE.
Now, DDE between two Visual Basic applications is an easy thing, however ToolBook handles DDE in a slightly different fashion, and the way that Visual Basic initiates the DDE conversation is not exactly what you would expect.
In a standard Visual Basic to Visual Basic DDE conversation you need to specify three things: the Link Topic, the Link Item, and the Link Mode.
The Link Topic is generally the Application name followed by the name of the form to receive the DDE conversation, separated by a pipe character. The Link Item would then be the field name, which was to be the target of the DDE message.
In the case of ToolBook, however, we were unable to link directly to a field on the window. The solution was then to use the LinkExecute method - to pass a message directly to the background of the ToolBook form. In this case, the LinkTopic was "ToolBook", followed by our executable name, separated by a pipe. The LinkItem was the name of our executable again.
Once you have the conversation established, via Visual Basic, you generally alter the contents of a field on the screen. The field in turn will look at what was passed across and respond accordingly. In our ToolBook application we were unable to do this, and as a result needed to send a message directly to the Background of the Page. From Visual Basic we set the LinkMode = vbLinkManual.
So our code, in Visual Basic, now looks like this;
lblTBKDDE.LinkTopic = "ToolBook|GUI.Exe" lblTBKDDE.LinkItem = "GUI.Exe" lblTBKDDE.LinkMode = vbLinkManual
This establishes the DDE link between the two applications. Now whenever we want to send ToolBook a message, all we need to do is the following;
lblTBKDDE.LinkExecute "Send MyMessage" & Param1 & "," & Param2 & "," & Param3
At the other end we have;
To Handle MyMessage Param1, Param2, Param3 Addition = Param1 + Param2 + Param3 End
So what we did, in effect, was execute a ToolBook message from within Visual Basic.
This method had far more advantages than setting the text of a field on the page. To begin with it eliminated the need to have a hidden field, which then checked itself and executed multiple routines depending on its contents. We could then execute a direct command and pass across parameters as though the routine were a part of Visual Basic. Very neat. In fact, had we needed to, we could also control the grid VBX within the ToolBook application, directly from Visual Basic itself (refer to article Using VBX's in ToolBook 4.0).