> > Can you explain this a bit more? Should we not prefer the deviceLabel IF > we can get it? >
When I created that patch I thought that it would be better to use only the device address to identify if the device is already in the list. This is due the fact that currently the pattern of the deviceLabel is *$deviceName ($deviceAddress) $pairingStatus *. There are moments when the device name is missing and moments when the pairing status is different. Now if I think more clearer if we don't update the devices state it would lead to some inconsistent states. Probably it would be a better idea to clear the list with the discovered devices when a new device lookup is initiated. In this way we will show only the devices that are in range during the last scanning. If you agree with this I can send you another patch. > > b) did you write all this from scratch or was this inspired by some > existing BT code for Windows from some other project? This is a > non-trivial chunk of code in an area I'm not very familiar with... > (and just to avoid email communication issues - no, I'm not doubting that > you wrote this code... I just want to make sure that if there is a source > we should credit that we do). > The code is written from scratch but I used two sources of inspiration: - for the implementation of our custom serial callbacks I looked over the Native bluetooth communication sample created by Jef - for the device lookup I looked over a sample[1] provided by Microsoft Corporation to demonstrate how to use Winsock 2.2 Api and RFCOMM protocol I didn't know where I should mention them :) . While Jef is probably already mentioned for his help I am not sure if Microsoft should be mentioned when you get inspiration from one of their samples. Also you should know that our custom serial implementation is based on the native serial implementation provided by Jef (the design). I thought that it is obvious but I just wanted to be clear :). Claudiu [1] - https://code.msdn.microsoft.com/windowsdesktop/Bluetooth-Connection-e3263296
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
