messagingtoolkit

The following changes was made in this release.

1. Fixed USSD command encoding issue with Huawei modem.
2. Added configurations for controlling header and data compression control for MMS data connection.
3. Fixed a message decoding bug in MMS library.
4. Added a configuration to control the "Profile" header while establishing data connection to MMSC.

Thanks
Regards
admin

Release 1.3.0.0 is out. You can download it at https://twit88.com/platform/projects/show/mt-qrcode

Thanks
Regards
admin

The patch release is available for download at https://twit88.com/platform/projects/list_files/mt-mms

The patch will be incorporated into upcoming MessagingToolkit 1.4.3 release.

If you have properly sending USSD commands using Huawei E160 or E173, have a look at this thread

https://twit88.com/platform/boards/2/topics/show/925

Thanks
Regards
admin

The followings are fixed in this patch release

1. Reset the memory location to original after a status report is read from the memory location
2. Fix MessagingToolkit.Core.Utilities sample to include time in Scheduled Sent Message date
3. Fix mobile gateway so that USSD response event is triggered without adding MessageReceived event handler.
4. Set the MessageoStorage correctly while connecting to the gateway

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

See more information available here http://connect.microsoft.com/VisualStudio/feedback/details/236183/system-io-ports-serialport-getportnames-error-with-bluetooth

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...

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

This release fixed a few bugs. It is available for both .NET 3.5 and 4.0.

A separate release for .NET 4.0 is available for download now.

This is a minor release which fixes some bugs in the sample code.