Hello,

I'm trying to get attribute IDs and their values from a certain bluetooth server. Here's the relevant code snippet:

for (int j = 0; j < serviceRecord.Count; j++)
{
label3.Text += ("\nID" + serviceRecord[j].Id.ToString("X") + ": " + GetServiceAttributeAsString(serviceRecord[j]));
}

The method "private static string GetServiceAttributeAsString(ServiceAttribute sa)" chooses the right GetValueAs...() for each ElementType in order to return a displayable string.

The content of label3 looks like this:

ID0000: 65537
ID0001: (element sequence)
ID0004: (element sequence)
ID0005: (element sequence)
ID0008: 255
ID0100: Data access
ID0101: Data access profile using MyProtocol
ID0102: gate

Unfortunately not all attributes are found. I'm really sure that the server also provides the IDs 4000 and 4001.BlueZ (Linux) is able to find them.
I think my code is OK because of the reasonable output, but maybe there's some kind of limitation.

Does anybody have similar experiences? Is there a way to access the IDs 4000 and 4001?

I've just tried manually adding a record with attributes in that range, and SdpBrowserDesktop app displayed then ok.  Can you try the SdpBrowserDesktop sample app and see whether is displays the record like BlueZ does.

If not can you call bdi.GetServiceRecordsUnparsed(...) and dump the output here.  We can see then whether the decoding of the record is wrong, or whether the attributes are not all being downloaded correctly...

SdpBrowserDesktop shows me the same as BlueZ (including the IDs 4000 and 4001). That's cool :-)
But if I run the corresponding device application SdpBrowserPPC, I get the same as in my application (without ID 4000 and 4001).

Currently I'm trying to get something useful out of the bdi.GetServiceRecordsUnsparsed(...) ...

Using bdi.GetServiceRecordsUnparsed(...) doesn't work for the IDs 4000 and 4001on my mobile device. I only get the attributes between ID0 and ID102.
What I discovered: SdpBrowserDesktop and SdpBrowserPPC both use the "unparsed way". That means there should be no difference because of the implementation.
I think the difference must be the device class respectively the operating system (in my case: WinXP vs. WM6). Why is my PC able to find ID4000 and ID4001 and my mobile device not?

For those who are interestend in my code:

foreach (Guid installedService in btDevInfo[comboBox1.SelectedIndex].InstalledServices)
{
foreach (byte[ ] byteArray in btDevInfo[comboBox1.SelectedIndex].GetServiceRecordsUnparsed(installedService))
{
ServiceRecordParser serviceRecordParser = new ServiceRecordParser();
ServiceRecord serviceRecord = serviceRecordParser.Parse(byteArray);
textBox1.Text += ServiceRecordUtilities.Dump(serviceRecord);
}
}

Yup, sounds like a problem on the WM/CE platforms.  Unfortunately I've broken my WM device so I can't test at the moment.  I'll have a look at the library code when I get a moment anyway.  When we ask the system to do an SDP query we do pass in the range of attributes we want and we pass in 0 to 0xFFFF as I remember, so that should be ok...

I think seeing the 'raw' record from GetServiceRecordsUnparsed is not so important now as I *think* it unlikely that its a parsing error; but I'd recommend using BitConverter.ToString(byteArray) to get a string like 01-FF-2E-34-91 etc to dump here.

Tell you what, far easier would be to use the SdpBrowser samples and dump the the output they produce (the normal output and with <dump bytes> too).

I've looked through the current code and it is currently set to retrieve attributes from 0-0x800 which explains why it is not showing these. I'm modifying the code to pas 0xffff as the upper bound so that it will always return all attributes.

Peter

Very cool, thank you very much! I was already affected with self-doubts ... ;-)

Just for me as an information: that means there are differences in the implementations of the CE/WM and the Desktop version, right?

@ Peter: what do you think, when can I await the improved version?

Thanks for all your help! :-)

Tilman

Yup there are some difference in the native APIs on the two platforms so the library has to have different code to get the same behaviour.

As to getting an updated version.  The library sources are available, so you should be able to download them and compile an updated version for yourself.  See http://www.codeplex.com/32feet/SourceControl/ListDownloadableCommits.aspx  Compiling shouldn't be straitforward.  (Initially disable building all the samples as reference issues /can/ occur with them and produce lots of apparent errors).

Alan

Hello again,

thanks for the hint with the source code. I followed all the steps in the readme (disableing of the samples etc.) and got nice 143kB of dll.

But now there's the next problem: as soon as I reference this dll in a small application, many of the standard libraries (e.g. System, System.Xml, ...) are not found anymore. Here's one of the error messages from the box at the bottom of the screen (they're all quite similar):

The type 'System.Uri' is defined in an assembly that ist not referenced. You must add a reference to assembly 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

If I replace the new dll with the old one everything is fine again and my small application works like charme (everything but the IDs 4000 and 4001 :-P).

Do I have to take care for any version number before debugging the library? Or is any version of .NET missing on my computer? Currently I've installed the following versions of .NET Framework:
1.1
1.1 German Language Pack
1.1 Hotfix
2.0 SP2
2.0 SP1 Language Pack - DEU
3.0 SP2
3.0 SP1 Lanuage Pack - DEU
3.5 SP1
CF 2.0 SP2
CF 3.5

IMHO this should be enough, at least with InTheHand build 2.2 it was.

So maybe this is a known issue or I made a stupid mistake, so it's not a big effort for you to help me.

Tilman

If this is a NETCF project then you need to use the assembly from within the "InTheHand.Net.Personal.CF2" project folder.  I think you've used the main desktop version.  I should have mentioned the three/two library projects. :-,(

(The well-known PublicKeyToken values are:
b77a5c561934e089   ECMA, desktop
b03f5f7f11d50a3a    Microsoft, desktop
969db8053d3322ac   MSFT .NETCF

and the first it being reported in your case!)

Alan

Good Morning nice world!

It works!

@Alan: thank you very much for the hint with the diversity of library projects, that was the problem.

@Peter: thank you for expanding the range to 0xffff. I can access now all the attributes I need.

CU maybe with my next problem ;-)

Tilman