DiscoverDevicesAsync and changing radios

Topics: Bluetooth - Microsoft
Jul 9, 2012 at 8:24 PM

I am attempting to "chain" calls to DiscoverDevicesAsync, so that I always have one call pending.  Should I be using the same BluetoothComponent for subsequent calls, or should I be creating a new one each time?

As currently implemented, I am re-using the same component and I'm having trouble with handling changes to the hardware.  Essentially, I haven't found a good way to know when the radio the component is referencing is no longer available.  If I pull the primary and add/leave a secondary radio, it behaves exactly as I would expect if it were functioning in an environment with no discoverable devices.


I am using the Microsoft stack on Windows 7 64 bit in a 32 bit process.

Jul 9, 2012 at 10:40 PM

It looks like new BluetoothClient() only throws PlatformNotSupported Exceptions until it succeeds once, and subsequent calls will fail to throw the exception even though the hardware has been removed.

This can be reproduced by plugging in the radio, calling "new BluetoothClient()" in a loop, removing the radio, and not seeing an exception thrown.

How do I properly handle discovery with changing hardware?

Jul 13, 2012 at 12:42 PM

Hmm. Good question! Its not something I test for.  When BluetoothClient is created we create a new Bluetooth winsock socket, so apparently its not reporting the missing radio either. I'll check if there's something we can here.