Image of Navigational Panel mapped to Home / Conetnts / Search Bringing VB Declares to Toolbook

by Mark Trescowthick - GUI Computing
Image of Line Break

With the advent of ToolBook 4.0, it's now possible (though not always easy) to use VBXes with ToolBook.

This is certainly a step forward, and my first thought was "Great, at last a Grid!". Well, sort of - TrueGrid doesn't actually want to work with ToolBook (even Gary Wisniewski couldn't get it to do so...), but Formula One and Spread/VBX seem only too happy to, after a fashion. The fun you can have getting them to do what you want is the subject of another article in this issue.

But, of course, to use any of the advanced grids you need to make numerous DLL calls as well as simply setting VBX properties. Now that's easy for VB programmers - just include the appropriate .TXT or .BAS file and away you go. But for ToolBook use, all those declares need to be converted. Formula One alone has 256 declarations.

At this point it was definitely time to write a small applet.

I chose the approach of allowing the user to paste the VB declarations into a field, then unpicking each line and creating a ToolBook-style LinkDLL command in a second field (actually a recordfield, as you will see below).

Let's use this declaration as an example throughout:

Thumbnail linked to Convert 1.0 Snap
Thumbnail of Convert 1.0
Image Size = 18 KB

  Declare Function SSAddColPageBreak% Lib "VTSSDLL.DLL" (ByVal hSS&, 
                                                         ByVal nCol%)

We'll turn this into the following ToolBook structure:

  LinkDLL "VTSSDLL.DLL"
    INT SSAddColPageBreak (LONG, INT)
  end LinkDLL

Step One...

Unpick the first line - to discover which DLL it was that I was linking. The fifth word of the VB declaration will always be the DLL name, so after unpicking that I now have the basis of the LinkDLL structure.

  get textline 1 of text of src
  dllname = fifth word of it
  put "LinkDLL" && dllname & CRLF into text of tgt

Now the fun begins.

Step Two...

Get the return type expected.

First I extract the line to be processed, then I check that it is in fact a declaration for the correct DLL. By checking the last character of the third word of the line, I can determine what type of return is to be expected. I then insert the appropriate ToolBook return type.

  workline = textline i of text of src
  if fifth word of workline =	dllname then   ' Skip if not the right DLL!
    get third word of workline
    conditions
    when last character of it is "%"
      clear last character of it
      put tab & "INT" && it after text of tgt
    when last character of it is "$"
      clear last character of it
      put tab & "STRING" && it after text of tgt
    when last character of it is "#"
      clear last character of it
      put tab & "DOUBLE" && it after text of tgt
    when last character of it is "&"
      clear last character of it
      put tab & "LONG" && it after text of tgt

This looked to be getting easier by the second. Obviously I'm only handling the four basic types here, but you can see how easy it would be to expand upon.

Next, of course, I ran across a Declare Sub rather than a Declare Function. Here there is no return type, but ToolBook requires one. I have decided to opt for a STRING return, but you may decide to take alternate action.

I now need to handle those types I wasn't expecting. My approach here is to include an UNKNOWN in the declaration, along with the character that caused the pain. At least I can now identify what is causing any problems which do occur.

  if second word of workline is "Sub" then
    put tab & "STRING" && it after text of tgt
  else
    put tab & "UNKNOWN - " && last character of it after text of tgt
      clear last character of it
      put " " & it after text of tgt
  end if

Step Three...

Parse the parameters.

I actually thought this was going to be a real pest, until I realised that once you strip away the parentheses it looks just like a standard ToolBook comma-delimited item list. This made things positively easy, and certainly very standard. The only real trap was to be on the lookout for ByVals and ByRefs, and to ignore them. I handled unknowns as I previously did for the return value portion of the parsing.

I also decided that, as ToolBook would "lose" the parameter names, I'd include them as comments.

  clear txtComment
  txtComment = "-- "
  step j from 1 to itemcount(workline)
    get item j of workline
    if first word of it is "ByVal" or first word of it is "ByRef" then
      get second word of it
    else
      get first word of it
    end if
    put it after txtcomment
    clear last character of txtcomment
    put ", " after txtComment
		
    conditions
    when last character of it is "%"
      put "INT, " after text of tgt
    when last character of it is "$"
      put "STRING, " after text of tgt
    when last character of it is "#"
      put "DOUBLE, " after text of tgt
    when last character of it is "&"
      put "LONG, " after text of tgt
    else
      put "UNKNOWN - " && last character of it && ", " after text of tgt
    end conditions		
  end step	

Now all that remains is to write the 'End LinkDLL'.

This worked just fine (with both source and target fields on the page), until I came to a significant number of declarations. As is (too) often the case, I quickly found I'd run out of room on the page. I know it's just a matter of a 'Save As' a new name to compact the book, but frankly I didn't feel like that much effort.

I ended up by simply moved the field we're creating text within to the background, which effectively doubles my available memory on the page. In fact, it got a little more complex than that when it came to copying the text to the clipboard, but I'll leave that story for another day.

The book is available for download (14Kb)... enjoy.


Written by: Mark Trescowthick
April 96

Image of Arrow linked to Next Article
Image of Line Break
[HOME] [TABLE OF CONTENTS] [SEARCH]