Detect just mobiles

[jordi120]

Hi Mike,

I thought this piece of code

e.Accept = (((COD & wcl.wclCODs.COD_MAJOR_MASK) >> wcl.wclCODs.COD_MAJOR_BIT_OFFSET) & wcl.wclCODs.COD_MAJOR_PHONE) != 0;

was filtering all the mac address but the mobiles one, but I found one MAC which is not a Mobile (or I think so, actually i'm not sure what this is) (00:10:60:30:5B:BD).

Maybe the unknown devices which COD is 1 1 1 1 1 escapes to this line of code? because 1 1 1 1 1 & 0 0 0 1 0 is not 0... (actually I'm not sure if i have understood correctly the line of code).

[jordi120]

well, I found this topic on the forum, maybe it will help, no?

http://forum.btframework.com/index.php?topic=677.0

[Mike Petrichenko]

I araid you mixed up a different things. The code above filters all the devices which has PHONE bits set. It includes lot of MINOR codes which may not mobile phones

[jordi120]

Yes, I thought that if the COD of the device had the major code of a phone, it would be a phone, but as I see in the topic posted above you suggest this one:

if (((COD & COD_MAJOR_MASK) >> COD_MAJOR_BIT_OFFSET == COD_MAJOR_PHONE) && (((COD & COD_MINOR_MASK) >> COD_MINOR_BIT_OFFSET == COD_PHONE_MINOR_SMART) || ((COD & COD_MINOR_MASK) >> COD_MINOR_BIT_OFFSET == COD_PHONE_MINOR_CELLULAR)))
{
   // It is mobile phone
}
else
{
  // It is not mobile phone
}

Maybe this is the cause of the strange behaviour of my app in random contexts, maybe the wclProximitySender tried to connect to some kind of device which make thinks went crazy.... (I hope so!)

[Mike Petrichenko]

now your code looks correct

[jordi120]

Do you think I could get wierd errors if the proximity sender tried to connect to some other device like a phone modem or something like that?

Maybe the wierd error which made a password promt appear is because of this?

Only want to know your opinion, because this error happens very little times, if I make know the update with this piece of code I will never be sure it is fixing this error or it is just not happening by chance...

(it's really hard to express my ideas in english sorry!)

[Mike Petrichenko]

First I do recomend to use the latest WCL version.
Then let me know your driver version and device which cause the error.
So we can reproduce it and fix.

With regards to your code: our product (TextBlue) does not include any devices filter and works good (at least I hope)

[jordi120]

Thanks you then, good to know.

Maybe my wierd error it's because If a device is close to the software, and does not respond to the requests of the proximitySender, at the end the device itselfs tries to block this requests in order to avoid a SPAM atack (this is the only real difference I'm seeing now between your software and mine, in textblue if a device returns a timeout 3 times in a row it is put in a temporal black list or this is what i think I saw when I tested your software). I wanted to do something like this at first (put a device in a temporal blacklist) but I was forbidden to do this by my partners (they say this would make the software do less sendings).

As always, sorry for my english and above of all, thanks you for your quick answers.

[Mike Petrichenko]

Hello,

Sorry for delay with answer.

I do not think that the "permanent" sending is good idea because people (receipients) may be annoyed and you may be named "spammer". The receipients must have choise and be able to cancel sending somehow. The right way looks for us as sending number limitation. That is why our software (and other software too) has that parameter. I do recomend to add it to your application too.

Unfortunately we have never been reported about such problem (except of you) before and never saw it with TextBlue. That is why I can't say something usefull or provide a bugfix.

But we will any way monitor that situation and if we can reproduce it - we will fix it immediately.

P.S. Your english is geat.

[jordi120]

Do not worry, I will search by my own, I'm pretty sure this happens just in one kind of usb devices and in one kind of remote devices and in one kind of situation concrete.

Of course on my app, if a user says 'no' or says 'yes' to a sending, it is 'blacklisted' as it has been configurated too, but I was thinking about that moments when some remote device is static near to the sender and is not answering to the requests because the user is busy or is not hearing his phone. In this cases, my software tries to connect to this phone until he answers yes or no (if this answer never comes, the software is allways retrying the requests to this device).

I will study this more deeply this christmas,
Thanks you

[jordi120]

It's kinda funny, just for testing purposes i put yesterday in a lot of computers with the software this code:

this.device.SetConnectable(false);

Well, at the moment no one report me the error I mentioned above. I put this here because if this things makes my problem goes away maybe someone will find it usefull.

[Mike Petrichenko]

Aha! It looks like other device (software) (not your one) tryed to connect to your PC! And that is why it happened not too often. So that wasn't your bug or WCL bug. And that is great idea to set connectable to false!