Hi,
I have a legacy application that uses a 3rd party serial com port connection. Currently, if we manually pair a bluetooth device, we can go into windows bluetooth manager and visually see which com port it is using and manually connect to this com port. This method does work, but we want it to be automatic.
I am using the WCL to automatically determine which com port is being used by the bluetooth device of my choosing and to pair a new device.
I have read several posts where you strongly recommend that we not use 3rd party devices to communicate with bluetooth devices; however, we have found that the latency we are able to achieve using our 3rd party device code is able to achieve ~15-20mSec latencies reliably while using the WCL Client can only give us ~25-25mSec latency. Therefore at this time, we must continue to use the legacy method.
I wish to make it so we can eliminate the manual process for figuring out the virtual com port that windows is using. As it is now, I can create a virtual com port in WCL, and get the com port in the wclVirtualCOMPortAfterOpen(TObject *Sender, DWORD Port, int Error) event using the C++ builder XE version.
Unfortunately, once I create a virtual com port, it appears that the port is held by the WCL. If I close the port, it doesn't just close the com port, it un-pairs the device. If I don't close the port, the port is closed for me when I unload the WCLApi... and the device is unpaired.
I am testing on Windows 7 and my computer uses the microsoft blue tooth stack.
Any help would be greatly appreciated. I love your library. It makes it possible to deal with the chaos of windows bluetooth.