   COM OpenGL C++ and VB
  I am planning to write a 3d engine in C++ with OpenGL, and the client required it to be able to be used under VB. Does this means that I have to make it into a COM object? I am rather weak in COM programming and thus can anybody suggest an alternative?I am not planning for .NET yet because the client doesn''t know VB .NET...Thanks in advance for the help guys 
  If the only requirement is that it can be used from VB, then your engine could be developed as a Windows DLL, exporting a C function based API (much like the WINAPI).The problem with function based APIs is that the client will end up passing a lot of handles around as the first parameter of the function, in order to tell the function which object to work on (much like the WINAPI e.g. hWnd, hDC, hFont).If the client wants to use VB and have a more object-based API, then since VB''s object model is COM, you will have to provide a COM API.  This can either be done in C++ (which you don''t want to do), or an alternative is develop the C DLL as before, and then wrap this with a VB object layer (COM objects are pretty easy to implement in VB because VB''s natural object model is COM, COM objects are more difficult to implement in C++ because C++''s natural object model is C++).  This way your engine could comprise of a C/C++ DLL (the majority of the engine, exposing a C function based API), and a VB ActiveX DLL (which acts as a thin object-based COM layer on top of your function based engine). ;  abstractworlds, I am interested in knowing more about wrapping C++ DLLs with VB. I am not sure how it works though. Can you give me some pointers? Do you mean writing a VB module to wrap over the C++ functions that the DLL provides and then when the client is using the program, he/she will just use the functions provided by the VB wrappers?will this compromise the performance of the C++ DLL? Since I am writing a 3d engine for a simulation I am concerned that by doing it this way the engine''s performance will drop... ;  The C++ DLLs must be standard Win32 DLL and can only expose C based functions to VB (like WINAPI), you cannot expose C++ objects or properties to VB.You then write VB class modules to provide an object based layer, and yes the client uses these VB objects.As an extremely simple (and non-practical) example, if you wanted to wrap the WINAPI MessageBox function (which is in the Win32 DLL called user32.dll) with a VB object layer, here's what you could do:1. Open new standard exe VB project2. Create a new VB Class called CMessageBox and enter the code: Private Declare Function MessageBox Lib "user32" Alias "MessageBoxA" (ByVal hWnd As Long, ByVal lpText As String, ByVal lpCaption As String, ByVal wType As Long) As LongPrivate Const MB_OK = &H0&Public hWnd As LongPublic Contents As StringPublic Caption As StringPublic Sub Show()    Dim lRet As Long    lRet = MessageBox(hWnd, Contents, Caption, MB_OK)End Sub3. In the main form's click event enter the following code to use this object:    Private Sub Form_Click()    Dim oMsg As New CMessageBox   With oMsg   .hWnd = Me.hWnd   .Caption = "Hello"   .Contents = "Fred"   .Show    End WithEnd Sub What you have done here is created a VB class and form using this class in the same standard exe project.  You could also place the class in an ActiveX DLL VB project, or ActiveX OCX VB project.  Of course you don't have to do everything via properties and methods, you could have multiparameter functions or methods in your class instead.In terms of performance, I did something similar a few years back. This was before there was a DirectX interface to VB, so I wrapped DirectX in a Win32 C DLL, and then wrapped the C DLL with a VB object layer.  I didn't see any major performance degradation, performance was fine for what I was doing (Close Approach - a first person 3D asteroids shooter).  In fact I'm still using this engine/architecture today.   [edited by - abstractworlds on February 4, 2004 8:03:04 AM];  thanks a lot abstractworlds. I''ll work it it immediately.  ;  My pleasure.When you start coding your own Win32 DLLs to be called by VB, a common issue you may run into is function name-mangling, that is the function names in your DLL are changed to something different when exported.  You could do a google search on DLL Name mangling C VB for more info, and this subject has also been discussed on gamedev threads.