Hi,

My WindowsMobile-Application search for Bluetooth Printer and should use the nearest one. There is the possibility that there are many Printers in Range. I get the device-list from the DiscoverDevices-function but when I access the RSSI Property, the code is blocked for 2-3 seconds. It seems that the Getter of this property causes a query for the actual RSSI and did not return a stored value. That is for me a unexpected behavior because I expected that the property return immediately the "old" RSSI value, so my list can be sorted in milliseconds. But when every reading access to the RSSI-Property needs 3 seconds - the sorting takes at least 3 seconds multiplied by the nummer of devices in range.

Thats why my application needs very much time for printing on the nearest device. Is there any workaround for this problem (except taking a random device from the list)? 

Yeh I don't like myself that get_RSSI does a connect internally if required.  In my option, and according to the MSFT framework guidelines, a property should be quick and have no side-effects.  In later Bluetooth specifications the device discovery ("Inquiry") process returns the RSSI value but that's not exposed by any of the stacks.  So to have a RSSI value we'd have to do the RSSI request and would only get a value if the two devices were connected.

Would having a property that did NOT do the connect but instead returned "unknown" be better.  I suspect it would return "unknown" for most devices however. :-'(

Hi Alan,

maybe a function "GetRSSI" instead of a property is a more intuitive class design. Or just use a private field that stores the rssi as the return value for the property. When calling the function "refresh" the actual rssi will be stored in the field. That would be great. The connect is not the problem. To query the rssi a connect must be done - thats ok. 

But without having a cached rssi-value, I must use this workaround: encapsulate the bluetooth-deviceinfo class in my own class and stored the rssi-Value in my private field, so I can access the rssi-value many times without performance issues. Ok, thats no problem, now my Code must store the rssi but I think the property is the right place for the caching code.

Are there any internal sortings done in the DiscoverDevices function? It seems that the device with the best rssi are the first element in the array, but can I rely on this?