Calling an Open Watcom DLL From Visual Basic
From Open Watcom
←Older revision | Newer revision→
This tutorial is right now a subset of Visual Basic Integration. Being I plan on writing a series of tutorials on using Open Watom DLLs with other languages (ok just C# and maybe VB.NET if I'm adventurous. I'd decided to modularize this tutorial. At the moment I will keep the original tutorial in tack.
1. Open up Visual Basic. I have not included any screenshots here as I assume you have programmed in Visual Basic, and there is but one IDE for Visual Basic development. Open up a new standard EXE project. At the bottom of the form place a button. Name it cmdCircle and give it a caption of &Circle. Go to view code and paste the following:
Private Declare Sub DrawOval Lib "zippy.dll" Alias "_DrawOval@20" _ (ByVal hwnd As Long, ByVal X1 As Long, ByVal Y1 As Long, _ ByVal X2 As Long, ByVal Y2 As Long) Private Sub cmdCircle_Click() Dim hwnd As Long hwnd = Me.hwnd DrawOval hwnd, 10, 10, 100, 100 End Sub
Time for a little discussion here. You might be wondering what that Private Declare Sub jibber jabber is all about. This is how you tell Visual Basic to use the function _DrawOval@20 in the DLL zippy.dll when you make a function call to DrawOval. The compiler "Name Mangles" the DrawOval function with the _ and the @20. Why it does this will be discussed in a future tutorial. The rest of the Declare Sub call is simply a parameter list. If you look at the parameter list, there are 5 parameters that are each 4 bytes wide. This is the reason for the @20. If you were declaring a function you would also add the size of the returned value.
Important note: If your function has a return value, the size of the return value gets included in the @[n]. Eg: Private Declare Function foo Lib "bar.dll" Alias "_Foo@4" () As Long
There is a way to remove name mangling from the DLL. This means that you do not have to include the Alias "_DrawOval@20". This is done through compiler flags and will be discussed in the next tutorial. Also, passing strings and structures between a VB program and a C DLL requires extra considerations that I will not cover here.
2. Compile the Visual Basic project. Make sure both the EXE and the DLL are in the same folder. Run the EXE. Your results may vary due to the size of your window.