messagingtoolkit: System.IO.Ports.SerialPort.GetPortNames error with Bluetooth

Added by admin almost 6 years ago

This problem is due to the COM port values are not null terminated in the registry.

See more information available here

I have seen the issue and trying some workarrounds. If you open the registry key HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM and look at a bluetooth device (right click and open "edit binary data") you will see that the portname is not null terminated, thus not respecting the registry type REG_SZ. The function to read the registry in .NET wrappers at least, are assuming the NULL will be there and not checking anything (making a memcpy and the last two bytes - unicode null - are left with whatever garbage is there) so the last to bytes can lead to some unicode value, sometimes a letter sometimes a symbol, whatever. You can verify this reading directly the registry entry for the port. My workarround will consist in getting the bytes from the string, replacing the last two bytes with 00 00 and reencodign the string... not done yet. Please comment if someone can workarround on this, also Microsoft, maybe a fix can be included in ORCAS... the bug is in the bluetooth stack from microsoft and in the registry functions...

messagingtoolkit: Patch release

Added by admin about 6 years ago

In this patch release, we

  • updated the demo program to use the latest barcode library
  • fixed a bug that caused the message storage location to be modified when a memory location of a status report arrived

messagingtoolkit: Release is out

Added by admin over 6 years ago

There are a few minor bugs which are fixed in this release. In additional now you can send DTMF tones using the library.

Please take note that DTMF commands may not be supported in every phone or modem.


Also available in: Atom