Widcomm bluetooth : how to open the virtual COM

Question

i\'m trying to use the Widcomm bluetooth stack by Broadcomm and it should work but there\'s one thing that still i cannot understand: HOW CAN I AUTOMATICALLY OPEN THE VIRTUA

Answer 1

I posted a response to this earlier but it seems never to have appeared! :-(

Anyway, I'm the maintainer of the 32feet.NET library and the author of the Widcomm support. Firstly, as far as I know the license should not be a problem for commercial distribution. See Peter Foot's comment at http://32feet.net/forums/t/2289.aspx:

"32feet.NET is free for commercial or non-commercial use. If you use the binaries you can just use the library as-is, if you make modifications to the source you need to include the 32feet.NET License.txt document and ensure the file headers are not modified/removed."

I'll see if Peter can post a comment here to give certainty.

Anyway, we haven't implemented support for the Widcomm virtual COM port functionality, (its certainly possible though no one has asked for it -- apart from yourself). I'm not a big fan of virtual COM ports. It always seems much easier to use a direct 'sockets' connection, rather than attempt to setup a COM port, and try to find what name it was created as[1], and then have to open a SerialPort to use it, and then if the connection is lost one doesn't know and have simply to keep retrying... Its so much easier just to do the following:

Dim addr As BluetoothAddress _
  = BluetoothAddress.Parse("001122334455")
'
Dim ep As New BluetoothEndPoint(addr, BluetoothService.SerialPort)
Dim cli As New BluetoothClient
cli.Connect(ep)
Dim peerStream As Stream = cli.GetStream()
peerStream.Write/Read ...

See more at http://www.alanjmcf.me.uk/comms/bluetooth/32feet.NET%20--%20User%20Guide.html

To answer your specific Widcomm questions. Multiple instances of a Bluetooth service can be created, i.e. multiple SPP services (each using the SPP Service Class Id), each can supply a Service Name attribute to allow clients to select between them. In most cases it won't be necessary, so just pass null or zero-length string -- the Widcomm SDK docs don't say what's allowed. As to the Window handles, Widcomm uses C++ virtual methods (yuk -- this makes direct P/Invoking mostly impossible) to implement events/callbacks, presumably Mr Figueira's code converts those callbacks into Window messages.

[1] Creating Bluetooth virtual COM ports is not straightforward. On MSFT+Win32, one isn't told what name was selected for the COM port! On MSFT+WM the official API doesn't work well on many device types. And our unofficial method of doing it requires a reboot IIRC. :-(