Hi

If a bluetooth sensor is not found i keep searching for it using the following line of codes

bluetoothClient.BeginDiscoverDevices(255, false, false, false, discoverableOnly, new AsyncCallback(HandleDiscoverComplete), null);

Then i have the following to capture the result of the bluetooth search

private void HandleDiscoverComplete(IAsyncResult ar)
{
BluetoothDeviceInfo[ devices = bluetoothClient.EndDiscoverDevices(ar);

.......
}


On a widcom phone the handler is called exactly once but any subsequent calls executing bluetoothClient.BeginDiscoverDevices will never result in the handler being called. I read up on your document but it is not clear to me that this is a know problem or not for widcom. Should i explicitely close the bluetoothClient on each call of bluetoothClient.BeginDiscoverDevices?
Cheers Peter

I did some more testing by closing the bluetoothClient after a search has completed but that does not solve the problem. I tested my code on a Microsoft stack and it works like a charm. It must be a Widcomm thing.. peter

I keep testing and i got a bit closer to where the problem might be. If my app doesn't find the sensor it will immediately search again for bluetooth sensors. So in my code in the HandleDiscoverComplete(...) method i call straight away
bluetoothClient.BeginDiscoverDevices(255, false, false, false, true, new AsyncCallback(HandleDiscoverComplete), null);

This is not a problem for a Microsoft stack but somehow with Widcomm it gets blocked. Is there a way to solve this for widcom?

thanks

peter

Remind me what platform this is on, because on testing this I see no problems on my WM device.  How does it fails for you?  It never returns?

However Widcomm seems to get confused quite easily, and forgets to call the 'discovery completed' event.  I've implemented code since 2.5 to complete the device discovery after a timeout.

Hi, I wrote a small test program where you can see for yourself where it goes wrong. This test program looks for bluetooth devices non-stop. It works perfectly for a Microsoft phone (HTC Touch HD or any other microsoft bt stack phone) but it only works once for any widcomm phone (I tested it on an old ASUS P735 and the latest HTC HD2).

You can download the project (zip) here

http://personalheartmonitor.com/download/WidcommTest.zip

Curious to hear why it goes wrong.

Cheers Peter

OK, I've just realised that because I'm testing from repository I have the BtCli.InquiryLength timeout in operation (bug 26094) so DiscoverDevices will never hang for me. :-,)

I'll test with a long timeout and check in the debugger what's happening.  I've also to test other operations (Connect) from within the discovery callback.  I think I'll end up raising all user callbacks on a new thread-pool thread in case Widcomm's not happy with us doing things from their callback threads.

OK I have committed a change that raises the DiscoveryDevices and GetServiceRecords callbacks on a thread-pool thread.  So we now stay far away from any (undocumented :-)) Widcomm reentrancy issues.  Both [Begin]DiscoverDevices and [Begin]Connect now always work in those callbacks.

Happy to test. it how do i get the latest dll? I downloaded the latest build but it seems not to have a dll included? Do i need to recompile the whole lot to get the latest DLL? peter

You just need the WM library, so ignore everything but the InTheHand.Net.Personal.CF2 project in the root.  It will compile as Debug no problem, so you can use that.  (To compile as Release, comment out the AssemblyKeyXxxx lines in Properties/AssemblyInfo.cs).

It'll be good to get confirmation that it is fixed. :-)

Hi YES it works beautifully now. Thanks a lot. It really was a show stopper for my application. Thanks! But as usual another feature request :-). With my bluetooth sensors some need to be paired with the phone. With microsoft stack you can do this programmatically (SetPin). It would be really nice if we have that same feature with widcom. It is so annoying that you get a pop-up asking to pair the sensor. What are the changes to realise this? Cheers Peter

Good stuff.

Unfortunately the support for handling authentication is quite poor in the Widcomm API.  Unlike in the two MSFT stacks there is no authentication required event or callback.  Presumably that's the case you wanted to handle.  As discussed in the Widcomm doc in the release we try to handle BtCli.SetPin, but it probably the dialog will pop-up before we get to try and call Bond.